Najdena resna varnostna ranljivost v AJPESovi podpisni komponenti

V nedeljo popoldan se je na nas (in na SI-CERT) preko omrežja Tor obrnil neimenovan varnostni raziskovalec, ki je odkril več resnih varnostnih ranljivosti v podpisni komponenti, ki jo uporablja AJPES. Gre za aplikacijo mdSign, s pomočjo katere zavezanci podpisujejo dokumente, ki jih elektronsko oddajajo AJPES-u. Ker je bilo obvestil v zvezi s to spletno stranjo iz različnih virov v zadnjem času kar precej in ker gre v tem primeru res za jagodni izbor, smo se odločili prejeto obvestilo objaviti nemudoma.

Varnostni raziskovalec je ugotovil, da zaradi napake v podpisni komponenti obstaja možnost, da napadalec, ki ima zmožnost izvesti aktiven napad s posrednikom (tim. MITM napad), žrtev pretenta, da z zasebnim ključem svojega kvalificiranega digitalnega potrdila podpiše poljubno vsebino pod nadzorom napadalca.

A to še ni vse. Raziskovalec je tudi ugotovil, da podpisna komponenta v nekaterih primerih sploh ne podpisuje dokumentov, pač pa zgolj identifikatorje dokumentov na strežniku AJPES-a. To je seveda problem, saj obstaja možnost, da s posegom (npr. administratorja sistema oz. kogarkoli, ki ima dostop do AJPESove strežniške infrastrukture) identifikator dokumenta ostane isti, sam dokument na strežniku pa se spremeni.

Po našem mnenju ne gre samo za varnostno ranljivost, pač pa za popolnoma neustrezno implementacijo digitalnega podpisa, saj podpisna komponenta sploh ne omogoča podpisovanja dejanskih dokumentov. Če drži, da se ne podpisujejo dokumenti, pač pa le njihovi identifikatorji, je celoten sistem popolnoma neustrezen in bi ga AJPES moral nemudoma prenehati uporabljati. Pri tem se seveda zastavi tudi vprašanje verodostojnosti in veljavnosti dokumentov, ki so že v sistemu, in ki so bili neustrezno “podpisani”. Po našem mnenju bi bilo najbolj smiselno, da se verodostojnost in integriteto na neustrezen način podpisanih dokumentov ponovno preveri in ugotovi ali so avtentični ali pa morda spremenjeni.

Potek podpisovanja

Zdaj pa h podrobnostim.

Podpisovanje dokumentov z mdSign, ki ga uporablja AJPES poteka takole.

1. Najprej se na strežniku ustvari ustrezen dokument.

2. Nato odjemalec k sebi prenese datoteko s končnico .mdsign, ki vsebuje ovojnico v formatu XML. Kot kaže, je ovojnica šifrirana, v elementu __ pa se nahaja BASE64-kodirana in šifrirana vsebina. Mimogrede, datoteka se prenese preko **navadne, HTTP povezave**, torej prenos med strežnikom in odjemalcem **ni šifriran**. Zakaj je to pomembno, bomo videli nekoliko kasneje.

3. Na tej točki je varnostni raziskovalec programsko opremo za podpisovanje analiziral s tim. povratnim prevajalnikom (ang. decompiler) in ugotovil, da je vsebina te datoteke (ki se do odjemalca prenese preko nešifrirane povezave) šifrirana s statičnim ključem in statičnim inicalizacijskim vektorjem (AES, CBC)!! Povedano drugače – parametri za dešifriranje (ključ in IV vektor) so fiksni in na voljo v podpisni komponenti sami! Kar je dobesedno recept za katastrofo.

4. Datoteka, ki jo z omenjenima dvema parametroma dešifriramo, pa vsebuje kup zanimivih podatkov. Element __ vsebuje URL naslove datotek, ki jih bo odjemalec preko nešifrirane (HTTP) povezave prenesel pred podpisom. Te datoteke seveda lahko vsebujejo občutljive podatke. Element __ vsebuje avtentikacijske podatke brskalniške seje. S temi podatki lahko napadalec ugrabi sejo in dostopa do žrtvinih dokumentov ali jih v imenu žrtve oddaja na APJES-ov strežnik.

In za povrh – samo podpisovanje poteka tako, da odjemalec iz elementa __ prebere URL naslov iz katerega si prenese vsebino, to vsebino pa nato slepo podpiše.

To napadalcu omogoča, da odjemalcu podtakne URL do poljubnega dokumenta, ki ga bo potem odjemalec mirno podpisal, ne da bi sploh preveril kaj podpisuje.

Vsebina, ki se podpisuje, pa kot rečeno (v nekaterih primerih) ni vsebina dokumenta, pač pa njegov identifikator (domnevno vsaj na primeru pooblastil za vlaganje dokumentov), ki se nahaja v elementu XML (XXXXXX – XXXXXX je identifikator dokumenta na strežniku AJPES-a).

Možne posledice

Iz navedenih razlogov – zlasti pa zato, ker kaže, da glede na navedeno zavezanci v resnici dokumentov sploh ne podpisujejo (pač pa le njihove identifikatorje), smo mnenja, da bi zavezanci morali podpisno komponento nemudoma prenehati uporabljati. Ne samo da podpisna komponenta deluje nepravilno in ne omogoča podpisovanja dejanskega dokumenta, njena uporaba je po našem mnenju tudi nevarna, saj potencialnemu napadalcu omogoča, da le-ta ugrabi sejo in dostopa do občutljivih dokumentov, oziroma v imenu žrtve na APJES-ov strežnik oddaja lažne dokumente. Poleg tega pa napadalec žrtvi v podpis lahko podtakne tudi poljuben dokument in tako podpisan dokument bo imel seveda pravno veljavo.

Glede na obvestilo, ki nam ga je posredoval raziskovalec, smo tudi mnenja, da podpisne komponente ne bo mogoče kar tako popraviti. Podpisna komponenta sicer ima podporo za uporabo HTTPS šifriranih povezav (kar pa se kot rečeno ne uporablja!), a je pregled kode pokazal, da se v tem primeru ne preverja digitalnega potrdila strežnika. To pomeni, da četudi bi pri AJPES-u vključili podpisovanje preko HTTPS povezav, bi napadalec lahko namesto AJPESovega spletnega potrdila lahko preprosto podtaknil svoje spletno potrdilo, sistem pa tega ne bi ustrezno zaznal.

Po mnenju raziskovalca, ki nas je kontaktiral, bi bilo edino pravilno, da bi vsi prenosi dokumentov potekali preko HTTPS povezav, AJPESov strežnik bi šifriral in s svojim zasebnim ključem overil vsebino, ki jo posreduje odjemalcu v podpis, odjemalec pa bi preveril integriteto vsebine in mu predvsem pokazal katero vsebino sploh podpisuje. Z njegovim mnenjem se lahko le strinjamo.

Nadalje je raziskovalec mnenja, da bi morali biti vsi protokoli in implementacije, ki se uporabljajo v povezavi s kvalificiranimi potrdili obvezno javno objavljeni ter predhodno varnostno pregledani – tako s strani najetih strokovnjakov, kot tudi s strani zainteresirane strokovne javnosti. Rezultati varnostnih pregledov bi seveda morali biti javni, ranljiva in nevarna programska koda pa bi morala biti nemudoma umaknjena iz produkcije. Tudi s tem se lahko le strinjamo.

Ker imajo po obstoječi zakonodaji digitalni podpisi narejeni s kvalificiranimi digitalnimi potrdili enakovredno pravno veljavo kot lastnoročni podpisi posameznikov oz. zastopnikov pravnih subjektov, smo mnenja, da je slovensko javnost potrebno nemudoma opozoriti na nevarnosti pri uporabi AJPESove podpisne komponente. Po našem mnenju bi morali uporabniki nemudoma prenehati z uporabo obstoječe AJPESove podpisne komponente, zato v skladu z načeli odgovornega razkrivanja varnostnih ranljivosti zavezance, ki uporabljajo AJPESovo podpisno komponento pozivamo, da le-to nemudoma prenehajo uporabljati ter da v evidencah AJPESa preverijo ali so dokumenti, ki so jih že podpisali sploh avtentični ali ne.

Ker v zvezi s to ranljivostjo nastaja škoda z vsako ponovno uporabo podpisne komponente na AJPESovi spletni strani (možnost podtikanja lažnih dokumentov v podpis), drugih posledic pa razkrita ranljivost nima, pri objavi nismo spoštovali sedem dnevnega roka, ki si ga je za “opredelitev do navedb” zaželel AJPESov izvajalec.

Glede na vse ranljivosti, ki so bile v zadnjem času povsem po naključju odkrite na AJPESovih sistemih, pa se lahko upravičeno vprašamo v kakšnem stanju je njihov informacijski sistem in kaj vse bi še odkril resen in strokoven varnostni pregled. Zastavlja pa se tudi vprašanje odgovornosti vodstva, ki je po našem mnenju objektivno odgovorno za pravilnost in zakonitost delovanja svojih sistemov.

 

Novica je bila 27. februarja 2017 objavljena na spletišču Slo-Tech.