Útok na mining.bitcoin.cz

24.4.2013 12:25 | Přečteno: 1717× | BTC | poslední úprava: 26.4.2013 12:58

Dňa 23.04.2013 vo večerných hodinách ohlásil užívateľ na diskusii bitcointalk.org nedostupnosť stránky mining.bitcoin.cz.

Úvod

Po DDos útoku na danú službu, nasledoval útok proti uživateľskej stránke. Táto stránka slúži na registráciu a správu mining workerov a ich prostriedkov v digitálnej mene BTC.

Prehlad udalosti.

• Stránka je nedostupná, mining by mal prebiehať bez problémov. Potvrdzujú to príspevky diskutujúcich. Na spomínanej stránke je v prípade nedostupnosti tento text.

• Neskôr užívateľia potvrdili dostupnosť webu, ale došlo k odstaveniu stratum protokolu. Správca poolu ohlásil vo svojom príspevku, že danú udalosť vyšetruje. V príspevku užívateľa zaznela myšlienka o čase ktorý potrebuje mining softvér na zistenie dostupnosti poolu a výpočtu odmeny za čas nedostupnosti hlavnej stránky.

• Správca poolu vo svojom poste na bitcointalk.org vysvetluje pravdepodobnú príčinu nedostupnosti hlavnej stránky. V príspevku píše, že stránka bola hacknutá. Hacknutá znamená, že útočník získal prístup do aministráčneho rozhrania servera. Pravdpodobná cesta do managmentu servera viedla cez reset užívateľského hesla. Pritom správca nezaznamenal prienik do email schránky. Neskôr po náprave situacie došlo k opakovanému resetu hesla. Ako ďalšie fáza útoku bol prechod serverov poolu do rescue modu.Vďaka rychlej akcii správcu stihol urobiť snapshot databázy. Pravdopodné spôsoby útoku sú : vnutorná spojka alebo nejaká chyba v sofvéri manažmentu. Z dôvodu udalosti dôjde k strate BTC z tohto časového obdobia.

  Strata práce na blokoch je potvrdená správcom poolu.

  Vďaka snapshootu databázy nedošlo k modifikácii vyplatných adries.

• V ďalšom príspevku správca poolu definuje dôvody, prečo nemá spustené stratum servery v EC2. Mining pokračuje na pôvodnom hostingu. Ako jeden z dôvodov úvádza vyššie náklady ako v súčasnom hostingu. V jednom príspevku padla otázka prečo došlo k útoku na pool. Správca odpovedá vo svojom poste.

  V diskúsii zaznela teória o spôsobe útoku cez reset hesla. Hostingové služby sú väčšinou bezpečné. Samozrejme sila bezpečnosti závisí od fyzického prístupu. Napríklad ak je perfektná sieťová bezpečnosť ale slabá alebo žiadna fyzická bezpečnosť. V prípade odcudzenia servera alebo disku, nie su data chránené proti zneužitiu alebo krádeži hesla. Z toho dôvodu sú možné dva scenáre. Pomoc administrátora hostingu alebo phising.

  Neskôr bola teória vyvrátená. Prístup k managmentu je riadený cez OTP (jednorazové hesla) a bez emailového konta nie je možné získať prístup k managmentu.

• Správca oznámil okamžitý presun poolu do nového hostingu. Zrejme z dôvodu, že súčasny hosting má v sebe bezpečnostnú dieru. Riešenie problému nemá zmysel.

• Z dôvodu nedostupnosti databázy nebudú odmeny zaznamenavané. Správca prislúbil rozdanie odmeny úžívateľom, ktorý neprepli na iný pool. K vyplateniu dôjde akonáhle bude dostupná databáza poolu.

• Reakcia správcu na frázu: "Ak ho nedržiš, tak ho nevlastníš."

• Presun poolu je dokončený. Miningadresy sú nasmerované na bezpečné servery.

• Hlavná stránka by mala byť dostupná hneď ako budé dokončená konfigurácia nekompromitovaného servera.

• Vyťažené BTC sú presmerované na inú adresu správcu poolu.

• Stránka poolu je dostupná. Funkcia poolu sa vrátila do normálného prevadzkového režimu. Je možnosť, že stránka náhodne vyhlasi režim údržby. Možno správca ešte doľaduje detaily. Podrobnosti k obnove databázy.

• Správca poolu poskytol v diskusii na abclinuxu.cz link na informácie o udalostiach a pripravovaných úkonoch. Ďakujem slush za link.

Záver

Zo súčasných udalosti vyplíva, že nestačí len bezpečnosť sieťi ale aj bezpečnosť fyzická.

Ďalšia otázka je možnosti prístupu lokálných správcov DC a hostingu. Aká úroveň prístupu je správna aby nedošlo k zneužitiu prístupových práv. Tiež nie je možné povoliť úžívateľovy plný prístup k správe servera, pretože by mohlo dôjsť k zneužitiu servera a lokálny správca by nemal možnosť zakročiť. Kde je ta správna rovnováha prístupových práv ? Ďalšia vec sú užívateľské PC s defaultnou konfiguráciou a bez akýchkoľvek bezpečnostných procedúr.

Ďalšia otázka je či tento incident súvisí s predošlým DDos útokom. Nebol DDos útok len maskovanie útoku na hlavnú stránku ?

Poznámka

Znovu neplánovaný blog ale udalosti vo svete si nevyberajú. Plynutie času nezaujíma či sa danej osobe udalosť páči či nepáči. Jednoducho plynie ďalej.

EDIT

Dopĺnenie úvahy o maskovaní tohto útoku, DDos útokom. - 24.04.2013 13:55

Pridanie ankety a korekcia textu. - 24.04.2013 14:12

Pridanie informácie o zmene BTC adresy poolu. - 24.04.2013 19:19

Vloženie informácie o dostupnosti hlavnej stránky poolu - 25.04.2013 11:07

Doplnenie linku na post správcu poolu o priebehu obnovy databázy. - 25.04.2013 13:53

Doplnenie linku od správcu poolu. - 26.04.2013 12:58

       

Anketa

Komentáře

[druzstevnik]

Pěkné shrnutí, díky!

[misch]

"Zo súčasných udalosti vyplíva, že nestačí len bezpečnosť sieťi ale aj bezpečnosť fyzická."

Mě to z článku tedy nevyplývá. Resp. čtu tam jen domněnky o tom že administrační rozhraní je údajně bezpečné a z toho plynoucí závěr že chyba musí být u providera. Netvrdím že to tak nebylo, ale trochu mě ta logika zdůvodnění překvapuje.

BTW: to byl virtuál, nebo fyzický server? A proč má hacknutí "hlavní stránky" (tedy z mého pohledu pouhého webu) vliv na těžení, tzn. na serverovou část která s webem nemusí mít mnoho společného?

[ewew]

Viem len toľko čo je na bitcointalk.org. Nevylučujem aj variantu, že to je úplne inak.

K fyzickej bezpečnosti. Ide hlavne o to aby lokálny admin nemal možnosť zistiť na ktorom serveri beží konkrétna služba. Ďalšia vec je prípad, že je nutné vypnúť určitú stránku. Táto situácia by mala byť autonómne zverejnená na domovskej stránke. Týmto by bolo možné zamedziť tiché vypnutie alebo zneužitie prístupu.

[Jendа]

BTW: to byl virtuál, nebo fyzický server?

Fyzický, ale v tomto případě je to úplně jedno, jak již zde bylo několikrát popsáno (snad si to nepletu s IRC :). Konzoli pro „záchranu“ to má tak jako tak. Útočník si prostě nakliká, že chce spustit livecd, k serveru se mu připojí KVM (lhostejno, zda fyzické nebo virtuální) a z livecd si prostě připojí disk a stáhne/změní data.

A proč má hacknutí "hlavní stránky" (tedy z mého pohledu pouhého webu) vliv na těžení, tzn. na serverovou část která s webem nemusí mít mnoho společného?

AFAIK proto, že přes web se nastavuje adresa, na kterou se ti posílají vytěžené BTC. Tedy útočník si tam nastaví svoji a nechá všechny vytěžené BTC odeslat.

[ewew]

AFAIK proto, že přes web se nastavuje adresa, na kterou se ti posílají vytěžené BTC. Tedy útočník si tam nastaví svoji a nechá všechny vytěžené BTC odeslat.

Tento scenár je možný len s prístupom do mailovej schránky užívateľa. Myslím, že pravdepodobnejšia verzia je vybratie peňaženky poolu. Ďalšia vec je, že všetky transakcie sú verejné. Stačí pozrieť blockchain.info.

[Jendа]

Tento scenár je možný len s prístupom do mailovej schránky užívateľa.

To si nějak nedokážu představit, jak je technicky vyřešené, že tam ta webová aplikace může zapisovat jenom po potvrzení mailem. Ale těžil jsem naposledy před 2 lety, tak nevím, nechám se překvapit :).

Ďalšia vec je, že všetky transakcie sú verejné. Stačí pozrieť blockchain.info.

To samozřejmě vím, ale nechápu, jak to souvisí. Spousta lidí už zjistila, že jim adresa 19kPDYubVp6ykeEQqrSgb5L84e45wJtUe5 ukradla peníze. Ale v čem jim to pomůže?

[misch]

Díky za osvětu. V tom případě by se tomu problému s livecd (resp. se záchranným režimem) dalo předejít šifrováním disku (luks, dmcrypt), že? A právě u fyzického serveru by to smysl mělo. Útočník by pak sice mohl provést shutdown/rescue/erase, ale nezískal by přístup k peněžence, heslům apod.

[Jakub Lucký]

Potíž je v tom, že ten šifrovaný disk musí nějak nabootovat, tzn. je tam nějaký kus, který musí být nešifrovaný (zavaděč+jádro). Útočník, pokud získá fyzický přístup, se tak může dostat sice jen k tomu, ale může ho zaměnit za jiné jádro s backdoorem, keyloggerem...

[Jendа]

(nicméně zde si slush útoku všiml, takže by potom kompromitovaný initramdisk nepoužíval)

[Jendа]

Hezké shrnutí.

Potřebujeme protokol, ve kterém nebude nic jako (centralizované) mining pooly potřeba. Dávám si to jako další položku do svého cryptocurrency wishlistu.

[czp]

co p2pool? http://p2pool.info/

[Jendа]

Cool, něco takového jsem si představoval. Hezké, že už to někdo vyrobil :).

[slush]

https://bitcoin-central.net/