Najdena resna varnostna ranljivost v AJPESovi podpisni komponenti

V kodi je backdoor, ki v primeru, da je operacijski sistem Mac OS, keystore datoteko shrani z geslom "1234", kar omogoča enostavno krajo uporabnikovega certifikata.

Datoteka application/main.java v komponenti mdSigJava.

    private String getPasswd(boolean store) throws Exception {
        if (this.osType == Common.OsType.Mac) {
            return "1234";
        }
        DlgPasswd dlg = new DlgPasswd();
        return dlg.GetPasswsd(this.appStage, store, this.osType);
    }

čuhalev je 28. feb 2017 ob 00:09 izjavil:

A koda se tako zlahka razbere?

Ja, za Javo lahko uporabiš naprimer tole spletno aplikacijo: http://www.javadecompilers.com/

Za .NET komponento tudi ni problem.

čuhalev je 28. feb 2017 ob 00:13 izjavil:

In tako je možno "obrniti" vsako Javo?

Načeloma ja, razen če so pri kompilaciji dodali še obfuskacijo (npr. ProGuard za Android), ali pa uporabljajo druge tehnike pri samem programiranju, da je koda težje berljiva.

čuhalev je 28. feb 2017 ob 00:22 izjavil:

Sem pa že mislil, kakšen maher mora biti ta anonimni varnostni raziskovec, da se je lotil tega. Pač programiram v C in karkoli takšnega je tam bistveno težje.

Ja, tam bi za tako lepo dekompilacijo potreboval še kakšne debug simbole, ki jih v release verzijah ponavadi ni.

Zakaj taka kritična koda ni open source? Zakaj nimamo ene preverjene podpisne komponente, ampak kar vsaka inštitucija nekaj po svoje? Skrajni čas, da se lotimo poenotenja sistemov gov.si.

Shalabajzer je 28. feb 2017 ob 00:27 izjavil:

čuhalev je 28. feb 2017 ob 00:22 izjavil:

Sem pa že mislil, kakšen maher mora biti ta anonimni varnostni raziskovec, da se je lotil tega. Pač programiram v C in karkoli takšnega je tam bistveno težje.

Ja, tam bi za tako lepo dekompilacijo potreboval še kakšne debug simbole, ki jih v release verzijah ponavadi ni.

Zakaj taka kritična koda ni open source? Zakaj nimamo ene preverjene podpisne komponente, ampak kar vsaka inštitucija nekaj po svoje? Skrajni čas, da se lotimo poenotenja sistemov gov.si.

Skrajni čas je bil že leta 2010, ko je ajpes prevzel register transakcijskih računov od banke slovenije.

Boš lahko z enim klikom glasoval namesto 100.000 ljudi.

A se je SI-CERT že kaj oglasil?

Shalabajzer je 28. feb 2017 ob 00:07 izjavil:

V kodi je backdoor, ki v primeru, da je operacijski sistem Mac OS, keystore datoteko shrani z geslom "1234", kar omogoča enostavno krajo uporabnikovega certifikata.

jukoz je 28. feb 2017 ob 09:50 izjavil:

A se je SI-CERT že kaj oglasil?

Ko sem prebral naslov sem si ravno mislil, da bo ubogega @GBX-a kap zadela. Zgleda si še niso upomogli in še usklajujejo izjave. Kak je zaj to blo takoj rešeno ker so oni bli vključeni kot zainteresirana stran, pa da je AJPES to tak nastavo za lovljenje nepridipravov.

Pri tem se po njegovih besedah zastavi tudi vprašanje verodostojnosti in veljavnosti dokumentov, ki so že v sistemu in ki so morda 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," je še zapisal Kovačič.

Tale Kovacic klati bedarije. Nic se ne sme ugotavljat integritete. Nepodpisan dokument ni veljaven, pika. A zdej bomo pa sli za vsak dokument preverjat, ce ga je admin sel spreminjat? Btw, kot da se ne da teh sledov ne da zakriti. Pa tudi ce ga ni nihce spreminjal, nepodpisan dokument ni veljaven.

Kaksna bedarija. Zdej bi on mel "prakticno" resitev, da bi se neki preverjalo, ko pa pravno-formalno lahko samo stran vrzes vse, pa das te kretene na sodisce, ker niso izpolnili uradne dolznosti. Sefi vedno govorijo da rabijo bit placani zaradi odgovornosti polozaja. No, zdaj je pravi cas za odgovornost. Zakaj se bodo teli klinci izognili posledicam, kar je bilo narejeno je tocno isto, kot ce bi delal na upravni enoti, cel dan izdajal dokumente, potem bi pa cel fascikel le-teh vrgel v kamin.

Samo me pa malo moti, ker se govori o 'podpisanih dokumentih', medtem ko sploh nimamo opravka z dejanskimi dokumenti, ki bi bili podpisani, temveč o slogih v bazah podatkov, katerih 'pravilnost' uporabnik potrjuje s svojim elektronskim podpisom.

Ko govoriš o 'podpisovanju dokumentov' imaš občutek, da se podpisuje nek pdf ali podoben dokument, kateri se potem shrani kot tak. Pa mislim, da temu še zdaleč ni tako.

Obratno, pa seveda ti sistemi omogočajo, da si uporabnik prenese neko 'potrdilo', katero lahko shrani kot dokaz. Tu pa seveda dejansko gre za podpisane dokumente, običajno v PDF obliki. Ampak tu v bistvu podpis uporabnika niti ni potreben - rabiš verodostojen podpis ustanove, ki ti je izdala ta dokument, da se kasneje ne morejo izgovarjati, da si oddal nekaj drugega. Sam dokument pa hrani uporabnik.

Preverjanje pristnosti dokumentov je enostavno, dokler so certifikati veljavni. Kaj pa potem, ko certifikat enkrat poteče in ni več veljaven?

SeMiNeSanja je 28. feb 2017 ob 15:04 izjavil:

Preverjanje pristnosti dokumentov je enostavno, dokler so certifikati veljavni. Kaj pa potem, ko certifikat enkrat poteče in ni več veljaven?

Temu se potem reče strokovno "problematika e-arhiva". Najboljša opcija je, da rok hrambe preteče in e-dokumente enostavno e-pobrišeš.

ender je 28. feb 2017 ob 15:24 izjavil:

SeMiNeSanja je 28. feb 2017 ob 15:04 izjavil:

Preverjanje pristnosti dokumentov je enostavno, dokler so certifikati veljavni. Kaj pa potem, ko certifikat enkrat poteče in ni več veljaven?

Zato imaš poleg podpisa še časovni žig, ki dokazuje, da je bil dokument podpisan v času veljavnosti certifikata.

Tu bi še dodal, da je za dolgoročno hrambo treba časovne žige podaljševati (omejen čas trajanja certifikata za časovni žig, kolizije hash funkcij). Primer je recimo ERS ali XMLERS sistem (ali kaj podobnega).

SeMiNeSanja je 28. feb 2017 ob 14:52 izjavil:

Fascikel je še vedno tam. Samo tisti vogal s podpisom se je skuril.

Ne drži. Nikoli ga ni bilo, to bi lahko bila analogija, če že. Ker uporabnik dokumenta nikoli dejansko ni niti podpisal.

SeMiNeSanja je 28. feb 2017 ob 15:04 izjavil:

Samo me pa malo moti, ker se govori o 'podpisanih dokumentih', medtem ko sploh nimamo opravka z dejanskimi dokumenti, ki bi bili podpisani, temveč o slogih v bazah podatkov, katerih 'pravilnost' uporabnik potrjuje s svojim elektronskim podpisom.

Ko govoriš o 'podpisovanju dokumentov' imaš občutek, da se podpisuje nek pdf ali podoben dokument, kateri se potem shrani kot tak. Pa mislim, da temu še zdaleč ni tako.

Obratno, pa seveda ti sistemi omogočajo, da si uporabnik prenese neko 'potrdilo', katero lahko shrani kot dokaz. Tu pa seveda dejansko gre za podpisane dokumente, običajno v PDF obliki. Ampak tu v bistvu podpis uporabnika niti ni potreben - rabiš verodostojen podpis ustanove, ki ti je izdala ta dokument, da se kasneje ne morejo izgovarjati, da si oddal nekaj drugega. Sam dokument pa hrani uporabnik.

Preverjanje pristnosti dokumentov je enostavno, dokler so certifikati veljavni. Kaj pa potem, ko certifikat enkrat poteče in ni več veljaven?

Okej, glede terminologije, je tako, da moraš biti eksakten, in ne zgolj neke svoje logike ob občutkih uporabljati. Potrebno je pogledati, kaj pravi ZEPEP, kaj je dokument, kaj so el. podatki itn. Saj je vseeno, kaj se podpisuje, le da so to podatki, ki jih je v prvi vrsti smiselno podpisovati (pa naj bodo zlogi, nizi, BLOB-i ali, nenazadnje v njih shranjen dokument) in za katere zakon to predpisuje, kdo, kaj in kako.

Jaz nasprotujem logiki, da se podpisuje zgolj in samo dokumente, ker potem to slovenske odločevalce napeljuje na dizajn sistemov, kjer se dejansko neke dokumente ustvarja, prenaša okoli kot to počne mačka z mladimi in vmes še podpisuje. Važno je, da je zadeva funkcionalna, pregledna in varna (pa naj bodo to vnosna polja, naoptinane možnosti ali od drugod povlečeni podatki). to vnosna polja, naoptinane možnosti ali od drugod povlečeni podatki).

Kakorkoliže - vse skupaj deluje kot velika mučka, nekaj spacano skupaj, da bi izgledalo fancy, po sistemu 'saj takointako ne bo nihče pogledal, kaj je res notri'.

Mučko se da pošlihtat. Problem pa je narušeno zaupanje. Sprašuješ se, če je agencija, ki je dopustila takšno mučko, sploh primerna za barantanje z našimi podatki. Nekaj ne gre po sistemu, ki bi ga pričakoval od skrbnega varuha podatkov. Flikanje in krpanje njihovih rešitev ne bo odpravilo sistemske (organizacijske) napake.

Kdo ali kaj je zdaj dejansko kriv za vse skupaj, bi moral presoditi nek organ, ki je dejansko neodvisen - jaz pa resno dvomim, da je to IP RS. Poleg tega pri tem organu tudi dvomim v sposobnost take presoje.

Treba je razrešiti, ali je kdo opustil dolžno ravnanje in je vsa mučka posledica malomarnosti/nesposobnosti (v tem primeru se morajo majati stolčki), ali je vse skupaj posledica sistema javnih naročil, kjer se gre po sistemu 'najnižja cena je edini kriterij'.
Ampak glede na prakso pri naših javnih naročilih, so ta že v naprej tako 'prečiščena', da cenovnih alternativ praktično ni, bodočega izvajalca pa med vrsticami razpisa razkrije tudi slepec.

Ampak nič hudega - tudi v tem primeru se da raziskati, kako je sploh bil narejen razpis in kdo je odgovoren za postavitev kriterijev, ki so vplivali na končni izbor izvajalca. Taka oseba pač ne sme več nositi tovrstne odgovornosti.

nebivedu? Prosim, če lahko pošlješ endpoint na mail (pa cc GBXu na cert@cert.si, da se ne bo ponovno počutil izvzetega).

Zakaj brezplačno? :)

hruske> Zakaj brezplačno? :)

Ker se nočem kregat o tem, kdo je pobral denar.

SeMiNeSanja je 28. feb 2017 ob 14:52 izjavil:

Fascikel je še vedno tam. Samo tisti vogal s podpisom se je skuril.

Efektivno isto.

poweroff je 28. feb 2017 ob 16:44 izjavil:

Spura je 28. feb 2017 ob 14:45 izjavil:

Tale Kovacic klati bedarije. Nic se ne sme ugotavljat integritete. Nepodpisan dokument ni veljaven, pika. A zdej bomo pa sli za vsak dokument preverjat, ce ga je admin sel spreminjat? Btw, kot da se ne da teh sledov ne da zakriti. Pa tudi ce ga ni nihce spreminjal, nepodpisan dokument ni veljaven.

Hja, jaz sem mislil bolj to, da Ajpes vse dokumente pošlje zavezancem, da jih pregledajo in potrdijo/ponovno podpišejo.

Ker da bi sedaj morali zavezanci PONOVNO izpolnjevati vse obrazce se mi zdi nepotrebna obremenitev zavezancev. Že tako bo veliko nepotrebnega dela zanje.

Drugega načina preverjanja itak ni.

Ok, ampak, kako bo to izvedeno. In tudi, ce jih ponovno podpisejo danes, so veljavni od danes naprej.

Ena kanta crvov, ki se je noben noce pipnit, je pa to, da efektivno pojma nimas kaj podpisujes. Kar nek plugin prikaze na ekranu, in kaj podpise sta lahko dve razlicni zadevi. Ubistvu bi moral dobit XML na download, ga lokalno odpret, prebrat in podpisat in poslat nazaj. Jasno je to rocket surgery za vecino uporabnikov, in predstavlja neresljiv problem. Zato tudi nihce niti noce odpirati vprasanja veljavnosti podpisov preko teh pluginov, ker bi to prizadelo vse take upravne projekte.

Ista fora (oziroma slabsa) fora so tiste tablice, ki ti jih molijo pod nos da se podpises na simobilu in mobitelu. Pojma nimas kaj podpisujes.

Osnovni name je, da s svojim podpisom zagotavljaš, da so podatki točni.

Zanimivo bi bilo, če bi nekdo oddajal lažne podatke (npr. da bo manj davkov za plačat). Potem ga en dan obišče inšpektor in ugotovi, da so oddani (in podpisani) podatki neskladni z dejanskim stanjem.

Inšpektor bi verjetno kaznoval podjetje, to pa bi se obrnilo na sodišče, kjer bi se šli prerekat o tem, da je podpis neveljaven, saj ima sama procedura X nepravilnosti, na koncu pa niti ne veš kaj si dejansko podpisal.

Kdo bi potegnil ta kratko?

Kdo bi odgovarjal, če bi zaradi takega šalabajzerstva bila na široko odprta vrata zlorabam, katere niti kaznovati nebi mogli?

Shalabajzer je 28. feb 2017 ob 00:07 izjavil:

V kodi je backdoor, ki v primeru, da je operacijski sistem Mac OS, keystore datoteko shrani z geslom "1234", kar omogoča enostavno krajo uporabnikovega certifikata.

Datoteka application/main.java v komponenti mdSigJava.

 private String getPasswd(boolean store) throws Exception {
 if (this.osType == Common.OsType.Mac) {
 return "1234";
 }
 DlgPasswd dlg = new DlgPasswd();
 return dlg.GetPasswsd(this.appStage, store, this.osType);
 }
 

To drži.

Med drugim so navodila na AJPES strani obupno spisana, zatakne se že pri prvem koraku, kjer nikjer ne napišejo katero potrdilo je potrebno namestiti (meni je jasno, moji mami pa to ni tako samoumevno).

Zanimivo je še, da mi testna spletna aplikacija za podpisovanje proXsign aplikacije ne zazna, kljub temu, da mi laufa in jo drugje uporabljam. S tem me prisilijo, da moram uporabiti njihovo, ki ima stranska vrata.

Še dobro, da to dela računovodja zame in mi ni treba samemu.