mobilās aplikācijas

Tehniskais apraksts

Mobilās aplikācijas izsaukumi tiek nosūtīti kā GET pieprasījumi uz adresi https://ib.swedbank.lv/touch/, turklāt svarīgi, ka User-Agent ir jāsatur, piemēram, vārds “Android”.

Pirmais pieprasījums ir https://ib.swedbank.lv/touch/auth?authenticate=true&language=ENG&mobileIdLogin=false&authPwd=pp&userId=nn, kur aa ir lietotāja numurs, bet pp ir lietotāja pastāvīgā parole. Korektu datu ievades gadījumā atbildē tiks saņemta json virkne

{"challenge":"cc","sessionId":"ss","securityId":"dd","loginType":3,"securityLevel":1}

Tajā cc ir drošības koda numurs, kas lietotājam nākamajā solī būtu jāievada no kodu kartes, ss ir sesijas identifikators, bet dd ir drošības identifikators. Ja klients lieto kodu kalkulatoru, nevis kodu karti, tad “challenge” netiek uzstādīts un “loginType” vērtība ir cita.

Uzmanības vērts ir fakts, ka, lai gan internetbankas mājaslapā klientam pieprasītais drošības koda numurs tiek parādīts kā attēls (drošības apsvērumi?), tomēr veicot pieprasījumu caur https://ib.swedbank.lv/touch/ šis pats koda numurs tiek nosūtīts kā ASCII teksts. Tāpat interesanti, ka parole tiek nosūtīta GET pieprasījumā, kas nozīmē, ka atkarībā no aplikācijas servera konfigurācijas, iespējams, žurnālfailos glabājas visu mobilās aplikācijas lietotāju paroles.

Lai iegūtu klienta vārdu un uzvārdu, ir jānovirzās no standarta komunikācijas plūsmas, nekavējoties veicot pieprasījumu https://ib.swedbank.lv/touch/overview;jsessionid=ss?securityId=dd, ko aplikācijas serveris šajā brīdī negaida. Šim pieprasījumam svarīgi, lai klientā būtu uzstādīta sīkdatne Swedbank-Embedded=android-app-3.2. Kā atbilde tiek nosūtīts kļūdas paziņojums HTML lapas veidā, kurā iekļauts JavaScript koda gabaliņš. Šis kods satur masīvu sessionInfo.

var sessionInfo = { jsessionId: 'ss', securityId: 'dd', securityLevel: 1, customerName: 'Alberts Kviesis', allowSingleSessionDefined: true, allowSingleSession: false, hasPrivateAccounts: false, hasBusinessAccounts: false, disclaimerAccepted: false, passwordChangeRequired: false }

Indekss “customerName” satur klienta vārdu un uzvārdu, tam sekojošie indeksi droši vien neatspoguļo patieso situāciju.

Reakcija

Par problēmu 23. oktobrī ziņojām bankai un CERT.LV. Informācija pirmo reizi paziņota publiski 12 dienas vēlāk — 4. novembrī. Saskaņā ar atbildīgo darbinieku komentāriem, šāda mobilās aplikācijas servera uzvedība atbilst specifikācijai un netikšot mainīta. Mēs centīsimies turpināt aplikācijas drošības pārbaudi un, atklājot nepilnības, ziņosim par tām iesaistītajām pusēm.

Pirms pāris mēnešiem viens no Latvijas mobilo sakaru operatoriem Bite publicēja programmu “BITE megaprieku kontroles rīks”. Šī programma, kas paredzēta lietošanai Android viedtālruņos, ļauj aplūkot savu iztērēto datu apjomu šajā mēnesī, kā arī aprēķina plānotās izmaksas.

Autorizēšanās

Ekrānšāviņš no kontroles rīka pirmās versijas.

Lai saņemtu informāciju par datu apjoma patēriņu, aplikācijai jāsaņem autorizācijas kods no Bites servera, ko sākumā varēja saņemt divos veidos:

Izvēloties kontaktu, Bite tam nosūtīja SMS ar drošības kodu, ko jāievada aplikācijas autorizācijas logā, kas tad tika nosūtīts Bites serverim, atbildē saņemot autorizācijas kodu.
Izvēloties “Savs numurs”, aplikācija Bites serverim nosūtīja abonenta IMSI, pretī saņemot autorizācijas kodu.

Tehniskā puse

Autorizēšanās un informācijas saņemšanas pieprasījumi JSON formātā tiek nosūtīti uz adresi https://213.226.139.54/prest/android.json.

Tā kā sertifikāta domēns neatbilst IP adresei, aplikācijā ir izslēgta domēna atbilstības pārbaude:

.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Autorizēšanās pieprasījums savam numuram izskatās šādi:

{"id":aaa,"jsonrpc":"2.0","method":"authIMSI",
"params":{"password":null,"imsi":"bbb"}}

Atbilde uz to (ddd ir klienta mobilā telefona numurs):

{"jsonrpc":"2.0","id":aaa,"result":
{"securityKey":"ccc","msisdn":"ddd"}}

Informācijas ieguves pieprasījums:

{"id":aaa2,"jsonrpc":"2.0","method":"getData",
"params":{"securityKey":"ccc"}}

Atbildes piemērs:

{"jsonrpc":"2.0","id":aaa2,"result":
{"customerAmount":"0.5000","customerCurrency":"Ls",
"customerDataUsage":"510","customerType":"POSTPAID",
"customerRoamDataUsage":"0","customerstatus":"ACTIVE",
"customerRatePlanExp":"2013-12-31 23:59:59",
"customerBalanceExp":"","customerIsInRoaming":"0"}}

Kā redzams, atbildē ir ietverti šādi dati: patērētais interneta datu apjoms, tarifu plāna nosaukums un veids, kā arī derīguma termiņš.

Problēmas

IMSI netiek ģenerēti nejauši, bet secīgi, tāpēc, nosūtot IMSI numurus vienu pēc otra, uz daļu no pieprasījumiem tiek saņemti derīgi autorizācijas kodi un telefona numuri.

Kad aplikācija vai uzbrucējs ir ieguvis “securityKey”, tas paliek derīgs pat tad, ja konkrētam telefona numuram tiek pieprasīts jauns kods. Tātad, ja Jūsu telefons īsu brīdi ir uzbrucēja kontrolē, tas var iegūt SMS drošības kodu un līdz ar to arī derīgu “securityKey”, ko nav iespējams atcelt izmantojot “megaprieku” uzskaites programmu. Bet ņemot vērā sekojošo informāciju, esmu drošs, ka piezvanot BITE atbalsta dienestam, to tehniski vajadzētu varēt izdarīt.

Atrisinājums

Par problēmu 12. septembrī ziņojām CERT.LV, lai viņi tālāk koordinētu ievainojamības novēršanu.

19. septembrī Play Store parādījās jauna programmas versija, kurā problemātiskais autorizācijas veids vairs nebija pieejams. Saskaņā ar mums pieejamo informāciju vecie drošības kodi ir deaktivēti un vairs nav izmantojami informācijas iegūšanai.

Par atrasto problēmu publiski paziņojām 23. oktobrī, ISACA Latvijas nodaļas un CERT.LV rīkotajā IT drošības konferencē
„Mūsu informācijas drošība – nākotnes panākumu atslēga”.

Sargiet savus telefonus!

Birku arhīvi: mobilās aplikācijas

Interesanta “funkcija” Swedbank mobilajā aplikācijā