SIM card exploita9on. The SRLabs Team. SRLabs Template v12

Transcription

1 SIM card exploita9on The SRLabs Team SRLabs Template v12

2 SIM cards are fully programmable computer systems Applica'ons on modern SIM card Smartcard with real- 9me opera9ng system Basic func'ons Iden9fica9on (IMSI) Authen9ca9on (Ki & Hash func9on) Simple file system Address book SMS messages Session keys Java virtual machine Custom Java apps Roaming mgmt Payment Tracking 2

3 SIM security involves many layers from smartcards to cryptography and Java process separa9on SIM card includes various protec'on mechanisms User authen'ca'on by simple comparison SIM authen'ca'on by cryptographic hash func9on (omen Comp128 in GSM; Milenage in 3G/4G) A Secure Java deployment using DES/3DES/AES signature + encryp9on PIN/PUK numbers Ki OTA keys B Applica'on separa'on: Java VM sand boxing Individual protec9on logic for banking applets, iden9fica9on applets, etc. Storage protec'on through proprietary smartcard security mechanisms Java crypto API: DES/3DES/AES; some9mes RSA 3

4 Agenda SIM card background A GeDng on to the SIM B Stealing SIM secrets 4

5 OTA security level is chosen by server while SIM enforces mandatory minimum level ILLUSTRATIVE OTA server ini9ates remote transac9on Binary SMS communica'on Target app / key set # Command possibly encrypted and/or signed Used security level Response protected according to request, but not below minimum level stored on card Reque- sted security level SIM card stores mul9ple key sets, possibly with different protec9on levels Key set 1 Encry- p9on Signa- ture Key set 3 Key set 2 DES 3DES AES Man- datory ü 5

6 OTA error handling is underspecified, possibly opening adack surface Binary SMS communica'on AOacker probes cards to gain material for DES key cracking Command with wrong signature Use: DES signature Request: DES signature Response to mal- signed request differs by card type a. (25%* of cards) (No response) SIM card with DES key (prevalence of DES keys varies between operators; can be up to 100%) b. (50%*) c. (25%*) Error message Error message Some9mes with all- zeros signatures DES signature Data useable for key cracking * Es9mated from rela9vely small and geographically skewed measurement set 6

7 OTA DES do not withstand key cracking Challenge: Derive 56 bit DES key from OTA response signature Cracking strategies Investment Cracking 'me Be pa'ent Brute force on GPU EUR months Throw money at it Brute force on FPGA cluster EUR day Ride the rainbow Time- memory trade- off using large hard disks & GPU EUR year pre- computa9on Only possible when OTA response is fully predictable 1 minute (but <100% success rate) 7

8 Adacker SMS asks for DES- signed SMS response with fully predictable content Command packet is sent by the adacker to provoke response UDHI PID DCS 246 Adack- specific features UDH CPL CHL SPI KIc KID TAR CNTR PCNTR CC Data Packet Header No DES App 01 Padding Rand. length length cipher signature counter invalid No ciphering Sign PoR request Generic command Packet details: No ciphering Cryptographic checksum Do not cipher PoR Sign PoR Send PoR in any case Response packet may offer adack surface UDH RPL RHL TAR CNTR PCNTR Status Code CC Packet length Header length App 01 Padding counter Status Code Crypto- Checksum Data Response or No response Signature over predictable data useable for rainbow table key cracking 8

9 Pre- computa9on tables store DES code book in condensed form E233 K K K 2F06 503A OCFE DB18 K K K B951 CAF3 77CF 22CB K K K A8F3 CAF3 77CF Collision 87A4 K K K 49A6 118F B33F The uncondensed code book is petabytes in size. Tables provide a trade- off: Longer chains := less storage, but also longer adack 9me 9

10 Table op9miza9on: Rainbow tables mi9gate the effect of collisions E233 K 1 44B2 K 2 BBA8 K 3 1B22 Collision DB18 K 1 ODE3 K 2 44B2 K 3 5DE2 22CB K 1 6C7A K 2 55D2 K 3 922A K 1 K 2 K 3 87A4 11F6 362E C7D5 Rainbow tables have no mergers, but an exponen9ally higher adack 9me Source:c t 10

11 Video and live demo: Remotely cracking OTA key Video source: hdp:// Hack- exponiert- Millionen- SIM- Karten html 11

12 OTA adacks extend beyond DES signatures Many mobile operators responded to the looming SIM hacking risk considerate and faster than we could have wished for others (too?) quickly concluded they were not affected Recent operator statements We use encryp9on instead of signa- tures; the adack does not apply here Does it make sense? No. Encryp9ng a known plaintext with DES is as bad as signing it. Even when both are required, the adack s9ll applies (but needs two rainbow tables) We don t even use OTA No. virtually all SIMs are Java cards. Even if you are not using those capabili9es, an adacker may (and will probably find that you never cared to update the keys of this virtual waste land) We only use 3DES Maybe. 3DES is good, but have you made sure to use full entropy 112/168 bit keys instead of mul9ple copies of a 56 bit key? changed all the standard keys? heard of downgrade a*acks? 12

13 For some cards, even 3DES keys are crackable Downgrade aoack flow AOacker Crack first third of key Command Error Command Request DES- signed response (KID = 1) DES- signed Request 2- key 3DES response (KID = 5) Some SIM cards with 3DES key use lower signature schemes when requested (in viola9on of the standard) Crack second third* Crack final third* Error Command Error 2- key 3DES- signed Request 3- key 3DES response (KID = 9) 3- key 3DES- signed 2- key 3DES DES 56 bit 3- key 3DES 56 bit 56 bit * Must be brute- forced; Rainbow table adack no longer possible 13

14 Only some cards provide crackable plaintext- signature pairs Adacker sends OTA command with wrong DES signature reques9ng DES- signed response Cards responding with a valid DES signature are vulnerable CC length No response 0 Bytes 8 Bytes CC content All zero or other fixed padern Valid signature (random padern) DES crack No Yes DES downgrade No Yes Vulnerable Not to this adack No No No Yes Yes 14

15 Agenda SIM card background A Getng on to the SIM B Stealing SIM secrets 15

16 Java virus does not automa9cally have access to all SIM assets OTA- deployed SIM virus can access SIM Toolkit API Java sand box should protect cri'cal data on SIM Data access on SIM would enable further abuse Standard STK func'on Abuse poten'al Protected func'on Abuse poten'al Send SMS Premium SMS fraud Read Ki SIM cloning Decrypt all 2G/3G/4G traffic Dial phone numbers, send DTMF tones Circumvent caller- ID checks Mess with voice mail Read hash func'on Reverse- engineer proprietary authen9ca9on func9ons; perhaps find weaknesses Send USSD numbers Query phone loca'on and sedngs Open URL in phone browser Redirect incoming calls; some9mes also SMS Abuse USSD- based payment schemes Track vic9m Phishing Malware deployment to phone Any other browser- based adack Read OTA keys Read Java processes Write to Flash or EEPROM Lateral adacks Clone NFC payment takers and other future SIM applica9ons Alter OS to prevent vulnerability patching 16

17 Java VM on many SIMs fails to confine malicious applets Java virus may try to intrude on other parts of SIM Simplis9c memory boundary viola9on adempt: X = small_array[ ] X Java VM needs to enforce sandbox boundaries of each app Java VM enforces array boundaries and stops request Other Java programs and na've SIM func'ons store value secrets Data in SIM Ki Banking applets Iden9fica- 9on applets Abuse scenario SIM cloning: SMS/call fraud, Steal balance Impersonate More complex construct to violate memory boundaries (responsible disclosure with vendors ongoing) Java VM fails to detect viola9on &! processes request All secret informa9on on SIM is exposed to malicious applets through vulnerabili9es in several popular Java implementa9ons 17

18 Putng it all together Remote SIM cloning A Infiltrate card with malicious Java applet B Exfiltrate valuable data Ac'on Send binary SMS with OTA command to card, reques9ng card response Crack DES signing key, then sign Java virus & send through binary SMS Leverage gaps in Java VM memory separa9on to access arbitrary SIM card data Result Card may respond with a DES- signed error message Card installs and executes signed Java applet Malicious applet extracts Ki, banking applets, etc., and send to adacker via SMS 18

19 Wide- scale SIM hacking risk must be mi9gated on several layers Mi'ga'on layer for OTA hacking risk Effec'veness Cost Low High Filter OTA messages from unapproved sources Prevents probing in home network; leaves SIMs exposed when roaming, to fake base sta9ons, and to phone malware Func9onality readily available in most SMSCs Network operators short- term mi9ga9on op9on Deac9vate OTA on card Prevents adack (but also any future use of OTA w/ DES key) Can be done through SMS Use 3DES or AES OTA keys Use cards that do not disclose crypto texts Filter suspicious messages on phone base band Prevents adack (expect for where downgrade adack works) Prevents the adack Prevents the adack Some cards need replacing, others updates Some cards need to be replaced New somware func9on for future phones Network operators mid- term mi9ga9on op9on Complimentary mi9ga9on op9on for phone manufacturers 19

20 OHM 2013 workshops confirm vulnerability and point to next issues Signature disclosure Cards s9ll disclose signatures even though: Many cards got patched over last 2 weeks OHM par9cipants use newer SIM cards than average 23% 29% Key entropy is low (measured at OHM) OTA DES key Entropy b ~16bit ~24bit 11% 2cee ae0a6 ~44bit aa7890c234aeee28 ~50bit Signature- disclosing cards in research set Cards affected in OHM sample (14 countries) 96a6141aaa5ef0ee ~52bit 20

21 Industry response was encouraging for responsibly disclosing hacking research The responsible disclosure went surprisingly well and is worth men9oning We disclosed several months ahead of the release to trusted contracts made around previous releases Experts from a few large companies verified the results and created best prac9ce responses Industry associa9ons disseminated guidelines to all other operators Many networks are now well underway implemen9ng filtering and reconfiguring cards Only a single lawyer stumbled into the interac9on, but quickly lem Take aways from a number of responsible disclosure that all went well (except for one) Find construc've partners in the industry; ask other hackers for their recommenda9ons Disclose early and don t be surprised if even the most mo9vated disclosure partner takes months to distribute the informa9on confiden9ally in their industry Bring someone with disclosure experience to mee9ngs Expect friendliness and remind your partner of the required e9quede should they ever act rude or arrogant Help your technical contacts win the internal badles: Refuse to speak to their lawyers; never sign an NDA prior to your disclosure Be extremely careful accep9ng money; and only ever to help with mi9ga9on 21

22 Take aways A Some DES- secured SIM- cards allow for remote key cracking and applet installa9on B Java vulnerabili9es enable adacker to remotely extract Ki, banking applet data Mi9ga9on op9ons exist on network, baseband, and SIM card level Ques9ons? Karsten Nohl <nohl@srlabs.de> 22