Forum

Hallo OPN-Team,

heute bin ich aber fleißig. Ich habe mir mal den Trunk-Code angeschaut. Es gibt ein potenzielles Sicherheitsleck. Es kann dadurch das gesamte OPN-Portal manipuliert werden.

Daher macht es mich doch etwas stutzig?! So wie ich sehe, dürfen alle auf sämtliche Skripte von OPN ausführen. Die PHP-Einstellung "REGISTER_GLOBALS" spielt hier keine Rolle. Das ist ziemlich gefährlich.


Daher möchte ich folgenden Vorschlag machen:

Ich würde die Ausführbarkeit der eingebundenen Skripte auf die jeweiligen Hauptskripte festlegen. Diesen nachfolgenden Code fügt Ihr in allen PHP-Skripten ein, somit dürfen nur "INDEX.PHP" und "ADMIN.PHP" die nachfolgenden eingebundenen Skripte starten. Bei direkt Zugriff auf die Unterseite wird der "HACKER" oder das Schadprogramm vom Server auf die Startseite umgeleitet. Somit minimiert man deutlich das Risiko, dass das System gehackt werden kann. (Ich weiß, das es bei derzeitigen Code-Umfang sehr viel Arbeit ist.) Nicht desto trotz ist die Sicherheit für den Webmaster das höchste Gebot.

Wenn ihr dabei Hilfe braucht, so lasst es mich wissen. Ich helfe gerne.

Beispiel-Code:

if (!eregi('index.php', $_SERVER['PHP_SELF']) and !eregi('admin.php', $_SERVER['PHP_SELF'])) {
header('Location: http://www.openphpnuke.info/index.php');
exit;
}


Nun, werde ich den Trunk-Code weiter analysieren. Evtl. werde ich noch weitere "Sicherheitslücken" finden.

Gruß

Sebastian

[ Diese Nachricht wurde bearbeitet von: Freespacer am 03.10.2006 18:57 (Originaldatum 03.10.2006 18:3 ]

[ Diese Nachricht wurde bearbeitet von: Freespacer am 03.10.2006 19:00 (Originaldatum 03.10.2006 18:38) ]

nein das ist hier etwas anders ich verstehe zwar den

"So wie ich sehe, dürfen alle auf sämtliche Skripte von OPN ausführen"

nicht ganz bzw. kann ich mir denken was du meinst wenn ich weiß das du von Nuke her kommst

In die Sicherheit wird und wurde viel Arbeit gesteckt solltest du wirklich eine Lücke finden viel Spaß beim suchen

Das Konzept ist hier anderes als bei Nuke. Wenn da überhaupt ein Konzept ist.

Vor ab die Sicherheitsstufe ist anpassbar im Admin. Ausgehend davon dass keiner ein FTP Zugang hat und User oder Unsichere Kameraden keine Anypage Seite erstellen dürfen und PHP Side / Centerbox sowie das Modul webdir unzugänglich ist (evt. noch noch bei den Makros die aber noch von anderen dingen abhängen) sollte es Sicher sein.

Zum Konzept

mainfile.php wird immer geholt das läst sich auch so nicht umgehen da dieses das erste ist was getan wird. Bei scripten die erst später bzw. nicht direkt startbar sind wird auch dieses geprüft und sofern nicht die()

die mainfile holt die master.php hier wäre ein Ansatzpunkt du müsstest zusehen ne eigene master.php von woanders zu holen. Praktisch würde das nur über z.b. "REGISTER_GLOBALS" gehen nur dumm wir nutzen keine "REGISTER_GLOBALS" und schecken die Variablen (komm ich noch zu) also eigentlich dürftest du nix eigenes einbinden können (master.php) so die ist jetzt gelesen und testet auch noch mal ne paar Sachen

(bin ich wirklich hier / wo komm ich her usw..)

Gehen wir mal davon aus bis hierhin ist das script durch. Nun kommt der Rest des -Modules- wir wurden Werte übergeben (vom User) POST / GET Variablen

Das ist der Typische Ansatzpunkt für die verschieden –Angriffe-

Bei uns wird jede Variable gesäubert und auf den Wertebereich glatt gebügelt. Also z.b. erwarten wir ein INT dann holt die Funktion GetVar auch nur ein Integer egal was du da übergeben hast und wie. Suchfelder werden noch mal gesondert behandelt.

Wenn du dann auch noch die URL Codierung an hast werden die Variablen auch noch mit einem Code Verschlüsselt. Dieser Code kann auch je Stufe noch mal Zufallskomponenten enthalten. Dann hast du noch schlechtere Karten da was auszurichten.

Aber vielleicht ist mir nicht klar was genau du meinst. Bzw. wie du den schadhaften Code einschleusen willst. Das das ein Modul auch auf den Code von anderen Modulen zugreifen darf, ist ja grundsätzlich nicht gefährlich. Im gegenteil das ist bei einem Plugin Konzept ja nötig da jedes Modul die Fähigkeiten eines anderen Modules nutzen soll.

Wie gesagt wenn jemand ne FTP Zugang hat naja da kann man nix machen.

Hallo Stefan,

Wenn du dann auch noch die URL Codierung an hast werden die Variablen auch noch mit einem Code Verschlüsselt. Dieser Code kann auch je Stufe noch mal Zufallskomponenten enthalten. Dann hast du noch schlechtere Karten da was auszurichten.

Wenn das so wäre mit der Verschlüsselung?! Dann bringt Sie leider nicht viel. Warum kann ich anhand eines simplen Beispiel geben. Achte bitte darauf, dass du die Verschlüsselung aktiviert hast. Ruf doch mal ein installiertes Modul z.B. das "Mein Gästebuch" (myguestbook) per direkt Link auf. z.B. auf http://www.openphpnuke.info/modules/myguestbook/index.php?op=addguest

Evtl. kann der Angreifer auch so das Gästebuch manipulieren bzw. jedes andere unsichere Modul.

Es wird noch nicht mal in der "mainfile.php" überprüft, ob die Verschlüsselung aktiviert ist???? Das ist mehr als bedenklich. Daher stufe ich es als ein Sicherheitsrisiko ein.

Ihr müsst da den Kontroll-Code nochmal überarbeiten. Es ist noch nicht sicher genug. OPN muss überprüfen, dass die Variable "OPNPARAMS" nicht leer sein darf. Da wir ja in OPN eingestellt haben, dass die Übergabe-Parameter verschlüsselt werden

Gruß

Sebastian

sorry ich verstehe nicht jetzt mal unabhänig von der URL Codierung was soll mr dein Beispiel sagen bzw. Wieso verhält er sich da deiner Meinung nach falsch.

Du willst da fremden Code einschleusen? Nach mal. Ich verstehe nicht was da die Lücke sein soll. Bis jetzt hast du das Modul nur auf gerufen und sollst was schreiben. Ich vermute du willst die Variable op angreifen. Versuch es. Versuch irgendwas zu übergeben was auch immer.

stefan schrieb am 03.10.2006 um 20:34:12 Uhr folgendes:

sorry ich verstehe nicht jetzt mal unabhänig von der URL Codierung was soll mr dein Beispiel sagen bzw. Wieso verhält er sich da deiner Meinung nach falsch.

Du willst da fremden Code einschleusen? Nach mal. Ich verstehe nicht was da die Lücke sein soll. Bis jetzt hast du das Modul nur auf gerufen und sollst was schreiben. Ich vermute du willst die Variable op angreifen. Versuch es. Versuch irgendwas zu übergeben was auch immer.

Weil es besser ist, von allen Seiten abzusichern. Andersherum gefragt, was bring mir die Verschlüsselung, wenn die Seiten sowieso öffentlich zugänglich sind? Da kann ich genauso die Verschlüsselung abschalten, weil sie nichts bringt. Verstehst du was ich meine?

Übrigens wäre es nicht vielleicht besser, wenn die Variable-Name "OPNPARAMS" öffentlich änderbar ist? Intern kann er von mir aus OPNPARAMS heißen, Aber das ist leider für mich ein Indiz, welches CMS gerade läuft.

Manche Webmaster empfehlen ein CMS gerne weiter, aber der Webmaster muss auch die Möglichkeit haben sein eigenes CMS zu verschleiern. Genausowie die Cookies, diese werden auch als "opnsession" genannt. Das sollte man auch im Adminbereich ändern können.

Nochmal zu Verdeutlichung, (leider habe ich auch ein Fehler im Gästebuch entdeckt)
Ich habe das Modul Gästebuch noch aktiviert. Ich will jedoch nur, dass man dieses Formular direkt von OPN generiert wird und diese auch direkt von OPN zurückschicken kann.

Aus unerfindlichen Gründen kann ich auch wenn ich in OPN angemeldet bin, ins Gästebuch nicht schreiben. Evtl. liegt hier ein BUG vor?! Nur die Einstellung schafft kurzfristig eine Lösung (aber nicht von dauer) unter admin -> Mein Gästebuch -> Einstellungen -> Spam Sicherheitsabfrage -> NEIN

Danach kann ich als angemeldeter User ins Gästebuch schreiben. Aber leider laufe ich auch sofort auf Gefahr, dass Spamschleuder dies ausnutzen können. Da die Sicherheitsabfrage leider in der Trunk-Version defekt ist.

Dieser kleine Code kann einfach SPAM's ins Gästebuch übertragen.
<html>
<head>
<title>SPAMING</title>
</head>
<body>
<form action="http://www.openphpnuke.info/system/forum/opnpr.php" method="post" name="coolsus" class="form" onsubmit="return validateForm('coolsus', validateFields, var_msg);">
<input type="hidden" name="guest_poster" value="2" />
<input type="hidden" name="guest_title" value="SPAMING GROUP!!!" />
<input type="hidden" name="font" value="" />
<input type="hidden" name="color" value="" />
<input type="hidden" name="chars" value="" />
<input type="hidden" name="search" value="" />
<input type="hidden" name="guest_body" value="THESE WAS SPAMED BY FREESPACER!!!" />
<input type="hidden" name="gfx_securitycode" value="Sicherheits-Code" />
<input type="hidden" name="op" value="saveguest" />
<input type="hidden" name="id" value="" />
<input type="submit" name="submit" value="SPAMING NOW" />
</form>
</body>
</html>

Aber da das Gästebuch leider mit der Sicherheitseinstellung nicht beschreibbar ist umso grö0er ist die Gefahr denoch. Das man die Sicherheitseinstellung heruntersetzen muss, um das Gästebuch nutzen zu können.

Da ist auch noch Nachbesserung angesagt.

Ok langsam du sprichts viele Dinge verschiedener Art in einem Posting aus.

Weil es besser ist, von allen Seiten abzusichern. Andersherum gefragt, was bring mir die Verschlüsselung, wenn die Seiten sowieso öffentlich zugänglich sind? Da kann ich genauso die Verschlüsselung abschalten, weil sie nichts bringt. Verstehst du was ich meine?

Bis dahin gebe ich dir Recht. Das mit der URL Codierung ist per Rev. 5956 korrigiert. Aber wie gesagt es ändert nichts du bekommst da trotzdem keinen Fremden Code rein.

Freespacer schrieb am 03.10.2006 um 21:35:13 Uhr folgendes:

Übrigens wäre es nicht vielleicht besser, wenn die Variable-Name "OPNPARAMS" öffentlich änderbar ist? Intern kann er von mir aus OPNPARAMS heißen, Aber das ist leider für mich ein Indiz, welches CMS gerade läuft.

Manche Webmaster empfehlen ein CMS gerne weiter, aber der Webmaster muss auch die Möglichkeit haben sein eigenes CMS zu verschleiern. Genausowie die Cookies, diese werden auch als "opnsession" genannt. Das sollte man auch im Adminbereich ändern können.

Über das verscheiern bitte ich zu akzeptieren das man unterschiedlicher Meinung sein kann. Das ganze nennt sich dann " security by obscurity " Obscurity bringt keine Sicherheit. Allerdings ist es auch kein Problem da ne Schlater hinzuzufügen. Aber wie gesagt sehe ich das nicht so entscheident an. Wichtig ist das es nicht durchkommt. Und genau da erwarte ich noch ne hinweiss wie ich da konkrett durch soll xss und co. sind getestet und werden abgefangen.

Freespacer schrieb am 03.10.2006 um 21:35:13 Uhr folgendes:

Ich will jedoch nur, dass man dieses Formular direkt von OPN generiert wird und diese auch direkt von OPN zurückschicken kann.

verstehe ich nicht was heisst besser was soll das bedeutet. Stichwort BOTs die da reinschreiben ?

Freespacer schrieb am 03.10.2006 um 21:35:13 Uhr folgendes:

Aus unerfindlichen Gründen kann ich auch wenn ich in OPN angemeldet bin, ins Gästebuch nicht schreiben. Evtl. liegt hier ein BUG vor?!

geht hier Problemlos wenn ich mir dein Code unten ansehe denke ich das du da keine GFx siehst mit einer Zahl...

Freespacer schrieb am 03.10.2006 um 21:35:13 Uhr folgendes:

Nur die Einstellung schafft kurzfristig eine Lösung (aber nicht von dauer) unter admin -> Mein Gästebuch -> Einstellungen -> Spam Sicherheitsabfrage -> NEIN

Naja ich gehe mal von der JA Stellung aus...

wie gesagt geht hier Problemlos. Dieser ganze Teil bezieht sich aber auf SPAM Probleme. Spam ist ein wichtiges Thema keine Frage aber das würde ich nicht so ganz im gleichen Atemzug mit HACK und Fremden Code ausführen nennen. Das hat nicht direkt mit einem einbrauch zutun. Wenn irgendwo SPAM Probleme auftauchen werden diese gelöst. Auch klar. Man muss Sie natürlich auch sagen

mit dem GFX Code ist da eigentlich nichts mehr zubeobchten. Ich bau da aber gerne noch was zusätzliches ein.

Mal so am Rande erwähnt. Wir / Ich haben eine Testbereich. Dort kann man von uns Adminrechte bekommen um jeden erdenkliche Konstellation nachzubauen. Wenn Kompleze Fehler vorhanden sind ist dort Testbar und für mich dann auch leiter behebbar. www.laborcenter.de

stefan schrieb am 03.10.2006 um 21:44:38 Uhr folgendes:

Bis dahin gebe ich dir Recht. Das mit der URL Codierung ist per Rev. 5956 korrigiert. Aber wie gesagt es ändert nichts du bekommst da trotzdem keinen Fremden Code rein.

Wo hast du da im SVN korrigiert? Bin ja sehr neugierig.

Okay, das mit den Sicherheitsfragen kann man lange hin und her diskutieren. Fakt ist, irgendwie komme ich mit der Verschlüsselung und darin der eigentliche Zweck nicht ganz dahinter. Wenn es eigentlich nur dazu dient, die Server-Anfrage zu verschleiern, was eigentlich auch klappt. Aber bei der HTML-FORM-Tag ist der Zielort und die ganzen Variabeln einsehbar. Ab da ist dann mit der Verschleierungstaktik schluss.

Sebastian

PS: So angeregt diskutiert, habe ich schon lange nicht mehr. Nicht desto trotz werde ich in nächster Zeit einige Sachen ausprobieren und im gesamten OPN-System irgendwelchen Schadcode einschleusen. Mal sehen, ob OPN standhält.

Freespacer schrieb am 03.10.2006 um 22:19:11 Uhr folgendes:

Wo hast du da im SVN korrigiert? Bin ja sehr neugierig.

Kannst du doch Problemlos im SVN log sehen?

Freespacer schrieb am 03.10.2006 um 22:19:11 Uhr folgendes:

komme ich mit der Verschlüsselung und darin der eigentliche Zweck nicht ganz dahinter.

zweck ist eben nicht jeden mist übergeben zukönnen

Freespacer schrieb am 03.10.2006 um 22:19:11 Uhr folgendes:

PS: So angeregt diskutiert, habe ich schon lange nicht mehr. Nicht desto trotz werde ich in nächster Zeit einige Sachen ausprobieren und im gesamten OPN-System irgendwelchen Schadcode einschleusen. Mal sehen, ob OPN standhält.

Kein Problem das mache ich ja auch Ich habe dafür ne HACK Programm gebaut das kommt in jedes CMS bis jetzt problemlos.

Jetzt bin ich mal gemein und gebe aber keine Tips wo du ne kleine Möglichkeit hättest. Mal schauen ob du es findest nur beeile dich weil ich Arbeite dagegen