Your SlideShare is downloading. ×
Hacking JME platform by example / 0wned by MoMo
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Hacking JME platform by example / 0wned by MoMo

744
views

Published on

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

Presentation held by me on Mobile Monday Tartu event on 07. September 2009.
http://www.momoestonia.com/2009/09/thank-you-for-superb-opening-slides-and.html

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
744
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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