Bekijk Volledige Versie : Hacked / virus?
Kwam dit tegen op een site van een klant van me (hosting elders). Iemand enig idee wat de oorzaak kan zijn, wat ik zo snel kan zien is dat het alle sites betreft op die server.
Vraag het aan deze illustere meneer zelf, hij zet toch niet voor niets zijn email erbij?
Het is overigens maar de vraag of zijn server "rooted" is. Vaak is het gewoon de index.html/php die aangepast is omdat ze het ftp password hebben gesnift (wie gebruikt er dan ook nog ftp?).
Oordeel zelf;
http://www.google.nl/search?hl=nl&q=Q8+h4x0r&meta=&aq=f&oq=
Het lijkt erop alsof die alleen wil aantonen dat je site niet veilig is. Op andere sites zie ik dat hij alleen de index pagina heeft aangepast en geen files of back-ups heeft gedelete.
Misschien kan je contact met hem opnemen, dan geeft die jou vast advies hoe beter je site te beveiligen.
Heb net een aantal pagina's bekeken wat de "Q8 h4x0r" gehacked heeft.
Het viel me al snel op dat hetvoornamelijk SQL injecties en XSS (cookie theft) en dergelijke waren.
Toevallig trof ik ook nog een aantal irc botjes aan op een niet nader te noemen irc netwerk waar ik een aantal hosts / ip / rdnsjes terugvond in google.
Het irc netwerk zit ram vol idiots wat massaal aan RFI scanning doen.
Happy patching.
Ik zie voornamelijk .php zaken met pad/bestand URL-parameters (RFI scanner (*)). Vereist dat niet iets als ingeschakelde register_globals en/of ingeschakelde allow_url_include()? Juist twee zaken die verplicht uitgeschakeld moeten zijn...
(*) RFI : Remote File Inclusion? (heb een beetje een off-day, ben er niet helemaal bij)
Heb contact gehad met de provider, blijkbaar waren er ook logs gewist. Niet echt iets wat je via SQL injection of XSS doet in mijn ogen.
Ben in ieder geval blij dat ik de puinhoop niet hoef op te ruimen :lovewht:
En je/jij/u bent sys admin ?
(*) RFI : Remote File Inclusion? (heb een beetje een off-day, ben er niet helemaal bij)
Correct.
Programmeur / hobby matig systeembeheer
Heb contact gehad met de provider, blijkbaar waren er ook logs gewist. Niet echt iets wat je via SQL injection of XSS doet in mijn ogen.
Ben in ieder geval blij dat ik de puinhoop niet hoef op te ruimen :lovewht:
Via RFI kun je vrij simpel een connect back binary uploaden naar /tmp en executen (standaard fstab config, dus geen noexec enz) , en tadaa de attacker heeft toegang onder user apache (mits ze geen suphp draaien)
Maar hij/zij kan ook simpelweg een phpshell geupload hebben en zo het e.e.a gesloopt hebben om lokaal access te verkrijgen...
En zo zijn er nog 1000 manieren om via RFI iets op een lekke doos te doen.
Als de hosting provider al geen logs meer aantreft, dan is die doos simpelweg geroot met een lokaal exploitje wat de attacker beslist op milw0rm gevonden heeft :clown:
Happy reinstalling (headbang)
Ok, bedankt voor de info! Alle websites draaide gisteravond weer dus mn klant is weer tevreden. Echter vraag ik me af of het lek nu gedicht is.
Lijkt me niet dat het lek gedicht is, normaliter kunnen normale gebruikers (lees, die niet in sudoers staan) geen logs verwijderen c.q aanpassen.
Dus, draai chkrootkit, check /tmp en /var/tmp, de desbetreffende user zijn dir, controleer .bash_history (of whatever welke shell hij gebruikt) en apache/lighttpd's access & error logs, controleer of er geen ranzige backdoor draait (netstat) en activeer een vuurmuur met ids ( http://www.configserver.com/cp/csf.html )
Van de week had ik ook aan klant, die had JOOMLA een vergelijkbaar probleem
Sterker nog de klant was vergeten de complete installatie mappen en bestanden te verwijderen.
Toch hebben wij voor de zekerheid de server na gekeken of alles wel goed dicht is
Vaak gebeurt het ook door onkundigheid van de gebruiker