CEO of Nethemba - Slovak IT security company founded in 2007, primarily focused on web application security and various penetration tests.
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
SMS public transport ticket vulnerabilities
Mifare Classic vulnerabilities and implementation of Mifare Classic Offline Cracker
SMS parking ticket vulnerabilities
Security analysis of Slovak and Czech NFC
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 channel – too expensive, impossible to modify SMS headers (sender, recipient, statusflag)
- 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
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!
- 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 CallerID
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
- readonly 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
- 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
- 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
- Authenticate to the block with default key and read tag's Nt (determined by LFSR)
- Authenticate to the same block with default key and read tag's Nt' (determined by LFSR) (this authentication is in an encrypted session)
- Compute “timing distance” (number of LFSR shifts)
- 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 readonly 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
- Anticloning 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 - generalpurpose 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!
- 30 € – tikitag / touchatag RFID reader/writer
- $449 – Proxmark 3 (just for advanced RFID
- 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 MParking system www.mparking.sk and Austrian MParking 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.mparking.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 opensource 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
- probably very efficient solution, because SMS spoofing services are prohibited in Slovakia / Austria
- you can not pay for parking your car in Slovakia, when you are outside of Slovakia
SMS parking ticket vulnerabilities VII - Proposed solution II
- 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
- 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
- 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
- Passive RFID shields
- Active RFID jammers
Thanks for your attention!
Public Security Projects
By Pavol Luptak