To help improve system configurations, iSEC is releasing the free software “SSLyze” tool. They have found this tool helpful for analyzing the configuration of SSL servers and for identifying misconfiguration such as the use of outdated protocol versions, weak hash algorithms in trust chains, insecure renegotiation, and session resumption settings.

SSLyze is a stand-alone python application that looks for classic SSL misconfiguration, while providing the advanced user with the opportunity to customize the application via a simple plugin interface.

Features

• Insecure renegotiation testing
• Scanning for weak strength ciphers
• Checking for SSLv2, SSLv3 and TLSv1 versions
• Server certificate information dump and basic validation
• Session resumption capabilities and actual resumption rate measurement
• Support for client certificate authentication
• Simultaneous scanning of multiple servers, versions and ciphers

For example, SSLyze can help user’s identify server configurations vulnerable to THC’s recently released SSL DOS attack by checking the server’s support for client-initiated renegotiations. For more information on testing for client-initiated renegotiations, you can read here.

You can download sslyze here:

sslyze-0.3_src.zip

Or read more here.

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.

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.

To get this running:

• Flip your machine into forwarding mode.
• Setup iptables to redirect HTTP traffic to sslstrip.
• Run sslstrip.
• Run arpspoof to convince a network they should send their traffic to you.

That should do it.

How does this work?

First, arpspoof convinces a host that our MAC address is the router’s MAC address, and the target begins to send us all its network traffic. The kernel forwards everything along except for traffic destined to port 80, which it redirects to $listenPort (10000, for example).

At this point, sslstrip receives the traffic and does its magic.

You can download sslstrip 0.2 here:

sslstrip-0.2.tar.gz

Or read more here.