Nethemba public security research projects (2007-2015)

Introduction, our reasons & motivation

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.

1. SMS public transport ticket vulnerabilities

SMS tickets are widely used in all large cities in Central Europe (Prague, Bratislava, Košice, Vienna, Warsaw, ..). Using a simple SMS message (e.g. “DPT”) sent to a predefined number, you can receive a valid SMS public transport ticket, e.g. “Price XYZ, Validity: from 28.10.07 13:20 to 28.10.07 14:50, code YrQPtMKs7 /52845”. The critical security issue lays in an absence of the connection between user’s identity and his SMS ticket’s identity. Therefore, SMS ticket can be shared by a community without any technological problems, despite the fact that legislatively it is prohibited to generate and distribute copies of personal SMS ticket. In our research, we have shown there is almost no way to detect these duplicates or the detection would be very expensive. We’ve also shown that an arbitrary SMS message can be locally generated on every current smartphone with the predefined sender, recipient, body, and status flag (“Not-Read-Yet”). Therefore, they are visually indistinguishable from the original ones. We have proposed two ways of “valid SMS ticket” distribution. One using SMS channel (it is publicly available, but too expensive with the impossibility to modify SMS headers) and the second one using TCP/IP (very cheap, but requiring a prepaid mobile data service and a smartphone which has to be capable of generating local SMSes). We have designed and described a communication architecture including SMS hack clients and servers. We’ve also described the following security workarounds implemented by public transport company that can by bypassed by our proposed circumvention methods:

Potential security fix (by public transport company)	Circumvention method (suggested by us)
Public transport inspector can look for duplicate SMS tickets (if two or more people use the same ticket, it is cleared that the shared ticket is used and distributed)	Regeneration of already checked tickets (in case the inspector looks for duplicate SMS tickets or uses sophisticated geographic correlation). It can be done fully automatically using passenger’s geographical collision detection. SMS hack clients will send the passenger’s current location to the central SMS hack server that will evaluate possible collisions and invalidate “collision” SMS tickets and ask for the new valid ones
Public transport service can use sophisticated geographical correlation systems to reveal that one SMS ticket is used in a short time in multiple places that are too far from each other	Mandatory regeneration of already checked tickets
The inspector makes a call to the SMS ticket sender (because he knows his number)	Use GSM card / Asterisk VOIP call center on the central SMS hack server, if any call to this number is detected, Asterisk will make a call to all participants/clients (and only the right one will pick up it )
The inspector sends a verification SMS to the SMS ticket sender (because he knows his number)	If the inspector’s verification SMS message is received by the central SMS hack server, this SMS is redistributed to all participants/clients with properly applied caller ID spoofing
The inspector can ask the user to make a call to his predefined number (and he checks if the same sender number is used that was used for the SMS ticket request)	The black passenger can run his special application that makes VOIP call through the central SMS hack server to the inspector phone – the inspector will see the same number that was used for SMS ticket request
The inspector can ask the user to send him an SMS verification (to verify if the user number is the same as the sender number that was used for the SMS ticket request)	The black passenger can run his special application that sends this SMS verification message through the central SMS hack server, so the inspector will see the same sender number that was used for the SMS ticket request)
Public transport service can reveal that many SMS ticket requests are sent from the same number. Consequently, it can blacklist this number and reject all SMS tickets requests.	Change of SIM/mobile number periodically (SIM cards/unique numbers can be bought completely anonymously in the Czech Republic or Austria). Use of multiple SIMs/mobile numbers in the central SMS hack server. Use private P2P mobile networks

There still can be a 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. In this, each SMS hack client should also have its SMS sending server. Thanks to this the proposed architecture can be fully decentralized with no single point of detection – every client participates in sending of SMS ticket requests – P2P mobile network cannot be easily blacklisted.

We have described two security fixes which are too expensive to implement:

1. Using IMEI for passenger identification (we can bind the passenger’s IMEI with his SMS ticket (after his proper registration).

2. Geographical localization of checked passengers – we need to know the response to a question: “Is a just checked passenger sufficiently closed (in a defined distance) to the inspector?” It requires cooperation with GSM/3G operators (they have to provide the name/position of the BTS the passenger or inspector). It may be a big privacy issue and too expensive.

The only viable and secure solution we have proposed was the registration of all new users with their birth date or ID number (personal ID or passport). We have described two different ways – the one using public, the second using symmetric cryptography. The final verification should be quite easy to use – the inspector just scans the personal ID document and visually compares the result of his PDA with the given SMS ticket. The inspector’s PDAs should support automatic personal ID scanning (e.g. using QR codes).

More information is available in our paper Public transport SMS ticket hacking.

Few years after our public release, the iOS and Android version of the application FareBandit was published, allowing anyone to share his or her SMS public transport ticket. It is a quite simple 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.

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

Mifare Classic represents one of the most used RFID cards (more than a billion smart card chips are used). It is based on ISO/IEC 14443 Type A, 1kB or 4kB and uses 13.56 Mhz contactless smart card standard. It uses a proprietary CRYPTO1 with 48 bits keys. Historically this technology had many security problems in the past. In Czech/Slovak Republic this technology was used by all University/ISIC/Euro26 cards, public transport ID (“električenka”) in Bratislava, Slovak Lines, Slovak railways cards, parking cards, swimming pools or skiing resorts. Mifare Classic security was based on read only Unique Identifier (UID), mutual authentication between reader and writer and encrypted communication, CRYPTO1 non public algorithm implementation and some other elements. The set of Mifare Classic commands is quite limited – authenticate, read, write, increment, decrement, transfer and restore. We have revealed a lot publicly used cards (even in Czech Republic and Slovakia) used at least one block encrypted with the default keys (i.e. 0xffffffffffff, 0xa0a1a2a3a4a5, 0xb0b1b2b3b4b5, 0x4d3a99c351dd, 0x1a982c7e459a, 000000000000, 0xd3f7d3f7d3f7 and 0xaabbccddeeff), so these blocks can be easily read by NFC tag reader.

The fundamental problem of Mifare Classic security was a pseudo-random generator that is defined by the polynomial x^16 + x^14 + x^13 + x^11 + 1, also called LFSR. Despite its length of 32 bits, it has only 16 bits entropy. This random generator was used for generation of “random” nonces that were consequently used for a mutual authentication between the RFID card and RFID reader. Despite the existence of various other attacks to Mifare Classic technology (e.g. “timeout” attack), we have decided to implement “Nested Attack”.

This attack can be described by four following steps:

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

The proposed attack works with Mifare Classic cards with at least one default block. This block encrypted with default keys can be quickly revealed by many NFC Android-based applications or by our released tool – Nethemba Mifare Offline Cracking Tool – MFOC.

Revealing all keys from Mifare Classic often makes possible cloning. When all keys are gained, every card can be easily cloned; it is possible to make 99.6% clone (except 0.block in 0.sector that contains readonly UID, in these days it is possible to buy in Chinese shops even Mifare Classic with rewritable UID). All these blocks (including UID!) can be 100% emulated by Proxmark3 or by any other card emulator. Proxmark3 is a general purpose RFID tool designed to snoop, listen and emulate everything from LF (125kHz) to HF (13.56Mhz) tags, it is a universal hacking RFID device.

Our MFOC implementation has been tested using very cheap (30 EUR) TouchTag RFID reader (ISO14443a 13.56 Mhz NFC reader).

For our “nested offline” card attack implementation we have used an open library Crapto1 that can be used for cracking Mifare Classic initial authentication handshake.

Unfortunately, we see a lot of practical applications of Mifare Classic (especially in public transport/transport companies) that use a sensitive information, e.g. “credit” physically stored on the card. Even if there is some complex crypto solution used for encryption/signing the credit, it is possible to make a full dump of the card (after charging the credit) and after spending some credits just restore this made the dump with the original credit (UID remains the same one). We have proposed three countermeasures for this situation:

Countermeasure #1 – use safer cards (Mifare Plus/DESFire or other)
Countermeasure #2 – use “decrement counter” protection (it is only “workaround”)
Countermeasure #3 – use online checking (the most secure one), unfortunately, this is not technically possible in all situations

Our analysis of Slovak Mifare Classic cards has shown:

all tested cards use the same keys for the first 1024 bytes (first 16 keys)

there was always at least one sector encrypted with a default key! (therefore, it was always possible to perform our “nested attacks”)
the name of passenger/the card owner was always stored in 0xd block – (imagine what can happen with strong antenna)
there was no protection against cloning or modification
all these cards could be easily cloned and modified

We have also done a binary difference analysis between the newly bought card, after its activation and charging credit. We have revealed the sensitive information that was available on all tested Slovak cards (“passenger/username”, expiration date of public transport document in Bratislava, student’s university number, student’s name).

Total costs for potential attackers are:

30 EUR for tikitag/touchatag RFID reader (sufficient for reading / cracking / writing / cloning Mifare Classic cards)
$400 for Proxmark 3 (universal RFID emulator, reader, writer, sniffer)
less than 1 EUR for a blank 4kB Mifare Classic card

There is no universally working security fix for Mifare Classic cards. We recommend using a safer technology (Mifare DESFire EV1). If Mifare Classic cards should be still used, we propose a partial workaround only – bind user identity with card’s readonly UID, use UID in content card encryption, use UID whitelists, use “decrement counter” solution. Because replacing all Mifare Classic cards to safer ones may be very expensive and time-consuming process, for a short time it is possible to use the “decrement-counter” workaround. Let’s have the “decrement counter” – initially set to 0xffffffff. Mifare access keys A and B have permission for decrementing counter only and these keys cannot be changed. The content of the card (with passenger credit) should be re-encrypted/hashed with card UID, this decrement counter, and private key. It is still possible to make a full clone of this card to Mifare Classic card with rewritable 0-block, but the original card cannot be re-used.

In addition to our released Mifare Classic Offline Cracker, there is also another tool from Andrei C called Mifare Classic Key Recovery Tool. Compared to MFOC this tool is a bit slower, but it can recover at least one key from the card with non-default keys (e.g. London Oyster cards). This key can be used by MFOC to crack other keys from the card.

3. SMS parking ticket vulnerabilities

In 2010, we revealed critical vulnerabilities in SMS mobile parking. All big cities (including Bratislava and Košice) were affected. We revealed two critical vulnerabilities:

1. We were able to force any registered prepaid Mobile Parking user to pay for parking of an arbitrary car.

2. We were able to dump mobile numbers of all registered users in prepaid Mobile Parking.

Firstly, we would like to explain how prepaid Mobile Parking works. If someone wants to use prepaid Mobile Parking, she should be registered in this system with her mobile number and car plate number. After this registration, she needs to charge her parking credit (and transfer her money to her Mobile Parking account). In this situation billing is performed by the Mobile parking company. If she decide not to register to use prepaid Mobile parking, and she wants to pay immediately for her parking by SMS messages, billing is performed by the mobile operator.

Syntax of SMS parking request looks like:

ParkingTime_CarPlateNumber

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

Car Plate number – it is possible to pay for parking of an arbitrary car (not only yours!)

The SMS message is sent to the particular number, e.g., +421902020202

The fundamental security problem is that the subscriber of the prepaid Mobile parking is identified according to the SMS sender of the SMS parking request. Moreover, of course, this number can be easily spoofed. For our experiments, we have used the SMS spoofing service www.armsms.com. Because some SMS spoofing services accept Bitcoin, thanks to Tor and Bitcoin payments, the potential attacker can be completely anonymous.

The question is how it is possible to force the existing registered users to pay for the parking without their notice. Now we can 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 originator number that is already registered in the Mobile Parking system. So another question is – How it is possible to reveal existing registered numbers?

We have revealed both 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 always informs if the given mobile number exists or not. Therefore, this behavior can be exploited to dump all mobile numbers of all Mobile parking registered users(!)

Using these two vulnerabilities it is possible to cause total Mobile Parking chaos:

The victim receives the SMS notification that he pays for parking of XYZ car plate. The owner of XYZ car does not need to know necessarily anything about the victim and the attacker. The attacker can be still anonymous and cause a maximum chaos because it will be difficult to distinguish between justified and unjustified complaints. This confusion may lead to mobile parking anarchy and shutting down the Mobile Parking service in the worst case.

Despite the fact the registration form at www.m-parking.sk was protected against enumeration attacks by Captcha, we were able to crack 100% of all Captcha images using commercial Captcha cracking services http://decaptcher.com and

http://www.deathbycaptcha.com, solving 1000 Captcha images costs 0.97 €, cracking one mobile subnet (0905XXXXXX) costs 978 €.

The registration form at www.handyparken.at did not use Captcha protection at all. Therefore, mobile numbers of all registered users could be dumped just in few hours or days.

To fix these vulnerabilities, we have proposed three solutions:

1. SMS center verification

The Mobile Parking system should always checks 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: it is not possible to pay for the parked car in Slovakia from outside of Slovakia

2. Shortened numbers

The Mobile Parking company should disallow using the international number (e.g. +421902020202) for the Mobile parking that can be easily reached from the SMS spoofing service. In the case of shortened numbers, spoofing will be much more complicated because the SMS spoofing service has to be functional in the given country where a mobile parking is used.

3. Protection against enumeration attacks

If a user put his mobile number on the registration form, a random authentication token should be sent to his number. He should enter this authentication token to the second form and if it is valid, he will be successfully registered to the system.

If anyone with this number is registered to the system – he will receive the SMS message with text “This mobile number has been already used. Please ask for your forgotten credentials”. We recommend not to use Captcha images at all.

4. Security analysis of Slovak and Czech NFC payment cards

Contactless payment cards VISA (payWave) and Mastercard (PayPass) are probably the most popular in Slovakia – prefers them more than half of people (56% . In April 2012, at the Conference Hackito Ergo Sum in Paris there was published presentation ”Hacking the NFC credit cards for fun and profit” firstly describing how it is technically possible fully anonymously and without authentication to gain a significant amount of sensitive information that can be subsequently misused. Such information includes, for example, a list of all executed payment transactions (payments in POS terminals, ATM withdrawals).

Three years after this presentation, we decided to implement a similar security analysis of NFC credit cards used in Slovakia and Czech Republic to find out if card issuers had already fixed these old vulnerabilities and started to issue sufficiently secure NFC payment cards. The result of our analysis was alarming – it is still possible to read much sensitive information from the most NFC cards used in Slovakia and Czech Republic.

The confidential information from NFC cards can be read by any seller with access to POS terminals, ATM owner/provider or anyone with physical access to a vulnerable NFC card payments. Consequently, it is possible to exploit this information to obtain “buying profile” of the card owner, to reveal all countries (based on the currency used) the card owner had visited in the past, to assess the card owner solvency and used this information for better-targeted marketing.

Contactless NFC cards can be read by an arbitrary ISO14443 based NFC reader working at the frequency of 13.56 MHz. In our case we have used standard smartphones and tablets with NFC support a special NFC reader (touchatag). As an Android application, we have used the Banking Card Reader (EMC) available directly from Google Play. Some information (e.g. card owner’s name) could not be read by Banking Card Reader application. To read this information we have used a special Android application NFC millionaire instead. As it was demonstrated in the following video, reading the sensitive information from NFC cards can be performed very fast.

We were able to read cards without external NFC antenna from a distance of 4 cm. The NFC standard allows this range to increase up to a distance of 20 cm. According to a presentation “Hacking the NFC credit cards and debit for fun” (slide 21) you can use an external antenna read range amplifier (for 2000 EUR) and antenna (for 1000 EUR) to increase the distance up to 1.5 meters. We have revealed that most than half of all tested NFC EMV payment cards contain sensitive information that is not necessary for the correct card functionality – e.g. the transaction history.

During our analysis of more than 60 Slovak NFC cards and 30 Czech NFC cards, we have discovered that it was possible for more than half of all tested cards to read a complete transaction history. Of course without any authentication. For our comprehensive results, click here. For all tested cards, we were able to read a card number, expiration date, and PIN tries. For almost half of them, it was possible to read the whole transaction history, for some of them “owner name”.

Using applications NFC millionaire we have also been able to retrieve the owner of the card.

CVC / CVV code is not stored on the card and therefore cannot be read.

In the case it was possible to know the transaction history, then for each transaction the following parameters were available:

type of operation (payment cards, ATM withdrawals, etc.)
date of the transaction
the total amount and the currency that was used

Based on the used currency where the transaction was executed, it was possible to evaluate a geographical profile of the card owner – it means when and what countries he had visited in the past.

Based on the frequency and volume of the payments it was possible to create a “buying profile” and assess his solvency, which is how much money the card owner had spent for the defined period.

It is necessary to emphasize that this information that can be obtained by any POS terminal owner (seller) or any attacker who is sufficiently close to the card owner. More important, many e-commerce websites still do not require CVC / CVV code for card transaction (only the owner name, card number and expiration date). Therefore, stolen card information from NFC cards can be misused easily.

How to check if someone is vulnerable to the attack mentioned above?

First of all, on any Android device that supports NFC, we recommend to install the application Banking card reader and try to find out what kind of information can be read from the given NFC card. If it is possible to read a very sensitive information (e.g. a transaction history, the name, and surname), we strongly recommend to contact the bank and ask them to issue newer and safer card replacement.

As long as the bank does not support secure NFC credit cards, we recommend choosing the bank that supports secure NFC cards.

If this is not possible, we recommend putting NFC cards to secure RFID shields (Faraday cage that blocks any electromagnetic radiation).

BLOG