Content

Latvijas IT drošības ziņu centrmezgls. Informācijas iesniegšana. Avota konfidencialitāti garantējam.

Internetbanku autentifikācijas protokolu un implementāciju drošības analīze

Kategorija: cert.lv + eparaksts + LVRTC + Personas dati

Abstract
In some European countries banks have taken the role of identity providers, providing identity services to external entities. The aim of this study is to define security properties required for protocols and processes used in this type of federated authentication, and assess the security of implementations employed in practice. The objects of this study are 11 major banks in Estonia and Latvia and their respective service providers. The findings show that required security properties are not provided in practice, thus making Internet bank authentication extremely insecure. Most of the banks were found to be using protocols vulnerable by their design. Security issues were discovered in nearly all of the implementations of service providers, and some implementations were even found to be vulnerable to a complete Internet bank authentication bypass.

7 Summary of Findings
This section contains a summary of the security issues found by this study. The security issues listed here have been enumerated according to their importance:
1. The service providers eparaksts.lv, lattelecom.lv, luis.lanet.lv, lursoft.lv, manabalss.lv and parkimine.ee have flaws in their signature
verification implementations: this allows a malicious user to completely bypass the authentication process.
2. Citadele (Latvia), Krediidipank (Estonia), Sampo (Estonia), SEB (Estonia), Swedbank (Estonia) and Swedbank (Latvia) use protocols that have a flaw in their design and therefore allow malicious service providers to use the received authentication tokens to authenticate to other service providers on behalf of the users. In order to prevent this vulnerability, the protocols must be updated to include a receiver identifier field.
3. Almost none of the banks outline sufficient requirements for authentication token verification in their technical specifications. As a result, the majority of the service providers fail to verify whether the token has been issued for the particular service provider, has not been received previously and is not outdated, therefore allowing an attacker to execute successful replay attacks and cross-site replay attacks.
4. Norvik (Latvia) and Swedbank (Latvia) for some service providers use an over-simplified protocol where only the personal data of the user are signed, thereby allowing everlasting replay attacks.
5. The Internet bank authentication of Nordea (Estonia, Latvia) uses a shared secret to check the integrity of an authentication token. Using this type of mechanism for integrity protection has a very high risk of shared secret leakage, and for this reason, it should be discarded.
6. Krediidipank (Estonia), Nordea (Estonia, Latvia), Sampo (Estonia), SEB (Estonia), Swedbank (Estonia) and Swedbank (Latvia) do not enforce the HTTPS URL and send an authentication token over an unencrypted HTTP channel.
7. Citadele (Latvia), DNB (Latvia), Krediidipank (Estonia), Norvik (Latvia), Swedbank (Estonia) and Swedbank (Latvia) could not confirm using HSM for generating and storing the RSA private key used for authentication token signing. Therefore, the risk of key theft is high for those banks.
8. Krediidipank (Estonia), Norvik (Latvia), Sampo (Estonia), SEB (Estonia), SEB (Latvia), Swedbank (Estonia) and Swedbank (Latvia) use a RSA signing key with the length of 1024-bits. The NIST recommends that the 1024-bit keys should not be used for the protection of data beyond the year 2010 [29].

The website of Swedbank has a link to the PHP sample code, which contains an example of signature verification. However, the sample code performs an incorrect return value check from the function openssl_verify(), and it could lead to a signature verification bypass.
http://www.swedbank.lv/lib/PHP_piemeri.rar (last visited 23.05.2012).

Interesanti, ka Swedbank links vēl aizvien darbojas.

This proof-of-concept video shows how the faulty implementation of Internet bank authentication can be used to bypass authentication in Latvian service providers eparaksts.lv, lattelecom.lv, luis.lanet.lv, lursoft.lv and manabalss.lv.

In this video personal identity code of famous Latvian hacker Ilmars Poikāns is used, however, it could have been anyone’s.

Avoti:
Arnis Paršovs: http://math.ut.ee/~arnis/bankauth/
youtube.com: https://www.youtube.com/watch?v=dpBKOcB414k

2012-09-24  »  edgars

  1. Irca Deops
    24 September 2012 @ 14:24

    Paldies par info.

    Ja kaadam vakaraa it gralaiciigi pavazaajaties ar Zed Attack Proxy pa LV lapaam CSRF probleeemas praaadisies daudz lapaas :) loti, loti daudz.

  2. juris
    24 September 2012 @ 14:54

    Tagad uztinam Nekā personīga un smaidam kā karina makaronus. Riski tiešām “ļoti teorētiski un dzīvē nerealizējami” :D

  3. sec
    24 September 2012 @ 15:28

    juris – pamēģini uzlauzt kaut ko izmantojot šīs “ievainojamības” un tad muldi.

  4. juris
    24 September 2012 @ 16:23

    sec – Arnis Paršovs varēja. Ir kaut kāds loģisks izskaidrojums kāpēc viņš vienīgais šajā pasaulē uz to ir spējīgs? Latvijā laikam tiešām nepilnības ir jāpierāda publicējot veselas DB, citādi visiem tie ir tikai teorētiski riski. Interesants ir jautājums – cik daudz info “izliekoties” jau ir iegūts?

  5. atis
    24 September 2012 @ 21:30

    Lol par Swedbank exampli, aizmirsa -1. Jautājums cik daudz kur tas strādā.

  6. antisec
    24 September 2012 @ 22:48

    Manuprāt šis ir daudz interesantāks un aktuālās video
    https://www.youtube.com/watch?v=9L1w2-9GWfE

  7. d-k
    25 September 2012 @ 16:10

    ļoti pat vērtīgs un labs pētījums!
    paldies autoram par ieguldīto darbu

  8. Liberālis
    25 September 2012 @ 16:26

    Video rullīši pagaidām neko īapšu nedod.. skiptu bērneļi tāpat aplauzīsies. Jo Jo varīgaikais šajā pasākumā ir autora izveidots tīmekļa ietvars, kurš ceru, no autora puses netiks izplatīts publiski :
    For testing the author used the browser plugin HttpFox [9], which provides an
    access to HTTP requests and responses, as well as a self-made web framework for
    token management, manipulation and replay.

  9. tusnis
    25 September 2012 @ 18:10

    Liberaali, proxis, plus cookie manageris un viss notiek. Piemeeram burp+foxyproxy

  10. d-k
    27 September 2012 @ 09:50

    Liberaali,
    Nav abosluti gruti ineta atrast tools kas atljaus formet HTTP requestus un manipulet un mainit tajos dazadakos parametrus.
    Es teiktu, ka sis ir tiesam samera viegls exploits un normalam IT specukam veicams ta rupigi pie sis problemas pasezot dazas dienas!

  11. Liberālis
    28 September 2012 @ 11:28

    tusni, d-k
    Jūs laikam neuztvērāt manu domu…IT specukam tas nav grūti modificēt un replay’jot htttp request un POST paketes.. es gribēju teikt tikai to ka ir labi jāorientējās šai saimniecībā, kas pamatā skriptu bēreļiem nav pa spēkam.

  12. d-k
    3 October 2012 @ 10:07

    Liberaali,
    nju atkariba ko mes katrs uzskatam par skriptu berneljiem :)
    un petijuma autors ljoti pat pareizu jautajumu uzdod – cik cilveku ir lidz so problemu noversanai veikusi Identity Theft? Un katram portalam to taka ar savam iesaistitajam bankam ir iespejams noskaidrot. Domajams, ka sada analize pat ja tiks veikta, diemzel netiks publiceta.

Re: Internetbanku autentifikācijas protokolu un implementāciju drošības analīze







Tags you can use (optional):
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>