"Chaos Congress Peers Into Mobile Security, Protocols"

From McAfee blog:

I heard a number of interesting mobile-related talks at the 28th Chaos Communications Congress (28c3) this week. Not every talk at the Congress was about newly discovered bugs or zero-day exploits; sometimes we got the building blocks necessary to better understand systems and increase security. I enjoyed key presentations on reverse-engineering USB 3G data sticks and the internals of 2G and 3G mobile data protocols.

Reverse-engineering a Qualcomm basebandGuillaume Delugré acknowledged researcher Ralph Phillip Weinmann’s work from last year during Delugré’s talk on reverse-engineering a popular 3G USB data stick.
 Guillaume Delugré discusses how he reverse-engineered Qualcomm firmware and developed a debugger.

[...]

Cellular protocol stacks for InternetHarald Welte, a lead developer of the Openmoko project and a Linux kernel developer, gave a good breakdown of various mobile data protocols. Cellular voice communication on GSM has gotten a lot of coverage over the years, but outside of the mobile industry there has been little to no information on how the data protocols function.
Harald Welte presents details on mobile data protocols.

"Networked Printers at Risk"

From McAfee blog:

"Multifunction printers (MFPs) have been common in offices for years. They let employees print, scan, and copy documents. Two separate talks at the 28th Chaos Communications Congress (28c3) show how attackers can infect these trusted office devices.

Hacking MFPs

In Andrei Costin’s presentation “Hacking MFPs,” he covered the history of printer and copier hacks from the 1960s to today. The meat of the talk concerned executing remote code on an MFP using crafted PostScript. Just printing a particular document can get code to run on the machine. Previous research proof of concepts have done exactly that, once with a specially designed Word document and once with a Java applet.

Printers and copiers have been targets of attackers and spies for decades.

[...]

Print me if you can

A day later researcher Ang Cui referred to Costin’s talk about PostScript attacks, though Cui’s research was limited to MFPs from HP. Similar to the earlier presentation Cui’s attack leveraged the update capabilities on multifunction devices.

Ang Cui and Jonathan Voris demonstrate printer malware that forwards printed documents to a printer outside the corporate network.

"Fighting Mobile Phone Impersonation and Surveillance"

From McAfee blog:

"[...] at the 28th Chaos Communications Congress (28C3), in Berlin, security researchers along with Karsten Nohl and Luca Melette showcased a number of flaws and solutions in GSM mobile phone networks."

Karsten Nohl presenting “Defending Mobile Phones” at the 28th Chaos Communications Congress.

An additional technique used to locate mobile phones is the so-called Silent SMS. These messages are silently ignored by the majority of mobile phones and give no indication to the user. But the messages leave trails in customer service records, the logs kept by mobile carriers, and allow monitors to correlate a mobile phone’s location with that of cell towers.

Our presenters have developed free software, CatcherCatcher, which detects features used by IMSI catchers that regular cell towers don’t use. The GSM security map, a site that uses data from the CatcherCatcher tool, helps to track unauthorized mobile phone monitoring.

Why I don't play QR Code Roulette and you shouldn't either

From the McAfee blog:

Last year a friend had a bright idea for a party game that involved a series of QR codes in a circle on paper. He called it QR Code Roulette. Unlike the gambling game, selecting the right 2D barcode did not make you a winner. It turned out that every QR code contained a URL to an Internet shock site. As soon as I or our other friends scanned a QR code with our phones we witnessed things that probably can’t be unseen. This was a good prank, but fortunately due to my distrust of autoloading and autorunning code I had an app that previewed the URL. If the address were a risky site or malware download I could choose not to visit the URL.

 

These QR codes are safe. They point to McAfee mobile security downloads and our Virus Information Library. To verify, download one of the QR code apps mentioned and view the preview URL.

My friend’s little joke drove home the necessity of not blindly scanning every QR code I run across. Some of my colleagues aren’t as lucky. I was discussing a recent threat of malware distributed by QR codes with a couple of coworkers who are penetration testers. They test the security of their clients’ networks and systems nearly daily and are very skilled computer security professionals. Although both of them had QR code-scanning apps on their phone, neither had one that could provide a preview of the URL. I ended up suggesting a couple of free barcode-scanning apps that would keep them from being unpleasantly surprised.

Although distributing mobile malware through QR codes is becoming popular, it’s not a new idea. Security researcher Felix “FX” Lindner described similar attacks about three years ago at the 24th Chaos Communications Congress and DefCon 16. FX claimed that newspaper ads with QR codes are trusted implicitly by readers (“It’s in print; it must be true”) and would make a good vector for exploits and malware. The functionality that enabled the attacks was the automatic loading and following of URLs in QR codes. Point your phone at the QR code and you end up downloading mobile malware.

 

In 2007-2008 FX publicly painted a number of scenarios in which QR codes could be used maliciously. We have since seen malicious QR codes that link to mobile malware.

The risk from such downloaded malware is still relatively low, as these are not drive-by downloads. Users would still need to choose to install the JAR or APK files on their smartphones. The risk from exploits, though, is one to worry about. An attacker who places a link to a modified Apple iOS jailbreak exploit or an Android root exploit can take over a victim’s device or steal sensitive information (emails, social network credentials, credit card numbers, etc.). 

As I told my two colleagues, there are a number of free QR code- and barcode-scanning apps with preview functions for both Android and Apple iOS. The following are my suggestions for safer QR code scanners:

 

Google Android

App	Author
Google Goggles	Google
Barcode Scanner	ZXing

Apple iOS

App	Author
Red Laser	Occipital/eBay
Bar-Code	Roberto Sonzogni

Protecting yourself from malicious QR codes and avoiding shock sites, mobile malware, and exploits doesn’t have to be too difficult.

• Use a mobile QR code-/barcode-scanning app that previews URLs
• Avoid suspicious URLs (for example, domains that don’t match ads, shortened URLs)
• Do not play “QR Code Roulette”

"Why Does My Car Have Its Own Smartphone?"

You would be surprised at the number of places you can find a GSM SIM card. Outside of your mobile phone, they can be found in power meters, water meters, vending machines, etc. These SIM cards (virtually identical to the one in your mobile phone) are used for machine-to-machine communication. Essentially all of these devices need to make mobile phone calls to other machines, usually for billing.

Machine-to-Machine Fraud/Theft of Service

Because it’s just machines talking to other machines, they don’t really need a voice plan and most if not all of their usage will be data. If the idea of “borrowing” the SIM card from the power meter outside your house for a few “free” downloads crossed your mind, you wouldn’t be the first. But consider the story of a woman in Tasmania who received a SIM card stolen from a power meter and used it to download movies for four months. She eventually destroyed the SIM card, yet the police tracked her down due to the large number of personal calls she had made with her mobile phone. She received six months in jail followed by two years of probation and was ordered to repay the power company nearly US$200,000 for all the data used.

Machine-to-machine SIM cards are generally identical to other SIM cards. Occasionally they may be smaller to be permanently installed in hardware. Credit: Giesecke & Devrient GmbH

Cars with Smartphones: Telematics, Diagnostics, and Attackers

Power meters aren’t the only devices that need their own smartphones. TV commercials by auto manufacturers show a man calling his wife, before her airplane takes off, to ask her to remotely unlock the doors of their car. Remote unlocking, engine starting, GPS/mapping, vehicle recovery, and crash assistance are features of what are known as telematics systems. Usually you would pay a monthly fee to the manufacturer to have access to all these features. In some cases you can get diagnostic output from car sensors emailed to you.

Crash assistance is usually handled by the car calling a center run by the manufacturer. In the movie “Live Free or Die Hard,” actor Justin Long portrays a computer hacker who social-engineers the call center agent into remotely starting the car. That was Hollywood; yet at the recent Black Hat USA conference, security researchers Don Bailey and Mat Solnik expanded on earlier research to locate and attack car telematics systems.

Their previous research involved using mobile phone databases to help in identifying and locating specific mobile phones. The new research involves using those same mobile databases to locate machine-to-machine devices. The researchers were able to determine a given device had a machine-to-machine SIM card because it would not answer a voice call. This is similar to war dialing, in which an attacker dials a block of telephone numbers until he locates a computer modem instead of a live person.

Bailey and Solnik also figured out that telematics systems used machine-to-machine SIM cards to dial home and provide most of their remote services. By fuzzing binary or system text messages, the “attackers” were able to determine which messages would allow them to remotely unlock and start a particular model of car. They were basically replicating what that man’s wife did in the commercial–just without authorization.  Fortunately they’re responsible researchers and not car thieves; they’re working with the car manufacturer to remedy this vulnerability.

These war-texting/text-fuzzing attacks aren’t the only ways to attack cars. The Center for Automotive Embedded Systems Security (CAESS), a joint venture of two universities, has demonstrated an attack involving inserting a CD with malicious (WMA) audio files into the stereo and taking over the automobile’s Engine Control Unit computer. The team succeeded in shutting down a running car by controlling the engine. Starting a car and shutting a car down remotely are both useful attacks, but they also managed to create a botnet that accepts commands and can exfiltrate data to the attacker using the machine-to-machine data connection.

As devices get smarter and more connected, we’re going to see more attacks targeted at them. The good news is that with researchers such as Bailey and Solnik we’ll be better prepared when these attacks eventually arrive.

"Fight the Urge to ‘Click Here to Get Infected’"

from McAfee blog:

Sometimes you can’t trust every link on your Twitter timeline. Yesterday, security researcher Stefan Esser tweeted the following:

Esser is the researcher who developed the Antid0te ASLR utility for jailbroken iPhones. If he helps to protect jailbroken iPhones, why would he want to infect me?

"Looking Into Google Wallet’s Security Setup"

from McAfee blog:

Google just announced its new near field communication payment service, Google Wallet. We’ve looked at Google’s NFC service and security before, but at that time the details were still scarce. Now we’ve gotten a better look at what lies within Google Wallet. It’s part service, part hardware, and part app.

 [...]

The App
The Google Wallet app plays a role in storing and accessing your credit card information from the “secure element”. Unlike with your credit cards, you need to enter a PIN to initiate a tap-and-pay transaction. This step prevents the bad guys from brushing by you in a crowd to grab your info via NFC.

Android apps are relatively easy to reverse-engineer, so that would probably be the first step an attacker would take. Google says that only authorized apps will have access to the “secure element” chip, and the chip uses asymmetric encryption to authenticate access to stored secrets (credit card credentials). This implies that an attacker has a good chance of extracting the authentication key from the Google Wallet app. The next step would be to create a malicious application that emulates the official Wallet app to fool the “secure element” chip into giving up your credentials. From here, the attacker can collect account information for sale or for attempts at cloning the data to new NFC cards.

The Google Wallet app has not yet been widely released, so it’s difficult to properly identify possible weaknesses. Once it’s available on more phones, we’re bound to see more research from both the criminal element and legitimate security researchers.

Google Tool Cleans Up Mobile Malware ‘Dream’

Over the weekend Google released the Android Market Security Tool to help clean up  devices infected with the DroidDream malware. The Android/DrdDream family of malware used a pair of exploits (Expoit/LVedu and Exploit/DiutesEx) to gain root access on vulnerable Android devices.  More than 50 Android applications were reported to be infected; all were pulled from the Android Market. The applications were all versions of legitimate programs that were repackaged by the malware authors with malicious code.

Android/DrdDream sends a collection of information (IMEI, IMSI, OS version, etc.) to the attacker and also attempts to download additional payloads. Although the malware uses the pair of root exploits, it doesn’t actually need root access to send the data to the attacker.

Inside the Android Market Security Tool

Google has its official statement on the the tool on the Android Market help site. They list a number of steps they’ve taken to remedy Android/DrdDream (“March 2011 Security Issue”):

• Suspending the developer accounts (three users) and removing the malicious applications from Android Market
• Remotely uninstalling the malicious apps from infected devices
• Pushing out the Android Market Security Tool to infected devices

Disabling accounts, taking apps out of the store, and hitting the remote-app kill switch were already well known ways for handling bad Android apps. Sending a security application to a phone is a whole new addition to the toolbox.

As a security researcher I find it interesting to see how new security tools are put together, more so when they come from an operating system developer. Normally I dig into the internals of malware; this time I got to see inside a mobile malware removal tool. Google’s security tool is available on the Android Market, so I was able to grab a copy for analysis.

The Android Market Security Tool is an Android app that also has a non-Dalvik native application component called droidreamclean. Android/DrdDream drops a few additional files (native binaries, an additional APK, etc.) on an infected phone. Because the files are located outside of the app directory, simply uninstalling the app won’t remove them from the phone. Really cleaning the phone requires access to the file system at a level that standard Android applications can’t reach. The security app  launches droiddreamclean to delete the additional files and restore some security settings.

The droiddeamclean binary deletes the second payload, DownloadProvidersManager.apk, downloaded by the Android/DrdDream malware. This prevents the malware from downloading additional malware or updates to the device.

After it gains root access, Android/DrdDream attempts to copy a second payload from its assets directory to the application directory (/system/apps/DownloadProviderManager.apk). This is a manual installation that completely bypasses the Android Market and because the Market doesn’t record the installation, it can’t be remotely killed. droiddreamclean doesn’t have this problem and instead tries a couple of uninstallation methods: using the “pm” package manager or manually deleting the APK.

The malware copies a renamed “su” executable (/system/bin/profile) to a directory of other system commands. This allows the attacker or updated malware to gain root access in the future. The Security Tool gives that executable the same treatment as the downloader component of Android/DrdDream.

In case the remote kill does not work, the security tool includes a list of apps that are removed using the command-line package manager. The Android/DrdDream authors definitely are not going to be able to slip one through.

A selection of the 58 packages removed by the Android Market Security Tool.

After droiddreamclean finishes, the Android Market Security Tool informs Google that your phone is now clean. It then uninstalls itself. At the end of all this, you get an email from Google telling you that it has removed the malware and that no issues remain.

Google informs you after the Android Market Security Tool finishes cleaning your phone.

Is the Android Market Security Tool enough?

The Android Market Security Tool is a pretty comprehensive tool, but it’s really designed only to clean up Android/DrdDream and its side effects. The tool itself doesn’t patch or reflash the operating system, so the vulnerabilities exploited by Android/DrdDream will remain. Updating the operating system will require help from the manufacturers of the various affected Android devices.

For similar infections, Google might have to follow the route that other security software takes and provide regular updates. The creation of the security tool and the work put into handling the Android/DrdDream issue shows that Google understands the need for mobile security software.

"Write Once, Mobile Malware Anywhere"

from McAfee blog:

"The Zeus (Zbot) crimeware is sold to criminals as a complete toolkit for building custom Trojans, usually to steal banking logins.  The Trojans are generally quite complex; injecting HTML into banking websites on the Internet Explorer and Firefox web browsers, intercepting keystrokes, and grabbing screenshots.  Until a few months ago the Zeus infrastructure targeted only Windows PCs, but the adoption of certain security measures (mTANs sent via SMS) used by some banks caused the criminals to change their tactics.

SymbOS/Zitmo.A was a mobile spyware application used to intercept and forward the mTAN SMS messages sent from an infected user’s bank to an attacker.  This was implemented by the Zeus Trojan for gathering information from victims about their mobile phones so that it could send a targeted download link to them.  The attacker could then change what numbers were monitored by the spyware to go after specific banks.  This particular group of crooks was using SymbOS/Zitmo.A in a targeted attack against Spanish banks.  It was suspected that a Blackberry version of the spyware was also being distributed, but no samples have yet been found."

[...]

Mobile Malware Benefiting From Virtual Machines?
The people behind Zeus are now targeting at least two, if not three, of the major smartphone platforms.  Writing for one smartphone platform can be challenging, writing for multiple devices can be a bigger headache.  By writing a malicious app for the .Net Common Language Runtime(CLR) and Compact Framework, the Zeus authors might be trying to take advantage of coding for virtual machines (VMs).

There are a number of benefits of using VMs for the malware author:

• maintaining compatibility
  
  • APIs on the VM will remain the same
    
• code reuse
  
  • working parts of the malware (SMS sending, Bluetooth transfers, etc.) don’t need to be rewritten
    
• affecting more devices/OS
  • malware can run on vastly different phones or devices

[...]

Alien Dalvik currently runs on a Nokia N900. Apps run at the same speed as on an Android phone with nearly identical specs. Credit: PRNewsFoto/Myriad Group AG

Given the availability of a common smartphone-based virtual machine (Dalvik on Android/Alien Dalvik on other OS) it would not surprise us if the Zeus authors eventually consolidated their mobile malware onto that single platform.  Instead of just “Angry Birds” one could also get the latest spyware or SMS Trojan.

"A ShmooCon Preview"

From McAfee blog:

It’s always tough to get a ticket for Washington D.C.’s ShmooCon hacker conference. Just over 1,200 tickets were available in three rounds of ticket sales for the January 28-30 event. It’s a sign of the conference’s popularity that each round sold out in under 10 seconds. At about a third of the size of a larger conference like Black Hat, it’s much easier to talk to the speakers without fighting with a crowd. Past years have had good presentations on mobile phone security and this year is no exception.

[...]

This year there are nearly twice as many smartphone-related talks as at last year’s Shmoocon. It looks like the start of an interesting year in smartphone and mobile threat research.