Pass the (EZ-Link Standard) ticket attack

Attacks on public transportation tickets have been around for a number of years. Two Italian students were able to lock a single use ticket and continually use it on the Turin public transit system. After reading through the research, I decided to try find out if Singapore's public transit fare system is vulnerable to a similar exploit.

The EZ-Link standard ticket is a single use ticket for the MRT system in Singapore. The standard ticket is only valid for a single day. However, commuters can get a refund for their unused tickets from any passenger service centre within 3 days of purchase of the ticket. In an effort to reduce wastage, the single ticket can also be topped up and used for up to 6 trips within 30 days.

Upon scanning the standard ticket with an NFC reader, I discovered that the card used is Mifare Ultralight, which is same as that used in the Turin system. Mifare Ultralight does not support any form of encryption or access control, hence it is possible to obtain a card dump.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

13 Jun 2016     $1.50 Stored Value

05 31 13 af     ID
e9 54 b0 c1     ID + Chk Digit
cc 01 0f 80     Chk Digit + Lock (0f 80) = (0000 1111 1000 0000)
00 4f 24 00     OTP  (Locked Permanently)
b9 77 6a 5c     Prog (Unlocked Permanently)
73 fc e9 78     Prog (Unlocked Permanently)
72 a1 32 16     Prog (Unlocked Permanently)
48 08 76 89     Prog (Unlocked Permanently)
b0 f9 db 2f     Prog (Unlocked Permanently)
00 00 00 00     Prog (Unlocked Permanently)
d9 71 b1 75     Prog (Unlocked Permanently)
37 93 ec a2     Prog (Unlocked Permanently)
0e 71 09 75     Prog (Unlocked Permanently)
c6 e4 76 4f     Prog (Unlocked Permanently)
06 07 01 c4     Prog (Unlocked Permanently)
17 f9 4a c2     Prog (Locked Permanently)

Upon consulting the Mifare Ultralight specifications, I realised that the standard ticket worked differently from the Turin system. The attack on the Turin system involved locking the bits in the OTP page so they cannot be turned on or off, however the OTP page on the standard ticket was already permanently locked. Hence, the EZ-Link system must rely on a different method. At a cursory glance, I was unable to find the date of purchase, 13 June, nor the $1.50 stored value anywhere on the card. I needed more samples so I decided to acquire a second card and dump both cards in new and spent state.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Card #1         Card #1         Card #2         Card #2
13 Jun 2016     13 Jun 2016     14 Jun 2016     14 Jun 2016 
$1.50 value     $0 value        $1.50 value     $0 value

05 31 13 af     05 31 13 af     05 31 23 9f     05 31 23 9f
e9 54 b0 c1     e9 54 b0 c1     e9 54 b0 c1     e9 54 b0 c1
cc 01 0f 80     cc 01 0f 80     cc 01 0f 80     cc 01 0f 80
00 4f 24 00     00 4f 24 00     00 4f 24 00     00 4f 24 00
b9 77 6a 5c     b9 77 6a 5c     8d b3 8e d2     8d b3 8e d2
73 fc e9 78     73 fc e9 78     23 67 68 ac     23 67 68 ac
72 a1 32 16     72 a1 32 16     26 76 57 81     26 76 57 81
48 08 76 89     48 08 76 89     4e d6 94 5a     4e d6 94 5a
b0 f9 db 2f     b0 f9 db 2f     a7 51 bc 69     a7 51 bc 69
00 00 00 00     00 00 00 00     00 00 00 00     00 00 00 00
d9 71 b1 75     31 43 ed bd     fb 18 b0 4f     85 25 2a 49
37 93 ec a2     8c 15 12 9a     ad c5 bc 73     02 be 65 0a
0e 71 09 75     c9 89 bf 66     37 f1 11 88     6e 37 ca fc
c6 e4 76 4f     92 1e 89 cf     18 13 18 34     38 00 f1 45
06 07 01 c4     ce 66 38 60     6a 91 99 a1     36 c6 36 4f
17 f9 4a c2     17 f9 4a c2     17 f9 4b 58     17 f9 4b 58

I wanted tickets that differed in only 1 attribute, in this case, the date, so I could identify which bits were flipped, which would indicate the page where the date was stored. The tickets were bought from the same dispensing machine, hence the similar ID numbers.

Comparing the dumps, it became obvious that page 10 to 14 (Line 14-18) is used to store the data. However, a difference in only 1 attribute resulted in a significant difference in data. 13 June looked completely different from 14 June. $1.50 looked completely different from $0. In other words, the cipher used exhibited very good diffusion properties.

XOR cipher

We will start with the low hanging fruit first, the XOR cipher. When the key of the XOR cipher is as long as the plaintext, we get a one time pad which exhibits good randomness. The card ID, OTP and the last page is ruled out because they are too similar, hence given that the plaintext is similar, they will produce similar looking ciphertexts. The only candidate key is page 4 to 8 (Line 8-12). It is 160 bits long, exactly the same length as the plaintext and card #1 has a very different value compared to card #2. Unfortunately, the XORed result did not display any correlation.

3DES cipher

Moving on, I realised that the card UID is exactly 56 bits, which is the effective keysize for DES. Using a script which I wrote, I expanded the key and used it to perform both DES-CBC and 3DES-CBC(DDD) decryption. DED is the preferred mode, most likely used in CEPAS as well, but with only 1 key, DED mode would be equivalent to DES. The results were similarly unspectacular.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Key - 05 31 13 af e9 54 b0
04984575FE4A5261

1DES-CBC:       ED04580528C2727E2507E6A8FC0AD3BB38DD70B0E4115845
1DES-CBC:       8515F7490415442ECB0E5FD018E89707E8AB7777B58428D9
3DES-CBC(DDD):  A5B101675604C88EA88C2F92924255FE8A8785E5A9809AA1
3DES-CBC(DDD):  DFBE27CCD05FEC12ACBBC8A1E01B4993CB52FCD524C1E356

Key - 05 31 23 9f e9 54 b0
04984973FE4A5261

1DES-CBC:       15F8DF2BD07494352E227B79DE46F42F0A1FD09E9F6ADAAC
1DES-CBC:       8A94E0E2D3964DF11864D116F1E1681977BBF528C273730F
3DES-CBC(DDD):  3D2DE1CDB79C78824EB8039B167D63E7A528F17F84C39525
3DES-CBC(DDD):  D8280E566E42A68C874074F21E9C01C928B7DC1ADE53A725

Time for more research. NXP publishes a document which provides implementation "hints". One of the tips include the use of a 128 bit Master Key which is encrypted with the card UID to produce 3 card keys which is used for 3DES(DED) decryption. The document also describes the use of zero padding and a default IV of 0s. In a last ditch attempt, I decided to follow the "hints" as closely as possible. Since I did not have a Master Key, I zero padded page 4 to 8 and used it in place of the Master Key. No dice. Looks like the crypto is sound.

1
2
3
4
5
6
7

1DES-Enc(page 4-8): 7FB935FB60863D01 2FB080C66B00A5C6 9FB477A1C76B7543
3DES-Composite Key(DDD): 38FF80ADD7F5EE25715C151621A84253C44BCC6913C91C9F
3DES-Composite Key(DDD): E14EAE79EB8CBBC6AEB01078209F02153C84C66C56DC3D03

1DES-Enc(page 4-8): DAA7FD0D0E86CC1D 716A6CE00E13AAE3 0EC20A1433D41899
3DES-Composite Key(DDD): 12354C9493AF218598B9DFD185E76A51E4A9CB5E0E2AACC6
3DES-Composite Key(DDD): 7256341BCF51E70346D58D2E07ED17E1C182049F4178D2CC

Pass the (EZ-Link Standard) ticket attack

The pass-the-ticket attack is based off the pass-the-hash attack, the idea being that if you cannot crack the hash, you simply forge a request and include the hash within. It is perfect for use with the Mifare Ultralight because the card does not contain a chip. It cannot perform a challenge response, or include a unique nonce or timestamp for each request. Therefore, it is trivial to perform a replay attack. In order to exploit the system, dump page 10 to 14 into a file. Go up to the passenger service centre and ask for a refund. Once out of sight, clone page 10 to 14 back onto the card. Go and ask for another refund at a different counter. Profit.

With more than 100 MRT stations in Singapore, there is more than enough to rotate around. A single card with round trip fare can store up to $6+, assuming you refund 3 card per station (to avoid suspicion), it is $18/station. Assuming you can visit 5 stations in an hour, it is a cool $90/hour in cash. Some stations have multiple centres due to multiple exits or it being an interchange with multiple lines. Further Profit. Don't forget, you also get to travel for free by reloading a 4th card and using it for personal travel.

The only equipment required is an Android phone with an NXP NFC chipset. A list of compatible phones has been provided here. There are many apps out there which allow reading and writing to Mifare Ultralight cards.

Proof

EZ-Link Golden Ticket

Inspired by the Kerberos golden ticket, a hypothetical EZ-Link golden ticket would allow unlimited travel for free. The cipher will first need to be broken, so it is impossible as of now. You will then need to get hold of a blank Mifare Ultralight card. Write in the data as necessary. Lock page 10 to 14. The card can now be used for free for today. For tomorrow, unlock pages 10 to 14, write in new data, and relock the pages. Make sure not to lock the block locking bits or you will not be able to unlock the pages anymore. For convenience, an app could perform the necessary computation, unlocking and relocking at the touch of a button. This is assuming the reader at the gantry does not verify the state of the locking bits.

Conclusion

While the EZ-Link standard ticket is not vulnerable to a golden ticket attack as was the case in the Turin exploit, it is vulnerable to a pass-the-ticket attack. The pass-the-ticket attack is usually less severe than the golden ticket attack. However, in this particular case, EZ-Link allows for the refund of the tickets. This increases the severity of the attack since attackers can now extract cash from the system, cash that can be spent not only on transportation, but on food, entertainment or elsewhere.