What is Number26?

Number26 is a mobile first bank account interface for their own bank account (the actual bank license is provided by Wirecard Bank), which provides a full featured SEPA bank account and a couple of payment cards.
This bank account uses a rather new method to verify that the initiated SEPA transactions were made by the correct owner of the bank account. To do so, the user first has to link their smartphone with the bank account, using information only known to the account holder. Once this initial pairing is done and a payment via the desktop browser is made, a push notification is sent to the mobile phone and the app is asking for confirmation showing this dialog:
Once the user taps on “Release” (“Freigeben” in the German version), the transfer will be approved. The technical details of how that is done are not publicly disclosed by the time of this writing, but my best guess is that something is being cryptographically signed and sent back to the server.
For those not familiar with SEPA transfers I’ll quickly explain the information you have to provide to initiate a money transfer:

• The recipient’s name (just for reference. Validity is never verified)
• The recipient’s IBAN (International Bank Account Number) and BIC (Bank Identifier Code).
• The amount to be transfered
• A payment reference / subject
• The transfer release pin (which is set once by the user when the bank account was set up)

Where is the problem?

The theory

Look at the information you have to provide to initiate a bank transfer and then look at the screenshot above. Usually, common banks™ use SMS to send a TAN (Transaction Number) to the owner of the bank account, stating at least the amount and some sort of recipient info (usually the IBAN) and ask the user to enter the TAN into the desktop browser to finally release the transaction.
This process has been streamlined with Number26. Instead of entering a TAN into the website received by the phone, the user has to release the transaction directly from the app, which opens once you tap on the notification you’ll receive. The app then shows the name of the recipient and the amount as shown in screenshot above. Once released the money is on it’s way to the recipient.
Stop right here… Let it sink in for a second…
So we just learned that common banks™ have their user verify their transactions. This is done by the user comparing the recipient’s info from the SMS with the info they have in their record, such as an invoice. However, with Number26, this verification is completely impossible as the recipient’s IBAN is never shown to the user once he initiates the transfer.

The attack

The attack on the desktop computer is rather simple. An attacker would install a malicious browser plugin or execute a man-in-the-middle attack exploiting computers with pre-installed insecure Certificate Authorities (see SuperFish on IBM or DELL). The attacking proxy or addon then waits for the user to initiate a bank transfer. It then secretly alters the IBAN and BIC in the background when sending the transaction request via the desktop site https://my.number26.de. Since the app does not show the modified IBAN (because it shows no IBAN at all), the user is in best belief that this transaction is legit and taps on release. In a sophisticated attack, the transaction history on the desktop would also be tampered with so the attack might go unnoticed for days.

The temporary workaround

Luckily I was able to keep using my bank account without being vulnerable to this attack. As a workaround, the user would have to create a standing order which executes the payment in the future (Terminüberweisung). After releasing the transaction it is reviewable in the standing order section in their app.

The Fix

After the update distributed on January 5th 2016, transactions have to be released with this new dialog:
The user finally has the possibility to verify the transaction on a separate channel, thus preventing malicious software on their desktop to secretly alter transaction data. An attack to SEPA payment verification now has to be much more sophisticated, i.e. by adding a rootkit to the potential victim’s cellphone.

Conclusion and personal note

What a clusterfail. It gets worse once you read Number26’s security information page. My favourite gem is this:

Partial screenshot of https://number26.eu/security/ taken on 2016-02-05 This states that TAN via SMS should be avoided for mobile banking because the text messages are sent to the same device that is being used for online banking. Number26, do you know that your method of payment release of mobile initiated transactions is just as bad as mTAN? This is the reason why from a security perspective you have to initiate transfers from your dektop instead of from the linked phone exposing you to the vulnerability that I just explained in length.
Fancy new user experience and a high security datacenter will never be able to protect the user if the design is flawed. Flawed? Broken beyond repair!

Communication with Number26

The support chat (a.k.a the bottomless pit)

Communication was always quite one-sided. I reported the issue to multiple support agentsover the course of six months, but all I ever heard was, “I am giving that to the developers”. I never heard back. So I upped the ante and told them that I am going to disclose my findings, when suddenly one support agent asked me to send a mail with the details to them, they will forward this mail to the developers. Success!
For full transparency, this is the email I sent to the developers – as always with no reply coming back. It just went into a black hole. But this time, an update to the app came back. Hooray!

My Mail to the developers

Dear Developers, Dear Product Owner,
after studying your mobile app and transaction release mechanism for a while, I have found a severe design flaw which lead to me coming up with a proof of concept how to unknowingly redirect transactions to unwanted destinations with little to no effort.
I am a big advocate for using responsible disclosure, as putting your customers at risk is neither in my, nor in your interest. However, this design flaw is so apparent, that I am baffled that it is not being actively abused yet.
I will outline the problem for you, so you can take appropriate action to prevent abuse of this flaw after the full release of my findings on Feb-22 2016. I feel it is my responsibility to inform the public about the risks involved and how to minimize them. Should you feel that nothing has to be changed, I’ll be happy to get a mail from you stating so, so I can release my findings earlier.
Here are the details:
When creating a bank transfer via the desktop website on https://my.number26.de, you are asked to enter
* The recipient’s name
* The recipient’s IBAN and BIC
* The amount to be transfered
* A payment reference / subject
* The transfer release pin
In the next step, a push notification is sent to the owner’s smartphone. In my case, it is an android phone. The user is asked to either approve or delete the request. The information provided for this decision is:
* The recipient’s name
* The amount to be transfered
And here lies the severe design flaw. The user does not see the actual IBAN/BIC that has been sent to the server.
In my proof of concept, a browser plugin (which malicious software could install) can secretly alter the recipient’s IBAN and BIC in the HTTPS request so the money gets sent to the bank account of the “evil hacker”. When releasing the transaction on the Android phone, the user has no chance to see that the transaction has been tampered with. Other banks using mTAN verification methods include the recipient’s IBAN and BIC as this information is more crucial than the recipient’s name. They also state in their mTAN terms, that the IBAN in the SMS has to be checked against the IBAN from the invoice document.
Multiple test transfers have shown that with a completely wrong recipient’s name, transfers are still successful. Further, another point of intrusion could be a transparent proxy inbetween. Sure, there is SSL and certificates, but we are seeing manufacturers adding weird CAs to their computers (see superfish), so some computers might be vulnerable to this kind of attack.
I have reported this issue as a regular chat via the customer support half a year ago. Nothing happened since, so I am taking this to the next level. In my full disclosure on Feb-22 2016, I will advise your customers to only create one time standing orders for a date in the future (i.e. tomorrow), so the content of the transfer can be checked with the phone after it has been released, but before it has been executed.
If you have any further questions, don’t hesitate to contact me. Unfortunately according to ***** [your support agent], you do not offer a pgp key for encryption, if someone else should pick up this conversation, I can not be held responsible for any earlier reporting about this issue. Should you use gpg nevertheless, we can upgrade the conversation anytime. Please use https://sks-keyservers.net/pks/lookup?op=vindex&search=0xCADA0055 as encryption key. I will also sign [my mails] with this key. Alternatively, you can call me at +xxxxxxxxxxxxxxxxx
Best Regards,
Christian Hawkins

No Comment

Unfortunately, Number26 was not available to me for a comment, whether or not there is an indication that this vulnerability has already been used.

But worry not…

…your data was always protected. For your amusement, a statement on the security of Number26.

Partial screenshot of https://number26.eu/security/ taken on 2016-02-05    https://metabubble.net/payment-cards-bank-accounts/number26-pushtan-or-when-transaction-verification-is-impossible/