This tool was originally written to demonstrate and exploit IE’s vulnerability to a specific “basicConstraints” man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes.

It is designed to MITM all SSL connections on a LAN and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.

The three steps to get this running are:

• Download and run sslsniff-0.7.tar.gz
• Setup iptables
• Run arp-spoof

Changes in 0.7

• Fixed some networking shuffling bugs (thanks Daniel Roethlisberger)
• Added basic compatibility with BSD pf (thanks Daniel Roethlisberger)

You can download sslsniff v0.7 here:

sslsniff-0.7.tar.gz

Or read more here.

1. Works if scapy doesn’t drop packets. using pcap instead of SOCK_RAW helps a lot now.
2. Works better on interactive traffic with no traffic at the time of the ptrace. It follows the flow, after that.
3. Dumps one file by fd in outputs/
4. Attaching a process is quickier with –addr 0xb788aa98 as provided by haystack INFO:abouchet:found instance @ 0xb788aa98
5. how to get a pickled session_state file : $ sudo haystack –pid `pgrep ssh` sslsnoop.ctypes_openssh.session_state search > ss.pickled

Not all ciphers are implemented.

Workings ciphers: aes128-ctr, aes192-ctr, aes256-ctr, blowfish-cbc, cast128-cbc
Partially workings ciphers (INBOUND only ?!): aes128-cbc, aes192-cbc, aes256-cbc
Non workings ciphers: 3des-cbc, 3des, ssh1-blowfish, arcfour, arcfour1280

It can also dump DSA and RSA keys from ssh-agent or sshd ( or others ).

You can download sslsnoop here:

trolldbois-sslsnoop.zip

Or read more here.

This time some researcher type fellas focused on the digital noise autocomplete webforms make over an encrypted connection and how it can expose some pretty sensitive data such as medical histories, income, search queries and more.

Google, Yahoo, Microsoft’s Bing, and other leading websites are leaking medical histories, family income, search queries, and massive amounts of other sensitive data that can be intercepted even when encrypted, computer scientists revealed in a new research paper.

Researchers from Indiana University and Microsoft itself were able to infer the sensitive data by analyzing the distinct size and other attributes of each exchange between a user and the website she was interacting with. Using man-in-the-middle attacks, they could glean the information even when transactions were encrypted using the Secure Sockets Layer, or SSL, protocol or the WPA, or Wi-fi Protected Access protocol.

“Our research shows that surprisingly detailed sensitive user data can be reliably inferred from the web traffic of a number of high-profile, top-of-the-line web applications” offered by Google, Yahoo, and Bing as well as the leading online providers of tax, health and investments services, which the researchers didn’t name.

There’s a lot of inference going on but from what I understand of the attack it would only get more accurate as they collected more data and refined the pattern matching.

The attack can succeed over SSL (https connections) or WPA encrypted wireless sessions.

It’s like a rather complex puzzle piecing together different snippets of meta data to come out with an answer, which so far seems to be working well.

They also showed how the auto-suggestion features in Google, Yahoo!, and Bing can leak the search terms users enter, even when traffic is encrypted over WPA. That’s because the resulting packets are easy to identify by their “web flow vectors.”

The threat is significant because it stems from fundamental characteristics of software-as-a-service applications that have been in vogue for about a decade. Among other things, apps built on AJAX and other Web 2.0 technologies are usually “stateful,” meaning they keep track of unique configuration information. Such data often has “low entropy,” making it easy for attackers to make educated guesses about its contents.

While a variety of mitigations are available to prevent such attacks, the researchers warn they could come at a high cost. The most obvious solution is to “pad” responses with superfluous data that confuses attackers trying to make sense of the traffic. But the researchers showed the mitigation isn’t always effective and they also point out that it adds a considerable amount of traffic to each transaction, which in turn drives up the costs of operation.

Honestly as a real life attack, apart from corporate espionage or identity theft I don’t see how it is very practical or dangerous.

Plus mitigation will produce a lot of redundant data and increase operation costs, who wants that?

You can get the full white-paper here:

WebAppSideChannel-final.pdf [PDF]

Source: The Register

When this SSL Renegotiation bug hit the news, most people said it was a theoretical attack and was of no practical use in the real world.

But then people tend to say that about most things don’t they until they get pwned up the face.

It turns out the rather obscure SSL flaw can be used to take over user accounts from websites that use API’s and especially those utilizing 3rd party clients (Twitter being the biggest but a lot of people are accessing Facebook now using clients too).

A Turkish grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the secure sockets layer protocol.

The exploit by Anil Kurmus is significant because it successfully targeted the so-called SSL renegotiation bug to steal Twitter login credentials that passed through encrypted data streams. When the flaw surfaced last week, many researchers dismissed it as an esoteric curiosity with little practical effect.

For one thing, the critics said, the protocol bug was hard to exploit. And for another, they said, even when it could be targeted, it achieved extremely limited results. The skepticism was understandable: While attackers could inject a small amount of text at the beginning of an authenticated SSL session, they were unable to read encrypted data that flowed between the two parties

So even though the fella couldn’t decrypt or read the data in the session, he could manipulate it in such a way that it spat out the goodies using the Twitter API.

It’s a very neat attack if you ask me, especially if you executed it via DM (Direct Message) it’s pretty unlikely anyone would notice their account had been ‘hacked’.

Perhaps this is how the bad guys have been doing it for a while because I do see an awful lot of hijacked accounts on Twitter and the owners have no idea why (they hadn’t logged in to any dodgy sites with OAuth or their Twitter credentials).

Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter’s servers, even though they were encrypted. He did it by injecting text that instructed Twitter’s application protocol interface to dump the contents of the web request into a Twitter message after they had been decrypted.

“My point is I think that it’s not so hard to make it work,” said Kurmus, who lives in Zurich and recently completed his masters thesis at the Eurecom Institute. “Maybe some other people did the same thing and did not make it public, so this is why I think it’s important that people would take this bug more seriously.”

Twitter proved an ideal platform to carry out the attack for several reasons. First, every request sent over the microblogging site includes the account holder’s username and password. Second, the site’s API made it easy to post the contents of the intercepted data stream into a message that an attacker could then retrieve.

Twitter has apparently plugged the hole from their side, but as the flaw in SSL itself it seems only one vendor is near to issuing a patch (OpenSSL).

If you extrapolate a little though, this attack could work on anything with a POST/GET interface on the web running on SSL – like Gmail for example.

I hope companies get to patching and plug this hole as it can be carried out all too quietly and wreak a whole lot of havoc!

Source: The Register

This tool was originally written to demonstrate and exploit IE’s vulnerability to a specific “basicConstraints” man-in-the-middle attack. While Microsoft has since fixed the vulnerability that allowed leaf certificates to act as signing certificates, this tool is still occasionally useful for other purposes.

It is designed to MITM all SSL connections on a LAN and dynamically generates certs for the domains that are being accessed on the fly. The new certificates are constructed in a certificate chain that is signed by any certificate that you provide.

New In Version 0.6

Version 0.6 has been significantly updated to additionally support the null-prefix attacks that was demonstrated at BlackHat 09 and Defcon 17. These allow for completely silent MITM attacks against SSL/TLS in the NSS, Microsoft CryptoAPI, and GnuTLS stacks — ultimately allowing for SSL communication in Firefox, Internet Explorer, Chrome, Thunderbird, Outlook, Evolution, Pidgin, AIM, irssi, and every other client that uses the Microsoft CryptoAPI to be intercepted.

sslsniff has also been updated to support the OCSP attacks that was published at Blackhat 09 and Defcon 17, thus making the revocation of null-prefix certificates very difficult. Additionally, sslsniff now supports modes for hijacking auto-updates from Mozilla products, as well as for Firefox/Thunderbird addons. Attackers can specify payloads of their choice, which will be delivered to the targets being man-in-the-middled.

sslsniff is useful for deploying other vulnerabilities as well. This is the tool that the people who pulled the recent MD5 hash collision publicity stunt used to demonstrate MITM attacks with their rogue CA-certificate. Also, anyone who is capable of obtaining a forged certificate by any means can easily deploy it through sslsniff with the targeted mode designed for null-prefix attacks.

You can download sslsniff v0.6 here:

sslsniff-0.6.tar.gz

Or read more here.