This morning I read Sniffing HTTPS URLS with malicious PAC files by Alex Chapman and Paul Stone. It's an excellent summary of a key problem with PAC files, mainly that its a JavaScript file delivered by HTTP with well-known techniques to push to unsuspecting clients, and that this script has full access to all URLs - including the content of SSL URLs. Chapman and Stone demonstrate a simple technique to exfiltrate the SSL URLs via DNS. Since the technique is now public, I'm publishing my findings and code from 2007 as a more fully weaponized tool that allows selective targeting and exfiltration of URL (including SSL URL) values.
Showing posts with label vulnerability. Show all posts
Showing posts with label vulnerability. Show all posts
Thursday, July 28, 2016
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
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)