Kada se firma ne pridržava sopstvene politike sigurnosti

• 3Ovo se svidja korisnicima: mcrule, diarno, Kentaurus
  
  Registruj se da bi pohvalio/la poruku!

dobije po nosu

O upadima i propustima se često piše, dešavaju se svima od običnih korisnika do korporacija ali nema veće sramote kada se to desi firmi koja svoju delatnost upravo bazira na prodaji sigurnosnih rešenja. Radi se o firmi HBGary, deo McAfee alijanse za sigurnosne inovacije (Security Innovation Alliance).

Aaron Barr, CEO HBGary, izneo je u javnost krajem 2010.god. da je uspeo da pronikne identitet ključnih osoba koje stoje iza grupe Anonimusa (poznati po DDOS napadima na Sajentologe 2008, i na PayPall, VISA, Mastercard 2010 zbog uskraćivanja usluga Wikileaks-u). Aaron je nameravao da informacije, prikupljene putem društvenih mreža kao što su Facebook, Linkedin i IRC kanala, proda FBI-u. Anonimusi mu naravno nisu ostali dužni i 5. februara 2011. Aaron Barr i HBGary su se našli u teškim mukama.

Serveri firme su uhakovani, baze prekopirane i dropovane; mail, linkedin i twitter nalozi kompromitovani, i tu, na žalost po HBGary nije bio kraj. Preko 50.000 emailova je okačeno na PirateBay, u okviru kojih su bila sav rad i "istraživanje" Aaron-a, uključujući i planove zajedničkog projekta sa drugim sigurnosnim firmama o napadu na Wikileaks i na one koje podržavaju isti. Jedan od naručilaca ovog projekta je Američka Banka za koju Wikileaks namerava da obelodani poverljiva dokumenta.
Ni tu nema još nema kraja ali to već nije poenta ove teme.

Na stranu polemike oko legalnosti ali činjenica je da HBGary trpi nemerljivu štetu zbog propusta u sigurnosti, iste te sigurnosti koju prodaju drugima za ne tako male pare. Prva greška koju su napravili je korišćenje custom CMS-a. To samo po sebi i nije toliko čudno jer obično firme gledaju da razviju ili plate neko custom rešenje za svoje potrebe, ali nema opravdanja ako se ne izvrši provera istog za propustima. Ništa im ne znači custom CMS ako isti padne kod najobičnijeg SQL injection napada, što im se upravo i dogodilo.

Napadači su iskoristili propust i došli do tabele sa nalozima i šiframa. Sreća u nesreći, šifre nisu bile u plain text formatu (pohvale za autore CMS-a, ipak su nešto odradili kako treba al ne u potpunosti) već su tabele sadržale samo MD5 heš šifri. Problem kod MD5 je što nije više toliko siguran način za određivanje heša, te se koristi nekoliko naprednih tehnika i metoda zarad onemogućavanja reverzibilnog heširanja (salt, višestruko heširanje itd). HBGary CMS nije imao ništa od toga, samo običan (plain) MD5 heš.

Ipak, napadači bi sigurno imali teži posao da se poštovalo pravilo da šifre budu što duže (preko 10 znakova) i kompleksnije (brojevi, veća i mala slova, specijalni znakovi), ali ne, ni to se nije pratilo. Da blamaža bude veća jedna od šifri do kojih su došli su upravo bile od CEO-a firme, Aaron Barr, koji nije našao za shodno da koristi kompleksniju šifru od šifre sa 6 znakova alfabeta (bez većih slova) i 2 broja. Blamaži se naravno još uvek ne vidi kraj jer je dotični istu šifru koristio za svoj mail nalog i za naloge na društvenim mrežama, pa još kad je CEO administrator mail servera firme nadolazak još veće katastrofe može i da se nasluti.

Drugi nalog, koji je patio od iste boljke kao i gore navedeni, iskorišćen je za upad na backup server, gde su napadači iskoristili exploit da dođu do root naloga (neko se nije setio da stavi zakrpu na rupu od novembra 2010. ), pokupe šta im duša ište, dropuju bazu i na izlasku obrišu sve.

Ne, ne još nije kraj. Arron-ov mail napadači su iskoristili za mali društevni inženjering. Zatražili su od admina sajta da otvori firewall i promeni šifru, pa čak da im da i username (?!?), što je ovaj učinio bez mnogo razmišljanja tj. setio se već kad je bilo kasno, tako da je pao jedan poveći deface sajta.

Epilog svega: ogromna šteta po HBGary, saradnici i klijenti se ograđuju i beže kao đavo od krsta, poverenje u njih razrušeno (ko da poveri firmi brigu o sigurnosti kad ne ume ni sama sebe da zaštiti) a CEO predmet sprdnje i podsmeha.

Ceo ovaj slučaj ako se posmatra sa stanovišta sigurnosti, pokazuje kako male stvari i na oko sitni previdi mogu dovesti do pravog pakla i ogromnih gubitaka, kako novčanih tako i živčanih. Verujem da će svako ko pročita ovaj tekst da se debelo zamisli oko šifri koje koristi, oko SQL-a (bar oni koji se time bave ), oko važnosti sigurnosnih zakrpa i kako treba obratiti veliku pažnju u slučaju kada vam kolega zatraži da isključite firewall i promenite mu šifru

http://arstechnica.com/tech-policy/news/2011/02/an.....-hack.ars/

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Citat:HBGary CMS nije imao ništa od toga, samo običan (plain) MD5 heš.

Ipak, napadači bi sigurno imali teži posao da se poštovalo pravilo da šifre budu što duže (preko 10 znakova) i kompleksnije (brojevi, veća i mala slova, specijalni znakovi), ali ne, ni to se nije pratilo.
Nema veze duzina sifre ukoliko se koristi MD5 hash kao nacin skladistenja sifre.

• 1Ovo se svidja korisniku: mcrule
  
  Registruj se da bi pohvalio/la poruku!

U ovom slucaju lozinke nisu ni bile "soljene", zato je bilo lako iskoristiti rainbow tabele. Ali nacin na koji su dobili korisnicko ime i lozinku... social ingenering at its best.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Smijesno kako su pali, kao gomila 10o godisnjaka.