szervert feltortek, avagy PHP mail() es SPAM

Flame

Sziasztok!

Rovid tortenet:
Eszrevettem, hoyg a szerveren a kimeno levelek queujeben tobb szaz level gyult fel mindegyik spam es a www-data user kuldte. Par oras nyomozo munka utan rajottem, hogy nem tortek fel a gepet, csak egyik php-s weboldalon keresztul kuldenek spamet.

A PHP mail() fuggvenye annyit csinal, hogy fogja a bejovo negy parameteret, beteszi egy template-be, es szepen benyomja a sendmail/postfix/etc stdin-jebe.
Tehat hogyha valaki a template-en belul kuld meg egy template-et, akkor kuldhet egy masik levelet is arra a feladora amire o gondolja. Bersze tobb ezer bcc mezovel. (a-z ig szinte az osszes .aol.com -os cimre ...)

Eddig volt az eset tanulmany. Es most jon a flame resze (sajat gondolatok).

Ki itt a hibas?

* A spamet kuldo (ez termeszetes)
* Rajottem, hogy a spamet kulonbozo IP-krol kuldik (del-korea, kina, usa, csak par ip: 68.8.94.249, 219.232.9.180, 211.223.58.182). Tehat itt bothaloval allunk szemben, ami:
* windows felhasznalok, akik szabaidejukben virust gyujtenek, es igy lesznek botnet tagjai
* botnet halot megiro programozo

* php fejlesztok, akik a szanalmas mail() implementaciojukkal php 3 ota szejjel spammeltetik a vilaghalot
* a program iroja, aki nem ellenorizte a bemeneti parametereket (es mondjuk limitalta volna a hosszat)

Szerintem itt a legjobban a PHP fejlesztok a hibasak. Mivel a mail() fuggveny igy lett meghivva:
mail("ideirj@szerver.hu", "Hibabjelentes", $message, "From \"$_POST[nick] ehhe@hu.hu\"")

En mint programozo joggal elvarhatnam, hogy barmi a bemenet (akar binaris fajl is) azt megkapjam egy-az-egyben levelben.

Szerintem meg kene jol buntetni (leultetni par evre) azt a PHP fejlesztot aki ilyen szanalmas mail() implementacioval spammelteti vegig a nagyvilagot.

Ez senkinek se tunik fel, hogy a vilaghalo spamforgalmanak jo resze (imho tobb mint a fele) a bugos fos php-n keresztul folyik?

Velemenyek?

Khiraly

  • 1988 megtekintés

( onyx v | 2006. 02. 06., h – 03:12 )

Nalunk is megesett, egy juzer altal irt 10 soros, sajat maganak mail kuldo php-n keresztul kuldtek el tobb ezer levelet. Elmeny volt kinyomozni, hogy mi a halal tortent.

( mocsi | 2006. 02. 06., h – 06:29 )

Háát a PHP-nál (de máshol is) az első alpelv az, hogy a user-től bejövő paraméterekben soha ne bízzál...

alap felfogas szerint egyeterthetunk abban, hogy minden nekem szant adatfolyamot meg akarok kapni. Akar virusos csatolmanyt is.

Szoval itt egyertelmu a php mail() fuggvenyenek a gagyisaga. Persze mostmar ellenorzom a bejovo adatokat korlatozom a hosszat (igy legalabb tobb oldalas siro levelet se kapunk meg), de ezt en kifejezetten ganyolasnak tartom.

Khiraly

Ha egyszer egy függvénynek az a dolga, hogy négy paramétert átadjon a mailernek, akkor miért baj az, hogy ezt meg is teszi?
Php (meg bármi más) programot úgy kell írni, hogy a bejövő adatokat ellenőrizni, nem oda való dolgokat kiszűrni az egyedi igényeknek megfelelően, készíthetsz rá függvényt, objektumot, akármit, és azt tessék használni.

lehet nem ertetted meg a konkret problemat.

A mail() fuggvenynek az alabbi 4 parametere van:
cimzett, uzenet, felado, targy

Ebbol minden fix (ertsd sima sztring) es *CSAK* az uzenetbe kerulhet sztring.

Ennel a felallasnal igenis a php-ban van a bug, hogyha ugyesen formazott sima .txt-t bevagva tobb szaz levelet kuld el.

Khiraly

( csko | 2006. 02. 06., h – 09:36 )

mail.c:

Author: Rasmus Lerdorf
/* $Id: mail.c,v 1.82.2.3 2005/07/28 08:48:31 hyanantha Exp $ */

Nem akarlak megbántani, de ha php-t raksz a szerverre akkor jó, ha tudod, mi mit csinál, és milyen korlátozásokat kell bevezetni.

Viszont egyetértek abban, hogy az alap PHP beállítások nagyon veszélyesek és ezen illene már változtatni. Első lépésként automatikusan ki lett kapcsolva a register_globals egy pár éve, ami szerintem jó döntés volt.

(forrást lehet szerkeszteni, ini fileban is lehet tiltani a függvényt, sőt bemeneti adatokat is lehet ellenőrizni)

( eax | 2006. 02. 06., h – 09:44 )

En inkabb azon valtoztatnek, h. nem kellene a vilag osszes degeneraltjat gep ele ultetni. Valami olyasmi kellene, mint a jogositvany (addig nem ulhetsz PC-hez, amig meg nem tanulod, hogy exe-s attachmentre buta dolog duplan kattintani).

( andrej_ v | 2006. 02. 06., h – 13:17 )

Hát.

Első körben annak kéne felháborodnia, aki nem ismeri azt, amivel dolgozik. Második körben pedig elgondolkodnia, hogy a címzettet/feladót, hogy állítja be és mit fogad el a külvilágtól.

Aztán pedig miért használja az illető a mail()-t? Van pl. megfelelő SMTP class, ami a megfelelő dolgokat megcsinálja és kissé flexibilisebb, valamint kevésbé gázos.

Aki megbízik bármilyen külső adatban az is hibás valamennyire, persze nem lehet validálni mindent minden ellen, mert akkor érdekesen semmit sem lehetne mailben küldeni.

ROTFL

Mert nem gondolt rá, hogy az üzenetbe helyezhető olyan tartalom, amely által más címre is küldhető email.

Teljesen igaza van, a php mail() függvényében van a hiba.
Persze céltudatos előre tervezéssel ellehet az ilyesmit is kerülni. Pl. az smtp a www/php-tól érkezett leveleket csak a belső hálózat fele továbbíthatja, stb. Az összes eshetőségre azonban nehéz felkészülni...

Dehát a haxoroknak meg a spammereknek is meg kell élni valamiből ;D

Pontosan.

A leszornyubb, hogy erre egesz iparag alakult ki ahogy nezem. Ugyes google keresessel leeht talalni egy valag oldalt amin keresztul lehet ilyen technikaval mailt kuldeni.

Egesz botnet halot uzemeltetnek (nalam mar tobb 100 ilyen level gyult fel (azota logolom levelet, ip-t)), mindegyik mas ip cimmel, szoval eleg valoszinu, hogy botnettel allunk szemben.

Mindenesetre nagyon jol van kitalalva, mivel a konkret felado ketszeresen is rejtve van (egyreszt mi kuldjuk a spamet, hozzank pedig vindozos gep kuldi).

Azt se tartom kizartnak, hogy fizetnek hogy ne javitsak ki ezt a hibat;)