Security Breach at M-PESA: Telco 2.0 Crash Investigation
Fraudsters have relieved a Safaricom M-PESA agent of 35,000 Kenyan shillings. This may not sound like a lot (about €340), in a business where figures in the tens of billions are routine, but it's a business-killing loss for a Kenyan reseller agent. In fact, it's equivalent to 26.8% of per capita GDP. With a savings ratio of 17%, it would take a typical Kenyan a little over 18 months to replace the capital loss. (Actually it's worse - there's no reason to think the savings ratio is evenly distributed. Usually, the rich save more, because they have money to spare.)
And if your business depends on thousands of reseller agents, anything that can wipe out their capital in 20 minutes is a serious threat. Therefore, security is a major challenge in delivering the promise of mobile money.
How it's meant to work
The cash-out process in M-PESA (in Kenya - some other deployments are different) works as follows; the customer approaches an agent and asks for cash. Then, the customer opens the M-PESA application on their device and initiates the USSD session with the network. The application running on the phone authenticates the customer's PIN and authenticates the device with the back-end. The OSS back-end processes the transaction. The agent's device initiates a session with the back-end and receives a message including a transaction authorisation code and the agent's current M-PESA balance.
This should rule out a number of attacks - as the devices involved are independently authenticated with the network, this should prevent one device pretending to be another to get access to someone else's account, and as the user and agent are authenticated with the devices, this should prevent someone pretending to be another user. Further, as the transaction process flow goes via the operator, you shouldn't be able to pose as an agent and accept deposits, or pose as a user and draw cash.
However, the security of the process depends critically on the agent being certain that the authorisation message comes from Safaricom. If an attacker could somehow deliver them a spoof authorisation message, they might be able to carry out a fraudulent withdrawal. Similarly, if an evil agent could somehow deliver a spoof authorisation message, they might be able to accept deposits fraudulently. A crucial element, therefore, is the distinction between the M-PESA application's user-interface context and that of the device's own messaging function.
At about 2 pm local time, on February 1st, 2010, two persons approached a reseller agent on the fringes of the city of Nairobi, about 24 kilometres from the city centre. They claimed to be Safaricom employees conducting an audit of the reseller and presented what seemed to be M-PESA publicity material and Safaricom identity documents. Such audits are carried out on a regular basis. They asked to see accounts, and left. It is not clear if they interfered with the device physically.
Some 20 minutes later, another man approached the agent and requested 35,000KSh in cash. He appeared to start the M-PESA transaction on a mobile device. Shortly afterwards, the agent received a message purporting to be an M-PESA transaction authorisation, which contained their current credit balance. They verified the man's name on his national identity card, and paid out 30,000KSh. Before the agent could hand over the rest, he signed the transaction slip and said he would return for the remaining 5,000. He left.
Some time later, another customer arrived. A valid M-PESA transaction was carried out, and the agent noted that the withdrawal of 35,000Ksh had not been recorded. They called 234 - the M-PESA agent support line - and reported a suspicious transaction. The call centre confirmed that no transaction had been recorded.
Previous frauds have occurred in which the fraudsters gained physical access to the agent's mobile device, and inserted a contact with the name "M-PESA" and a GSM number under their control into the address book. Therefore, a message or call from that number would appear as "M-PESA", although it would not appear in the user interface context of the M-PESA application. This permitted, up to a point, a spoofing attack. Of course, the necessity of physical access to the device - a so-called Evil Maid attack - restricts the possible scope of the threat.
In this case, it is reported that there may have been no such physical security breach. If this is the case, this renders the attack considerably more dangerous, as many agents could be simultaneously compromised at a distance. The most likely vector for such an attack would be that an "M-PESA" contact was inserted into the device address book remotely, as a vCard payload in an SMS message (most devices, including all Nokias, will open them automatically, although the Nokias at least will show a dialog asking the user if they want to add the contact to the address book). A large scale attack could use a GSM device or modem controlled by a PC, or more complicatedly, a software client sending SMS messages encapsulated in SIP. A really basic option would be to simply keep texting.
However, the attack fails if the M-PESA user interface is easily distinguishable from a normal SMS event, and it is actually distinguished by the user (not the same thing). Similarly, it fails if the message itself can be verified as being genuine or not. Various approaches are possible, but essentially all of them rely on a shared secret between M-PESA and the authenticating party. In this case, it seems that the authenticating party's balance is used as such a shared secret - the authorisation message should contain the correct balance after the transaction, which serves both to help the agent monitor their finances and to verify the transaction's genuineness.
This explains the role of the fake Safaricom employees. Without the need for physical access to the phone, you might wonder why they were needed, except perhaps as psychological reassurance or misdirection. In fact, it seems that they probably served to discover the shared secret and therefore to get the information required to create a convincing forged authorisation. As they asked to examine the agent's accounts, they presumably simply read off or calculated the current balance. (Perhaps they also sent the spoof contact to the device at the same time - under the guise of an "update" or a "test"?)
It's also worth noting that the attackers ingeniously made use of M-PESA's own security system - namely, auditing - to get the information they needed and to gain the target's trust.
The evil client, it can safely be assumed, didn't start an M-PESA transaction and instead sent his accomplices an SMS message telling them to send the forged authorisation.
Critical Points of Failure
The critical point of failure is undoubtedly in the user interface. The technical architecture of M-PESA provides a secure channel for transaction authentication and authorisation from device to device, using encryption, the SIM, and USSD. Attackers therefore targeted the section of the communication channel that runs from the device screen to the user's eye. The UI may need to be redesigned to make the distinction between the M-PESA user context and the phone's normal context more obvious, if at all possible implementing a poka-yoke function to force the correct process path.
For example, inbound SMS could be suppressed while the application is active - SMS is a store-and-forward technology and therefore no messages would be lost - or the notification of incoming messages could be turned off temporarily. This would require the authenticating party to start the application at the beginning of the transaction, which would itself require thought as to how to make this unavoidable. However, there are barriers to this example - a major criterion of acceptance by the Symbian test houses is that your application must not interfere with voice or messaging functionality. Another design issue is that users are likely to be unfamiliar with computers and at least some possibly illiterate.
Of course, the pretty UI in the screenshot above is all well and good, but not many Kenyans have iPhones.
A secondary point of failure is the use of the balance as an authentication secret. Is it sufficiently secret? Further, it may not be optimal to use a number that the agent has to record in writing as a shared secret. On the other hand, it's necessary for the agent to remember the secret, and the balance is obviously a number they are likely to know. Further, there is a useful feature here in that using the balance provides an automatic red flag - if it isn't what you expected, something is suspicious. On balance, this shouldn't be a problem if the user interface is fixed.
Impact and risks
A serious problem that this attack exposes is that the agents - critical to the entire system - bear a disproportionate fraud risk. Essentially, they're out of pocket. This has a number of downsides - for a start, the system depends on their confidence and on users' confidence in agents. If existing and prospective agents fear their capital might be wiped out, it will be harder to recruit and retain agents, especially as raising the capital to become an agent is a nontrivial challenge in itself.
Further, the agents' coping strategies against fraud risk are likely to harm M-PESA. The obvious countermeasure is to minimise the credit balance you hold with M-PESA and the cash float you keep on hand. This diminishes the liquidity and value of the entire system, the potential for collateral sales of airtime, and its value to the banking partner as a source of deposits. There is a worse one - if you have no protection against fraud risk, you also have an incentive to cooperate with the fraudster.
A limiting factor to the risks is that this attack is still only partly capable of being industrialised. It's possible to push spoof contacts out in large numbers, but discovering the credit balances of agents requires either a class break of M-PESA's Web or core-network security precautions, or else a fairly laborious social-engineering attack like this one. It's possible, however, that such a social-engineering attack might be carried out at a distance by voice or SMS, which would indeed be a major threat.
Conclusions and recommendations for action
M-PESA security is critically dependent on the device graphical user interface and process flow to prevent attackers spoofing transaction authorisations. A successful attack using spoofing and social engineering has been demonstrated which requires physical access to the target device. An attack which does not, and which is capable of at least some scaling-up, may have been demonstrated. Such an attack is certainly technically possible. Attention to the user experience is required to defeat spoofing.
However, second-line security measures constrain the attacker to use an expensive and risky social engineering exploit that requires their physical presence. Further, the attacker demonstrated that it was possible to defeat Safaricom's physical security by faking or acquiring stolen ID cards, uniforms, and publications.
Further, the management of fraud risk against agents requires attention to prevent it becoming a major threat to user and agent confidence in what is, after all, a quasi-bank. A refund process for end-users does exist, as discussed in this excellent blog post.
In general, MMT operators should be aware that it is certain they will encounter mischief and unauthorised innovation of some sort. It may be difficult to distinguish between user innovation and actual abuse - for example, how do we classify the Ugandans who are providing an unofficial M-PESA service where the real thing doesn't exist yet?