no pokud se dostal k MD5 hashům hesel, tak ani nemusel použítat rainbow tabulky, ale mohl najít "kolizní" heslo viz [http://www.root.cz/clanky/tunely-v-hasovacich-funkcich-kolize-md5-do-minuty/]

pa3k napsal/a:
-------------------------------------------------------
> Takže bližšie info.
> Z logov webservera z času zmeny tabuľky rs_bloky
> vyplýva, že vloženie obsahu išlo cez regulérny
> login. Útočník sa dokonca odhlásil. Vyzerá to na
> útok cez zistenie hash hesla, jeho nájdenie v
> rainbow tabuľkách a následné RUČNÉ prihlásenie do
> webu cez nájdené heslo.
>

Patriku,
ja jsem vzdy vyjimka :-))
stranky [http://www.hnfond.cz] jsou taky napadeny, avsak!!!
Avsak na techto strankach nikdy za celou jejich eru nebyl prihlasen, v rs:ctenari neni zadny ctenar, a v ssesions taky nic neni ze by se nekdo nejak?? prihlasil.

Bohuzel tyto stranky jedou na free forpsi a tak se obavam ze logy asi nebudou.

pa3k napsal/a:
-------------------------------------------------------
> JanVar:
> v logoch ten text odkazu nenájdeš, pretože išiel POST-om. Poslal som ti mailom čo treba hľadať ;-)

nehledal jsem boží dar, spíše pokusy o průniky do nepovolených oblastí (adresářů)... A díky za mailíka


-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------

U nás též gallery.php není a nebyla => útok musel být veden jinudy.

Pa3k: ten robotický sken/útok byl ze stejné IP jako vložení odkazu? Takové skeny jsou obecně dost běžné... S ohledem na datum by šlo zřejmě o [zatím nezacílenou] přípravu útoku - tj. vyhledání jakéhokoli zranitelného systému. Je pravděpodobné, že tahle fáze nebude u všech.

S SQL si rozumím dobře a na ty logy bych byl celkem zvědav (vlastní zatím nemám); na druhou stranu mě nenapadá, jak by znalost SQL mohla pomoci z těch logů vydolovat něco víc. Navíc jsem zrovna na štíru s časem - dokončuji dálkově VŠ, zítra mám poslední, zato dost nepříjmenou zkoušku a když ji nedám, tak za týden repete (na té zkoušce už někteří byli dvakrát a zatím to nedal nikdo - to se nám ještě nestalo).
Kdyby to zítra vyšlo, mohl bych na to o víkendu mrknout.
Jinak je na zvážení, zda/jaké citlivé informace v tom logu můžou být - osobně bych asi log svěřil jen někomu, koho znám dostatečně dobře osobně...

BTW - překvapuje mě, že někdo dokáže připravit takhle úspěšný útok a pak ho vede nenanonymně ze své IP; že by dnes nějaký talentovaný amatér udělal tak zásadní chybu se mi nezdá - na to jsou informace o nutnosti a způsobech anonymizace příliš rozšířené. Jedno vysvětlení by mě napadlo, ale nechci napovídat - předpokládám, že útočník tuhle diskusi čte a [zatím] se u toho dobře baví (zdravíme! :)

OB

taky děkuji za poslaní logů, moc pěkné a přikládám ukázku SQL příkazu z toho logu od Patrika, který je přidaný jako parametr stránky:
LIMIT 0 UNION SELECT CHAR(97),CONCAT(CHAR(97,50,48,71),IFNULL(HEX(CONCAT(IFNULL(`user`,CHAR(78,85,76,76)),CHAR(39),IFNULL(`password`,CHAR(78,85,76,76)),CHAR(39),IFNULL(`jmeno`,CHAR(78,85,76,76)),CHAR(39),IFNULL(`email`,CHAR(78,85,76,76)))),CHAR(52,69,53,53,52,67,52,67)),CHAR(97,50,48,71)),CHAR(99) FROM `rs_user`


Jen mě trochu překvapuje, jak je ten útok je dělaný - jako kdyby útočník vůbec neznal zdrojový kód a jen věděl, kde je díra, kterou se postupně "učí" jak jí zneužít.



Celkem upraveno 1×. Poslední úprava MirekS v 07.07.2011 10:43.

tak jo, taky si přisadím do hnízdečka...

"GET /galerie.php?akce=kategorie_ukaz&kat_id=66%20LIMIT%200%20UNION%20SELECT%20CHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29%2CCHAR%2868%2C109%2C98%2C81%2C78%2C55%2C100%2C116%2C81%2C81%29

server mu na to odpověděl HTTP/1.1" 404 28

no a ještě další kousek do pytle, zatím ho mašiny ignorují... :-)

"GET /admin HTTP/1.1" 403 207
"GET /D1Is1 HTTP/1.1" 404 28
"GET /admin HTTP/1.1" 403 207
"GET /D1Is1 HTTP/1.1" 404 28
"GET /admin.htm HTTP/1.1" 404 28
"GET /pVSIMKMNB HTTP/1.1" 404 28
"GET /admin.html HTTP/1.1" 200 1520
"GET /FVPTxdHjN7 HTTP/1.1" 404 28
"GET /admin.html HTTP/1.1" 200 1520
"GET /FVPTxdHjN7 HTTP/1.1" 404 28
"GET /admin.php HTTP/1.1" 200 119
"GET /9CZUnfBMY HTTP/1.1" 404 28
"GET /admin.php HTTP/1.1" 200 119
"GET /9CZUnfBMY HTTP/1.1" 404 28
"GET /administration HTTP/1.1" 404 28
"GET /TPrsDfmZog5hfH HTTP/1.1" 404 28
"GET /administration.htm HTTP/1.1" 404 28

jinak toho mám měsíc Z5, díky patrikovi jsem šel přímo po IP

takže galerií to rozhodně nebude :-) ale to už se tady prokázalo...

-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------



Celkem upraveno 1×. Poslední úprava JanVar v 07.07.2011 11:12.

mahoney.web napísal/a:
-------------------------------------------------------
> Pa3k: ten robotický sken/útok byl ze stejné IP
> jako vložení odkazu? Takové skeny jsou obecně dost
> běžné... S ohledem na datum by šlo zřejmě o
> přípravu útoku - tj. vyhledání jakéhokoli
> zranitelného systému. Je pravděpodobné, že tahle
> fáze nebude u všech.

Áno, IP pri vložení kódu bola rovnaká ako scan na SQL injection. Užívateľ je ale za NATom a vyzerá to, že pod tou IP je niekoľko ulíc a viacero firem.

> BTW - překvapuje mě, že někdo dokáže připravit
> takhle úspěšný útok a pak ho vede nenanonymně ze
> své IP; že by dnes nějaký talentovaný amatér
> udělal tak zásadní chybu se mi nezdá - na to jsou
> informace o nutnosti a způsobech anonymizace
> příliš rozšířené. Jedno vysvětlení by mě napadlo,
> ale nechci napovídat - předpokládám, že útočník
> tuhle diskusi čte a se u toho dobře baví
> (zdravíme! :)
> OB

Je celkom možné, že ten provider má niekde na tej IP verejnú WiFi...


Stále neviem ako mohli byť napadnuté weby bez galérie. V phpRS som síce našiel neiošetrený vstup v search.php, ale nedá sa cez neho nič vypísať na výstup.

Má niekto napadnutý web na samostatnej databáze bez pluginu gallery.php ???

Právě jsem poslal Patrikovi mail, jak lze chybu v search.php využít k tomu, co se stalo [díky za ukázku SQL injekce!].

Dokud nebude oprava, víc bych to veřejně nerozebíral - a ani nepublikoval ty "veselé" ukázky injekce. Ono je totiž potřeba si uvědomit, že to útočníkovi dává 100% kontrolu nad databází (ve smyslu změny databáze, nikoliv načtení dat), jako příklad uveďme jemnou nevinnou legrácku zablokování všech uživatelů (nebo naopak, povolení všech zablokovaných).

Jak už jsem zmiňoval, já se k tomu dostanu nejdřív o víkendu, takže je pravděpodobné, že opravu stihne napsat někdo dřív.
Zatím ahoj :)

>> Je celkom možné, že ten provider má niekde na tej IP verejnú WiFi...

Pořád je to omezená lokalita (velmi pravděpodobně je pachatel místní) a provider by měl mít logy (minimálně upřesní lokalitu na dosah konkrétního hotspotu) - pokud podáme trestní oznámení, je to pro policii docela dost indicií na to, aby mohla pachatele najít. Takže pořád mi to přijde jako zbytečná neopatrnost. Samozřejmě je možné, že tam útočník dojel ze severní Moravy, ale nechápu proč by to dělal, když anonymní proxy je pohodlnější a jistější...

mahoney.web napísal/a:
-------------------------------------------------------
> Právě jsem poslal Patrikovi mail, jak lze chybu v
> search.php využít k tomu, co se stalo .

Myslím, že zatiaľ je to planý poplach a tú chybu ešte nemáme. Ja stále podozrievam gallery.php nie kód phpRS.

pa3k napsal/a:
-------------------------------------------------------
> Myslím, že zatiaľ je to planý poplach a tú chybu ešte nemáme. Ja stále podozrievam gallery.php nie
> kód phpRS.

patriku, pár řádků máš nahoře, galerií u mne neprošel....
Pokud budeš chtít, dám ti plný přístup na můj server, ale pokud vím, tak času nemáš taky nazbyt... :-(

-- JaV ---- [http://www.hades.cz] ---- security by obscurity ---------------------------------------------
motto:
It's OK to be ignorant; it's not OK to play stupid.
But it's simply not efficient for us to try to help people who are not willing to help themselves.
----------------------------------------------------------------------------------------------------------------------

Ahoj,

taky jsem jeden z napadenych. Galerii u sebe nemam vubec (jedna se o asi 7 let starou verzi PHPRS), utocnik sel urcite jinudy nez galerii a sel pres chybu, ktera tam existuje uz spoustu let.
V podstate 90% skriptu jsem predelal a jsou "custom" a pridal slashovani na vsechy SQL prikazy v hlavni sekci i administraci v kodu PHPRS (a spoustu SQL prikazu jsem kvuli vykonu udelal uplne jinak - tim nechci rict, ze jsem tam nejakou chybu nezavlekl, spis jen to, ze kdyz na to fungoval stejny pristup, pravdepodobne se jednalo o nejakou "starou" cast kodu), Safe mode = ON.
Jedine, co jsem nikdy poradne neprosel byl soubor search.php a podezrivam tedy hlavne tento - uz to zaznelo i tu.
je pravda, ze jsem nemel administraci osetrenou pres .htaccess (to jsem napravil).
Hledal jsem v logu a zatim jsem nasel kulove, ale jeste na to kouknu vecer. Kazdopadne zatim jsem search.php vyhodil z adresare a projdu jeste zbytek kodu, jestli tam neco nenajdu. Mate nekdo nejaky hint, co hledat? GREPoval jsem casti vypisu, co jsou vyse, ale no luck.
Mozna ze uz se logy odrolovaly, ale stejne by bylo zajimave prijit na to, co prostrelil a jestli to opravdu byl search.php

kamaradovy stranky:
[http://www.majaka.cz]
fotogalerie tam neni, ale bozidar jo.
web jede na active24, mozna se dostaneme k logum

ICQ: 179653900
skype: marty_hranice
| www.hnfond.cz | | www.struhlovsko.cz | www.bxclub.com | www.r21club.com | www.palenice.net



Celkem upraveno 1×. Poslední úprava marty v 07.07.2011 14:39.

Zdravím,

dotyčný napadl i web Turnovskovakci.cz, udělal to pomocí skriptu search.php a pomocí proměnné rstema.

Log:
turnovskovakci.cz 188.244.56.2 - - [01/Jul/2011:23:59:59 +0200] "GET //search.php?rsvelikost=sab&rstext=all-phpRS-all&rstema=2%2B1000%2A%28%28SELECT+ASCII%28SUBSTRING%28CONCAT%28%60table_schema%60%2Cchar%2832%29%2C%60table_name%60%2Cchar%2832%29%2C%60column_name%60%29%2C4%2C1%29%29+FROM+%60information_schema%60.%60COLUMNS%60+WHERE+%60table_name%60+LIKE+CHAR%2837%2C117%2C115%2C101%2C114%29+LIMIT+1%2C1%29%3C64%29 HTTP/1.0" 200 43049 "-" "-"

Asi podle počtu výsledků rozeznával o jaké číslo jde a tak seskládal vše co potřeboval. Potom je v logu normální přihlášení a přístup do admina a následná úprava bloků. Ale nyní ještě zjišťuji zda to náhodou nebyl někdo z adminů.

Myslím, že nejde přímo po nějakém skriptu a využívá tak nějak díry po celém systému - jednou je to galerie potom vyhledávání.
Vyhledávání jsem upravil tak, aby PHP do proměnné rstema pustilo jen číselnou hodnotu (is_numeric()).

Docela zajímavé a tomu dotyčnému dávám palec nahoru ;-)


Adam Hrůza.

Paráda, dobrá práca. V search.php som našiel dieru, ale nevedel som ako dostať von heslo.

Oprava search.php doplniť riadok hneď na začiatok súboru, bude to potom vyzerať takto:

<?php
######################################################################
# phpRS Search 1.6.2
######################################################################

// Copyright (c) 2001-2005 by Jiri Lukas ([email]jirilukas@supersvet.cz[/email])
// [http://www.supersvet.cz/phprs/]
// This program is free software. - Toto je bezplatny a svobodny software.

// vyuzivane tabulky: rs_user, rs_topic, rs_clanky

/* mozne vstupni promenne:

  $rstext ... prenasi hledany text, povinny vstup, retezec: "all-phpRS-all" umozni kompletni vypis
  $rstema ... omezuje vypis pouze na zadanou rubriku/tema -> vstupem je cislo tematu, default hodnota = nic
  $rsautor ... omezuje vypis pouze na zvoleneho autora -> vstupem je cislo autora, default hodnota = nic
  $rsod + $rsdo ... umoznuje casove omezeni, $rsdo neni povinny, jelikoz search.php jej umi doplnit
  $rskde (titulek,uvod,text,t_slova) ... specifikuje, kde se dany $rstext vyhledava, default nastaveni ukazuje na "text"
               - platne hodnoty: tit, uvd, txt, tsl, vse
  $rskolik + $rskolikata ... umoznuje definovat rozsah vypisu: $rskolik (mnozstvi polozek) a $rskolikata prenasi informaci o pozici
  $rsvztah ... umoznuje definovat vztah mezi vetsim poctem zadanych slov k vyhledavani, default hodnota = OR
               - platne hodnoty: AND, OR
  $rsvelikost ... definuje zpusob vypisu: bud jednoradkovy vypis nebo vypis doplneni o uvodni texty u jednotlivych nalezenych polozek
               - platne hodnoty: jr, uvod
*/

/*
Header("Pragma: no-cache");
Header("Cache-Control: no-cache");
Header("Expires: ".GMDate("D, d M Y H:i:s",Date("U")+3600)." GMT");
*/

define('IN_CODE',true); // inic. ochranne konstanty

include_once("config.php");

if (isset($GLOBALS['rstema']) && $GLOBALS['rstema'] != 'nic') {
	$GLOBALS['rstema'] = (int)$GLOBALS['rstema'];
} 
include_once("specfce.php");
include_once("myweb.php");
include_once("sl.php");
include_once("trlayout.php");
include_once($adrlayoutu);

Celkem upraveno 3×. Poslední úprava pa3k v 08.07.2011 14:38.

Tak,

prolezl jsem log od Patrika a vzápětí mi přišel log z našeho webhostingu (za poslední měsíc), závěry:

* v Patrikově logu je jasný robotický pokus o nalezení díry v gallery.php a vytažení přístupových hesel (těžko říct, zda úspěšný),

* ve svém logu jsem našel velmi podobný pokus z 23.6. (v podstatě identický), ale směrovaný na search.php, IP je z nějaké pražské IT firmy (pošlu jim dotaz, proč jsou na můj web z jejich sítě vedeny útoky :),

* ani v Patrikově, ani ve svém logu jsem ale nenašel stopu po vlastním vložení odkazu => zřejmě nebylo SQL injekcí,

* ve svém logu jsem našel přihlášení do admin rozhraní 2.7. z té samé IP, ze které byl veden robotický útok dle Patrikova logu; přihlášení v 0:38 hod, rychlá návštěva editoru článků (u nás byl odkaz vložen do anotace článku), po 30 sekundách POST a odhlášení - celá akce zabrala o málo víc než minutu; kromě podezřelé rychlosti (naše redaktorky obvykle tráví v administraci víc času) jsem si i poměrně jist, že v ten den a v tu hodinu se ani jedna z nich nenacházela v jižních Čechách :)


Hypotéza (už tu jednou zazněla):

1. SQL injekcí byla vytažena hesla - zranitelnosti jsou zřejmě jak v gallery.php, tak v search.php (je možné, že na našem webu je starší verze vyhledávání a v novější už je chyba opravená - prozkoumám o víkendu),

2. Odkaz byl vložen ručně po standardním přihlášením přes administraci.

3. Google má jasnozřivého robota, neb ten prý bozidar našel na našich stránkách už 30.6. :)


Teď se jdu učit na zkoušku, zítra ořežu náš log o nepodstatnosti a pošlu ho Patrikovi.

OB

Ha - než jsem se rozepsal a dopsal, tak to jiní stihli dořešit :)

Má niekto chuť podať trestné oznámenie? Myslím, že nikomu nevznikla škoda, no ak má niekto na webe v db nejaké citlivé údaje, mohlo by to byť zaujímavé. Trestný čin resp. prečin to je aj tak, takže ak vieme IP, možno by malo význam po ňom ísť.

mahoney.web napísal/a:
-------------------------------------------------------

> 1. SQL injekcí byla vytažena hesla -
> zranitelnosti jsou zřejmě jak v gallery.php, tak v
> search.php (je možné, že na našem webu je starší
> verze vyhledávání a v novější už je chyba opravená
> - prozkoumám o víkendu),
>
> 2. Odkaz byl vložen ručně po standardním
> přihlášením přes administraci.
>
> 3. Google má jasnozřivého robota, neb ten prý
> bozidar našel na našich stránkách už 30.6. :)
>
>
> Teď se jdu učit na zkoušku, zítra ořežu náš log o
> nepodstatnosti a pošlu ho Patrikovi.


Každopádne som našiel aj veľa webov s dierou v gallery.php, kde je vytiahnutie hashu hesla oveľa jednoduchšie.
Je to tragédia. BTW, najhoršie na tom je, že táto chyba v search.php bola riešená v roku 2007 ale nebola vydaná oficiálna oprava...

[http://www.phprs.net/forum/read.php?32,30139,30227#msg-30227]

wertrik napsal/a:
-------------------------------------------------------
> Myslím, že nejde přímo po nějakém skriptu a
> využívá tak nějak díry po celém systému - jednou
> je to galerie potom vyhledávání.
>
> Docela zajímavé a tomu dotyčnému dávám palec
> nahoru ;-)

Palec nahoru jen v případě, že si toho robota napsal sám. Pokud ne, tak je to jen buran co si stáhl chytrou utilitku - a s ohledem na to, že se ani nesnaží maskovat svou IP, je tato varianta pravděpodobnější :(