Vdor v strežnike Domovanja in Domenca

10 naročnikov

Pozdravljeni, včeraj sem dobil obvestilo Domovanja, da je v torek 6.9. pri njih prišlo do poskusa vdora. Mogoče, kdo ve, kaj več o tem napadu?

Prilagam še kopijo obvestila:

Spoštovani,

zaradi varnostnih razlogov smo ponastavili vaše geslo za dostop do uporabniških strani. Dostop do uporabniških strani Domovanje.com lahko ponovno pridobite, tako da s klikom na naslednjo povezavo zahtevate ponastavitev gesla in sledite navodilom, ki jih boste prejeli po elektronski pošti.

Predlagamo vam, da v skladu z varnostno prakso ne izberete istega gesla in preverite, če ste isto kombinacijo elektronskega naslova in gesla uporabili tudi na kakšni drugi spletni storitvi in geslo spremenite tudi tam.

Zakaj takšna prošnja?

V torek, 6. septembra, smo zaznali poskus vdora, kjer je napadalec prek naše spletne strani skušal dostopati do podatkov v naši bazi podatkov. Naši tehniki so takoj po identifikacij zaprli vektor napada ter pričeli z analizo incidenta. Po opravljeni začetni analizi smo včeraj, v četrtek 8. septembra, ugotovili, da obstaja možnost, da je napadalec dostopal do uporabniških podatkov naših naročnikov, med drugim tudi do uporabniških imen in šifrirane oblike gesel.

Kljub temu, da še ni potrjeno, da je napadalec pridobil podatke, smo se odločili, da v skladu z varnostnimi priporočili, sprejmemo vse ukrepe s katerimi bi preprečili potencialno škodo. O incidentu smo tudi obvestili SI-CERT in ga prosili za pomoč pri nadaljnji raziskavi incidenta in iskanju storilca.

Vse spletne strani in e-pošta naših strank se nahajajo na drugih strežnikih in po ugotovitvah dosedanje analize niso bili predmet napada.

Naši strokovnjaki trenutno izvajajo nadaljnjo analizo incidenta. Poleg vseh varnostnih ukrepov, ki so nam že sedaj omogočili zaznati ta poskus vdora, bomo seveda vseskozi uvajali nove ukrepe in aktivnosti. Varnost in pravilno ukrepanje v primeru incidentov nam je pomembna vrednota in želimo biti vzgled vsem ostalim ponudnikom v regiji.

Ekipa Domovanje.com

@twosocks: Spregledal si objavo #9, ki ima vezo z nami.

suprpp:
@twosocks: Spregledal si objavo #9, ki ima vezo z nami.

aha torej avant.si = neoserv ... nisem povezal. Hvala za pojasnilo.

<manjsi_offtopic>Sicer me takšni vdori še kar strašijo, ampak če se hosting providerji potem bolj začnete zavedati varnosti in hitreje vpeljevati izboljšave, so vsaj za nekaj dobri.</manjsi_offtopic>

suprpp:
@spicey: Hvala za skrb. :)

Stanje v našem sistemu je bilo do včeraj sicer sledeče:
- gesla in ostali podatki v bazi so v vsakem primeru že zakodirani, tako da je sama podatkovna baza praktično neuporabna brez PHP datotek;
- pri nas je bilo geslo vidno samo preko "salt" ključa oz. se preko le-tega odkodira, da je lahko sploh vidno;
- gesla torej v bazi niso bila v plaintext obliki.

Se opravičujem za malo offtopica ampak tole je pač treba omenit...

No, da razjasnimo par stvari.
Ker se očitno gesla dekodirajo pomeni da jih ne shranjujete v obliki hashov. salt o katerem ti govoriš je dejansko ključ za kerkoli simetričen kripto ste že ali pa še uporabljate.

Neglede na način hrambe plaintext gesla pač nikoli ne pošlješ uporabniku nazaj, kvečjem resetiraš in posreduješ po vnaprej znanem kanalu link za zamenjavo. Pri uporabi hashiranja so gesla v nereverzibilni obliki (lahko samo primerjaš hash-a, ne pa inputa(plaintext geslo) ki sta le te hashe dala). Salt se uporablja kot dodatni random input skupaj z originalnim plaintext geslom zato da se oteži uporabo dictionary napadov na hashe.

Point tega je da nobena implementacija v kateri imate vi vpogled v plaintext gesla strank na kakršn koli način ni varna.

http://www.securityinnovationeurope.com/blog/whats-the-difference-between-hashing-and-encrypting

@aaaccc, se razumemo, mogoče je @suprpp napisal malo nejasno.

Hotel je povedati, da tudi pred to spremembo, gesla niso bila v "plain text" obliki, so pa bila reverzibilna. Vseeno je taka baza bila odporna tudi na dictionary attack, saj za to naše "custom" kodiranje slovar ne obstaja. Težava bi bila lahko samo v primeru, da bi nekdo prišel do baze in kode.

Situacija sedaj:
Gesla so hashirana s SHA, ter zasoljena z dolgim salt-om.

V prihodnje se obeta še nekaj novosti na tem področju, kot je omenil že @suprpp, med drugim tudi 2FA s pomočjo SMS-ov.

Torej so imeli "vaši administratorji" (in vsi, ki so imeli dostop do tiste mašine) možnost kadarkoli "pogledati" geslo za kateregakoli uporabnika? Wow...

Ne. Edina oseba, ki bi teoretično lahko dekodirala gesla, sem jaz osebno.

Mimogrede opazka: če ste na novo razvijali sistem bi lahko uporabili kak standardni Bcrypt namesto SHA.. če vam ukradejo bazo in sol še zmeraj lahko probavajo z brute force. Z bcryptom (npr cost=10) se zadeva vsaj hudo upočasni.

Ni uporabljen SHA.
Uporablja se password_hash, z algoritmom PASSWORD_BCRYPT. Implementirano je tudi ponovno generiranje po potrebi (passwordneedsrehash). Cost option ni podan, tako da se uporablja privzeti 10, tako kot si sam že omenil.

Good enough? :)

Kakor za koga za mene je good enough če ni "reverzibilno" + salted. Sicer pa je v Sloveniji to tako stalna praksa in potem tekmujemo kdo je slabši? Brez skrbi, tukaj verjetno FURS krepko vodi z njihovimi potegavščinami na eDavkih.

Boljše vprašanje je seveda kako si sploh nekateri to upate, jaz si nebi. V končni fazi se lahko zgodi, da določen uporabnik reciklira gesla (verjamem, da jih veliko in to sploh ni sporno iz pravnega vidika recimo) in bi lahko objava takšnih podatkov pomenila tudi večjo finančno škodo, za katero bi v primeru tožbe (verjetno) tudi odgovarjali, ker kolikor vem ste po zakonodaji (ZEKom če se prav spomnim) dolžni poskrbeti za ustrezno varovanje in obdelavo podatkov.