Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 39, views: 24.718 •

Mogelijk twintigduizend websites die gehost worden op Apache-servers zijn de afgelopen maanden ge´nfecteerd met malware. De toolkit genaamd Darkleech is nog steeds actief en onderzoekers hebben moeite de exacte werking te achterhalen.

Dit meldt Ars Technica op basis van een rondgang bij verschillende beveiligingsexperts. De eerste meldingen van de malware dateren al van augustus vorig jaar en onder andere het blog van Seagate en de site van The Los Angeles Times werden getroffen. Na besmetting van de Apache-server wordt code in websites op de systemen geïnjecteerd. De browser van bezoekers van die websites opent vervolgens heimelijk een verbinding met andere websites, die malware serveren.

Door de complexiteit van het programma is er echter nog steeds veel onduidelijk rondom Darkleech. Onderzoekers weten bijvoorbeeld niet hoe de kwaadaardige software zich op servers nestelt. Het zou via kwetsbaarheden in Plesk of Cpanel kunnen gaan, maar ook worden social engineering, het kraken van wachtwoorden en het uitbuiten van andere kwetsbaarheden niet uitgesloten. Onderzoekers van Cisco troffen bij een analyse de malware aan op meer dan tweeduizend webservers en schatten op basis daarvan, met de voorzichtige aanname dat zo'n server gemiddeld tien sites host, het totaal aantal geïnfecteerde sites op minstens twintigduizend.

Het onderzoek naar de malware wordt bemoeilijkt doordat niet makkelijk is vast te stellen hoeveel en welke sites er precies geïnfecteerd zijn. Darkleech serveert namelijk niet aan alle bezoekers kwaadaardige links. De malware lijkt ip-adressen te filteren en adressen afkomstig van hostingbedrijven en beveiligingsfirma's zijn geen doelwit. Ook bezoekers die recentelijk het slachtoffer van een aanval waren of op de betreffende website kwamen via specifieke zoekopdrachten lijken niet getroffen te worden. Darkleech is daarnaast in staat om unieke links die het bezoekers serveert, te genereren.

Het verwijderen van de malware blijkt ook lastig. De malware wijzigt onder andere na besmetting de ssh-binaries op servers. Hierdoor kunnen ze op afstand de authenticatie van de systemen omzeilen en ook bestaande authenticaties onderscheppen. Daarnaast slagen aanvallers er mogelijk in om hun toegang te herstellen na het verwijderen van de kwaadaardige modules via backdoors en rootkits. Overigens is de Darkleech-module zelf niet nieuw: eind september werd hier al melding van gemaakt en toen was de claim al dat de software al twee jaar oud was.

Reacties (39)

Reactiefilter:-139039+133+210+30
Enige oplossing lijkt een reinstall van de complete distro.

(edit: ok, op een nieuwe schijf zodat je bootloader rootkits eruit haalt. Of SecureBoot gebruiken zodat je weet dat het bootproces clean is)

[Reactie gewijzigd door Dreamvoid op 3 april 2013 12:09]

Als er sprake is van een rootkit dan is dat jammergenoeg ook niet voldoende.
Als er sprake is van een rootkit dan is dat jammergenoeg ook niet voldoende.
Een rootkit nestelt zich typisch in het OS, dus een clean herinstall van het OS (vanaf trusted media) is dan natuurlijk wel voldoende. Je moet dan alleen gegevens die je terugzet uit een backup goed controleren.

Het enige waar een clean herinstall niet tegen kan helpen is als de rootkit zich in firmware (zoals de BIOS/EFI) nestelt. Maar volgensmij gebeurt dat (nog) niet echt in het wild. Mocht ik me daar in vergissen, dan laat ik me graag corrigeren :)
Julie vergeten dat de originele install in de eerste plaats wel gehackt was, en dus zolang je de oorzaak of het gat niet kent kan 'ie zo weer geinfecteerd zijn. Zeker als het automatisch (bv. worm) gebeurt.
Als de rootkit in de bootloader zit, dan kan het ook een herinstall overleven (als je bij installatie niet ook de bootloader herinstalleert).
Tja, maar wie weet heb je dan binnen de kortste keren opnieuw die malware op je server?
Dan vraag ik me af: hoe weet ik of mijn server besmet is?

Ik gok dat als SSHD aangepast is, dat de enige betrouwbare manier is om de server met een USB rescuekit te starten en dan bepaalde bestanden te controleren, zoals de SSH daemon?

[Reactie gewijzigd door Trolando op 3 april 2013 11:42]

In het originele artikel staat hierover het volgende: "The injected HTML iframe tag is usually constructed as IP address/hex/q.php. Sites that deliver such iframes that aren't visible within the HTML source are likely compromised by Darkleech."

Misschien dat je het met deze informatie kunt vaststellen of je site besmet is?
Doet me denken aan veel "linkendIn" spam die ik een tijdje geleden kreeg


mischien nog wel, maar sinds ik de spam filters heb gefixed nooit meer eigenlijjk

[Reactie gewijzigd door fish op 3 april 2013 14:29]

niet lang geleden was LInkedIn gehakt en zijn er een groot deel van de e-mailadressen van de gebuikers buitgemaakt. Ik denk dat je via daar zoveel spam krijgt en heeft niet zoveel te maken met deze malware.
niet lang geleden was LInkedIn gehakt
Naar mijn weten komt gehakt bij koeien en varkens vandaan...

Gehacked bedoel je ;)
rpm --verify voor een rpm based distributie of debsums -c op een debian based systeem. Als ook de apt of rpm database besmet is kun je altijd het package re-installen uit de repository.


edit: dit was een reactie op de SSH vraag. Een re-install van de httpd packages kan natuurlijk ook, maar het is maar zeer de vraag of dit ook een "besmetting" ongedaan maakt, vooral als het lek niet in apache zit :)
Hopen dat ze snel de oorzaak vinden en het gat dichten (waar het ook zit)

[Reactie gewijzigd door nehru op 3 april 2013 11:51]

Als er werkelijk een rootkit actief is, dan is rpm verify ook verdacht - alles wat het draaiende systeem je vertelt is onbetrouwbaar, een rootkit kan alles injecteren wat hij wil. Je zal de HDD moeten mounten vanaf een 'vertrouwd' systeem en een checksum op alle executables/libs (kernel, etc) moeten uitvoeren.

Het zekerste is de (virtuele) server opnieuw opbouwen, en niet te vergeten: nieuwe account passwords aanmaken, en evt gaan nadenken over SELinux.

[Reactie gewijzigd door Dreamvoid op 3 april 2013 12:04]

Dus om the checken of de sshd binary nog in orde is: voor Red Hat/CentOS/Fedora installaties; start met een installatie CD, ergens in het begin van het installatie proces kun je een shell starten (ALT+F2) en dan iets als:

chroot /mnt/sysimage
rpm -qV openssh-server


Uitgebreide informatie is op de site van Red Hat te vinden.
http://urlquery.net/

Die vindt deze besmetting wel. En kan je overal draaien.
Ik neem aan dat deze malware zijn ip filter lijst regelmatig update, binnen de kortste keren wordt deze tool daarmee onbruikbaar of zelfs gevaarlijk als er blind vertrouwen ontstaat...
Als dit alleen een apache hack is, hoe worden dan de SSH binaries aangepast? Apache draait altijd in haar eigen user, apache, en je hebt wel echt iets fout gedaan als deze de SSH binaries mag aanpassen.
http://blogs.cisco.com/se...he-darkleech-compromises/

"Dubbed “Darkleech,” thousands of Web servers across the globe running Apache 2.2.2 and above are infected with an SSHD backdoor that allows remote attackers to upload and configure malicious Apache modules. These modules are then used to turn hosted sites into attack sites, dynamically injecting iframes in real-time, only at the moment of visit"
Nooit gehoord van de term "remote root exploit". Het zou wel heel erg zijn als er hiermee ÚÚn in Apache gevonden is en dat verwacht ik ook niet maar ook met user rechten kan een handig iemand in staat zijn om gebruik te maken van een ander lek waardoor alsnog root toegang kan worden verkregen.
Apache draait altijd in haar eigen user, apache
Da's het hele idee van een exploit, dat een aanvaller een applicatie dingen laat doen die het niet zou mogen.
Nee, apache kernel draait (start) altijd als root (anders kan het geen porten onder 1024 claimen) en daarna worden de child processen gestart welke onder een beperkte user draaien en ook de kernel draait grotendeels onder deze user.

Maar Apache codebase bestaat niet uit 10 regeltjes. De schrijvers van de malware hebben waarschijnlijk een bug ondekt waarmee zij via een child met de apache-kernel en het root apache proces kan communiceren.. Dat is alleen mogelijk via een (extreme) dubbele exploit.

De verdenking dat de exploit in een vserver zoals plesk zit is dan ook niet zo raar. Via een webinterface kun je namelijk verschillende systeem wijzigingen aanbrengen. Die wijzigingen worden op de achtergrond doorgevoerd en ik vermoed dat de infectie dan ook plaats vind via een dergelijke command queue. Die command queue draait vaak wel met hoge rechten om bijvoorbeeld users (home, mailbox, etc) aan te maken. Dat zijn taken welke een standaard apache user niet kan (terecht!).

Een exploit in een vserver pakket zou dan ook verklaren waarom het aantal infecties erg laag is. Apache serveert ruim de helft van alle websites op het internet. Bij een exploit in de originele apache code had het infecties veel hoger geweest..

een andere mogelijk is dat een apache variant van een distributie vatbaar is. Maar die kans is erg klein omdat wijzigingen aan core Apache packages zeer goed gecontroleerd en getest worden bij alle bekende distributies..
Maar die kans is erg klein omdat wijzigingen aan core Apache packages zeer goed gecontroleerd en getest worden bij alle bekende distributies..
Het is makkelijk om hier cynisch over te doen, maarre...dat hebben we vaker gehoord.
Als je eenmaal binnen bent met 1 user, kun je vervolgens gaan kijken of je niet 'elevated privileges' kunt krijgen via bekende bugs in bvb. de kernel. Daarom is regelmatig patchen ook zo belangrijk, zowel van de kernel als van software pakketten die je misschien op een specifieke server niet gebruikt.

Op die manier kun je voorkomen dat als ze al binnen zijn bvb. via apache, dat het nog lastig wordt om vervolgens die inbraak uit te buiten.
Het probleem is ook niet Apache, maar een hack via andere mogelijkheden. In het artikel worden al hacks in Plesk en cPanel genoemd, maar je kunt ook gewoon met een trojan de opgeslagen FTP wachtwoorden ophalen van klanten bij een willekeurige webhost, bestandjes uploaden en vervolgens gaan kijken of er nog iets te hacken valt op zo'n server. Een verouderde kernel met local root exploit is dan voldoende om root te krijgen, en vervolgens hack je gewoon apache en voeg je een module toe die random dingen aan uitgespuugde HTML toevoegt.
Dat staat er niet:
Vulnerabilities in Plesk, Cpanel, or other software used to administer websites is one possibility, but researchers aren't ruling out the possibility of password cracking, social engineering, or attacks that exploit unknown bugs in frequently used applications and OSes.
Maw, ze weten het niet. Misschien zijn het lekken in Apache, misschien in andere applicaties. Enige wat ze tot nu toe hebben gezien is dat het tot nu toe alleen servers met Apache zijn die besmet zijn, en geen servers met Nginx of IIS - dat hint naar een lek in Apache of Apache-specifieke tools.

[Reactie gewijzigd door Dreamvoid op 3 april 2013 12:25]

Of zoals Trolando impliciet schrijft: het is geen Apache hack. Er wordt eerst root acces verkregen tot de server waarna er een bepaalde module (die je blijkbaar voor $1000 online kan kopen) wordt ge´nstalleerd in de Apache software.

Root access wordt dus verkregen op een andere, niet-gedefinieerde, wijze, maar vermoedelijk via onbeveiligde administration panels zoals cPanel en Plesk omdat er blijkbaar veel hosters ge´nfecteerd zijn en niet zoveel corporate servers.
Met de symtomen die hier beschreven zijn lijkt het erop dat ik hier ook last van heb gehad. Is rond januari gebeurd. Op server draai ik ongeveer 25 klanten. Ik kreeg via WhatsApp een berichtje dat mijn server malware leek te serveren.
Naar website toegegaan (javascript disabled) en zag dat dit inderdaad het geval was.

Smiddags eerst een check gedaan. Hier gebruik gemaakt van scanner: http://sitecheck.sucuri.net/scanner/
Deze detecteerde inderdaad dat er malware werd geserveerd.

Daarop alle website bij langs gegaan en de javascript verwijderd.
De javascript wordt in zowel .php, als .js als .tpl files aangepast.

De malware stond bij mij bekend als Trojan-Downloader.JS.Iframe.dcc of Trojan.Script.Iframer
Wat werd toegevoegd was begin van een hashcode. (Zie: http://www.webcurve.nl/ni...t-op-ftp-sidename-js.html en http://www.webcurve.nl/ni...-code-in-sidename-js.html)

Wat ik heb geconstateerd is dat in dit geval er gewoon via FTP is ingelogd. Mijn SSHD lijkt zover bekend niet te zijn aangepast. Wellicht dat men hier nog wat aan heeft.
Dat lijkt op een ander virus, dat ik ook een keer ben tegengekomen. Dat virus luistert FTP-gegevens af en speelt die door, zodat de eigenaren het virus weer op jouw servers kunnen zetten. Best sneaky, en behoorlijk gevaarlijk, maar ik denk dat het een andere is.
Ja het zou maar zo kunnen. Het is ontzettend vervelend. Ik zat beetje in dubio om het te posten. Maar stel dat iemand dit nog tegenkomt dan hebben we er wat aan. (zitten toch met bijna alleen maar tweakers en paardenliefhebbers _/-\o_ :+ )
Daarnaast lijkt het erg veel op elkaar, misschien zelfde makers?
en hiervoor heb je dus spamhaus en mod-security.
Geen last van deze dingen.

Als er getracht wordt op dergelijke links te openen wordt de boel gewoon geblokkeerd.

Bedankt Spamhaus !! ( en zeker ook mod-security )
Questie van de boel goed opzetten en up2date houden.
en hiervoor heb je dus spamhaus en mod-security.
Geen last van deze dingen.

Als er getracht wordt op dergelijke links te openen wordt de boel gewoon geblokkeerd.

Bedankt Spamhaus !! ( en zeker ook mod-security )
Questie van de boel goed opzetten en up2date houden.
Spamhaus is met name voor e-mail, wat dat met een webserver van doen heeft, geen flauw idee. Mod-security is interessant, ik ga eens kijken of ik die in de CentOS repositories kan vinden. :)
spamhaus kan zeker wel wat doen: http://sourceforge.net/projects/mod-spamhaus/
Ik heb ook mod-security voor apache, maar dat is toch wel een redelijk trigger happy systeem. Ook legitieme aanvragen worden ook opeens geblokkeerd, dus delen heb ik uit geschakeld.

Verder kun je altijd BulletProof security gebruiken op je wordpress site: http://wordpress.org/extend/plugins/bulletproof-security/ Die via .htaccess een groot aantal aanvallen tegen kan houden.

Verder zijn er ook andere wordpress plugins die de bad-guys kunnen blokkeren.
(edit, even een lijstje voor de ge´nteresseerde)
  • Akismet
  • Bad Behavior
  • Login LockDown
  • Stop Spammer Registrations Plugin
  • Wordpress Sentinel
Wordpress sentinel is ook een van mijn favorieten, die verifieert de website bestanden. Helaas stuurt hij geen mail als er iets is aangepast. Op mijn oude host merkte ik af en toe dat er een backup was terug gezet, aangezien ik mijn eigen backup maak iedere week kon ik zo toch weer bestanden herstellen :)

Als dat nog niet heeft gewerkt heb ik nog suhosin, wat wel beperkte beveiliging oplevert.
De apache server is gechroot, en er zit een app-armor profiel op.

en verder staan er geen poorten open eigenlijk dus ook geen ftp of ssh :P
Die heb ik weer op een speciale manier ter beschikking gesteld ;)

[Reactie gewijzigd door wootah op 3 april 2013 13:41]

Die heb ik weer op een speciale manier ter beschikking gesteld ;)
port knocking?
Nee, geen security through obscurity hier ;)
Denk eerder aan een VPN ;)
Ik was al benieuwd of mensen dat nog deden.
Je hebt het toch hopelijk toch geen mchap in gebruik?
Mod-security voor IIS is in ieder geval bijzonder slecht gedocumenteerd en maakt de werking van normale asp.net sites met de basis of "core" rules onbetrouwbaar ...

Waardeloos stukje software dus, zal het eens proberen op enkele linux servers. Waarschijnlijk is het daar beter ontwikkelt.
Ik heb onmiddellijk mijn beide webhosts gecontacteerd en bevestiging gevraagd dat ze de security bulletins tijdig opvolgen en recente versies gebruiken van hun controlpanels (respectievelijk cPanel en DirectAdmin). Ik wil niet dat mijn website aan mijn bezoekers malware zou afleveren doordat een hosting company onzorgvuldig omspringt met beveiliging...
wat een geneuzel over die packages. In dreamwaver geef ik een dos_prom comando en packages laden automatisch in VM naar de klusteromgeving in de Cloud. De commandqueu kan je zo via VPN zo open zetten dat van queing geen sprake meer is en packages voor alle IP adressen op het netwerk ook zo zijn te benaderen.
Pakt tripwire dit niet op?? En kan rootkithunter (of die ander ben de naam kwijt dit niet aanpakken?)

Staat me iets van bij dat je uit een apache webserver kan container of chrootomgeving kan breken door pathnames die je moet veranderen.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013