By Martyn Ruks
Anyone involved in security knows the old adage that as soon as you think you are smarter than the bad guy then you have lost you battle with them. After all it was Luke Skywalker that reminded us that overconfidence was the Emperor’s weakness when the rebels were caught in an imperial trap (Star Wars conspiracy theories aside for a moment). Likewise, anyone involved in cyber security within the payment industry will know this better than anyone else. No matter how sophisticated your solution and the security controls you implement, the more ingenious and creative the attacker becomes. Sometimes even those who are responding to security breaches in payment solutions have to sit back and applaud the innovative way their controls were breached by a cunning and resourceful attacker.
Back in the real world though we don’t want to find that our payment system has been compromised to the point where we have incurred significant losses either financially or reputationally. So what can we do about it? How do we anticipate what the bad guys will do without simply waiting until the money is gone and then seeing what they did to steal it? One answer to this problem is to design and implement a payment system, put it in a hostile yet controlled environment and then sit back and see what happens. So what better place is there to try such a thing than at HackFu. By now you should know all about this event and its purpose but if not then you can take a look here.
At HackFu 2014 we therefore built and ran our own payment system, for a number of reasons. These included the ability to have an in-game currency as well as seeing how some of the brightest minds in cyber security poked, prodded and attacked a payment system. In this article we share some of what we learnt from doing this, including how we designed and built the technology, how it was used at the event and more importantly whether it survived the onslaught from some of the best in the business at hacking payment systems. Let’s start out by describing what we wanted our system to achieve and then we’ll explain how we implemented it.
HackFu is a hacking event so first and foremost we wanted our payment system to be a challenge for the teams as well as providing us with an opportunity to learn about how they would actually attack it. We were also constrained by our limited resources both in terms of time and money, so we needed to be pragmatic about how we would do things. Therefore in terms of equipment we could use we had a back-end Windows server, some USB RFID dongles, MiFare Classic 1k RFID tags and some old, battered laptops to use.
We started out with a number of key objectives we wanted to achieve. The first was that we wanted the teams to focus on the payment processing, not on the back-end systems or networks. The latter are really important to protect but we wanted them out of scope or infeasible to attack in the time available. We also wanted the system to be hackable within the duration of the event, 48 hours, and we also wanted there to be logic based vulnerabilities that could only be found by thinking through the problem and using real-world observation to identify them. We also wanted there to be sufficient penalty for being caught as well as plenty of reward for succeeding.
From our knowledge of the way people behave and specifically how they approach events like HackFu we knew there were a number of factors to consider in the scenario we provided for the teams. We summarise these as follows:
The potential reward for a successful attack must be high, therefore if one team steals large sums of money they would win a large percentage of the points on offer from this challenge.
Anyone who is caught abusing the system must have negative implications for their team in the form of imprisonment or the individual otherwise being unable to compete in the other challenges for a period of time.
Investigation of the system and security weaknesses requires an understanding of MiFare Classic RFID tags as well as protocol and data format analysis and therefore needed to be learned.
Remembering that there are so many other things going on at the event and this is just one small part of the overall challenge so it can’t be too complex to discover the vulnerabilities and execute the attack.
Our payment system consisted of a fixed wired infrastructure solution, with a back-end server and six Point of Sale (POS) terminals that then used contactless technology for triggering the payments. These POS terminals were Linux laptops with a full screen (kiosk style) browser based payment application and a USB dongle RFID reader. The browser interfaced to a python application on the POS that handled the NFC communications as well as the back-end web service calls. Messing around with this application was out of scope to the contestants as we simply didn’t have time to protect the system from kiosk break-outs and physical tampering.
Each contestant at the event was issued an RFID wristband
that could be used to make transactions on any of the POS terminals as can be
observed in the images.
Each terminal was setup in an identical manner and allowed anyone with an authorised RFID wristband to query their account details as well as send money to any other user.
The high level architecture of the solution can be observed below as well as a photo of one POS terminal in situ at the event.
The POS terminals were all configured to interact with a back-end web service that was protected using TLS, client certificates and other network based security controls. By including these controls we were focussing people’s efforts on how the system interacts with the data held on the RFID cards themselves and any security weaknesses at that point in the payment process. The application running on the POS was designed to be easy to use and allowed individuals to make payments themselves without a third party merchant being involved.
If a user simply presented their RFID wristband to the reader then information about the user’s account would be displayed, including the amount of money in their account and their bank account details. Alternatively a user could select one of the three on-screen options illustrated in the following screenshot:The icon on the left enabled them to transfer money from their own account into the team’s vault (where it was guaranteed safe by the bank). The icon on the right enabled money to be withdrawn from the vault and moved into the user’s account. Each of these options required a single RFID wristband to be presented to the reader.
The middle icon enabled a transaction to be completed between two users and when selected prompted the users to touch their wristbands to the reader in turn before requesting a transaction value to be entered. The sender then had to confirm the transaction by touching their tag to the reader again. The system proved to be robust and with the combination of python application, .NET web services and SQL server back-end provided a 100% uptime and a back-end failed transaction rate of less than 0.5% The majority of these were caused by the user removing their tag from the reader too soon and when the tag was presented again resulted in the transaction being successful for the user. So the front-end success rate of transactions, where unauthorised activity was not attempted, was 100%. Not bad for a do-it-yourself payment system!
At HackFu 2014 the winning team was the one who gained the most points over the course of the event. So to incentivise teams to earn money (either legitimately or illegitimately) it was decided that a large pool of points would be allocated to this challenge and distributed in proportion to the amount of money in each of their team members’ bank accounts at the end. So if a team made lots of money through good business practices they would be rewarded for it but if they could steal large amounts of money they could gain an even bigger advantage and therefore earn a greater percentage of the points. The ultimate victory in this challenge would therefore be for a team to have all the currency in circulation in their accounts at the end of the game. In this situation they would win all the points allocated to this challenge for themselves. If this were to happen it would result in a massive swing in the gameplay and could determine who the final winner of the event would be.
In order to provide a realistic environment within which to operate the system, a basic legal framework was constructed that provided some ground rules for the team as well as acting as a genuine deterrent from attacking the system. The legal framework therefore consisted of a basic set of laws about what activities were permitted and which were not.
This was implemented in two different ways, firstly there were the detection mechanisms that were built in to the system that would automatically raise the wanted level of an individual if they tried to process a transaction that didn’t conform to the rules. Anyone whose level rose to the highest level would then have a bounty on their head, which could be claimed by the other teams at the expense of the perpetrator who would be locked up and requiring their team-mates to bail them out of prison.
The second aspect of the legal framework was a guarantee of all money stored within the team’s vault. This was a special account that teams could only move money to and from when using their team’s wristbands and could not otherwise be attacked. Or at least if it was the bank would guarantee their money so that they weren’t penalised for an unforeseen vulnerability.
Over the 48 hours that the event ran for there were a total of 507 transactions across the six payment terminals. There were 78 unique senders and 87 unique receivers of money, with one person being responsible for making 98 of the total transactions. The average value for a transaction was relatively consistent across each payment terminal and was in the region of $60 (for reference a frosty beer would cost you $3 in TJ’s Saloon). So this shows us that the financial system was used for far more than simply buying drinks at the bar. In fact the transaction stats match what we observed ourselves, namely that the financial system was used by the teams to trade information as well as to research and investigate the workings of the system itself.
What we also observed was that the large transaction volumes were concentrated within a core group of about 10 people. Transactions involving the transfer of large sums of money were also primarily the result of one individual out of total of approximately 90 attendees. Things get even more interesting when we look at the status of each transaction. The breakdown of these was as follows:
So that gives you an idea about the scale of the system and its use, so what about the really interesting stuff? How many people tried to compromise the system and how many succeeded? Before we look at what the scale and success of the attacks was its worth reflecting on how we expected people to find their way to “loadsamoney”.
In order to exploit the vulnerabilities in the system and steal money from other bank accounts there were a number of things that the teams needed to understand. All of these could be discovered from observation, using the system legitimately and then only after that, attempting to use it illegitimately. The logic behind the challenge was therefore as follows:
By understanding all of this information it would therefore be possible for someone to steal any money sat in another user’s account. The methods for doing this could either by shoulder surfing the data values displayed on a payment terminal or deriving them and using “intelligent” brute forcing. It was therefore possible for teams to steal any money that had not been safely stored away in the team’s own vault. Once teams had gained this capability the type of unauthorised activity that would have been possible would have created a hostile operating environment for teams to perform transactions in but with smart use of the team vaults, would not have led to widespread fraud or money stealing without falling foul of the law.
What teams may also have noticed though is that there was another fundamental vulnerability in the system that could be used to steal far more money and with far lower risk of being caught. To use this flaw the teams were required to spot the following:
As a result it would be the destination tag’s transaction identifier that was checked, all of this would be data that was known to the attacker. For the sender’s tag they would only need to know an account number and not a valid transaction identifier for that account.
As a result of this logic flaw in the payment system it was possible to transfer money from any bank account. By discovering the bank account numbers for some of the in-game characters it would then be possible to steal money from them that was not technically in circulation and thereby significantly alter the percentage of money in the possession of a team as well as increasing their bank balance.
So after placing a clearly vulnerable system in the middle of an event full of hackers, what did we see? The one key thing we observed was that the deterrent that was put in place was largely effective in preventing large scale or widespread attempts to abuse the system. This is evidenced by the level of casual unauthorised investigation that was attempted. Of the 80 unique users, only roughly 10% of them had a transaction fail for a security violation. That number would be quite high for a transaction system in use by the general population but for a group of hackers we feel that it is quite a low percentage. What was more evident was that the vast majority of these attackers did not attempt any further unauthorised activity, probably as a result of the warning messages returned and the other punishments in place as deterrents.
So, despite the potential big upside for any successful attack, the legal framework and resulting impact on the teams’ chances of winning the event clearly had an impact on security. However, as you might expect it did not stop the teams from attempting to attack the system. It was discovered that the most common reason for a transaction failing was the presence of an unauthorised identifier value being present on the card. This was observed in log messages where an attacker rewrote the bank account number on their card to another person’s but did not set the correct transaction identifier for that account. By observing the transaction logs it quickly became clear that the users who failed in this way had not correctly analysed the system and had not systematically sought to understand and document how the system worked. This is indicative of the opportunistic attacker, one who knows enough to experiment but who isn’t determined enough to break the problem down in order to find the weaknesses. These are therefore the easiest to defend against and to detect as well as being the most prevalent.
What was also observed was that whilst there were roughly ten opportunistic attackers at work there was only one persistent and determined attacker in the whole of the user base. Therefore, of the five teams who were investigating the system only one discovered enough of the information about its security to perform a successful attack.
Analysis showed us that this persistent attacker systematically sought to understand and query how the system worked. They completed numerous low value transactions and observed the results. They tested assumptions about the security controls and also attempted low value unauthorised use of this system. As a result of this they actually tripped the fraud detection threshold after making a number of failed transactions, something that ended up with them being arrested. However, given the low value nature of the crime and after being given a slap on the wrist they were released and returned to their team where they continued to attack the system.
After clearly pondering the reasons for the fraud detection being tripped, they refined their attack and eventually identified all of the vulnerabilities needed to steal lots of money.
Therefore, from roughly 80 active users of the system, only one of them fully implemented the attack described above. After stealing $1 million from an in-game character, plus a few hundred dollars from other teams, their team ended up with 99.9% of the money in circulation and therefore won the same percentage of the points that were available.
Payment systems will always be an attractive target for attackers and in our not-very-scientific experiment conducted at HackFu 2014 we showed that vulnerabilities in a system will be spotted and exploited by the bad guys when the reward for doing so is great enough. However, even within the context of a game we also showed a number of things that relate directly to real-world payment systems:
In our opening article we discuss how we see the problem space and what some of the challenges are so given all of that, what are we looking to achieve with this website.
As we said previously we don’t claim to know all the solutions but we are certainly trying things that will enable us to find them. Along the way we’ll learn lots of lessons, we’ll no doubt have a few false starts but we’ll also get some stuff right. It’s that journey that we’re going to share on this site, including all the initiatives and events that we’re planning to run to support it all.
We don’t know yet exactly what will be on this site but the one thing we’re certain of is that it will be thought provoking, philosophical, challenging and most importantly it will be fun and engaging. We’ll get techie at times, something we make no apology for, as well as extracting the concepts and key points that we encounter along the way.
We also want your help on our journey. We want you to tell us your thoughts and experiences of what we’re doing and hopefully some stories about how you’ve taken our ideas and turned them into your own projects, events and general awesomeness. We want to know the good, the bad and the ugly and to get involved please get in contact via Twitter and then keep coming back to this hub for more insight and information.
So hold on tight, this will be a wild ride for all of us.