“Number26 PushTAN” or “When transaction verification is impossible”

A couple of months ago, I have dug into the security precautions of the Number26 banking application for Android. The flaw explained in this post is so obvious that the cows go home. I am surprised if this has not been abused by an evil party yet. Still, I am going to explain it in detail because the possible attack vector is infinite.

Disclaimer: After responsible disclosure two weeks ago an update is now available and I am happy to share my findings with everyone. Even though the deadline set with the responsible disclosure is not reached, publishing these details no longer puts users at risk.

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

And before I forget to mention: This statement was made before this vulnerability was closed.

8 thoughts on ““Number26 PushTAN” or “When transaction verification is impossible”

  1. Not showing the target IBAN is of course bad, and as a user of their services, I’m glad that this is now fixed.

    But your assertion that the system is not more secure than mTAN seems imprecise, at least on Android smartphones. It is roughly equivalent to the Push-TAN system used by some German banks, which is definitely a security improvement over mTAN:

    On Android, it is possible for apps with SMS permissions to intercept all incoming text messages, including those that contain a confirmation TAN. There are supposedly malware apps out there that do exactly that, some even working in tandem with their desktop counterparts to phish for login credentials on the desktop and intercept the confirmation SMS on the corresponding mobile.

    However, intercepting the confirmation messages of a bank using the “push TAN” pattern usually requires root permissions if implemented correctly.

    1. It does not necessarily require root. If an app has access to notifications (i.e. by claiming to provide extra function) and an app putting content in the dropzone (such as the Facebook Messenger chat bubbles, but bigger) can be enough to trick the user to release a fraudulent transaction.

      A side channel is only a side channel if it’s a channel on the side. Doing banking and authorizing on the same device always puts the user at higher risk. It is also notable that “root” is usually used for “rooted”. However there are dozens of privilege escalation exploits for Linux out there and once in a while they are also present on Android. The phone does not have to be rooted for an attacker to gain root privileges.

      1. You mean some kind of tapjacking attack? I agree, that’s a problem, but arguably one that can be fixed at the application level (e.g. by requiring a mandatory “complex” interaction like copying a number instead of just a button press, varying the “confirm” button location etc).

        The situation seems like a general security trade-off to me: A secondary confirmation device/channel would be even more secure, but speaking personally, I have my phone with me all the time – my ChipTAN device not so much.

        If you’re willing to do transaction initiation and confirmation on the same device at all, a well-implemented push TAN approach seems like a big improvement over SMS-TAN.

        1. I personally am not willing to do the initiation on the same device as the verification. That’s why I was so insistent that this inconvenience is fixed.

          The key to your statement is “Well implemented” – a state Number26 is still far away from…

          However, the real issue is, that many users don’t know anything about the implications of initiating and verifying on the same device. Sentences like “Our security algorithm monitors authorization requests and immediately detects irregularities. In this way, phishing attempts can be identified and blocked.” makes the user think that they are completely safe. I am certain that the attack described would not have been caught by Number26 immediately.

  2. Well,
    i do not see any reason why to make any big deal out of this?
    Sure – N26 did this not because of lack of coding/security skills/knowhow, they did this for convenience for their customers?

    UX/UI “experts” (gurus!) have told all product designers/builders/managers/etc. for the last decade to show minimum information, if possible, to prevent a confused DAU – obviously, N26 designers/developers took this “approach” too far? 😀

    Another thing is:
    Sending a “classic” mTAN over the GSM network usually involves costs – so its clear to me why they took the app approach, since the app can communicate through the data connetion more or less for free.

    Nontheless, i’ll stick with my classicc mTAN via SMS 🙂

    Regards

    1. Trading security for convenience? Yes, they definitely took it too far. Enabling MITM attacks by design is not a choice, you shouldn’t make a big deal about…

  3. Totally agree, horrendous service when it comes to fraud! There’s no 2 step verification, no mastercard secure code, causing me to lose more than 1000 euros and it’s been 2 weeks since I reported the issue and still there’s not a single cent back!

    1. How did this happen to you? I also have a pending fraud-issue but for a much lower amount. Still not sure exactly how it happened, but hopefully I’ll know after the investigation.

Leave a Reply

Your email address will not be published. Required fields are marked *