The risk of changing a set of parameters is to assume that the attackers will not try to understand the method behind the change. The Docomo E-Money attack is an excellent example with obvious consequences.
First Published 7th October 2020
Connecting the dots… securely.
4 min read | Reflare Research Team
A major story in Asia this month, which has been largely unheard of in the west, is the theft of millions of dollars worth in Yen from bank accounts in Japan through the Docomo E-Money service. In this briefing, we will have a look at what happened and go into detail about the risks of changing parameters.
What happened?
Docomo is one of the three major mobile carriers in Japan. It is operated by NTT, the former national phone company. Like many other businesses in Japan which are currently undergoing a boom in mobile payment solutions, Docomo developed and rolled out its own payment service. While almost all payment services support the linking of credit cards, cultural and historical factors in Japan mean that they must also accept cash charges at convenience stores and linkages to bank accounts in order to be competitive.
The linkage function is the crux of the breach. Details are still sparse and the exact flow of the attack may never be publicly revealed. The following is our current working assumption based on the press releases made by Docomo and the affected banks.
To authenticate the payment app with bank accounts, several separate systems are in place. The exact systems used vary across banks. In order to authenticate users, many banks opt to either log in with online banking credentials or use a combination of account numbers, PINs and the exact balance printed on the last paper statement (not digital statement). However, some banks only rely on account numbers and PINs.
In a way, this is unsurprising. After all, withdrawing money with a magstripe card only uses the account number and PIN for verification as well. (In the vast majority of cases, the number on the card is encoded using well-documented algorithms and not secured with any form of encryption.)
Of course, the defining security feature of cash card withdrawals is that the bank tracks the number of wrong PIN entries and locks the account after a set number of invalid attempts. ATMs are also video surveilled, which further increases the risk for attackers.
It appears that either the banks or Docomo failed to implement a similar safeguard with E-Money. This led to attackers being able to simply try every possible PIN number before linking a bank account to their payment app. Account numbers themselves are often used for wire transfers and subsequently are easy for criminals to acquire. Four-digit PINs on the other hand only have 10,000 possible combinations. If no safeguards are in place, all possible PINs can be tried within minutes by specialized software.
After gaining access to other people’s accounts, the attackers then proceeded to steal money from said accounts. It appears there were numerous values across these transactions. There were cases where the maximum withdrawal amount of JPY 100,000 (US$950) was stolen, as well as incidents where only a few thousand JPY (a few dozen USD) were stolen. This indicates that several criminal groups were abusing the vulnerability at the same time.
After the issue was discovered, and following a short period in which both the banks and Docomo denied responsibility for the breach, the service was suspended by Docomo and the banks.
The danger of changing parameters
This breach illustrates one of the fundamental issues in information security. Something that is secure in one context may be insecure in another. And the exact contexts are often unclear. We do not assume that either Docomo or the affected banks were completely oblivious of the risk. Most likely, both sides assumed that safeguards against the brute forcing of PINs were in place on the other end. It turns out, they were not.
This scenario often leads to tension between infosec staff and developers when new software is audited. The auditors will correctly point out that a certain behaviour will pose a security risk if the software were to be changed in a certain way. The developers will correctly point out that no such change is intended and that fixing the issue is therefore unnecessary.
The problem, of course, is that such changes are usually done years later when the warnings are long forgotten and often after the original developers have long moved on to other companies or projects.