Austrian Mobile Phone Signature is vulnerable against phishing and MitM attacks

February 1, 2016

Update: As some people asked. I’m not saying that the mobile phone signature is not good. It is much better than simple username and password and it protects against attacks that work against username/password. Specially as many users reuse their passwords.

Talking with various people about the Two Factor Authentication (2FA) which is used in Austria to access public services led to my impression that most people think that the system is really secure. While it is more secure than a simple user/password combination its by far not that secure. In this post I’ll show how a simple phishing and man in the middle attack can be performed.  This is no 0day attack or something that runs through the media, it is just showing a design weakness which is not toughed up by mitigating techniques.

For your information: Most attackers don’t use 0days to get into systems, (spear) phishing is much easier and cheaper. The problem is that most companies and government agencies don’t take it seriously – as this case will show.

After showing the attack, I’ll provide methods to mitigate that kind of attacks – some are really easy and I don’t know why there are not deployed.

Background

Some text parts from the offical “Mobile Phone Signature or Citizen Card” webpage. The “important” parts are highlighted:

There are two alternative forms of the Citizen-Card functionality:

  • Mobile Phone Signature: This requires a ready-to-receive mobile phone. The Mobile Phone Signature works with all mobile phones and is free of charge.
  • Smart card: This requires a smart card with activated Citizen Card functionality (e.g. e-card) and a smart-card reading device.

Both alternatives can be used for the creation of legally valid signatures in online procedures. These signatures are legally equivalent to handwritten signatures. This way, the mobile phone and your activated e-card become your virtual ID, which can be used quite similar to your driving license. You have also the possibility to sign documents or invoices electronically with your Mobile Phone Signature or Citizen Card.

Yes you read correctly it is a qualified signature – which is:

The highest quality level for an electronic signature. Electronic Signature Act (SigG) § 4 declares that a qualified electronic signature is the legal equivalent of a written signature (with only a few exceptions such as e.g. Notary records).

So if an attacker is able to fake the signature he can get really far …..

Claims by the operator

From their  offical “Mobile Phone Signature or Citizen Card” webpage:

Mobile Phone Signature and Citizen Card are particularly reliable methods to identify oneself on the Internet. Both provide high security against

  • theft of access codes (such as phishing)
  • attacks through the network (Man in the Middle)
  • attacks on the computer (for example viruses)

…. hm that’s bold …. we should take a look at it ….

Basics

There is no legal difference between the signatures so most citizens by far took the easier and cheaper one, which is the mobile phone signature. So lets take a short look at how the mobile phone signature works from the user perceptive – which is enough for our purpose and attack.

  1. Go to a homepage which allows you to login via mobile phone signature
    citizen1
  2. After clicking on the “Mobile BKU”, I need to input my phone number and my signature password. The darker grey area is provided by the https://www.handy-signatur.at/mobile/https-security-layer-request/ website and not by the site I want to access.
    Update: Some sites redirect to www.handy-signatur.at and some include it as an iFrame.citizen2
  3. If these entries are correct I get a SMS, which contains a TAN which I need to enter into the website. The SMS looks like this:
    mobile phone signature
    reference value: yt7Zqb8aTZ
    TAN: 3As3Rz
    (valid for 5 min.)

    citizen3
  4. You’re logged in.

 

The attack

This attack assumes that the user is using a separated device to receive the SMS … otherwise the attack would be even easier. Following diagram shows the steps need to impersonate a user. citizen_card_blogpost-01

  1. The attacker sends a phishing email to the user. To make it more real lets be more specific. The attacker tells the user that there is something wrong with his taxes and that he needs to log into “finanz online” (tax and revenue office online portal) to fix it.
  2. The user clicks onto the link “finanzonline-bmfgv.at” or “finanzonline-bmf.at” which looks like the real one and even has a HTTPS certificate. How?
    Getting a domain validation certificate (and often free e.g. startssl or let’s encryt) is really simple and the domains are still vacant.
    freefree2
  3. The Man in the Middle (MitM) server requests a page from the site we want to log into. It is not necessary that this is the “finanz online” site. It can be any other which uses mobile phone signature and the users has access to. The request/response are needed to get the correct link/parameters for the request to the mobile phone signature server.
  4. The MitM server sends the user a fake “finanz online”. The mobile phone signature frame is relayed through the MiTM server which changes the traffic accordingly.
  5. The user enters the phone number and password and sends it to the MitM server,
  6. which forwards the data to the mobile phone signature server.
  7. The mobile phone signature server sends a SMS to the user,
  8. which the user enters into the HTML form and sets to the MitM server.
  9. The MitM servers sends that to the mobile phone signature server,
  10. which redirects him to the side he wants to get to.
    Important: That does not to be the site used for the phishing, as the SMS contains no information for the user to which site he authenticates.
  11. As nice add-on …. provide the user with a page that reports that the email was send in error and that everything is ok with his taxes.  😉

That’s not that complicated … it is done against online banking sites every day of the week and the mTAN for a banking can not be used for various other sites and so trick the user into thinking its only a “unimportant” site he is loggin into.

From the claims of the operator the first 2 are not true. And also the third is not valid, everything an attacker is able to do via a phishing attack is also possible via malware on the computer. He just needs to install his own CA onto the system and is so able to redirect the traffic to its own servers. In this case the attacker does not even need to register a domain or an official TLS certificate.  So all 3 claims are not correct.

Mitigation techniques

Here are some mitigations techniques. From simple to more complicated to implement:

  1. Tell the user in the SMS to which service he is authenticating for.
    This allows the user to make sure his authentication is used for the service he wants to sign in.
  2. Write the IP address and/or the provider name in the SMS to the user. Also add the country the IP address belongs to.
    If I’m a Telekom Austria or UPC customer at home I know that, or at least I know that I’m not a China Telekom customer.
  3. Send an email to user that he is used a new ISP, if the IP address is from an AS that does not match any old one.
    This way the user at least knows that something wrong happend and is maybe able to prevent something or go the police.
  4. With cooperation from the Austrian mobile phone providers it is possible to check if the phone is currently registered in the same country as the computer (SS7 network).

Following techniques need software on the computer:

  1. Provide a browser add-on which stores a secure hashed version of the signature password and checks every browser edit field if the mobile phone signature got entered into an 3rd party website. This also makes sure that the user is not using the password e.g. for facebook. 😉
  2. Browser add-on connects periodically (e.g. at the start of the browser) to the mobile phone signature server. If a login is performed from an other network/country block it or warn the user in the SMS.

All of the above won’t prevent all possible phishing attacks, but they will make them much much harder! As written in the beginning of this post, this attack is not some remarkably new one. It’s just about thinking the attack vectors through and some mitigations against them. I hope this post leads to a better security of the mobile phone signature server and all users and provides which use it.

7 Comments »

RSS feed for comments on this post. TrackBack URI

  1. The mitigations regarding to tell the User where he authenticates are already there. Your screenshot doesn’t show the LogOn-Data to Sign which indeed tells you what you sign (Link Signaturdaten).

    The reference value has to be the same like you get in the SMS. An educated User is able to detect that he is not signing the original Text when the MITM changes what he wants the User to sign.

    Indeed you are able to Intercept the Traffic to FinanzOnline by a MITM Server, but you can not fool an educated User to Sign a altered Document without having a good chance to check this before signing.

    Comment by Gunnar — February 2, 2016 #

  2. So the user needs to click on LogOn-Data after providing his credentials to see following values?

    Anmeldedaten:

    Daten zur Person
    Name: User Name
    Geburtsdatum: xx.xx.xxx

    Daten zur Anwendung
    Name: Name der Anwendung
    Staat: Österreich

    Technische Parameter
    URL: https://url_der_Anwendung/
    Bereich: PV (Personalverwaltung)
    Identifikator: xxxxxxxxxx
    Datum: 02.02.2016
    Uhrzeit: 19:37:06

    And why should a MitM server not be able to change the HTML to fit the user expectations? As user you don’t see the HTML from the real server .. you see it from the MitM server.

    The SMS is the second factor/channel … it needs to be used if the first (HTML) is intercepted so the info about the server, the user is logging into, needs to be there also.

    ps: “No” user in the real world clicks on the link and checks that data. And the users that click on that link wont enter their phone number and password in a phishing site in the first place.

    Comment by robert — February 2, 2016 #

  3. Hello Robert,

    The outlined exploit will not be possible with finanzonline, because there is no iframe used to embed the handy-signatur.at sign on frame.

    finanzonline is redirecting the user to a sign-on page, which in turn redirects back to finanzonline upon successful sign on.

    A real problem I spotted at a first glance is, that the responses delivered by handy-signatur.at do not contain X-Frame-Options header, which should be set to DENY or the domain of the embedding site in the examples mentioned by you.

    Since there must be other server-to-server communication involved (getting the personalization information based on the handy-signature.st session ID), I beg you to cite the original specification concerning these issues and outline in detail how the personalization data will be retrieved by your exploit.

    Moreover, you should obey old security researchers rule and build a demonstration site, so everybody can prove your claims.

    Best regards, Wolfgang

    Comment by Wolfgang Glas — February 8, 2016 #

  4. First there is no problem with finanzonline by itself, I just used it as example to build a story – replace it with any other site that uses the mobile phone signature to login. Secondly the user/victim never sees an original site, it gets everything from the attacker. While the X-Frame-Options headers are missing its not used by this attack, as the user gets a fake site anyways. Many sites don’t redirect but just us an iframe to include the handy-signatur.at content, so the user is used to seeing this.

    About server-2-server communication, the attack described doesn’t care. The MitM server plays the roll as web browser client. For the site and handy-signatur.at it looks like the MitM server is the client. The main problem is that many users think about the mobile phone signature as of a secure version of “Login with Facebook” or “Login with Google”. But the user has no way to know what he is signing, he just wanted to login to a website but in the background it used for something else.

    About the demonstration site – I though about it, but didn’t want to get into trouble and therefore did not build one.

    Comment by robert — February 8, 2016 #

  5. To me it’s much more annoying that some sites by A-Trust don’t work as the browser tells you that the site isn’t secured. Also “meinbrief.at” forces you to install the A-Trust-CA-certificate manually to even make it possible to access your documents (that’s rude and not a way which makes you feel comfortable because it simple doesn’t make you trust them). And even IF it would be possible (my old BK on e-card still works) i somehow doubt that my phone number is so securely stored, that no one could get my number or data from there since A-Trust seems not the company to trust because of the CA-problems i spoke about above.
    If you search for their encryption methods you can find them (if you look deep enough), but it doesn’t say anything about WHERE your data is encrypted (only from the browser to their servers, or if or how their hardware (like HD) is encrypted…)

    However, I have concerns about putting in all the data onto a web form on a PC – I guess, all you’d need is a key logger, for instance, right?

    Comment by Andi — March 5, 2016 #

  6. Hello Robert,

    seems your research has been stolen[ctrl+backspace]… uhm… “rediscovered” by Mr. Prentner who even made national TV news and heise 😉

    Congratulations…
    Peter

    http://tvthek.orf.at/program/ZIB-2/1211/ZIB-2/12853530/Sicherheitsluecke-bei-Handy-Signatur/12853532

    http://www.heise.de/newsticker/meldung/Oesterreichische-Handy-Signatur-anfaellig-fuer-Phishing-3222980.html

    Comment by Andi — May 31, 2016 #

  7. The same attack vector on heise online: http://www.heise.de/newsticker/meldung/Oesterreichische-Handy-Signatur-anfaellig-fuer-Phishing-3222980.html

    Comment by Simon — May 31, 2016 #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS. 76 queries. 0.259 seconds.