AJPES-ova alternativna dejstva

Potem ko smo na Slo-Techu v ponedeljek objavili obvestilo anonimnega prijavitelja v zvezi s popolnim neupoštevanjem kakršnihkoli varnostnih standardov na AJPESovi spletni strani, je danes predstavnik AJPESa za STA podal odziv. Sporočili so, da so na spletni strani vključili protokol HTTPS, ter da zato štejejo, da so vse izpostavljene težave s tem odpravljene.

Težko je reči, ali nas je tak odziv razočaral ali presenetil. A očitno je, da Agencija ni kos svojim nalogam in da to skriva tako, da probleme pometa pod preprogo, nadejajoč se, da v tej državi res ni nikogar, ki bi jo znal za to kaznovati.

Poglejmo si njihov odziv nekoliko podrobneje.

V Ajpesu so danes za STA pojasnili, da po zagotovilih avtorjev omenjene podpisne komponente v primeru uporabe HTTPS-povezave med Ajpesovim strežnikom in uporabnikom, ki izvaja elektronski podpis, zloraba e-podpisa ni mogoča. V primeru uporabe HTTP-povezave pa zelo majhna možnost obstaja, vendar pa bi pri tem napadalec moral izvesti celo vrsto povezanih aktivnosti, in to v času, ko se uporabnik odloči, da bi oddal nek dokument.

"Verjetnost izvedbe takega postopka pri uporabniku je zelo majhna, še manjša je verjetnost, da bi se isti postopek lahko izvedel pri več uporabnikih. Ne glede na navedeno je mogoče na Ajpesu spremenjeno datoteko prepoznati, saj ni enaka originalu, ki je shranjen na sistemih Ajpesa," pojasnjuje vodja službe za informacijsko tehnologijo v Ajpesu Marjan Babič.

Dodal je še, da so po posvetu z zunanjim izvajalcem kot preventivni ukrep vzpostavili varnejšo HTTPS-povezavo za celoten portal. Od vzpostavitve novega portala v januarju do 27. februarja so imeli namreč začasno še vzpostavljen mešan model, podobno kot na starem portalu, kjer se je del prometa odvijal po HTTPS-, del pa po HTTP-povezavah. Ta korak je sicer bil prvotno predviden za 6. marec, ko je predvidena tudi menjava kvalificiranega digitalnega potrdila strežnika.

Poleg tega so že preverili nekaj skupin dokumentov, pri čemer so bile vsebine teh pravilne, e-podpisi pa ustrezni. S pregledi bodo nadaljevali, ocenjujejo pa, da neustrezno podpisanih dokumentov ni.

AJPES trdi, da je podpisno komponento in konfiguracijsko datoteko za izvedbo podpisa zdaj pa zares začel servirati preko HTTPS. To drži. Vendar pa pri tem še vedno uporablja stare šifrirne algoritme, svoj strežnik pa identificira s samopodpisanimi certifikati. Posledično njihova stran ni nič bolj varna kot prej. Pravzaprav je sploh ni mogoče obiskati, ne da bi brskalnik eksplodiral z opozorilom, da je nekaj hudo narobe. Njihov ukrep je tako očitno brez vsake praktične vrednosti. Vsakdo, ki je bil sposoben narediti MITM napad zoper nešifirano povezavo, lahko še vedno naredi isti napad tudi zoper strežnik s takšnimi certifikati. Preprosto si jih izda sam, kajti za brskalnik bo zgledalo povsem isto.

Odgovor AJPES prav tako izkazuje nov primer popolne ignorance in zavajanja (ali pa morda kar direktnega laganja), saj ni povsem jasno, kako naj bi prehod na HTTPS povezavo obvaroval uporabnike, ko pa ima komponenta uporabljen "stackoverflow" primer izklopa preverjanja veljavnosti strežniških potrdil in tako omogoča prestrezanje in popravljanje povezav enako, kot če varni način sploh ne bi bil uporabljen (za odkritje se zahvaljujemo bralcu v izvirni temi).

if (useSSL.booleanValue()) {
    HostnameVerifier allHostsValid = new HostnameVerifier(){

        @Override
        public boolean verify(String hostname, SSLSession session) {
            return true;
        }
    };
    HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
    con = (HttpsURLConnection)url.openConnection();
} else {
    con = (HttpURLConnection)url.openConnection();
}

AJPES je pač mojster navajanja "alternativnih dejstev". Če jim ena resnica ni všeč, pač predstavijo svojo.

Ampak to niti ni bistveno. AJPES ni prav v ničemer spremenil samega procesa podpisovanja. Tako še vedno datoteko z navodili kodirajo s simetričnim ključem, kar ne zagotavlja nobene integritete. Na ta način naključnemu napadalcu še vedno omogočajo, da ničhudegaslutečemu uporabniku podtakne v podpis datoteko, ki je morda ne želi podpisati ter hkrati specificira naslov, kamor želi, da se podpisana datoteka pošlje. Uporabnik prav tako še vedno dejansko ne ve, kaj točno podpisuje.

Če bi AJPES kaj dal na varnost, bi si najprej kupili pošten certifikat za svojo spletno stran. Potem bi javni del spletišča ločil od zasebnega, preko katerega se oddajajo razna poročila in drugi dokumenti. Tam bi dodali dvofaktorsko avtentikacijo in vključili kakšno osnovno preverjanje, npr. csrf in xss filter. Za samo podpisovanje bi uporabili brskalnikov lastni API ali vsaj kakšno varnostno preverjeno komponento.

Odgovor predstavnikov Agencije ponovno dokazuje, da jim je popolnoma vseeno za varnost njihovih uporabnikov, saj so mnenja, da dokler lažno podpisani dokumenti niso pristali v njihovem informacijskem sistemu, to ne predstavlja težave. Da se podpisna komponenta obnaša kot učbeniški primer "malware"-a tako, da komurkoli omogoča, da ustvari veljavno .mdsign datoteko v kateri specificira kaj naj se podpiše in kam naj se podpisana vsebina naloži za AJPES očitno ni težava (dokler se tako podpisana vsebina ne nalaga k njim).

Prav tako predstavlja pesek v oči izjava, da AJPES preverja veljavnost podpisov v svojem informacijskem sistemu. Kot je razvidno iz objave, sama veljavnost ni bila nikoli vprašljiva (kar je pravzaprav problem). Problem predstavlja dejstvo, da se ponekod namesto vsebine dokumenta podpisuje samo enolični identifikator dokumenta (sicer veljavno) ter da uporabnik nikoli ne ve, kaj pravzaprav podpisuje (in komu) -- 2. odstavek 37. člena ZEPEP.