Ovo je kratki pregled sadržaja baze koju je nepoznata osoba skinula sa sajta lakodoposla dot com i ujedno savjet kako da osigurate tudje i svoje privatne informacije. Ovdje će izostati analiza šifri (karakteristike, frekvencija, duzina, ostalo) koja bi trebalo da bude u narednom periodu a i ujedno će sadržaj biti u Wifi pass fajlu
Baza se pojavila prvo na jednom od reddit subova, tj skrihshoot a poslije nekog vremena i link ka kompletnoj bazi.
Šta se nalazi u bazi?
Baza sadrži informacije o poslodavcima i radnicima koji traže posao. Jedan dio se odnos na komunikaciju izmedju administracije sajta i poslodavaca gdje se vrši plaćanje usluga. Svi skupa imaju sljedeće informacije: ime/prezime, email, šifre, adresa/ulica/grad, broj telefona, datum rodjenja.
Slika zapisa baze
Baza sa korisnicima počinje nekad od 2008 godine a posljednji unos/izmjene su 28 Jula 2022 u 02:21
Informacija o datumu kreiranja zadnjeg naloga je jako bitna kao i broj kreiranih naloga ukupno i vremenski period.
Baza sadrži oko 510.000 zapisa radnika. Od toga je u 2022 godini registrovano 10.000.
Kako su došli do baze?
Baza je vjerovatno skinuta sa nekim od alata (sqlmap, sqlninja i slično) a preko buga u sajtu (vjerovatno SQL injection). Napadac je vjerovatno onda prebacio u svoj phpmyadmin pa dumpo/izbacio bazu u sql fajl i okacio na jedan od foruma. Razlog je gledanje informacija iz baze (tražio je kartice, pristupne šifre, mailove i drugo) U ovom teksu se neću baviti propustima i ovo sve navedeno je nagadjanje u nedostatku informacija.
Kako ne raditi sa privatnim informacijama
Ovo je najbitniji dio teksta i ovome sam želio pisati. Ovdje ću tek nekoliko osnovnih i bitnih stavki vezano za sigurnost napomenuti. Ima ih još pa čak u narednom periodu planiram preduzeti neke korake kako bi se generalno stanje na ovom polju u BH/SRB/CG/HR počelo mjenjati.
Trajanje zapisa privatnih informacija
Svako kreiranje naloga treba da ima kada je osoba zadnji put se logovala. Iz te informacije treba izvršiti da poslije 90 dana neaktivnosti šaljemo korisniku email upozorenja a zatim ako nema odgovora - brišemo iz baze. Sa ovim pristupom od 510.000 privatnih informacija, šteta bi se svela na svega 2000 do 4000 naloga.
Kvalitet šifre + 2FA ili čak OAuth2 identifikacija
Sve šifre se čuvaju u nekoliko formata: plain text, wordpress hash(wp hash) i bcrypt hash(bcrypt). Sajt lakodoposla nema minimum duzine (idealno 12 do 16), miks slova, brojeva i specijalnih znakova. Prilikom kreiranja naloga šifre kao "12345678" je moguće unijeti. Takve stvari su nedopustive.
Sajt takodje nema 2FA (izuzetno lako integrisati sa freeOTP) koji bi u slučaju pogadjanja šifre moguće je sačuvati pristup sajtu (pod uslovom da nema curenja baze i slično). Čak i ako se koristi ista šifra za različite sajtove 2FA pravi ogromnu razliku.
freeOTP logo
Sljedeći iz ovog arsenala je OAuth2 protokol koji može da posluži za registraciju i pristup sajtu. Sa SSO (single sign-on) korisnik može autorizovati sajt da preuzme informacije i kasnije da pristupi istom tom sajtu. Ovdje se ne mora posjedovati šifra - sve se čuva u OAuth provajderu a minimum informacija koje sajt treba da ima su email, ime i prezime, ostalo.
OAuth2 - slika preuzeta sa InterSystems Learning Services youtube kanala
Minimiziranje dijeljenja privatnih informacija i skladištenja u bazi
Imamo nekoliko bitnih privatnih informacija koje moramo držati u bazi a sve se mogu redukovati i smanjiti negativni uticaj curenja informacija. Ovdje pričamo o ime/prezime, email, broj telefona, CV-iju, tekstualne poruke.
Ime i prezime: redukovati na samo ime sa početnim slovom prezimena. Apsolutno nebitno poslodavcu a u komunikaciji kasnije moguće je saznati.
Email: Ukratko moguće je u bazi drzati email koji je povezan sa korisnikom i loginom, a da pri tome ne držimo pravi email. Slanje na ovaj email bi mogao samo servis zbog informacija/resetovanja i slično. Samim tim bi npr imali 9dc3242cd523367c2296afbc65520f29@domena.com gdje bi na email serveru identifikacija za 9dc3242cd523367c2296afbc65520f29 bila prema ovojenekimail[at]gmail dot com. Naravno, ovdje se može smanjiti veličina hasha, uzeti neki drugi koji pruža bolju sigurnost (argon2id, scrypt, PBKDF2) i napraviti format koji je pogodan za email adresu.
Broj telefona: Ako postoji mogucnost izbaciti skroz. Ako bas se mora implementirati onda bi jedinstveni ID bio u bazi a pravi broj bi se čuvao na drugom mjestu i informacije slale kroz REST API.
CV: Izbaciti sve privatne detalje, imena firmi - kasnije je moguće poslati zainteresovanom poslodavcu puni CV sa detaljima. Ovdje bi trebalo da sama firma koja vodi sajt pregleda isti taj CV i ukloni isto sve privatne detalje radnika i firmi.
Tekstualne poruke: Godina je 2022 i vi dalje vjerujete da vam niko neće sem vas samih čitati poruke? Public key, moguće je šifrovati poruke i držati ih kao takve u bazi i za svaku sesiju / tekst imati ključ koji se opet čuva sa master ključem / privatnim ključem (ovdje treba PKI al ideja je da se poruke ne ostavljaju u otvorenom tekstu). Uglavnom: ne ostavljajte poruke u bazi u "otvorenom tekstu"
Zaključak
Ovaj incident je samo "demo" sajtova u SRB/HR/BH/CG/MK gdje se ne vodi računa o privatnosti korisnika. Samo da je ispoštovano pravilo 90 dana il manje - uticaj ovoga bi bio redukovan sa 510.000 zapisa na 2000 do 4000. Pričamo o brojevima telefona, email adresama, datumima rodjenja, punim imenima i prezimenima oko pola miliona ljudi. Ovakve informacije se mogu koristiti za dalji napad, uznemiravanje ljudi, preprodati ili zloupotrebiti na druge načine. Sajt se nalazi na Linodu u USA - isto nedopustivo kada znamo da informacije gradjana Srbije treba da budu u Srbiji. Nisam spominjao standarde, penetration testing, hardening sajta i drugo - koji bi definitivno smanjili šansu da se dese ovakvi ishodi.
Zahvalnica
Gospodinu @milos_rs_ koji je pokazao skrinshoot i naveo početni dio (phpmyadmin). Svima koji stvaraju i kreiraju sadržaj a vezano za računarsku sigurnost.