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.
Posted by Marcin on Wednesday, December 31, 2008 in
Code and
Security.
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`
do
while read line
do
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 127.0.0.1:8880 -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.
Posted by Marcin on Sunday, December 14, 2008 in
Code,
Security and
Work.
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:
SSLCipherSuite HIGH:MEDIUM:+TLSv1:!LOW:!EXP:!ADH:!aNULL:!eNULL:!NULL:!SSLv2
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:
HIGH:MEDIUM:+TLSv1:!DH:!LOW:!EXP:!ADH:!aNULL:!eNULL:!NULL:!SSLv2
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?"
Posted by Marcin on Thursday, November 20, 2008 in
Security and
Work.
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.
Posted by Marcin on Saturday, October 18, 2008 in
Conferences and
Security.
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.
Posted by Marcin on Wednesday, October 1, 2008 in
News,
People and
Security.
