Drupal waarschuwt voor misbruik ernstig beveiligingslek

Een kwetsbaarheid voor sql-injectie die eerder deze maand in Drupal werd gevonden, wordt actief misbruikt. Het contentmanagementsysteem waarschuwt beheerders van een Drupal-installatie dat ze zijn geïnfecteerd als ze het lek nog niet hebben gepatcht.

Elke Drupal-installatie die niet binnen zeven uur na het verschijnen van de patch op 15 oktober is bijgewerkt moet als gecompromitteerd worden beschouwd, waarschuwt het cms. Dat komt doordat aanvallers geautomatiseerd zouden hebben gezocht naar Drupal-installaties die kwetsbaar waren voor het beveiligingslek. Dat lek laat aanvallers eigen sql-code injecteren. De kwetsbaarheid kan er bovendien toe leiden dat aanvallers eigen php-code kunnen injecteren.

Wie Drupal nog niet heeft bijgewerkt naar de nieuwste versie, is dan ook te laat, blijkt uit de waarschuwing. Het installeren van de patch zorgt er namelijk niet voor dat bestaande backdoors worden verwijderd. In het geval van besmetting is het aan te raden om een back-up van voor 15 oktober terug te plaatsen en deze vervolgens meteen te patchen. Het is zelfs aan te raden om een nieuwe server te nemen, aldus Drupal, of op zijn minst alle websites en databases te verwijderen.

Het is onbekend waar dat laatste advies uit voortvloeit; mogelijk is Drupal bang dat aanvallers vanuit php andere delen van het systeem hebben aangetast. Als de php-installatie het uitvoeren van shell-commando's toestaat, kan het zelfs zo zijn dat aanvallers hebben gezocht naar andere beveiligingsproblemen om hogere systeemrechten te krijgen.

Reacties (114)

Je kunt dit controleren door in Drupal in te loggen, vervolgens klik je op Rapportages en open Systeemrapportage. Bovenin staat welke versie van Drupal is geinstalleerd. Wanneer hier versie 7.31 of lager staat ben je kwetsbaar en moet je updaten naar 7.32, waarin het lek is gedicht. Mits je niet besmet bent.

[Reactie gewijzigd door blottle op 30 oktober 2014 09:50]

Het is ook mogelijk om te controleren of er hacks in core/contrib modules en themes zijn aangebracht door de volgende module te installeren: https://www.drupal.org/project/hacked

Edit: Deze module controleert alleen files, in de database kunnen nog steeds hacks zitten.

[Reactie gewijzigd door jeroensurft op 30 oktober 2014 10:35]

Registreert de hacked module ook _toegevoegde_ bestanden?

Zo te zien (nog) niet: https://www.drupal.org/node/2363083

Dit is niet volledig. Versie 6 is niet kwetsbaar!

En als je nu nog niet geupdate bent, dan mag je er vanuit gaan dat je site al gehackt is.

Ik heb drupal sites die binnen de 24h al prijs hadden.

ik heb een hobby drupal site, net pas geupdate dus aanzienlijk laat, hoe kan ik zien of ik besmet/gehackt ben?

Zal sowieso voor de zekerheid een backup van de vm terug gaan zetten later.

Dit kan nuttig zijn: http://drupal.geek.nz/blog/your-drupal-website-has-backdoor

Je moet 2 dingen doen:
- Checken of er bestanden gewijzigd zijn sinds woensdag 15/10 in je installatie (vergeet je geuploaded files ook niet te bekijken, liefst vanaf een backup van voor 15/10)
- Controleer wat er allemaal gewijzigd is in je database sinds 15/10 (ook vanaf backup).

Je kunt ook in de logs van je webserver gaan kijken naar opvallende POST's. Hier vind je een overzicht van de meest gebruikte aanvallen vind je hier: https://www.getpantheon.com/blog/what-we-are-seeing-drupal-sa-2014-005

Ook dit is nooit helemaal sluitend, omdat een aanvaller in sommige gevallen via local privilege escalation root privileges heeft kunnen krijgen. In dat geval is alles wat je op het systeem uitvoert een risico. De SSH of FTP daemon kan vervangen zijn door een versie die je wachtwoord plaintext doorstuurt. De ls, bash, etc commando's kunnen een backdoor hebben die de hackers extra rechten geeft. De sky is wat dat betreft de limit.

Nu zal dit in de meeste gevallen niet gebeuren. Maar als je een machine draait met een outdated kernel, dan is de kans groot dat er nog wel een klein backdoortje te gebruiken was, mits de hacker via PHP bij de shell kon komen,.

Dank u, leer ik weer van.

Wanneer je nou in de Drupal install dir volgende commando uitvoert (linux)

find . -type f -mtime -16

En behalve logbestanden geen gewijzigde bestanden gevonden, zit je dan wel safe? Dan is er geen aangepaste code neem ik aan?

Tip voor de volgende keer:

Zorg er voor dat je de bestanden en database regelmatig backupt. In zo'n geval als deze, wat wel eens vaker zal voorkomen, kan je de bestanden op de server dan gewoon verwijderen en vervangen door je backup. Sowieso is een backup altijd handig. Er kan ook een fout op de server ontstaan waardoor je database wordt beschadigd, of je kunt per ongeluk verwijderde bestanden terug zetten. Daarnaast handig om aangepaste thema's te bewaren, voor als het verkeerd gaat bij updaten.

Uiteraard had ik wel backups, maar wanneer je 2 weken terug gaat en in de tussentijd contentwijzigingen hebt aangebracht ben je die natuurlijk ook kwijt.

zoals in de bevindingen van https://gist.github.com/joshkoenig staat, gebruiken sommige hacks het commando "touch met de originele datum"... en dan kan je dus niet zien dat ie gewijzigd is...
ik zou eerder aanraden om drupalgeddon en site_audit te draaien :
drush dl site_audit
drush dl drupalgeddon
drush cache-clear drush

in je webdir / httpdocs dir : drush asec
die verteld je ook als er een injectie in je menu_router table staat
(kan je ook handmatig doen :
SELECT * FROM `menu_router` WHERE `access_callback` like "file_put_contents"
)

++
en vooral te diffen met originele sources van drupal en te diffen tussen een vers mysqldump een oude.
diff -r /backupdir /jewebdir > verschil.txt
diff ouwedump.sql niewedump.sql > bdddif.txt

[Reactie gewijzigd door zeduude op 30 oktober 2014 12:27]

Zoals eerder gezegd moet je ook niet enkel in die directory zoeken... Er kan ook een level lager of in andere dirs shit gewijzigd of toegevoegd zijn.

Toen de eerste berichten van het lek opdoken wist niemand dat het zo snel zou gaan! Wij hebben gelukkig onze websites snel kunnen patchen.

De grote hosting firma's hebben snel alle klanten verwittigd en kort daarna hebben ze een hotfix toegepast. De kwetsbaarheid zat namelijk in één lijntje code. Ze zijn dit systematisch beginnen overschrijven op al hun Drupal installaties.

Wil je checken of je gehackt bent, check dan Drupalgeddon, wat enkel met drush te gebruiken is. Indien je hier melding krijgt over gewijzigde bestanden, check dan de Hacked! module. Deze checkt overigens alle bestanden. Dus als je bijvoorbeeld een README.txt verwijderd hebt, dan geeft deze ook melding hiervan.

Ook runnen van Drupalgeddon is niet genoeg!
In feite is alles dat onder je webserver draait het haasje.
- Verander het wachtwoord van de Druapl user in je MySql database
- Verander ook alle wachtwoorden (van gebruikers) die in je MySql staan en waar Drupal bij kon
- Restore alle bestanden waar je webserver schrijftoegang toe had.
- Restore alle Drupal bestanden, modules en instellingen
- Zorg dat alle folder waar je webserver kon schrijven geen andere bestanden bevat dan er in de restore stonden
- In al die beschrijfbare folders ben je dus je wijzigingen gedaan na 14 oktober kwijt..

Is Drupal 6.x vulnerable?
Drupal 6.x is not vulnerable to SA-CORE-2014-005 (CVE-2014-3704).
https://www.drupal.org/drupalsa05FAQ

voordat mensen direct denken dat alles lek is onder versie 7.32 zoals nieuwsbericht eigenlijk doet suggeren.

[Reactie gewijzigd door Qualixo op 30 oktober 2014 13:34]

Wie Drupal nog niet heeft bijgewerkt naar de nieuwste versie, is dan ook te laat, blijkt uit de waarschuwing. Het installeren van de patch zorgt er namelijk niet voor dat bestaande backdoors worden verwijderd. In het geval van besmetting is het aan te raden om een back-up van voor 15 oktober terug te plaatsen en deze vervolgens meteen te patchen. Het is zelfs aan te raden om een nieuwe server te nemen, aldus Drupal, of op zijn minst alle websites en databases te verwijderen.

Damn, hoe kun je je toekomstige gebruikers afschrikken... . Het is wel duidelijk dat ik met een grote boog om Drupal loop na dit nieuwsbericht.

Tsja, en welke ga je dan gebruiken? Een willekeurig ander open source CMS? Iets wat je zelf hebt gebouwd?? waarbij je geen enkele publieke library gebruikt? Platte HTML?

En op welke server? IIS? Op een WindowsPlatform? Of ga je het op een *nix-systeem zetten? En die zijn wel helemaal dicht? Zie bijv. nieuwsberichten over heartbleed nog eens.


Ik ga al wat jaartjes mee en het is best prettig om een miljoen Wordpress/Drupal/Joomla/PHP installaties te hebben als 'test-case'. Deze worden elke dag aangevallen en elke dag verbeterd. Als er iets gebeurt in die sector dan hebben we het tenminste gelijk boven water.

De 'eigen ontwikkelde CMS-en' zitten vol met gaten waar je het NIET van weet. En als er iets mis gaat ben je weken aan het debuggen om erachter te komen waar het gat zit.

Neem van mij aan - het overgrote deel van websites is gewoon het beste/goedkoopste/slimste af met een goede disaster recovery/backup.

Welke dan gebruiken?

In elk geval een CMS waarbij niet geautomatiseerd gedetecteerd kan worden op welk CMS een website draait. De reden waarom ik al een decennia geen Joomla meer gebruik omdat in de meta tags zelfs het versie nummer stond (kan nu best anders zijn, maar het kost teveel tijd om alle CMS-en te blijven checken).

Mijn voorkeur ligt al een poos bij ModX. Erg flexibel en een erg sterke basis alhoewel steile leercurve als je zelf modules wilt bouwen. De manager (backend) is op een url naar eigen keuze in te stellen en kan op die maneir dus ook nauwelijks geautomatiseerd gedetecteerd worden.

Edit: een CMS zelf ontwikkelen is natuurlijk erg goed voor je programmeer skills maar zou je nooit in productie mogen nemen. Wel heel arrogant om te denken dat je het allemaal net zo goed weet als een devteam / community die al 5+ jaar aan 1 product sleutelen.

[Reactie gewijzigd door prutsger op 30 oktober 2014 10:08]

Yep - dat onderscheid de beginners van de gevorderden

- geen standaard detectiemogelijkheden
- geen publicatie van wat je hebt
- geen default passwords, usernames, locations, etc

Maar zelfs dan ben je nooit zeker: ModX kent ook enkele gaatjes
http://web.nvd.nist.gov/v...x&search_type=all&cves=on

Dus het advies blijft: Zorg voor een goede disaster recovery. En zet die dan niet op je ongepatchte Synology Nas ... Want als die Cryptolocker voorbij komt ben je ook die weer kwijt...

tenzij je al 10 jaar een eigen CMS hebt, die vaak genoeg wordt gescreent door externe bedrijven om gaten te vinden, dit zegt natuurlijk niet direct dat het veilig is maar wel dat het moeilijker is te hacken als een wordpress website of joomla.

Tevens is het meestal niet de core wat het probleem is meer de thema's en plugins.

...mijn Wordpress/Drupal en Sitefinity sites worden elke dag zo'n duizend keer 'gechecked' of deze nog veilig zijn En de core is eigenlijk best veilig (zeker als je kijkt naar de functies die er allemaal standaard in zitten). Ik maak me meer zorgen om de plugins...

Ik heb jaren voor een eigen ontwikkeld CMS gewerkt, en onze scanbedrijven keken inderdaad naar veel oppervlakkige en bekende mogelijkheden. Maar ik durf niet te zeggen dat het veel veiliger is hoor. Onbekend: ja. Veiliger daardoor?... mwa.

Ik weeg per klant gewoon af: "hoe erg is het als deze gehacked wordt". En als dat een 'bakker op de hoek" is met 10 pageviews per dag dan mag deze best eens een half dagje offline i.v.m. backup/restore.

Bij een KLM, bol.com of een Tweakers kun je je dat niet veroorloven natuurlijk en dan heb je het over een site van een hele andere orde. Dan zit daar ook een file en database-monitor op die kijkt of er ongeoorloofde wijzigingen uitgevoerd worden.

Maar hoe kun je je nu echt wapenen tegen inbraak?? Er zijn vele 'hardening' tutorials, maar dat houdt ook niet alles buiten.

Ik zie met wappalyzer toch af en toe een modX site langs komen.
Zie bijvoorbeeld: http://www.snijder.nl/
En als ik het met zo'n tooltje al kan vinden, dan zal een hacker daar ook zeker geen problemen mee hebben.

Edit: Ik keek even naar de issues waar Stranger__NL naar linkt, en de laatste zijn net zo serieus als bovenstaant Drupal issue. Punt is dus vooral dat Drupal dit veel serieuzer oppakt.

[Reactie gewijzigd door rvec op 30 oktober 2014 14:27]

@ xleeuwx, ergomane, rvec,

Eens met jullie hoor. Wat ik noem is slechts een begin. Maar een goed CMS exposed in mijn ogen niet welk CMS het is, en maakt het in thema's niet mogelijk om PHP uit te voeren (scheiding van logica en layout). Dat doet ModX in mijn ogen erg goed. Uiteraard kun je daarna als ontwikkelaar alsnog de boel wijd open zetten.

Uiteraard komen er dan scans van exploits van andere CMS-en op je site, maar liever dat ze hun resources daar aan opmaken dan meer gerichte pogingen.

Ik ben ook niet van mening dat ModX de heilige graal is en er geen exploits voor zijn. Bij Modx wordt je ook snel op de hoogte gebracht via de ingebouwde newsfeed en twitter.

Het is trouwens niet mijn bedoeling dat dit een pro/con ModX discussie wordt. Het ging meer om de voorbeelden. Doe als CMS gewoon zoveel mogelijk goed. De rest is aan de beheerder/ontwikkelaar.

> In elk geval een CMS waarbij niet geautomatiseerd gedetecteerd kan worden op welk CMS een website draait.

Dat boeit veel exploit bots niet echt. Ik zie bijvoorbeeld behoorlijk wat Joomla aanvallen op een Drupal site.

[code]
De 'eigen ontwikkelde CMS-en' zitten vol met gaten waar je het NIET van weet. En als er iets mis gaat ben je weken aan het debuggen om erachter te komen waar het gat zit.[/code]

wat is dat nu voor onzin? mijn eigen ontwikkelde CMS (die op een 15 tal websites draait) heeft niet zulke gaten. maar mijn eigen ontwikkelde CMS is dan ook niet zo uitgebreid als Drupal.

heel spijtig voor de developers van Drupal om dit soort lekken tegen te komen. Zeker in de laatste jaren zijn sql inject bugs afgenomen. de nieuwe technologie probeert dit dan ook zo goed mogelijk te verhinderen (entity framework, mvc, ...) en dan spreken we nog niet over de design patterns. als het juiste pattern gevolgd is kan er onmogelijk een sql command van de presentationlayer rechtstreeks naar de data access layer gaan.

mijn gedacht is gewoon dat dit nog een oud stukje code in Drupal was dat over het hoofd gezien is.

Publiceer eens een link naar een site met jouw CMS. Plaats ik 'm op een speciale site en zeg ik erbij: "Deze is niet te hacken! Prove me wrong.".

Spreek ik je morgen weer.

Don't worry, ik ga de wedstrijd niet echt aan hoor... maar je moet wel enige onzekerheid hebben gevoeld toen je de eerste regels las. Ook in jouw CMS zit een gat. En als het niet rechtstreeks is dan wel via je OS. En anders via BruteForce. Je _kunt_ niet in je eentje een CMS ontwikkelen en alle detectiemogelijkheden/inbraakpogingen hebben afgevangen? En anders ben je nu aangenomen als hoofd ontwikkelaar. Ik zag 'm het eerst!

Ga voor de gein eens naar deze site en type eens wat libraries of hosting/OS spullen in die jij gebruikt. Kwam er nergens iets naar boven?

http://web.nvd.nist.gov/v...y&search_type=all&cves=on

[Reactie gewijzigd door Stranger__NL op 30 oktober 2014 10:27]

Het is een blijft ook een combinatie van goede hardware met software. Wij zitten bij een goede leverancier qua hardware en die leveren ook de support. Wanneer een lek in opensource libraries bekend wordt en er wordt een patch uitgebraht dan is deze dezelfde dag (ook al is het 03:00u s'nachts) geïnstalleerd. Daarbij betalen wij wel grof voor een VPS, maar de performance is goed, de support is goed en de oplossingen die zij aanreiken bij vraagstukken zijn ook goed.

Daarbij hangt het ook van je architectuur af. Wij hebben bijvoorbeeld enkel de front-ends publiekelijk toegankelijk. Alle data verloopt via XML-RPC/XML-LPC die op zijn beurt weer met de SQL database communiceert. De database is enkel te bereiken via het interne netwerk (tussen de VPS server zelf).

Wat ik mij wel afvraag, dan heb je nog zo'n grote community en kan iedereen je bron code inzien en dan nog is het mogelijk om SQL-injectie uit te voeren? Heeft bijna iedereen zitten slapen dan? Wellicht zit hier een addertje onder het gras en hebben hackers juist mannetjes in dit soort projecten zitten zodat zij juist kwetsbaarheden kunnen maken die later weer op grote schaal misbruikt kunnen worden. Want je hebt maar 1 lek nodig en je hebt er, afhankelijk van de configuratie, een server bij.

Het is niet zo dat als de broncode online staat dat er direct door iedereen naar gekeken wordt. Ik heb vaak genoeg in broncodes van CMS systemen gekeken, maar soms is daar geen doorkomen meer aan door verwijzing na verwijzing.

De introductie van het lek is idd nogal vreemd gegaan. Op de avond voor kerst is een niet-gereviewde patch, die slechts als "benchmark" discussiepunt werd aangeboden, gecommit door de BDFL.

elke software heeft gaatjes daar ben ik zeker mee akkoord maar hoe kleiner de software hoe minder fouten je gaat vinden. daarom ook dat ik zei dat mijn cms ook veel kleiner is dan een software als drupal. ik ben er ook zeker van dat iemand die echt moeite doet geen probleem heeft om anti-forgery tokens na te maken. maar het zijn allemaal de kleine dingetjes die de 'amateurs' buiten houden

toch wel een leuke ref. die je mee geeft, zeker handig om eens rond te neuzen. ty

dan kun je 99% van alle prebuild web- meuk wel negeren...

Ik vind het juist moedig van Drupal om hiermee naar buiten te komen. Anders had je de patch geïnstalleerd met de gedachte dat je weer veilig bent. Ze geven zelfs een aantal mogelijke oplossingen, of je deze nou leuk vind of niet.

Voor mij zou dit juist een rede zijn om Drupal in overweging te nemen zou ik hiernaar op zoek zijn.
Een fout maken is menselijk en dus doet iedereen dat. Een fout op de juiste manier oplossen of je fout toegeven dat doen er maar weinig.
Dus om maar in de internet sfeer te blijven: +1 voor Drupal

Dit is een algemeen iets, en geldt voor elk script dat de mogelijkheid heeft gehad om php code te installeren of te wijzigen via een exploit.

Juist goed van Drupal dat ze dit GOEDE advies durven te geven, alleen willen de mensen dit niet horen... kost tijd om het goed te doen.

De enige goede beveiliging is een checksum hebben van elk bestand en een overzicht krijgen van nieuw toegevoegde/gewijzigde bestanden. Zo is er te zien of er gerommeld is.

[Reactie gewijzigd door kritischelezer op 30 oktober 2014 09:51]

Bestanden checken is niet genoeg. Je moet eigenlijk een diff van de database doorlopen om te zien wat ze gedaan hebben.

Hier vind je een overzicht van een aantal aanvallen via deze exploit: https://gist.github.com/joshkoenig
Zoals je kunt zien, de meesten touchen geen bestanden.

Dit kan ook handig zijn:
http://drupal.geek.nz/blog/your-drupal-website-has-backdoor

Goed advies; die server vervangen...?
Mwah. Het is een nogal overtrokken statement. Een goede PHP configuratie is daarbij de hoofdzaak.

Of dacht je dat alle shared hosting providers waar ook maar één Drupal installatie per server op draait meteen alle servers gaan herinstalleren omdat een of ander cms een lek heeft?
C'mon. Bij de meeste hosts kan een PHP script niet buiten z'n eigen accountje cq homedir komen.

Het is enkel goed advies als de server beheerder een lul de behanger is, maar dan heb je waarschijnlijk wel grotere zorgen dan enkel een Drupal exploit en wordt die server ook niet opnieuw geinstalleerd.

Het is mogelijk om bijvoorbeeld een hard drive controller firmware te flashen en daar een backdoor in te zetten, in dat geval is er echt een nieuwe server nodig, ook al maakt de gebruiker een nieuwe installatie. Vaak omdat huurders geen fysieke toegang hebben tot de servers, is dat de enige veilige oplossing.

[Reactie gewijzigd door kritischelezer op 30 oktober 2014 10:05]

Hoe wil jij in hemelsnaam firmware naar een hard drive controller flashen vanuit een PHP scriptje...?

Als het zo bizar slecht met je server configuratie gesteld is (eg: draait PHP als root ofzo...?) dan heb je wel grotere zorgen dan enkel een Drupal lek.
Over t algemeen, en de meeste hosters en serverbeheerders regelen dat wel, kan je zulk soort fratsen echt nevernooit uithalen via iets simpels als Drupal.

Met het ene lek kom je bij het andere en daarmee kun je uiteindelijk root rechten krijgen en gewoon via ssh inloggen.

Nou, dan moet je een hele slechte PHP config met daarnaast sterk verouderde software hebben wil je dat voor elkaar krijgen.

Wat jij hier beschrijft is echt heel ver gegrepen voor wat een PHP scriptje kan aanrichten.

Let er op dat een veiligheidslek in een PHP script helemaal niets te maken heeft met lekke systeemsoftware... Dat drupal gekraakt wordt houdt niet in dat de server software kwetsbaar is.

Als je server al zo slecht in elkaar zat dat zoies extreems uberhaupt mogelijk is, en die kans is bij redelijk onderhouden en geconfigureerde servers (gelukkig t merendeel van...) niet aanwezig, dan heb je sowieso al een probleem. Immers kan elk PHP script dan problemen veroorzaken op jouw systeem. Elke hack.
Sterker nog: elke klant. Een hackertje koopt een accountje, kan dus in de PHP code zetten wat hij wil... Poef, server root access gekregen.

Sorry hoor, maar zie je zelf niet een beetje in hoe extreem overdreven dat is...?
Als je je PHP configuratie op orde hebt, dan heb je he-le-maal niets te vrezen aan de server kant, je Drupal kan wel kapot zijn: maar verder niets.

Kom op man, als elk PHP script root access kan veroorzaken heb je een veel groter probleem dan je gekraakte cmsje...

Je kan wel overdrijven hoor.

[Reactie gewijzigd door WhatsappHack op 30 oktober 2014 15:01]

Bijvoorbeeld, via php kun je een script plaatsen waarme je de harde schijf kan bekijken en daarmee wachtwoorden kan vinden voor bijvoorbeeld root access (deze zijn encrypted opgeslagen, maar dat is te decrypten met bijvoorbeeld Johntheripper

Een simpel bestand maken dat login gegevens logt en via die gegevens op root niveau inloggen.

De database uitlezen en de beheerders account gegevens pakken.

Met de gegevens die via php beschikbaar komen, verdere structuur van de server uitpluizen en daar vervolgens andere exploits voor gebruiken.

Het is een domino effect.

Je kan die hele hdd niet uitlezen via php omdat een goed geconfigureerde server dat niet toestaat

ja een goed geconfigureerde server, die wordt ook op tijd gepatched in het algemeen...

Drupal heeft niets te maken met de back-end... Het is niet de taak van een serverbeheerder om de software die de klanten en/of webdesigners gebruiken up to date te houden.

Dus als men Drupal niet op tijd patched (al is 7 uur wel heel summier trouwens, tijdzone verschillen alleen al kunnen dan gelazer geven), betekent dat niet dat de server administrator ook een totaal malloot is.

Nee, dat kan niet. Dat gaat werkelijk enkel als er een zeer bizar slechte PHP configuratie aanwezig is. Daar moet je bijna je best voor doen om het voor elkaar te krijgen.

Wat jij beschrijft is enkel mogelijk als PHP als root draait, en nul komma nul beveiliging heeft. Als je als server administrator PHP als root draait, dan verdien je het gewoon om heel de server de pleuris in te zien draaien...

Is het niet vriendelijker van Drupal om een script vrij te geven die de md5-checksums van alle belangrijke files toont en de modified-date controleert?

Dat werkt wss niet lekker als mensen zelf wijzigingen hebben aangebracht. Ik weet ook niet of plugins bij Drupal eigenlijk core bestanden wijzigen of standalone draaien; in t eerste geval gaat MD5sum helemaal nooit werken.

De last modified date is te manipuleren, maarrrr het find commando is een prachtige tool om uit te vinden wat er veranderd is in de meeste situaties
Bijvoorbeeld, uit te voeren in de home directory van de user (virtueel /) (en niet enkel in de Drupal directory!! Dat omdat er ook elders in de account zooi gewijzigd of toegevoegd kan zijn!):

find . -mtime -15

(Recursief alle bestanden tonen die de laatste 15 dagen (sinds 15 okt. dus) gewijzigd zijn)
(Let op dat als je de patch uitgevoerd hebt je dus ook resultaten zal krijgen met dat commando... Aan de gebruiker dan maar te bekijken of dit binnen 7 uur na release was of niet.)

[Reactie gewijzigd door WhatsappHack op 30 oktober 2014 10:21]

De kans dat er aan je bestanden gesleuteld is, is minimaal vergeleken met wijzigingen in je database. Deze laatste zijn eenvoudiger te bewerkstelligen en kunnen net zo goed resulteren in de vangst van zeer veel gevoelige informatie.

nvm
Slechte zaak en doet de wens om hier iets met drupal te doen wel gelijk teniet.

nieuwe server te nemen

The fuck? Wie wil hierna ooit nog iets met drupal doen?

[Reactie gewijzigd door eL_Jay op 30 oktober 2014 09:43]

Van andere producten weet je niet eens of ze een dergelijk ernstig lek hebben. Drupal is er tenminste open over dat er een ernstig lek is en geeft aan wat te doen. Het zijn inderdaad wel rigoreuze maatregelen die genomen moeten worden. Wel meteen een mooie test van disaster recovery.

Hadden ze niet juist eerst het lek genegeerd? (nieuws: Gevaarlijke bug in Drupal 7 maakt cms gevoelig voor sql-injecties - update)

Een jaar geleden was het lek al gepost... Oke, het was bekend, maar niet een al te beste zaak.

Nee, niemand (althans, geen relevant iemand) heeft dat feature request onder ogen gehad.

Precies.

Ik heb zelf een aantal wordpress websites, maar afgelopen maand vond ik ook bestanden van hackers op mijn server. Ze hadden een mapje aangemaakt met bestanden en een bestand in de root. Een vriend van mij adviseerde om de bestanden gewoon te verwijderen. Er is niks aan te doen, omdat wp gewoon niet 100% veilig is. Maar ja, geen enkele website is 100% hack proof hoor! Dus prima dat Drupal dit noemt.

Edit: Ik kwam er overigens achter door Statcounter. Iemand vanuit Brazilie had dat mapje bezocht. Statcounter is echt geweldig wat dat betreft:-)

[Reactie gewijzigd door bh1967 op 30 oktober 2014 12:09]

Je kan hier goed wat aan doen: bestanden en dirs niet schrijfbaar maken voor de webserver om mee te beginnen. Ik weet dat je dan niet meer kan auto-upgraden, maar Wordpress moet ook eens ophouden met de gedachte hebben dat dat een goed idee is.

En, zet een .htaccess in de upload dir met:

<Files *.php>
ForceType 'text/plain; charset=UTF-8'
</Files>

Verder, zet een htpassword op wp-login.php en /wp-admin. Je kan zelfs in de announce message gewoon zetten: 'log in met foo/bar'. Op die manier ben je bots al voor. Je kan in je apache config een globale <Location> of <File> zetten die meteen alle wordpress installaties beslaat.

Edit:

zet dan meteen dit in de apache php.ini:

disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

[Reactie gewijzigd door halfgaar op 30 oktober 2014 14:37]

Mwoah curl kun je best nodig hebben de rest idd minder snel

Waarom zou je een nieuwe server nodig hebben?
Kan je niet beter de HDD's verwisselen en een backup van je gegevens terugzetten?

[Reactie gewijzigd door Elsandre op 30 oktober 2014 09:54]

In deze tijd van cloud en virtuele servers zou ik dat natuurlijk niet lezen als het moeten aanschaffen van nieuwe hardware. Maar je neemt een nieuwe instance, data overzetten en de oude afsluiten.

ik denk eerder dat het een beetje een vertaal fout is, want je kunt in principe er vanuit gaan dat je hardware safe is, tenzei je systeem heel toevallig last had van die uefi bug van pas, die ze via drupal hebben weten aan te vallen...

een nieuwe instalatie met een backup je gegevens, en een handmatige scan naar exploits moet voldoende zijn zou je denken. probleem is dat veel hobbyisten ook dit soort paketten veel gebruikt en die zie ik hun database nog niet napluizen op php code ed. die er niet thuis hoord...

een nieuwe instalatie met een backup je gegevens, en een handmatige scan naar exploits moet voldoende zijn zou je denken. probleem is dat veel hobbyisten ook dit soort paketten veel gebruikt en die zie ik hun database nog niet napluizen op php code ed. die er niet thuis hoord...

Dat zou ik niet zeggen. Volgens het artikel konden aanvallers code uitvoeren, dat betekent in principe dat ze de hele machine in handen hebben. Als je dat combineert met een slechte configuratie (bijvoorbeeld een webserver die als root draait) of een exploit in het OS, dan ben je helemaal de sjaak. Ik zou er zeker niet op vertrouwen dat een 'scan naar exploits' voldoende is.

Bovendien, zoals hierboven ook al genoemd wordt, is het in deze tijd een kwestie van een nieuwe VM aanzetten en daar je backup op zetten.

> een exploit in het OS, dan ben je helemaal de sjaak

Er zijn inderdaad aanwijzingen dat sommige aanvallers proberen via local privilege escalation systemen over te nemen.

Nee, nergens voor nodig,
(nieuwe server is ook niet nodig)

In principe kan dit bij elke web installatie die het toe laat om server commando's uit te voeren.
Dit is niet iets drupal specifiek, maar een kwestie van instellingen.

Als je geen shell commando's kan uitvoeren op je drupal installatie, wat bij de meeste webservers het geval zou zijn, dan kan je de database controleren en je folders om te kijken of er niks vreemd staat. Dit is nog steeds erg lastig omdat bijna niet is na te gaan of er ergens een backdoor in een module is gebouwd.

Als ze bijvoorbeeld de node module hebben gewijzigd kom je daar niet snel achter om deze module staat op bijna elke installatie aan. Het makkelijkst is om een oude installatie terug te zetten of als je een copy lokaal bewaart die terug te zetten.

Kijk ook of je geen rare content pagina's en blokken er tussen hebt staan, hoewel php niet standaard uitgevoerd kan worden is het in sommige gevallen toch mogelijk (de php filter module kan aan staan).

je kunt met FTP/SSH inloggen en dan naar de laatste wijzigingstijd (timestamp) kijken geloof ik.

Dat is volgens mij wel te spoofen

Als iemand je login credentials heeft ja, dan kun je met 'touch' die timestamps bijwerken ja. Anders word het lastig.

Met PHP's 'touch' kun je ook de timestamp aanpassen. Als men er dus in slaagt eigen PHP te plaatsen en uit te voeren, kun je gewoon de data aanpassen.

Zover ik weet is PHP's "touch" een wrapper om het UNIX shell commando 'touch' heen, iets wat op een goed geconfigde server gewoon netjes uitstaat (PHP shell_exec disablen)

Dat wijzigt enkel de mtime, de ctime blijft netjes staan.
Hierdoor kan je met bijvoorbeeld het stat commando toch nog kijken wat de werkelijke datums zijn. Of je find hier ook compatible mee kan krijgen weet ik niet uit m'n hoofd, straks es ff kijken.

Is natuurlijk niet zo afhankelijk van je drupal installatie maar meer van je php configuratie.

Met een slechte php configuratie en een gehackt Wordpress systeem heb je hetzelfde probleem.

nvm
Slechte zaak en doet de wens om hier iets met drupal te doen wel gelijk teniet.

Dan neem je een ander cms. Waar volgende week een lek in wordt gevonden.

Als beheerder van websites zul je nu eenmaal moeten accepteren dat er af en toe lekken worden gevonden en misbruikt.

Ik ben juist blij dat ze er zo open over zijn.

Leuk zo'n content management systeem. "Oeps, foutje, uhm... Zou u alles weg willen gooien en opnieuw willen beginnen? Hartelijk bedankt"

Ik snap ook wel dat het de schuld is van de systeembeheerder om niet te updaten, maar goed, dit is dan ook wel weer erg radicaal zullen we maar zeggen...

dit advies is dan ook alleen voor mensen die blindelings adviezen uitvoeren,

geen enkele zichzelf respecterende website beheerder zal dit uitvoeren, voordat hij er alles aan gedaan heeft op eigenkracht te achterhalen :

1 of die fout erin zit,
2 waarom hij zo stom is geweest niet direct te upgraden.

trouwen dat idee van die md5 is een prima idee. download (op een test machine) die betreffende versie en draai een md5 over alle bestandjes, en dan over je geinstalleerde versie... als er mee gekloot is merk je dat meteen...

dan is alleen je database nog gecompromiteerd maar die kun je volgens mij vrij makkelijk scannen op aanwezige code php of anders.

Zo stom was het niet hoor om niet direct te updaten. Hoeft normaal gesproken ook helemaal niet op stel en sprong. In dit geval had het wel gemoeten, zo blijkt nu. Maar het lek zat er van tevoren ook al in, dus de hackers hadden het 2 maanden eerder (of 1 dag voor de update) ook al kunnen doen.

Negen van de tien keer is het niet de verantwoordelijkheid van de serverbeheerder om de software die op de site draait te updaten.

Just sayin'
Die houden zich meestal bezig met de back-end, wat er aan de voorkant gebeurt is aan de designer/webbeheerder of aan de klant zelf. Dat laatste is waarschijnlijk t meest voorkomend...

Dat je een hoop comments moet doorlezen om tips voor herkenning te vinden, vind ik nogal euh slecht. Zelf heb ik een aantal Drupal-sites gelijk gepatchtt toen ik het bericht zag. Kreeg ik gister toch nog de security mail. Dan ga je toch weer twijfelen, maar nergens in de mail lees je goed waar je op moet letten.

Als er een ziekte uitbreekt, verspreiden ze toch ook informatie over de symptonen?

Zie het nou maar meer dat je immuunsysteem niet meer werkt en dat je vatbaar bent voor -alles-. Verder is er heeeel duidelijk aangegeven dat als je niet binnen ~7 uurtjes na de release het hebt gefixed, dat je bent gehacked. Men kan in feite alles doen, domweg de kleur van je website aanpassen, of bestanden toevoegen/verwijderen, je database injecteren of verwijderen. Als je ook nog eens verkeerde rechten aan hebt staan kunnen ze zelfs heel je server hebben overgenomen.

Je hoeft nergens op te letten, je moet gewoon weten dat je website naar de maan is, tenzij je heel snel was met updaten.

Eens, maar een paar tips (zoals hier gegeven) hadden niet misstaan: kijk in die en die tables, zijn er nieuwe users mee, zie je verdachte dingen et cetera

De initiele aanvallen hadden een signature waarbij de aanvallers een array in het usernaam veld van het loginformulier posten.

Dit leidt tot een tweetal warnings die je kan terugvinden in de error logs:

Warning: addcslashes() expects parameter 1 to be a string, array given in...
Warning: mb_strlen() expects parameter 1 to be string, array given in...

Als je die prepatch ziet heb je dus zeker een probleem.

Daarnaast zijn er echter andere manieren op SQL-i uit te voeren die niet leiden tot zo'n PHP waarschuwing.

Ook de gevolgen varieren sterk. Als je niks vindt, wil het nog niet zeggen dat je A-OK bent. Er zijn zoveel manieren om persistent access te verbergen.

Er is helaas geen easy fix, vandaar het advies.

"Reacties op je eigen reactie kan je niet modereren."

Nou, dan maar zo: dank je wel :-)

Wat bedoel je met "Als je die prepatch ziet heb je dus zeker een probleem."? De foutmelding? De term prepatch zegt me niks.

Als je die foutmeldingen in de error log ziet met een timestamp eerder dan dat je de update of de patch hebt toegepast, weet je dat er een exploit-poging gedaan is op een moment dat de site nog kwetsbaar was.

Denk er wel aan te corrigeren voor de eventueel afwijkende server timezone als je die tijden vergelijkt.

Ben ik wel met je eens. Het zou niet zo moeilijk moeten zijn om een beschrijving te geven. Helaas kan ik je ook niet helpen want ik gebruik helaas geen Drupal, wel Wordpress.