Disecarea unui atac de tip phishing destinat unui card BCR

By vlad July 31, 2021 Securitate, Tehnologie 0 Comments

In ultima vreme pe serviciul de mail de la yahoo, dar si gmail, ajung dubiosenii care au trecut de la rangul de simplul furt al unui cont de netflix incercand in chiar ultima faza sa fure si cardul ca o cireasa de pe tort.

Insa acum se pare ca au devenit tot mai pe fata si nu se mai ascund in spatele unor iluzii asa ca ataca direct contul bancar/ cardul atasat prin niste scheme de phishing care sunt din ce in ce mai aproape cu realitatea privite dintr-un unghi non tehnic.

Luam cazul cu un mail primit ce are ca titlu “Contul dvs este inchis in prezent” ce apare ca fiind trimis de la “Romanian Commercial Bank – BCR”. Ce are ca si continut :

Contul dvs. a fost interzis!
Începând cu 21/05/2021 vom lansa un nou sistem de securitate. Trebuie să-l activați pentru a vă utiliza contul mai sigur. Contul dvs. este închis în prezent, vă rugăm să activați noul cont pentru a vă deschide contul.

Nu este un capriciu, ci o cerință a tuturor băncilor:
Actualizarea informațiilor clienților noștri ne ajută să ne angajăm în activități bancare responsabile și să evităm problemele viitoare.

La prima vedere totul pare ca are sens, contul a fost interzis, se implementeaza niste masuri de securitate la BCR, mailul apare ca avand un logo al BCR, textul e corect gramatical fara greseli evidente si ca printr-o minune sa consideram ca persoana care a primit acel mail chiar are si un cont la aceasta banca.

Daca toate cele mentionate mai sus se intrunesc, continuam cu un button mare albastru in josul paginii ce ne-ar ghida spre acea pagina de setare a lucrurilor. Si de aici incepe adevarata cacealma.

Trecand peste faptul evident ca foloseste un logo total aiurea cu o banca din Costa Rica se poate observa un form de logare ce contine doua input-uri: Utilizator si Cod eToken/Token. Daca cineva are un background in banca asta stie ca de obicei se foloseste intr-adevar un eToken si nu o parola. Asa ca lucrurile se cam bat cap in cap, adica logo-ul e aiurea, insa form-ul bate cu realitatea.

Un alt lucru interesant este ca pe acel link exista niste parametrii care nu sunt aleatori:

https://conisoc.notovoca.com/soporte/plataforma/identidad/api/v4/account/login/?inipos=5546532156545468886454651256656663215465487954645497546&emanuius=35564ipos

acel inipos are o valoare definita pentru tipul de atac probabil folosit pentru a identifica resursele aduse, ex. pagina de login pentru BCR

In spatele acelui form se observa ca pe executarea lui se face un POST catre ceva folosind atributele probabil dupa name: user, pass.

<form action="/soporte/plataforma/identidad/api/v2/account/login/" method="POST"><input type="hidden" name="csrfmiddlewaretoken" value="VpdrVozKGFLcEZKH3QpnssaslT0hHPim4OgCYSR9iUEU7f6Eknt7f9f4bz9K107o">
                    <input type="text" name="user" class="champ" placeholder="Utilizator" maxlength="16">
                    <input type="password" name="pass" class="champ" placeholder="Cod eToken / Token" maxlength="7">
                    <input type="submit" value="Autentificare" id="button" maxlength="3">    
                </form>

Dupa executarea form-ului se face intr-adevar un POST pe:

/soporte/plataforma/identidad/api/v2/account/login/

Cu parametrii pe request:

csrfmiddlewaretoken: wWBP8Zjw7W3lhlVjc6J6Gk7ikisXDKOkFlE0btBVJbW3KBhgtDNQt1cUaYBqXVDm
user: xxxx
pass: aaaaaa

In acel moment se si ataseaza un cookie extras din csrfmiddlewaretoken in acea sesiune:

cookie: csrftoken: fndXi7OBEyPnVuRmtnNyDQrO4aqttWafoMg8lB60gNI5oKdjKURiqxwqUQzWN7Zh

Folosita pe headerul requestului urmator de GET pe:

/soporte/plataforma/indentidad/api/v2/account/login

Ce raspunde cu un alt template in care sunt cerute datele acelui card:

<form action="/soporte/plataforma/identidad/api/v13/account/login/" method="POST"><input type="hidden" name="csrfmiddlewaretoken" value="5WzBOP8AeIGSYixnwcEUKN5Jn4gUUsjuelCMRjqZQXzAryTkNJIExualdKpneD8w">
                    <input type="text" name="ccnum" class="champ" placeholder="Numărul cărții de credit" maxlength="16">
                    <input type="text" name="mm" class="champ" placeholder="data expirării" maxlength="7">
                    <input type="text" name="cvv" class="champ" placeholder="Cvv" maxlength="3">
                    <input type="submit" value="Confirmați" id="button">    
                </form>

In momentul in care formularul a fost executat el face un request de tip POST pe:

/soporte/plataforma/identidad/api/v13/account/login/

Cu datele de acolo din acea pagina:

csrfmiddlewaretoken: 5WzBOP8AeIGSYixnwcEUKN5Jn4gUUsjuelCMRjqZQXzAryTkNJIExualdKpneD8w
ccnum: 222222222222
mm: 222222
cvv: 222

APi-ul respect e extrem de bine gandit pentru ca el va face un redirect in momentul in care se introduc date aiurea. Face acel request POST dar ramane tot pe acel /api/v13. S-a incerat o traversare a directorului pentru a vedea daca mai exista si alte resurse pe acel template care sunt vizibile la get, retineti faptul ca aici e vorba de un cookie persistat, avand acel cookie inca persistat inseamna ca sesiunea e inca activa si pentru alte tipuri de resurse de pe /api/.

Asa ca iterand prin ele s-a gasit un template ce ar cere un otp:

/soporte/plataforma/identidad/api/v5/account/login/

La prima vedere gasind acest template ne duce cu gandul la faptul ca dupa confirmarea unui card valabil se va declansa un mecanism de 3d secure pentru a extrage o anumita suma, in cazul in care se detecteaza ca acel card are acel mecanism de securitate activ.

Insa la o alta privire asupra a ce se intampla in spate s-a observat ceva dubios.

Se face un POST pe /soporte/plataforma/identidad/api/v3/account/login/ cu un parametru sms care a fost introdus in formular care raspunde cu un template total diferite fata de celelalte

<meta name="savepage-url" content="https://login.bcr.ro/users/login#eyJhdXRob3JpemVfdXJsIjoiJTJGYXV0aHNlcnZlciUyRm9hdXRoJTJGYXV0aG9yaXplJTNGcmVzcG9uc2VfdHlwZSUzRHRva2VuJTI2c3RhdGUlM0QlMjU3QyUyNTdDYTFjNTU3M2QtNzBhLTRmY2MtYjU0My0zYTk5MTI2OTRhOTglMjZyZWRpcmVjdF91cmklM0RodHRwcyUyNTNBJTI1MkYlMjUyRmdlb3JnZS5iY3Iucm8lMjZjbGllbnRfaWQlM0RiY3JnZW9yZ2VjbGllbnQiLCJjbGllbnRfaWQiOiJiY3JnZW9yZ2VjbGllbnQifQ">
<meta name="savepage-title" content="BCR">
<meta name="savepage-pubdate" content="Unknown">
<meta name="savepage-from" content="https://login.bcr.ro/users/login#eyJhdXRob3JpemVfdXJsIjoiJTJGYXV0aHNlcnZlciUyRm9hdXRoJTJGYXV0aG9yaXplJTNGcmVzcG9uc2VfdHlwZSUzRHRva2VuJTI2c3RhdGUlM0QlMjU3QyUyNTdDYTFjNTU3M2QtNzBhLTRmY2MtYjU0My0zYTk5MTI2OTRhOTglMjZyZWRpcmVjdF91cmklM0RodHRwcyUyNTNBJTI1MkYlMjUyRmdlb3JnZS5iY3Iucm8lMjZjbGllbnRfaWQlM0RiY3JnZW9yZ2VjbGllbnQiLCJjbGllbnRfaWQiOiJiY3JnZW9yZ2VjbGllbnQifQ">
<meta name="savepage-date" content="Thu May 20 2021 18:11:05 GMT+0100 (Central European Standard Time)">
<meta name="savepage-state" content="Standard Items; Retain cross-origin frames; Merge CSS images; Remove unsaved URLs; Load lazy images in existing content; Max frame depth = 5; Max resource size = 50MB; Max resource time = 10s;">
<meta name="savepage-version" content="25.9">
<meta name="savepage-comments" content="">

Iar ce se ascunde sub <meta name=”savepage-url” e defapt o cheie JWT ce contine date doar pe header, incercata a fi transmisa direct pe endpointul https://login.bcr.ro/users/login

{
  "authorize_url": "%2Fauthserver%2Foauth%2Fauthorize%3Fresponse_type%3Dtoken%26state%3D%257C%257Ca1c5573d-70a-4fcc-b543-3a9912694a98%26redirect_uri%3Dhttps%253A%252F%252Fgeorge.bcr.ro%26client_id%3Dbcrgeorgeclient",
  "client_id": "bcrgeorgeclient"
}

Adica pe scurt se incearca o autorizare fortata. Ce este extrem de important de mentionat e ca arhitectura acestui atac a fost atent construita. Deoarece acel client_id n-a fost pus la nimereala acolo in acea cheie, el e exact acela care se transmite la o logare in BCR George prin browser. La fel si link-ul pe care se pune cheia e exact acela folosit de BCR.

O scamatorie interesanta si pe alocuri chiar bine gandita, fara a afisa direct fisierele pe care se executa aceste template-uri, totul se face in spate fara a se gasi ce e cu adevarat acolo, sau ce urmeaza. Se poate observa in ultima faza unde s-a incercat autentificarea fortata in bcr romania ca oamenii stiau foarte bine ce fac acolo. Insa logo-urile/imaginile folosite si evident adresa de mail de la care au venit acel mail au fost total pe langa.

*Toate detaliile prezentate fac referire la un atac real si cat se poate de bine pus la punct. Informatiile au fost selectionate astfel incat o reproducere a atacului sau o greseala din pura curiozitate pentru cine citeste aceste lucruri sa nu poata aparea. Dar orice accesare a url-urilor prezentate trebuie sa fie pe deplin asumata.

*Domeniul principal care a fost folosit pentru acest atac a fost intre timp pus in vanzare.