spykids hacken CMS

[bine]

So, ist das also, wie macht man denn diesen Kiddies den Garaus, die in der Lage sind ein ganzes großes CMS-System zu hacken und alle Inhalte aller index.html files in diesem Falle sind es 129 Dateien mit ihrem dämlichen Spruch zu überschreiben?

ja, @RK, ich lese dich schon schreiben, das man nur ordentlich coden muß. Stimmt auch, und das ist wohl bei jedem noch so großen OS-Produkt nie wirklich der Fall. Haben wir ja bei der gfx gesehen, was das fürn Kampf war die einzelnen Module aufeinander abzustimmen.

Aber was mich interessiert, wo ist generell die Angriffsstelle? Gibt es irgendwelche Richtlinien, die ich umsetzen könnte? Wonach muß ich suchen? Gibts vielleicht eine allgemeinübliche Schwachstelle? Wohl ne blöde Frage, sonst würd sowas wahrscheinlich gar nicht erst passieren. Aber dennoch. Mich motiviert son Quark, dagegen entwas zu tun.

 

[.stephan]

spykids? Oder meinst nicht Scriptkiddies?

Also generell ist es schonmal gut, wenn anständige Passwörter vergeben werden. In vielen Fällen sit das schon des Rätsels Lösung.

Aber wenn man selber programmeirt sollte man einfach jede Eingabe als böse betrachten und sie entsprechend filtern, bis nurnoch die "guten" Dinge zurückbleiben.

MfG

Stephan

 

[ein schlauer]

Es geht wohl um Mambo
http://www.google.de/search?hl=de&q=spykids+hacken+CMS&btnG=Google-Suche&meta=

 

[cag-live]

hm also es ist durch einige dinge ziemlich leicht auszuhebeln...

also einmal schon so wie stephan sagt: durch eingaben der user. also immer den nutzern mißtrauen. Besonders bsp. wenn du Dateien einbindest über eine weitergeleitete variable... z.b folgendermaßen:

$action = $_GET['action'];
include($action);

und man dann mit

index.php?action=pfad1.php

die pfad1.php-Datei einbindet

Der Hacker könnte dann folgendes machen:

index.php?action=../geschützt/passwort.php

und schlimmstenfalls PW's auslesen.

dann sollte man PHP-Fehler ausblenden und verzeichnisse geheim halten. Könnte von einigen Leuten von nutzen sein...

Und zuletzt bei MySQL mit mehreren Nutzern & Rechten arbeiten. Also einfachen Leuten im script nirgendwo die möglichkeit zu geben was zu löschen.


hmm ja, dass fällt mir grad so spontan, ist aber ein riesiges fachgebiet

mfg david

 

[ein schlauer]

und PHP Nuke und so ganz klar ist mir das noch nicht, ist das eine sql Injection oder nicht?

 

[cag-live]

sql-injection ist, wenn man in weitergabewerten einen mysql-befehl weiterleiten lässt. somit kann der nutzer den befehl bearbeiten uns irgendetwas löschen... Beispiel:

index.php?id=42

soll die 42ten Datenbankeintrag auslesen.
die Id wird also hier mit eingespannt.

SELECT author, subjekt, text FROM artikel WHERE ID=$id

wenn der "Hacker" nun folgende url aufsucht:

index.php?id=42;UPDATE%20USER%20SET%20TYPE="admin"%20WHERE%20ID=23

wird der befehl des "UPDATES" mit ausgeführt.

naja alles dazu: SQL-Injektion - Wikipedia

mfg david

 

[ein schlauer]

Ist mir schon klar aber ist diese "spykids ownz you" einer oder nicht?
Soweit ich das rausgekriegt habe liegt's an awstats, ist zum Glück bei meinem Provider nur per Login erreichbar.

 

[bine]

genau so ist das, es geht um Mambo Sites.
So langsam komme ich zu dem Schluß, das viele Köche den Brei doch verderben...

*spykids ownz you* steht anstelle des normalen Inhalts in allen index.html Dateien. Und davon gibt es in dem CMS viele viele viele.

Glaubt mal nicht, das ich schon irgendwo ne Antwort zur Lösung gefunden habe. Das kommt mir aus gfx-Zeiten sooo bekannt vor. Viele nicht wirklich beantwortete Fragen, Antworten von irgendwelchen Usern, die schlaue Kommentare abgeben oder mit Halbwahrheiten gemischte Vermutungen. Den kompetenten Anteil muß man sich durch probieren zusammensuchen, wenn man nicht gerade selbst das Ganze schreiben kann.

Wobei ich natürlich zu schätzen weiß, das Leute sich überhaupt Gedanken machen und mögliche Lösungsideen präsentieren. Aber in der Summe ist der Salat mehr ein Verwirrspiel als ne Lösung.

Na jo, so ist das wohl. Internet halt.

Lücken werden eben immer erst dann geschlossen, wenn sie sich aufgetan haben. Oder erst später wie bei M$ Es gibt ja mittlerweile bereits nach Mambo das Produkt Joomla was sich explosiv weiterentwickelt. Das Kern-Entwicklerteam ist sicher ne kompetente Mannschaft. Zumindest folgt ein Update dem anderen sehr schnell. Es sind aber auch so wie ich quergelesen habe reichlich Macken drin gewesen.

Beschweren kann man sich darüber aber nicht, schließlich ist es OS.

Da kann ich wohl nur darauf bauen, die vorhandenen Mambo-Sites auf die aktuellste Joomla-Version zu bringen und hoffen das dieses Problem dann erledigt ist. Zumindest sehe ich mich nicht in der Lage, den Knackpunkt selbst zu finden und zu beheben.

Nichtsdestotrotz find ich das sehr spannend hierüber zu lesen und zu lernen.

 

[Harry Hunt]

Das Problem mit Systemen wie Typo3, Mambo, phpBB, phpnuke, etc. ist, dass sie weit verbreitet und damit auch für Skriptkiddies interessant sind. Sicherheitslücken in diesen Systemen geraten schnell an die Öffentlichkeit und werden so auch von Leuten ausgenutzt, die an sich nicht das Fachwissen haben, um derartige Lücken selbst aufzuspüren.
Dazu kommt, dass alle eben genannten Projekte einen enormen Funktionsumfang haben. Viele Funktionen werden von den meisten Leuten nie genutzt, aber dennoch stellen sie eine potentielle Angriffsfläche für "Hacker" dar.
Es ist eine allgemeine Schätzung, dass ein durchschnittliches Programm (und das gilt sicherlich auch für Web-Anwendungen) etwa 20-30 Fehler pro 1.000 Zeilen Code enthält. Vor einer Weile habe ich mal ein Forum für eine Website geschrieben, das ziemlich genau den Bedürfnissen angepasst war und insgesamt mit etwa 5.000 Zeilen Code auskam. Hätte ich z.B. vBulletin verwendet, wären es stattdessen über 100.000 Zeilen gewesen. Ich will damit nicht sagen, dass vBulletin ein schlechtes Produkt ist, sondern nur, dass man sich dessen bewusst sein sollte, dass umfangreiche Softwaresysteme potenziell mehr Fehler enthalten.

Natürlich kann die Lösung nicht sein, nur noch alles selbst zu entwickeln, aber wenn man "fremde" Software einsetzt, hat man damit auch gewisse Verpflichtungen, etwa regelmäßig updates zu machen, sich über bekannte Sicherheitslücken zu informieren usw.
Und in vielen Situationen kann es auch sinnvoll sein, nicht auf vorgefertigte Lösungen zurückzugreifen und selbst "Hand anzulegen" oder zumindest den kleinsten gemeinsamen Nenner zu suchen, d.h. Systeme zu benutzen, die nicht mehr können als man eigentlich braucht und ungenutzte Module zu deaktivieren.

 

[RoyalKnight]

Da muss ich tatsächlich auch etwas zu diesem Thema loswerden

ja, @RK, ich lese dich schon schreiben, das man nur ordentlich coden muß. Stimmt auch, und das ist wohl bei jedem noch so großen OS-Produkt nie wirklich der Fall. Haben wir ja bei der gfx gesehen, was das fürn Kampf war die einzelnen Module aufeinander abzustimmen.

Das Problem mit dem "ordentlich" coden ist halt auch, dass das gar nicht geht. In Software werden sich immer Fehler einschleichen - 100%ige Sicherheit gibt es nirgends.

Sicherheit steht in der Software-Welt sehr stark im Zusammenhang mit dem Entwicklungsmodell - bzw. der geforderte Sicherheits-Level bestimmt das Entwicklungsmodell bzw. das (entscheidendere) Test-Modell. Für kritische Anwendungen wie bspw. Signalsteuerungen für Eisenbahnanlagen (kann Leben gefährden), etc. wird die Funktions- und Sicherheitstauglichkeit von Software mathematisch überprüft und bewiesen. Normale Testläufe wie für normale Software (keine gravierenden Schäden) sind hier auch eine Selbstverständlichkeit.

Zurück zum Thema:
Nehmen wir vBulletin (Commercial) und phpBB (Free) zum Vergleich her. Die Entwickler von vBulletin leben vom Erfolg der Software. Eventuelle Sicherheitslücken (welche sehr selten auftreten) werden vertraulich behandelt, ausgebessert und die Kunden über Updates informiert - es steckt ein ordentliches Konzept dahinter. Genau diese fehlt bei den meisten Open Source-Produkten in meinen Augen.
Ein weitere wichtiger Punkt der beiden ist der Funktionsumfang: vBulletin bringt alles wichtige von Haus aus mit, alles aus einem Guß - von den selben guten Entwicklern. Für phpBB muss alles gesondert nachinstalliert werden um den benötigten Funktionsumfang für einen sinnvollen Betrieb zu erreichen. Das Problem dabei (genauso wie auch bei Typo3, Mambo und sonstige Systeme mit Erweiterungen von Dritten - auch vBulletin-Hacks) ist, dass es oft von relativen Laien geschrieben wird und sich dadurch sehr viele Fehler ins System einschleichen, die Software dadurch sehr unsicher wird.

Aber was mich interessiert, wo ist generell die Angriffsstelle? Gibt es irgendwelche Richtlinien, die ich umsetzen könnte? Wonach muß ich suchen? Gibts vielleicht eine allgemeinübliche Schwachstelle? Wohl ne blöde Frage, sonst würd sowas wahrscheinlich gar nicht erst passieren. Aber dennoch. Mich motiviert son Quark, dagegen entwas zu tun.

Den Rechner in einem sicheren Safe einsperren...

Vor einer Weile habe ich mal ein Forum für eine Website geschrieben, das ziemlich genau den Bedürfnissen angepasst war und insgesamt mit etwa 5.000 Zeilen Code auskam. Hätte ich z.B. vBulletin verwendet, wären es stattdessen über 100.000 Zeilen gewesen. Ich will damit nicht sagen, dass vBulletin ein schlechtes Produkt ist, sondern nur, dass man sich dessen bewusst sein sollte, dass umfangreiche Softwaresysteme potenziell mehr Fehler enthalten.

Anmerkung:
Soll jetzt nicht heißen, dass selbstgeschriebene Software grundsätzlich fehlerfreier ist. Wenn Leute hier ein wenig Code hernehmen, da ein wenig, das noch toll zusammenflechten, oder allgemein keine Ahnung von Programmierung haben, schleichen sich in 10-100 Zeilen eigenem Code mehr Fehler ein als in einem der oben genannten Standardsysteme...