[SecurityRatty] tag: txt

Myspace Cracker Steals Firefox Passwords

Tue, 26 Aug 2008 14:49:03 +0000

A "Myspace Cracking tool" has recently come to light, though if you're considering attempting to crack some Myspace accounts with this:

....then you might want to think again, on account of it not being quite what it seems. This "cracking tool" is only after one persons details: yours. Run it, and you'll see the following (somewhat bizarre) message, which should be your first clue that all is not quite right here:

At this point, your CD tray may well pop open - perhaps in tribute to the Trojans of old that did pretty much the same thing. At any rate, you're certainly not cracking any Myspace accounts, and after a faint grinding from your PC you're left to sit and stare at your desktop, wondering what went wrong. Here's a clue - have a poke around inside the EXE, and some lines of code will likely start to give the game away:

..."Firefox password grabber"? Oh dear.

The observant end-user will notice a .txt file appears on their C Drive, and itcontains all the stored passwords saved via Firefox on their computer:

Click to Enlarge

As you can see, the bad guys here seem to be exploiting a well known password recovery tool for nefarious purposes - in this case, Firepassword. You're probably wondering what happens with the stored login details at this point - well, do some more digging in the code and you'll see this:

Click to Enlarge

The stolen Firefox passwords are sent to an FTP drop set up by the hacker, and every login you had stored in Firefox at that point is immediately at risk. Of course, if you're foolish enough to play around with hacking tools then there's a good chance you're going to get burned sooner or later...

We detect this as FoxPass.

The Bot Hunter: An Event Processing Challenge

Fri, 15 Aug 2008 05:35:00 +0000

Recently we penned The Attack of the Spiders from the Clouds where we mentioned how cloud computing infrastructures can be used to stage malicous or accidential network attacks.

Today I challenge our CEP/ESP/EP vendors (or SIs) to create the following solution to detect and block rogue bots on Apache web sites. I will install and test each submitted solution on The UNIX Forums and post the results here.

Here are some basic requirements:

Your solution must run on Linux and be installable and configurable remotely with SSH or HTTP. There will be no physical access to the server. No exceptions.
Preferrably, the configuration can be done with a Web-Based Interface (WBI) - a browser.
Your solution will listen to continuous updates to the Apache2 access log, exact location configurable in your solution, and identify robots ( bots), also known as spiders, from the log.
Your solution will provide a confidence metric, key indicator (KI), for each bot detected, from 0 to 10, where 10 indicates “absolutely a bot,” 0 is “absolutely not a bot.”
Your solution will update the IP address of each bot and KI you identify in a file/table called, for example, ./bot_scorecard.txt where each line is an IP address of a bot, followed by a semicolon (or other delimiter of your choice) and the confidence factor, for example, 10.0.0.1;10 means that 10.0.0.1 is a bot, 100% sure.
Your solution must compare bots detected to a file/table called, for example, ./bots_allowed.txt and ./bots_denied.txt that are in the format IP address/mask, for example 10.0.0.1/24, or 10.0.0.1/32.
If the KI “confidence factor” of the IP address of your detected bot is higher than the tunable “is a bot” KI, then your solution should update the tables/files and then call iptables and block the bot.
It should send an email to one or more email addresses with a message, for example: “New Bot Detected - Confidence 8″ with IP address, etc. in the message. Another example would be an email, “Bot Blocked” - with details, etc.
You cannot automatically block any traffic that is not a bot. Blocking one “non-bot” results in failure, no exceptions.
The Prize: The winner will get their logo (w/link) on this site in a block called “Bot Hunter Winner” (or something like that.)

These are some basic requirements; I don’t want to restrict your thinking or solution, so be creative! Feel free to ask any questions in the comment section of this thread.

Remember, sometimes you may have to manage the state of IP addresses for days, or hours, before you can accurately deterimine if it is a bot based on behavior alone. So, you will need to work with both long and short time windows. Latency is not important. Detection accurate is importance.

Anyone care to submit a solution for testing?

MadMACs Ver. 1.2: Update to my MAC address and host name changer / randomizer / spoofer

Wed, 06 Aug 2008 20:13:25 +0000

Qwasty let me know that if host name randomization is used with MacMACs, and the host name is over 15 characters (or has certain bad illegal characters) it can cause all sorts of lsass.exe errors on boot up. To fix this, I've updated the code to do some sanity checks on the possible hostnames given to it in dic.txt. Hopefully this fixes the problem. I also compiled it with the newer Autoit3 v3.2.12.1.

The Attack of the Spiders from the Clouds

Thu, 31 Jul 2008 11:09:19 +0000

We have seen a lot of discussions of cloud computing in the news recently, as a technology to permit “users to access technology-enabled serviceswithout knowledge of, expertise with, nor control over the technology infrastructure that supports them.” This sound great doesn’t it?! Users with little to no IT expertise can log into the cloud and launch 8 instances of a server with the equivalence of 16 high performance CPU cores. However, as we all know, all things, including cool technologies have the potential for both good and evil, opportunity or threat; and cloud computing is no different.

It just so happens that I have been experimenting with Amazon Elastic Computing Services (EC2), documented in Computing in the Clouds with AWS over at The CEP Blog. The server over at The UNIX and Linux Forums has been experiencing some very hardware-limited, high load averages recently. We thought we should take a look at moving the forum server up to the clouds.

Then, a fellow system admin over at the forums suggested that maybe some rogue bots were causing high server loads; so I wrote a one-line command to do a bit of real-time spider hunting in the Apache2 logfiles. Surprise! I found there were a number of rogue, hungry spiders that would not follow our robots.txt directive not to crawl the site. One of the bots was from Russia, one was from China, and another one was from Korea. There were spiders from places I never heard of, all consuming precious resources and denying our users!

So, I did what any Linux admin would do. I used iptables to block the networks of these rogue, hungry, spiders (sorry I was not very kind to these cyber creatures). It probally comes to no surprise at this point in the story that four of the spiders were from the Amazon EC2 cloud. Here is a sample of the output from iptables -L:

root@www:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all — ec2-67-202-45-0.compute-1.amazonaws.com/24
DROP all — ec2-75-101-243-0.compute-1.amazonaws.com/24
DROP all — ec2-75-101-197-0.compute-1.amazonaws.com/24
DROP all — ec2-75-101-213-0.compute-1.amazonaws.com/24

Well, imagine a not-so-distant future dystopian world where criminals or terrorists want to launch a massive denial-of-service attack against some critical infrastructure, like the root DNS servers, or an attack against major financial institutions, military or e-commerce sites.

First, the bad guys create an instance of powerful operating system with a malicious network application, they test it, and they place it the cloud (without invoking the instance, paying a very small storage fee, no computing time fee) and they wait. Then, at the precise moment of their planned attack, they launch 128 instances each with the equivalence of whatever is the mega-platform at the time, and just blast away at their attack target(s). Even more damaging, they do this from many cloud computing infrastructures. (Note: The cost of the attack is minimal because the criminals are only charged a few pennies an hour for each running instance and the attack runs an hour or two.)

My experience with cloud computing, which is still maturing, is that cloud computing has great promise for both good and evil. The very real example of the “spiders from the clouds” is a harmless enough story of folks using a cloud computing infrastructure for web crawling, perhaps hoping to be the next Google billionaires.

One the other hand, cloud computing brings with it an emerging and growing danger for the misuse of the power of cloud computing infrastructures. The misuse could be malicious, or accidental, but never-the-less, the danger is real.

What an interesting world we have created! Would would have ever dreamed 10 years ago that we could be attacked by ……

#include

…. Spiders from the Clouds.

Reprinted by permission from The Attack of the Spiders from the Clouds by Tim Bass, CISSP

Who's Behind the GPcode Ransomware?

Tue, 10 Jun 2008 05:44:53 +0000

So, the ultimate question - who's behind the GPcode ransomware? It's Russian teens with pimples, using E-gold and Liberty Reserve accounts, running three different GPcode campaigns, two of which request either $100 or $200 for the decryptor, and communicating from Chinese IPs. Here are all the details regarding the emails they use, the email responses they sent back, the currency accounts, as well their most recent IPs used in the communication :

Emails used by the GPcode authors where the infected victims are supposed to contact them :
content715@yahoo.com
saveinfo89@yahoo.com
cipher4000@yahoo.com
decrypt482@yahoo.com

Virtual currency accounts used by the malware authors :
Liberty Reserve - account U6890784
E-Gold - account - 5431725
E-Gold - account - 5437838

Sample response email :
"Next, you should send $100 to Liberty Reserve account U6890784 or E-Gold account 5431725 (www.e-gold.com) To buy E-currency you may use exchange service, see or any other. In the transfer description specify your e-mail. After receive your payment, we send decryptor to your e-mail. For check our guarantee you may send us one any encrypted file (with cipher key, specified in any !_READ_ME_!.txt file, being in the directorys with the encrypted files). We decrypt it and send to you originally decrypted file. Best Regards, Daniel Robertson"

Second sample response email this time requesting $200 :
"The price of decryptor is 200 USD. For payment you may use one of following variants: 1. Payment to E-Gold account 5437838 (www.e-gold.com). 2. Payment to Liberty Reserve account U6890784 (www.libertyreserve.com). 3. If you do not make one of this variants, contact us for decision it. For check our guarantee you may send us ONE any encrypted file. We decrypt it and send to you originally decrypted file. For any questions contact us via e-mail. Best regards. Paul Dyke"

So, you've got two people responding back with copy and paste emails, each of them seeking a different amount of money? Weird. The John Dow-ish Daniel Robertson is emailing from 58.38.8.211 (Liaoning Province Network China Network Communications Group Corporation No.156,Fu-Xing-Men-Nei Street, Beijing 100031), and Paul Dyke from 221.201.2.227(Liaoning Province Network China Network Communications Group Corporation No.156,Fu-Xing-Men-Nei Street, Beijing 100031), both Chinese IPs, despite that these campaigners are Russians.

Here are some comments I made regarding cryptoviral extortion two years ago - Future Trends of Malware (on page 11; and page 21), worth going through.

Malware Attack Exploiting Flash Zero Day Vulnerability

Tue, 27 May 2008 13:33:43 +0000

It's been a while since we've last witnessed malware attacks using zero day vulnerabilities, and the latest one exploiting a zero day in Adobe's flash player is definitely worth assessing. The current malware attack has been traced back to Chinese blackhats, who are using a zero day to infect users with password stealers, moreover, one of the domains serving the Adobe zero day has been sharing the same IP with four of the malware domains in the recent waves of massive SQL injection attacks, indicating this incident and the previous ones are connected. According to Symantec :

"Preliminary investigation suggests that the DeepSight honeynet may also have captured this attack. We are looking into this further. Currently two Chinese sites are known to be hosting exploits for this flaw: wuqing17173.cn and woai117.cn. The sites appear to be exploiting the same flaw, but are using different payloads. At the moment these domains do not appear to be resolving, but they may come back in the future. Network administrators are advised to blacklist these domains to prevent clients from inadvertently being redirected to them. Avoid browsing to untrustworthy sites. Also, consider disabling Flash or use some sort of script-blocking mechanism, such as NoScript for Firefox, to explicitly allow SWFs to run only on trusted sites. "

The Internet Storm Center also made an announcement and assessed a malware domain that was using the exploits in this case play0nlnie.com (125.46.104.172), next to Adobe's Product Security Inci dent Response Team (PSIRT) original announcement of the vulnerability. What about the original hosting sites for this exploits? Are they still active and serving it, what are the detection rates of the exploits and the malware served, and are there any other domains that should be blocked, also responding to the same IPs.

Let's assess the campaign using the Adobe Flash Player SWF File Unspecified Remote Code Execution Vulnerability. At count18.wuqing17173.cn/click.aspx.php (58.215.87.11) the end user is receiving a look looks like a 404 error message, however, within the 404 message there's a great deal of information exposing the exploits location and participation domains, which you can see attached in the screenshot above. In between several obfuscations we are finally able to locate the exploits serving host, as there are multiple exploits this particular campaign is taking advatange of, in between the Adobe Flash Player one :

0novel.com /real.js
0novel.com /rl.htm
0novel.com /lz.htm
0novel.com /bf.htm
0novel.com /xl.htm
0novel.com /flash.swf
0novel.com /flash1.swf

Let's get back to the second domain which is not returning a valid 403 error forbidden message, woai117.cn (221.206.20.145) which has also been sharing the same IP with kisswow.com.cn; qiqi111.cn; ririwow.cn; wowgm1.cn, among the domains used in the ongoing SQL injection attacks. Once the binary located at woai117.cn /bak.exe was obtained and sandboxed, it tried to download more malware by accessing woai117.cn /kiss.txt with the following binaries already obtained, analyzed and distributed among AV vendors :

117276.cn /1.exe
117276.cn /2.exe
117276.cn /3.exe
woai117.cn /bing.exe

Detection rates for the exploit, the obfuscations and the malware binaries obtained :

Sample obfuscation
Scanners result : 3/32 (9.38%)
F-Secure - Exploit.JS.Agent.oa
GData - Exploit.JS.Agent.oa
Kaspersky - Exploit.JS.Agent.oa
File size: 35767 bytes
MD5...: 11d2b82a35cd37560673680f25571bac
SHA1..: 687066c90bb44fee574f2763041ee80dfee4d5bf

A sample flash file with the exploit
Scanners result : 2/32 (6.25%)
eSafe - SWF.Exploit
Symantec - Downloader.Swif.C
File size: 846 bytes
MD5...: 1222bf4627894cb88142236481680d03
SHA1..: bbf59d9e6610e6f982a7ce7fc9e9878ffd3bfe70

The malware served
Scanners result : 18/32 (56.25%)
MemScan:Win32.Worm.Otwycal.T; a variant of Win32/AutoRun.NAD
File size: 25229 bytes
MD5...: 6be5a7b11601f8cb06ebba08c063aa09
SHA1..: 95d266e2e04e27a923467f483c23818c38ebe19e

The password stealers
Scanners result : 19/32 (59.38%)
Trojan.PWS.OnLineGames.WOM; Win32/TrojanDropper.Agent.NKK
File size: 42268 bytes
SHA1..: 7dfd51e96269f8d53354dd4c028d0c9481ebf4c8

Scanners result : 13/32 (40.63%)
W32/Heuristic-159!Eldorado; Suspicious:W32/Malware!Gemini
File size: 108172 bytes
MD5...: a0383dd1571af5e2f104e1f7d6df7a67
SHA1..: be5b9b00ce9e378e545fa4f1e67160f20ba82ad2

Consider blocking flash by using Flashblock for instance, until the issue is taken care of :

"Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on a webpage and blocks ALL Flash content from loading. It then leaves placeholders on the webpage that allow you to click to download and then view the Flash content. "

It could have been worse, as "wasting a zero day exploit" affecting such ubiquitous player such as Adobe's flash player for infecting the end users with a rather average password stealer is better, than having had the exploit leaked to others who would have have introduced their latest rootkits and banker malware.

Eicar.pdf

Tue, 20 May 2008 14:02:02 +0000

Didier Stevens has a quick post up about embedding eicar in PDF files.

From his site:

I like to embed the EICAR Anti-Virus test file in usual formats and less usual formats. Today, I’m publishing a PDF document with an embedded EICAR test file (eicar.txt). This PDF document has also an annotation with a JavaScript action linked to it. Clicking the annotation will export the embedded eicar.txt file to a temporary folder and launch the default editor for .txt files.

Read on.

Article Link

Anton Security Tip of the Day #15: Fear and Loathing in Event 560 (and 562 and 567)

Thu, 08 May 2008 09:37:00 +0000

Following the new "tradition" of posting a security 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 #15: Fear and Loathing in Event 567

This tip digs into a seemingly simple, but really VERY esoteric subject: monitoring file access and modification via a Windows event log. Now, some people - who never studied this subject - tend to have a very simplistic view of this: just enable Object Access auditing, then right-click on a file or directory, click Security->Advanced->Auditing and then pick what types of events will be logged and by what accessing entities (i.e. users or computers). OK, so this will produce some logs, that is for sure. But are they useful?

First, why are we doing this? We typically need to know the following when we audit file access in Windows (or any other OS for that matter) for security (monitoring and investigation) or compliance:

Time/date
Computer where it happened
User who touched the file
Application he used to access the file
File name + location (directory, share, etc)
Type of access (read, write, create, delete, etc)
Status (i.e. success or failure)

Can we get this from the above logs? No.

What? No!?! Really?

Yes, really. We can get some of the above, some of the time, not all of the above, all of the time. Here is an example, we are looking at event ID 560 (picture) and then at an extract from its description field.

Event:

Description (selected field):

Object Server: Security

Object Type: File

Object Name: C:\0\TestBed\simple_text_file.txt

Image File Name: C:\WINDOWS\system32\notepad.exe

Primary User Name: Anton

Primary Domain: XXXXXX

Accesses: READ_CONTROL

SYNCHRONIZE

ReadData (or ListDirectory)

WriteData (or AddFile)

AppendData (or AddSubdirectory or CreatePipeInstance)

ReadEA

WriteEA

ReadAttributes

WriteAttributes

WTH is that? Well, we know that the user 'Anton' has successfully read? wrote? changed attributes? did something? with a file named "C:\0\TestBed\simple_text_file.txt" using a program named "C:\WINDOWS\system32\notepad.exe." That's the best we can get, in this case! We may try to look at event IDs 562 and 567, but this missing information (i.e. the exact action performed) will not be added.

BTW, there will be a few more dozen (sometime hundreds!) of the 560s, 562s and 567s produced - all from just opening the text file in a notepad. The above event is notable for having BOTH "notepad" and "simple_text_file.txt" in the same event; others will have either of the two.

Anything else gets in the way? Yes, lots! MS Office will write to all files, even just opened for reading (with no user modifications to the content whatsoever), which will screw up your log monitoring efforts. If the file is on a share, more information will be missing (e.g. username might be).

So, how to use Windows event logs for file access tracking?

Enable logging (as described above)
Pick events 560 (most useful) and 562, 567 (useful too)
Look for fun filenames that might be touched by the users (have a list of files and users handy)
Figure out what programs were used to access them (this is called "Image File Name" in "WinLogSpeak")
Ponder the 'Accesses' section of each event until your brain turns blue :-) or until you decide whether such access is authorized or not...

Overall, this is still very useful for file access monitoring, but the process is paaaaaainful.

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

Technorati tags: security, tips, logging, log management

The Phorm Webwise System

Fri, 04 Apr 2008 12:53:06 +0000

Last week I spent several hours at Phorm learning how their advertising system works — this is the system that is to be deployed by the UK’s largest ISPs to pick apart your web browsing activities to try and determine what interests you.

The idea is that advertisers can be more picky in who they serve adverts to… you’ll get travel ads if you’ve been looking to go to Pamplona for the running of the bulls, car adverts if you’ve been checking out the prices of Fords (the intent is that Phorm’s method of distilling down the ten most common words on the page will allow them to distinguish between a Fiesta and a Fiesta!)

I’ve now written up the extensive technical details that they provided (10 pages worth) which you can now download from my website.

Much of the information was already known, albeit perhaps not all minutiae. However, there were a number of new things that were disclosed.

Phorm explained the process by which an initial web request is redirected three times (using HTTP 307 responses) within their system so that they can inspect cookies to determine if the user has opted out of their system, so that they can set a unique identifier for the user (or collect it if it already exists), and finally to add a cookie that they forge to appear to come from someone else’s website. A number of very well-informed people on the UKCrypto mailing list have suggested that the last of these actions may be illegal under the Fraud Act 2006 and/or the Computer Misuse Act 1990.

Phorm also explained that they inspect a website’s “robots.txt” file to determine whether the website owner has specified that search engine “spiders” and other automated processing systems should not examine the site. This goes a little way towards obtaining the permission of the website owner for intercepting their traffic — however, in my view, failing to prohibit the GoogleBot from indexing your page is rather different from permitting your page contents to be snooped upon, so that Phorm can turn a profit from profiling your visitors.

Overall, I learnt nothing about the Phorm system that caused me to change my view that the system performs illegal interception as defined by s1 of the Regulation of Investigatory Powers Act 2000.

Phorm argue, with some justification, that their system does not permit them to identify individuals and that they meet and exceed all necessary Data Protection regulations — producing a system that is superior to other advertising platforms that profile Internet users.

Mayhap, but this is to mix up data protection and privacy.

The latter to me includes the important notion that other people, even people I’ll never meet and who will never meet me, don’t get to know what I do, they don’t get to learn what I’m interested in, and they don’t get to assume that targeting their advertisements will be welcomed.

If I spend my time checking out the details of a surprise visit to Spain, I don’t want the person I’m taking with me to glance at my laptop screen and see that its covered with travel adverts, mix up cause and effect, and think — even just for a moment — that it wasn’t my idea first!

Phorm says that of course I can opt out — and I will — but just because nothing bad happens to me doesn’t mean that the deploying the system is acceptable.

Phorm assumes that their system “anonymises” and therefore cannot possibly do anyone any harm; they assume that their processing is generic and so it cannot be interception; they assume that their business processes gives them the right to impersonate trusted websites and add tracking cookies under an assumed name; and they assume that if only people understood all the technical details they’d be happy.

Well now’s your chance to see all these technical details for yourself — I have, and I’m still not happy at all.

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

Wed, 12 Mar 2008 10:35:00 +0000

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, 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.

Technorati tags: logging, log management, tips, security