[server defacement] Whackerz Pakistan

[0528973]

Goededag allemaal,

Sinds gisteravond heeft 1 van onze webservers een groot probleem.
Hij heeft namelijk last gehad van een defacement door een groep die zich
Wackerz Pakistan lijkt te noemen.

Zie het voorbeeld van de defacement hieronder:
http://www.zone-h.org/en/defacements/mirror/id=2415754/

Op deze server draait debian(testing) en Nessus lijkt geen vulnerabilities te vinden in de services die draaien.

Het lijkt erop, dat onze server gehacked is geweest en er dmv het root-account verschillende index.php/.html/ed pagina's zijn overschreven. De rechten, groep en eigenaar informatie per overschreven bestand zijn hierbij correct gebleven. De defacement heeft gisteren(05-06-2005) tussen 17:00 & 19:00 plaatsgevonden.

Op dit moment zijn we onze firewall-rules aan het aanscherpen, echter zou ik graag van jullie willen weten of jullie een idee hebben op welke manier ze dit voor elkaar gekregen hebben. Zouden ze dit via een tot nu toe onbekende exploit gedaan hebben, of op een andere manier. Tot nu toe, heb ik tot op 28 april referenties gevonden van gedefacede sites door deze groep.

Wat algemene server informatie dat jullie misschien kan helpen.

code:

Server version: Apache/2.0.54
Server built:   May 12 2005 05:30:44
PHP Version 4.3.10-15
Mysql: 4.0.24
Exim(port 25) 4.50

PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   open     smtp
80/tcp   open     http
110/tcp  open     pop3
143/tcp  open     imap
873/tcp  open     rsync
1241/tcp open     nessus
3306/tcp open     mysql

111/tcp  filtered rpcbind
135/tcp  filtered msrpc
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
161/tcp  filtered snmp
445/tcp  filtered microsoft-ds
593/tcp  filtered http-rpc-epmap

[ Voor 3% gewijzigd door 0528973 op 06-06-2005 12:14 ]

[Wirehead]

ssh > permitrootlogin op NO gezet? SSH protocol V2 geforceerd?

verder: moet je mysql naar buitenaf openstaan? alle php-progsels gebruiken waarschijnlijk dan toch "localhost" als server, en dus moet deze niet openstaan naar buitenaf.

edit: als het kan, post ook de relevante firewall logs, met IP's eruit gefilterd natuurlijk

[ Voor 21% gewijzigd door Wirehead op 06-06-2005 13:38 ]

[sh4d0wman]

Probeer eens te kijken bij de andere linux servers die op dezelfde dag gedefaced zijn welke services / linux versie / (php scripts) men gebruikt. Op de site die je aangeeft staat er een hele massa op dezelfde dag, ergens moet er iets overeenkomen....

[MrBarBarian]

Alleen locale php/mysql connecties toestaan (gaan toch allemaal via de webserver).. Geen standaard mysql-accounts, en het liefst alleen een account met select-permissies..

En controleer ook je (php) code, samen met webroot authorisaties..

[0528973]

Bedankt voor de tips, al had ik gehoopt op wat meer reacties tav de specifieke defacement. De meeste standaard zaken zijn goed geregeld en omdat ik hier geen bekende vulnerabilities kan vinden, vraag ik me af hoe er ingebroken kan zijn.

Ondertussen heb is er iets gevonden wat lijkt op een hack-poging via een SESSION en de inhoud van de session...

[Wirehead]

Tja, zonder logs kunnen wij ook niet veel zien hoe de attack verlopen is..
Waarschijnlijk gewoon een exploit door brakke php-code / ssh, aangezien je het over sessions had.

edit: misschien nog handig om te weten: Firewall-Jay is een excellente firewall voor Debian. Configuratie is makkelijk en filterd ook nog eens malformed packets eruit. Je kan hem installeren door "deb http://firewall-jay.sourceforge.net/debian/ ./" in je sources.list toe te voegen.

[ Voor 46% gewijzigd door Wirehead op 06-06-2005 14:19 ]

[Bor]

Je draait aardig wat services met netwerk access die wellicht niet nodig zijn. Draai je bv de nessus client lokaal? Is mysql access over het netwerk nodig? Heb je wel een goede config voor de FTP server?

[ Voor 14% gewijzigd door Bor op 06-06-2005 14:16 ]

[0528973]

De desbetreffende services die network acces nodig hebben zijn daarop ingesteld. De rest draait localhost. Nu ik weer wat info rijker ben, kan ik zeggen dat het niet zozeer door een SESSION is gebeurt.

uselib24 is gebruikt om root te worden, en er zijn wat aanwijzingen die erop duiden dat het desbetreffende bestand er via apache icm perl of php op het systeem is gekomen.

Jullie kennen de groep die deze defacement lijkt uit te voeren niet? Ik kan weinig info over hun vinden, wel een boel sites die last lijken te hebben van dezelfde defacement.

[ Voor 20% gewijzigd door 0528973 op 06-06-2005 14:31 ]

[Bor]

0528973 schreef op maandag 06 juni 2005 @ 14:30:
De desbetreffende services die network acces nodig hebben zijn daarop ingesteld.

Wellicht overbodig maar blijkt dat ook uit de portscan? Draai je bv nessus als netwerkserver? Gebruik je mysql alleen ism de webserver op dezelfde host?

[Wirehead]

De gehackte site behouden? Daar kun je misschien nog flarden van de gebruikte code voor de exploit uithalen. Waarschijnlijk gebeurd door code-injection ergens (correct me if i'm wrong )

[0528973]

Dat blijkt ook uit Nessus ja... De sites zijn behouden middels een backup. Het zou heel goed een code eploit kunnen zijn. Al zijn de meeste sites, op enkele oude sites niet door mij gemaakt, injection proof. Uitgebreid getest tijdens development. Maar ja, je kan nooit zeker weten.

[arnoman]

Evil_Homer schreef op maandag 06 juni 2005 @ 14:32:
De gehackte site behouden? Daar kun je misschien nog flarden van de gebruikte code voor de exploit uithalen. Waarschijnlijk gebeurd door code-injection ergens (correct me if i'm wrong )

Over het algemeen laten alleen de beginnende crackers rotzooi achter. De mensen die ik ken in de scene controleren over het algemeen meerdere malen of ze niet perongeluk iets hebben achtergelaten wat naar hun toe herleid kan worden, of de door hun gebruikte exploit kan verraden.

Ik zou het als volgt aanpakken, bewaar een kopie van de desbetreffende gehackte webserver. Zet vervolgens een backup terug op die webserver. Ga in de tussentijd de backup doorpluizen van de gehackte webserver. En monitor de webserver (waarvan de backup is terug gezet) zeer nauwlettend.
Uit ervaring kan ik zeggen dat de meeste defacers meestal dom genoeg zijn om binnen korte tijd een site op dezelfde manier weer terug te pakken. Wellicht kan je op die manier wat wijzer worden van hoe ze binnen gekomen zijn.

Op zoek gaan naar de gebruikte exploit is hoogstwaarschijnlijk verloren tijd, er zijn de laatste paar maanden zo gruwelijk veel gaten ontdekt in de verschillende OS'n/Progsels dat dit ondoenelijk is.

Succes!

[0528973]

Dank je Arnoman, ondertussen hebben we genoeg aanwijzigingen om zeker te zijn van het feit dat het via php is gebeurd. Erg vervelend, voornamelijk omdat de meeste sites netjes in safe_mode met hun beperkingen via de open_basedir draaien. Echter sommige nog niet.

Deze aanpak wordt op dit moment idd ook gebruikt. Mocht ik meer te weten komen dan horen jullie het.

[MrBarBarian]

Via een php-exploit of via een slordigheid in de eigen code?

[frickY]

Als je via een webform een executable op je server hebben gekregen, zit er toch ergens iets niet helemaal snor in je PHP-scripts. Dat hij vervolgens ook nog eens uitgevoerd kon worden is helemaal vreemd. Zoek eens terug in je acces-log van Apache wat voor requests er rond het tijdstip van de defacement zijn gedaan.
Welke pagina's zijn opgevraagd en welke parameters zijn meegegeven.

[0528973]

Gelukkig mag ik zeggen, niet in mijn eigen code... Ik weet niet precies of het een exploit of een fout in onze eigen code is geweest. Ik verwacht een fout in onze eigen code, al vraag ik me nog steeds af hoe hij het bestand heeft kunnen uitvoeren

Nou ja, gelukkig heb ik de tijd gekregen om alle oude sites die niet van mijn hand zijn te verbeteren...

[frickY]

Hoe ze het bestand tot uitvoer hebben gekregen... Misschien door hem als CGI zijnde aan te roepen?
Ik ben in ieder geval erg benieuwd naar de oorzaak...
Was er nietrs vreemds in de acces-log van Apache te vinden?

[ Voor 17% gewijzigd door frickY op 08-06-2005 16:49 ]

[0528973]

Een bestand kan alleen als CGI aangeroepen worden als het op de juiste plaats staat. Daar stond het dus niet. Apache geeft geen vreemde logs weer, daarnaast levert het bestand volgens mij alleen root-access op een shell als er al via een shell is ingelogd.

Wat er gebeurt lijkt te zijn:
een bestand is er ge-upload, deze is op een ongebruikelijke plaats terecht gekomen(de algemene tmp-dir) terwijl er voor elke site een specifieke tmp dir is ingesteld.

er lijkt shell access verkregen te zijn.

dmv het eerder geuploade bestand heeft men root-access verkregen en bestanden overschreven, om de server daarna lekker met rust te laten.

---
Voor de eerste stap kan ik een verklaring vinden(hiervoor moet ik alle sites gewoon goed nalopen en testen) Ik vraag me echter nog steeds af, hoe deze hacker(meer waarschijnlijk, een script) shell-access heeft verkregen.

[frickY]

Zoek eens naar scripts welke de exec- system of passthru-functies gebruiken?

Ik begrijp dat er meerdere sites op je server draaien. Dat er ergens vergeten is een tmp-dir te defineren is mogelijk. Maar onwaarschijnlijk dat de 'hacker' dit wist.
Wat kom je uit als je op IP naar je kast surft? Of een domein van de kast vraagt welke helemaal niet op die kast draait?

[igmar]

0528973 schreef op maandag 06 juni 2005 @ 14:30:
uselib24 is gebruikt om root te worden, en er zijn wat aanwijzingen die erop duiden dat het desbetreffende bestand er via apache icm perl of php op het systeem is gekomen.

uselib is een lokale kernel exploit, wat concreet aangeeft dat je je kernels niet gepatched hebt / had.
Verder :

1) Zet op /tmp ed noexec of nosuid aan
2) Zet op /tmp ed nodev aan
3) Zet alle niet-noodzakelijke poorten dicht dmv iptables
4) Zet in PHP alles uit wat extern een shell kan uitvoeren (exec, system, popen, etc).

Indien mogelijk :

5) Zorg dat apache in een (1) locatie kan en mag uploaden
6) Gebruik grsec en zet PAX aan.

[ Voor 3% gewijzigd door igmar op 09-06-2005 15:41 ]

[igmar]

0528973 schreef op donderdag 09 juni 2005 @ 10:27:
Een bestand kan alleen als CGI aangeroepen worden als het op de juiste plaats staat. Daar stond het dus niet.

Wat verhinderd mij op met PHP functies een exe uit te voeren ?

Apache geeft geen vreemde logs weer, daarnaast levert het bestand volgens mij alleen root-access op een shell als er al via een shell is ingelogd.

Niet echt : Indien de exploit lukt wordt het huidige process een shell met euid 0, en met de standaard filedescriptors nog geopend.

Wat er gebeurt lijkt te zijn:
een bestand is er ge-upload, deze is op een ongebruikelijke plaats terecht gekomen(de algemene tmp-dir) terwijl er voor elke site een specifieke tmp dir is ingesteld.

sja.. Dat zal weinig helpen indien met ongerestrict fopen() ed kan uitvoeren.

Voor de eerste stap kan ik een verklaring vinden(hiervoor moet ik alle sites gewoon goed nalopen en testen) Ik vraag me echter nog steeds af, hoe deze hacker(meer waarschijnlijk, een script) shell-access heeft verkregen.

Zodra men PHP code kan uploaden en uitvoeren heeft men ook meteen shell.

[0528973]

Bedankt voor de laatste reacties, er zaten een aantal nuttige tussen waar ik nog niet eerder aan heb gedacht. Er zijn ondertussen uitgebreide voorzorgsmaatregelen genomen om te voorkomen dat dit nog vaker voorkomt. Bedankt.