Loading

Sicherheitslücke in Joomla!-Erweiterung

Posted in Google hacking, Sidetopics on July 13th, 2013
Tags: , , , , ,

Heute mal ein kleiner Artikel über eine Sicherheitslücke in einer Erweiterung von Joomla!. Ich schreibe darüber, weil man die Opfer sehr leicht auch über Google finden kann. Es geht um die Sicherheitslücke, die in der Packetstormsecurity Datenbank zu finden ist: Joomla Attachments Shell Upload

Um was geht es?

Die Erweiterung ermöglicht es Dateien auf Eure Webseite zu laden. Dabei wird allerdings kein Typ ausgeschlossen. Es ist also möglich jede Art von Datei über die Erweiterung auf den Webspace eurer Webseite zu laden.

Ganz schlimm wird es dann, wenn ein Internet-Krimineller eine php-Shell auf euren Webspace lädt. Das ist ein Dateiexplorer der dem Angreifer euren kompletten Webspace “öffnet”. Er kann sich darüber Dateien anschauen aber auch verändern oder gar auf eure Datenbank zugreifen und zwar selbst dann, wenn der Zugriff auf den Webspace selbst beschränkt ist. Denn die Shell liegt ja auf genau diesem.

Hier einmal ein Video in dem man sieht, wie leicht man mit so einer Shell Schabernack treiben kann: Using C99 shell hacking.

Du glaubst das sei nicht wichtig, weil deine Seite eh keiner kennt?

Hier kann ich nur sagen: Bitte täusch dich da mal nicht. Man kann über Google über einen sehr einfachen Suchstring potentielle Opfer finden. Dazu sucht man einfach nach.

inurl:”index.php?option=com_attachments”

Direkt zu Google

Schnell kann in dieser Suche auch Eure Webseite drin sein.

Was ich ganz gut finde: Joomla! reagiert auf solche Sicherheitslücken in Erweiterungen sehr charmant. Auf der Seite der Erweiterungen in der Joomla!-Datenbank wird für dieses Plugin eine Warnung ausgegeben.

Auch der Hersteller des Plugins hat wohl bereits reagiert und einige Sicherheitsabfragen für den Upload von Dateien hinzugefügt. Joomla! selbst hat dazu einen Blogartikel geschrieben.

Aktuell würde ich aber jedem empfehlen die Erweiterung erst einmal zu deaktivieren, bis auch Joomla! Entwarnung gibt und das Plugin auf deren Seite wieder offiziell angeboten wird.

Das hab ich jetzt deinstalliert, was sollte ich außerdem tun?

Du solltest unbedingt nachschauen ob sich auf deinem Webspace vielleicht bereits eine Shell befindet. Eine einfache Möglichkeit dazu wäre zum Beispiel die suche nach “<?php” in dem Verzeichnis der Attachements. Wenn Du dabei fündig wirst, ist eine komplette Forensik von dem Webspace vorzunehmen. Dazu nimmst du die Webseite besser erst einmal offline, denn: Sollte die Webseite von Dritten infiziert worden sein, dann besteht eine akute Gefahr für deine Besucher.

Auch dein Computer könnte dann bei einem Besuch auf deiner eigenen Webseite mit einem Virus infiziert worden sein. Solltest du dir hier unsicher sein empfehle ich einen Besuch auf check-and-secure.com.

[1 Comment »]

Wie finden Angreifer eigentlich Ihre Opfer?

Posted in cms-systeme, custom search, Google hacking on June 30th, 2011
Tags: , ,

Ja mancher mag sich das wirklich fragen. Man erstellt sich eine eigene Seite anhand eines Tutorials oder ganz selbst oder man nutzt ein gängiges CMS und irgendwann wird man angegriffen. Nach dem ersten Schock stellt man sich dann meistens die eine Frage: Warum ich?

Diese Frage ist eigentlich ganz einfach zu beantworten: Weil du unsichere Software auf der Webseite benutzt. Bei den meisten Angriffen im Internet geht es nämlich nicht darum dem Webseitenbetreiber zu schaden, sondern um von dem Server des Seitenbetreibers Spam zu versenden, weitere Systeme anzugreifen oder auch Viren zu verteilen.

Angreifbare Systeme sind dabei meist sehr einfach zu finden. Dazu benötigt man nur die richtigen Patterns, mit der man die Google-Suche füttern kann. Für die selbst geschriebenen Seiten haben ich für das Projekt Der WebWart einen bereits einen entsprechenden Artikel geschrieben: Remote-File-Inclusion / Local-File-Inclusion – Warum ich?

Dort wird sehr einfach erklärt warum man auch mit einer eigenen Webseite schnell zum Angriffsziel für Remote-File-Inclusion und Local-File-Inclusion-Angriffe werden kann und was man dagegen tun kann. Allerdings fehlt noch ein Tipp in diesem Artikel: Parameter verstecken!

Man kann die URL einer Webseite so umschreiben, dass diese über eine Google-Suche, die zum Beispiel über die inurl-Suche gemacht wird, nicht als PHP-Script mit Parametern erkannt wird. Damit macht man dann aus ‘index.php?seite=start’ einfach ‘/start’ . Der Suchstring ‘inurl:php?page=home’ findet diese Seite dann einfach nicht mehr. Benötigt wird hierzu nur die installierte Apache-Mod mod_rewrite und eien entsprechende Regel. Das Modul wird ausführlich auf apache.org erklärt. Für das genannte Beispiel sähe es wie folgt aus:

RewriteEngine on
RewriteRule ^/(.*)$ /index.php?seite=$1

Aber nicht nur mit der Programmierung und dem Einsatz einer eigenen Software begibt man sich in diese Gefahr. Auch angreifbare CMS kann man über Google recht gezielt suchen. In zum Beispiel der exploit-db findet man jede Menge Angriffsvektoren und kann daraus sehr einfach Patterns für die Google-Suche bilden. Zum Beispiel für diesen Exploit: Joomla Component (com_sef) RFI

Über die Sicherheitslücke kann man ein beliebiges externes Skript in die Seite einbinden und damit sehr großen Schaden anrichten. Das Sicherheitsloch ist hier die Variable ‘mosConfig.absolute.path’ die zum includieren von Dateien im Joomla!-System verwendet wird. Man kann nun über Google gezielt nach Joomla!-Versionen suchen, die die Komponente com_sef einsetzen. Das geht so einfach, weil die Information mit in der URL drin steht ‘ption=com_sef’. Der Google-String sieht dann so aus:

inurl:'option=com_sef' + inurl:'mosConfig.absolute.path='

Direkt zu Google
Die Ergebnisse kann man dann über ein Script automatisiert durchlaufen lassen und findet damit sehr schnell die Angreifbaren Versionen heraus.
Ähnliches kann man machen um sich gezielt Content-Management-Systeme aus Google zu ziehen. Viele System verraten schon über die URL was Sie sind. So kann man WordPress-Installation über

inurl'wp-admin/index.php'

finden. Den Verzeichnis-Prefix ‘wp-‘ verwendet sonst kein CMS. Gleiches funktioniert zum Beispiel auch für Joomla! mit

inurl'administrator/index.php'

Die meisten anderen CMS verwenden als Namen für das Administrationsverzeichnis ‘admin’, daher findet man darüber sehr eindeutig Joomla!-Installationen. Warum sind Angreifer interessiert an den Administrationsverzeichnissen? Ganz einfach: Auf die Anmeldeseiten kann man sehr leicht einen Brute-Force-Angriff starten. Die meisten CMS sind dagegen nicht abgesichert. Ist man als Angreifer dann einmal im Administrationsbereich drin, kann man sehr schnell Zugriff auf den ganzen Webspace/Server bekommen. Man platziert zum Beispiel einen Shell-Code in einer Template-Datei.

Goldene Regeln:

  1. Benutzereingaben niemals ungeprüft weiter verarbeiten. Wenn man nur bestimmte Eingaben erwartet, dann sollte man diese auch Prüfen.
  2. Benötigt man die Funktion um externe Dateien zu laden überhaupt? Wenn nicht kann man entsprechende Variablen für PHP abschalten. Für php4 ‘allow_url_fopen’ für php5 ‘allow_url_include’ und ‘allow_url_include’.
  3. Versteckt eure Angriffsvektoren zum Beispiel über mod_rewrite.
  4. Aktualisiert eure CMS regelmäßig. Das schlimmste ist eine Software die man hoffnungslos auf dem Webspace/Server veralten lässt.
  5. Nehmt Dateien und Verzeichnisse die nichts in der Google-Suche verloren haben aus dem Index raus. Das könnt Ihr über eine robots.txt steuern oder gleich die ganze Datei oder das Verzeichnis mit eienr .htaccess für den Zugriff sperren.
[ Leave A Comment »]

Die Zugangsdaten der anderen.

Posted in Google hacking on June 20th, 2011
Tags: ,

Mancher von euch überlegt jetzt sicher: ‘Hatten wir das nicht schon?’ Das stimmt auch fast, ich habe bereits einen ähnlichen Artikel geschrieben. In diesem ging es aber speziell um pastie.org. Das Portal ist aber nicht das einzige dass zum ablegen von Zugangsdaten genutzt wird. Auch kompromittierte Internet-Seiten oder Datei-Upload-Dienste die nicht korrekt prüfen was man hoch lädt werden als sogenannte Drop-Zone missbraucht.

Wer meinen alten Artikel (pastie.org – Das Portal zu den Zugangsdaten der Anderen.) aufmerksam gelesen hat und auch fündig geworden ist, wird hier wahrscheinlich nichts viel neues finden. Dennoch will ich es einmal erklären.

Der Inhalt der Dokumente sah immer so aus

http://benutzername:passwort@domain.de/url

oder so

Webseite: http://domain.de/url
Benutzername: Benutzername
Passwort: Passwort

Mit der URL steht uns also eine wichtige Information zur Verfügung. Diese kann man auch gezielt abfragen. Als Beispiel nehmen wir jetzt einmal Amazon. Die deutsche Anmeldeseite hat folgende URL ‘https://www.amazon.de/ap/signin’. Genau danach suchen wir jetzt einfach mal bei Google

"amazon.de/ap/signin"


Direkt zu Google

Schon damit fallen uns die ersten Zugangsdaten in die Hände. Das Spiel lässt sich nun beliebig weiterspielen. Fast jedes Portal bietet in der URL genügend Eindeutigkeit um damit gezielt nach diesen Dateien zu suchen. Ein weiteres Beispiel ist Ebay. Allerdings findet hier die reine Suche nach der Login-URL zu viele schlechte Ergebnisse. Auch das hinzufügen von “Passwort” oder “Benutzername” führt nicht zum gewünschten Ergebnis. Was also tun? Ganz einfach. In vielen Fällen werden diese Dateien als TXT-Dateien abgelegt. Damit lässt sich die Suche dann genügend verfeinern um gute Ergebnisse zu erhalten.

"signin.ebay.de"  filetype:txt

Direkt zu Google

Also hier noch einmal die Warnung: Eure Zugangsdaten sind wie euer Haustürschlüssel. Hütet diese. Auf dem Blog des Internet-Projektes ‘Der WebWart‘ das ich mit 3 weiteren Personen betreibe haben wir vor kurzem einen ausführlichen Artikel zur Passwortsicherheit geschrieben. Ich empfehle: Lesen!

Um herauszufinden ob euer Passwort bereits im Internet zu finden ist empfehle ich einfach mal danach zu googlen.

[ Leave A Comment »]

Google hacking database

Posted in Google hacking on January 13th, 2011

Ein paar solcher Sachen habe ich selbst hier ja auch bereits selbst gefunden und gepostet. Eine größere Datenbank an “Google-Hacks” findet Ihr aber in der Google hacking database.

Die Google  hacking database ist ein Teil der Exploit-DB und zeigt sehr viele Sicherheitslücken auf die man durch Google finden kann. Dabei geht es nicht rein darum unsichere Skripte ausfindig zu machen sondern auch wie man Zugangsdaten oder ungewollt für alle erreichbare Bereiche einer Webseite im Internet findet.

Schuld daran sind meist unbedacht oder fahrlässig handelnde Webmaster.

  • Passwort-Dateien werden einfach mit auf die Webseite gelegt, in der Hoffnung, das Google diese nicht findet.
  • Administrator-Bereiche werden oft einfach offen gelassen, weil die CMS ja bereits eine Passwortsicherung mitbringen. Das diese Ebenfalls Sicherheitslücken enthalten können, wird nicht bedacht.
  • Bereiche die nicht für die Öffentlichkeit gedacht sind werden teilweise nicht mal in der robots.txt erwähnt. Google wird also auch darin suchen. Noch besser wäre hier aber natürlich ebenfalls ein Passwortschutz über .htaccess.

Wenn Bedarf besteht, kann ich einzelne Artikel aus der Google hacking database gerne übersetzt mit ausführlicher Erklärung hier reposten. Ihr könnt mir dazu einfach Feedback über die Kommentar-Funktion oder das Kontakt-Formular geben.

[ Leave A Comment »]
Blogverzeichnis - Blog Verzeichnis bloggerei.de Blogverzeichnis