Downloaded 195 times
Uploaded byPositive Hack Days
Mobile Network Attack Evolution
This document summarizes the evolution of attacks against mobile networks and industry responses. It discusses past attacks against SIM cards, including cracking DES keys using error responses. More advanced SIMs are fully programmable computers running Java with various security layers, but some still have crackable cryptographic keys. The talk will cover SIM attacks, GSM intercept techniques, and efforts to ensure network operator honesty.
More Related Content
Similar to Mobile Network Attack Evolution
Mobile Network Attack Evolution
- 1. SRLabs Template v12 Mobile Network A9ack Evolu=on Karsten Nohl <nohl@srlabs.de>
- 2. Security research is successful if vulnerabili=es get removed 2 Industry assesses impact and implements counter measures Security researchers discover new vulnerability classes (and some=mes mi=ga=ons) This talk focuses on the industry response to mobile network security research
- 3. Agenda 3 § Advanced SIM card a<acks § Advanced GSM intercept § Keeping network operators honest
- 4. SIM cards are fully programmable computer systems 4 Applica=ons on modern SIM card Basic func=ons § Iden=fica=on (IMSI) § Authen=ca=on (Ki & Hash func=on) Simple file system § Address book § SMS messages § Session keys Custom Java apps § Roaming mgmt § Payment § Tracking Java virtual machine Smartcard with real-‐=me opera=ng system
- 5. SIM have many security layers from smartcards to cryptography and Java process separa=on 5 by cryptographic hash func=on (oVen Comp128 in GSM; Milenage in 3G/4G) User authen=ca=on by simple comparison Secure Java deployment using DES/3DES/AES signature + encryp=on SIM authen=ca=on Individual protec=on logic for banking applets, iden=fica=on applets, etc. … Java crypto API: DES/3DES/AES; some=mes RSA Applica=on separa=on: Java VM sand boxing SIM card includes various protec=on mechanisms Ki PIN/PUK numbers OTA keys through proprietary smartcard security mechanisms Storage protec=on
- 6. OTA security level is chosen by server while SIM enforces mandatory minimum level 6 ILLUSTRATIVE OTA server ini=ates remote transac=on Binary SMS communica=on Response protected according to request, but not below minimum level stored on card SIM card stores mul=ple key sets, possibly with different protec=on levels Key set 1 Key set 2 Key set 3 Encry-‐ p=on Signa-‐ ture DES 3DES AES Man-‐ datory ü Command – possibly encrypted and/or signed Used security level Reque-‐ sted security level Target app / key set #
- 7. OTA error handling is underspecified, possibly opening a9ack surface 7 A<acker probes cards to gain material for DES key cracking SIM card with DES key (prevalence of DES keys varies between operators; can be up to 100%) Binary SMS communica=on Command with wrong signature Use: DES signature Request: DES signature Response to mal-‐signed request differs by card type c. (25%*) b. (50%*) a. (25%* of cards) (No response) Error message DES signature Error message Some=mes with all-‐zeros signatures Data useable for key cracking * Es=mated from a geographically skewed measurement set
- 8. OTA DES do not withstand key cracking 8 Challenge: Derive 56 bit DES key from OTA response signature Cracking strategies Investment Cracking =me Be pa=ent Brute force on GPU EUR 1.000 6 months Throw money at it Brute force on FPGA cluster EUR 50.000 1 day Ride the rainbow Time-‐memory trade-‐off using large hard disks & GPU EUR 1.500 + 1 year pre-‐computa=on 1 minute (but <100% success rate) Only possible when OTA response is fully predictable
- 9. For some cards, even 3DES keys are crackable 9 Downgrade a<ack flow Some SIM cards with 3DES key use lower signature schemes when requested (in viola=on of the standard) * Must be brute-‐forced; Rainbow table a9ack no longer possible A<acker Command Request DES-‐signed response (KID = 1) Error DES-‐signed Command Request 2-‐key 3DES response (KID = 5) Error 2-‐key 3DES-‐signed Command Request 3-‐key 3DES response (KID = 9) Error 3-‐key 3DES-‐signed 56 bit 56 bit 56 bit Crack first third of key Crack second third* Crack final third* 3-‐key 3DES 2-‐key 3DES DES
- 10. Java virus does not automa=cally have access to all SIM assets 10 Java sand box should protect cri=cal data on SIM OTA-‐deployed SIM virus can access SIM Toolkit API Standard STK func=on Abuse poten=al Send SMS § Premium SMS fraud Dial phone numbers, send DTMF tones § Circumvent caller-‐ID checks § Mess with voice mail Send USSD numbers § Redirect incoming calls; some=mes also SMS § Abuse USSD-‐based payment schemes Query phone loca=on and seUngs § Track vic=m Open URL in phone browser § Phishing § Malware deployment to phone § Any other browser-‐based a9ack Data access on SIM would enable further abuse Protected func=on Read Ki Read OTA keys Read Java processes Write to Flash or EEPROM Abuse poten=al § SIM cloning § Decrypt all 2G/3G/4G traffic § Lateral a9acks § Clone NFC payment takers and other future SIM applica=ons § Alter OS to prevent vulnerability patching Read hash func=on § Reverse-‐engineer proprietary authen=ca=on func=ons; perhaps find weaknesses Possible on some SIMs due to bug in their Java VM
- 11. SIM security research mo=vated some technology upgrades 11 Security researchers published several SIM card a<acks Industry reacted swiVly but not thoroughly Finding Anybody can send management SMS to SIM cards 1 Many networks started filtering the most obvious a9ack messages The OTA app mgmt interface is not always protected with good crypto 2 Some operators phased out DES keys in favor of 3DES SIM applica=ons can break out of their JavaCard sandbox 3 The vulnerability has not been addressed yet in affected cards Response
- 12. 12 1 Best prac=ce filters Imple-‐ mented filters Several message types may go to the SIM Some phones also forward other types Many networks only filter one type Binary SMS can take many forms to circumvent filters SMS field PID DCS UDHI User data 127 * * * * 246 or 22 * * * * 1 027000… 127 * * * * * 0 027000… vs.
- 13. Misconfigura=ons in SIMs go well beyond DES keys 13 ILLUSTRATIVE 2 2. Verify that all SIM applica=ons enforce cryptography 1. Verify that all keys are 3DES or AES Applica=on (TAR) Keyset 1: 3DES 2: 3DES … 16: DES Sign + encrypt Sign + encrypt Sign 000000 Unprotected (MSL=0) Sign Sign 000001 FFFFFF … … … … SIM configura=ons need to be assessed in two dimensions
- 14. A9ack example– Persistent infec=on of modern SIM card 14 Target — New nano-‐SIM (October 2013) in iPhone 5s from major European carrier A<ack steps A B D C Lure the phone onto fake base sta=on to circumvent network filters Scan the SIM remotely for configura=on issues (on the SIM in this demo: discover TAR with MSL=0) Install Java virus through vulnerable TAR Let phone connect back to normal network, maintain persistent access through SMS-‐C&C
- 15. Self-‐assessment tool: Find bugs in your SIM card’s configura=on 15 § Find cryptographic a9ack surface: – Signature disclosure – 3DES downgrade § Enumerate logical a9ack surface: Detect hidden applica=on TARs and test their security level § Upload traces to gsmmap.org for further analysis (Thank you.) Tool name Purpose Requirements Source SIMtester PC/SC smartcard reader –or– Osmocom phone opensource.srlabs.de
- 16. Agenda 16 § Advanced SIM card a9acks § Advanced GSM intercept § Keeping network operators honest
- 17. GSM intercept a9acks are s=ll under addressed 17 To protect customers, mobile networks must support and harden two encryp=on standards The majority of mobile phone calls worldwide s=ll uses 2G GSM frequencies Older phones only support A5/1 encryp=on Protec=on status: Available strengthening measures are rarely seen 1 A5/3 protects much be9er Protec=on status: S=ll only a minority of networks support A5/3 2
- 18. A5/1 decryp=on can mostly be prevented through randomiza=on ! ! Features!to!decrease!cryptographic!attack!surface! Example!call!setup!trace! Unprotected!! Padding!randomization! +!SI5!randomization! Ciphering)Mode)Cmd) ) ) ) TMSI)Reallocation)Cmd) ) ) ) Null)Frame) ) ) ) System)Information)5) ) ) ) Call)Proceeding) ) ) ) System)Information)6) ) ) ) Null)Frame) ) ) ) Fragment) ) ) ) Assignment)Command) ) ) ) System)Information)5ter) ) ) ) ) Predictability, , High, , Medium, , None,(secure), , Not,ciphered, , 18 1
- 19. A5/3 makes intercept much harder, but decryp=on is s=ll possible for well-‐funded spy agencies 19 Speed Success Rate Cost A5/1. One computer with 2TB storage decrypts short transac=ons (SMS) with 95% success in 1s (aggregated) A5/3. 400 computers break one 1-‐minute call per minute with 50% success Challenge: A5/3 decryp=on is computa=onally two million =mes more difficult 2
- 20. Agenda 20 § Advanced SIM card a9acks § Advanced GSM intercept § Keeping network operators honest
- 21. You can help: Measuring mobile network security from Android or Linux 21 Tool name GSMmap.apk xgoldscanner OsmocomBB Purpose Collect network traces on Android phone and upload for analysis to gsmmap.org Record network traces for analysis in Linux Update to Sylvain’s burst_ind setup to capture network traces for analysis in Linux Requirements Rooted Samsung Galaxy S2/S3 An older Motorola phone (C123, …) Samsung Galaxy S2, S3, Note 2, or Nexus Source opensource.srlabs.de OsmocomBB git: gsmmap branch Google Play: GSMmap
- 22. Live ISO puts mobile security tools on ready-‐to-‐use USB s=ck 22 GSM map live ISO bundles mobile security tools Network measurement with Galaxy S2/S3 Network measurement & IMSI catcher detec=on with Osmocom BB phone SIM card assessment with PC/SC reader or Osmocom BB phone Download and How-‐Tos opensource.srlabs.de
- 23. gsmmap.org – Tracking mobile network evolu=on online 23
- 24. Thank you! Ques=ons? 24 Karsten Nohl <nohl@srlabs.de> Many thanks to Lukas Kuzmiak, Luca Mele<e, and Linus Neumann for crea=ng and suppor=ng our research tools! Research supported by