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.
Tuesday, August 6, 2013
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.
Labels:
cryptography,
DES,
hacking,
netlm,
ntlm,
privacy,
security,
tricks,
vulnerability
Monday, March 11, 2013
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
Tuesday, February 5, 2013
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.
Sunday, February 3, 2013
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.
Monday, January 21, 2013
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'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.
--------------------
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.
Labels:
cryptography,
lancom,
openssl,
private key,
public key,
shodan,
ssl,
tls,
vulnerability
Subscribe to:
Posts (Atom)