Forensication

In another interesting collision of Sweet Element‘s world and mine, Jen asked me one morning to take a look at a really weird set of emails she received from someone inquiring about a wedding cake.

The first email that arrived was nothing out of the ordinary as it was a simple referral from weddingwire.com where Jen is an active advertiser:

From: no-reply@weddingwire.com
Date: February 20, 2012 10:37:33 AM EST
To: Sweet Element
Cc: denisehevak2@yahoo.com
Subject: Denise Shevak would like information about your services!

Denise Shevak found your business directly on the vendor catalog and would like to know more about your services. Please respond to this lead within 24 hours. Here is the lead’s contact information:

Name: Denise Shevak
Email: denisehevak2@yahoo.com
Phone: Not provided

Wedding Date: Apr 29, 2012
Location: Not provided

Message:
Please send me an email with information about your services.

Simple enough, right? I checked the headers on this email and it did come in from weddingwire.com’s servers, but unfortunately their server didn’t include the source IP address of the person filling out the form or anything else that could yield any clues.

Jen, followed up with an email asking for lots of additional info as “Denise” failed to include helpful information and her wedding was 2 months away. What came back was curious, to say the least.

From: “Denise Shevak” <denisehevak2@yahoo.com>
Subject: Re: Wedding Cake Inquiry
Date: Wed, February 29, 2012 3:06 am
To: Sweet Element

Thanks for responding to my posting and apology for my late response. Let’s get down to business, I would love you to take care of our wedding cake and I would want it to be 2 tiers cake for about 120 guests. I know you would really want to make the day a memorable one for me and my fiance.Attached is a preferred design of the cake. If you have an idea you could add to make the creativity more perfect.

The venue for the wedding is taking place in the apartment’s compound I’m relocating to in Bogota, New Jersey 07603. The date is 04/29/2012.Time is 11am.I am currently living HACKENSACK,NJ and still very much around but working offshore in United Kingdom. I will resume back to work next Monday. I am sure we can conclude on everything before I leave.

Please, make the cake color to be two, cream and butter color and not white as shown in the picture but I want you to design it with roses. The color of the roses has to be yellow and white. I love creativity, it’s a sign that I’m getting the best of the cake. The flavor can be 2 for each tier. (1) Vanilla and (2) Coconut.Let me know the total cost for the cake and as regard delivery, I could arrange for pick up and you could make delivery as well.

Thanks as I await your response,

Denise.

Aside from the rather odd language, the one thing that really caught my attention was “HACKENSACK, NJ” standing out like a sore thumb in all caps. Why would they choose such a specific city? If you look up Sweet Element’s phone number, the area-code and prefix is for Hackensack, NJ. In reality, it’s just a phone number and the Sweet Element cake studio is actually quite a distance from Hackensack – but the scammers don’t know that. All the scammer is trying to do is establish that they are from the area and even mention the city of Bogota, NJ which is right across the Hackensack River.

So exactly what is going on here? Let’s find out.

The first thing I did was upload the attached cake photo to TinEye to see if it had shown up anywhere else, hoping to find it referenced on a blog somewhere confirming it was a scam. Nothing at the time I first looked, but I’m sure that will change soon enough as more people become aware of this particular variation of the scam and warn others.

Next, I took a look at the email headers. I’ll spare you the full, lengthy email header, but will include the most critical line below which shows the first time the message hit Yahoo’s servers:

Received: from [41.220.69.9] by web121303.mail.ne1.yahoo.com
via HTTP; Wed, 29 Feb 2012 00:06:01 PST

It’s rather fortunate that, Yahoo Mail keeps the source IP address of the web client in the headers of the message and we can see that the mail originated from 41.220.69.9. Looking up this address at ip-lookup.net, we find that it originates just outside of New Jersey in the country of Nigeria. Another quick check at Project Honeypot shows a great deal of malicious activity from this node as well as many others in the same subnet.

Yeah – it’s a scam.

So how does the Nigerian Cake Scam work? A similar scam has been going on for a while now, although the story has changed a little. The scammer contacts the victim wishing to order a cake and pays for the cost of the cake plus delivery using a stolen credit card but insists on having the cake delivered by a specific delivery company that the victim is asked to wire payment to. The shipping company is the scammer. It would not surprise me to find that the United Kingdom was mentioned in the email in order to make sure the victim doesn’t have issues wiring money to a UK shipping company when the payment phase of the scam begins.

Unfortunately, I have heard of people that actually fell victim to these scams, made the cakes and prepared them for delivery only to be cheated out of their time, resources, money and are then stuck with an extra bill because the credit card processors hold vendors financially responsible for the fraudulent charges.

I was sitting in the office one day doing my usual checking that everything was okay when I happened to look at the traffic on the firewall and saw the first half of this graph:

Odd outbound firewall traffic. Red is download. Grey is upload.

We do quite a bit of data processing at work and there’s always one big upload or download happening all day long – but the gradual and ever-increasing outbound traffic was just odd. What’s equally as disturbing is that it was worked it’s way up to 45.27Mbps!

Leaping into action (okay, leaping is a bit of a stretch – I was sitting on and took a moment to sip some coffee and wonder what the hell I was looking at, but an opening like that makes for more excitement a-la CSI: SysAdmins.) I checked the pftop output on the firewall and saw that one system on the network was making all of that outbound traffic – specifically the machine of a developer who started with the company recently. Traffic was heading out to an IP address related to a company I recognised and that we could have been sending data to, but this was still really weird.

Deciding to take the easy route first and gather more information, I casually strolled over to her to ask a few simple questions. After all, there’s no reason to panic yet. She was sitting quietly at her desk with earbuds in her ears and quietly coding on her Ubuntu laptop. I walked up and she popped out an earbud – the riveting sounds of talk radio escaping to the ether.

Me: Hey, quick question for you – Are you uploading any really big data files right now?
Her: Hmm? No, I don’t do any of that.
Me: Oh, well I’m seeing a lot of outbound traffic going from your machine to an Akamai address and I just thought I’d check and see if you were doing anything like that.
Her: Do you think I have a virus?
(I love how users immediately jump to the virus conclusion. I said there was no need to panic yet and I meant it – because panic would just make any situation worse.)
Me: I don’t know if I’d say that yet. I just saw this really weird traffic on the firewall coming from your machine and wanted to see if you were doing anything that might explain it. Anything that might be making a bunch of network traffic? Anything that would push out 40 megabits a second?
(I could already by the puzzled look on her face and the contents of her screen that she was doing nothing of the sort. Just Eclipse, FireFox and a filesytem window open. Not even a P2P client in sight.)
Her: Definitely not. I’m just using Eclipse and listening to Bloomberg. Let me close all this stuff.
(Unfortunately, she was too fast and closed all the windows before I could stop her. My hope to prevent panic and not freak her out cost me the he possibility of looking at things I needed to look at on her machine.)
Me: Actually, I was hoping you could keep on doing exactly what you were going so I could take a closer look. I just wanted to make sure I wasn’t looking at any expected traffic.
Her: Oh, okay. So you want me to reboot?
Me: No. Just do everything you would normally be doing – even listening to the radio.
Her: Okay. Let me know what you find.
Me: You’ll be the second to know.

I wandered back to my office already certain that this was going to be an interesting issue. Based on my experience, developers of nefarious software usually want it to go undetected for as long as possible so I’d only expect to see something like this if the ‘virus’ had a bug or was being used to DDoS – and even if it was a DDoS, I’d expect to see a steady stream of data and not an ever-increasing chunk of outbound data.

I watched pftop on the firewall and hoped the strange outbound traffic would show up again and was happy to see it did. It wasn’t at the crazy-high levels I was seeing before she killed everything, but it was there and it was actively increasing. I started a packet capture on the firewall to do a quick grab of all traffic going between her machine and the destination server.

Opening the file of captured packets in Wireshark, I saw a large number of RTMP packets going back to the server. Right-clicked on one, selected Follow TCP Stream to reconstruct what was going on and was presented with a very interesting and large window of data that read:

POST /idle/2iMmdz02wSLmyUHI/8097 HTTP/1.1
Host: 96.6.41.39:1935
Accept: */*
User-Agent: Shockwave Flash
Connection: Keep-Alive
Cache-Control: no-cache
Content-Type: application/x-fcs
User-Agent: Shockwave Flash
Connection: Keep-Alive
Cache-Control: no-cache
Content-Type: application/x-fcs
User-Agent: Shockwave Flash
Connection: Keep-Alive
Cache-Control: no-cache
Content-Type: application/x-fcs
User-Agent: Shockwave Flash
Connection: Keep-Alive
Cache-Control: no-cache
Content-Type: application/x-fcs
<... repeat the above 4 lines *many* times over ...>
User-Agent: Shockwave Flash
Connection: Keep-Alive
Cache-Control: no-cache
Content-Type: application/x-fcs
Content-Length: 1

What it looked like was happening was the Adobe Shockwave Flash component that was streaming her Bloomberg Radio audio was sending back keep-alive packets to tell the server to keep sending the audio stream. This is actually normal behaviour, except the rate at which it was doing this was increasing as time passed. I assume it would continue this unfortunate pattern of screaming back to the server until it was either interrupted or it completely saturated all upstream bandwidth. Only one way to find out.

I set up a test environment in my lab to isolate the systems and replicate the situation. Same firewall. Simplified network of a single client machine. Basic installation of Ubuntu Linux 11.04. A visit to http://bloomberg.com/radio under Firefox and pressed play on the audio player. The results were pleasantly identical.

Listening to Bloomberg Radio in the lab uploaded over a DVD's worth of data in less that two hours.

Although inbound traffic never exceeded 226kbps and total content downloaded for the test period was 124.2MB, the outbound traffic gradually built up to 9.67Mbps with a total upload of 4.69GB in about 1h49m. The stream self-terminated and ended the test prematurely, but enough data had already been collected to confirm a theory: Bloomberg Radio was killing my upstream bandwidth and I was very glad I wasn’t paying for upstream bandwidth by volume.

Continuing to test on several different operating systems and browser combinations I found that Windows and Mac were completely unaffected by this issue and the problem itself seems limited to the Bloomberg Media Player version 1.0428 running with Adobe Shockwave Flash Player version 10,3,183,5 under Linux. Browser choice did not seem to matter as they all utilise the same libflashplayer.so plugin file from Adobe to execute the audio stream flash object.

Since discovering this odd bug, the problem has continued to show up day after day. I explained to the user what I found and she’s made a conscious effort to pause the audio stream when she gets up from her desk and in return I have been nice and didn’t set any rules to block her audio stream. Know someone at Bloomberg that can get this big fixed? I’d appreciate you forwarding this over to them.

So your ISP was really nice and gave you *free* WiFi-enabled router with password-protected encryption and everything? Change the default password. Change it now – because there is nothing safe or secure about it.

The danger of leaving your wireless access point open has been repeatedly reported in the news and countless blog entires. Fortunately, in the interest of protecting their own networks and making their customers feel a little safer, many service providers have been setting up customers with password-protected WiFi-ready routers with built-in firewalls. Awesome, right? Well, sort-of.

As an example, Verizon FiOS customers are given a standard issue router that takes care of everything they need to get a siple home network running and even includes encrypted WiFi protected by 40-bit WEP!

Security-minded people who just finished reading the above sentence have likely done a face-palm at this concept. WEP is broken and has been broken for quite some time. As if that was not enough, 40-bit encryption is the lowest option available and has become trivial to attack and recover if the attacker is in range of the access point. Decryption attacks are possible at even greater distances if the attacker has enough data being broadcast from the access point.

Could this shoddy security deployed on a massive scale to uninformed, yet trusting users get any worse? Sure. When you have to build millions of devices and deploy them efficiently, you pre-configure them exactly the same, or have some sort of predictable pattern that makes them unique – like password selection. This is exactly what the manufacturers and ISPs affected by the vulnerability have done.

The default password on a Verizon FiOS router is based off of the last 5 hex values of the WAN port MAC address. To use my own decommissioned unit as an example, the WAN MAC address is 00:26:62:C0:6A:BF and the default WiFi key is 2662C06ABF. Granted, the WAN MAC address is generally a difficult thing to discover unless you’re standing in front of the router – which is why some helpful people made a database of all the default passwords and used the ESSID of the wireless signal as the lookup key.

The Router Keygen program is an application for Android phones that uses the phone’s WiFi to scan an area for all wireless access points in range and highlights which points are still set to the default configuration. Selecting a point then tells the user what the password is. The database of all entries takes up about 28MB of storage space, but this is a trivial amount of memory for every Android phone on the market.

Here’s a terrifying and real-world example: I was visiting a friend who lived in a high-rise apartment complex – one of those places where you can see into the balcony windows of about a hundred other apartments across the courtyard. While sitting comfortably in his living room, I turned on Router Keygen to see what would come back. The results were staggering:

25 vulnerable networks from the comfort of my chair.

The screen-shot to the left is one of three pages of vulnerable access points that I could have accessed and utilised with my phone, laptop, or any wireless device of my choosing. This whole process was completed in the time it took me to unlock my phone and click 1 button. Total wait time for the phone to lookup and start displaying keys was maybe 3 seconds. It’s hard to say with any certainty as my jaw was sitting in my lap from the number of results returned.

Sitting in my friend’s comfy chair, I was looking at a list of about 25 vulnerable networks – any one of which I could have connected to, used their internet connection, other computers, network storage, music and video collections, webcams, and anything else that was open and listening on the network.

WEP Passwords in 1 click.

The developers of the application were also very thoughtful in giving the ability to lookup passwords manually by ESSID. Running Kismet or similar wireless monitoring software on a laptop, an attacker can quickly and conveniently look up passwords for wireless access points that are out of range for the phone’s antenna, but not for the laptop. If this table on Wikipedia is an accurate representation of reality, someone could access and utilise a vulnerable network hundreds of feet away. Equally as bad, a wireless sniffer could capture and actively decrypt the wireless traffic from thousands of feet away.

Still happy with that free router your ISP gave you? Rather than throwing it in the trash, you should simply fix your security. Here are some helpful tips from the US-CERT Team regarding wireless security with additional comments from me in italics:

• Change default passwords – Most network devices, including wireless access points, are pre-configured with default administrator passwords to simplify setup. These default passwords are easily found online, so they don’t provide any protection. Changing default passwords makes it harder for attackers to take control of the device.
• Restrict access – Only allow authorized users to access your network. Each piece of hardware connected to a network has a MAC address. You can restrict or allow access to your network by filtering MAC addresses. Consult your user documentation to get specific information about enabling these features. There are also several technologies available that require wireless users to authenticate before accessing the network. – A bit of a pain to manage as it requires each device to be added to the authorised list in order to join the network, but if you really want to control what devices are allowed to connect to your network, then this is something you may want to explore.
• Encrypt the data on your network – WEP and WPA both encrypt information on wireless devices. However, WEP has a number of security issues that make it less effective than WPA, so you should specifically look for gear that supports encryption via WPA. Encrypting the data would prevent anyone who might be able to access your network from viewing your data. – And don’t use WEP! Use WPA2. If your device does not support WPA2, then you should get a new device.
• Protect your SSID – To avoid outsiders easily accessing your network, avoid publicizing your SSID. Consult your user documentation to see if you can change the default SSID to make it more difficult to guess. – This tip is suggesting that you avoid broadcasting your SSID, which really doesn’t do much to protect your network as a wireless sniffer will eventually capture some traffic and your SSID will be seen. Changing your SSID to something other than the default will show a party interested in your network that you have taken the time to change the configuration on your devices and getting inside your network will probably be more trouble than they care to invest as there are probably easier targets in range.
• Install a firewall – While it is a good security practice to install a firewall on your network, you should also install a firewall directly on your wireless devices. Attackers who can directly tap into your wireless network may be able to circumvent your network firewall—a host-based firewall will add a layer of protection to the data on your computer. – Although a good practice, the routers I am referring to in this post are also acting as firewalls between the internal network and the Internet. It is possible to have a firewall on a wireless device, but that is beyond the scope of this article and would require a different device than the models I am referring to. If available on your system, you should have the firewalls on all of the computers on your network turned on and only known, trusted systems to connect to each other.
• Maintain anti-virus software – You can reduce the damage attackers may be able to inflict on your network and wireless computer by installing anti-virus software and keeping your virus definitions up to date. Many of these programs also have additional features that may protect against or detect spyware and Trojan horses. – This goes along with the above advice regarding firewalls. Many antivirus programs also come with firewall software built-in.

If you happen to have a neighbor broadcasting that obvious factory-default SSID, please take a moment to tell them how insecure they are and encourage them to change the settings on their router.

After much delay and debate I have finally broken down and decided to get a bloggy, webby thingy online. This decision was brought about after the past few months of various half-started projects that really needed a home, and the occasional desire to share my unabridged thoughts, culminating with my wish to share my opinions and experiences with the unfortunate Dropbox debacle.

I’ll still be on Twitter being my normal snarky self, but for those times when I really need to do some ranting or raving in excess of 140 bytes, I’ll be posting those here.

So exactly what is this corner of the intertubes supposed to be? If you’re hoping it will be the next awesome digital forensics website, I’ll be surprised and you’ll probably be upset. Although I do plan to make digital forensics one of the topics I write about regularly, you should think of this spot as my mental junk-drawer.

That being said, thanks for reading and I hope to contribute something of interest to someone at some point.