Firmensite gehackt - was machen?

B

Benedict

Angesehenes Mitglied
Hallo,

als ich eben auf meine Firmensite geschaut habe musste ich erschreckender Weise feststellen, dass die Site gehackt worden ist.
Was mache ich nun?
Kann man sowas anzeigen?

Auf der Site steht folgendes:

QUOTE Your SyStem Hacked By Real_Karizma ~ DeathSyStem

./RooT

Thanks y soyletmez

Real_Karizma says : Türk Milleti İçin Burdayız !¿



Contact : real_karizma@hotmail.fr

..::| FOR iSLAM ~ FOR TURKEY|::..

©Turkish & Muslim Attackers

real--karizma.blogspot.com

Copyright 2008-2010 ©



Gruß,
Benedict
 
hat uns auch erwischt. Sind wohl beim gleichen Hoster :) Server 12.... hab zum guten glück nicht viele sites dort laufen... wegen dem elenden joomla wurde der ganze Server versäucht und alle nicht joomla Kunden werden ebenfalls bestraft. Hab schon immer gesagt, dass Joomla der letzte Müll ist.

Was kann man dagegen machen? Anzeige kannst vergessen. Für die Zukunft am besten einen eigenen (managed, unmanaged oder virtualaisierten) Server verwenden, wo man weiss, was sonst noch drauf läuft.... Wenn dann etwas passiert, weiss man wenigstens, dass man selber der Grund war.

Und an alle Firmen und Organisationen, die Joomla einsetzen wollen: Lasst die Finger davon, wenn ihr nicht die Zeit und Lust habt ständig das System zu patchen!

Grüsse

Martin
 
Martin H;
Diese Aussage kann ich so NICHT unterschreiben. PHP lässt sich auch so aufsetzten/betreiben, dass die einzelnen vHosts untereinander keine Zugriffsmöglichkeit haben - z.B. mit suPHP. Ist halt resourcenfressender und somit meistens wenig verbreitet im Tiefpreissegment
wink.gif


Das eine Kundenseite durch eine bekannte Lücke "gehackt" wird (betrifft nicht nur joomla) - ist leider keine Seltenheit. Bei uns z.B. gabs aber bisher noch keinen Fall wo dadurch auch andere Accounts oder gar Systeme betroffen waren.



Zum Thema;
Gehackte Seite sichern - und schnellstmöglich eine Dummyseite aufschalten damit keine Kunden abgeschrekt werden. Danach erst dem Problem ausführlich auf den Grund gehen und die "normale" Seite aufschalten wenn die Ursache behoben.
 
QUOTE (Alonso @ Do 11.02.2010, 12:42) Martin H;
Diese Aussage kann ich so NICHT unterschreiben. PHP lässt sich auch so aufsetzten/betreiben, dass die einzelnen vHosts untereinander keine Zugriffsmöglichkeit haben - z.B. mit suPHP. Ist halt resourcenfressender und somit meistens wenig verbreitet im Tiefpreissegment
wink.gif


Das eine Kundenseite durch eine bekannte Lücke "gehackt" wird (betrifft nicht nur joomla) - ist leider keine Seltenheit. Bei uns z.B. gabs aber bisher noch keinen Fall wo dadurch auch andere Accounts oder gar Systeme betroffen waren.



Zum Thema;
Gehackte Seite sichern - und schnellstmöglich eine Dummyseite aufschalten damit keine Kunden abgeschrekt werden. Danach erst dem Problem ausführlich auf den Grund gehen und die "normale" Seite aufschalten wenn die Ursache behoben.

Tatsache ist, dass man es endlos von Joomla hört! Bei keinem anderen Opensource Produkt gibt es dermassen viele Security Issues... Wenn das System oder einzelne Module standardmässig nur korrekt laufen, wenn gewisse sicherheitssensitiven Serverkomponenten installiert oder nicht installiert sind, dann liegt das an der Architektur und Guidelines von Joomla... Kann ja nicht sein, dass man den Server komplett freigeben muss, dass ein CMS funktioniert und im Gegenzung eine Zusatzkomponente (suPHP) benötigt, damit es dann wieder sicher ist??

Klar, kann man ein Joomla sicher betreiben. Es kann aber wiederum nicht sein, dass das Produkt auf Anfänger losgelassen wird und auch als gutes CMS für Anfänger kommuniziert wird und anschliessend muss man ein Server- oder Unixexperte sein um das Ding halbwegs stabil zu betreiben.

:)

Grüsse

Martin
 
Joomla ist halt auch extrem verbreitet. Versteh mich nicht falsch - ich bin auch kein Freund von Joomla - dennoch finde ich den Joomla-Core relativ gut, sicher und brauchbar.

Bei den ganzen Plugins die aus der Community kommen siehts dagegen leider etwas anders aus. Diese sind qualitativ teilweise extrem mager. Wenn du die ganzen Security-Issues mal genauer analysierst sollte sich diese Aussage auch entsprechend bestätigen.

Für den Laien ist es zugegebenerweise fast unmöglich zu beurteilen wie gut und sicher nun ein entsprechendes Plugin ist.

Was sicherlich nicht passieren darf ist - dass eine Lücke auf einer Kundenseite gleich den ganzen Server - bzw. zumindest andere Accounts ruiniert. Dieser Punkt ist absolut unabhängig von verwendeten System - das ist schlichtweg verantwortungslos vom Betreiber des Servers.
 
Mal abegesehen von eine paar grafischen Anpassungen habe ich auch nichts mit joomla zu tun. Allerdings scheint es da wirklich ein paar eklatante Sicherheitslücken zu geben, die einigen bösen buben bekannt sind.

Ich selber habe einige Joomla-Seiten aufgehübscht die innerhalb von Monaten nach der Fertigstellung gehackt und zerstört wurden. Ich rede hier allerdings von ca 4 gehackten von 10 erstellten Seiten. Eine erschreckende Quote!!!

Gruß Ronny
 
Ich würde mal behaupten, dass eine halbwegs aktuelle Joomla-Installation sicher ist und nicht mehr Lücken als andere CMS aufweist. Das Problem sind die Zusatzkomponenten, welche ja recht simpel durch unbedarfte Nutzer installiert werden können. Ich sehe es sehr ähnlich wie Alonso...der Hoster hat dafür Sorge zu tragen, dass sowas keine Auswirkungen auf alle Kunden des Servers hat.

Grüße
Oli
 
Wenn ich das richtig verstanden habe (falls nicht, bitte korrigieren):

Es gibt Hoster, die betreiben einen Server, auf dem viele verschiedene Kunden laufen.

Und wird eine Kundenwebsite bsp. über ein unsicheres Joomla gehackt, dann ist der ganze Server - und nicht nur dieser Kunde - komprimittiert?


PS: Ich habe von LAMP - Konfigurationen nicht sonderlich viel Ahnung. Ansonsten hieße das aber als Kunde, die Flucht weg von diesem Hoster zu ergreifen. Umgekehrt ist es natürlich schwierig, im Vorfeld herauszufinden, wie ein Hoster das handhabt. Selbstverständlich scheint das ja wohl nicht zu sein.
 
Also grundlegend erst würde ich hier sagen, dass erstmal der Server gecheckt werden müsste, denn woher soll man wissen, wie gut PHP und Webserver abgesichert sind? Oder vielleicht ist es ja trotz sehr sicherer Konfiguration gelungen aus den "Gefängnis" auszubrechen. Also als erstes diese Reklame löschen und nicht einfach das alte Script drauf spielen, dann den Admin des Server kontaktieren und versuchen herauszufinden, was genau passiert ist. Wie ist der Angreifer hereingekommen. Ergo Logs lesen (und immer im Hinterkopf halten, dass Sie ggf. doch gefälscht sind) und auf die Rückmeldung vom Admin warten.


So, dann mal zu Joomla, Joomla in Version 1.0.x war eine Katastrophe, in Version 1.5 wird es besser und ich denke, die meisten Sicherheitslücken sind eher in den Zusatzmodulen von Drittanbietern, aber auch vernachlässige Updates des Website-Betreibers spielen oftmals hier mit rein. Die meistens Exploits in meinen abonnierten Sicherheitslisten sind bei Joomla in Modulen von Drittanbietern, oder ältere Sicherheitslücken, die in der nächsten Version bereits gefixt sind.


Kennt noch wer Santy?
 
php als module und / oder ausbrauch via CGI / Perl sind möglichkeiten, die mir auch schon auf dem ein oder anderen zu betreuenden server unterkam.
confixx beispielsweise wird zumeist mit php als module aufgesetzt, was systemweit einen www user ausmacht - not so good.
joomla ist kein cms - das ist ein backlinkgenerator - einfach zu viele schwachstellen.
 
Hallo!

naja, kann mich dem was hier über Joomla genörgelt wird nicht so ganz anschliesssen. Habe seit 4 Jahren ausschliesslich Seiten aus Joomla, da man sich ja mal für ein CMS entscheiden muß/soll um dann auch weiter darinnen zu arbeiten und Erfahrung zu sammeln mit dem CMS und in diesen 4 Jahren wurde einmal eine Seite von 10 gehackt. Wäre eglaub ich aber auch mit jedem anderen CMS passiert. Und jetzt mit der neuen Vers.1.5.15 sollten recht viele Sicherheitslücken wirklich ausgebessert worden sein.

mfg snowdog
 
joomla an sich ist genauso sicher wie andere cms. Es sind die drittanbieter plugins die unsicher sind.
 
QUOTE (Yves @ Sa 13.02.2010, 12:34)joomla an sich ist genauso sicher wie andere cms. Es sind die drittanbieter plugins die unsicher sind.

Es liegt aber in der Verantwortung der Joomla - Gesamtarchitektur, daß solche Drittanbieter-Plugins überhaupt zulässig / möglich sind.


Dasselbe grundsätzliche Loch gibt es auch bei Drupal: Eigene Module können direkt auf die Datenbank zugreifen - und sind damit bsp. gegen Sql-Injektionen usw. empfindlich.


Eine sichere Gesamtarchitektur heißt, daß es für Nutzer überhaupt keine Möglichkeit gibt, solchen unsicheren Code einzubinden.
 
Da muss ich Jürgen voll und ganz zustimmen.

Ich kenne Joomla überhaupt nicht, doch was ich hier so lese, dann muss man zum Schluss kommen, dass der Einsatz von Joomla wie russisches Roulette spielen ist.

Aussagen wie "Und jetzt mit der neuen Vers.1.5.15 sollten recht viele Sicherheitslücken wirklich ausgebessert worden sein" lassen mir ja die Haare zu Berge stehen. Was heisst da "recht viele"? Das tönt ja nicht sehr vertrauenserweckend.
 
QUOTE (Jürgen Auer @ Sa 13.02.2010, 11:58)
QUOTE (Yves @ Sa 13.02.2010, 12:34)joomla an sich ist genauso sicher wie andere cms. Es sind die drittanbieter plugins die unsicher sind.

Es liegt aber in der Verantwortung der Joomla - Gesamtarchitektur, daß solche Drittanbieter-Plugins überhaupt zulässig / möglich sind. [...]

Das ist bei OpenSource kein Argument, selbst wenn Sie nicht zulässig sind, würde es welche geben. Hier liegt die Verantwortung alleine beim Administrator, welcher die Software einsetzt. Da kann auch Wordpress, phpBB oder jede andere beliebige Software unsicher werden.

Es ist niemand gezwungen unsichere Software einzusetzen, denn es gibt auch genügend Web-Applikationen, die von Grund auf löchrig sind, und nicht erst durch Drittanbieter löchrig werden. Da tut sich CloseSource, wie OpenSource nicht viel, nur bei OpenSource ist es um Längen leichter die Lücken zu finden.

Software die keine Lücken hat, gibt es nicht, es liegt einfach in der Natur der Sache, da immer ein Wettrüsten zwischen Angreifer und Sicherheit existiert, wobei der Angreifer oft den Vorsprung hat.


Ansonsten kann ich nur wieder das wiederholen, was ich oben über Joomla bereits gesagt hat, aber ich denke nicht, dass hier ein Flamewar gegen Joomla irgendwem etwas bringt. Wer meint, dass es mit seinen Sicherheitsdenken nicht einsetzen würde, der setzt es nicht ein. Wer Vorurteile dagegen hat, wird es auch nicht einsetzen. Wer hier rummaulen möchte, dass der Core unsicher ist, soll bitte Beweise dafür anführen.


Ach ja, kurz zu meiner Frage, da ja sonst niemand mehr zu wissen scheint was Santy war: Santy war ein Wurm geschrieben in Perl, welcher sich über phpBB verbreitetet hat.


Vielleicht kommen wir ja nun mal von der OT-Diskussion weg, hin zu der Fragestellung: "Was tun, wenn eine Website gehackt wurde?".


@Benedict
Interessant wäre es zu wissen, was Du installiert hat und in welcher Version.
 
QUOTE (Sascha Ahlers @ Sa 13.02.2010, 14:24)
QUOTE (Jürgen Auer @ Sa 13.02.2010, 11:58)
QUOTE (Yves @ Sa 13.02.2010, 12:34)joomla an sich ist genauso sicher wie andere cms. Es sind die drittanbieter plugins die unsicher sind.

Es liegt aber in der Verantwortung der Joomla - Gesamtarchitektur, daß solche Drittanbieter-Plugins überhaupt zulässig / möglich sind. [...]

Das ist bei OpenSource kein Argument, selbst wenn Sie nicht zulässig sind, würde es welche geben.


Natürlich ließe sich das abschotten. Mit Open/Closed Source hat das nichts zu tun. Es wäre bsp. ein dramatischer Unterschied, wenn die Grundinstallation den direkten Zugriff auf Tabellen durch Drittanbieter-Plugins verbieten würde, so daß die Drittanbieter-Plugins keinerlei ad hoc generierten Sql-Code nutzen dürften. Damit würden diverse Löcher in bezug auf Sql-Injektionen geschlossen werden.



QUOTE (Sascha Ahlers @ Sa 13.02.2010, 14:24)Software die keine Lücken hat, gibt es nicht, es liegt einfach in der Natur der Sache, da immer ein Wettrüsten zwischen Angreifer und Sicherheit existiert, wobei der Angreifer oft den Vorsprung hat.


Es ist ein erheblicher Unterschied, ob Software strukturelle Lücken hat (bsp. siehe oben) oder ob das prinzipiell nicht möglich ist.
 
QUOTE (Jürgen Auer @ Sa 13.02.2010, 16:03)Natürlich ließe sich das abschotten. Mit Open/Closed Source hat das nichts zu tun. Es wäre bsp. ein dramatischer Unterschied, wenn die Grundinstallation den direkten Zugriff auf Tabellen durch Drittanbieter-Plugins verbieten würde, so daß die Drittanbieter-Plugins keinerlei ad hoc generierten Sql-Code nutzen dürften. Damit würden diverse Löcher in bezug auf Sql-Injektionen geschlossen werden. [...]

Damit ist immer noch nicht verhindert, dass ein Drittanbieter dies aus hebelt. Und nur weil keine SQL-Injections über den Core oder der PlugIn-Schnittstelle möglich sind, kann durch eine neue Datenbankanbindung (innerhalb des PlugIns) dies wieder aufgerissen werden, auch ist noch nicht verhindert, dass man über die PlugIns Systembefehle aufruft, oder ins Dateisystem eindringen kann. Jegliche Abschottung hilft nichts, wenn der Drittanbieter direkt im System neue Lücken aufreißen kann. Es ist doch egal, ob man nun über den Core, oder über das PlugIn ins System eindringen kann. Wenn kein PlugIn-System angeboten wird, wird der Core aufgebohrt. Zu meinen, die PlugIns irgendwie in PHP abschotten zu können ist Utopie, wenn sich der Drittanbieter nicht an den vorgegeben Standard hält.




QUOTE (Jürgen Auer @ Sa 13.02.2010, 16:03)
QUOTE (Sascha Ahlers @ Sa 13.02.2010, 14:24)Software die keine Lücken hat, gibt es nicht, es liegt einfach in der Natur der Sache, da immer ein Wettrüsten zwischen Angreifer und Sicherheit existiert, wobei der Angreifer oft den Vorsprung hat.

Es ist ein erheblicher Unterschied, ob Software strukturelle Lücken hat (bsp. siehe oben) oder ob das prinzipiell nicht möglich ist.

Ich verstehe nicht ganz, was das jetzt mit meiner hier zitieren Aussage zu tun hat. Habe ich irgendwas anders behauptet? - Ich denke nicht.
Auch erzählst Du nichts neues damit. Doch was hat das damit zu tun, dass jede Software Lücken hat? Oder damit, dass wir ein Wettrüsten haben? Kennst Du bereits die Angriffsmethoden von morgen? Also sichere Struktur Hin oder Her, kommen neue Angriffsmethoden, kann sich eine sichere Struktur von heute, morgen schon wieder als komplett unsicher erweisen.
 
QUOTE (Sascha Ahlers @ Sa 13.02.2010, 18:07)
QUOTE (Jürgen Auer @ Sa 13.02.2010, 16:03)Natürlich ließe sich das abschotten. Mit Open/Closed Source hat das nichts zu tun. Es wäre bsp. ein dramatischer Unterschied, wenn die Grundinstallation den direkten Zugriff auf Tabellen durch Drittanbieter-Plugins verbieten würde, so daß die Drittanbieter-Plugins keinerlei ad hoc generierten Sql-Code nutzen dürften. Damit würden diverse Löcher in bezug auf Sql-Injektionen geschlossen werden. [...]

Damit ist immer noch nicht verhindert, dass ein Drittanbieter dies aus hebelt. Und nur weil keine SQL-Injections über den Core oder der PlugIn-Schnittstelle möglich sind, kann durch eine neue Datenbankanbindung (innerhalb des PlugIns) dies wieder aufgerissen werden, auch ist noch nicht verhindert, dass man über die PlugIns Systembefehle aufruft, oder ins Dateisystem eindringen kann. Jegliche Abschottung hilft nichts, wenn der Drittanbieter direkt im System neue Lücken aufreißen kann. Es ist doch egal, ob man nun über den Core, oder über das PlugIn ins System eindringen kann. Wenn kein PlugIn-System angeboten wird, wird der Core aufgebohrt. Zu meinen, die PlugIns irgendwie in PHP abschotten zu können ist Utopie, wenn sich der Drittanbieter nicht an den vorgegeben Standard hält.


Wenn es keine direkten Select/Insert/Update/Delete - Berechtigungen für die Verbindung zum Datenbank-Server gibt, dann gibt es auch keinen Ad-Hoc - Sqlcode. Und dann würde auch eine neue Datenbank-Anbindung nichts nützen, weil das externe Plugin gar nicht die Berechtigung dazu hätte.

Aber das hieße, daß bsp. die Setups für das Erstaufsetzen der Datenbank erheblich anspruchsvoller sein müßten.

Daß natürlich dieses übliche PHP / mySql - Gefrickele da nichts taugt, das ist geschenkt. Warum liegt bsp. Code offen in PHP-Dateien rum? Muß man eben mit den sich daraus ergebenden Problemen leben. In .NET kann man DLLs signieren - damit würde die Hauptanwendung eine fremde DLL gar nicht ausführen, weil sie nicht signiert ist.

Ich halte bereits die Logik von PlugIns für aberwitzig. Die Nutzer, die solche Konstrukte verwenden, müssen dann halt ab und zu damit leben, daß es ihnen die ganze Domain wegputzt.
 
QUOTE (Jürgen Auer @ Sa 13.02.2010, 17:47)Wenn es keine direkten Select/Insert/Update/Delete - Berechtigungen für die Verbindung zum Datenbank-Server gibt, dann gibt es auch keinen Ad-Hoc - Sqlcode. Und dann würde auch eine neue Datenbank-Anbindung nichts nützen, weil das externe Plugin gar nicht die Berechtigung dazu hätte.

[...]

Ich halte bereits die Logik von PlugIns für aberwitzig. Die Nutzer, die solche Konstrukte verwenden, müssen dann halt ab und zu damit leben, daß es ihnen die ganze Domain wegputzt.

Also kommst Du genau zum gleichen Schluss, dass der Admin selber verantwortlich ist, wie ich es bereits gesagt habe, und meine Hauptaussage war.


PlugIns haben halt immer Vor- und Nachteile, aberwitzig ist aber nur, dass Personen ohne Ahnung meinen Sachen zu nutzen und zu betreiben, von welchen Sie keine Ahnung haben. Denn für die Sicherheit am System, ist immer noch in erster Linie der Anwender verantwortlich, egal ob es der eigene Rechner ist, Server oder Website.




QUOTE (Jürgen Auer @ Sa 13.02.2010, 17:47)[...] Daß natürlich dieses übliche PHP / mySql - Gefrickele da nichts taugt, das ist geschenkt. Warum liegt bsp. Code offen in PHP-Dateien rum? Muß man eben mit den sich daraus ergebenden Problemen leben. In .NET kann man DLLs signieren - damit würde die Hauptanwendung eine fremde DLL gar nicht ausführen, weil sie nicht signiert ist. [...]

Super Du vergleichst Äpfel mit Birnen, und scheinst hier noch etwas als gefrickel ab zu stempeln, was Du gar nicht wirklich kennst, bzw. vielleicht nicht mal den Hintergrund verstehen möchtest. Das Gefrickelargument hört sich auch wieder nach so eine Grundsatzdiskussion wie Windows VS Linux, oder Scriptsprache VS Höhere Programmiersprache an, und spätesten dann hätte sich für mich die Diskussion erledigt.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben