Nethemba public security projects 2007-2015

Pavol Lupták, Nethemba s.r.o.

Who Am I?

• Long time IT security specialist with many certifications
• Founder of IT security company Nethemba focused on ethical hacking and penetration testing
• Founder of the initiative www.nepracujemeprestat.sk ("we do not work for the government") because of many ethical and economical reasons
• Co-founder of hackerspaces in Bratislava (Progressbar) and Prague (Paralelni Polis)
• Cryptoanarchist with a belief that crypto technologies can significantly enhance our freedom
• Member of controversial group Czech artistic group Ztohoven

Our reasons & motivations

• Since 2007 when Nethemba was started, we have begun to focus on public research projects.
• One of the reasons was that we were aware of a lack of security in technologies most people use daily, the second one, was a need of being different compared to our IT security competition, especially in Czech and Slovak republic.
• During the period 2007-2015, we published many security-related articles, blogs, and papers. We would like to discuss the most important ones with the considerable impact

Noteworthy projects

1. SMS public transport ticket vulnerabilities

2. Mifare Classic vulnerabilities and implementation of Mifare Classic Offline Cracker

3. SMS parking ticket vulnerabilities

4. Security analysis of Slovak and Czech NFC

   payment cards

SMS public transport ticket vulnerabilities I - basics

• SMS request with a predefined body (e.g.“DPT”) is sent to a predefined number
• a unique SMS response (as a valid SMS ticket) is received in a few minutes:

• Public Transport Company ABC, SMS ticket Price XYZ, Validity: from 28.10.07 13:20 to 28.10.07 14:50, code YrQPtMKs7 /52845

• possibility to request for a duplicate if the SMS ticket is accidentally deleted or mobile phone is out of battery

SMS public transport ticket vulnerabilities II - Who is vulnerable?

• the biggest public transport companies in  Czech Republic, Slovakia, Poland and Austria
• despite the fact that public transport companies have already been informed about this serious vulnerability, they ignore this fact and still use  the vulnerable systems
• we have no information if there are some public  transport SMS tickets that are not vulnerable to  this kind of attacks

SMS public transport ticket vulnerabilities III - Looking for security problems

• SMS token (YrQPtMKs7 / 52845) seems to be sufficiently random and hardly predicted
• the inspector uses his PDA for online verification
• BUT: there is NO connection between user's identity and his SMS ticket's identity, therefore SMS ticket can be SHARED by community
• legislatively it is prohibited to generate and distribute copies of SMS tickets but currently there is NO WAY to detect these duplicates

SMS public transport ticket vulnerabilities IV - Let's go hack!

• SMS generation (an arbitrary SMS message can be locally generated on any smartphone)
• SMS distribution
  • ​SMS channel – too expensive, impossible to modify SMS headers (sender,  recipient, status­flag)
  • TCP/IP - very cheap (short SMS ticket requests/responses) – need of prepaid mobile data service – need of intelligent phone that is capable to generate  local SMSes (any smartphone)

SMS public transport ticket vulnerabilities V - Architecture

Text

SMS public transport ticket vulnerabilities VI - Inefficient workarounds

• there are many inefficient ways how to detect our  described attack, all of them can be circumvented by:
  • regeneration of already checked tickets (in case the  inspector looks for duplicate SMS tickets or uses  sophisticated geographical correlation)
  • full MITM attack between the inspector and  passenger mobile phone (calls / SMS)
  • using of a private P2P mobile network (blacklisting  of the number responsible for sending valid SMS  requests becomes impossible)

SMS public transport ticket vulnerabilities VII - Ahead to perfection!

• CallerID Spoofing
  • It is possible to spoof SMS sender or Caller  ID using public available services to use VOIP provider who allows you to set your own Caller­ID
• Private P2P mobile network
  • single point of detection – the central SMS hack server uses the  unique and still same phone number this phone number can be  easily detected and blacklisted
  • every SMS hack client should have own SMS sending server

SMS public transport ticket vulnerabilities VIII - Solutions that work

• it is necessary to bind the user identity with his  SMS ticket
• the user who wishes to use SMS tickets needs  to REGISTER himself to the SMS service using  SMS with text:

  • REGISTER PERSONAL_USER_IDNUMBER or  REGISTER PERSONAL_USER_BIRTHDATE

• public transport server computes hash of the  user's ID number or his birthdate and associates it with the user phone number   (hash(PERSONAL_USER_IDNUMBER) <­>  USER_PHONENUMBER)

SMS public transport ticket vulnerabilities IX - Does the fix look complicated?

• not really, the inspector just scans you personal  ID document and visually compares the result  of his PDA with your SMS ticket – that's all
• inspector's PDAs should support automatic  personal ID scanning
• symmetric keys can be used even if the  inspector's PDA is lost/stolen (it is necessary  immediately to redistribute all new keys to all  inspector's PDAs and central SMS server)

SMS public transport ticket vulnerabilities X - And there is a partial implementation

• http://farebandit.net/ - it is a quite simple iOS and Android application, and it does not implement most of our described functionality, but despite this fact, it is still widespread used by many black passengers in Central Europe.

• Despite the fact that public transport companies have already been informed about this serious vulnerability, they ignore this fact and still use the vulnerable systems. We are not aware of any public transport SMS tickets which are not vulnerable to this kind of attacks.

  
   

Mifare Classic vulnerabilities I - basics

• one of the most used RFID card (more than 1 billion smart card chips are used)
• based on ISO/IEC 14443 Type A, 1kB or 4kB
• uses 13.56 Mhz contactless smartcard standard
• uses a proprietary non-public CRYPTO1 with 48 bits keys
• read­only Unique Identifier (UID)
• mutual authentication between reader and
  writer and encrypted communication
• had a lot of security problems in the past but nobody cares :­)
• it's cheap (about 1 €)

Mifare Classic vulnerabilities II - Past usage in Czech Republic, Slovakia

• all University/ISIC/Euro26 cards
• public transport ID (“električenka”) in Bratislava and Prague
• Slovak Lines, Slovak railways cards
• parking cards
• swimming pool and ski entry cards
• Now most cards have already used Mifare DESFire EV1

Mifare Classic vulnerabilities III - Commands and default keys

• authenticate
• read, write, increment, decrement – always sent in encrypted session
• transfer, restore

• a lot of publicly used cards (even in Czech Republic / Slovakia) use at least one block encrypted with default keys:
  • 0xffffffffffff 0xa0a1a2a3a4a5 0xb0b1b2b3b4b5  0x4d3a99c351dd 0x1a982c7e459a  000000000000 0xd3f7d3f7d3f7 0xaabbccddeeff

Mifare Classic vulnerabilities IV - Linear Feedback Shift Register
(LFSR)

• pseudo random generation defined by the polynomial x^16 + x^14 + x^13 + x^11 + 1
• length is 32 bits, but it has only 16 bits entropy!
• L16 = x0 XOR x11 XOR x13 XOR x14 XOR x16
• Ar = suc2(Nt), At = suc3(Nt)
• generated nonces can be predicted in the time
• Nt is chosen by tag and sent to the reader
• Nr is chosen by reader and sent to the tag 

Mifare Classic vulnerabilities V - Our implemented "Nested" attack

1. Authenticate to the block with default key and read tag's Nt (determined by LFSR)
2. Authenticate to the same block with default key and read tag's Nt' (determined by LFSR) (this authentication is in an encrypted session)
3. Compute “timing distance” (number of LFSR shifts)
4. Guess the Nt value and authenticate to the different block 

Mifare Classic vulnerabilities VI - Cloning

• when all keys are gained, every card can be easily cloned
• normally we can make 99.6% clone (except of zero-block in zero-sector that contains read­only UID) - this can be bypassed by special Chinese Mifare Classic cards with rewriteable zero-block leading to 100% clone!
• all blocks (including UID!) can be 100% emulated by Proxmark III
• protection against cloning – make whitelist of allowed UIDs, or always use it in card content encryption

Mifare Classic vulnerabilities VII - Countermeasures

• Anti­cloning protection does not work against dumping the whole card ­ when you decide to charge your card and restore the dump with original credit (UID remains the same)
  • Countermeasure #1 – use safer cards (Mifare DESFire EV1 or EV2)
  • Countermeasure #2 – use “decrement counter” protection (it's only “workaround”)
  • Countermeasure #3 – use online checking

Mifare Classic vulnerabilities VIII - Mifare Offline Classic Cracker

• Our Mifare Offline Classic Cracker (MFOC) - implementation of "nested offline" card attack is based on crapto1 which is open implementation of attacks against the CRYPTO1 cipher
• it can be used for cracking Mifare Classic initial  authentication handshake
• the current version of MFOC is available in all good hackers Linux distributions (e.g. Kali Linux)

Mifare Classic vulnerabilities IX - NFC analysis/cracking HW

• Proxmark III - general­purpose RFID tool designed to snoop, listen and emulate everything from LF (125kHz) to HF (13.56Mhz) tags, universal hacking RFID tool :­)
• Tikitag / Touchatag - very cheap (30 EUR), NFC­ based RFID  reader/writer 

Mifare Classic vulnerabilities X - Slovak Mifare Classic vulnerabilities

• all tested cards use the same keys (!!!) for the first 1024 bytes (first 16 keys are the SAME!)
• there is always at least one sector encrypted with default key! (possibility of nested attacks)
• the name of passenger/owner is always stored in 0xd block – imagine what can happens with strong antenna :­) 
• no protection against cloning or modification!
• Attacker's costs
  • ​30 € – tikitag / touchatag RFID reader/writer
  • $449 – Proxmark 3 (just for advanced RFID
    playing :­)
  • 1 € for blank 4kB Mifare Classic with rewriteable UID

SMS parking ticket vulnerabilities I - introduction

• Critical vulnerabilities in Slovak Mobile Parking (used by all big Slovak cities  including Bratislava) that make possible to
  • force any registered Mobile Parking user to pay for parking of an  arbitrary car
  • to dump mobile numbers of all registered users in Mobile Parking

SMS parking ticket vulnerabilities II - basics

• Registered users – they need to register to the  Mobile parking system with their mobile number  and car plate number, after the registration they  need to charge their credit (and transfer their  money to their Mobile Parking account) –  billing is done by the Mobile parking  company
• Unregistered users – billing is done by the  mobile operator – no registration is necessary

• Syntax of SMS parking request sent to the specific number - ParkingTime_CarPlateNumber

  • Parking Time – in hours (Bratislava) or in minutes (Vienna)

  • Car Plate number – you can pay for parking of  an arbitrary car (not only yours!) 

SMS parking ticket vulnerabilities III - Payments

• The payer of the Mobile parking is identified  according to the SMS sender of the SMS  parking request!
• And of course it can be easily spoofed using multiple SMS send spoofing services!
• And yes, the attacker can be completely  anonymous and use TOR and Bitcoin payments (Moral Reform:-)
• OK, we are able to send any SMS parking ticket  with an arbitrary spoofed sender number
• But, if we want to park for free, we need to send it from the sender number that is  already registered in the Mobile Parking  system
• How it is possible to reveal existing registered  numbers?

SMS parking ticket vulnerabilities IV - Enumeration

• Let's use web registration forms to dump  all mobile numbers!
• Slovak M­Parking system www.m­parking.sk and Austrian M­Parking system  www.handyparken.at are vulnerable to the trivial enumeration attacks!
• During the registration process the Mobile  Parking system informs you if the given mobile  number exists or not - this behavior can be exploited to dump all mobile numbers of all  Mobile parking registered users!!!

SMS parking ticket vulnerabilities V - Captcha bypass

• Registration form of www.m­parking.sk is protected  against enumeration attacks by CAPTCHA
• We were able to crack 100% of all CAPTCHAs using  commercial CAPTCHA cracking services - 1000 CAPTCHAs  cost 0.97 €, cracking one mobile subnet  (0905XXXXXX) cost 978 €
• If the open­source CAPTCHA cracking is used, this  can be done completely for free!
• Registration form of www.handyparken.at DOES NOT USE CAPTCHA at all, therefore all mobile numbers of all registered users can  be dumped just in few hours / days!

SMS parking ticket vulnerabilities VI - Proposed solution I.

• The Mobile Parking system SHOULD VERIFY if the  number of SMS center of the SMS request has the  given country prefix (Slovakia +421*, Austria, +43*) ­ if  not, the SMS parking request should be throw away
• Advantages:
  • probably very efficient solution, because  SMS spoofing services are prohibited in Slovakia /  Austria
• Disadvantages:
  • ​you can not pay for parking your car  in Slovakia, when you are outside of Slovakia

SMS parking ticket vulnerabilities VII - Proposed solution II

• Shortened numbers
  • ​Disallow using the international number (e.g.  +421902020202) for the Mobile parking that  can be easily reached from the SMS spoofing  service
  • In case of the shortened numbers, spoofing will  be much more complicated, because the SMS  spoofing service has to exist in the given  country

SMS parking ticket vulnerabilities VIII - Proposed solution III

• Protect against enumeration attacks
  • If the user put his mobile number to the registration form, a  random authentication token is sent to his number
  • He enters this authentication token to the second form and if it  is valid, he is successfully registered to the system
  • If anyone with this number is registered to the system – he  receives the SMS message with text “This mobile number has  been already used. Please ask for your forgotten credentials”.
• No CAPTCHA is used at all - be aware of SMS DDoS attacks (use SMS rate limiting per IP  address)

Security Analysis of Czech and Slovak NFC payment cards I

Mastercard PayPass, VISA PayWave

• firstly published at Hackito Ergo Sum in Paris "Hacking NFC credit cards for fun and profit"
• few months ago we decided to check NFC cards in Slovakia / Czech Republic
• we are able to read a lot of sensitive information (e.g. history of payments) without any authentication

Used tools

• ​Banking Card reader NFC (EMV) app for Android
• touchatag NFC reader with NFC millionare application

Security Analysis of Czech and Slovak NFC payment cards II

Security Analysis of Czech and Slovak NFC payment cards III

Maximum Reading Distance

• our experiments were done from the distance of 4 cm
• NFC standard allows to extend this range up to 20 cm
• According to the original paper, using external antenna and special amplificator it is possible to reach the distance 1.5 meter

Security Analysis of Czech and Slovak NFC payment cards IV

And the results!

• We have analyzed almost 60 Slovak NFC payment cards and 30 Czech ones
• For all tested cards it was possible to read card number, expiration date, PIN tries
• For almost half of them it was possible to read "transaction history"
• For some of them "owner name"

Security Analysis of Czech and Slovak NFC payment cards V

Potential risks

• in case of stored transaction history it was possible to read:
  • type of transaction
  • date of transaction
  • amount and currency
• This information can be used to create "geographical profile" of the victim (what countries he visited and when)
• Payment patterns can be used to create a "buying profile" of the victim and help to estimate his solvency
• CVC/CVV code is not possible to read from the cards, but this may not be a problem because many online portals still do not require CVC/CVV code

Security Analysis of Czech and Slovak NFC payment cards VI

And all of this can be exploited by any POS terminal / ATM owner or anonymous attacker within physical proximity!

Security Analysis of Czech and Slovak NFC payment cards VII

Protection

• Passive RFID shields
• Active RFID jammers

Thanks for your attention!

Q&A

www.nethemba.com