Suche

[breakdancer]

Hey zusammen,

ich versuche gerade das kleine Script "Ctracker" in meine Seite zu implementieren...

Die Installationsanleitung sagt mir folgendes:

Code Auswählen Erweitern

5. Folgenden Code im Footer deiner Seite einfügen:

   Im einer overall_header direkt nach <?PHP:

   CODE für Schutzsystem:

include(dirname(__FILE__) . '/ctracker/ctracker.php');


   CODE für Copyright:

<?PHP echo footer(); ?>


Gut gut, habe ich gemacht. Und zwar in der header.php wie folgt:

Code Auswählen Erweitern

* $Author: tora60 $
* $Date: 2007/04/10 17:02:44 $
*/

include(dirname(__FILE__) . '/ctracker/ctracker.php');

if (!defined("mxMainFileLoaded")) die ("You can't access this file directly...");

Als Ergebnis erhalte ich über den Debug-Modus jedoch mehrere Notices, dass in der Basisdatei cTracker.php die Variable "ct_filedir" nicht definiert ist.

Zudem habe ich drei Meldungen, dass die Offsets 3, 4 und 5 nicht definiert seien... Klar, das sind alles "nur" Notices, bin aber unsicher, ob das nicht doch die Funktionsweise beeinträchtigt. Ist schliesslich eine wesentliche Funktion, die da undefiniert scheint.



Dann noch zur Copyright - Notice, die ich Einbinden möchte. Hierzu sagt mir die Anleitung, dass ich den oben stehenden Text so in den Footer einbinden soll...

Nur wo und wie genau ?

Wer kann mir denn hier mal helfen ?

Liebe Grüße

Markus

[Andi]

Hi

ctracker?
Hab ich schonmal gehört/gesehen und hier was dazu geschrieben:
http://www.pragmamx.org/Forum-topic-21678.html

Aber du scheinst da irgend ne andere Version zu haben.
Wo hast du das Ding her?

[breakdancer]

Hui Andi,

man könnte meinen, Du hättest alle Beiträge nicht nur auf dem Server sondern auch in Deinen grauen Zellen gespeichert...   

Gugg mal hier, da findest Du die Infopage und Downloadseite zu der von mir verwendeten Version:
http://www.wupmedia.de/ctracker/stact/    - das Ganze basiert also auf "cback" und wurde wohl von dem netten Kollegen hier erweitert. Es gibt auch schon eine downloadbare Beta einer Version 1.4 oder so, die hab ich gestern gefunden, find sie jetzt aber nicht mehr...

Wie ich drauf gekommen bin? Durch die bekannte Wurm-Attacke, durch die Dateien möglicherweise infiziert und verändert werden (siehe http://www.pragmamx.org/Forum-topic-21745.html). Und unter einem von den von Dir angegebenen Links fand ich ein Forum mit Verweis auf den Ctracker...

Lieben Gruss

Markus

[Andi]

Hi

also, bevor sich jetzt noch andere User daran versuchen...

Vergiss das Teil

Ich will eigentlich keine Coder irgendwie kritisieren, oder deren Arbeit irgendwie abwerten.
Aber:

In dem Fall muss ich ganz klar sagen, es taugt nix.
Die einzige Schutzfunktion die dort im Code enthalten ist, ist ein extrem einfach gestrickter Filter, der bestimmte Teilstrings in der Url versucht als Schadcode zu erkennen. Die vorgegebenen Teilstrings sind, zu 80% völlig ungefährlich, können durch kleine Veränderungen ganz leicht umgangen werden und sie sind so pauschal gehalten, dass sie mehr Fehlmeldungen produzieren dürften, als wirkliche Gefahren abzuwehren.
Es wird nur die URL gefiltert, sämtliche Daten, die über Servervariablen, Formulare oder Cookies dem Script übergeben werden, bleiben völlig unbehelligt.

PragmaMx hat selbst einen eingebauten Filter, der alle übergebenen Scriptparameter untersucht. Der Filter ist kein reingeflickter Aufsatz, sondern fester Bestandteil des Systems. Der Filter arbeitet "lautlos" im Hintergrund und verrichtet einfach nur seine Arbeit, ohne gross Tamtam drumrum.
Der Filter im pragmaMx ist zum Grossteil auch nicht für das pragmaMx selbst zuständig, sondern in der Hauptsache für unsaubere Fremdmodule, die oft die einfachsten Sicherheitsregeln nicht beachten.
Der Code von pragmaMx ist so geschrieben, dass die übergebenen Daten an der Stelle überprüft bzw. konvertiert werden, an der sie verarbeitet werden und nicht irgendwo pauschal....
Wenn wir irgendwelche Hinweise auf Sicherheitslücken im pragmaMx erhalten, dann wird das direkt dort gefixt wo das Problem besteht. Irgend ein zusätzliches PHP-Script ist da völlig unnötig.

Durch die bekannte Wurm-Attacke, durch die Dateien möglicherweise infiziert und verändert werden

Diese Wurm-Attacke ist mit Sicherheit nicht über das pragmaMx gelaufen. Sonst hätten wir hier schon hunderte infizierte Installationen, nicht nur die eine....
Hacker, die solche Atacken erfolgreich fahren können, die lachen über solche eingeflickten Hilfsmittel. Die arbeiten mit ganz anderen Mitteln, die bringen ihren Schadcode nicht über die Url ein. Und wenn sie doch mal ausgesperrt werden, dann haben die Möglichkeiten um bei jedem Seitenaufruf die IP zu wechseln...


Hier mal die "unerlaubten" Teilstrings, die in der Url nicht vorkommen dürfen:

'chr(', 'chr=', 'chr ', ' chr', 'wget ', ' wget', 'wget(', 'cmd=', ' cmd', 'cmd ', 'rush=', ' rush', 'rush ', 'union ', ' union', 'union(', 'union=', 'echr(', ' echr', 'echr ', 'echr=', 'esystem(', 'esystem ', 'cp ', ' cp', 'cp(', 'mdir ', ' mdir', 'mdir(', 'mcd ', 'mrd ', 'rm ', ' mcd', ' mrd', ' rm', 'mcd(', 'mrd(', 'rm(', 'mcd=', 'mrd=', 'mv ', 'rmdir ', 'mv(', 'rmdir(', 'chmod(', 'chmod ', ' chmod', 'chmod(', 'chmod=', 'chown ', 'chgrp ', 'chown(', 'chgrp(', 'locate ', 'grep ', 'locate(', 'grep(', 'diff ', 'kill ', 'kill(', 'killall', 'passwd ', ' passwd', 'passwd(', 'telnet ', 'vi(', 'vi ', 'insert into', 'select ', 'nigga(', ' nigga', 'nigga ', 'fopen', 'fwrite', ' like', 'like ', '$_request', '$_get', '$request', '_request', '$_request', '$get', '.system', 'http_php', '&aim', ' getenv', 'getenv ', 'new_password', '&icq', '/etc/password', '/etc/shadow', '/etc/groups', '/etc/gshadow', 'http_user_agent', 'http_host', '/bin/ps', 'wget ', 'uname\\x20-a', '/usr/bin/id', '/bin/echo', '/bin/kill', '/bin/', '/chgrp', '/chown', '/usr/bin', 'g\\+\\+', 'bin/python', 'bin/tclsh', 'bin/nasm', 'perl ', 'traceroute ', 'ping ', '.pl', '/usr/x11r6/bin/xterm', 'lsof ', '/bin/mail', '.conf', 'motd ', 'http/1.', '.inc.php', 'config.php', 'cgi-', '.eml', 'file\\://', 'window.open'

Ich sehe da auf Anhieb keinen einen, der einer pragmaMx Installation gefährlich werden könnte...


PS:
eine ähnliche Diskusion hatten wir vor 3 Jahren schon auf nukeboards.de. Damals gab es ein nuke "Sicherheitstool" welches im Prinzip genauso arbeitete....
Diskussion: http://www.laanix.de/showthread.php?t=25424
meine Code-Analyse: http://vkp.shiba.de/doku/fortress.htm

[Andi]

sehe gerade, da steht ja schon einiges zu pragmaMx (damals noch vkpMx)  in dem Thread....

http://www.laanix.de/showpost.php?p=147897&postcount=21

Oki, dann ein kleines Beispiel.
In dem umstrittenen logfile bei den Nukecops findet sich recht oft dieser Exploit:

Code Auswählen Erweitern

http://domain.xx//modules.php?name=xxxxxxxx&d_op=xxxxx&cid=2%20UNION%20select%20cccc,%20aaa,%20ddd%20FROM%20nuke_tabelle Wie und wo, prüft man da auf Gültigkeit?
Im Modul selbst, bevor die Query überhaupt an die Datenbank abgeschickt wird. Die Variable $_GET['cid'] darf nur ein Integerwert sein, sonst nichts. Also wandelt man diese Variable mit intval() in einen Integerwert um.
Aus:

Code Auswählen Erweitern

cid=2%20UNION%20select%20cccc,%20aaa,%20ddd%20FROM%20nuke_tabelle wird:

Code Auswählen Erweitern

cid=2 fertig....
Jetzt kann man dem script übergeben was man will, diesbezüglich kann nichts mehr passieren.

Klar, das ist Arbeit, richtige Arbeit, keine Sache von 5 Minuten und hat nur Gültigkeit für dieses Modul.
Im vkpMx haben wir ca. 1/2 Jahr dafür gebraucht, das System und die enthaltenen Module auf diesen Standard zu trimmen. Dieser "Fork" läuft mit Sessions, error_reporting(E_ALL) ohne eine Fehlerausgabe, keine nichtinitialisierten Variablen, alle Variablen werden vor absenden an die DB gecheckt, usw. Sämtliche in der letzten Zeit in nuke aufgetauchten Sicherheitsprobleme per sql_injection oder admin.php Angriffe (addauthor etc.) sind daran gescheitert. Bis heute brauchten wir für das System und die integrierten Module keinen Sicherheitsfix basteln.

An einer globalen Funktion, die auch Fremdmodule noch etwas sicherer macht, arbeiten wir gerade. Hier wird aber nicht nur geprüft, was über Request kommt, sondern es wird mit dem verglichen, was auch tatsächlich in der Funktion sql_query() davon noch ankommt.

Weiss nicht, ob das jetzt Selbstgefälligkeit ist....


Stimmt, aber leider passiert das m.E. am falschen Ort. Das ist nicht nachgearbeitet, sondern wieder reingeflickt um uralte Versäumnisse von FB zu überdecken.

Vielleicht ganz interessant zu dem Thema:
http://www.post-nuke.net/module-ContentExp...-24-meid-28.htm
http://www.dclp-faq.de/q/q-sql-injection.html

Achso, nuke unhackbar machen...
Nö, der Zug ist abgefahren, es gibt in Deutschland mindestens 4 vkp, die nuke um Längen überholt haben. Nur leider haben das die User und leider auch die Medien noch nicht richtig registriert.

EDIT:
Code unbrauchbar gemacht