tssci security

bruteoptions.py -- Get allowed HTTP Methods for a list of directories

A recent email by Dave Aitel to the Dailydave mailing list on Pen testing web servers was an inspiration to publishing a short, but simple script. I like to keep things simple when I write scripts, taking the Unix philosophy of doing one thing and doing it well.

bruteoptions.py takes two arguments: 1) a FQDN of a known site, and 2) a file with directory names. The script runs through and performs an OPTIONS HTTP Request for each directory name in the file. In the past, I've used a combination of directories I've identified while browsing/spidering a website through Burp, and the other partly a dictionary list taken from a tool like OWASP DirBuster.

Using the tool is simple, just specify the site FQDN to scan and give it a file as a second argument.:

$ ./bruteoptions.py
./bruteoptions.py <url> <list of directories>``

$ ./bruteoptions.py tssci-security.com dirs
“tssci-security.com”,”/about/”,”200 OK”,”Apache/1.3.39 (Unix)”,”None”
“tssci-security.com”,”/upload/”,”200 OK”,”Apache/1.3.39 (Unix)”,”GET, HEAD, OPTIONS, TRACE”
“tssci-security.com”,”/projects/”,”200 OK”,”Apache/1.3.39 (Unix)”,”None”

An interesting thing I've just noticed, is the lack of allowed methods returned for a virtual directory, versus an actual directory when run against my site. If anyone cares to comment about this, I'd be interested to know what is the cause.

You can download the script from the bruteoptions.py project page.

Writing a web services fuzzer in 5 minutes to SQL injection

This week, I was doing an internal penetration test for a client of a web service, which is used by applications loaded on kiosk machines around the country. I didn't have much time to do the test, so I had a couple advantages, like having network access to the service, the WSDL and also ability to interact with the developers. This also gave me a chance to see how capable our web application firewall was at being able to detect attacks.

I had some trouble with WSFuzzer, and kept getting "XML Fault" errors like the one below:

There was an anomaly encountered in interfacing with the provided target. The neuroFuzz team is aware of these situational conditions and we are looking into the root cause(s) ...

If you would like to help with this type of research send the following data along with some details about the target service to wsfuzzer@neurofuzz.com

Response: XML Fault

Ok, no big deal -- I'll just write my own! I loaded up soapUI and put in the WSDL address, and soapUI was able to generate the XML requests according to the WSDL. soapUI automatically puts a question mark placeholder into the input areas, so I then saved these as individual XML files -- one for each service method.

Then, I wrote a quick BASH script that looped through each line in WSFuzzer's Attack_all.txt and replaced every placeholder parameter in each XML file with the attack string:

#!/usr/bin/env bash# Generate our attack files
# Escape slashes and backslashes
sed -e 's/\\\\/\\\\\\\\\\\\\\\\/g; s/\\//\\\\\\\\\\//g; s/:::.*//g' All_attack.txt > All_attack.txt~echo -n "Generating attacks"n=0
for i in `ls -1 *.xml`
        while read line
                sed "s/?/${line}/" $i > $i.$n
                #echo "Writing $i.$n"
                echo -n "."
                let "n+=1"
        done < All_attack.txt~
        let n=0
doneecho " done"# Cleanup
echo "Removing temporary files no longer needed."
rm All_attack.txt~exit 0

This script will then generate one XML file for each attack string per method. In my case, it generated close to 15,000 XML files. So what do we do with this? We'll use cURL to POST it to the web server (after removing SQL shutdown statements and other risky injections):

$ for i in `ls *.xml.*`; do curl -A "marcin" -s -x -k -d @$i -H "Content-Type: text/xml;charset=UTF-8" -H "SOAPAction: \"\"" https://service-tested:8443/warfile/service/Endpoint; done

I specified a proxy by using the -x flag with cURL so I can proxy it through Burp, which keeps a detailed request/response log I could later pour through.

So there you have it: a web services fuzzer in 5 minutes, or less. Sure, it doesn't replace WSFuzzer as WSFuzzer does a lot more, it was enough for my purposes and gave me time to do other testing. The best part about this, was when the database administrator notified us about a SQL injection we did that caused the CPU load to spike for a duration of time. He's been asking the developers to fix the query for months now, but his reasons for fixing were for performance. Now he's got a security reason to fix the code, and I wouldn't have been surprised if they fixed it that same day.

Oh, and for those wondering... the WAF missed about 25% of the attacks.

Decreasing Security for Perceived Security -- all in the name of compliance

Today I ran into a little setback for an issue I did not foresee. For the past several months, I've been on a PCI remediation project, of which one of my tasks was to implement a web application firewall to address PCI requirement 6.6. Now, for everyone out there who has been following our posts, knows us dealing with WAFs is worse than pulling teeth.

So, in creating a secure Apache standard build, I seemed to have over-engineered and made our build too secure. How? Well, one of the lines in our httpd.conf included the following SSLCipherSuite directive:


With support for the following ciphers:

DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

Looks good right?

This directive, included the Diffie-Hellman ciphers, which I was reminded by blatant error messages of unsupported ciphers in the management console, that it was not susceptible to MITM attacks due to the nature of the key-exchange. Doh! What's this mean? Our WAF, was rendered useless for monitoring and protecting our application because our SSL encryption strengths being negotiated were the most secure, and thus, the WAF had no visibility into our application. The most common SSL cipher being negotiated was TLS_DHE_RSA_WITH_AES_256_CBC_SHA -- the most secure of all.

So to comply with PCI Requirement 6.6, I had to step down our list of available SSL ciphers with the following SSLCipherSuite directive:


which at least provided support for the following ciphers:

AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

So much for PCI Requirement 4.1, which requires the use of strong cryptography and security protocols such as SSL/TLS to safeguard sensitive cardholder data. This post is just a little FYI for those in the same boat. Turns out we can be "too secure," :P

As my manager likes to sometimes put it, "How do you like 'dem apples?"

Looking forward to OWASP EU Summit Portugal

In only a couple weeks, many of the greatest minds in web application security will come together again for OWASP EU Summit in Algarve, Portugal. The Summit is a gathering whose main goal is, besides promoting the exchange of ideas on web application security, defining the future of OWASP itself. In other words: Do you want to help define the future of web application security? If so, the OWASP Summit is the place to be.

This year, the Summit will happen in November, from the 3rd to the 7th, in Portugal. It will offer a great selection of training and technical sessions, regarding the most important OWASP projects and themes. It will also host a business track dealing with the usage of OWASP generated documents and tools by companies worldwide and with the opportunities for these companies to help OWASP's development. It will be a great opportunity to meet the people that make a difference in the web security arena.

I will be attending, as a reviewer for AntiSamy.NET and also to join in the discussion on browser and framework security, a workshop hosted by the Intrinsic Security Working Group. I'll be flying out several days earlier to do a little tourism -- gotta make the most of "training" days ;) -- so if anyone has been to the area before and has any recommendations, I'd love to hear them.

Don't forget to check out the training and working sessions available.

Some of training being offered at OWASP EU Summit:

Training Courses

Monday, November 3, 2008

Advanced Web Application Security Testing (day 1 of 2)

Building Secure Web Services (day 1 of 2)

WebAppSec for Managers and Executives - The Road Less Travelled (1 day)

Uncovering WebScarab's Secret Treasures (1 day)

Secure Programming with Java (1 day)

Building Secure Web Applications with OWASP's Enterprise Security API (ESAPI) (1 day)

Building Secure Web 2.0 Applications (1 day)

Web server/services hardening using SELinux (1 day)

Web Application Assessments (1/2 day PM)

Hacking OWASP Orizon Project v1.0 (1/2 day PM)

Tuesday, November 4, 2008

Advanced Web Application Security Testing (day 2 of 2)

Building Secure Web Services (day 2 of 2)

The Art and Science of Threat Modeling Web Applications (1 day)

Ajax Security (0,5 day AM)

Securing WebGoat with ModSecurity (1/2 day PM)

Flash Player Security (1/2 day AM) Auditing Flash Applications (1/2 day PM)

OWASP Top 10 - What Developers Should Know on Web Application Security (1/2 day)

OWASP Testing Guide (1/2 day PM)

In summary, it will be an unparalleled opportunity to learn, share, and network.

Don't Tell Mom the World is Gonna End

Today, another vulnerability has been making the headlines, various industry security professionals predicting apocalyspe, genocide and famine along with everything in between. It first started earlier this summer, back when Dan Kaminsky, in a multi-vendor coordinated effort, told the world of his DNS vulnerability. Then came the BGP hijacking, disclosed by Tony Kapela and Alex Pilosov at Defcon. Granted, these were serious issues and not to discredit their research, the vulnerabilities themselves were nothing truly groundbreaking. Both DNS poisoning and BGP hijacking are literally implemented into the RFC -- it was all just a matter of enumerating the various ways of doing it.

Following, came RSnake's and Jeremiah Grossman's browser Clickjacking bug, which when disclosed to Adobe, Adobe took upon themselves to fix within Flash and asked both to cancel their OWASP presentation at AppSec NYC 2008 last week. Today (or rather this week), was Robert E. Lee's and Jack Louis' SYN Cookie DoS vulnerability, affecting almost every TCP/IP stack implementation. (why people are even using SYN cookies is beyond my comprehension -- it's a hack and does not mitigate DoS attacks, though that's a seperate discussion on its own) [Edit (10/02/2008 11:30): I misread the original post and it is not a vulnerability with SYN cookies. Robert was using SYN cookies as an analogy. See Outpost24's TCP DOS Attack Explained]

The common occurrence between these vulnerabilities? They all were touted as super critical vulnerabilities that could bring down the internet and pwn every being in existence. In addition, the researchers behind them opted not to disclose details of the vulnerability. What this created, was an incentive, or challenge to others to discover the vulnerability before the discovering researchers decided to fully disclose. It took about two weeks before Halvar figured out Dan K's bug, and only another couple hours for Arshan to figure out the Flash/clickjacking vulnerability.

I read this Slashdot comment earlier today which I found hysterical, that poked fun at RSnake's "Robert and Jack are smart dudes." I know RSnake is a smart dude too, but really, at the end of the day, you're taking our word for it. And to quote Bruce Potter, "Don't believe anything I say."

But seriously though, I think the blogosphere is doing a disservice hyping these vulnerabilities to no end, and researchers doing a disservice to themselves when they disclose this way. Don't tell the world until you're ready. If you're not ready, stay home. The security industry needs to stop crying wolf, because not everybody holds security to the same level of attention as we do. People are getting tired of the fear, uncertainty and doubt we spread.

Instead, let's focus on fixing the problems and providing lessons learned so these vulnerabilities don't crop up again. That's what people truly want to see. If you discover a vulnerability and want to report it to the vendor, that's great! Continue to work with the vendor until a patch has been released before going public -- even to announce you have something. Just please, don't come out and ask us to pick a hand when you know both are empty.

« Newer entries — 4 — Older entries »

blog comments powered by Disqus