Furs zagotavlja: zdaj smo pa res popravili varnost portala eDavki
Aprila smo odkrili hude varnostne ranljivosti portala eDavki. Avgusta naj bi bile odpravljene. A bralci ste opozorili, da temu ni tako. Zdaj na finančni upravi spet zagotavljajo, da so varnost izboljšali.
Strokovnjak za elektronsko varnost Matej Kovačič je na portalu podcrto.si aprila letos opozoril na hude varnostne ranljivosti portala eDavki. Te so omogočale prestrezanje podatkov ter celo krajo identitete in s tem potvarjanje davčnih podatkov uporabnikov portala. Na testu varnosti strežnikov si je davčna upravatakrat prislužila najnižjo možno oceno, F.
Davčna uprava nam je aprila obljubila, da bodo varnost izboljšali do konca septembra. Varnost portala smo sproti preverjali in že v sredini avgusta je test pokazal izboljšano varnost. Portal eDavki je namreč dobil oceno B.
A le dan po objavi članka, v katerem smo davčno upravo pohvalili za izboljšano varnost, ste nas bralci opozorili na ponoven slab rezultat testa varnosti. Portal eDavki smo še enkrat testirali in res: spet je dobil oceno F.
Odločili smo se počakati do prvotnega roka, ki so si ga zadali na nekdanji davčni, zdaj finančni upravi. Portal smo testirali v prvih dneh oktobra, test je zopet pokazal oceno F. Zato smo se na davčno upravo obrnili z vprašanjem, zakaj so zopet »poslabšali« varnost portala eDavki po tem, ko so jo sodeč po našem avgustovskem testu že izboljšali.
Odgovorili so, da uporabljajo »več strežnikov aplikativne požarne pregrade, na katerih se zaključujejo seje SSL in delujejo v t.i. sticky load-balancing farmi,« in da vsi strežniki avgusta še niso bili varnostno posodobljeni. Drugače povedano: posodobili so le del strežnikov, prek katerih uporabniki dostopajo do portala eDavki. Po njihovih zagotovilih z dne 13. oktobra so bili ta dan varnostno posodobljeni vsi strežniki.
To trditev smo se odločili ponovno preveriti. A test, ki smo ga izvedli naslednji dan, je (spet) pokazal najnižjo oceno varnosti, F (datum testa je razviden v levem zgornjem kotu spodnje slike).
Seveda smo finančno upravo ponovno zaprosili za pojasnila. Še posebej nas je zanimalo, zakaj trdijo, da so vsi strežniki varnostno posodobljeni, če testi tega rezultata ne odražajo. Njihov odgovor? »Zaradi velike obremenjenosti sistema eDavki, ki je bil posledica oddaje dokumentov davčnih zavezancev, smo morali v produkcijski sistem začasno vključiti tudi strežnike, ki smo jih sicer že umaknili iz produkcijskega okolja. Take obremenitve v času izvajanja predprodukcijskih testov, preden smo dali nove strežnike v produkcijo, nismo mogli simulirati.«
Petnajsti dan v mesecu je rok za oddajo dokumentov o poslovanju finančni upravi. Zaradi navala davčnih zavezancev okoli 15. oktobra so morali torej ponovno vključiti tudi varnostno neustrezne strežnike. Tudi težavo s preobremenjenostjo v času oddaje davčnih dokumentov so po njihovih najnovejših zagotovilih na finančni upravi že rešili, zato se slabi rezultati na testu ne bi smeli več ponoviti.
Upamo, da to drži. Lahko pa preverite tudi sami. Naslednji mesec lahko okoli 15. novembra varnost portala testirate v aplikaciji SSL Labs. Če bo test ponovno pokazal oceno varnosti F, nas na to opozorite – najbolje s posnetkom ekrana vašega računalnika, s katerega bo razviden čas testa.
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.
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 …
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.
1 komentar
TadejM 19. 1. 2016, 20.47
Opazil sem tale članek iz leta 2014 in sem preveril, če so torej na eDavkih izboljšali varnost.
Rezultati testa se prikažejo, če v brskalnik vpišemo naslov (in počakamo, da se test konča):
https://www.ssllabs.com/ssltest/analyze.html?d=edavki.durs.si&hideResults=on
Mene bi zanimali odgovori na sledeča vprašanja, če bi lahko kdo iz eDavki odgovoril:
1. Glede na zgornji test je razvidno, da strežnika eDavki varnostno že dlje časa (vsaj leto dni) niste nadgradili.
a) Kakšne varnostne postopke uporabljate za ugotavljanje ranljivosti v programski opremi?
b) Če uporabljate produkt (penetration teste) priznane varnostne družbe, kako je ime produktu?
c) Kako pogosto izvajate varnostne teste?
d) Ko se ugotovijo ranljivosti, kakšen je postopek ukrepanja? Penatration testi bi morali (glede da ssllabs.com test pokaže) pokazati ranljivosti?
2. Strežnik edavki.durs.si uporablja samo protokol TLSv 1.0, ki danes ni več varen (edino resnično varen je TLS v1.2 z AHEAD algoritmi). Zakaj ne uporabljate trenutno edino resnično varnega protokola TLS v1.2 (Vir 1)?
3. Zakaj ne uporabljate ECDHE-RSA mehanizma za izmenjavo asimetričnih ključev?
4. Zakaj uporabljate algoritem TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, ki ga imate celo nastavljenega z ne-varnim parametrom (Vir 2)? Namreč vsi brskalniki, ki podpirajo DHE mehanizem podpirajo tudi ECDHE mehanizem. Torej v čem je razlog uporabe DHE mehanizma?
5. Zakaj za podpisovanje (certifikat) še vedno uporabljate SHA-1 zgoščeni algoritem, ki je dokazano ne-varen (Vir 3)? Zakaj ne uporabljate SHA-2?
6. Zakaj za šifriranje podatkov uporabljate simetrični stream šifrirni algoritem RC4, ki je že več let dokazano ne-varen (Vir 4 in 5)?
7. Zakaj ne uporabljate Forward Secrecy šifrirnih algoritmov, ki so edini odporni na pretekli posneti mrežni promet (Vir 6)?
8. Zakaj na seznam asimetričnih šifrirnih algoritmov ne dodate resnično varnih AHEAD algoritmov npr. GCM-AES?
9. Zakaj uporabljate leaf certifikat z veljavnostjo petih let? Praksa nekako svetuje maksimalno dve leti. Na primer novo ustanovljena CA "Let's Encrypt" menjuje certifikat celo vsakih 90 dni (Vir 7). Zakaj ste se odločili ravno za obdoblje 5 let za veljavnost certifikata?
10. a) Ko uporabnik obišče spletno stran e-davki in vstopi v enkriptirano okolje (https), zakaj uporabnik dobi obvestilo, da je certifikat ni zaupanja vreden (untrusted)?
b) Zakaj na primer root certifikat ni navzkrižno podpisan z uveljavljenim CA (cross-signed), s tem bi namreč odpravili opozarjanje uporabnika o ne-zaupanja vredni spletni strani?
c) Raziskave kažejo, da uporabniki ne berejo varnostnih opozoril (tudi računalničarji ne), ampak da kar sprejmejo ponujeni certifikat, čeprav brskalnij javi opozorilo o tveganem certifikatu. Ali menite, da so uporabniki vaših storitev dovolj računalniško podkovani, da ne nasedejo potencialnemu MITM napadu?
d) Na kakšen način podučite uporabnike, da nezaupanja vreden (s strani brskalnika) certifikat sprejmejo in da v tem primeru ne gre za MITM (man in the middle attack) napad?
11. Dodatno vprašanja imam glede na izjavo iz članka na podcrto.si iz oktobra 2014 (Vir 8).
"Odgovorili so, da uporabljajo »več strežnikov aplikativne požarne pregrade, na katerih se zaključujejo seje SSL in delujejo v t.i. sticky load-balancing farmi,« in da vsi strežniki avgusta še niso bili varnostno posodobljeni."
a) Glede na to, da glede na izjavo, vsi strežniki v okolju niso enako varni, kakšne varnostne teste izvedete preden vključite strežnik v "load balancing" sistem?
b) Kako je možno, da eni strežniki v sistemu naj bi bili domnevno posodobljeni, drugi pa ne? Razumljivo je, da se to zgodi znotraj enega dne (morda bolje znotraj ene ure), ne pa da je takšno stanje domnevno dlje časa. Kakšen je razlog?
c) Kako na splošno skrbite za kakovost sistema strežnikov (vključno z varnostnimi posodobitvami)? Namreč če so eni strežniki posodobljeni in drugi ne, kakšne mehanizme testiranja/preverjanje uporabljate, da zagotovite varnost sistema kot celote?
12. V istem članku je odgovor.
»Zaradi velike obremenjenosti sistema eDavki, ki je bil posledica oddaje dokumentov davčnih zavezancev, smo morali v produkcijski sistem začasno vključiti tudi strežnike, ki smo jih sicer že umaknili iz produkcijskega okolja. Take obremenitve v času izvajanja predprodukcijskih testov, preden smo dali nove strežnike v produkcijo, nismo mogli simulirati.«
a) Zakaj strežniki (verjetno je govora o programskih strežnikih), ki so bili umaknjeni iz produkcijskega okolja, niso bili uničeni? Namreč, če odmaknjen strežnik ni uničen, potem ga je potrebno varnostno nadgrajevati. Kakšne varnostne mehanizme "uničevanja" neustreznih strežnikov uporabljate?
b) Kako ste lahko nenadgrajen (odmaknjen) strežnik vključili v produkcijsko okolje, preden je bil na tem strežniku izveden ponoven varnostni test? To morda kaže, da varnostnih testov ali ne izvajate ali pa jih izvajate nekoliko površno. Ali torej izvajate varnostne teste?
c) Kako je narejeno podvajanje verjetno virtualnega okolja strežnikov, da se zagotavlja varnost/stabilnost sistema? Namreč, ko se ugotovi performančno pomankanje strežnikov, je potrebno klonirati virtualno okolje. Kako se zagotovi, da se klonirajo varni strežniki in ne varnostno nenadgrajeni strežniki?
Viri:
(1) https://community.qualys.com/blogs/securitylabs/2015/05/22/ssl-labs-increased-penalty-when-tls-12-is-not-supported
(2) https://weakdh.org/
(3) https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know
(4) https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
(5) http://www.isg.rhul.ac.uk/tls/
(6) https://en.wikipedia.org/wiki/Forward_secrecy
(7) https://community.letsencrypt.org/t/pros-and-cons-of-90-day-certificate-lifetimes/4621
(8) https://podcrto.si/furs-zagotavlja-zdaj-smo-pa-res-popravili-varnost-portala-edavki/