Trojan Malware for BlackBerry Devices OttSec – July 6 2009

1. Trojan Malware for BlackBerry DevicesOttSec – July 6 2009 By 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 Log PhoneLogs _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 smaller for (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 NATHOO Principal Consultant e:knathoo@inverselabs.com p:613.293.3076 f:888.255.4240 www.inverselabs.com