James
Thanks for the response. I’d be keen on a bit more clarity if possible:
1.
We have made the login, topup and journey history live again on the website but have left the edit details and change password functionality off for the moment. Can you tell me how many cards
you have registered for on line use and whether if the edit functionality was made live you could use this to access any personal details in the automated way you describe.
2.
We have found a few cards which have not been imported properly into our card list. One of these cards looks a bit suspicious in terms of history. Can you confirm that you have not entered any
of the following cards into the system:
|
Serial number
|
|
1323573918
|
|
1887593123
|
|
1887541939
|
|
1517227118
|
|
1444141923
|
|
2524144957
|
3.
Does the script you ran to determine the unregistered card numbers rely on the sequential nature of the etched card number. Ie. if we were to use a GUID number would it prevent the script being
effective.
Thanks
David Stenhouse
021 226 6987
From: James Turner [mailto:[email address]]
Sent: Monday, 11 November 2013 10:08 p.m.
To: David Stenhouse
Subject: Re: Private disclosure of vulnerability
1: on the website, once a user has logged in, they can block a lost/stolen card, as discussed in the presentation and below, this can be automated for all users
who have not registered their cards. this could allow an attacker to block ("hot-list") a great many cards.
2: yes, this is mostly correct. the language python is just an example, I only choose it because it is often used for similar tasks. it is very easy to write a program which will automatically try to register all possible cards (1000000), this program could
check an email account to activate the account and if it worked (i.e. the card was not already registered) copy the card holder's personal details. because the program could do this very fast (much faster than a human could), it could try to register several
cards a second, e.g. lets say it could register 5 cards a second, at that rate, it could try all possible cards in 56 hours, i.e. just over 2 days.
3: CAPTCHA would not stop humans from registering another user's card, but it would stop the program I described above, making it far more time consuming to gather the user's personal details etc. and yes, to implement CAPTCHA would only take most programmers
half a day to add to an existing web site such as metroinfo. in order to stop humans from registering another user's card I would require them to provide some personal data, such as their DoB which must match the card they are trying to register.
4: Correct, the readers on the buses do not use white-listing on the card UID. I do not have any cards added through this method.
I hope this info is helpful in your effort to secure the metro card system. if you have other questions or are confused about anything above, let me know.
~AmmonRa
-----Original Message-----
From: David Stenhouse <[email address]>
To: jamesturner968 <[email address]>
Sent: Sun, Nov 10, 2013 11:17 pm
Subject: FW: Private disclosure of vulnerability
I’ve watched your video from Kiwicon and am concerned about a few parts of it and wonder if we might meet up to discuss your findings over a cup of coffee? As you’ll have seen we’ve taken down
our website while INIT find a solution.
Of particular interest to us are the following observations:
1.
The assertion that you can wipe all cards in the system. We’re unclear how you can do this given that you are using the website to access personal details?
Are you are able to explain how you would do this?
2.
Personal Information. When you advised of the security around personal information it was assumed that this would be on an individual card basis and
that you would then be required to register the card and that verification would be via email to your personal email address. This sounded to INIT like a laborious process which would be unlikely to be a high risk and so a solution was discussed which was
to be implemented in the medium term (ie 2-3 months). However through your presentation it now appears that you are running a script (python) to both determine the unregistered cards, register them and potentially even automatically derive personal information
for all users. Are we correct in this assumption?
3.
Captcha as the security mechanism to prevent other users accessing personal details. Is this what you are referring to when you identified in your presentation
that a developer could develop a solution in half a day?
4.
Whitelisting. You make the comment during your presentation that there is an absence of whitelisting in our system which allows you to introduce
cards other than ECan’s cards into the system. Are you able to tell us whether you have actually done this and if so how many cards you have added?
From: David Stenhouse
Sent: Friday, 20 September 2013 3:37 p.m.
To: 'James Turner'
Subject: RE: Private disclosure of vulnerability
We started to learn of the vulnerabilities during 2009 and gathered as much information as we could over the subsequent period. By that time we had entered into a contract with a new ticketing
supplier and the new system was deployed on buses in August 2010. Together with the supplier we felt that the large number of active cards in use meant that we would be best placed to have a progressive migration from 1K Classic to 4K DESfire rather than a
single moment in time where all existing 1K cards ceased to operate. Thus we worked on a plan whereby the ticketing supplier developed to read and write to both card types. This made our situation fairly unique as at that time the majority of ticketing systems
being deployed around the world were being deployed from scratch with a specific card type.
We had some issues related to software deployment which we were working through at the time of the earthquakes. We also had the bus exchange, service centre and website deployment which we were
working on at that time. The earthquakes, as you will appreciate, set us back a long way and the metrocard transition was dropped down the priority list a bit while we recovered the network.
On our ticketing suppliers side they continued to work on development to roll out the DESfire cards in other centres.
Re the research, it’s best that you investigate further to understand the full extent of what has been discovered.
From: James Turner [mailto:[email address]]
Sent: Monday, 16 September 2013 7:02 p.m.
To: David Stenhouse
Subject: Re: Private disclosure of vulnerability
I also have a couple of questions.
You said you were already aware of the research done in Europe and are planning to switch to the desfire cards. when did you first learn of the vulnerabilities in mifare classic? I ask because it was reported in 2011 that metro cards would switch to desfire.
Why didn't that happen?
You said what I informed you of has already been discovered and published in Europe, are you only referring to the research on mifare classic cards I cited in my initial email? Because if so,
the three vulnerabilities I discussed are not covered in that research. If there is other research I'm not aware of please let me know as there is no point in publishing my findings if they are already public.
Thanks for advising us of your findings. We are already aware of the findings of the researchers in Holland and have several mitigation strategies in place. The primary strategy is to transition
to the Mifare 4K DESfire card which has a greater level of security. Our ticketing system provider has developed the software to allow our on-bus devices to read and write to the 4K DESfire cards and this is currently undergoing Factory Acceptance Test before
deployment with another city.
We are also able to identify transactions that are of the nature you describe through routine analysis of the ticketing system reports which we have available. Once transactions of the nature
you describe are identified we can then hotlist the offending card.
We would be interested in the reason why you have a timeframe for releasing the information by 9th of November. Are you able to clarify this for us? We would also be interested in
understanding why you have undertaken the research when it has already been undertaken and publicised in Europe?
Manager Passenger Services
Private disclosure of vulnerability
While conducting recent research, I have discovered a number of quite serious security issues with the Metro Card system.
Before getting into the details of the issues, I want to explain the nature and purpose of this communication. I am informing you as a courtesy, in the hopes that it will help you address the
issues. It is not in any way intended as a threat.
At this point, I have not told anyone else of these issues, to avoid malicious parties exploiting the vulnerabilities before you can fix them; however, I have a hard deadline where I must publish
my findings on 9th Nov 2013.
Another reason it is important to fix these issues as soon as possible is that there could be malicious parties already exploiting them.
1. Ability to arbitrarily increase/decrease credit on a Metro Card
2. Ability to add new unauthorised cards to the system
3. Ability to copy any other user�s card and use their credit
You will hopefully already know everything in this section, but I want to cover some background about the technology used by the Metro Card system.
The contactless card used for the Metro Card is called Mifare Classic. The Mifare Classic was first released in 1994, which means it is quite old now, at least by technology standards.
Each Mifare Classic card is divided into 16
�sectors� of data. The system uses two authentication
keys per sector to only allow authorised reader devices to access the data on the card; these are called A and B keys. This makes for a total of 32 keys per card. Most of the sectors on a card can be rewritten, however the first part of the first sector contains
a special number called the UID, the UID is unique to each card and cannot be changed.
The researchers found a number of weaknesses with the Mifare Classic system. One of the weaknesses allowed anyone with access to a card to retrieve the authentication keys used on the card.
To do this however took significant time. There is another weakness where if an attacker already knows at least one key for one sector, they can retrieve all the remaining keys very quickly i.e. in less than a minute. This is called the
�nested attack�.
There is also an important vulnerability involving the card reader device. The attack allows the keys used by the reader device to be retrieved if the attacker can record,
�snoop�, the failed (or successful) authentication traffic
between a card and reader. To read the details of these attacks see
http://www.sos.cs.ru.nl/applications/rfid/2008-esorics.pdf
There are two notable tools which were used to take advantage of these weaknesses. The first is called a
�proxmark3�; it is a general purpose reader/writer device.
It also allows eavesdropping on other reader/card transactions.
The second device is called a
�magic Chinese card�. These are special Mifare Classic
cards which allow the UID to be changed; effectively making them appear to be any other card.
As you can see, the Mifare Classic system is very insecure. Using the first weakness listed above, we could retrieve the keys from any Metro Card in a number of hours, which would allow us to
read the data stored on the card and to change the data.
This task is made harder by the fact the each metro card uses different keys, so we would need to rerun the attack for every card we wanted to access. However, every metro card uses the same
A key for sector 0 i.e. FFFFFFFFFFFF, which means we can use the �nested attack�
to find the keys for any metro card in under a minute.
This allows us to easily read and change the data on any Metro Card we have physical access to. Since the data on Metro Cards is not encrypted, it is easy to find and change the important values,
such as the card etched number and the balance. It seems there is no online checking of balance when a card is presented to a reader, so changing the balance on the card will make the reader accept the new value. Worse is the fact that there seems to be no
server side balance verification either, which means that changing the balance on a card also updates the balance stored by the server the next time the reader device on the bus is synced.
As mentioned there is another attack against Mifare Classic involving a reader device. With this attack we can get the keys a reader tried to authenticate with when it attempts to read a card.
Using this attack we can present the reader with a blank Mifare Classic card and find out what keys the card should be programmed with to allow other Metro Card readers to access it, we can then format the card to appear to be a valid metro card and it will
work just like a legitimate card i.e. we can add unauthorised cards to the Metro Card system and use the first issue described above to set whatever balance we want.
The final issue is that we can
�clone� any other user�s
Metro Card without ever having physical access to it. Each metro card has two different IDs, the number printed on the top left of the card, and UID.
Although there is a mapping from the card number to the UID, the UID is the id which the balance is associated with. By loading the url
https://metrocard.metroinfo.co.nz/account/get_balance/card:<card number>?callback=x, where <card number> is any six digit number, the server will return the UID and balance for the card, if it is active. This means that we can get the card number, UID and
balance for every card in the Metro Card system. Using one of the �magic Chinese cards�
we can clone any card in the Metro Card system and use that user's credit. Because of the first vulnerability mentioned, when the owner of the card next uses the card, the system balance will be reset, in effect making the legitimate user commit fraud.
As mentioned above I have not told anyone else of these security issues, so that you have a chance to fix them before the public and any malicious parties become aware of them. I will be releasing
all information related to this research on 9th Nov 2013. Although I won't release any details before then, the title/summary of this research will be released prior to the publication. It is therefore possible others may attempt to recreate what I have found.
I suggest fixing these issues as soon as possible.
Companies and governments are informed about security issues everyday by independent researchers like myself, how you react to this information is of cause up to you, but below I outline the
recommended response.
The professorial response to being informed about security issue in one's system is to thank the researcher, fix the issue as soon as possible, and then inform the researcher when it is safe
to let the public know. The benefits to this type of response are: other researchers will feel comfortable about informing you if they find issues in the future. Good public relations as people see you fixing a problem as soon as you learn of it.
I assume you have skilled technical staff that will be able fix these issues. If you need further advice you might think of asking me, although I happy to provide more details of what I have
discovered in this research, I do not work for you and am under no obligation to help fix these issues. You might think of hiring me to do contract work, but that would be very inappropriate. If you do need technical advice on how to fix these issues, I recommend
contacting Lateral Security (http://www.lateralsecurity.com) or Insomnia Security (http://www.insomniasec.com), both well respected local
computer security companies.
Please respond to this email to confirm you received it.