Hacking JME platform by example / 0wned by MoMo


Published on

Presentation held by me on Mobile Monday Tartu event on 07. September 2009.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Hacking JME platform by example / 0wned by MoMo

  1. 1. Hacking JME platform by example 0wned by MoMo Sven Kirsimäe [email_address]
  2. 2. [why hack a phone] <ul><li>“ You can tell what a culture values by what it has in its bags and pockets” John Agar, “Constant Touch: A Global History of the Mobile Phone” </li></ul><ul><li>billions of mobile phone users </li></ul><ul><li>sometimes the only way of personal private communication </li></ul><ul><li>mobile internet communication is rising </li></ul><ul><li>becoming a tool for payments </li></ul><ul><li>many old “broken” devices still around </li></ul>
  3. 3. [publicly known issues] <ul><li>april, 2004 “Siemens S55 SMS Send Prompt Bypass Weakness” </li></ul><ul><ul><li>Overlay the prompt with more “user friendly message” </li></ul></ul><ul><li>2004, Adam Gowdiak, Poland “Insufficient validation of bytecodes in the bytecode verifier component” </li></ul><ul><ul><li>confirms on his Nokia 6310i </li></ul></ul><ul><ul><li>took him 4 months </li></ul></ul><ul><ul><li>no details revealed </li></ul></ul><ul><li>2008, he claims 0wning all Nokia S40 devices </li></ul><ul><ul><li>able to take full control of the device: phone calls, networking, recording audio and video, accessing address book and file system, etc. </li></ul></ul><ul><ul><li>6 months of research </li></ul></ul><ul><ul><li>no details revealed - 20,000EUR for the full report and source </li></ul></ul>
  4. 4. [patching the issues] <ul><li>update the JVM = update the firmware </li></ul><ul><li>update hundreds of thousands of devices </li></ul><ul><li>“ Over the wire firmware update” come again? </li></ul><ul><li>renewing mobile hardware is more feasible for a general case </li></ul><ul><ul><li>every year or two </li></ul></ul><ul><ul><li>is the new phone patched? </li></ul></ul>
  5. 5. [MIDlet JVM security constraints] <ul><li>low-level VM security </li></ul><ul><ul><li>rejecting ill-formed or maliciously-encoded application </li></ul></ul><ul><ul><li>two-phase verification: off- & on-device class file verification </li></ul></ul><ul><ul><li>missing custom class loaders </li></ul></ul><ul><li>application-level security </li></ul><ul><ul><li>user prompts, application signing </li></ul></ul><ul><ul><li>access only allowed libraries and system resources </li></ul></ul><ul><ul><ul><li>file system, printers, infrared devices, native libraries, the network </li></ul></ul></ul><ul><ul><li>no native functions or direct access to the existing ones </li></ul></ul><ul><ul><li>no reflection , no finalization </li></ul></ul><ul><ul><li>no overriding or extending the set of system or manufacturer specific classes found in </li></ul></ul><ul><ul><ul><li>java.* ; javax.microedition.* ; com.sun.* com.nokia.* ; com.samsung.* </li></ul></ul></ul>
  6. 6. [hints on breaking JVM constraints] <ul><li>read the source </li></ul><ul><ul><li>phoneME – reference implementation of the MIDlet JVM + JSRs </li></ul></ul><ul><ul><li>manufacturer APIs – decompile and read </li></ul></ul><ul><ul><li>emulators/SDKs provide list of manufacturer classes </li></ul></ul><ul><li>try to break the specification constraints </li></ul><ul><ul><li>buffer overflows on internal data structures </li></ul></ul><ul><ul><li>bytecode manipulations on off-device verified code </li></ul></ul><ul><ul><li>cheating the on-device verifier </li></ul></ul><ul><ul><li>typing on behalf of the user </li></ul></ul><ul><ul><li>hiding the prompts – threading? </li></ul></ul><ul><ul><li>search for hidden system classes </li></ul></ul><ul><ul><li>accessing the system classes </li></ul></ul><ul><ul><li>call the native methods from the application </li></ul></ul><ul><li>don’t emulate! </li></ul><ul><li>takes time to have something </li></ul><ul><li>non of the “heavy breaking” is required for our today’s demo </li></ul>
  7. 7. [SMS without permission] <ul><li>some Samsung devices discard the official specification requirements for the security </li></ul><ul><li>application is able to gain access to the manufacturer specific “protected” classes </li></ul><ul><li>access enables to change the internal logic of the “protected” classes </li></ul><ul><li>a vulnerability enables to send SMS from the MIDlet application without the user’s confirmation </li></ul><ul><li>affects: </li></ul><ul><ul><li>targeted audience – the SMS-generation </li></ul></ul><ul><ul><li>premium SMS </li></ul></ul><ul><ul><li>malicious applications can be envisioned by anyone… </li></ul></ul>
  8. 8. [affected devices] <ul><li>~ 5- 10% ( GetJar/ AdMob, Feb. 2009), ~130 devices (J2ME Polish) , 3rd after Nokia and Sony-Ericsson. </li></ul><ul><li>Confirmed on Samsungs </li></ul><ul><ul><li>D500 (Q4, 2004) </li></ul></ul><ul><ul><li>Z500 (Q1, 2005) </li></ul></ul><ul><ul><li>D600 (Q1, 2005) </li></ul></ul><ul><ul><li>E500 (Q2, 2006) </li></ul></ul><ul><ul><li>E250 (Q4, 2006) </li></ul></ul><ul><ul><li>D900i (Q1, 2007) </li></ul></ul><ul><li>Potentially affected: E730, E760, T509, X700, T809, E340, E360, E370, Z140, Z150, Z230, Z300. </li></ul><ul><li>All devices are: CLDC 1.1, MIDP 2.0 and JSR 120 (Wireless Messaging API). </li></ul>
  9. 9. [why i did it] <ul><li>was just reading around the JME implementation source </li></ul><ul><li>geekiness kicked in </li></ul><ul><ul><li>2 weeks of not sleeping </li></ul></ul><ul><li>no HTTP in the similar way </li></ul><ul><ul><li>but what about SMS-in? </li></ul></ul><ul><li>Samsung has been notified in 02.2007 </li></ul><ul><ul><li>brief response acknowledging the issue </li></ul></ul><ul><ul><li>release of confirmed D900i </li></ul></ul>
  10. 10. [are they critical] <ul><li>needs human factor for the malicious program to reach and run on the device </li></ul><ul><li>fragmentation of the devices = potential flaw cannot reach many devices </li></ul><ul><li>phones are getting more open (smartphones) </li></ul><ul><li>rare exploitations can be quite costly for the end-user </li></ul><ul><li>T he most effective phone hacking can still be </li></ul><ul><li>“ stealing the phone” ;) </li></ul>