Tuesday, June 29, 2010

Russian spies and adhoc wi-fi

On June 28, 2010, the FBI arrested 10 Russian spies. The complaint against two of them, Anna Chapman and Mikhail Semenko is fascinating. Instead of dead drops at cemeteries or brush-passes at crowded restaurants, these spies set up adhoc wireless networks between 2 laptops and exchanged information.

The complaint first describes what an adhoc wireless network is:

and then cites many examples of how when Anna Chapman opened up her laptop, and when a certain Russian government official was nearby (in a van outside a coffeeshop or standing outside a bookstore), an ad-hoc wireless network with the same two MAC addresses sprung up.
Semenko used the same technique. In one instance, he was sitting in a restaurant, while a car with diplomatic plates (issued to the Russian embassy) entered the parking lot and sat there for 20 minutes and then left.

Further down, Semenko described to an undercover FBI agent posing as a Russian diplomat how he zipped up the files, opened up his laptop to set up the adhoc wifi and transferred the files.

A number of questions and thoughts:
- Because the FBI knew enough to pose to undercover agents as Russians and arrange meets with the spies, they had penetrated the ring for a very long time. Other documents mention search warrants against safe-deposit boxes as early as 2001.
- Which brings up another question. Why did Russian agent and FBI counter-intelligence honcho Robert Hanssen, not warn them? His position in the FBI should have guaranteed he knew about this.
- Or did Hanssen, who was arrested in 2001, give them up?
- But if Hanssen knew about this team, why didn't the Russians pull them out?
- Anna Chapman must have smelled a rat, and that's why she bought a disposable phone (to call Russia?) and did not show up for the meeting the next day (June 27)
- Which must have led to the arrests on the 28th because the FBI decided the spies were on to them.

Thursday, May 6, 2010

What Virustotal says about a suspicious attachment and AV products

I received a $50 iTunes gift certificate today as a zip file. Yay!

I uploaded it to Virustotal, and the result is below. If the formatting is lost, you can see the report here: http://shar.es/m6tDP

First, Virustotal told me that they already have seen this file. Next, very few AVs identified it as a threat. And at the risk of beating up on McAfee again, their gateway version with a May 6 def identified it, but their regular (?) version with a May 7 def did not! In all, only 8 of 41 identified it.

AVG, which is on my laptop, did not identify it either.

My question: what happened to AV companies sharing knowledge? I would
have thought in 24 hours at least all the big boys would have shared the
signature. A 20% detection rate is pretty bad. But as McAfee's left hand
does not know what its other left hand is doing, I guess I should not be
too surprised.

Antivirus Version Last Update Result
a-squared 2010.05.07 -
AhnLab-V3 2010.05.07.00 2010.05.06 -
AntiVir 2010.05.06 -
Antiy-AVL 2010.05.06 -
Authentium 2010.05.06 -
Avast 4.8.1351.0 2010.05.06 -
Avast5 5.0.332.0 2010.05.06 -
AVG 2010.05.07 -
BitDefender 7.2 2010.05.07 Gen:Variant.Bredo.4
CAT-QuickHeal 10.00 2010.05.04 -
ClamAV 2010.05.06 -
Comodo 4783 2010.05.06 -
DrWeb 2010.05.07 -
eSafe 2010.05.06 -
eTrust-Vet 35.2.7472 2010.05.06 -
F-Prot 2010.05.06 -
F-Secure 9.0.15370.0 2010.05.07 Gen:Variant.Bredo.4
Fortinet 2010.05.05 -
GData 21 2010.05.07 Gen:Variant.Bredo.4
Ikarus T3. 2010.05.06 -
Jiangmin 13.0.900 2010.05.06 -
Kaspersky 2010.05.07 -
McAfee 5.400.0.1158 2010.05.07 -
McAfee-GW-Edition 2010.1 2010.05.06 Artemis!ECB1C56D7D93
Microsoft 1.5703 2010.05.06 -
NOD32 5092 2010.05.06 -
Norman 6.04.12 2010.05.06 -
nProtect 2010-05-06.02 2010.05.06 Gen:Variant.Bredo.4
Panda 2010.05.06 Suspicious file
PCTools 2010.05.06 -
Prevx 3.0 2010.05.07 -
Rising 2010.05.06 -
Sophos 4.53.0 2010.05.07 Mal/FakeAV-BW
Sunbelt 6272 2010.05.06 -
Symantec 20091.2.0.41 2010.05.06 -
TheHacker 2010.05.06 -
TrendMicro 2010.05.06 PAK_Generic.001
TrendMicro-HouseCall 2010.05.07 -
VBA32 2010.05.06 -
ViRobot 2010.5.6.2304 2010.05.06 -
VirusBuster 2010.05.06 -

Saturday, April 10, 2010

Cheapest 419 scam ever

Received this just now.Are they just giving up now? Or is it some sort of ultra-soft-sell?

Also notice that they are not sure about my religious affiliation

新しいメールアドレス: sadiqaliman1@yahoo.co.jp

Dearest one,

I greet you in names of our almighty allah? however let me give you brief introduction myself, My name is Aliman Keita the only surviving daughter of Mr &Mrs Sadiq Keita, he deposited ($6.5) I will give more details concerning me and the transaction.

Miss Aliman.

- Keita Sadiq Aliman

Saturday, January 30, 2010

A "safe" handgun or a $9700 design fail waiting to happen?

Wired is reporting that Armatix introduced a Euro 7000 (US$ 9700) handgun that can only be fired if it is armed via a wristwatch worn by the shooter.
This year, the highest-tech gun belonged to Armatix. The German firm has an electronic safety that automatically disables the pistol when it’s not within a few inches of a custom wristwatch. The watch sends a wireless arming signal to the gun. If the gun is picking up a signal from the watch, a green LED on the back lights up. Try squeezing the handle without wearing the watch, and you will see a red warning light. Anyone can pick up a limited edition version of the pistol for about 7,000 euro, which is pretty steep for a .22cal plinker. They start shipping next month.

Few inches, eh? Smells like RFID. Then we found this on Armatix's website:
The benefits of biometrics (sole allocation to specific people) are also combined with those of Radio Frequency Identification ( split- Seconf activation, hands-free operation.

"Seconf" above should be "second", but that might be the least of their problems. My problem is, given the many, many security failures I have seen in basic authorization/authentication schemes, I anticipate a slew of them in this handgun. Here are some of them:
  1. It's not like RFID has been read or cloned. Oh wait!
  2. RFID can be jammed. For that matter, any RF can be jammed.
  3. Forget hightech.. throwing a bucket of water at the person holding the gun at you might work. I see a Rush Hour sequel where Chris Tucker almost gets Jackie Chan killed by spilling coffee on his wrist and rendering his gun into a paperweight.
  4. The flip-side of jamming is arming. People have read RFID passport numbers and cloned them. Then it is just a matter of playing that back, from a more powerful transmitter, and suddenly the "safe" gun will fire a bullet.
  5. And then ofcourse, the same RFID scanners can be used to identify who is carrying those guns and wrist-watches.

One can only hope that this gun will be completely safe because there are no morons who will pay that kind of money for a .22

Thursday, January 28, 2010

Multiple Congresspeople websites defaced

National Journal's Hotcall reported around 3:20 AM on Thursday, January 28 that various congress people's (both republican and democrat) websites were defaced.

The message was crude and simple:
"F--- OBAMA!! Red Eye CREW !!!!! O RESTO E HACKER!!! by HADES; m4V3RiCk; T4ph0d4 -- FROM BRASIL," the messages read.

Praetorian Prefect has some screenshots and what seems to be a pretty complete list (perhaps compiled by going through the sites manually around 4 AM!)


A few committee sites were affected as well:


Ironically, one of the first defacements discovered was on Congressman (R-SC) Joe Wilson's site, who (in)famously yelled "You Lie!" at Obama. Mr. Wilson gave one of the first live responses to Obama's SOTU speech.

The websites are maintained by the House IT staff, and most of them run on identical systems and software. So it is not surprising that after the first site was found to be vulnerable, the attackers found a rich array of soft targets.

As a result, the serial defacement does not surprise me--if anything, I am surprised they did not hack 500+ sites.

Praetorian Prefect identified the Joomla CMS as the one common factor on all the defaced websites (but not all Congressional sites running Joomla were defaced)

It seems a particular Joomla component or module was vulnerable and was exploited. I just hope the knee-jerk reaction to this is not to go back to some proprietary CMS.

Saturday, January 16, 2010

How mobile phone users stumbled into other people's FaceBook account

AP is reporting: "Network flaw causes scary Web error":
A Georgia mother and her two daughters logged onto Facebook from mobile phones last weekend and wound up in a startling place: strangers' accounts with full access to troves of private information.

The glitch -- the result of a routing problem at the family's wireless carrier, AT&T -- revealed a little known security flaw with far reaching implications for everyone on the Internet, not just Facebook users.
True. Most internet sites that do not use secure login (https) may be vulnerable until AT&T fixes their problem. Boston Globe readers are reporting that they faced the same problem as far back in 2007, on carriers other than ATT Wireless.

As an aside, I had to laugh after reading this line in the AP article:
In each case, the Internet lost track of who was who, putting the women into the wrong accounts.
Reminds me of this AOL helpdesk gem: "This is not an AOL problem. Have
you tried calling the Internet's support department?"

To understand how this could have happened, lets take a look at how a website knows who is who once they log in. Of course, they could just have your username added to each page request. But then anyone who knew your username would be able to impersonate you. One popular mechanism is using session cookies. Here is a very simplified description:
HTTP is stateless (meaning the web server has no memory of who you are or what you just did), so the server has no way of keeping track of the users who logged in (and tying them to a specific browser).

Once a user logs in, a cookie is set with a lifetime (say, 15 minutes), and this cookie and matching userid is stored somewhere, preferably a database. It is typically a long and random string like xyn29f071bca9bf7f85da28205439fc3, so someone can not just guess it.

Every time the user tries to go to a protected page, the server reads the cookie from the browser, looks up the username that matches the cookie, and allows (or disallows) access. The cookie is also updated with each request (lifetime extended by 15 minutes). If no request is made, the cookie expires, and user gets logged out for inactivity. If the user chooses to log out or in the previous case gets logged out due to idle timeout, his/her cookie is deleted on the server, so they can not access protected pages any more.

So, if for some reason Alice gets Bob's cookie (before Bob logs out), the server will think Alice is Bob, look up pages that Bob has access to, and bada bing!--Alice will be looking at Bob's pages.

Now the million dollar question is, how would Alice get access to Bob's Facebook session cookies? Stealing session-cookies is a well-known attack; people have demonstrated this on multiple sites including Google Spreadsheets, and bad guys have used this to compromise accounts. But we can be pretty sure in this case the person who experienced this wasn't doing any such attack. So what happened?

Here we enter the murky territory of speculation. We know that AT&T is worried about the amount of data usage by it's wireless customers because their network can't keep up. So is it possible they used HTTP pipelining to improve performance?
Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.

HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.

What I think happened was: ATT's web proxy uses pipelining. User A and User B where both trying to log onto Facebook at the same time. When the responses came back it messed up the order, and sent the response destined for User A to User B's browser, thus giving her access to User A's facebook page.

PS: Where did the response meant for User B go? To user A? To yet another person who has not come forward yet? To User B's browser, which then discarded it because it thought it already got a response to its original request? To the bit-bucket? Who knows.

Monday, January 11, 2010

Harsh: Google Security chief's night-job

Gawker has a post about Google Apps' Director of Security Eran Feigenbaum, and his not so secret identity as Eran Raven, mentalist/magician.

I had to laugh out loud after reading this:
Maybe it should come as no surprise that Google's Director of Security is also a "mentalist" magician; few can better sell the illusion of ironclad internet security, after all, than a master of deception who fooled thousands of NBC viewers.

But Eran Feigenbaum — better known as "Eran Raven" — has turned the cheese knob up awfully high, considering his buttoned-down job as the Director of Security for the putative blue-chip operation that is Google Enterprise, which is trying to sell "cloud computing" to no less uptight a customer than the federal government.

Tuesday, January 5, 2010

We don't need no stinking security in our digital photo frames

Update (Jan 6, 2010): Looks like FrameChannel is doing something to block access to known URLs. It could be something as simple as user-agent checking, but at least it is a start.

2010's first security vulnerability (that I know of) is a doozy. But before getting into that, lets take a peek into the design meeting that resulted in it.

Person 1: Lets see.. how would each customer identify the product for activation?
Person 2: We will stick a random code on each package
Big boss: No, that is too much work
Person 3: You know, each device already has an unique identifier. This MAC address...
Person 2: Shouldn't it be random? Should we talk to the security guys?
Big Boss: Awesome. Why would a photo frame need security? This MAC thingy sure looks very unfriendly, so lets label it as a user-convenience feature. While you guys do that, I will go tell my boss I came up with the idea.

This not-so-unlikely scenario is brought to you courtesy of an excellent blog post by Casey Halverson, owner of two W820 Kodak digital picture frames.

Knowing that the frames can display pretty much any RSS feed, Mr. Halvereson discovered that the configuration screen shows a URL for the RSS feed that ends in what looks suspiciously like a MAC address, because, you guessed it--it IS a MAC address. (The link below is not clickable by choice--we don't know what will be there if you visit it)

Look, its an RSS feed of what my picture frame is showing now! I can send this nice URL to everyone I know so they can look at all my private content I have configured for this device. Now, under no circumstances would I recommend changing the last digits of this MAC address frame ID to another number….because you would get someone else’s picture frame content. Why would you want to do that?

If you don't know how MAC addresses are assigned and numbered, here is a quick introduction. The first 6 hexadecimal digits (in this case, 00:23:4D) designate the manufacturer of the network card, and the remaining 6 hexadecimal digits identify a serial number assigned by the manufacturer.

So if you are looking at a Kodak photoframe, who does not make network chips, it is a pretty safe bet that they buy the chip from someone else (or their outsourced manufacturer does, but same effect). It is also a near certainty that because of economies of scale, these chips will be bought from the same company. What I am leading up to is, this means virtually ALL Kodak wireless frames will have the same first 6 digits, making the remaining address-space any number from 00:00:00 to FF:FF:FF -- a total of slightly over 16 million possible numbers: trivial for a computer to generate and check. 00:23:4D:B8:07:6D is manufactured by Hon Hai Precision Ind. Co., Ltd. Obviously, all their cards will not be used on the Kodak frames. But now that we know the name of the manufacturer, a bad guy can go and find other prefixes assigned to them, and expand the search.

The frames, by the way, can not pull down RSS feeds on their own. The feeds need to be managed through a company called FrameChannel, which, as the name indicates, is in the business of creating channels for picture frames. They very conveniently list a number of frame manufacturers they support.

Could they all be vulnerable to the same attack?

They also are saying that Woot sold 100,000 Kodak frames on Dec 20, the first day they went on the market. Given the other manufacturers, the problem-size could be more than a million vulnerable frames out there.

In their FAQ, they answered (as of this writing; I expect this to change soon):
Who can see the pictures in my account?

Unless you add pictures to a public or group channel, or share them with your invited friends, you are the only one who will see images in your account. No other FrameChannel user will ever see images you upload or add to your account unless specifically approved by you (such as in the case of a public user generated or group channel, or as a contributor to your friends' accounts). (emphasis mine)


Someone could point all the unsold/unactivated frames to pornography, or other objectionable or even illegal content like child pornography. So if you have one of these frames, what should you do? Don't feel safe because you only have nature photos. If you have the Weather channel configured, a remote viewer may be able to figure out your city and state. If your userid contains your name in some form, they may be able to narrow it down much further.

In the configuration screen, there is a URL parameter called reset=0. Any guesses as to what reset=1 will do? Yes, it gives a new activation code, and I presume it deactivates the old code. Seems like this can be used to kill feeds to a frame.

The next one is a bit more serious. One report says they saw something like:
“This frame has been preactivated” and gave the username and password and invited the user to login to framechannel.com to upload their own content.
 As long as you treat this frame as something viewable by the whole world, then you are fine.

Should you return the product? Your choice. But if you want to keep it, definitely contact the manufacturer and FrameChannel, and ask them to fix this issue.

Postscript: The bad guys can point these frames to a photostream of their choice before they are activated by the actual owner. Equally easily, the good guys can load up an image containing an warning about this risk to these frames, but they will not, because that will mean breaking more than one law. So if you know anyone with one of these frames, also tell them about this.

Rant:I don't understand why the manufacturers decided to go with a 3rd party which may go out of business (a distinct possibility given this mess) instead of just allowing any random RSS feed. It is not like this 3rd party is hosting my images or creating the RSS feed any way. So why shouldn't consumers be able to use a RSS feed directly?

Update: David Stafford asked below if an already activated and used frame can be compromised. The answer is, I think so, although I have not personally tested it yet.
The known/confirmed risks are:
- Someone may be able to view private images- Someone may be able to glean private information from the images or other channels being displayed

Unconfirmed: The major risk (remote image upload) might be possible because FrameChannel lets people who knows/guesses the frameid (the MAC address) to reset the frame. The aforementioned reset=0, when changed to reset=1, will do this. I am not posting the actual URL, but it is by now widely available on the Net.

After a frame activation is reset and re-activated, I believe at least on the Kodak model it can be done.(waiting for confirmation)

For users on unencrypted (or 40-bit WEP encrypted) WiFi, an attacker who is within the WiFi range will be able to capture the PIN, but that is true about any wireless technology and not particular to this issue