Sophos ontdekt geraffineerde deface-methode met php-scripts

Beveiligingsfirma Sophos waarschuwt websitebeheerders voor een aantal geraffineerde aanvalsmethodes. Met behulp van php-scripts kunnen sites gedefaced worden zonder dat de eigenaar het bemerkt.

Een groeiend aantal websites wordt door hackers belaagd met code-injectie-aanvallen, voornamelijk via iframes. Via de iframes worden vervolgens php-scripts ingeladen, zo meldt Sophos. Door aanpassingen aan het script kan een site voor elke bezoeker die de betreffende website opvraagt gedefaced worden, terwijl zoekmachine-bots uitgesloten worden.

Door het uitsluiten van zoekmachines wordt voorkomen dat gekraakte pagina's uit de zoekindexen worden verwijderd. Bovendien werken de scripts via een blacklist zodat een bezoeker slechts eenmaal de defacement te zien krijgt, waardoor het lastiger is om het probleem te identificeren.

Sophos merkt bovendien op dat de kwaadaardige php-scripts zo zijn gemanipuleerd dat deze door websitebeheerders en beveiligingsfilters minder snel gedetecteerd worden. Niet alleen wordt de code meerdere malen versleuteld en gecomprimeerd via php-functies als base64_decode en gzinflate, ook worden scripts via obfuscation nog moeilijker te detecteren. Volgens Sophos kunnen site-eigenaren zich tegen deze aanvalsmethode deels verdedigen door regelmatig de bestandsgrootte en -datum van php-scripts op de server te controleren op mogelijke afwijkingen.

Reacties (59)

[YakuzA]

Zo ziet het er dus uit:
[php] Code ontcijferen

de 'blacklist' is gewoon een cookie

[Reactie gewijzigd door YakuzA op 23 juli 2024 16:49]

[Mellow Jack]

Best mooie code moet ik eerlijk toegeven Met alleen maar een beetje basis php kennis kom je niet ver

[Peedy]

Dit probleem wordt ook verspreid door "free Wordpress templates", zie hier; http://wpmu.org/why-you-s...-google-or-anywhere-else/

[Scripted]

Voor de meeste webmaster is gewoon belangrijk als je cms / forum of ander scripts op je server hebt draaien die regelmatig te updaten. En jezelf inschrijven op update nieuwsbrieven is ook handig, weet je direct wanneer er update's van je scripts uit zijn.

Ook standaard dingen zoals een lege index.html in al je directory's is ook wel verstandig.
Je folder permissies controleren en natuurlijk de basic .htaccess en php.ini instellingen controleren.

Ook alle 404 error pagina's afvangen en die logs naar jezelf sturen is handig.
Weet je in iedergeval wat ze allemaal proberen.

On October 20, 2011, 12:37:30
***.***.***.*** tried to load www.domain.nl/.htaccess
User Agent = Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1
User got there from: Unknown Location

er zijn natuurlijk nog veel meer dingen, effe googlen breng veel antwoorden.

[DexterDee]

Een goede eerste stap om dit soort problemen te voorkomen is het uitschakelen van de eval() functie. Dit kan vrij eenvoudig en zonder PHP safe mode te gebruiken:

In de php.ini van je server zet je dit statement:
disable_functions = eval

De eval() functie in PHP is slechts in zéér uitzonderlijke gevallen nuttig en moet in normale omstandigheden nooit gebruikt worden. Het uitzetten kan dus vrijwel zeker geen kwaad.

Er zijn trouwens ook nog andere potentieel "gevaarlijke" commando's die ongebruikelijk zijn in een webomgeving, zoals exec,passthru, proc_close, proc_open, shell_exec, dl, popen en show_source. Deze kunnen naar behoefte ook uitgeschakeld worden door ze komma gescheiden in het lijstje op te nemen.

[wootah]

Mja, dat php moet ook maar eens afgelopen zijn eigenlijk...
Ik heb mijn website al onder versie beheer gezet, die ik ook regelmatig controleer op veranderingen, maar toch voel ik me onveilig, vooral met al die website defacing van de laatste tijd.

Het word echt tijd dat er een beter taaltje beschikbaar komt die by-design al makkelijk tegen script injecties weet te verweren.

[eth0stack]

Volgens Sophos kunnen site-eigenaren zich tegen deze aanvalsmethode deels verdedigen door regelmatig de bestandsgrootte en -datum van php-scripts op de server te controleren op mogelijke afwijkingen.

Even een tipje voor de mensen die op linux zitten (de meeste, als je shared hosting met cpanel hebt is 99.9% linux)
Vaak heb je ook ssh. Als je hierop kan inloggen kun je met deze command een lijst maken met php bestanden die veranderd zijn.

find /locatie/ -name '*.php' -mtime -30 -print

Verander de /locatie/ met de path waar je wil zoeken op php bestanden. de -mtime 30 betekent dat "find" alle php bestanden laat zien die veranderd zijn tussen nu en 30 dagen oud, dit kun je veranderen naar wens.

[Reactie gewijzigd door eth0stack op 23 juli 2024 16:49]

[wootah]

Goede tip
En als je dan toch je eigen server hebt kun je nog altijd svn of git gebruiken om de versie te checken. Je kan sowieso altijd een bepaald punt terugzetten

[AtlonXP1800]

In elke taal kan je "slechte" code schrijven die vatbaar voor aanvallen is. Feit is dat een populaire taal aantrekkelijker is om aan te vallen en php is nou eenmaal één van de talen waar een zeer groot deel van de internetpagina's mee wordt gebouwd.

Aangezien in dit artikel niet wordt gemeld hoe de hack wordt uitgevoerd, maar enkel wordt gemeld dat er een extra stukje php wordt geplaatst valt PHP geen enkele blaam, dit zou je in elke andere taal ook zo kunnen bouwen.

[wootah]

Mijn punt is, dat php eigenlijk niet super geschikt is voor webpagina's.
Wat je eigenlijk wilt, is dat het ontwerp van de taal standaard al de meeste zooi tegen houd door bijvoorbeeld rechten toe te kennen aan variable en functies... etc.
Dat maakt niet alleen het programmeren makkelijker, maar ook nog eens netter.

[moozzuzz]

PHP heeft er eigenlijk niets mee te zien. PHP is de taal om het defacement uit te voeren in dit geval, niet de instantie die veilig of onveilig is. Het is niet enkel de verantwoordelijkheid van de scripttaal om "veilig" te zijn, je zou hetzelfde kunnen zeggen van mysql/apache die meestal in de combinatie met PHP ingezet worden.

Het is de aard van het beestje dat PHP nooit out of the box injectie-ongevoelig zal zijn, het is immers een scripttaal geen programma.

[Roland684]

Inderdaad, dit heeft niet specifiek betrekking op php.

Maar er zijn, om php aantrekkelijk te maken voor beginnende programmeurs, wel diverse keuzes gemaakt die vanuit veligheids-oogpunt niet erg verstandig waren. Doordat je bijvoorbeeld variablelen niet expliciet hoeft te definieren, is het makkelijker om fouten te maken die onopgemerkt blijven.

Het is een quick-and-dirty taal. Dat heeft zijn voors en zijn tegens. PHP is wel degelijk onveiliger dan de gemiddelde andere taal, niet vanwege zijn populariteit, de populariteit is eerder een gevolg daarvan.

[Reactie gewijzigd door Roland684 op 23 juli 2024 16:49]

[highflyer]

Valt dit soort injecties niet tegen te gaan door je file read only te maken?

[t_captain]

Ten eerste, strak dicht zetten van (schrijf)rechten op je systeem. Niet alleen je filesystem, maar ook andere storage (cache, database etc). Is bij dynamische sites wel lastiger. Als je alles dicht zet van een blog, kan er niemand meer posten.

Tweede aanpak: virtualisatie. Dat helpt tegen exploits die iets installeren op de server; de wijzigingen op de server gaan verloren wanneer (periodiek) een image wordt teruggezet.

Derde aanpak: automatische test. Maak een client die regelmatig je pagina's bekijkt (zonder persistente client state zoals cookies natuurlijk ). Die merkt defacing ook wel op.

[Anoniem: 329694]

Deface is toch het bekladderen van website's? En de websitebeheerder ziet het niet? Dan is het toch geen deface meer?

[Rub3s]

Bovendien werken de scripts via een blacklist zodat een bezoeker slechts eenmaal de defacement te zien krijgt, waardoor het lastiger is om het probleem te identificeren.

Het staat er toch echt in het artikel hierboven....

Lijkt me erg lastig te verwijderen als ik zo dit nieuwsbericht lees. Weer een reden om je website in de eerste plaats goed te beveiligen, ipv achteraf

[Inny]

Het is niet lastig te verwijderen, het is lastig te detecteren. Het artikel zegt niets over hoe het überhaupt op het systeem komt, dus inderdaad, goed beveiligd systeem: niets aan de hand.

[SKiLLa]

Meestal wordt het gewoon via een lek CMS of gastenboek geplaatst en vervolgens wordt het iframe in elke PHP/HTML pagina geinjecteerd (meestal direct als 1ste tag achter de BODY-tag, of juist als allerlaatste voor de /BODY-tag).

Die iframes verwijzen meestal naar obscure .ru urls die soms tot weken lang niet geblacklist worden door de phishing filters van de browser-makers.

Een eind-gebruiker kan het ook merken doordat er vaak enorm veel exploit-vectors uitgeprobeerd worden op de bezoeker, van Flash, Java, Adobe Licensing Manager (= berucht) tot standaard IE exploits en zodanig (als je de pech hebt geinfecteerd te worden) je PC gaat staan 'stampen/ratelen' als je die website bezoekt.

PS: De Sophos link is ook alleen een blog-post met een analyse van een dergelijke (nieuwe ?) variant; er is helemaal niets nieuws 'ontdekt', dergelijke technieken zag je 2 jaar geleden al in het wild. De titel van dit nieuwsbericht is dus een beetje misleidend ...

[defixje]

je PC gaat staan 'stampen/ratelen' als je die website bezoekt

Nou als je een beetje een goede pc heb met uitstekende specs kan je dat tegenwoordig daar ook niet meer vanaf zien

[T-men]

...goed beveiligd systeem: niets aan de hand.

Pas op dat je met die gedachte niet op je lauweren gaat rusten. Altijd alert blijven !
Controleer de kenmerken van de server handmatig. Open en lees regelmatig je logfiles enz.

Overigens is defacing wel degelijk gevaarlijk. Een melding als "This server is hacked by ..." is inderdaad alleen maar vervelend, maar met hetzelfde gemak ziet een pagina er 'gewoon' uit, maar worden op de achtergrond stiekum de credit-card gegevens doorgesluisd.

Je admin wordt in je bedrijf steeds belangrijker. Voeger was zijn voornaamste taak de systemen op kantoor in de lucht te houden. Tegenwoordig bewaakt hij de toegang tot je meest belangrijke data (én houdt bovendien de systemen op je kantoor draaiende )

[Inny]

De meeste systeembeheerders (zeker in het MKB) hebben de kennis niet of krijgen de kans niet om überhaupt fatsoenlijk onderzoek te doen naar de security, hebben het al druk zat met andere zaken of door gevolgen van slechte security en werkwijze. Deze twee zijn nauw met elkaar verweven, overigens.

[Inny]

Je boodschap zet meer aan tot paranoia dan tot iets anders, trouwens...

[CMG]

Waarom niet gewoon checken op eval, base64_decode en gzinflate? Meestal heb je deze functies niet nodig en als je ze wel al gebruikt, weet je als developer goed waar dat zou moeten zijn. Een rogue functie zou zo sneller gedetecteerd moeten worden.

[FreqAmsterdam]

Als er een klein stukje gewijzigd wordt zonder dat iemand daar wat van merkt kan er flink misbruik gemaakt worden van bepaalde zaken.

Denk bijv. aan phishing. De klant is op een vertrouwd domein en klikt op een link op een gedefaced stukje dat leidt naar een niet vertrouwd domein. De klant merkt daar niets van en voor de beheerder is het moeilijk te detecteren.

Edit: Typo's.

[Reactie gewijzigd door FreqAmsterdam op 23 juli 2024 16:49]

[S7YX]

Vaak worden anti-virus programma's uitgerust met internet security, die aangeeft dat de link onbeveiligd is of zelfs schadelijk kan zijn. Zelf heb ik McAfee internet security en AVG 2011 die beiden aangeven of een site niet veilig is. Dus iemand met zo'n programma zal dus geen slachtoffer van zo'n dergelijke exploit worden, mits ze de waarschuwing serieus genoeg nemen.

[Anoniem: 63975]

Dan moet die site wel worden gedetecteerd alszijnde onveilig.

[Torrentus]

Zolang de bezoekers het maar blijven zien is het wel een deface..

[broodjekaas92]

een websitebeheerder kan het dus ook zien( ook al is het eenmalig) dus veel zin heeft het niet

[BLACKfm]

Hoe vaak loop jij je hele site door om te kijken of alles nog klopt?

Je eigen web-blog met 5 pagina's is wellicht nog makkelijk te beheren, maar een belangrijke site met >100 verschillende pagina's is dan een ander verhaal.

[timonb]

Op zich is dat niet zo heel moeilijk, maak 1 script die een lijst maakt van alle PHP bestanden die sinds x dagen geleden zijn gewijzigd.

[Gersomvg]

Die 'last modified'-datum is ook te manipuleren toch? Of is dat met alleen PHP niet mogelijk?

[wow7]

osC_Sec kan dat bijvoorbeeld als je Oscommerce gebruikt als shop die ziet als er veranderingen plaats vinden op de server.

Je kan zelf ook een functie (script) schrijven (bedenken) in php met filectime ( ) en filemtime ( ) welke dan een berichtje zou kunnen sturen en waarschuwt dat er veranderingen op de server plaats vinden , zo heel erg moeilijk moet dat ook weer niet zijn.

The filectime() and filemtime() filesystem functions in PHP will allow you to check and see when a file has last been changed. It will return a timestamp holding the value of the time the file was last altered, which you can then modify for human reading using the date() function.

[J.J.J. Bokma]

Als iemand op je server je PHP bestanden aanpast, dan kan die dat inderdaad prima doen. I.p.v. datum controle zou je een MD5 digest of SHAxxx digest kunnen controleren, maar goed, als iemand al op je server zit kan daar ook wat aan gedaan worden.

[Thomzh]

Regelmatig bestandsgrootte en datum controleren is geen doen voor grote systemen. Hoe kan deze methode VOORKOMEN worden? (dat is immers beter dan genezen).

Is het een kwestie van geen iFrame's gebruiken?

[Emunator]

Is aardig te doen via scripts neem ik aan.
Neem een prive web site directory en een public.
Laat een script automatisch na een bepaalde interval de prive en public vergelijken.
Bij verschillen ten opzichte van de prive dir de prive bestanden naar de public kopieeren.

[hackerhater]

Nog makkelijker : zorg dat de webserver geen schrijfrechten in de www heeft.
hiervoor heb je wel doorsnee SSH-toegang nodig

[Roland684]

Voorkomen doe je door te zorgen dat je systeem niet gehacked wordt. Dat heeft niets ( specifiek) met iframes te maken.
Daarnaast moet je kunnen detecteren of je misschien toch gehacked bent.

De opmerking dta je de bestandsgrootte en -datum moet controleren is wel opmerkelijk. Dat laat nog steeds wijzigingen toe. Beter zou zijn om vooral de inhoud te controleren.

Daar zijn systemen als tripwire voor. Maar je kunt natuurlijk ook prima zelf iets bouwen dat de bestanden controleert, bijvoorbeeld op basis van hashes. Liefst vanaf een andere locatie.

[Cronax]

juist een heel slimme defacement, hij zal langer blijven staan, iedereen krijgt hem maar 1 keer te zien waardoor ze aan zichzelf gaan twijfelen ipv aan de website...

[sumac]

Cookies laat ik altijd verwijderen bij het sluiten van de browser. Dus dat zou bij mij betekenen dat ik de pagina één keer te zien krijg totdat ik de browser sluit. Volgende keer zie ik de exploit weer, en na een refresh niet meer, en dan ga ik toch echt wel met een andere browser kijken (Chrome in incognito mode), en dan gaat er langzaamaan een belletje rinkelen.

[defixje]

Behalve als het scripts gewoon een ip-logfile bij houdt. Dan zie jij het ook maar gewoon 1 keer hoor. Ook met een andere browser.

[Reactie gewijzigd door defixje op 23 juli 2024 16:49]

[Solutio]

Is er ook een manier om te testen of je website hier tegen bestand is?

[sumac]

Alle websites die jij op die server hebt staan bedoel je? Plus de webserver zelf, plus een veilig wachtwoord, plus de server (of je 'm nu zelf thuis hebt staan of laat hosten). Alles moet veilig zijn, want het maakt niet uit hoe ze binnenkomen, als ze maar even toegang hebben om een php-script aan te passen.