Challenger: A Tool for Breaking NETNTLM/MSCHAP Hashes

A few months ago I stumbled upon an excellent write-up explaining the details of NETNTLM (NTLMv1 Challenge Response) authentication. It's an interesting design, and two things jumped out at me right away: the use of a symmetric cipher (DES) rather than only hashing functions, and the odd way the hash is split into three, uneven, portions. This inspired me to work on increased attack speeds against NETNTLM. In the end, I created a small Python tool called Challenger that significantly accelerates dictionary-based attacks on NETNTLM challenge-response hashes.

More Proxy Authentication Fun!

As an update to my post about stealing credentials via proxy authentication requests, it looks like Chirs John Riley has found that Privoxy not only still allow this (I last tested around 2007 with the Tor bundle), but it will even pass actual proxy credentials in plain text if you're using an authenticated proxy. Ouch!

Privoxy Proxy Authentication Credential Exposure – CVE-2013-2503

Stealing Windows Credentials Silently from the Browser

Proxies are a wonderful tool for anonymity, but here we'll exploit them to silently steal identifying information and credentials of a Windows user by visiting one website.

IPv6 Privacy and Hurricane Electric

IPv6 privacy has been a topic that has been garnering more attention as IPv6 has become more prevalent but I've found that there's sometimes more data leaking out than just what the protocol itself leaks.

Free RSA Private Key Giveaway...by Lancom

UPDATE: I've heard back from LANCOM and they suggest, as did the person commenting below, that the problem lies with administrators selecting the wrong "slot" when uploading the key.

--------------------

There is no security problem when using the certificate-based VPN
connection.
When uploading the certificate you have used the wrong certificate type.

You can undo this by creating a text file in which only one blank character
is available.
When you upload the file, please use the certificate type "Message Before
Login (plain text)".

---------------------

While this would seem to be a true statement, it seems a like a particularly bad design choice if, while configuring the device, uploading a private key or a login banner are only a single click away from each other and could so easily result in the publication of the data. At least the Shodan database shows very few devices configured this way (currently 9) so it's hardly a wide-spread problem.

Original Post:

There's always a sense of excitement when I see that magic text "-----BEGIN RSA PRIVATE KEY----- ", and it's not  coming from a file on my computer. Anyone who even slightly understands public key cryptography knows that the key with the word "PRIVATE" doesn't get shared. Apparently, some Lancom router, VPN, and VoIP devices are having a hard time figuring out the difference between public and private keys.

Tracking an Internet User with VoIP

I started taking a closer look at SIP traffic last year, looking for areas to explore - especially information leaks. Of course, if you're receiving a VoIP call plenty of information leaks out: source and destination phone numbers, source and destination IP addresses, client versions, NAT traversal data (internal IP addresses), etc. But you're part of the call, so it's not particularly significant that you're getting some detailed technical information about the caller. But what about when you call someone else, or even just scan SIP services without establishing a call?

Monitoring GSM Networks with SNORT

Last December, during the annual Computer Chaos Congress, I was testing out OsmocomBB and monitoring the CCC test GSM base stations. It gave me a chance to monitor a GSM network being used in a test environment. Since the network was run by OpenBTS and OpenBSC I expected the network to exhibit some differences to more traditional equipment from Ericsson, Siemens, etc. I wanted to try to fingerprint the differences in GSM equipment in order to detect anomalies to assist in identifying rogue GSM towers and/or  what are often referred to as "IMSI-catchers". Within a few minutes of monitoring I realized I wouldn't be disappointed. The very first thing that caught my eye was this very interesting frame...