Letní prázdniny byly zrovna v půlce. Část kolegů pryč na dovolené a část na větší realizaci u zákazníka. Já jsem se snažil prokousat klasickým pondělním shonem, kdy mám mailovou schránku zaplněnou e-maily od o víkendu dobrovolně či nedobrovolně pracujících workoholiků.
Zavolal nám nový zákazník, že mu prý nechce nastartovat server a externí disk se zálohami se nenačítá. Dostal na nás kontakt od svého známého, že jestli mu je někdo schopen pomoci, tak že jsme to my (taková chvála nás vždy těší 😊).
Popis situace
Od zákazníka jsem následně dostal tuto fotku s obrazovkou serveru. Řekl jsem si OK, tohle jsem ještě neviděl a vypadá to zajímavě. Rychle jsem zagoogloval a tipnul si, že to je tak 50/50 fake. Zákazník se tedy vydal na nepředvídatelnou 4hodinovou cestu z Plzně do Brna po D1.
Než zákazník dorazil, stihl jsem trochu více googlit. Podařilo se mi zjistit, že někteří útočníci přešli od svých, často děravých „cryptovirů“ na legitimní nástroj Diskcryptor. Jejich „cryptoviry“, resp. nástroje, kterými šifrovali data, měly často nějakou vadu. Díky těm vadám se dařilo bezpečnostním firmám šifrování prolomit a útočníci tak přišli o výkupné.
Je to poměrně chytrý tah. Už dříve jsem si říkal, proč to tak nedělají. Využitím ověřených open source nástrojů totiž: obejdou antivirus (protože se jedná o legitimní aplikaci), nebudou muset sami nic programovat a neudělají tak v programu chyby, které by zhatily jejich zálusk na výkupné.
Když jsem si pak porovnal výše uvedenou fotku s „promptem“, kterou má DiskCryptor, byl jsem si poměrně jist proti čemu jdeme (FVE – full volume encryption – šifrování celých diskových oddílů). Nechtěl jsem to však hned vzdát, protože zákazník se na nás spolehl a hledal jsem dále.
Když dojel zákazník
Pořád jsem doufal, že útočníci udělali nějakou chybu a data se podaří obnovit. Například někteří útočníci používali stále stejné heslo a já doufal, že by mohlo fungovat. Bohužel žádné z hesel nefungovalo.
Nabootoval jsem „Active@ LiveCD!“ a začal analyzovat data na interním RAID serveru. Na vedlejším PC jsem pak analyzoval externí disk pomocí „EaseUS Data Recovery Wizard“. Disky serveru i externí disk byly opravdu zašifrovány pomocí DiskCryptoru. Další analýzou jsem však objevil i nějaká nezašifrovaná data. Dle mého názoru se jednalo o „volné místo“ (smazané soubory v době před spuštěním Diskcryptoru), které Diskcryptor vynechal, aby zkrátil dobu šifrování. Asi bychom z toho nějaké MDF soubory, o které šlo zákazníkovi nejvíce dostali, ale ani tak by to nebyl žádný zázrak a trvalo by to řadu hodin.
Situace byla tedy následující:
- Zákazník nemá žádné zálohy. Jediné, které měl, byly ty na externím disku, který je také zašifrován.
- Disky serveru i externí disk jsou zašifrovaný legitimním SW DiskCryptor, u kterého nečekám žádné chyby, které by měly být v brzké době odhaleny.
- Zákazník vyčíslil ztrátu na 63 tisíc za každý den, kdy data nemá.
- Útočníci se zákazníkem nekomunikovali.
Komunikace s útočníky
Ještě, než zákazník dorazil, začal jsem s útočníky vyjednávat. Byla to taková pojistka, kdyby náhodou došlo na nejhorší a my nedokázali data obnovit. Vyjednávání jsem vedl ze soukromého e-mailu (abychom je nevyplašili a neodhadli, kolik je zákazník ochoten zaplatit) v angličtině (útočníci česky neumí 😊).
Musím říct, že rychlost odpovědí útočníků by mohla závidět kdejaká korporátní help linka. Útočníci nastřelili cenu na 2,1 BTC, což bylo v té době cca 126 tisíc korun. Vyjednával jsem ve stylu, že jsme malá rodinná firma a tolik peněz nemáme. Dostali jsme se tedy na 0,5 BTC (cca 30.000 Kč). Myslím, že by se to dalo uhrát ještě níže, ale zákazník byl již s touto cenou spokojený a vzhledem ke ztrátě, která mu vznikala za každý den nedostupnosti, na částku přistoupil.
Převedli jsme tedy peníze do BTC, útočníkům zaplatili a s napětím jsme čekali, zdali dostaneme heslo pro odemčení disku. Za pár minut přišel e-mail i s heslem, které bylo poměrně jednoduché (6 číslic) a naštěstí fungovalo.
Konec dobrý, všechno dobré
Normálně bych nepokládal zaplacení výkupného jako úspěšný konec záchrany dat…
Na druhou stranu:
- Když nám zákazník ráno volal, tak se bál, že už data nikdy neuvidí a že to bude znamenat konec firmy.
- Měl však štěstí, že v tomto případě šlo výkupné zaplatit a data opravdu získat zpět.
- Vše se nám podařilo stihnout během 1 dne (v 8 hodin večer odjížděl s funkčním serverem z Brna zpět do Plzně). Ztráty z výpadku tak byly nízké.
- Útočníci neodhadli hodnotu dat, ke kterým se dostali. Zákazníka přišlo výkupné poměrně „levně“.
Poučení z příběhu?
Poté, co jsme server odemkli zaslaným heslem, začal jsem zjišťovat, jaký byl způsob průniku. Původně jsem podezříval prolomení uživatele Administrator skrze slovníkový útok na port-forwardované RDP (viz Ransomware 1: Obnova dat aneb štěstí v neštěstí). Neměl jsem však jistotu, heslo zde bylo slabé, ale nikoliv úplně slovníkové. Po naběhnutí serveru mi však bylo jasné, že útok byl veden ručně skrze VNC, které zde bylo ponecháno se slabým heslem a s přístupem z internetu.
Viděl bych následující kritické problémy u serveru:
- Nedostatečné zálohy: server byl zálohován pouze na připojený externí disk a to tak, že se zálohovala jenom samostatná databáze. Nebezpečí je zde několik:
- Pomalá obnova: jelikož se zálohuje pouze DB a nikoliv celý server. Tak v případě obnovy by se musel celý server nainstalovat znovu (aktualizace, ovladače), nainstalovat databáze, nainstalovat informační systém, vše znovu nakonfigurovat a nakonec obnovit databázi. To je práce více jak na 1 den a ještě k tomu bude pravděpodobně potřeba spolupráce výrobce IS.
- Nepřežijí útok: jelikož jsou zálohy dostupné běžně ze serveru, tak v případě jeho prolomení přijdete i o zálohy (viz tento případ). Je potřeba se na takovéto věci připravit a mít zálohy odolné. V PATRON-ITu jsme zavedli dvě technologie, které nejsou drahé a zálohy ochrání. Brzy o nich také vyjde článek.
- Zbytečné služby: paradoxní je, že VNC již několik let nikdo nepoužíval, ale přesto jej neodstranili. Je to stejné, jako jsem psal v případě („Ransomware 1: Obnova dat aneb štěstí v neštěstí“) u jiného zákazníka. Chce to nepoužívat uživatelské účty se známými jmény, blokovat nepoužívané účty, mít silná hesla, deaktivovat port-forwardy co nepoužíváte anebo je omezit jen na konkrétní IP.
Neaktualizovaný systém: po naběhnutí serveru jsem si všiml, že operační systém nebyl 4 roky aktualizován. Sice to v tomto případě nehrálo roli, ale byla by jen otázka času, než by byl server kompromitován na základě nějakého exploitu (např. EternalBlue). Stačilo by jen aby někdo zapojil do sítě infikovanou stanici.