| blog | tools | publications | media |

subscribe to site updates: rss feed

contact Wesley McGrew: | email - wesley@mcgrewsecurity.com | gpg key | aim - wesleymcgrew | twitter - mcgrewsecurity |

McGrew Security Blog

Archive for the ‘phishing’ Category

Scammer edits Wikipedia entry on Advance fee fraud

Tuesday, June 3rd, 2008

Last night, I received a phishing email wanting my university email account information.  Whenever I’m picking through email headers, or any other kind of network forensics, I find it useful to punch the IP addresses I find into Google.  You can often build a good image of what that particular system or network is used for, by reading abuse reports, exposed log files, logs of Wiki edits, and all sorts of other situations where an IP address might be indexed by a search engine.  

This particular bad-guy IP is a great example of an IP address that has really made its mark on Google, so I’ll link the results here:

* Google search results for “196.3.61.4″

Off the eastern coast of Madagascar, there’s an island called Mauritius.  On this island there’s the city of Ebene.  In this city, there’s this building, the “Cyber Tower”.  According to Whois, on the third floor of this building, there’s a computer being used for all sorts of phishing and fraud.  

It would be “just another scammer”, but this one has a great sense of humor.  Check out this diff on an edit made from that IP address on the Wikipedia entry for Advance fee fraud:

Very nice.

 

“Import email addresses” Considered Harmful

Sunday, March 30th, 2008

I’ve posted about this before, regarding Twitter’s signup process, although Facebook’s signup process is probably the most well-known example. Now, I see it on Slideshare. For future reference, when you see this:

 

SlideShare Fail

Please do this:

SlideShare 2

I’m sure most of my readers can imagine what a bad idea it is to hand their email password over to a third party. What’s more dangerous is that this functionality might become more common. If every social-networking-site-of-the-week integrates something similar into their signup process (and it is attractive for them), then it will become more natural for users to expect it, making them less likely to question it. Overall, it makes phishing a lot easier, as now you have a wider choice of sites you can mimic, or you can just make up something completely new.

Also, at least in this specific case, the credentials you’re handing over are not going over SSL. Who knows what precautions are being taken on the other side of this web application, where it’s actually signing into your email and harvesting out the information. You might be carefully using GMail only over SSL for your sessions with it, but there’s no guarantee that SlideShare/Twitter/Facebook will be doing the same. There’s also no real assurance that your credentials haven’t been cached or stored in some way.

You may make yourself out to be a bad Internet citizen if you utilize these features, as well. I know of at least one case where a user signed up, the site automatically picked up all of his contacts, and immediately spammed out a referral email to every one of them, including mailing lists. Your friends and other contacts might not like this very much.

I think it’s a bad idea, and I hope that it doesn’t become more widespread trend than it already is.

Dissecting the crackmails.net Phishing-For-Hire Scheme

Friday, October 26th, 2007

A week ago on the BinRev forums, a link was posted to a site that advertised the ability of the owners to hack any web-based email account. The link was to crackmails.net, however the same site was also available at yourhackers.net and hackpasswords.net (and perhaps more). The cost of this service was $100 per account, and (this is the great part) they would provide proof to you that they had hacked the target account with a screenshot of the inbox. Only then would you have to pay to receive the . You probably know what I was thinking when I read this already ;) .

Here’s what the main page looked like:

I created a new email address on Gmail, with the name of a recent, but inactive, troll on the forums (so there’d be a few things in Google if they decided to do their research). Then, I filled out their order form with the information in the screenshot below, asking them to attack my own Gmail account, wesleymcgrew@gmail.com . I had to give them something that didn’t look as much like a dummy account. Besides, it’s funnier this way. I had a lot of fun filling out the form asking why they should hack my Gmail account ;) :

A short while later, I received an automated mail confirming my order (very professional!) in my dummy account’s inbox:

A full day later, I received the following phishing mail in my own Gmail account:

A plaintext copy of this email with full headers is available here for those who love to dig :). I suppose they got around Gmail’s filters by being such a small operation. Does anyone really trust 123greetings-type emails anymore? I guess they must. Notice the domain name 123greetingsline.com, and the just-for-me unique URL. I tried modifying the URL, however it seems like they just generate the files as-needed when they receive an order.

Clicking on the link takes you to the phishing site itself:

Here’s the source for the login form:

For all the domain names they have, and all the web hosts they’ve been using, they had to resort to using a form mail script and leave the email addresses they use for harvesting out in the open. Hilarious.

If you’re a regular reader of this blog, you already know what I like to do with phishing sites (read up here if you’re not familiar with the technique I use to set up web bugs for catching phishers unaware). This one is no exception, so I set up a unique image and page on my site here to use with a web bug. Then I fill out the form fields with the html needed to try and render the image and link to the unique URL:

Once that was submitted, it actually went through the trouble of redirecting me to the real 123greetings for a nice card:

I set up tail and grep to look for a hit to either of the unique URLs I set up, and a day later I got the hit:

81.129.180.36 - - [23/Oct/2007:12:23:19 -0400]
"GET /XXXXXXXXXXXXXXX>HAY</a&gt HTTP/1.1" 404 245
"http://desigubshup.com:2095/horde/imp/message.php?index=245"
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506;
InfoPath.2)"

So, here you have the IP address (resolves to one of btcentralplus.com’s customers), which at a glance didn’t appear to be running any sort of open proxy, a referral URL revealing where and how they’re checking their mail (there might be somewhere around 244 other victims, judging from the mail ID), and a nice long user agent string. Judging by the mangled end of the request, my web bugs didn’t render very well within IMP, however the phisher was dumb enough to click on the link anyway. This is the reason I try to put HTML links in along with normal image-based web bugs, and you’d be amazed at how often this happens.

I sent a couple of emails to them inquiring about the status of my order. Unfortunately, I haven’t heard back from them. As of a day or two ago, the sites they were advertising their services on look like this:

I’m sure they’re not very happy about that. Maybe they’ll find this post and leave us a comment bringing us up to speed on their situation ;) .

Flash Redirects on Ebay

Monday, September 10th, 2007

Last night, a friend pointed out an auction on Ebay Motors that would automatically redirect you to a phishing site. It turns out, the auction had a flash movie embedded that performed the redirect. Here’s the relevant bit of the auction’s code:

I haven’t bothered obfuscating the IP address, so don’t go poking around unless you feel like you know what you’re doing :) . As a matter of fact, for the sake of folks using GooSweep to investigate incidents involving this guy, here’s something for the googlebots to pick up: The IP address 89.34.212.194 is hosting a handful of Ebay Motors phishing sites and flash redirects to those sites..

The host is in Romania, and has been around at least long enough to get its phishing sites indexed by Google. Since there seems to be such a small chance of getting caught and punished for this sort of thing over there, many Romanian attackers are pretty open and carefree about their operations. I wouldn’t be surprised to find out that this box is some old PIII under the phisher’s desk.

Moving on, the flash file itself is pretty interesting. It’s only 172 bytes, and as you can see from the screenshot above, it’s being hosted in a few different places. It may be an attempt to make sure it fails over if the hosting goes down, but I suspect it may be an attempt to throw careless investigators off track. Only the center, highlighted link to 89.34.212.194 ever worked since the time this was spotted. I grabbed the swf, and since it’s so small, my first instinct was to just take a look at it directly:

I don’t know a lot about flash and I didn’t have any flash specific tools on my system, but this is pretty straightforward :) . To make it a bit clearer, I installed flasm (a Flash assembler and dissassembler) out of the Ubuntu repositories and ran it to get the following output:

Again, I don’t know much about Flash, but it’s obviously not rocket science. The attacker defines a function that getURL’s the target, and sets up a call to it in the first frame of the “movie”. It’s pretty trivial to modify this to redirect anywhere, just change the url and use flasm to recompile. I tried this out, so here’s an swf file that’ll redirect you to my blog ;) :

Sample Flash Redirect (.swf)

This is a bad situation for sites like Ebay, with users that demand the ability to have Flash content (such as image galleries, animations, etc.). It’s easy for them to patch up ways to redirect and XSS in the auction’s code itself, but it’s much more difficult to regulate what goes on in Flash objects brought in from other servers. It’s also difficult for Adobe to fix this up in Flash, since I would think that many legitimate sites use the getURL functionality to hop around. I imagine a solution would require sites to have policies on what functionality is allowed and/or disallowed, that the Flash player would have to parse and honor those policies.

Yet Again, Phishers Have Bad OpSec

Sunday, May 6th, 2007

The next time you’re plotting a cunning scheme, be very careful when you’re doing your homework. You might wind up tipping your hand prematurely…


20070505.log:24.117.239.142 - - [05/May/2007:17:51:41 -0400] “GET /blog/?cat=15 HTTP/1.1″ 200 5450 “http://www.google.com/search?hl=en&q=How+to+make+a+phishing+site+for+runescape” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)”

Apparently, I’m the first hit on google for runescape phishing site creation, thanks to the article where I talked about tracking phishers through web bugs. It’s already a bad sign for your skills when you have to Google this sort of thing, but it’s even worse when you wind up at a page like this. Maybe he should have just viewed from Google’s cache.

Note that I haven’t obscured the IP address, so when this kid follows through and winds up in a lot more logs, whoever does the investigation might find this ;) . Just to make sure it’s indexed well: 24.117.239.142 which is 24-117-239-142.cpe.cableone.net. Time stamps and user agents and such are available in the log entry above. Feel free to contact me if you need any help ;) .

Exploiting Phishers’ Harvesting With Web Bugs

Monday, April 30th, 2007

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:

  • IP Address - (Where is it? Is it a proxy? More on this in a bit, read on!)
  • Date - (Response time)
  • User Agent - IE 6 on a Windows XP machine. Apparently they either have a MegaUpload account or have added “MEGAUPLOAD 1.0″ to their user agent string in order to make MegaUpload think they have an account. Either way this unique bit makes it more likely that I’d be able to pick this host out of the logs if it were to come back to this site as another IP address.

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.

Phishers use old stuff too sometimes…

Wednesday, April 11th, 2007

Well hello there Andrew.

I’ve been away from computers for an extended weekend, so I’m pulling this from some stuff I was looking at late last week. It’s amazing how many of these old mailto scripts are still hanging around. Makes you want to poke around and see if phf is sitting there too.

Phishers are bad coders too

Friday, March 30th, 2007

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.