Trojan Malware for BlackBerry Devices

OttSec – July 6 2009By Karim Nathoo

[2]

Agenda

• Context about “exercise” and constraints• Motivation for attacking BlackBerry handsets• Potential Handset Attack Surfaces• Trojan Attack Path• Code Signing• Trojan Infection Vectors• Ex-filtration / Command & Control channel

options • Covertness• BlackBerry development environment• Proof of concept demo• Botnet potential• Future Work?

[3]

The Exercise

• Exercise performed in September 2008• Explore ways a BB handset could be

compromised• Specific target was a BB Curve 8310 on Rogers• Had about a week to spend on research and

developing proof of concept• Primary Goal - raise awareness about smart

phone threats for a security awareness day event• Secondary Goal - justify recommendations made

in various security assessments to disable various BB features using a proof of concept demo

• Not everything worked as originally expected• Started with some basic threat modelling

[4]

BB Handset Attack Motivation

“Put more of your life on your BlackBerry smartphone” – RIM website

• Handset Resident Information Assets:– Address Book– Phone History– E-mails– Personal notes, tasks, appointments– Removable memory– Browser history, cookies, cache

• Surveillance– Location Based Surveillance (GPS)– Camera– Microphone

• Multiphase Attack– For BES managed handsets, attack corporate network the handset is

bound to (see BBProxy)– Botnet: SPAM, DDOS

[5]

Potential Attack Surfaces

• Handset has a large potential attack surface:– Bluetooth– Removable Memory– Data network – WiFi– GPS– Browser– SMS– BlackBerry Messenger– PIN – PIN messaging– General client side application vulnerabilities (image

rendering libraries, document parsing vulnerabilities, etc.)– 3rd Party Applications

• BlackBerry Enterprise Server/Carrier compromise– BES/Carrier can push application code down to handsets

without user intervention– Wanted to focus on the handset and users

[6]

Trojan Attack Path

• RIM aggressively marketing 3rd party apps, creation of the BB app store in March 2009

• RIM provides developer tools to create Java apps that run in the handset resident JVM

• Installed Java apps have access to most important handset functionality (SMS, e-mail, GPS, phone, camera, ….. )

• Create some malicious BB apps and distribute them

[7]

Trojan Attack Path - Negatives

• Require some social engineering to get users to install application

• Code Signing Requirement for applications to run on handset

• For BES managed handsets, many organizations prevent users from installing apps (although some don’t)

[8]

Trojan Attack Path - Positives

• Provided the code is signed, most of the interesting functionality/assets of the handset will be available

• Coding of Trojan app to run in JVM much simpler than code to identify and exploit an implementation vulnerability

• Java based Trojan code portable across handsets, exploit code may be very target specific if it exploits a firmware/OS level vulnerability

• Highly vulnerable consumer segment is rapidly expanding

[9]

Target Rich Environment for Trojans

• Growth in unmanaged consumer handsets (not locked down by BES policy)– RIM aggressively growing consumer (versus

Enterprise) market through consumer targeted devices/features

– 3.8 million new subscribers added in first quarter 2009 (up 65% year over year)

– 70% of new subscribers are unmanaged consumer handsets and are not managed by BES policy

– 28.5 million BlackBerry subscribers as of May 30 2009

– 50% of overall subscriber base is unmanaged consumer

[10]

Code Signing

• Application code needs to be signed before it will run on a handset– Exceptions are applications that do not use

any “sensitive” handset functionality– In practice, most useful code needs to be

signed– RIM states code signing is to “track use of

sensitive API’s for security and export control reasons”

– Not clear what implications are of code signing keys being revoked

• Further apps can not be signed• Existing apps disabled?

[11]

RIM Code Signing Keys Order Form

[12]

Getting Code Signing Keys• 1st Attempt (Success)

– Applied using my true identity – Incorporation records exist since it is a real company (although only 1 person

and no website)– A valid company but no indication I should be writing BB apps– Used valid credit card

• 2nd Attempt (Success)– Created a fictitious company and registered domain and e-mail address– Not a real company, no incorporation or similar business records exist– Used valid credit card not matching “signer” identity

• 3rd Attempt (Fail)– New fictitious company created same as above– Used a pre-paid credit card– Received a payment error– Seemed related to pre-paid card brand and not verification of company info

• 4th Attempt (Success)– Applied using Gmail address and fake company and contact name

• Conclusions: – Just need a valid credit card to pay $20 fee– Credit card identity does not have to match “signer” identity– Code signing keys delivered in 2-3 days

[13]

Development Environment

• Support for Java ME MIDP standard, with some RIM proprietary extensions for interfacing with BB specific functionality

• Phone functionality and information stores modeled as Java classes

• Event driven programming model• Coding is high level and easy, not like

coding firmware• Learning curve minimal, just a couple of

days for me as a Java novice• Lot’s of sample code provided by RIM

[14]

Example: Access Phone Call LogPhoneLogs _logs; PhoneCallLogID participant;PhoneCallLog phoneCallLog;

_logs = PhoneLogs.getInstance();int numberOfCalls = _logs.numberOfCalls(PhoneLogs.FOLDER_NORMAL_CALLS); // KN - Put a maximum cap on number of calls at 10 to make ex-filtrated message smallerfor (int i =0; i < numberOfCalls && i < 10; i++) { Object o = _logs.callAt(i, PhoneLogs.FOLDER_NORMAL_CALLS); if (o instanceof PhoneCallLog) { phoneCallLog = (PhoneCallLog) o; participant = phoneCallLog.getParticipant(); sb.append("Phone Number: "); sb.append(participant.getAddressBookFormattedNumber()); sb.append("Caller ID: "); sb.append(participant.getName()); sb.append("Call Duration: "); sb.append(phoneCallLog.getDuration()); sb.append("Call Date: "); sb.append(phoneCallLog.getDate().toString()); } }

[15]

Useful Features for Malware

• Event Listeners– Register some code that will get called when an event occurs on the

handset: e-mails, phone calls, SMS, …– Register a listener, wait for event, do malicious processing, then let

system proceed as normal– Allows for “delta” state changes to be reported to collection point

• Example: don’t ex-filtrate entire call history, just do it for the new events as they come in

– Can use for a stealthy ex-filtration scheme• Only do ex-filtration when there is other traffic such as e-mails being

sent/received, phone calls in progress, etc– Malware just sits in background while waiting for interesting events

to occur• Auto Start

– Can start your application in the background when handset turns on– Options for background threads that register listeners– Can specify application as “system module” without GUI– Auto start application can function as an “alternate entry point” and

start another application when handset turns on

[16]

End User Prompting

• Some application functionality will require end user to accept on first access:– GPS– SMS– Phone logs– …

• End user prompts contain vendor name– Vendor name specified in application install package– Vendor name can be set to anything, not bound to the

identity of the signing key– This weakness helps in social engineering aspect of attack

• Surprisingly, some functionality does NOT require end user to accept:– Access to e-mail store– BB messenger– …

[17]

Example: End User Prompting for GPS

[18]

End User Prompting Workarounds

• Depending on level of access required, Trojans may need to “tell” a good story

• GPS Example– Set Vendor Name to known GPS vendor in application

package– A search of Google revealed several legitimate

BlackBerry apps that use GPS:• Golf GPS• Trip Computer/Mileage Tracker• Restaurant finder• Google Maps• AAA travel guides/emergency assistance

– Make sure the Trojan app has some functionality that would legitimately require GPS access

[19]

Ex-filtration Options• Ex-filtration/Command Control Channels:

– SMS• Covertness issue, billing charges, per number granularity on bill, message size

limitation, may get around lack of data plan as SMS uses voice network– Bluetooth

• Range limitations, pairing limitations– Data network (generic IP type sockets supported)

• User prompting– PIN-PIN messaging

• Flexibility, did not want collection point to have to be BB device and did not want to implement emulator

– BlackBerry messenger• Flexibility, did not want collection point to have to be BB device and did not want to

implement emulator– Phone

• Covertness issue, billing charges, per number granularity on bill, not straightforward for data

– E-mail• No user prompting, no billing granularity, but not as flexible as data network in

automatic scripting/parsing of responses from target

• Within each of the “channels” there are additional levels of sophistication affecting covertness – “all at once”, “piggy backed”, etc

[20]

Trojan Infection Vectors

• Over the air – make available on any website– Set content-type appropriately– Victim surfs to website using hand held and

installs software• BlackBerry Desktop Manager

– Create .alx “wrapper file” that points to byte code files

– Install using BlackBerry Desktop manager through a USB connection with PC

• BlackBerry AppStore– Launched November 2008– Similar to iPhone AppStore

[21]

Proof of Concept

• Tic Tac Toe Game– Used sample application source distributed by RIM as starting point – Retrofitted with malicious code, re-built and signed the application

using my signing keys• Uses e-mail as the covert channel

– Once the user plays the game, information ex-filtrated to an anonymous Gmail address serving as the collection point

• Ex-filtrated data:– Target phone number– Phone call history including phone numbers– E-mail messages residing on target handheld– GPS co-ordinates

• Continuous surveillance– Trojan code turns on device GPS– Attempts to send GPS co-ordinates on first contact– Send location update every 1 minute if within satellite coverage– Will handle situations where subject goes dark and then re-appears

[22]

Proof of Concept Weaknesses

• Social engineering improvements necessary (GPS)

• Does ex-filtration all at once, too much visual indication of traffic

• Don’t clean up sent messages (this was to help debug)

• Doesn’t effectively use auto-start, background thread processing

[23]

BlackBerry Botnet?

• How do we make money?– Probably needs to be a profit capability before Botnet appears

• Potential SPAM Bot– No user prompting for e-mail store accessing and sending, could be

fairly covert– Trojan could be programmed to receive SPAM messages from

controller and then send them out through handset at regular intervals

– Potentially create inbox folder listener to listen for commands from Botnet controller

– Potential for being discovered if data billing gets too out of control• DDoS Bot?

– Bandwidth limitations?• Realistic?

– 28.5 million BlackBerry subscribers and growing, 50% are vulnerable unmanaged consumer devices vs. enterprise devices

– As smartphone adoption increases, Botnet potential increases

[24]

Future Efforts?

• BB AppStore– Investigate nature of verification for apps submitted to app

store• Reverse Engineer, Patch, Re-Sign existing apps?

– Ability to create sophisticated Trojans based on real commercial grade apps versus “Tic Tac Toe”

• Covertness Improvements• Interprocess Communication Vectors

– Get Trojan app to communicate with and attack/mis-inform other apps using built in IPC primitives

• Investigate possibility of using event listener system for general purpose utilities such as keystroke, traffic loggers

• Discovery of new infection vectors– Significant effort, would involve stressing/fuzzing attacker

accessible interfaces and finding exploitable vulnerabilities

[25]

Future Efforts?

• BlackBerry Enterprise Server/Carrier compromise– Not feasible within parameters of my

exercise, so was not investigated– BES/Carrier can push application code

down to handsets without user intervention

– Wanted to focus on the handset and client side compromise, but server side compromise is an interesting attack vector

[26]

KARIM NATHOOPrincipal Consultant

e:knathoo@inverselabs.comp:613.293.3076f:888.255.4240

www.inverselabs.com