Objevena první zranitelnost v Nette, aktualizujte!

Ja som v poslednej dobe sledoval celkom podivné logy
samozrejme veľa bolo takých ako by sa skúšal niekto dostať do Wordpresu a teda samé wp-admin
ale potom bolo pomerne dosť URL s podivnými [zatvorkovými] parametrami

potom sa mi aj na FTP začali objavovať divné index.php súbori a potom nejaké s úplne divným názvom a obsahom
a po konzultácii s hostingom sme zistili že bol to útok
taktiež som to vyhľadal cez access.log konkrétnu IP a dané POST requesty a celé FTP som premazal

čo bolo horšie na tom jednom hostingu som mal 12 projektov a bolo to vo všetkých ale v Nette som mal len ten jeden hlavný ostatné boli Wordpress a OpenCart …a teda neviem odkiaľ tie súbory vznikli či práve cez Nette alebo skôr dieru v inom projekte

#1 sucho, tyhle logy, co popisuješ, jsou zcela běžné už drahně let, jde o automatizované útoky na Wordpress a další populární projekty. (Nemusí vůbec na webu běžet.)

Když je v katalogu CVE vyhledáš, zjistíš, že těch bezpečnostních chyb mají opravdu hodně a je nutné je všechny pravidelně aktualizovat.

Další věc je, že se běžně kradou FTP přístupy, ať už „po cestě“, pokud nepoužíváš šifrované spojení, nebo se vykrádají různé Total Commandery a podobně, kde jsou spojení uložená včetně hesel. Darebáci se pak připojují přímo na FTP a modifikují soubory nebo nahrávají nějaké další, obvykle právě index.php.

Budou prosím aktualizované verze k dispozici ke stažení jako zip v archivu starších verzí ?

#3 Lukáši, doplnil jsem je

#4 Davide Grudle, Děkuji

Dá se předpokládat, že tento exploit funguje to i na pre-release 2.0?
Používám tuto úžasnou verzi Nette:
version 2.0-dev released on 2011–10–12

Davide to s tím isImage jsem reportoval já a absolutně s tebou nesouhlasím. Pokud metoda isImage kontroluje pouze hlavičku co příjde od klienta je to špatně, porgramátor volá v kodu pak isImage a spoléha na fakt ze nette isImage osetri správně a ehle nem ono tam může být PHP kod jen klient NETTE řekl je to JPG/PNG/GIF a pak to projde touto validací, tedy vlastně je to metoda k ničemu. Kdybys mi odpověděl tenkrát na email mohli jsme o tom vést diskuzi, tak jí můžem vést tady i s ostatnimi navíc Michal Špaček na některých přednáškách říká ze ošetrovat na zakladě hlaviček je chybně, když se dají podvrhnout. Mimochodem díky této chybě jsem hacknul nespočet webů postavený na nette.

#7 Marku, Když už jsem i v komentářích… 🙂 Pokud metoda isImage kontroluje pouze hlavičku co příjde od klienta: FileUpload::isImage() se kouká na typ souboru, do samotného souboru, ne do HTTP hlaviček. A dělá to tak aspoň 10 let, to je udělané správně. Browser musí poslat soubor s GIF hlavičkou, aby Nette mohlo říct, že to je GIF, co o souboru tvrdí klient je nepodstatné.

Byl záměr, že v Nette 3 je to ošetřeno vyhozením Nette\InvalidStateException a ve starších verzích Application\BadRequestException? Proč?

Bylo by prosím možné zveřejnit nějaký closed-source nástroj, kde člověk zadá URL adresu a nástroj zkontroluje, zda je projekt zranitelný? Máme mnoho starých nette projektů, kde se např. používá jen malá část frameworku (staženého, ne přes composer, v2.0) a bylo by nákladné to opravovat. Hlavně bych chtěl zjistit, zda je to vůbec napadnutelné.

#10 Víte Sikoro, Access log mám zaprasenej requestama z https://www.salamek.cz/nette-test.php

#6 Vláďo, Ano, dá se více než úspěšně předpokládat, že „version 2.0-dev released on 2011–10–12“ je také zranitelná.

#6 Vláďo, nemám archiv těchto verzí, ale můžeš ji fixnout tak, že smažeš soubor MicroPresenter.php, pokud tam je. Ale bál bych se, že v deset let staré nestable verzi budou onačejší problémy.

#7 Marku, můžeš mi napsat do emailu postup jak tímto způsobem hackuješ web na nette?

#9 Andreji, v další verzi nette/application to bude zpátky BadRequestException

#10 Víte Sikoro, v takové situaci, kdy nepoužíváš composer, můžeš použít automatizovaný nástroj napsaný v php nebo shellu

Aktualizujte, útoky na tenhle exploit už běžej od blackhatů. Nahráli nám na server nějaké části wordpressu ale asi se jim nepodařilo útok zprovoznit, index ale házel 500 na chybějících součástech.
#stary-odkaz-#stary-odkaz-https://www.abuseipdb.com/check/188.165.211.206

#12 Michale Špačku, To je tool na kontrolu zda li je web děravý, nějaký white hat jej volá z Python crawleru a parsuje mailto z vulnerable webu kam posila emaily s infem o nutnosti aktualizace… více info na https://www.abclinuxu.cz/…testing-tool
#10 Vít Sikora Viz ^

#15 Salamku, Zatracený off-by-one chyby, to asi měla být reakce na #11 Andrej 🙂

Tato zranitelnost může způsobit kompromitaci vaší databáze aniž by jste si toho vůbec museli všimnout. I když vám web funguje normálně mohl si útočník odnést kompletní databázi, privátní klíče a jiná data uložená mimo veřejně dostupný adresář aplikace. Po aktualizaci si zkontrolujte access log.

Pokud hostingy problematickou URL přímo blogují, tak se mohla zveřejnit i zde. Spíše by ji měly blokovat.

#13 Davide Grudle, Já když zpětně po sobě četl co jsem ti psal, tak to nebylo dobře napsané. Popis a i uvažování proč si to myslím jsem ti hodil na email. Samozřejmě pokud stále vyhodnotíš, že za to nemůže samotné nette, ale bud PHP finfo_file či programátor co to chybně používá, tak by to v tom případě v nette být nemělo ať si validaci na image dělá programátor sám, ale když jí tam máš, měla by skutečně zvalidovat IMAGE nikoliv, že přes tu validaci projde i PHP které půjde pustit, pak je chybně napsaná právě ta validace. Vše máš v emailu.

Tak jsem alespoň zjistil, že mi na webu chyběla složka nette.

#19 Marku, shrnu ten email pro zdejší čtenáře: poukazuješ na problém způsobený tím, že programátor uloží do veřejného adresáře uploadovaný soubor pod názvem podstrčeným útočníkem. Např. obrázek uloží pod názvem image.php a pak jej lze pochopitelně spustit na serveru.

To samozřejmě je fatální chyba. Ale programátora, nikoliv validátoru obrázku.

• Jednak to se netýká jen obrázků, ukládat pod podstrčeným názvem nelze ani nic jiného.
• Zároveň není možné zahazovat obrázky, které v sobě „obsahují PHP“. Rychlým testem jsem zjistil, že pětina mých fotek obsahuje náhodně bajty shodné s otevírací značkou PHP <?=. A jde o zcela platné obrázky.

Co by se dalo udělat z pohledu Nette? V docce i phpDoc je řečeno, že názvu od klienta se nesmí důvěřovat. Asi by byl dobrý nápad přejmenovat metodu getName() na getUntrustedName() apod. Ale validátor obrázků je imho uplně ok.

#20 antijoudo,
ou, tak už mi na web nahráli nějaký servershell.php, 16.10.