Ten kdo si neosetril sve stranky postavene na phprs, stane se co nevidet obeti hackera
napr:

[http://5zlin.skauting.cz/]

[http://www.dimenze3.cz/]

[http://www.skmeteorkacerov.cz/fotbal/index.php], ty to presmeruje zrovna na: [http://3spi0n.net/ab.htm] ale stranky jedou, viz: [http://skmeteorkacerov.cz/fotbal/indexcl.php?akce=temata]

[http://krnovbazar.cz/]


uz jsem jim poslal mail s odkazy kde maji hledat chybu..


edit:
opravy najdete zde




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



Celkem upraveno 6×. Poslední úprava marty v 26.07.2011 22:21.

Nejlepší by bylo předělat hashování hesel na SHA2, které nelze prolomit - celý problém s napadením webů se objevil až teď, když je známý způsob, jak prolomit MD5 hash hesla během pár vteřin a tím získat heslo, kterým se lze přihlásit. Např. přidáním nového sloupečku do tabulky uživatelů, kde bude příznak, jestli se používá MD5 nebo SHA2, pokud příznak není nastaven, použije se k ověření MD5 a zároveň se vygeneruje SHA2 a uloží do hesla a nastaví se příznak a při příštím přihlášení se již použije SHA2 na ověření.

Od php 5.1.2 je funkce hash_algos() , která vrátí možné hashovací algoritmy a pak funkce hash() , která heslo vybraným algoritmem zahashuje

jinak doporučuji si přečíst [http://zdrojak.root.cz/clanky/nekolik-poznamek-k-heslum/]

Ahoj Mirku, chystam zmenu hashovania do 2.8.2 tak aby hash v md5 ulozeny v db prebehlo este viacnasobne sha1, to bude stacit. heslo teda ulozim tak ze spravim md5 a na nasledny hash este napr. 1000 x sha1() so vstupom ktory moze byt vysledok predch, operacii, pripadne sa ten string bude spajat. Vyhoda - nemusi sa menit heslo, zabezpeci to script.

majitel stranek www.motochina.cz , ktere byly rano napadeny mi ted poslal screen co objevil v novinkach:

[img]http://www.phprs.net/forum/file.php?2,file=298[/img]

Jen nevime zda je to ten samy hacker, bo jsme jej stihli s pa3kem odstrihnout spis nez udela vetsi skodu.

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 26.07.2011 17:42.

pa3k napsal/a:
-------------------------------------------------------
> Ahoj Mirku, chystam zmenu hashovania do 2.8.2 tak
> aby hash v md5 ulozeny v db prebehlo este
> viacnasobne sha1, to bude stacit. heslo teda
> ulozim tak ze spravim md5 a na nasledny hash este
> napr. 1000 x sha1() so vstupom ktory moze byt
> vysledok predch, operacii, pripadne sa ten string
> bude spajat. Vyhoda - nemusi sa menit heslo,
> zabezpeci to script.
>
> | PATRIK JÁN | FILMDAT.CZ | WAMOS.SK | KURZY
> PRVEJ POMOCI | KOHAPLANT.SK | PAPRADNO |
> TRIDENT.SK | MONITORUJI.CZ |

no mě by se asi víc líbila ta funkce SHA512 s nějakým pěkným saltem, pro každého uživatele jedinečně generovaným, než 1000x SHA1 s tím, že by se ty hesla měnily postupně, jak se uživatelé přihlašují (předpokládám, že admini se přihlašují často, takže jejich hesla by se změnila brzy) případně by se dal uživatelům rozeslat email, aby se rychle přihlásili a tím si hesla změnili, a možná než dělat zásah do phpRS na dvojí hashování, tak nechat v phpRS jen to silnější SHA512 a na změnu hashe použít samostatnou stránku jen k tomuto účelu, kam by uživatel byl odkázán třeba tím informačním emailem

A rozhodně by to chtělo napsat jako funkci, která bude šifrovat heslo a bude se volat v celém phpRS a využije tu funkci hash() , aby pokud někdo bude instalovat nový phpRS, tak si mohl klidně šiforvání změnit, třeba na to SHA512 a případně změní i počet opakování
Tím bude mít systém bezpečnější a pokud každá instalace phpRS bude používat jiné parametry, tak se tím stíží možnost hacknutí, neboť pro každý web se to bude muset dělat trochu jinak

Vždy je lepší použít vícenásobné hashování, které je podporované i na starších verzí PHP, což může být u tak starého a dlouho neaktualizovaného systému jako phpRS dosti důležité, než používání funkcí závislých na nových (relativně) verzí PHP či knihovnách, které nemusí být ve standardní konfiguraci a především jejich jednoduché/jedno použití. Vícenásobné hashování je dostatečnou ochranou. Např. použití kombinace md5 a sha1 je dostatečné i v menším cyklu než 10 ... pro paranoiky či nedůvěřivce klidně vícero, nikomu to neublíží, server to zatíží min. :) jediné použití je při vytváření účtu a při kontrole přihlášení - vůči tomu je lepší hledat kompromis mezi velmi dlouhým cyklem a dostatečným bezpečím - tedy např. pro čtenáře, kterých může být tisíce a přihl. pokusů taktéž ...

Hlavní výhoda vícenásobného hashování je především v neexistenci rainbow tables - samozřejmě je otázka, jak rychle si je k systému s otevřeným kódem někdo udělá a zveřejní - je to práce na pár minut ... takže u systému s otevřeným kódem bych se nesnažil o super vymyšlení vícenásobného hashování či použití složitějšího hashování, ale především bych se zaměřil na max. zabezpečení jako takové ... vždy dám ale obecně přednost vícenásobnému hashování než jednoduchému i třeba se složitější hashovací funkcí ...

========================
WEB: Publikační systém WAMOS
SEO: SEO analýza zdarma
OPEN PROJECTS: Studentský portál VUT
HOSTING: WebGlobe.cz
ICQ: 313887644
EMAIL: xsuchy09(at)centrum.cz
========================

function vypocitaj_odtlacok_hesla($heslo = "") {
	$hash = md5($heslo);
	for ($i=0; $i < 10000; $i++) {
	    $hash = hash("sha512", ($hash.$i), FALSE);
	}
	return $hash;
}

// VS.

function vypocitaj_odtlacok_hesla($heslo = "") {
	$hash = md5($heslo);
	for ($i=0; $i < 10000; $i++) {
	    $hash = sha1($hash.$i);
	}
	return $hash;
}

Osobne som pre variant, ktory bude bezat aj v php4 / a php5.1. Na tak starom systeme ako je phpRS je vyzadovanie novych kniznic resp. verzii php potencionalny problem. Konluztoval som to s xsuchy09 a je tiez skor za sha1(). Myslim, ze narocnost prelomenia oboch variant je o dve triedy ine ako samotne md5 v sucasnom phpRS. Treba samozrejme ratat aj s tym, ze bude pouzita zakladna kontrola zlozitosti hesla + padne sucasne nezmyselne obmedzenie dlzky hesla na max. 10 znakov.



Celkem upraveno 5×. Poslední úprava pa3k v 26.07.2011 21:40.

Este by som dodal, ze viacnasobne hashovanie ma vyznam, pretoze vytvorenie rainbow tables bude trvat niekolkonasobne dlhsie. Samozrejme predpoklad je, ze utocnik vytiahne z db hash a pozna algoritmus. Hladanie hesla brute force je preto omnoho narocnejsie. Samozrejme je tu predpoklad, ze utocnik pravi rainbow tables najprv zo slovnika a skusi najst heslo. Tu by pomohol jedine salt ale nie ulozeny v databaze, pretoze by bolo pre utocnika lahke sa k nemu dostat (rvnako ako sa dostal k odtlackom).

Ak budeme ukladat SALT do config.php bude to zas problem pre menej skusenych userov. Tiez tu vzniknu rozne problemy so znefunkcnenim hesiel ak si niekto ten SALT zedituje na zivom systeme...

Je to dilema, medzi jednoduchostou pouzitia a dobrym zabezpecenim. Osobne by som SALT urcite neukladal do DB, uvazujem, ci ho vynechat uplne a spolahnut sa na to, ze user nezvoli heslo zo slovnika.

Také je možné v configu nastavit ten počet opakovaného zahashování (např jako číslo mezi 10 a 1000) potom bude mít takřka každý phpRs web jiné hashování, což nějakou možnost rainbow tables zcela vyloučí. Ale jednak tu je výše uvedený problém s náhodnou editací na "živém systému" a za druhé bychom měli pak nezapomenout vytvořit nějakou náhražku známé rady "když jsi zapoměl heslo pro admina, dej v phpMyAdminu / Admineru 955db0b81ef1989b4a4dfeae8061a9a6. Protože to se tu a) budou lidé ptát, když to nějak zapomenou a za b) se to bude muset při nové instalaci nějak v systému u defaultního admina nastavit.

Hepbegclub | Čáslavsko | MN Čáslav

Kryšpín napísal/a:
-------------------------------------------------------
> bychom měli pak nezapomenout vytvořit
> nějakou náhražku známé rady "když jsi zapoměl
> heslo pro admina, dej v phpMyAdminu / Admineru
> 955db0b81ef1989b4a4dfeae8061a9a6. Protože to se tu
> a) budou lidé ptát, když to nějak zapomenou a za
> b) se to bude muset při nové instalaci nějak v
> systému u defaultního admina nastavit.

O toto by som nemal strach, kľudne online generátor, je to párriadkový script.

> [http://zdrojak.root.cz/clanky/nekoli] k-poznamek-k-heslum/

Dobrý článok. ALE :-)

Variabilný salt uložený v db, je pri verejnom algoritme a dumpnutej db riešením, ale nerieši slovníkový útok na jeden konkrétny účet. Tomu by práve pomohla tá soľ uložené mimo db. Prichádza mi čím ďalej viac vhodné to definovanie konštanty SALT v config.php s vyyyyraznym komentarom: "ak toto prepises, zmenia sa vsetky hesla", nebo tak neco.



Celkem upraveno 4×. Poslední úprava pa3k v 27.07.2011 10:32.

pa3k napsal/a:
-------------------------------------------------------
Tu by pomohol
> jedine salt ale nie ulozeny v databaze, pretoze by
> bolo pre utocnika lahke sa k nemu dostat (rvnako
> ako sa dostal k odtlackom).
>
> Ak budeme ukladat SALT do config.php bude to zas
> problem pre menej skusenych userov.

to neni vubec pravda - pokud bude salt v db pro kazdeho uzivatele jedinecny, tak by utocnik musel delat rainbow tabulky pro kazdeho uzivatele, pokud bude spolecny v configu, tak mu staci jedna rainbow tabulka pro vsechny uzivatele, nicmene v configu muze byt jeste druha cast, ktera by tu bezpecnost zvysila, tim ze se neda z db vycist a snadno by si ji kazdy mohl pro sve phpRS menit, aby se zase stizil hromadny\ utok na vsechny phpRS systemy

MirekS napísal/a:

> to neni vubec pravda - pokud bude salt v db pro
> kazdeho uzivatele jedinecny, tak by utocnik musel
> delat rainbow tabulky pro kazdeho uzivatele, pokud
> bude spolecny v configu, tak mu staci jedna
> rainbow tabulka pro vsechny uzivatele, nicmene v
> configu muze byt jeste druha cast, ktera by tu
> bezpecnost zvysila, tim ze se neda z db vycist a
> snadno by si ji kazdy mohl pro sve phpRS menit,
> aby se zase stizil hromadny\ utok na vsechny phpRS
> systemy

Jasné, hromadný útok to sťaží. Ale majme útok na konkrétny web s phpRS. Ide mu o prelomenie typicky jedného alebo niekoľko málo hesiel a použije slovníkový útok + variácie napr. 2 znakov. Ak nevyjde slovníkový útok na prvé admin konto, ide ďalej. Počet admin účtov len zvyšuje pravdepodobnosť, že niekto z adminom má heslo
slabé.

Cez blind SQL injectin vytiahne útočník z db hashe, salty a keďže phpRS je opensource, bude poznať aj algoritmus tvorby hashu. Aký je rozdiel v tom, či je SALT použitý alebo nie keď si ho útočník aj tak vytiahne z db? V taktomto pípade žiadny, resp. bude viesť slovníkový útok s variáciami na každý účet zvlášť, čo mu v prípade variabilného saltu spraví na celkovom čase len znásobenie potrebného času (čas na kontrolu slovníka + variácie krát počet účtov). Zato s hashom v configu stúpa náročnosť exponenciálne aj keď môže útočiť slovníkom naraz na všetky heslá.

Variabilný hash (ku každému účtu iný) je ochrana pred hromadným lámaním veľkej množiny hesiel cez predpripravené rainbow tabuľky. Vylúči možnosť generovania univerzálnych rainbow tabuliek, to je jasné. Síce to vylúči riziko hromadného napadnutia phpRS webov, ale v tomto prípade, keď ide útok na konkrétny web, mi to moc nepomôže, ale zato mi veľmi pomôže SALT v config.php, pretože k tomuto údaju bude veľmi ťažké sa dostať (aj keď by som za určitých podmienok vedel ako). Hromadné napadnutie phpRS webov rovnako spoľahlivo alebo ešte lepšie vylúči aj SALT v configu.

Ak bude rozumne dlhý SALT v config.php a nejaký admin použije heslo zo slovníka, hacker má šance veľmi malé aj keď pozná hash aj algoritmus. Tým, že salt nepozná a je v prdeli. Pri inštalácii by ten salt string mohol generovať nejaký generátor aby zabezpečil jeho zložitosť.

Myslím, že tieto debaty sú síce prínosné, ale viacmenej filozofické. Podstatné je zmeniť algoritmus z md5 na čokoľvek komplikovanejšie a hlavne zaplátať diery v search a pluginoch.

Z napadnutých webov to vyzerá, že na tieto zraniteľnosti niekto vyrobil nástroj a polodementné script kiddies z Turecka sa pretekajú, kto "hackne" viac webov pomocou hotového nástroja.



Celkem upraveno 1×. Poslední úprava pa3k v 27.07.2011 11:39.

Nasel jsem neco tady :
[http://www.security-portal.cz/clanky/phprs-281a-xsrf-poc-exploit]

Zkusil jsem to na svym opatchovanym zkusebnim, v logu apache mam pak :
[Sat Jul 30 10:26:04 2011] [error] [client 77.48.11.22] ALERT - configured GET variable value length limit exceeded - dropped variable 'modul' (attacker '77.48.11.22', file '/srv/www/vhosts/phprs/readers.php')

Tak snad je to spravne :D

Nebo nemate nekde nastroj ci zpusob jak si to muzu overit ? at mam jistotu..

Diky
J.K.

Search si testneš ľahko,

/search.php?rstema=xxx&rstext=a
vs
/search.php?rstema=nic&rstext=a

by malo dat rovnaky vysledok (vsetky clanky obsahujuce "a")
ak v prvom variante vyhodi chybu alebo prazdny vysledok (aj ked druhy variant nieco vypise), je to derave.


PS: WAW, To je nejaky Apache modul? A ja sa s tym seriem vlasnym blacklistom, generovanym z IP, ktore pouziju potencionalne nebezpecny reguest :-D

Inak ten odkazovaný XSS POC je na readers. Testneš jednoducho tak, že vložíš HTML napr. "><h1>XSS</h1>do mena citatela a skusis v admine zobrazit zoznam citatelov. HTML musi byt osetrene a nesmie sa "vykonat/zobrazit".



Celkem upraveno 1×. Poslední úprava pa3k v 30.07.2011 14:23.

Heh, to kdybych vedel, co me to pomaha za modul, myslel jsem ze je to antiloris, to bylo posledni co jsem asi tak stoural, do nastaveni, ale nejak si tim nejsem jistej. Jeste zapatram a dam vedet, jo ? :)

No, pokud se nemylim, tak i podle hlasek co jsem nasel na netu je to php modul "suhosin" - [http://www.hardened-php.net/suhosin/] . Mam ho taky nainstalovanej. Nicmene nekde jsem videl, ze to muze zpusobit problemy (ale to vsechno zabezpeceni, ze ? :) )
Modul suhosinu pro php5 mam z distribuce opensusecka, asi jsem videl v popisu ze je to pro zvyseni bezpecnosti, tak jsem ho nainstaloval. Zatim nevim o zadnych problemech ze by me to delalo ... Ma s tim nekdo nejaky zkusenosti, jakykoliv ?
J.K.

Jasne, suhoshin na hostingu mam, nevedel som ze riesi aj toto. Nepostrebol som ziadne problemy.