oxSecurity - Hacker Modul

Hallo zusammen,

da der OXID Shop immer mehr das Ziel von Hackern wird, haben wir, für die OXID Version ab 4.6 und 4.7.x ein Security PlugIn/Modul erstellt.

Das PlugIn erfasst versch. Arten von Angriffen und wertet diese mit mit PHPIDS aus.

Es gibt schon jetzt eine einfache Konfiguration der Lösung, die wie folgt aufgebaut ist

debug = “false”; Debuginformationen anzeigen
log_file = “false”; Intrusions in File loggen
log_db = “false”; Intrusions in Datenbank Loggen
send_email = “false”; Intrusion Email senden
email = " "; Emailadresse für Alerts
level_1 = “15”; ab wann soll geloggt werden
level_2 = “25”; ab wann sollen Emails gesendet werden
level_block = “50”; ab wann soll der User geblockt werden

Wenn ein Shop ein Opfer eines Hackers wird, erhält der Shopbetreiber, sofern gewünscht, eine eMail mit dem Hinweis des oder der Angriffe und des IMPACTS - also der Angriffsstärke.

Durch die oben genannten Einstellungen kann der Shopbetreiber einstellen ab wann ein PHP Prozess beendet werden soll - es macht ja keinen Sinn wenn man einem Hacker über Stunden freie Hand lässt.

Die anderen Einstellungen erklären sich sicher von selbst.

So sieht die eMail aus die ein Shopbetreiber erhält wenn ein Angriff erfolgte:

IP: xx.xx.xx.x 
Date: 2013-03-05T17:54:51+01:00 
Impact: 54 
Affected tags: xss csrf id rfe lfi sqli 
Affected parameters: REQUEST.test=%22%3EXXX%3Cscript%3Ealert%281%29%3C%2Fscript%3E, GET.test=%22%3EXXX%3Cscript%3Ealert%281%29%3C%2Fscript%3E, 
Request URI: /index.php?test=%22%3EXXX%3Cscript%3Ealert(1)%3C/script%3E 
Origin: xxx.xx.xx.xxx

Für die Weiterentwicklung des kostenloses Moduls suchen wir noch Mitentwickler, die Sicherheit wichtig finden und eigene Ideen einbringen wollen. Wir suchen aber auch Sponsoren die mit Geldspenden die Entwicklung fördern, zum Dank nennen wir diese auf itratos.de mit PR7 Vererbung.

Die PHPIDS Entwicklung übernimmt in unserem Haus der Web-Application Security Spezialist und Buchautor Herr Dr.-Ing. Mario Heiderich.

Hallo Timo,

für mich ist interessant, ab wann der Hacker eine Chance hat. Allerdings sollte die Info zunächst nicht öffentlich im Forum gepostet werden sondern an die security@ gehen, damit niemand kompromittiert wird.

Gruß

[QUOTE=Marco Steinhaeuser;118253]Hallo Timo,

für mich ist interessant, ab wann der Hacker eine Chance hat.
Gruß[/QUOTE]

Hallo Marco,

die hat er doch immer, sobald der Shop Online ist kann der Hacker wann auch immer angreifen.

Wenn der Hacker dann noch die Möglichkeit hat sich den CODE der Applikation zu ziehen, in dem Fall eine neue oder ältere OXID CE, dann kann er nach möglichen Lücken und entsprechende Scripte vorbereiten.

Open Source Programme werden gerne angegriffen, weil sich der Hacker mit einer Aktion einen sehr guten Namen in der Szene machen kann, er erwischt sofort z.B. 500 Projekte in einer Nacht.

Zu oxSecurity:

Jede Art von Aufruf wird ausgewertet, wenn etwas nach Angriff aussieht dann reagiert oxSecurity je nach Einstellung.

Die Einstellungen sollte man nicht zu hoch oder zu niedrig wählen, ist ähnlich wie bei den Sicherheitseinstellungen einer Firewall.

Beispiel:

level_block = “50”; ab wann soll der User geblockt werden

Wenn man hier 10 einstellt um den PHP Prozess zu beenden, dann könnten externe Anbindungen ein Problem bekommen die dem Shop per URL einen Status senden.
Wenn man 200 wählt dann kann man den Schutz auch gleich deaktivieren.

Tests haben gezeigt das ein Wert zwischen 35 - 50 gute ist, dies erkennt man auch an dem Beispiel

IP: xx.xx.xx.x
Date: 2013-03-05T17:54:51+01:00
Impact: 54
Affected tags: xss csrf id rfe lfi sqli
Affected parameters: REQUEST.test=%22%3EXXX%3Cscript%3Ealert%281%29%3C%2Fscript%3E, GET.test=%22%3EXXX%3Cscript%3Ealert%281%29%3C%2Fscript%3E,
Request URI: /index.php?test=%22%3EXXX%3Cscript%3Ealert(1)%3C/script%3E
Origin: xxx.xx.xx.xxx

Diese Auswertung sollte der Shopbetreiber dann, wenn es wirklich heftig wird, an seinen zuständigen Dienstleister senden - oder die LOG Datei komplett.
Der Dienstleister kann dann sofort reagieren und evtl. in Rücksprache mit OXID esales für ein Update sorgen.

Wir haben die Lösung schon bei einigen Shops im Einsatz, die sind überrascht was alles so passiert z.B. wenn sie schlafen, oder an Wochenenden / Feiertagen etc. Der Angriff auf einen Shop ist für den Hacker vorteilhafter als auf ein Joomla Projekt - im Shop gibt es vollständige Kundendaten die einiges Wert sind.

Interessantes Modul. Ab wann ist es erhältlich?

Yepp, würde mich auch interessieren…

Moin nochmal,

wenn ich das recht verstehe, wertet PHPIDS aus, wie viele Attempts über Input Parameter obfuscated sind. Das hat mit Sicherheit seine Berechtigung und dürfte eine sinnvolle Bereicherung sein. Allerdings dürfte es nicht vor einem Angriff schützen, wenn eine Sicherheitslücke bekannt ist und mit dem ersten Attempt gestartet werden kann, oder?

Gibt es denn bekannte Fälle erfolgreich gehackter Shops?

Noch ein Hinweis. Hier wird beschrieben, wie wir mit dem Thema umgehen:
http://wiki.oxidforge.org/Security

Teil dieser Policy sind Security Bulletins. Wenn diese veröffentlicht werden, empfiehlt sich natürlich immer ein Update.

Open Source Programme werden gerne angegriffen, weil sich der Hacker mit einer Aktion einen sehr guten Namen in der Szene machen kann, er erwischt sofort z.B. 500 Projekte in einer Nacht.

Ohne dazu eine Grundsatzdiskussion heraufbeschwören zu wollen: Das hat nichts mit Open Source vs. Commercial zu tun! Der Punkt ist hier die grosse Verbreitung. M$ Windows wird auch ganz gern angegriffen :wink:

Gruß

Mich würde so ein Modul auch interessieren (wann wird es denn veröfetnlicht? ), eventuell wäre hier ein kleines Kickstarter Projekt sinnvoll um Spendengelder zu sammeln oder ähnliches.

Hallo Michael,

wir geben es nächste Woche raus “kostenlos”
Es würde uns aber freuen wenn es z.B. Shopbetreiber gibt die sich bei uns melden und das Projekt mit einer Spende, natürlich gegen Rechnung, unterstützen.

Wichtig sind auch weitere Entwickler die eigene Ideen beisteuern und evtl. den einen oder anderen CODE schreiben.

@all, hier findet Ihr eine DEMO einer 4.7.3 CE

http://dev1-oxid.itratos.org/oxid4_7_shopsecurity/

mit folgenden Einstellungen:

; Start ids_config.ini file here
debug = "false"; Debuginformationen anzeigen
log_file = "true";	Intrusions in File loggen
log_db = "true"; Intrusions in Datenbank Loggen
send_email = "true"; Intrusion Email senden
email = "Meine@E-Mail"; Emailadresse für Alerts
level_1 = "3"; ab wann soll geloggt werden
level_2 = "40"; ab wann sollen Emails gesendet werden
level_block = "55"; ab wann soll der User geblockt werden

Mit einem Aufruf wie diesem

?test=%22%3EXXX%3Cscript%3Ealert%281%29%3C/script%3E

erzeugt Ihr einen IMPACT von 54.
Ab 55 wird der Aufruf geblockt - testet einfach mal ob Ihr es schafft.

TEST

@Marco, zu:

Das hat nichts mit Open Source vs. Commercial zu tun! Der Punkt ist hier die grosse Verbreitung. M$ Windows wird auch ganz gern angegriffen

Das stimmt schon, aber bei Angriffen hat man es oft mit Script-Kiddy zu tun, die wie in dem Howto beschrieben einfach mal etwas übern wollen und gewollt oder ungewollt einen Schaden anrichten.

Aber das nur am Rande, ich finde es einfach wichtig zu wissen ob man gerade ein Opfer ist der von einem Hacker oder mehr angegriffen wird.

Jeder schaut sich die Werte bei google Analytics & CO an und freut sich über steigende Besucherzahlen, es könnte aber auch ein Angriff über versch. Proxies sein - weil man eine Lücke nutzen will.

klasse!!! :smiley: schon ungeduldig

Hallo zusammen,

ich habe Euch das Paket hier vorbereitet und noch ein paar Infos bereitgestellt

http://forum.itratos.de/showthread.php?39230-Shop-Security-für-OXID-eShop-4.6.x-4.7.x-(CE-PE)

Die Studie zeigt das Sicherheit für den Endlunden noch wichtiger ist als Kundenbewertungen, die stehen auf Platz 2

Es würde uns freuen wenn Ihr Euch als FANs bei den unten genannten SMM Portalen für uns itratos eintragt.

Wurde heute schon von einigen angerufen und per eMail kontaktiert, danke für Eure Unterstützung und Euer Interesse.

Wir übernehmen extern die komplette Security Überwachung, dies wurde von einigen Shopbetreibern und Agenturen gewünscht die mit mir heute Kontakt hatten. Wenn wir im Rahmen der Leistung große Probleme feststellen, dann kontaktieren wir OXID für einen globales Securty Fix.

ZITAT:

"Dienstleistungen:

Wir bieten interessierten Shopbetreibern für eine Pauschale von 50 Euro zzgl. UST im Jahr die externe Security Überwachung."

was mich interessiert: was macht ihr denn dann anders (oder besser) als das modul?

@all, im Anhang das Modul, bitte gebt uns hier Feedback - spart Zeit beim Support

[QUOTE=domino;118398]ZITAT:

"Dienstleistungen:

Wir bieten interessierten Shopbetreibern für eine Pauschale von 50 Euro zzgl. UST im Jahr die externe Security Überwachung."

was mich interessiert: was macht ihr denn dann anders (oder besser) als das modul?[/QUOTE]

Hallo Volker,

wir arbeiten in dem Fall für den Shopbetreiber und erhalten die eMails möglicher Angriffe, der shopbetreiber muss sich darum nicht selbst kümmern.

Wenn sich der Verdacht bestätigt das der Shop angegriffen wird, dann nehmen wir telefonisch mit dem Shopbetreiber oder dem zuständigen Entscheider den Kontakt auf.

In dem Gespräch wird entschieden welche Schritte folgen, die können unterschiedlich sein z.B.

  • man klärt mit dem zuständigen Hoster ob er vorab die IP Region des Hackers sperren kann
  • bei einer älteren Shopversion könnte ein Update von Vorteil sein
  • bei einer neueren Shopversion könnte es nötig sein das man ein Security Fix erstellt
  • es könnte aber auch ein Angriff auf eine alte PHP, MySQL Version des Servers sein - dies muss man dann mit dem Hoster besprechen.

Wenn festgestellt wird das ein Fehler im Shop ausgenutzt wird, dann teilen wir unsere Ergebnisse dem Hersteller OXID mit, dieser muss ja dann die Möglichkeit haben Global reagieren zu können.

TOP! werd’ dann wohl demnächst zu euren kunden gehören

schonmal (auch aus marketingtechnischen gründen für beide seiten) gedanken über ein “security siegel” gemacht? :smiley:

[QUOTE=domino;118424]TOP! werd’ dann wohl demnächst zu euren kunden gehören

schonmal (auch aus marketingtechnischen gründen für beide seiten) gedanken über ein “security siegel” gemacht? :D[/QUOTE]

Hallo Volker,

freut mich zu hören.
Ja wir haben ein Siegel - siehe Modul Download &Supportbereich oder im Anhang

Hi Timo,

zunächst mal vielen Dank für die Veröffentlichung das Moduls.

Ich habe das Modul heute einmal ausprobiert und mir ist folgendes aufgefallen:

-CMS-Seiten-Abspeichern im Adminbereich wird als Impact von 100-140 (je nach Inhalt der CMS-Seite) erkannt und geblockt. Abspeichern ist bei aktiven Modul somit nicht möglich.

-Nach über 10 eingetragenen Zeilen in der Datenbanktabelle funktioniert der Report im Adminbereich nicht mehr - es erscheint nur noch die Shopstartseite. Nach dem Löschen der Zeilen 11-x aus der Datenbank erscheint der Report wieder ordnungsgemäß.

Das Siegel ist eine tolle Idee - kann das denn von allen verwendet werden, die das Modul einsetzen, oder ausschließlich von denen, die die externe Securityüberwachung durch itratos nutzen?

[QUOTE=nickname;118446]Hi Timo,

zunächst mal vielen Dank für die Veröffentlichung das Moduls.

Ich habe das Modul heute einmal ausprobiert und mir ist folgendes aufgefallen:

-CMS-Seiten-Abspeichern im Adminbereich wird als Impact von 100-140 (je nach Inhalt der CMS-Seite) erkannt und geblockt. Abspeichern ist bei aktiven Modul somit nicht möglich.
[/QUOTE]

Hallo nickname,

nichts zu danken, ich danke für den Test und das Feedback.

danke für den Hinweis, dies sind interne Aktionen die wir einmalig in die Ausnahmen aufnehmen müssen.

[QUOTE=nickname;118446]
-Nach über 10 eingetragenen Zeilen in der Datenbanktabelle funktioniert der Report im Adminbereich nicht mehr - es erscheint nur noch die Shopstartseite. Nach dem Löschen der Zeilen 11-x aus der Datenbank erscheint der Report wieder ordnungsgemäß.
[/QUOTE]

danke, ist mir gestern schon aufgefallen und steht schon auf der Liste

[QUOTE=nickname;118446]
Das Siegel ist eine tolle Idee - kann das denn von allen verwendet werden, die das Modul einsetzen, oder ausschließlich von denen, die die externe Securityüberwachung durch itratos nutzen?
[/QUOTE]

der Gedanke ist eigentlich das Shopbetreiber die auch den externen Service nutzen dieses Siegel nutzen können. Ich sehe aber wie sich viele schon bereiterklären ohne Gegenleistung das Projekt zu fördern.

Ich denke wir könnten das Siegel auch nur von der Verwendung des Moduls abhängig machen, ohne den externen Service nutzen und zahlen zu müssen.

[QUOTE=nickname;118446]Hi Timo,

-CMS-Seiten-Abspeichern im Adminbereich wird als Impact von 100-140 (je nach Inhalt der CMS-Seite) erkannt und geblockt. Abspeichern ist bei aktiven Modul somit nicht möglich.

[/QUOTE]

Hallo nickname,

so das CMS haben wir in den Ausnahmen mit aufgenommen, aber mir war es nicht möglich einen Wert von 140 zu erzeugen - was hast Du den versucht zu speichern.

Unsere Tests liegen zwischen 35 - 42 IMPACT - oder speicherst Du JS CODE im CMS mit ab?

"84.57.83.203",2013-03-11T14:29:11+01:00,38,"xss csrf rfe","REQUEST.editval.oxcontents__oxcontent%3D%253Cdiv

Mal eine ganz grundsätzliche Frage, generell dürfte ja jedem der schon mal in seine Logs geschaut hat klar sein das täglich massig blinde Angriffe auf eine Webseite niedergehen. 99% davon sind absolut ziellos, es geht den Leuten die das im grossen Stil betreiben ja nun auch weniger darum sich einen Namen zu machen als darum damit Geld zu verdienen was sie tun. In OXID selbst sind ja nun nur sehr wenige Sicherheitslücken bekannt, dann alles mögliche nach XSS (Crossitescripting), wie oben und sonst was zu klassifizieren ist ja schön und gut aber was bringt das? Eigentlich würde es doch voll und ganz ausreichen bekannte Lücken zu überwachen, die aber hoffentlich in der Installation nicht existieren weil der Betreiber seinen Shop dann schon gefixt hat. Ich meine man hat dann schön viele imposant aussehende Log Einträge darüber was am Tag so alles an einem probiert wird, aber das hat doch effektiv keinen IT-sicherheitstechnischen Vorteil.

Die meisten Shops die gehackt werden, werden Opfer durch Fehlkonfigurationen, durch Trojaner abgegriffene Passwörter, falsche Dateirechte (besonders bei Massenhostern) oder ähnliches.

Spielt man sich da nicht dann auch ein Stückweit Sicherheit vor? Die gröbsten und häufigsten Fehler liegen dann auch noch ausserhalb der OXID Applikation. Spontan fällt mir da die fehlende .htaccess im TMP Ordner ein (ja so Tabellen Cache Files sind was feines…), die offene PMA Installation im Webroot, die “Maintance” Scripte oder mein persönlicher Favorit beim netten Massenhoster von nebenan den Template Ordner auf 777 stehen zu haben.

Hallo acpi,

hast Du auf Deinem Rechner ein Virenschutzprogramm, oder sind Deine Server abgesichert, dann kann man sich ja auch fragen, warum dieser Aufwand.

ZU:

Eigentlich würde es doch voll und ganz ausreichen bekannte Lücken zu überwachen

Die Sicherheitslücken auflisten die es gibt ist etwas aus der Luft gegriffen u.a. würden sich potentielle Hacker über eine derartige Liste freuen.
Viele Lücken ergeben sich durch

  • Shop Version
  • genutzte PHP Version
  • genutzte MySQL Version

Ein Shop mit der gleichen Version könnte unter PHP 5.3.x keine Probleme haben, in einer PHP 5.2.9 wird er aber zum Opfer eines Hackers.
Wenn man die Lücken kennt muss man sie auch nicht auflisten, man behebt diese.

Oder will man gar nicht wissen ob man ein Opfer ist, also ich schon und viele Shopbetreiber die diese LOGs sehen, wollen die weiter bekommen.

ZU:

In OXID selbst sind ja nun nur sehr wenige Sicherheitslücken bekannt

Ist das Gut oder eher schlecht? Wenn OXID so am Markt vertreten wäre wie z.B. Joomla, dann würden wir bei Heise öfters etwas lesen.
Es geht hier ja auch nicht allein um OXID, was ist mit den ganzen Modulen externer Hersteller - sind die so sicher wie der Shop selbst?

Kleine Angriffe oder evtl. Fehler bei Eingaben der Besucher müssen weder erfasst, noch per eMail an den Shopbetreiber oder dessen Betreuer gesendet werden.
Bei Werten von 30 oder mehr sollte man aber mal kurz schauen was los ist.

Hallo Timo,

[QUOTE=itratosTeam;118528]Hallo acpi,
hast Du auf Deinem Rechner ein Virenschutzprogramm, oder sind Deine Server abgesichert, dann kann man sich ja auch fragen, warum dieser Aufwand.
[/QUOTE]

Dass hat aber jetzt meiner Meinung nach nichts mit dem Thema zu tun weil es eine ganz andere Baustelle ist. Zu meinem Background, ich habe 5 Jahre einen Honeypot betrieben und ausgewertet und war im Bereich Sicherheit längere Zeit sehr aktiv. Ich äussere mich jetzt nicht ohne Grund so kritisch zu diesem Thema.

[QUOTE=itratosTeam;118528]
Die Sicherheitslücken auflisten die es gibt ist etwas aus der Luft gegriffen u.a. würden sich potentielle Hacker über eine derartige Liste freuen.
Viele Lücken ergeben sich durch

  • Shop Version
  • genutzte PHP Version
  • genutzte MySQL Version

Ein Shop mit der gleichen Version könnte unter PHP 5.3.x keine Probleme haben, in einer PHP 5.2.9 wird er aber zum Opfer eines Hackers.
[/QUOTE]

Dinge wie PHP Version und Co. bekommt man auch ohne weiteres so raus, da schützt aber das Modul einen nicht vor. Das ist ziemlich Basic das zu ermitteln. Was die Shop Version angeht, was hindert mich z.B. daran einfach in die rev zu gucken?

[QUOTE=itratosTeam;118528]
Wenn man die Lücken kennt muss man sie auch nicht auflisten, man behebt diese.

Oder will man gar nicht wissen ob man ein Opfer ist, also ich schon und viele Shopbetreiber die diese LOGs sehen, wollen die weiter bekommen.
[/QUOTE]

Wenn du Opfer eines Angriff warst, ist es bereits zu spät und die häufigsten Gründe Opfer zu werden erfasst das Modul ja eben auch nicht (siehe voriges Post). Ich halte es aber für ein Problem, wenn sich ein Betreiber darauf ausruht das ein “IDS” im Hintergrund läuft.

Die meisten sind nicht in der Lage IDS Logs sinnvoll auszuwerten. Des weiteren nutzt es auch nur etwas wenn es wirklich greifen würde, dass wäre nur der Fall bei einem Angriff mit einem 0-Day (unbekannte Lücke), die dazu noch das eingestellte Level an Verdächtigkeit erreicht und zusätzlich irgendwo wirkt, wo sie die Einbindung des IDS noch erfasst. Diese Konstellation dürfte aber doch eher eine Rarität sein.

[QUOTE=itratosTeam;118528]
Ist das Gut oder eher schlecht? Wenn OXID so am Markt vertreten wäre wie z.B. Joomla, dann würden wir bei Heise öfters etwas lesen.
Es geht hier ja auch nicht allein um OXID, was ist mit den ganzen Modulen externer Hersteller - sind die so sicher wie der Shop selbst?
[/QUOTE]

Ich denke wenn es eine kritische Lücke in OXID geben würde, die auch aktiv ausgenutzt wird, würde man das auch auf Heise erfahren. OXID ist nicht nur CE, sondern auch ein Enterprise E-Commerce System und das ist bei ziemlich vielen namenhaften Shops im Einsatz. Dazu ist die Codebase zwischen EE/PE/CE die gleiche und so wenig verbreitet ist es auch nicht gerade.