Zakaj je napadalcem uspelo vdreti v aplikacije Ajpesa

Naše raziskovanje okoliščin vdora v aplikacijo Ajpes je razkrilo, da so zadnje zunanje teste ranljivosti aplikacij pri Ajpesu opravili leta 2013.

Devetega februarja letos je spletni portal Slo-tech objavil novico o vdoru v aplikacije Agencije Republike Slovenije za javnopravne evidence in storitve. Z Ajpesa so portalu odgovorili, da so v zadnjem obdobju izvedli več zunanjih varnostnih pregledov aplikacije. Naša preiskava pa je pokazala, da so zadnji pregled aplikacij opravili leta 2013.

Napadalec prišel do varovanih osebnih podatkov

Aplikacije na portalu Ajpes javnosti med drugim omogočajo vpogled v podatke o posameznem podjetju, letna poročila podjetij, podatke o stečajnih postopkih in podobno.

Vse baze podatkov, ki jih vsebujejo aplikacije, pa niso namenjene javnosti. Aplikacije na primer ne prikazujejo celotnih EMŠO številk ali davčnih številk posameznikov, ki so direktorji ali lastniki podjetij. S tem Ajpes varuje določene osebne podatke fizičnih oseb.

Varovanje takšnih podatkov je smiselno. Če bi se do njih dokopali tisti s slabimi nameni, bi jih na primer lahko uporabili za krajo identitete.

Napadalcu pa je, sodeč po dokazih, ki jih je pridobil spletni portal Slo-tech, uspelo priti do osebnih podatkov, ki bi morali biti skriti. Kot smo izvedeli, je neznani vir portalu poslal posnetek, na katerem je davčna številka ene izmed fizičnih oseb, ki je bodisi zastopnik bodisi lastnik ene izmed pravnih oseb.

Vir: Slo-tech
Posnetek z razkrito davčno številko fizične osebe, ki ga je pridobil Slo-tech. Vir: Slo-tech

Do tega podatka je prišel z napadom, ki se imenuje SQL-vrivanje, po angleško SQL injection. SQL-vrivanje je eden izmed najpreprostejših vdorov v informacijske sisteme, ki temeljijo na bazah podatkov. Kako poteka ta napad?

Napadalec v vnosna polja, ki mu jih aplikacija daje na voljo, namesto »pričakovanih« vnosov vnaša delce programske kode z namenom, da aplikacijo pretenta v posredovanje podatkov, ki jih ne bi smel dobiti.

Ajpes že na vstopni strani uporabnikom daje na voljo polje, v katerega lahko vpišejo naziv poljubnega podjetja. Aplikacija Poslovni register Slovenije jim nato posreduje javne podatke o podjetju.

V primeru napada z uporabo SQL-vrivanja pa bi napadalec namesto imena podjetja v to okence vnesel programsko kodo. S tem bi aplikacijo poskušal pretentati, da mu posreduje nejavne podatke v podatkovnih bazah aplikacije ali celo pridobil celotno bazo podatkov. Hipotetičen primer takšnega napada si lahko ogledate v tem videu.

Pogosta in nevarna ranljivost

SQL injection oziroma SQL-vrivanje je preprost in v svetu pogost napad. Kot nam je pojasnil Gorazd Božič, vodja nacionalnega odzivnega centra za obravnavo incidentov s področja varnosti elektronskih omrežij in informacij (SI-CERT), je SQL-vrivanje v strokovnih krogih prepoznano kot najbolj kritična ranljivost spletnih aplikacij.

Za preverjanje, ali je neka aplikacija ranljiva na ta napad, so na voljo recepti in orodja. »Določene konfiguracije se hitro preveri, za druge pa je mogoče potrebno več znanja,« pove Božič.

Kot so zapisali na Slo-techu, jim je Ajpes kot odziv na vprašanja o napadu odgovoril, da so »v zadnjem obdobju izvedli več zunanjih varnostnih pregledov, vendar nobeden od njih ni odkril tovrstne ranljivosti.«

Na podlagi tega pojasnila smo Ajpesu posredovali več vprašanj o tem varnostnem preverjanju. Nenavadno se nam je namreč zdelo, da zunanji varnostni pregledi niso ugotovili tako osnovne in tvegane ranljivosti, kot je SQL-vrivanje.

Zanimalo nas je, zakaj je bil vdor kljub varnostnim testom možen, kdaj je bil izveden zadnji pregled, kdo ga je izvedel in kakšni so bili rezultati pregleda.

Glede samega vdora so na Ajpesu odgovorili: »Izvajalci AJPES so glede na prejete informacije ugotovili, katera ranljivost je bila med vdorom izrabljena. Šlo je za vrsto varnostne ranljivosti, ki jo sicer dobro poznamo in proti kateri smo se v preteklosti uspešno branili. Pomanjkljivost v programski opremi, ki je omogočila ranljivost, je bila posledica napake, ki ni bila pravočasno ugotovljena.«

Podrobnosti o tem, kdaj so teste izvedli, koliko so točno stali in kdo jih je izvedel, nam z Ajpesa »zaradi varovanja podatkov zaupne narave« niso želeli posredovati.

Aplikacije nazadnje varnostno preverili leta 2013

Ob tem odgovoru smo Ajpes opozorili, da je podatek o nazivu podjetja, ki je izvedlo zunanje teste, informacija javnega značaja. Gre namreč za porabo javnih sredstev. Po tej naši utemeljitvi so nam z Ajpesa le sporočili, da je zadnje teste izvedlo podjetje HIC-SALTA, d. o. o.

Nato smo na podcrto.si v aplikaciji Erar preverili plačila Ajpesa temu podjetju. Kot je razvidno iz Erarja, je HIC-SALTA zadnje večje nakazilo od Ajpesa dobilo leta 2012.

Je torej HIC-SALTA zadnje teste za Ajpes izvedla leta 2012? Za komentar nakazil smo poprašali direktorja HIC-SALTA, Iztoka Lasiča. Povedal nam je, da so nakazila res dobili leta 2012, a da so zadnje teste ranljivosti aplikacije Ajpes izvedli leta 2013. Sodeč po podatkih iz Erarja je Ajpes podjetju za takratne teste plačal 7800 evrov.

Zakaj torej na Ajpes trdijo, da ranljivosti aplikacije preverjajo periodično, če pa so zadnje teste izvedli 2013? »Kot smo vam že sporočili, vam periode in časov izvajanja vdornih testov ne moremo razkriti, ker gre za varnostno občutljiv podatek,« so nam odgovorili z Ajpesa.

Tako dolgo obdobje brez testiranja je nenavadno. Še posebej zato, ker so januarja letos pri Ajpesu aplikacije prenovili. V novi programski kodi pa se lahko skrivajo nove varnostne ranljivosti.

»Varnostne preglede in penetracijske teste je smiselno opravljati takrat, ko se razvije aplikacija (preden je na voljo javnosti, op. a.) ali ko pride do večjih sprememb v kodi,« poudarja Gorazd Božič s SI-CERT.

Strokovnjak za informacijsko varnost Matej Kovačič, ki je objavil članek o ranljivostih Ajpesa na portalu Slo-tech, mu pritrjuje.

»Mednarodno sprejeta varnostna priporočila PCI DSS določajo, da naj bi se penetracijski testi izvajali vsaj enkrat letno oziroma ob vseh večjih spremembah informacijskega sistema. Payment Card Industry Data Security Standard (PCI-DSS) je skupek mednarodno priznanih varnostnih priporočil, ki je namenjen organizacijam, ki posredno ali neposredno upravljajo s podatki o plačilnih karticah. Standard določa, da naj bi organizacije vsaj vsako četrtletje izvedle notranji in zunanji varnostni pregled (t. i. vulnerability scan), vsaj enkrat letno in po vsaki večji spremembi informacijskega sistema pa naj bi izvedle tudi temeljito penetracijsko testiranje (t. i. penetration testing),« pojasnjuje Kovačič.

Ajpes ima v svojih bazah tudi osebne podatke finančne in lastniške narave, ki si po Kovačičevem mnenju zaslužijo visoko skrbnost pri hrambi. Standard PCI DSS pa predstavlja enega boljših primerov dobre prakse na področju varovanja takšnih občutljivih informacij.

Odgovornost Ajpesa pri vdoru v njihove baze podatkov zdaj preiskuje informacijski pooblaščenec.

Ajpes si želi povrniti ugled

Na Ajpesu so sicer v odgovoru podcrto.si tudi zapisali, da je: »Uspešnost [avtomatiziranih postopkov za testiranje vdorov] odvisna tudi od časa izvajanja testiranja, saj so zahtevane spremembe v spletnih aplikacijah veliko bolj pogoste kot izvedba vdornih testov.«

Ali to pomeni, da lahko pričakujemo še več vdorov v baze podatkov Ajpesa, glede  na to, da se aplikacije spreminjajo hitreje od izvedenih vdornih testov?

Na Ajpesu odgovarjajo, da »zaradi že uvedenih in načrtovanih dodatnih varnostnih mehanizmov, več nivojske zaščite, dodatnega pregledovanja kode pred namestitvami in drugih ukrepov bo možnost, da se kaj podobnega zgodi v prihodnje, občutno manjša. Trenutno varnostno situacijo bomo preverili z načrtovanim varnostnim pregledom v naslednjem mesecu. Po morebitnih dodatnih predlogih za izboljšave na osnovi rezultatov tega testa in izvedbi še načrtovanih ukrepov bo portal AJPES ustrezno varovan. Računamo, da se bo lahko tudi nivo zaupanja uporabnikov ponovno dvignil na želeno raven.«

Posodobitev: danes (27. 2. 2017) je Slo-tech objavil članek o novih ranljivostih v Ajpesu

PodCrto_Design_Podpri_Cam#4_Banner_960x360_Strap # WebButton

Nastanek tega članka ste omogočili bralci z donacijami. Podpri Pod črto

Deli zgodbo 1 komentar



Več iz teme: Komunikacijska varnost

Kako varno je naše komuniciranje z drugimi prek spleta, telefona in ostalih komunikacijskih kanalov? Preverjamo varnost različnih oblik komunikacije.

36 prispevkov

Kdo je odgovoren za slabo informacijsko varnost na UKC Ljubljana

UKC Ljubljana je slabo zavaroval podatke o zdravstvenem stanju posameznikov. Pooblaščenec za informacijsko varnost v UKC Ljubljana je nekdanji direktor …

Tema: Komunikacijska varnost
Članek,

Zakaj FURS strankam priporoča uporabo varnostno ranljivih brskalnikov

Finančna uprava je v začetku marca razburila z nasvetom, naj uporabniki Mac in Linux operacijskih sistemov prenehajo posodabljati brskalnik Firefox.

Tema: Komunikacijska varnost
Članek,

1 komentar

iztok2 27. 2. 2017, 20.01

"Podrobnosti o tem, kdaj so teste izvedli, koliko so točno stali in kdo jih je izvedel, nam z Ajpesa »zaradi varovanja podatkov zaupne narave« niso želeli posredovati." Kaj je pri tem zaupnega?

"Odgovornost Ajpesa pri vdoru v njihove baze podatkov zdaj preiskuje informacijski pooblaščenec."
Pravniki, so resnično računalniško podkovani, da bi razumeli varnostno situacijo? Sicer dvomim, da je to res, da bo IP preverjal odgovornost. Morda bo preverjal le, katere informacije so bile dane v eter brez zaščite.

"Na Ajpesu odgovarjajo, da »zaradi že uvedenih in načrtovanih dodatnih varnostnih mehanizmov, več nivojske zaščite, dodatnega pregledovanja kode pred namestitvami in drugih ukrepov bo možnost, da se kaj podobnega zgodi v prihodnje, občutno manjša."
Smešno. Če povezave niso varovali niti s https (kar mimogrede počne podcrto.si na spletni strani novic, kjer ni občutljivih osebnih podatkov), kaže na to, da se jim kaj prida o varnosti ne sanja. Problem ni v dodatnih varnostnih mehanizmih, problem je, da je osnovni mehanizem povsem zatajil. To je tako kot da bi avtomobilska industrija trdila, da bo vgradila dodatne varnostne mehanizme v avtomobile, vendar zavore pa jim ne delujejo.

Dodaj odgovor

Vaš e-naslov ne bo objavljen. * označuje zahtevana polja

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Zadnje objavljeno