*33C3 preroll music*
Herald: Next talk is gonna be “Shut up and take my money” by Vincent Haupert.
Vincent is a research associate at the security research group
of the Department of Computer Science at Friedrich-Alexander-Universität
in Erlangen, Nürnberg, Germany. Typical, very long German word.
His main research interests are authentication, system security
and software protection of mobile devices.
It’s actually Vincent’s second time speaking at the Congress.
Last year’s talk discussed conceptual insecurity of app-generated passwords
in online banking. This year he will discuss the practical aspects
and some successful hacks that, if I recall correctly,
took over entire bank accounts from users’ mobile apps.
With that, Vincent, over to you.
*applause*
Vincent Haupert: Hello again, thanks for the warm welcome,
and let’s dive right into it because we have a tough program.
Okay. First of all, online banking is something that affects us all,
because virtually everybody uses it. In traditional online banking,
we use two devices. One to initiate our payments
– and to log in with user name and password –
and another device to confirm transactions.
With the rise of mobile devices, app-based confirmation procedures became popular
like this app there. In the recent past,
what I have been talking about last year, it became popular
to implement those two devices in two apps. That means you only have
one single device and have two apps now
to authenticate transactions.
Last year I showed that this has severe conceptional drawbacks.
But this is not the end of it. The latest evolution in online banking
are now one-app authentication models. I already said this last year:
Actually, it doesn’t make so much difference. So banks are no longer faking
to have real two-factor authentication. It’s now clear that it’s just one,
so you do the transaction initialization inside the app
and the confirmation is just another dialog inside the app.
This time I want to talk about N26,
the shining star on the German FinTech sky.
Actually, this time I’m only going to be talking about technical issues.
It’s clear that we have similar conceptual problems like with two-app authentication,
but I will focus on technical issues because we have enough of this there.
Briefly about N26: N26 is a Berlin-based, “Mobile First” FinTech
and it plans to establish your smartphone as your financial hub
for everything, so that you do literally everything
from inside the app. Actually it was only founded in 2013,
it started in 2015 with their app and it already has over 200.000 customers,
which is astonishing, actually.
It now also has its own European banking license. It’s only, I think,
half a year ago; and it announced not even one month ago that it’s now
available in 17 European countries. And they also claim
that you can open a bank account in just eight minutes. As it turns out
you can lose it even faster.
*laughter*
Okay, let’s talk briefly about transaction security in the Number 26 app.
If you want to do a transaction, you at first need to log in.
This works with your user name, in this case it’s just your email address,
and your password. This is pretty standard.
Afterwards you are good to initiate a transaction. After you have entered
all the details you also have to supply a transfer code. This is just a four-digit
number, you use this also to withdraw cash. Probably you would call this ‘PIN’.
The last factor in this authentication scheme is you paired phone.
This is actually the most important security feature of the N26 account,
and you can only pair one smartphone with you N26 account.
That means, from a technical perspective, the N26 app,
the very first time you start it, generates a RSA key pair
and sends the public key to the N26 backend. And whenever you initiate
a transaction they are going to send an encrypted challenge to your smartphone
and you send it back decrypted. That’s how it works. Actually,
re-pairing, that means pairing another phone is a pretty well secured process,
but we will talk about this later. Just to talk about the infrastructure
of N26: basically they have two apps, one for iOS, one for Android,
and they communicate over a JSON-based protocol, TLS encrypted.
The backend is at api.tech26.de.
How do I know, actually, that this is a JSON-based protocol: because I used
a TLS man-in-the-middle attack to log the protocol.
I only needed to install a certificate, the MITM proxy certificate on the client,
but actually I was surprised that I didn’t need to touch the client, because
they didn’t implement any certificate pinning.
*applause*
So that means, the first thing that comes into mind is like:
Let’s do real-time transaction manipulation. That means we manipulate
a transaction that the user does, but we will change the recipient
and the user won’t see nothing about this. So if we look at this graphic again,
what if an attacker could get the DNS record of api.tech26.de under his control?
This would mean that all traffic is routed over the man-in-the-middle attacker server
and, as there is no certificate pinning, we could just issue a Letsencrypt
TLS certificate and the app is going to trust the certificate.
How does this work? Let’s take an example here.
Let’s image I want to transfer 2 Euro to my friend Dominik.
After I entered all the transaction details I have to enter my transfer code, too.
When I did this I get like the second factor where you need the paired device
and I need to confirm it. This is just like the next dialogue inside the app.
After I confirmed it, the transaction went through, everything looks good.
2 Euro less on my account, pretty good.
In the next step you can see in your transaction overview too, that
there are 2 Euro less. But after the attack when N26 realized that something wrong
was going on and they fixed it you will realize that we actually transferred
20 Euro, not 2. But this was completely transparent for the user
even after the attack. Okay, this is nice.
We can manipulate a transaction in real time, but
wouldn’t it be even more interesting to take over entire accounts
to do our own transactions?
For this, we need the login credentials, the transfer code and the paired phone.
So we need to obtain all of them.
Let’s start with the login credentials.
Actually, I want to assume, that the login credentials are already compromised.
But there are some weak points in the security system of the N26 transactions,
that make it an easier task to obtain those login credentials.
There are two things I want to talk about. The first thing is the recovery-from-loss
procedure. When you forget your password, N26 just sends
an email to your email account. There is a link inside, you click it
and you can just reset your password.
This breaks the N26 password policy
which is actually pretty solid, because if you have access to the email account,
you have automatically access to the N26 account, too
and the access to the email account could be as bad as “password” or “123456”.
Another idea is spear phishing. Think of spear phishing like a more targeted
version of phishing. What you always need for phishing is a similar domain,
something the user can relate to. And if you want to make spear phishing
you want to have it more targeted. That means you want to expose
N26 customers, so only send out mails to them. And you need to have
a valid reason to contact them. About the domain:
usually N26 uses number26.de; and for password resets
e.g. number26.tech. Sounds pretty valid in my eyes.
Only by chance I happen to own that domain. *laughter*
The next thing is exposing N26 customers. N26 offers
peer to peer transactions, that means if your recipient also has a N26 account,
those transactions are instant. To show the N26 customers
who of his contacts actually have an N26 account, they upload
all of the email addresses, all of the phone numbers in your address book
to the N26 backend. Unhashed.
*applause*
But we actually want to use this to identify customers of a given dataset.
We can actually abuse this API for that.
Do you remember the recent Dropbox leak that revealed 68 million accounts?
We evaluated all of those 68 million email accounts against this API
and N26 took no notice of this. There were no limits applied.
They just think, I’m really popular. *laughter*
*applause*
In the end, we revealed 33.000 N26 customers and could now send out
e-mails to them. Actually, this also provides a valid reason to contact them.
E.g. the usual e-mail of N26 looks somehow like this.
So we could say to them: “Hey, you are affected by the Dropbox leak, please
change your password for your own security. Click this link to change your password.”
Now I can already see the N26 management board nervous,
but don’t worry, we didn’t do this. My professor had legal concerns.
*laughter*
Now, that we have the login credentials, we have to wonder: Can we already
do something with those login credentials? And this brings me to Siri transactions.
With iOS 10 N26 now supports transactions using Siri. That means
now you can just say: “Send 5 Euro to Dominik Maier using N26”, then
the transaction pops up and you can say: “Send it” and afterwards it’s gone.
The app doesn’t even open. So this already sounds wrong,
*laughter* …but you can only do this with the paired device.
If you use another phone and just log in and try to use Siri with this,
this dialogue appears and you really have to open the app and have
to confirm it with the paired phone. As it turns out, this is just a client feature.
*laughter*
This is actually the entire payload you need. It’s just like “5 Euro
to Dominik Maier”, and there is the phone number. And look at this API endpoint,
‘/transactions/unverified’. So it turns out
you don’t need the paired phone to do this type of transactions.
*applause*
Yet another thing that’s interesting is that N26 claims that they have
some intelligent algorithms to immediately detect irregularities
and prevent fraud before it even occurs. So we thought: “Challenge accepted!”
*laughter and applause*
And what we actually did, and I think this is pretty irregular,
we sent 2000 Siri transactions worth 1 Cent within 30 minutes.
*laughter*
Try to speak that fast. Ok.
And so what happened? Like we waited the next day and the day after nobody actually
made contact with us, and we thought they would never actually make contact.
But over three weeks later N26 required Dominik to explain
the “unusual amount” of transactions. Okay, they even threatened to cancel
his account. I mean, this is actually… it’s reasonable because it’s a clear misuse
of the account and it violates the Terms of Service of them.
But Dominik didn’t send those transactions, he received them!
*laughter*
They contacted the wrong person! This is kind of like
if Gmail cancels your account because you received Spam!
*loud laughter*
*applause*
Okay, let’s go back to the account hijacking. And the next thing we need
to obtain is the transfer code and get the control over the paired phone.
What we will do: with the transfer code we will try to reset it; and
the paired phone we have to un-pair. Actually, those processes are
not as independent as it seems. So I will right start with the paired phone.
As I told in the beginning, un-pairing is actually a highly-secured process
and I mean, this is my serious opinion. So let’s look at the process.
At first, when you want to pair a new phone, like I said, you need to un-pair
the existing one. Therefor, you open the app, then you click at “Un-pair” and
afterwards they send a link to your email account. Then, in the e-mail
you need to follow the un-pairing link.
In the next step the real un-pairing process starts, where you
have to enter your transfer code first, then your MasterCard ID. This is something
that is kind of special for N26, like, every N26 account comes with a MasterCard,
and they have printed a 10-digit numerical token below your name. I don’t know
what this actually is, it’s not the PAN, it’s not the credit card number but
some other sort of token. So you need to have the Mastercard, actually.
And in the last step they’re going to send an SMS to you with a token, and you have
to enter it. And only after this process the un-pairing is done.
So that means we need to have access to the e-mail account. We need to know
the transfer code. We need to have the Mastercard and we need to own the SIM card
in order to receive the token. You can’t screw up each of those.
*laughter and applause*
Okay. Let’s go into it. So, the first thing: when you actually click
on that item in your app where it says “Start un-pairing”
it sends – this is basically HTTP GET request but you wouldn’t believe
that they send the link as a response. So – it’s not this plate (?)
but it’s there. So you don’t need to have access to the e-mail account
because it’s in the response. *laughs*
*laughter*
Okay. Next thing. The transfer code – I actually will skip this for the moment
and we’ll get right back to this. But the next thing is actually the Mastercard ID.
And this ID is printed on the card, and we don’t have access to that card.
So what will we do? In the transaction overview
N26 shows a lot of properties, e.g. the amount, the beneficiary,
whatever. And it turns out that this…
*laughter and turmoil* that they used
this Mastercard ID, they thought: “Oh, this is actually a nice ID, let’s use it
as a prefix”. So, again, this is not displayed to the user inside the app
but it’s clearly there in the API. It’s way too verbose.
So… *applause*
Okay. Whenever…
the step that I just skipped was this transfer code.
The transfer code is unknown. But you can reset the transfer code.
And it is – as it turns out – what you need to reset the transfer code
is the Mastercard ID. *laughs*
*laughter and applause*
So you need to enter this Mastercard ID
that I just told how we will get it and then we just will confirm
our new transfer code. Think of one, I don’t know. Any code.
And therefor we don’t need to know the transfer code. Not even the old one
because it’s not required. The Mastercard ID is sufficient.
Then. The last step. SMS. The SIM card is inaccessible.
We don’t have access to that phone. But this is a 5-digit token that they send out
and it’s only numbers. I mean this is 100.000 possibilities.
And even though the login procedure, the login form, has a brute-force protection
this doesn’t have any brute force protection. So…
*laughter*
…the maximum that I could get out of the backend was 160 requests per second!
*laughter*
So this means… *laughs*
*applause*
So that means that it takes on average approx. 5 minutes to get this token.
In the end we will just brute-force it and that’s it. Okay. That’s…
*laughter*
Let’s look if this really works. At first we will login to the app
just to see that it’s paired. And if it wouldn’t be paired we would know,
like, see a dialogue that we should pair our phone.
So now it opens. Great.
And now we will start our script.
And N26 claimed that this attack doesn’t scale, just don’t blink!
*exhales sharply*
So those are the login credentials *laughter*
…that will do all the fun. And actually, everything already happened, it’s just
the brute-forcing that now takes place. And I have to admit that I have been
really lucky this time because we are done now. *laughter*
So this is the response, now the SMS numeric token is valid, and the phone
has been successfully un-paired. Okay, now let’s verify in the app… if this worked
really? So let’s open it again. Touch-ID expired, so this is actually good.
That means that something happened. Let’s login with our password.
And there it prompts us for pairing the phone. So it worked.
*applause*
Yeah… *laughter*
This… even though I said that this attack really scales very well it has a drawback.
Because three mails are sent out to the user. The first one when you actually
start the un-pairing, the second one when you reset the transfer PIN and
the third one when the un-pairing is successful. And the user also receives
an SMS. But I mean fraud is perfectly possible. But is there a possibility
to avoid this? Let’s try to call the customer support.
The customer support is actually the most powerful entity in the N26 security model.
Because they can even change things you can’t change inside the app.
E.g. your email address, or name – you cannot change.
But they can. So let’s talk with them. They can… it turns out they can also
un-pair phones. So now the question arises of course you cannot just call there
and say: “Hey, my name is Vincent, please un-pair my phone.” Of course they
are going to authenticate you. And what… *loud laughter*
…and what will they ask? They will ask for the Mastercard ID. We know that.
The current account balance is always available if you have the login credentials.
Okay. There’s one thing that is still missing. Place of birth.
It’s always the same. *laughter*
It’s, again, you can’t see this information inside the app. It’s just not displayed.
But it’s there. There’s so much information you can’t think of.
Really, they know more about me than I do. *laughter*
Now that means we have all information available, and we can change any data.
And the user won’t receive any notice of that. So no email, nothing.
So we can just un-pair the phone, and later we can pair our own one,
or… this is perfectly stealth.
Now actually I heard already: “Ah, I only got 50 Euro on my account,
why should I care?”
This is actually a valid argument because many N26 accounts are opened out of
curiosity, and many are inactive, or not used seriously, that means you only use it
for travelling or paying things online because of the conditions.
But you don’t use it as the salary account so there is frequently not so much money
in it. But as this wants to be the financial hub for all the services
you of course can also apply for an overdraft. And this is an instant overdraft
that is granted during two minutes. And it’s between… you have guaranteed
50 Euro and up to 2000. This requires the paired device. What did we just do?
We have the paired device. We have the entire account.
So what do we do? We will just hijack the account
then we apply for an overdraft, and then we will take all the money
he has as a balance and as an overdraft.
So even if you don’t have money on your account and think you’re safe
you are not. *laughs*
Okay. This was quite a bit, something. I want to talk briefly about disclosure
before I will draw my conclusion.
I reported all these issues to N26 on September 25. I didn’t establish
the contact, this was the CCC. Thank you for that.
I did this because I didn’t know how N26 would react to this kind of vulnerabilities.
But, actually, there was no reason to think so. Because they acted
really professional. And they were actually thankful that I revealed
these vulnerabilities.
*applause*
Then, afterwards, they started to incrementally fix the issues.
I don’t know when they fixed the first thing. I didn’t monitor the process.
But the last fix I know of happened on December 13 when they implemented
certificate pinning on iOS. And, apparently, I have to say that
I didn’t check everything. But apparently all issues are resolved.
But what are the consequences out of this? It is obvious that N26 needs to put
more emphasis on security. It’s important to notice that this wasn’t a coincidence.
It simply wasn’t! And N26 needs to understand that it’s not enough to release
videos with caption “mobile first meets safety first” and to claim that security
is of paramount importance of them. So PR shouldn’t do your security.
It’s funny: If you visit the N26 home page you will find out that they currently have
44 open positions. Not even one is dedicated to security.
Furthermore, with such a strategy FinTechs squander the trust
in financial institutions that banks established over years, actually.
Today you usually trust in your bank that they will deal with your money
responsibly. And in the end you also need to question authorities. I mean
it was BaFin that granted a banking license to N26 only six months ago.
And, really, those vulnerabilities are in sight for longer time.
Okay. I think, like… résumé for this is:
you shouldn’t say “Works for me” when it’s about security.
So, thank you!
*applause*
Herald: Thank you Vincent. That was awesome. And also kind of fucking scary.
We only have a short time for questions. Is there anybody who has a question
for Vincent?
No, I guess everybody is out deleting banking apps.
*laughter*
Oh, number 6!
Question: Quick question.
Do you know whether they have disallowed those apps
that have not yet been updated to still manage their bank account?
So e.g. if someone has a mobile app that has not yet been updated
to the version that includes certificate pinning would that person
still be vulnerable to man-in-the-middle attacks?
Vincent: Yes.
*laughter* *laughs*
Actually they don’t have so much of an idea which device you are using.
They don’t even know which is the paired device! This is only a client value.
Herald: Do two more, it’s a guy here on number 1.
Question: Thanks for the talk. Did they actually invite you to help them
or give your talk at N26? Have they been in contact with you?
Vincent: Yes, we have been in contact and I also visited them and gave a workshop,
so yeah, they…
*laughter and applause*
Question: Are you serious?
Vincent: I am serious, yes! *ongoing applause*
Herald: And we do one last, one here, from number 5, please.
Question: So during your talk you name-dropped Letsencrypt, and
you kind of glossed over that bit, about getting them to issue a certificate
for their API host name. Do you know something I don’t?
Vincent: Ehm, the question, again? I don’t…
Question: So you mentioned getting a Letsencrypt certificate to impersonate
their API host name, because they weren’t using certificate pinning.
How did you go by doing that?
Vincent: But I didn’t do. This, like, was a scenario.
That’s an attack scenario. I didn’t hijack the DNS record, okay, sorry.
*laughs*
Question: Thank you.
Herald: Alright. Thanks everybody for joining. And get a big round of applause
here for Vincent!
*applause*
*postroll music*
*Subtitles created by c3subtitles.de in the year 2017. Join and help us!*