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!