Logging and Web Services

This post about the paper we wrote earlier this year (“Logging in the Age of Web Services” by Gunnar Petersen and Anton Chuvakin, published in “IEEE Security and Privacy”) will just prove how behind I am on blogging :-) Fortunately,  Gunnar announced this paper a long time ago; I just added it to “2blog” folder :-) The paper will be a useful read to those into either logging or web services or both. I do suspect that web services audit logging will be one of the unresolved mysteries when SaaS/PaaS/IaaS/cloud everything will enjoy further adoption…

Google Docs 0-day?

Or what?

Anton Security Tip of the Day #14: More access_log Fun: What Are You Not GETting?

Following the tradition of posting a tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #14: More access_log Fun: What Are You Not GETting?

In this tip, we will look at some bizarre artifacts that show up in web server access logs today. Here we have a production log from an Apache web server that is full of interesting (and sometimes ominous!) little mysteries that we will investigate in order to determine their impact on security and operational health of the site.

Logs do contain more mysteries than we have time, so we will focus on a few of them: specifically, unusual web request methods. Let's see who is trying to POST or use some other method (OPTIONS, HEAD, PUT or something - see a list here) on our site, instead of just GET'ting the content (GET command is used by web browsers to retrieve the pages, while POST is used to upload content, press buttons, etc - at least in "web 1.0" land - see earlier tip #12 where POST request was found in proxy logs)

Here is one little artifact that attracted my attention due to a POST request vs a web forum as well as a battery of slashes (which actually increases in subsequent request - of which there were many)

10.10.102.250 - - [12/Feb/2008:16:10:50 -0500] "POST /phpBB3////ucp.php?mode=register&sid=e5efaa77a777066c61f71808e9e57b19 HTTP/1.0" 200 14397 http://www.example.com/phpBB3///ucp.php?mode=confirm&id=7640df05c7e24b7acf7a68800fe6dc59&type=1&sid=e5efaa77a777066c61f71808e9e57b19 "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126"

... more...

10.10.102.250 - - [12/Feb/2008:16:12:29 -0500] "POST /phpBB3///////////////ucp.php?mode=login&sid=e5efaa77a777066c61f71808e9e57b19 HTTP/1.0" 200 9355 "http://www.example.com/phpBB3//////////////ucp.php?mode=login&sid=e5efaa77a777066c61f71808e9e57b19" "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126"

This one really is a mystery; what do we know about it? The server responded to the request OK (code 200), so the POST actually happened. The first request was a request to register with a web discussion board and the second was a request to login. Multiple slashes are actually ignored by the web server, so why put them in the request (no answer)? Also, I think that the User-Agent is spoofed ... do you know why? Finally, if I see something like that in my logs, I will definitely investigate it, primarily due to the fact that Apache responded with 200 OK code.

The next one is so classic it it dumb (and so dumb, it's a classic :-))

10.10.123.226 - - [12/Feb/2008:03:46:54 -0800] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 - "-" "MSFrontPage/6.0"

10.10.123.226 - - [12/Feb/2008:03:46:55 -0800] "OPTIONS / HTTP/1.1" 200 20210 "-" "Microsoft Data Access Internet Publishing Provider Protocol Discovery"

It is probably one of the ancient IIS attacks (check out this fun BlackHat preso on that, circa 2003) - why would someone probe for it now is beyond me. In any case, Apache on Linux and "*.exe" don't mix :-)

The final log record is also fun:

10.10.101.222 - - [12/Feb/2008:15:33:22 -0800] "PUT /zk.txt HTTP/1.0" 405 223 "-" "Microsoft Data Access Internet Publishing Provider DAV 1.1"

The above uses a PUT request which is pretty much deprecated now; the purpose of the above is clearly malicious. In fact, modern Apache shouldn't even allow it, thus it responds with code 405 "Method Not Allowed." Nothing to worry about (even though some poor critter got owned with that! BTW, if you follow that link, check out HTTP response code 201 - if you see it in your logs, run! :-))

Overall, this tip teaches to look for unusual request methods (POSTs to strange pages, all PUT, DELETE, OPTONS requests, etc) and then check the response codes to assess the impact. If your web server happily executed such strange request (code 200), that you'd need to dig further. And, you "lucky" :-) and you see the response code 201 "Run for the Hills" (in reality, it stands for "New File Created"), then you can go straight into incident response mode.

Another lesson to learn is that if you see too many POSTs or too many "GET then POST" sequences from the same IP in rapid succession, investigate it since no legitimate access should produce such a pattern...

As further reading, I heartily recommend this paper: "Detecting Attacks on Web Applications from Log Files"

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Fun Preso on Proxy Logs

I did a few insightful webcasts for LogLogic lately, here is one of them (webcast with voice, slides only), on analyzing and managing web proxy logs. It goes well with my logging tip #12, also on proxy logs.

On Semantic Web or "Web 3.0" (Yuck!) Threats

I want to be a hype-master for a day :-) So, why else talk about "web 3.0" threats?

In any case, I had this fun chat with a journalist about threats to semantic web (which some people started calling 'web 3.0'). WTF is semantic web? Wikipedia fans go here and here, others go read Sir Tim Berners-Lee. The way I understand it is: it is the web that is both human- and machine-understandable, which creates (or allows one to create) a "mash-up" of anything with anything else (well, almost) as well as allows funky automated ways of querying the web.

So, go read the piece, keeping in mind that journalists have a tendency of hearing what they are writing about, not what is being said :-)

OWASP Top10 2007

It's been a few days, but OWASP Top10 2007 is out.

I am still thinking about the logging implications of these. For now, it will suffice to say that web logs do have the info useful for (at least) investigating the incidents which involve exploitation of some Top10 flaws.

On "Know your Enemy: Web Application Threats"

A fun new paper from the Honeynet Project on honeynets vs. web hacking.

On Fruit, Low Hanging and Those Hanging Elsewhere

Here is an insightful post from Jeremiah Grossman blog. As he says, often people recommended fixing the simple glaring vulnerabilities - low-hanging fruit - after a vulnerability assessment.

And then he makes this bold claim: 'eliminating the low-hanging fruit doesn't really do much for website security.' He then explains that this is because the role of 0days is much higher in web hacking compared to platform hacking and removing simple problems just means that complicated ones are sure to be exploited ...

It does seem to make sense! So, in this case "better than nothing" strategy gives you just about the same stuff "nothing" strategy aka "close your eyes and go."

Those doing risk assessments should definitely pay attention to this!

Alien vs Predator aka XSS vs Overflow :-)

A lot of folks are talking about this one (for a more graphical representation and a trend see here), and some choose to strongly object.

The main issue at hand is that XSS vulns (or cross-site scripting vulnerabilities) overtook buffer overflows as the most common type of reported (important to note!) vulnerability: "XSS has become the number 1 vulnerability of all time [...] in CVE" and further "Buffer overflows were number 1 year after year, but that changed in 2005 with the rise of vulnerabilities that are found in webapplications, including XSS and SQL injection."

So the objections are centered around reported vs exploited vulnerabilities as well as their relative risk.

I think some correlation is in order. For instance, look at this piece that was published at about the same time as the above research. It covers Top 5 Causes Of Credit Card Data Loss and - surprise, surprise! (not :-)) - SQL injection and other web app vulnerabilities hold a respectable #4 on the list. Now you see that this baby is not about reporting, ease of discovery, triviality and other bla-bla-bla related to web vulnerabilities; this is about losing real cash(well, credit cards, really) and getting their behinds whooped due to PCI ....