Joomla sites gehacked

[Wildfire]

Crap... ik wou net gaan dutten, checkte nog ff m'n mail. Kreeg ik een mailtje van een collega, onze sites waren gehacked. En ja hoor...



Het kloterige is, ik weet niet *waardoor* we hackbaar zijn.

Het gaat hier om een site met Joomla 1.5.15 met als toevoegingen JCE en CKForms (beide afgelopen week nog up-to-date gebracht (JCE v1.5.7, CKForms v1.3.4). Misschien dat iemand enig idee heeft adhv de screenshot? Ik neem aan dat het een of andere exploit is, sinds afgelopen week is het namelijk raak. Eerst dachten we CKForms, we hadden een oudere versie die een SQL Injection exploit had dus die is snel van een update voorzien. Maar toch, wederom raak.

Redelijk snel omheen gewerkt nu door via .htaccess automatisch naar index.php te rerouten zodat index.html niet wordt gebruikt (kan nu zo snel ff niet bij een back-up van de site).

Crapzooi. Bah...

-- Edit: die klojo schijnt een soort blog te hebben, http://trsniper-r00t.blogspot.com/

[ Voor 4% gewijzigd door Wildfire op 26-04-2010 01:04 ]

[Hertog]

Wildfire schreef op maandag 26 april 2010 @ 01:00:
Eerst dachten we CKForms, we hadden een oudere versie die een SQL Injection exploit had dus die is snel van een update voorzien. Maar toch, wederom raak.

Zijn na die eerste hack alle wachtwoorden veranderd en alle accounts gecontroleerd?

[wow7]

Ik zou eerst maar eens in je logs kijken als je daar bij komt , ook .htacces eens aanmaken en modrewite gaan gebruiken bv http://www.reference.joomlademo.de/htaccess.txt.source.html om de meeste exploit verzoeken te voorkomen , ook kijk eff naar de datums van de files in je folders , ergens staat er wel een backdoor denk ik nu.

Dit zijn maar een paar tips.

[Wildfire]

wow7 schreef op maandag 26 april 2010 @ 01:09:

Ik zou eerst maar eens in je logs kijken als je daar bij komt , ook .htacces eens aanmaken en modrewite gaan gebruiken bv http://www.reference.joomlademo.de/htaccess.txt.source.html om de meeste exploit verzoeken te voorkomen , ook kijk eff naar de datums van de files in je folders , ergens staat er wel een backdoor denk ik nu.

Dit zijn maar een paar tips.

Die .htaccess hadden we al en mod_rewrite ook. Na de CKForms exploit hack is het wachtwoord van de FTP veranderd en in Joomla is de administrator van een andere naam en wachtwoord voorzien.

In de root van één van onze twee sites waren nu twee bestanden bijgekomen cz.pl en sadrazam.pl

In de cz.pl was de omschrijving "CGI-Telnet Version 1.0 for NT and Unix : Run Commands on your Web Server". Da's niet goed natuurlijk. En in de sadrazam.pl zag ik "r57pws.pl - Perl Web Shell by RST/GHC".

Beide meteen removed natuurlijk.

-- Edit: hmmm, ik zie dat de /tmp mappen op beide sites public schrijf- en uitvoerrechten hebben. Lijkt me niet gezond, meteen verwijderd.

-- Edit #2: kan het ook aan de serverconfig liggen? Onze hoster heeft op de desbetreffende server bv. nog steeds PHP4 draaien (4.4.4-8+etch6). Ik zie ook dat de PHP safe mode uit staat.

-- Edit #3: op de site waar die cz.pl en sadrazam.pl stonden, stond in de /tmp een dc.pl "ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE"

Als ik het goed begrijp een backdoor methode voor de server, die wij dus niet in eigen beheer hebben. Klopt het dat dit een serverhack is, waardoor men op sites kan komen die erop draaien?

-- Edit #4: de serverbeheerder geeft aan de server up-to-date zou zijn en dat andere op deze server gehostte sites geen problemen hebben en de betreffende bestanden ook niet daar zijn aangetroffen.

-- Edit #5 (gaat lekker met het niet binnen 24h nieuwe post te mogen doen): we gaan vandaag over naar een nieuwe server met PHP5. Daarnaast gaan we alle wachtwoorden ook nog een keer wijzigen. Ik ben benieuwd of alles nog goed werkt daarna... maar goed, zowel de hoster als wijzelf hebben een 1:1 backup van de site inclusief de database, mocht het nodig zijn.

[ Voor 57% gewijzigd door Wildfire op 26-04-2010 12:48 ]

[wow7]

Het kan zelfs zijn dat de exploit ergens op een ander domain staat en dat de hacker gewoon root access heeft , het hoeft zelfs niet eens meer op een ander domain te staan als er al ergens eval code in de root is die gewoon via telnet te bereiken is , de perlcode wijst er zeker op dat telnet access als root uitgevoerd kan worden , dus erg slim is de hoster zeker niet.

Een exploit kan via velen manieren gedaan zijn , het is dan ook raadzaam dat de hoster dat mede onderzoekt.
SafeMod Uit is ook een slechte zaak en PHP4 kent nog wel een paar backdoors dus ook dat is niet onmogelijk , ik zou ook je code van de site zelf checken want ook daar kan eval code in staan meestal een zend stukje of een js link ergens naar een trojan die dan weer op de server geplaatst word er zijn zat mogelijkheden, dus ik zou zekers de hele rommel na kijken.

[Wildfire]

wow7 schreef op maandag 26 april 2010 @ 13:53:
Het kan zelfs zijn dat de exploit ergens op een ander domain staat en dat de hacker gewoon root access heeft , het hoeft zelfs niet eens meer op een ander domain te staan als er al ergens eval code in de root is die gewoon via telnet te bereiken is , de perlcode wijst er zeker op dat telnet access als root uitgevoerd kan worden , dus erg slim is de hoster zeker niet.

Een exploit kan via velen manieren gedaan zijn , het is dan ook raadzaam dat de hoster dat mede onderzoekt.
SafeMod Uit is ook een slechte zaak en PHP4 kent nog wel een paar backdoors dus ook dat is niet onmogelijk , ik zou ook je code van de site zelf checken want ook daar kan eval code in staan meestal een zend stukje of een js link ergens naar een trojan die dan weer op de server geplaatst word er zijn zat mogelijkheden, dus ik zou zekers de hele rommel na kijken.

Als straks de site is overgezet naar een nieuwe server dan mik ik sowieso Joomla er nog eens overheen zodat alle Joomla bestanden in ieder geval weer gelijk zijn aan wat ze horen te zijn. Daarnaast gaan alle relevante wachtwoorden veranderd worden en ik ga kijken naar de mogelijkheid voor een site-in-de-gaten-houden scriptje. Via Joomla.org zag ik al wat mogelijkheden, zaken die als cronjob gescheduled kunnen worden en die veranderingen aan de site meteen melden.

Ik ga de serverbeheerders ook wat info doorsturen over de exploits die we hadden, links en rechts worden die in relatie gebracht met diverse server beveiligingslekken enzo dus daar moeten ze toch zeker ook eens naar kijken.

[Wildfire]

Nou, wat is er dus veranderd is in totaal:

- Sites overgezet naar nieuwe server met PHP5;
- Nieuw FTP-adres;
- Nieuw FTP password;
- Ander adres voor databaseserver;
- Admin usernames/passwords voor beide sites aangepast;
- Database wachtwoorden allemaal aangepast;
- Joomla 1.5.15 full install over beide sites heengegooid (excl. de INSTALLATION map natuurlijk en de reeds door ons aangepaste robots.txt ook behouden na controle op inhoud) zodat alle Joomla bestanden 100% zeker origineel zijn.

Ik heb ook beide sites even volledig lokaal overgezet en met Avast, Malwarebytes, Asquared Free, AdAware, Spyware Terminator en SUPERAntispyware gescanned. Niets gevonden.

Op onze hoofdsite hadden we maar extensies/plug-ins voor Joomla en die zijn allen up-to-date. Op de andere site ben ik nog bezig, meeste oude crap is al gedelete omdat het niet meer gebruikt wordt.

Oh, en aangezien we nu uiteindelijk PHP5 hebben: Akeeba Backup geinstalleerd en gebruikt. Full site back-up met full database back-up. Ideaal.

[ Voor 7% gewijzigd door Wildfire op 27-04-2010 14:47 ]

[LuckY]

Ik heb ook beide sites even volledig lokaal overgezet en met Avast, Malwarebytes, Asquared Free, AdAware, Spyware Terminator en SUPERAntispyware gescanned. Niets gevonden.

Kan je niet beter manueel even de code doorlezen of je geen rare dingen tegenkomt. Want die scanners vangen natuurlijk geen backdoors af alleen maar mogelijke links naar bekende exploit sites.
Ik weet niet om hoeveel regels code het gaat, maar het lijkt mij raadzaam

[Wildfire]

LuckY schreef op dinsdag 27 april 2010 @ 14:56:
[...]

Kan je niet beter manueel even de code doorlezen of je geen rare dingen tegenkomt. Want die scanners vangen natuurlijk geen backdoors af alleen maar mogelijke links naar bekende exploit sites.
Ik weet niet om hoeveel regels code het gaat, maar het lijkt mij raadzaam

Het is een Joomla site, en aangezien ik de full install van Joomla op beide sites opnieuw heb geplaatst zijn iig alle Joomla bestanden weer origineel en dus schoon (ja, ik heb bij het uploaden alle bestanden op de server laten overschrijven).

De de door ons aangepastte of toegevoegde bestanden zijn al geverifieerd als zijnde niet aangepast en nog origineel.

Helaas wordt het een k*tklus als ik alle mappen zou willen nasporen naar bestanden die er niet zouden horen... alhoewel het voornamelijk om Perl-bestanden zou gaan, dat is wat ik de vorige keer in de root en in /tmp aantrof. Dat is eenvoudig filteren op .pl bestanden aangezien we daar zelf geen gebruik van maken.

[ Voor 5% gewijzigd door Wildfire op 27-04-2010 15:12 ]