Archive

Archive for the ‘Exploit’ Category

Good night Milw0rm

Final Update: Crisis averted, Milw0rm is still up and functioning.

Looks like Milw0rm is calling it a night. Haven’ t been able to get any official word as the site is unavailable. As the site is now unavailable it’s hard to tell what happened, but an ISC diary has this message from the site:

Well, this is my goodbye header for milw0rm. I wish I had the time I did in the past to post exploits, I just don’t :(. For the past 3 months I have actually done a pretty crappy job of getting peoples work out fast enough to be proud of, 0 to 72 hours (taking off weekends) isn’t fair to the authors on this site. I appreciate and thank everyone for their support in the past.
Be safe, /str0ke

Always a shame when a big player in the infosec community closes it’s doors. My thanks to all those how contributed and ran the site when it was a going concern; and if anyone has a recent mirror, I’d appreciate a copy, mines a little dated 😥

Andrew Waite

Update:
Looks like the fat lady may not be singing for Milw0rm just yet, Str0ke post this on Twitter:

I have talked with a few friends and I’ll be handing the site over so a group of people can add exploits / other things to the site. Hopefully it will be a new good start

Plus Dale Pearson of Security Active pointed me in the direction of splo.it, which is currently posting nothing but a farewell to Milw0rm. Given the (rather cool) URL it may become Milw0rm’s spiritual successor.

Update 2:
This keeps on going, Milworm came back and then died under the load of people trying to grab an upto date archive (ISC Diary). Until/if Milw0rm comes back for good you can get a copy of the July archive via Security Database Tools Watch

Advertisements
Categories: Exploit, InfoSec, Reading, Tool-Kit

Denial of Service with Slowloris

2009/06/18 1 comment

Earlier this week the ha.ckers.org blog posted the release of the Slowloris HTTP DoS tool primarily coded by Rsnake, discribed as The low bandwidth, yet greedy and poisonous HTTP client!

The attack vector essentially works by initialising an HTTP request but never completes the request, causing the handling thread to wait for the end of the request. Slowloris uses multiple threads to rapidly exhaust the web servers available network resources. The attack is effective against several web server platforms, but most significant in terms of market share and install base is Apache 1.X and 2.X services.

The HTTP request currently generated by Slowloris is below, however before trying to use the info to create IDS signatures the packet contents could easily be modified to avoid overly specific signatures (and overally general signatures could generate high volume of false-positives)

GET / HTTP/1.1
Host: 192.168.80.129
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)
Content-Length: 42

Highlighting the potential damage this technique could course, the Internet Storm Center has already posted two diaries discussing the attack since it’s release, the first introduces the tool and has some rudimentary low-level analysis of the attack vector. The second discusses potential mitigation techniques, unfortunately these are currently far from bulletproof at present.

Since it’s release I’ve tested the Slowloris script and, unfortunately, it’s been wholly effective everytime. Whilst the suggested mitigations can improve a web server’s resilience to the attack, as the point of the web-server is to provide services to the outside world it is near impossible to prevent a maliciuos attack of this nature without similarly impacting legitimate service provision. Unfortunately the maliciuos user has the up-hand in this battle, as the level of resources required to deny service is miniscule compared to the potential damage and resources required to avoid the threat.

Even against a server modified with some of the proposed mitigations, the attacker still only required a sustained traffic flow of appoximately 45Kbps, easily obtainable from even a single ADSL connection. This also means that the attack may be missed by some traditional techniques such as monitoring for unusual traffic levels. Especially as other servers on the server will be responsive, basically if you have issues with your web services I’d recommend checking current connections to the Apache service, for example:

#netstat -antp | grep :80

Best response I’ve found so far is re-active, basically get hit with the attack, find source IP and block at firewall (perimeter or host based), not ideal but, at least currently I haven’t seen this attack in the wild to justify modifying functional production servers to only mitigate against a potential attack when those modifications could deny legitimate services itself.

Life could be about to get interesting…

Andrew Waite

P.S. Twitter plug: whilst this attack vector could be significant, it was publically available 48hours before I noticed any reference in even information security focused mainstream media. However, I had a test environment demoing the script within 60 minutes of RSnake (@rsnake) publicising the link on Twitter.

If you’re not already following the industry in real-time give it a go; @Jhaddix has a short guide to using Twitter to follow the security industry at EH-Net.

VMware ESXi updates

2009/04/14 Comments off

A couple of SANs ISC diaries (“Recent VMware updates available” and “VMware exploits – just how bad is it?“) should be a concern for anyone running a VMware lab (or VMware production environment). The ISC diaries explain the situation better than I could, but to cut a long story short the exploits allow a malicious user/payload to escape the guest system and gain direct access to the host.

Looks like I know what I’ll be doing after work tonight. I’ll try to document the update process as I go, watch this space…

Andrew Waite

Categories: Exploit, Lab, VMware

Honeypotting with Nepenthes

If you’ve got an interest in information security, then there is a good chance that you’ve got a good handle on malware in all it’s (in)glorious forms. The books, articles and war stories are nice, interesting and can result in some improved knowledge but to get a real feel for malware nothing beats live samples. Best way to get live samples? Get infected! To manage this without bringing your network and organisation to it’s knees best practice is a honeypot, in one (or more) of it’s various forms.

For exactly this purpose I’ve been running the Nepenthes application for around 10 months. Nepenthes is a low interaction honeypot which emulates several known vulnerabilities across multiple services in an attempt to capture live malware samples as it is ‘exploited’. The Nepenthes services advertise known vulnerabilities, emulate service interaction to the point of exploit and final store the shellcode/binary provided by the malicious system.

If my honeypot system is any indication, these systems will and do get pounded heavily from prospective intruders, over the lifetime of my honeypot systm I have collected in excess of 850 unique malware samples. In fact when the system was first installed it captured it’s first malicious binary within 30 minutes of gaining a live network connection (in this case an IRC bot).

Nepenthes has the ability to automate a fair chunk of the analysis process by automatically submitting any collected binaries to one of several sandboxes (for example the Norman Sandbox). This can provide analysts with an immediate indication as to the type of malware being dealt with, and perhaps most significantly prevent analysts from utilising resources analysing essentially the same binary/malware. One word of caution however is that the submit process does not always work 100% (this hasn’t been investigated in too much detail, could be Nepenthes, could be the sandboxes not accepting/reviewing the file, could be the winds of fate. As with many things, your mileage may vary.)

As an example of the interactions and logging processed by Nepenthes, below is a log snippet of a malware sample that has just (literally) ‘exploited’ my honeypot. (N.B. IPs edited to protect the guilty):

[12042009 16:36:51 warn module] Unknown NETDDE exploit 76 bytes State 1
[12042009 16:36:51 warn module] Unknown SMBName exploit 0 bytes State 1
[12042009 16:36:51 info handler dia] Unknown DCOM request, dropping
[12042009 16:36:57 info sc handler] i = 1 map_items 2 , map = port
[12042009 16:36:57 info sc handler] bindfiletransfer::amberg -> 9988
[12042009 16:36:57 info sc handler] bindfiletransfer::amberg -> w.x.y.z:9988
[12042009 16:36:57 info down mgr] Handler creceive download handler will download creceive://w.x.y.z:9988/0
[12042009 16:37:12 info mgr submit] File 9604e9c99768c5cd2deb108935356196 has type MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit

VirusTotal analysis of this file (MD5 hash: 9604e9c99768c5cd2deb108935356196) indicates it is a member of the Rbot family of malware. When working with and investigating the malware collected by Nepenthes I have found the VirusTotal Hash Search feature to be particularly useful as it allows analysts the ability to search VirusTotal’s extensive database to gain analysis of the file in question purely from the binary’s hash value. This means that you don’t need to transfer the binary itself between systems to upload to the VirusTotal for actual analysis, removing the potential for an unintended double-click causing havok on a network. And if VirusTotal hasn’t seen the file in question you may have something new and exciting to analyse yourself (or an old polymorphic binary….)

The downside of using a low interaction honeypot like Nepenthes is that you are not going to be collecting on the bleeding edge. As the process suggests, as Nepenthes emulates known vulnerabilities, the vulnerabilities in question need to be known and coded into Nepenthes before it will collect any malware exploit the vulnerability. For instance, dispite all the recent hype and media attention this honeypot system as not captured any sample of Conficker/DownAdUp. However, as most new malware will still utilise old vulnerabilities to increase potential targets this isn’t a major limiration (Conficker was somewhat unique in that it originally limited itself to the ms08-067 vulnerability, before expanding it’s repertoire with subsequent variants.)

Honeypots (of any variety) also provide a good return on investment even in environments where the analysis of malware isn’t a primary (or even secondary) concern. As the honeypot server has no legitimate services then the only traffic targetted at the honeypot should be malicious. Placed externally, this can provide an early warning system for attacks that eventually target legitimate systems and can give system administrations a better indication of the types and frequency of attacks that will be directed at live services. Placed internally they can help identify any internal infections, as compromised systems sweep the internal networks for other vulnerable hosts and trigger the honeypot. These logs can also help identify the root cause of any infectiona and potentially the initial infection vector.

Ultimately honeyput systems of all varieties have a myriad of beneficial uses. There is an enormous wealth of high quality information available from the various honey pot organisations, for example Shadowserver, the Honeynet Project and Carnivore.IT (home of Nepenthes).

–Andrew Waite

‘If you know your enemy and know yourself, you need not fear the result of a hundred battles’ – Sun Tzu

First Lab Victim

2009/02/17 Comments off

I’ve spent the last couple of hours installing my next victim machine for lab, thought I’d share the process if for nothing else it’ll be a useful reminder next time I delete the wrong file and need to re-do tonight’s work.

Target in this case is a Windows XP install, patched to service pack 2. I’m intending to use this VM for dual purposes, for exploit development (both MS native and third party apps) and for malware analysis. As a result I’m going to make extensive use of VMWare’s snapshotting capabilities, allowing me to have multiple states of essentially the same machine depending on what I’m working on at any point in time.

For resource allocation the VM has a 4GB HDD and 512MB of RAM, the RAM may get expanded depending on performance if I’m working on the VM (during malware analysis) rather than just exploiting it.

There is a NIC configured (not connected at power on) to the WAN network to allow access to the web for tool downloads etc. Permenant NIC has access to a ‘malicious’ ESXi vLAN which has not outside access. Once the OS was installed it was connected to the outside world to allow the OS to allow it to phone home and authenticate. At this point the VM was snapshotted to provide a ‘clean’ base incase I need to start from scratch without having to re-install.

Following this I changed the desktop wall paper, so I can tell if I’m in a VM or my real machine, hopefully should help prevent ‘accidents’. Basic tools were installed at this point, before I final generic snapshot:

I’m fully expecting this list of tools to expand as I gain experience, but for now this should provide a workable environment. Just need to go and exploit something now…

Andrew Waite

Categories: Exploit, InfoSec, Lab, Malware