Operation Charlie: Hacking the MBTA CharlieCard from 2008 to Present
June 2023 Update — Hardwear.io Conference Talk:
Introduction
The CharlieCard is a contactless smart card used for transportation fare payment in the Boston area. It is the primary payment method for the Massachusetts Bay Transportation Authority (aka MBTA or the T) and several regional public transport systems in the U.S. state of Massachusetts. Nearly 15 years after a group of MIT students first publicly disclosed security vulnerabilities in the CharlieCard, I am publicly disclosing that it is possible using only an Android phone to:
- Have a replacement CharlieCard delivered to a listed address, without paying
- Provision a new CharlieCard with funds, without paying
- Steal anyone’s CharlieCard with a single physical tap of the card against a phone in a matter of seconds
This post will tell the story of the CharlieCard, complex system design, how vulnerability likelihood and severity can change with rapid changes in technology, the importance of OSINT (Open-Source Intelligence) monitoring and threat intelligence, and the process of responsible vulnerability disclosure to a government agency without a Vulnerability Disclosure Program.
Prior Research
It is important to first acknowledge the prior research that has been conducted on the CharlieCard.
In 2008, a group of MIT students planned on appearing at Defcon and disclosing a set of vulnerabilities in the CharlieTicket (magstripe) and CharlieCard (Mifare Classic RFID card). The students were famously sued by the MBTA and were issued a gag order preventing them from disclosing the findings at Defcon. The conference slides would later be posted online and the students ultimately worked with the MBTA on remediating the issues (http://tech.mit.edu/V128/N30/subway/Defcon_Presentation.pdf).
As was disclosed by the MBTA in their public court filing in 2008:
The public never heard the outcome of the MIT students’ and the MBTA’s remediation work, however, one would assume that the publicly outlined issues were fixed.
Fast forwarding to 2011 — a man was arrested for selling millions of dollars worth of forged CharlieCards and commuter rail passes, but it turns out he was a subcontractor for Cubic Transportation Systems which manufacturers the MBTA’s CharlieCards, so the public assumed that he leveraged his internal access to carry this out. (http://archive.boston.com/news/local/massachusetts/articles/2011/05/20/alleged_ghost_pass_scheme_cost_mbta_millions_officials_say/).
In 2016, the MIT Office of Security Operations was doing some work on their MIT student ID cards which are integrated with the CharlieCard system — this allows students to use their ID cards to ride the T. The MIT Office of Security noticed that it was possible to clone the CharlieCard with RFID badge cloning tools used by those in the security and physical access control industries, such as a Proxmark. MIT shared this information with The MBTA. The MBTA, recognizing that technically sophisticated criminals might try and leverage this to distribute counterfeit CharlieCards as the subcontractor had in 2011, implemented a monitoring script on their servers. The CharlieCard keeps track of the number of rides taken on the card itself. Every time someone rides the T, a counter on the card is increased by 1. The monitoring script would watch for instances where a CharlieCard’s transaction counter repeatedly decreased rather than increased, signifying that the card had been illegally cloned and someone was using a cloned snapshot of that card from a previous point in time. A cloned card would be invalidated by the MBTA so that it could no longer be used. The MBTA also implemented monitoring for cards that responded to “magic” commands, which are a distinct feature of a type of Mifare cards that are manufactured in China and are often used for low-cost card cloning.
As explained by Lab401 “Many access control systems / RFID readers are now able to detect ‘Chinese Magic’ tags by sending the ‘Unlock Command’ (0x40 / 0x43). If the badge replies, it is flagged as an imposter/clone and rejected” (https://lab401.com/products/undetectable-mifare-compatible-1k-one-time-write-uid).
Legitimate CharlieCards do not respond to magic commands, so if fraudulent CharlieCards responded to the “magic” commands when tapped against an MBTA turnstile or fare machine, they would be invalidated by the MBTA. Though this information is not in the public sphere, I later learned of this from the MBTA during the disclosure process.
In 2019, a Boston-based security researcher at NCC Group named Will Enright quietly published a PDF on his personal GitHub page, outlining research he had conducted on the CharlieCard (https://github.com/ncc-wenright/Publications/blob/c05c7473cdaab54a6bd085c78a8960f5170ce878/CharlieCard_Research_BlogPost.pdf). I learned of Will’s research from a former colleague of mine, after my research had independently been completed and after I had already disclosed my findings to the MBTA. Will’s research is an excellent technical breakdown of Mifare Classic technologies and the CharlieCard and I highly suggest reading through it. In the final paragraph of his research, Will outlines that many of the key problems that MBTA had in their 2008 court filing still exist. Will alludes to the fact that it may be possible to ride the Boston subway without paying by leveraging mobile NFC technology, but does not provide further details. Will shares how he did attempt to share his technical report with the MBTA but did not receive any response from the email addresses he contacted. The MBTA was perhaps already aware of the content of the majority of Will’s research following MIT’s 2016 disclosure.
Vulnerability Discovery Process and Tool Analysis
In this section, I will walk through my independent vulnerability research, and what specific information I am bringing to the public that was not detailed in prior research.
First, we need to analyze the available tools on the market today in 2022, that were not available in the years of prior research since 2008.
Historically, only those with the technical knowledge of badge cloning tools like the Proxmark could conduct security research or criminal activity on transit system cards. Transit system designers who utilized insecure Mifare Classic technologies and systems of stored value on their transit cards, weighed the cost, time, and effort that an entire system design would take, against the likelihood that fraud might take place and the monetary cost of that fraud, and decided to keep existing insecure systems. A true modernization to a more secure transit system would involve shifting from Mifare Classic to a more modern card technology, implementing internet connectivity in all of their subway cars, and implementing server-side storage of transit funds instead of stored value on the card. One could argue that the likelihood of an average citizen of greater Boston conducting a hard-nested cryptography attack with a Proxmark against the CharlieCard is quite small.
All companies, not just transit systems, are constantly making assessments of a vulnerability’s overall risk based on several factors including impact, likelihood, ease of reproducibility, and more. However, these factors are not static but rather change over time based on changes in publicly available tools and technologies.
In 2020, a product was posted on Kickstarter called the Flipper Zero (https://www.kickstarter.com/projects/flipper-devices/flipper-zero-tamagochi-for-hackers). The Flipper Zero is a brilliant tool that allows hackers, hobbyists, and tech nerds to analyze technologies including radio signals, Bluetooth, infrared transmissions, and more. The Flipper burst onto the scene, selling nearly $5 million of Flippers, with the first units being shipped out in 2021.
One advertised feature of the Flipper was the ability to analyze NFC cards, which I was particularly interested in, given the number of old transit cards, hotel room keys, arcade cards, and employee access badges sitting in my desk drawer.
When my Flipper Zero arrived in the mail in July 2022. I decided to tap my CharlieCard to it, simply to see if the Flipper Zero would recognize it.
My Flipper Zero recognized the CharlieCard as a Mifare Classic card. It successfully reads the card’s UID value as “14 FC 6C 3F”. If we convert 0x14FC6C3F to decimal notation, the value is 352087103 which is printed as the card number on the front of the CharlieCard.
I will not go into great detail about Mifare Classic technology as it has already been well documented. Suffice it to say, Mifare Classic cards are protected by 32 separate encryption keys. If someone has access to the 32 encryption keys, they can read the content of their Mifare Classic card. There are a variety of complex cryptographic attacks that can be carried out against Mifare Classic cards to obtain the encryption keys, but the most basic attack, which the Flipper Zero supports, is a brute-force attack where a user iterates through a list of common encryption keys to see if their card utilizes any of them for the 32 encryption keys.
After leaving the Flipper Zero with the CharlieCard for a few minutes, the Flipper Zero was able to find all 32 encryption keys, and I was able to save a dump of the hexadecimal values that are stored on the CharlieCard.
This immediately raised the question, why was the Flipper Zero able to guess the CharlieCard encryption keys, but none of the other NFC/RFID cards I tested? Was the CharlieCard re-using a set of encryption keys that another company or transit system was using? Was the CharlieCard using 32 of the same encryption keys so if one was successfully guessed, they were all successfully guessed? Was the CharlieCard using the same set of encryption keys across all CharlieCards?
I decided to pause and dive into the Flipper Zero firmware which is public, open-source, and available on GitHub.
The Flipper Zero firmware seems to include keys from a variety of Pastebins and GitHub repositories.
One of the first encryption keys utilized by the CharlieCard can be found at the beginning of Block 3 of my card’s hexadecimal output, “30 60 20 6F 5B 0A”. Searching for this key within the Flipper Zero firmware keys list, that key is found as being pulled from a “proxmark” repository of a GitHub user iceman1001.
Visiting iceman1001’s “proxmark” repository, we see a list of Mifare Classic Keys from a variety of sources.
Looking for the CharlieCard key “3060206F5B0A”, we find that the entire list of CharlieCard encryption keys is included in iceman1001’s repository, and labeled as coming from the MBTA’s CharlieCard.
Looking at the repository commit history, we can see a user “tuxthemadpenguin” (a subtle nod to the Linux logo) made a commit to the repository on February 19, 2018, called “Adding MBTA keys — same for every card”. These CharlieCard encryption keys, which “tuxthemadpenguin” likely recovered through a more complex cryptographic attack using the Proxmark device, were then copied from iceman1001’s repository to the Flipper Zero firmware.
Tapping a few more CharlieCards I had against the Flipper Zero, I could successfully access each one, confirming that the same set of encryption keys was being used across all CharlieCards, and the Flipper Zero came preloaded with the list of keys.
I then wondered where else these encryption keys might be used other than the Flipper Zero device.
Modern Android phones have NFC chips for mobile payments and access control systems. A list of Android phones that have the necessary NFC chips to read the frequency of Mifare Classic Cards can be seen below:
The most popular Android application for debugging and developing Mifare cards, with over 500,000 downloads, is the Mifare Classic Tool app.
The Mifare Classic Tool app supports the same brute-force attack that the Flipper Zero does.
The Mifare Classic Tool’s source code is open-sourced like the Flipper Zero’s firmware.
Looking through the application source code and commit history, we can see the app developer copied and pasted the MBTA CharlieCard keys from iceman1001’s repository and added them to the Android application on February 25, 2018, 7 days after tuxthemadpenguin first committed them.
Returning to the Flipper Zero, since we have all the CharlieCards of the encryption keys, we can view a hexadecimal dump of any card.
We can view the UUID and the card serial number in the first line of the CharlieCard dump, however, it remains unclear what the other hex values on the card mean.
Having a hex dump of a blank CharlieCard as a control to compare to, would help decipher the content of my CharlieCard. However, the card dispensing vending machines can only distribute CharlieCards with funds on them. Digging through the MBTA website, I discovered that the MBTA has “retail locations”, or small businesses in the greater Boston area that sell CharlieCards to those who don’t live near a fare vending machine (https://www.mbta.com/fares/retail-sales-locations). I was able to visit my local MBTA retail location, where I obtained a free, blank CharlieCard not loaded with any value.
Now I could compare, side-by-side, a blank card dump with a loaded card that I put $2.40 on for testing purposes.
Using https://www.diffchecker.com, I compared the $0.00 card hex with the $2.40 card hex.
Immediately, the middle of line 13 jumps out. Analyzing the highlighted values in the middle of line 13, we see the hex of the card with $0 on it on the left has the value “00 00”. The hex of the card with $2.40 on it on the right has the value “01 E0”. “01 E0” can be read as hex 0x01E0. 0x01E0 is equal to 480.
480 divided by 100 divided by 2 = 2.40 or $2.40.
Though the MBTA is obfuscating the card value, the value of the CharlieCard is still present and stored on the CharlieCard.
This aroused my suspicion that the CharlieCard was still using a system of stored value, but more testing was required.
Exploring the MBTA website further, I discovered a “MyCharlie” site, which allows CharlieCard holders to link their card to an online account (https://charliecard.mbta.com/CharlieCardWebProgram/pages/charlieCardCenter.jsf). This allows CharlieCard holders to replenish their CharlieCards online, which goes through the next time the card taps an internet-connected fare machine or turnstile.
The “MyCharlie” site also includes information about the amount of funds on your linked card, If one’s card gets lost or stolen, one can call the MBTA and have a new card sent with the value that one’s card was last registered as having.
I was curious to see if I could control the value of my “MyCharlie” account, and arbitrarily give myself more or fewer funds utilizing my Flipper Zero. The Flipper Zero has an emulation feature, allowing you to emulate a Mifare Classic card of a captured hex dump. The Flipper Zero does not yet support Mifare Classic writing, only reading, so the Flipper can be tapped against a fare vending machine to check a balance, but cannot be used to ride the T, as this would require the ability to write to the Flipper and decrement the stored value.
I took a CharlieCard with $23.60 on it and captured the contents onto my Flipper Zero. I then loaded an additional $36.75 onto the actual CharlieCard.
So, I had an actual CharlieCard with $60.35 on it, and I had a Flipper Zero snapshot of when $23.60 was on the card. After I loaded my card to have $60.35, I saw that my MyCharlie account reflected this balance and showed the fare machine I visited.
I then returned to the fare machine and tapped my Flipper Zero to check the balance of my “card”. The fare machine showed that my “card” had $23.60 on it. I returned home, checked my MyCharlie account, and saw that my account balance now reflected $23.60. I had just lost $36.75!
I once again returned to the fare machine and tapped my actual CharlieCard to return my account balance to $60.35, and sure enough, when I went home, my MyCharlie account once again registered $60.35.
I had proven that I could arbitrarily add and subtract funds from my MyCharlie account and the MBTA servers were treating my CharlieCard as the source of truth for the amount of value I had, instead of the reverse.
In theory, I could take a snapshot of a card with $100 with the Flipper, utilize the $100 card until the balance hit $0, return to the fare machine and tap my Flipper Zero snapshot of the card when it had $100 on it, call the MBTA to report my lost card, and they would see I had a $100 balance. The MBTA would send me a new card in the mail with $100 loaded onto it along with a fresh card UUID and serial number. This method:
a) Bypasses any ride counter checks, as I would never actually have to ride the T with a cloned card, I would simply check my balance at the fare machine and then leverage their system design to request a new card.
b) Bypasses any “magic” byte checks as I would never have to clone the CharlieCard contents to a Chinese cloned card — I would simply emulate the card with my Flipper Zero NFC chip.
c) Bypasses any cryptographic checks the MBTA may be conducting against the card, as I would not alter the card serial number, stored value, etc.
While leveraging the Flipper Zero was certainly interesting, I was still curious as to how other more widely-used devices, like an Android phone, could be leveraged to achieve the same end goal.
I first thought back to the Chinese “magic” cards — the MBTA first implemented this magic byte checking in 2016. Was it possible that since then, the technology had evolved and a newer version of the Chinese cards had been produced that didn’t respond to magic bytes, but were still UUID writable, meaning that the entire contents of a CharlieCard could be written to a cloned card but would be indistinguishable from the real card in the eyes of the MBTA?
After a bit of online research, I discovered a newer form of Chinese Mifare Classic cards that did just this and were sold by many major online retailers in a pack of 20 for less than $20.
Lab401 does an excellent job explaining the differences in cards and outlines how these Gen 2 UID Clone Cards are compatible with the Android Mifare Classic Tool or “MCT” Application we showed earlier.
Utilizing the Mifare Classic Toolkit app, I could theoretically capture a dump of a real CharlieCard, write it to a blank card I purchased online, repeatedly ride the T, and then once I emptied my funds, replenish by writing the dump of the real card back to my blank card. Additionally, I could write to multiple cloned cards and either distribute or sell them.
Since we do know that the CharlieCards all use the same set of encryption keys, we can create a keys list in the Mifare Classic Toolkit app containing only the CharlieCard encryption keys. Employing a newer Android phone like a Samsung Galaxy or Google Pixel which has impressive computing power, we can iterate through the keys list, and access any CharlieCard we tap our phone against in 5 seconds or less. This means a criminal could repeatedly steal people’s CharlieCards with only a tap of their phone against a rider’s bag, wallet, or card holder, write the contents to a blank card, ride the T until they get caught and the card is deactivated, and then repeat this process over and over.
“Stealing” my own CharlieCard with an Android Phone and the MCT App
Reporting Process and Legal Questions Raised
I reached out to the MBTA by filling out the contact form on their website, asking if they had a vulnerability disclosure program. I ended up receiving a reply from the MBTA’s security team stating that they did not but would like to have a phone call with me to discuss this further.
After a productive call with the MBTA and some emails back and forth, I quickly realized that there were important questions that needed to be clarified legally before both sides could move forward:
1) Under what circumstances am I permitted to publicly disclose this information with legal safe harbor?
2) What does resolve or mitigated mean with regard to the systemic issues in the CharlieCard design?
3) What if the MBTA ultimately decided they were either unwilling or unable to mitigate the CharlieCard issues?
Despite the increased protections in today’s legal system for security researchers, the MBTA has a legal team with a track record of suing a group of security researchers, albeit 15 years ago. Thankfully, I was able to get in touch with the Harvard Law School Cyberlaw Clinic, which is a legal clinic committed to providing pro-bono legal services to clients on issues relating to the Internet, technology, and intellectual property. The Clinic team (led by Kendra Albert) advised me in the negotiations of the above questions with the MBTA and provided insightful guidance and legal counsel leading up to this public disclosure. Terms with the MBTA were ultimately reached and we had additional, productive conversations around mitigations.
Key Takeaways and Suggested Remediations
The MBTA did not have any short-term plans to implement a complete system overhaul, despite initial public discussions beginning this year about potential future CharlieCard designs and the AFC 2.0 system continuing to roll out through 2024 (https://commonwealthmagazine.org/transportation/mbta-seeks-to-charge-3-for-new-charlie-cards/). The MBTA can speak in more detail about their detection efforts, however, I suggested, and the MBTA did implement the following short-term detection measures as a result of this collaboration:
- Improved system monitoring efforts for fraudulent rides
- Increased headcount of personnel dedicated to this system monitoring
This research and the vulnerability disclosure process, highlight a few key aspects that transit authorities as well as all large-scale system designers and maintainers should keep in mind:
1) Having a Vulnerability Disclosure Program is essential and provides white-hat, ethical hackers the freedom to report vulnerabilities without legal consequences. As the MBTA is located in Massachusetts, and as I am a Massachusetts resident, Harvard Cyberlaw Clinic was able to legally represent me, but the majority of security researchers are not afforded the same access to free, if any, legal counsel.
2) Large-scale system design and maintenance is complex. Technologies are rapidly changing and consequently, the threat landscape is rapidly changing. The more offensive security minds that can be in the room during system design and maintenance, the better. If system designers can think like attackers and regularly conduct threat models that analyze their exposure, they are more likely to stay one step ahead of malicious hackers and criminals.
3) Trying to keep up with threat actors is extremely difficult. One tool that all organizations must utilize is threat intelligence and OSINT monitoring. Threat intelligence not only allows organizations a way to respond quickly to potential threat actors, but it also affords them an opportunity to try and stay one step ahead of attackers, and implement protections and mitigations for cyber issues before they are actively exploited in the wild. In this particular case, had the MBTA been conducting OSINT monitoring, they may have found:
- The encryption keys were uploaded to the GitHub repository in 2018.
- The existence of new Chinese Mifare cards that were writable but did not respond to magic bytes.
- The Flipper Zero Kickstarter launch and Mifare Classic Toolkit app rollout would make it easier for the general public to research the CharlieCards.
Closing Thoughts
I would like to thank the MBTA and their security team for their cooperation and prompt communication throughout this research process. The MBTA was highly receptive and engaging, and repeatedly expressed appreciation for my efforts as a white-hat security researcher.
Special thanks to Kendra and the remarkably talented law student team at the Harvard Law School Cyberlaw Clinic, who offered invaluable guidance throughout this enlightening process.
Bobby Rauch
Twitter — @bobbyrsec
bobbyrsec.com
The above article reflects research and analysis which I performed independently of my employer. This publication does not represent the views of my employer or past employers.
