Thursday, December 30, 2010

Notes from 27th Chaos Communications Congress

From McAfee blog:
The 27th Chaos Communications Congress (27C3), a computer security conference held in Berlin, has offered several good mobile and embedded security talks in the past few days. SMS-based vulnerabilities, vulnerabilities in mobile phone radios, and laptop rootkits that infect peripheral chips instead of the main CPU were among some of the new research presented.
[...]

Collin Mulliner and Nico Golde demonstrate maliciously crafted SMS message attacks against a collection of feature phones.
[...]

Ilja van Sprundel describes how to reliably identify mobile phone OS versions using a maliciously crafted MMS message and a web server.

[...]

Ralf-Philipp Weinmann explains the process he used to discover vulnerabilities in the code running on Baseband processors.

[...]
The conference continues
The Chaos Communications Congress is an annual event that ends the year with a lot of good research and food for thought. 27C3 ends this Thursday, but the talks I’ve cited, or any others you might be interested in, will be available online soon

Monday, December 13, 2010

"‘Antid0te’ Coming to Boost Security for Jailbroken iPhones"

From McAfee blog:
"Jailbreaking your iOS device used to simply be about gaining some freedom–getting root access, installing native apps, and adding or modifying themes. The worst that could happen would be running into a slightly malicious installation package. Then we met the OSX/RRoll family of worms that actively went after jailbroken devices. Part of the risk came from insecure defaults and reduced security caused by the jailbreaking process.

The entire insecurity situation is about to change with the release of the new security tool Antid0te. Created by security researcher Stefan Esser, the Antid0te adds Address Space Layout Randomization (ASLR) to jailbroken iOS devices.  Esser will present the technical background for Antid0te on Tuesday at the Power of Community conference (POC 2010) in Seoul, South Korea."
[...]
"The initial release of Antidote is scheduled for December 24, but Esser is not stopping with adding ASLR to jailbroken iOS devices. In upcoming releases, Antid0te will also re-enable code signing and other protections. With these changes we will eventually see an overall increase in the security of jailbroken iOS devices–resulting in their becoming as secure as, if not more so than, stock iOS devices."

Tuesday, November 30, 2010

"Mobile Browsers: Trouble Comes in Threes"

From McAfee Blog:
In the last week there have been a few vulnerability disclosures for mobile web browsers. These threats affect a number of smart-phone platforms: Android (Google), WebOS (Palm), and iOS (Apple). Although all three platforms have their own apps and environments, it’s interesting that they’re all vulnerable through the same entry point of the mobile browser.
[...]

Patches: a compete solution?
A number of these vulnerabilities have been patched, but this does not secure all of the affected devices. Embedded systems and mobile phones in particular can’t be patched as easily as your desktop computer. For over-the-air patches there are costs involved in bandwidth, transmission time, and device downtime that argue against frequent updates. These updates also do not include testing and QA on every affected device. The additional work can result in the “fixed it in CVS/SVN/etc.” situation–in which developers have fixed a bug in the project’s source code but the fix hasn’t yet reached current compiled programs.

The outlook with smart phones isn’t quite as stark as with phones with fewer features. Whereas simple phones have almost all their system software and applications in the firmware, smart phones tend to have theirs on easily writable storage. A buggy browser can be fixed with a small signed update, rather than requiring the phone firmware to be reflashed. Or we may see a move toward placing thin firewalls/IDS layers between applications and potential attack vectors. As more vulnerabilities are discovered in mobile applications, these small targeted patches may become the norm.

Tuesday, November 16, 2010

"Mobile NFC Features Raise Security Concerns"

From McAfee blog:
Yesterday, at the Web 2.0 Summit, Google’s CEO Eric Schmidt presented the Nexus S. This wasn’t just about a new phone, he also talked about how Gingerbread (Android OS Version 2.3) would have support for NFC (Near Field Communications) built in. In light of the mobile-phone hotel-key (NFC-based) trial going on at the Clarion hotel in Sweden and questions raised during the conversation at the Summit, it’s time to take another look at the state of NFC security.
[...]

The more your mobile phone is used for payments (as a “wallet in your phone”) the more it becomes a target for attackers. Last week we discussed attacks that target NFC-enabled phones.

Monday, November 08, 2010

Mobile Hotel Room keys, what could possibly go wrong?

From McAfee blog:

If you are like me, there are times when you will misplace your hotel key. Times when you’re switching a bucket of ice between hands while searching your pockets or bag. Wondering if you’ve left the key in your room or possibly the lobby. Thinking “I’ve always got my phone on me, wouldn’t it be so much easier if I could use it to open the door.” OK, maybe I’ve never thought that last bit, but the folks at high-security lock makers Assa Abloy apparently have. They’re running a four-month trial of their Mobile Key technology at the Clarion Hotel in Stockholm. Essentially a guest checks in with a phone and the room key is sent directly to the device. No more misplaced keys.

The hotel trial is a joint effort among Choice Hotels Scandinavia, mobile carrier TeliaSonera, and near field communications (NFC) vendor Venyon. NFC is an extension of the same technology used in “tap and pay” credit cards. NFC turns your phone into a mobile wallet. In this case, just tap your NFC-enabled phone next to the hotel door knob and it unlocks.

Just hold your mobile phone near the door and it unlocks. What could possibly go wrong?


Assa Abloy has an interesting video showing off the many uses of their Mobile Keys (house key, office key, temporary key for contractors, hotel keys, etc.). You can issue temporary keys to contractors or cleaners, and you receive a notification whenever one of the temporary keys is used. In the same way, when you check in to a hotel using your phone, they can send your hotel key directly to your phone.

Because most people don’t have NFC-enabled phones, the Clarion’s guests are given new versions of a Samsung phone. The Samsung S5230 was a popular touch-screen phone released last year, and this year it’s been updated for NFC. So for the moment guests will still carry multiple devices–two phones–but eventually we expect to use one smartphone for nearly everything.

The Java Mobile Keys application provides relevant information on the hotel key, and a handy reminder of the room number.

NFC security
NFC phones sound like a great improvement over hotel keys and keycards. If you’re like me, however, you’re probably wondering how it could all go horribly wrong–especially if you’re familiar with Collin Mulliner’s security research on NFC-enabled phones.

Mulliner took a look at a number of Nokia NFC phones. He tried a number of attacks against the devices: phishing, fuzzing, spoofing. He also developed a python library and tools to read and create NFC tags. This library generated a number of specially crafted tags to fuzz the NFC reader on the Nokia 6131. This research isn’t current for the latest NFC phones, but it serves as a basis for expanding to new devices.

A Nokia 6131 NFC-enabled phone loading a URL from a Smart Poster. This phone was investigated by security researcher Collin Mulliner. (Credit: Timo Arnall at the English Wikipedia project)

Unlike the Nokia 6131, the Samsung S5230 supports the Security and Trust Services API for the J2ME (JSR-177) standard for secure distribution of Mobile Keys. This is basically using public key encryption to ensure that the key your phone receives came from the hotel (no spoofing attacks) and that it hasn’t been tampered with on the way (no man in the middle attacks).

Your phone’s accepting a fake key isn’t the most likely attack. An attacker or thief would rather get the actual key or, in this case, an electronic copy of your key. With NFC and other RFID systems, there’s an attack called ghost and leech, or simply a relay attack. Here’s a quote from the first paper to mention the attack: “The ghost is a device which fakes a card to the reader, and the leech is a device which fakes a reader to the card.” An attacker would either need to steal an actual reader (from a hotel door) or manufacture a compatible reader to function as the leech, and similarly clone the hardware used in your phone to play back the Mobile Key to your hotel room’s door as the ghost. It’s difficult for attackers to get access to the hardware during a trial, but once the hardware is widely in use there will be opportunities to acquire it. We’ve already seen as much with RFID credit card readers sold on eBay.

These are attacks that attempt to intercept the key during transit or block it from arriving on your phone. There is still the possibility that an attacker will go after the device that holds the key or the mobile app that interfaces with the NFC hardware. The Samsung S5230 is a J2ME device and the Mobile Keys app is very likely a Java program. Generally the threats we’ve seen on J2ME phones have been Trojan horse programs, designed to trick users into harming themselves or costing them money. It’s unlikely that a Trojan could properly convince a user to install it in place of the legitimate Mobile Keys app. It would make more sense, as on platforms such as Android, to go after the underlying operating system or Java Virtual Machine (JVM). Two years ago security researcher Adam Gowdiak exposed vulnerabilities in the JVM used by a number of well-known mobile phones. He developed a number of proof-of-concept exploits and malware targeting the JVM. Given that the flaws were in the JVM and not in the applications, the fixes would require a firmware update on affected phones. Although these threats are more difficult to defend against, they also require a much higher skill level and a greater amount of work from an attacker.For the moment these are either old or theoretical attacks. We still have some time before attackers and thieves catch up to the new technology.I hope the trials will go well and in the near future I won’t need to shuffle things around in my arms to hunt down that elusive hotel key. But finding my misplaced mobile phone is another story.

Thursday, October 28, 2010

iBots? Mobile phone network 0wnage

From McAfee blog:
Some of the most interesting research on mobile botnets is being done in the lab.  Security researchers Collin Mulliner and Jean Pierre Seifert have put together a robust Proof-of-Concept (PoC) iPhone botnet. 
Their research was presented at the 5th International Conference on Malicious and Unwanted Software (MALWARE 2010) last week.  In a presentation titled “Rise of the iBots: 0wning a telco network”, Mulliner/Seifert look into various methods of establishing command and control (C&C) of a botnet over a mobile telephone company’s network.  Very timely, I added an overview of the research to my talk on Saturday at Toorcon
The researchers didn’t implement any spreading functionality so that there was no risk of the botnet escaping the lab. They instead concentrated on seeing which communication methods were best for maintaining a distributed computing network (like a botnet); SMS, http, or P2P.  Unlike general PC security researchers, these two have experience in the challenges and issues involved in developing for low powered, limited CPU/RAM devices with inconsistent network connectivity(EDGE, 3G, WiFi, etc.).
The SMS method, using text messages to send commands to the bots, is commonly used by other mobile spyware and botnets.  The more advanced malware will also intercept and delete any command SMS messages, so that the user never suspects that they’re infected.  Mulliner has previous experience with SMS interception, having presented his research on the topic at the Black Hat USA security conference in 2009
Instead of using straightforward text-based SMS messages like with other mobile malware, they use binary mode SMS. These are not system SMS messages or “flash” SMS messages that don’t leave a trail in the inbox.  They’re just SMS messages with about 140 bytes.  Sending in binary lets them encode commands in less space and also helps to make the C&C messages harder to detect.  They also determined that in addition to SMS, using a combination of P2P and http protocols could increase the robustness of the botnet. 
There’s a joke amongst malware researchers that sometimes it feels like we’re doing QA for the malware authors; calling them out on their bad code.  Malware authors aren’t generally known for following secure development or software testing processes.  Occasionally it takes a professional developer/researcher to do it right.  Mulliner’s research from Black Hat involved fuzzing SMS handlers, so it was amusing to see that they actually fuzzed their botnet’s SMS command handling code.  I guess when you’re getting ready to take over your telephone company’s network, you can’t have your botnet fail just because it gets a malformed command SMS. 
Since they used binary SMS messages, the botnet commands aren’t as easy to decode as a plain text protocol.  The table below shows the breakdown of a command SMS.  Mulliner/Seifert were careful in designing their communication protocol to insure that it was safe from replay attacks(responding only to packets with sequence numbers greater than the last command) or hijacking through command emulation(encrypting and digitally signing command messages).
Breakdown of ibot command packet
Fig 1 - Binary command SMS messages are broken down into a few parts. 
Each command SMS is digitally signed to prevent hijacking of the botnet.
The sequence number helps to prevent a replay attack.
All packets can also be optionally encrypted to further evade detection. 


Below is a breakdown of the commands they implemented:

Fig 2 - A human-readable list of the binary commands used in the botnet.
Running a command can be used to DDOS a website


After seeing an attempt at a stable, fault resistant, mobile botnet, one might wonder how to protect against such a threat.  On that note, we may actually be better off taking a page from Mulliner and Seifert’s presentation:

“Mobile telcos need to think about monitoring and fighting SMS-based botnets”.

This works for threats on the network. On the individual level there are still a few ways to shut the door on attackers:

    • Install the latest official OS/firmware patches for your smartphone
    • Avoid pirated software or software from untrusted sources

 

Tuesday, March 02, 2010

Geocities gone, old site mirrored

I never expected the lack of server side scripting support on GeoCities (free) accounts would be helpful for preserving the old site. This also led to the site being much smaller and easier to archive locally. The W3 link checker helped in removing dependencies on Geocities.

The old Symbian Malware Detection site is now mirrored on byethost:

Mirror 1: http://jfldars.byethost4.com/

Mirror 2: http://symbmalwaredet.byethost33.com/

No ads as far as I can tell.

Auto "Kill Switch", solving the wrong problem?

Consumer Watchdog, a consumer advocacy group, put out a report on the dangers of Internet connected cars. They received coverage on the nigh...