1. Trojan Malware for BlackBerry Devices OttSec – July 6 2009 By Karim Nathoo

2. [2][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. [3][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. [4][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. [5][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.) –3 rd 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. [6][6] Trojan Attack Path RIM aggressively marketing 3 rd 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. [7][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. [8][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. [9][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. [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. [11] RIM Code Signing Keys Order Form

12. [12] Getting Code Signing Keys 1 st 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 2 nd 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 3 rd 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 4 th 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. [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. [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. [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. [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. [17] Example: End User Prompting for GPS

18. [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. [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. [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. [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. [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. [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. [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. [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. [26] KARIM NATHOO Principal Consultant e:knathoo@inverselabs.com p:613.293.3076 f:888.255.4240 www.inverselabs.com