The paper that I presented at the IFIP WG 11.9 digital forensics conference, “Using Search Engines to Acquire Network Forensics Evidence” (using my tool GooSweep) has been published as a chapter of the new hardcover “Advances in Digital Forensics III” from IFIP and Springer. I just received my copy today, and I’m quite proud:
More information is available over at Amazon
LonerVamp of terminal23 has written a nice blog post about anonymity on Internet Relay Chat (IRC):
staying anonymous – part 4 irc
I left some additional comments to it that should be approved any moment now 
. Anonymity is harder than configuring your client to use a proxy, and LonerVamp does a good job of conveying that. It’s a matter of changing your behavior, and becoming tuned to recognize identifying characteristics of what you’re doing, and modifying them. You should always be looking for ways that you might blow your own cover and prevent those situations from happening before someone else comes around to blow it for you. IRC’s a great protocol to think about anonymity in, since there’s such a host of technical and social problems that might make things difficult.
Maybe I should start my own multi-part series on “Blowing Up People’s Anonymity” .
Alexander Sandström Krantz has self-published a report, entitled “Practical WLAN Security”, that he put together along with David Johansson for a class at Linköpings University in Sweden. I just caught his post on SecurityFocus’s “basics” list, and have glanced over the text, and it looks to be a very well written introduction to 802.11 network security issues. This is definitely something you should pick up and read if you’re getting a start on this subject
http://wireless.sandstromkrantz.se/
Update: Mirror at http://www.cyd.liu.se/~alesa195/
Lately I’ve been reading Eldad Eilam’s “Reversing: Secrets of Reverse Engineering”, working through all of the exercises and such. I need to build up my skills at really low level workings of Windows, static analysis of disassembled code, and debugging a live process more effectively. This is the perfect book for that, so I’ve been really enjoying it.
When I received some malware, attached to a “Message could not be delivered” email, I figured I’d play with it bit, as I often enjoy doing. Now, this is the sort of thing VMWare Server is excellent for. If you ‘re running Ubuntu, check here for a nice writeup on getting it going on 6.10. For Feisty, check my comments 
. I can create a checkpoint before I load the malware onto the system, and then rewind it back to that clean state whenever needed.
I already had an Windows XP VM that I was using OllyDbg in, working through Eilam’s examples, so I figured it’d be fun to load up some malware and see what I could do. Unfortunately, I’m not far enough into the book yet to beat this malware’s executable packing and anti-debugging features . Not to be discouraged, I dropped back to my one of my usual techniques for analyzing malware: seeing how it interacts with the network.
For this, I could run Wireshark in the host OS (Linux) without fear of the malware affecting it. Here’s some notes:
As you can see, this executable tries hard to make itself look like an HTML file (that’s a “.com” at the end of all those spaces). A proper icon would have helped though.
I was very happy that, when I ran the malware, the Windows Firewall popped up to ask me if I wanted to let it access the network. The malware was smart enough to call itself “services”, which is innocuous enough for a lot of people. For the purposes of testing, I went ahead and allowed it.
After a while of sniffing traffic, I stopped the Wireshark capture, and began restoring the VM back to a clean slate. The traffic mostly consisted of email (sending out copies of itself, boring and unsuccessful), and web traffic (much more interesting). So, if you want to take a look at the sort of web requests are being made in a packet dump, here’s a nice display filter…
This filter resulted in a large number of searches on lots of search engines, presumably looking for more email addresses to spread to on sites that it found in my browser history:
I’m impressed by the wide variety of search engines and terms that I’ve seen it use. I do, however, question the practicality of mining debian.org for people vulnerable to Windows malware
So, for this exercise, I intentionally didn’t search out any information about the virus beforehand, but this is always a good idea. Google the md5 hash of the malware you get your hands on, run strings over it and search for any unique strings, and anything else you can think of. Anytime you can find someone who’s already done analysis for you, you have saved some time. Just be sure to verify their results, because they may not know what they’re doing, or maybe you have a new variant.
For the sake of completeness, here’s what VirusTotal.com had to say about this malware:
Antivirus Version Update Result AhnLab-V3 2007.5.16.1 05.16.2007 Win32/MyDoom.worm.40960.B AntiVir 7.4.0.23 05.16.2007 Worm/Mydoom.BB.1 Authentium 4.93.8 05.16.2007 W32/Mydoom.BF@mm Avast 4.7.997.0 05.16.2007 Win32:Mydoom-L2 AVG 7.5.0.467 05.16.2007 I-Worm/Mydoom BitDefender 7.2 05.17.2007 Win32.Mydoom.AQ@mm CAT-QuickHeal 9.00 05.16.2007 I-Worm.Mydoom.m ClamAV devel-20070416 05.16.2007 Worm.Mydoom.M-unp DrWeb 4.33 05.16.2007 Win32.HLLM.MyDoom.54464 eSafe 7.0.15.0 05.16.2007 Win32.Mydoom.bf eTrust-Vet 30.7.3638 05.17.2007 Win32/Mydoom.BA Ewido 4.0 05.16.2007 Worm.Mydoom.m FileAdvisor 1 05.17.2007 no virus found Fortinet 2.85.0.0 05.17.2007 W32/MyDoom.BE@mm F-Prot 4.3.2.48 05.16.2007 W32/Mydoom.BC@mm F-Secure 6.70.13030.0 05.17.2007 Email-Worm.Win32.Mydoom.am Ikarus T3.1.1.7 05.16.2007 Email-Worm.Win32.Mydoom.m Kaspersky 4.0.2.24 05.17.2007 Email-Worm.Win32.Mydoom.am McAfee 5032 05.16.2007 W32/Mydoom.bf@MM Microsoft 1.2503 05.17.2007 Worm:Win32/Mydoom.BF@mm NOD32v2 2272 05.17.2007 Win32/Mydoom.AX Norman 5.80.02 05.16.2007 W32/MyDoom.AU@mm Panda 9.0.0.4 05.16.2007 W32/Mydoom.AT.worm Prevx1 V2 05.17.2007 no virus found Sophos 4.17.0 05.16.2007 W32/MyDoom-BE Sunbelt 2.2.907.0 05.17.2007 VIPRE.Suspicious Symantec 10 05.17.2007 W32.Mydoom.BB@mm TheHacker 6.1.6.115 05.15.2007 W32/Mydoom.am VBA32 3.12.0 05.16.2007 MalwareScope.Email-Worm.Mydoom.1 VirusBuster 4.3.7:9 05.16.2007 I-Worm.MyDoom.BC Webwasher-Gateway 6.0.1 05.17.2007 Worm.Mydoom.BB.1
| Aditional Information |
| File size: 41312 bytes |
| MD5: 34e99b96a132caac09c5f3c4f4db7636 |
| SHA1: 9c25a1841dc4ac0eb0503f1a8707e9cbab9f6eb2 |
| Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics. |
I’m going to assume that FileAdvisor and Prevx1 just had a bad day or some kind of glitch, because I’m not sure why else they wouldn’t be able to recognize MyDoom. As long as you’re using pretty much anything else, it looks like you’re safe!
…or you could just use VMWare and restore to a clean state after your questionable activities .
Tonight, here in Starkville, MS, I taught my first of what will hopefully be many training classes for SANS. Tonight, 8 very bright students (mostly IT staff for the university), took part in the “Stay Sharp: IP Packet Analysis”. I say they “took part”, rather than “attended”, as each and every single one of them were contributed a lot and turned the class into a very collaborative learning experience. I think everyone walked out with a few new tricks up their sleeves, including myself.
Many thanks to my talented wife, Crystal, for making the refreshments enjoyable this wonderful creation:
Dinner afterwards at the Bulldog Deli with a handful of the students was a great way to wind down too!
I’m really looking forward to teaching more of these classes, and participating in improving and developing course materials. Stay tuned!
If you’re at all involved in computer forensics, I highly recommend that you read this deposition of a RIAA expert witness, in which a defense attorney enjoys some success at attacking the witness’s methods, experience, and claims:
Deposition of RIAA’s Expert Available Online
This really illustrates how well you need to document and understand your processes when you are perfoming an investigation. There are a few genuinely cringe-worthy moments in there, and I put together a few bullet points on things one should pay close attention to before going into a situation like this…
I’ve posted before about how phishers and others that are on the “other” side of computer security ironically do not practice very good coding techniques. To borrow one of Dave Aitel’s ideas from a few weeks ago, hackers often do not practice very good operational security, since it’s not a good fit with their aggressive nature. The same idea applies equally well (if not better) to phishers. Phishing is a numbers-game for those involved, and when the choice in front of the phishers is between secure software and processes, or spending that time pushing out more emails and sites, the phishers will always pick the latter. It’s hard for them to justify the additional time, when that time could be spent making more money.
A while back, I came up with and experimented with a technique for gaining more information about phishers’ operations. The idea is based off of web bugs that are normally used to track users through emails or web site visits. A classic example of a web bug is an HTML email, containing a reference to 1×1 transparent .GIF file located on the senders’ web server. If the filename of that image is unique to that email, and the recipient’s email client renders the HTML and retrieves the image, then the sender can examine their web server logs to see if and when the recipient opened the email. Not only that, but the web server logs will also indicate the IP address, and possibly some information about the email client or web browser being used.
To apply this to phishing, I simply decided to stuff HTML image tags and links and such into phishing web sites’ forms. The idea is, if the data is being logged to or emailed to any type of system that renders the HTML, there is the possibility that the phishers will inadvertently retrieve the web bugs along with their data. At the very least, they may become curious about the URLs showing up in their data and try to see what’s there. On a lark, I created unique images and stuffed web bugs and links into a few different phishing sites the morning that I came up with the idea. I wound up getting hits back for some of them. So it was a promising idea.
I have passed the idea along to a masters degree student here who is currently working on refining it and collecting larger amounts of data for his thesis. Along the way, I co-authored a paper with him on the topic. He’s working on automating it and such now, however I still play with the idea from time to time.
Last night I received a phishing email that targeted Runescape (an MMORPG) players. This outside of the norm of what I usually receive, so I figured it would be fun to try baiting it with some web bugs. I set up a unique-URL image (a small McGrew Security logo, lol), and php redirecting page, and then set about baiting the site. The following images show the forms on this Runescape phishing site:
Maybe they didn’t design that with Firefox in mind. As I said, phishers can be very sloppy . At any rate, to stuff the appropriate image and link tags in, we can’t simply use the stock web browser, as they have the forms set to limit the number of characters input into each field (chances are, their server-side code doesn’t check these bounds). We wouldn’t be able to fit the whole tag and URL into them normally. There are extensions for firefox that allow you to remove such restrictions in a page, but since I’ve already covered the Burp Suite proxy in a previous blog entry, I’ll just use it:
The same technique is applied to the second page’s worth of forms, alternating between putting an image tag that will render automatically (if all goes well) and links (which a curious phisher might decide to click on). You then pass it all along through Burp, and sit back and wait, grepping through your web logs for someone accessing those URLs.
About 3 hours later, I had a hit!
82.135.214.208 - - [30/Apr/2007:02:22:25 -0400] "GET /XXXXXXXXXXXXXX HTTP/1.1" 200 2354 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; MEGAUPLOAD 1.0)"
So, from this alone we get a few bits of information:
Back to the IP address, it reverse DNS’s to “82-135-214-208.ip.zebra.lt”, and is in Lithuania. If you do a google search for the IP address in quotes (a similar technique as what my YaSweep/GooSweep app uses for larger ranges), you’ll see that it has been used for phishing and spamming in the past. Project Honeypot has a very informative page on it. Looking back at the email that I received originally, it turns out it was sent from the same IP address.
Poking at the host a bit indicates that it’s likely a Linux machine, with what appears to be a tcpwrapped proxy. The Windows user agent coming from a Linux machine also indicates that it is a proxy, and it’s apparently not an open one. It’s a machine that is, one way or another, under the control of the phisher and used to anonymize their actions. That’s at least something this attacker did well for themselves to do. Many phishers view their resulting data on their own computers, unproxied, and will give away their actual workstation’s IP address, if their procedure is vulnerable to this kind of attack.
So there you have it! Information gathering on phishers/blackhats. It’s a fun concept. It would be very interesting to extend it to include javascript, and other attacks on the different ways phishing data is processed.
You might recall that a month ago, I gave a lecture on web security to the “Distributed Client-Server Programming” class taught here at Mississippi State University. The goal was to give them a heads-up on what mistakes are commonly made by web developers, so they could try and avoid them while developing their final group projects. Yesterday and today, I have been sitting in on their final presentations, and (playfully) tinkering with their sites as they demonstrate them. They’ve definitely tried hard to work security into their projects, and it’s been interesting to play around and show off how things can go wrong.
They’re definitely learning a lot too, because one of the students actually pointed out the vulnerability I’m going to describe here before I found it . I thought it was a neat opportunity to show off how to attack bad access controls, so I decided to make this post about it as a tutorial on how to use PortSwigger’s excellent Burp Suite to bypass things like this. I’ve even set up a page on my site here that you can try it on .
The original student team’s project had two interfaces, the user’s interface, at $baseURL, and an admin interface at $baseURL/admin . When the user logged in, it would send them to the appropriate interface, based on the “admin” flag the user set in the database. To prevent normal users from going into the admin interface, the following code is used for all admin pages:
This lets the web browser know that it should head back to $baseURL. The problem is, that the php code/page just keeps on going: parsing parameters, sending the interface, and all the things that it would do for a real admin. A well-behaved web browser honors the “location:” in the header, however, and doesn’t render anything below. Unfortunately attackers aren’t well-behaved…
To show off how to beat this, I’ve set up this page for you to play with. Open it up in a new tab, and you’ll see that it uses “location:” to send you straight back to the root page of this site. Here’s the code:
Now, the page does get to the “You’re not supposed to be here, lol” part, it simply doesn’t get a chance to render. To see it, we’ll have to take the “location:” part of the header out. We’ll do this with Burp Suite, so go ahead and get a Java VM on your machine if you haven’t already, download Burp, and get it running.
Burp acts as a web proxy, and allows you to intercept requests and responses, and then modify them before they’re sent along to the server or client. This is very handy stuff for attacking web applications. Once you have it up and running, change your web browser’s proxy settings to use it:
Burp is already set up to intercept client requests, but you’ll need to turn on the functionality for intercepting server responses in the “Options” tab under “proxy”, in the “server responses” section. Check the “intercept if:” box here:
Now, go back to the “intercept” tab, and open this in a new tab again. Your web browser will just sit there (if you’ve got it all set up right), while the request has been intercepted by Burp:
Go ahead and click “forward” here. In this case, there’s not much to see in the request, but a lot of the times when using Burp on web apps, you’ll be changing things before forwarding along. Now, it should intercept the server’s response:
Notice that the whole page got sent (complete with the typo on the closing h tag that I just noticed, lol oh well). Also notice, in the header, the line “Location: http://mcgrewsecurity.com/”. This is what’s making your browser jump to another location, rather than display the page, so just highlight it and cut it out. The response should look like this after your modification:
Now, go ahead and click “forward”, and it’ll send the page along to your browser. There you go :
Note that even though we had to do some trickery to get the page to display, if it actually processed any POST/GET parameters (as admin pages tend to do), it would do so in this case, regardless of whether or not the browser redirected. All the attacker would have to do is supply the correct parameters. Burp makes things like this a breeze .
I’ve never personally seen a system that did access control like this, but when this was pointed out to me, I thought it was interesting and educational enough to share . Definitely something to look out for, and maybe if you haven’t used the Burp Suite before, you’ve got a nice new tool to play around with.
Sometimes you just can’t help yourself but to poke at a phishing site…
So it isn’t that impressive, through a POST’d variable, but it is kinda funny. It brings up the point that attack tools, exploits, schemes, and systems have vulnerabilities just like “legitimate” software. Just because they’re in the field of security (on the wrong side) doesn’t mean they write secure code .
It’s a situation where there’s a return-on-investment for the effort put into the creation of, say, a phishing site. Spending more time making the phishing site more robust doesn’t make any more people fall for it and doesn’t bring in more money. For this reason, that time isn’t invested.
Recent Comments