Die Begriffe Remote-File-Inclusion und Local-File-Inclusion beschreiben Standard-Angriffsarten auf verschiedene Websysteme. Über diese Angriffe wird Quellcode in ein Websystem eingeschleust, der  nicht dafür vorgesehen ist, auf dem Webserver eigene Befehle auszuführen.

Wie geht das?

Remote-File-Inclusion (RFI)

Als Grundlage für einen dieser Angriffe liegt immer der gleiche Programmierfehler vor. Eine Variable, die über die URL oder einer anderen Anfrageart übergeben wird, wird dazu verwendet den Inhalt für die Darstellung der Webseite dynamisch nachzuladen. In der Eigenprogrammierung ist ein Standardfall, zum Beispiel die Übergabe der aktuellen Seite in der URL.

Beispiele:

http://example.com/index.php?page=aktuelleSeite

http://example.com/index.php?id=aktuelleSeite

Diese Variable wird dann dazu genutzt, den Inhalt für die Seite dynamisch vom Webspace zu laden. Das erfolgt dann auf solche Weise

...
include($_GET['page'].'php');
...

oder auch so

...
$page = $_GET['page'];
include($page.'php');
...

Hier kann nun ein Angreifer einen beliebigen Dateinamen mitgeben, den das Skript ohne Prüfung ebenfalls includiert. Ein Angriff würde bei diesem Beispiel folgendermaßen aussehen

http://example.com/index.php?page=http://der-webwart.de/blog/impressum/?

und dazu führen, dass auf Ihrer Webseite der Inhalt von unserem Impressum angezeigt wird. Auf die gleiche Weise kann ein Angreifer auch eine böse Textdatei. Die kann ein PHP-Dateimanager (PHP-Shell) sein, der dann auf Ihrem Webserver ausgeführt wird. Der Angreifer hat damit vollen Zugriff auf Ihren Webspace.

Jetzt könnte man denken: Ok, dann prüfe ich einfach, ob die Datei bei mir auf dem Server/Webspace existiert oder schalte die entsprechenden PHP-Variablen ab, die verhindern, dass externe Inhalte includiert werden können. Das wäre wie folgt unter PHP4 ‘allow_url_fopen = off’ und unter PHP5 ‘allow_url_include = off’ möglich. Es ist natürlich generell zu empfehlen, immer mit der neuesten PHP-Version zu arbeiten.

Local-File-Inclusion (LFI)

Das behebt das Problem aber nur zum Teil. RFI-Angriffe wären damit tatsächlich verhindert, was aber noch möglich ist, sind LFI-Angriffe. Dabei legt der Angreifer den Schadcode in verschiedenen Dateien auf Ihrem Server ab. Es gibt ein paar Dateien, die Angaben vom Besucher der Webseite direkt übernehmen. Dazu gehören zum Beispiel die Apache-Access-Logs. In diesen wird meistens mitprotokolliert, was der Besucher vom Server angefragt hat, mit welchem Browser (User-Agent) er arbeitet und woher (->Referer) er kommt.

Alle diese Angaben kann der Besucher aber auch selbst bestimmen. So ist es möglich, dass auch im User-Agent der PHP-Quellcode mitgegeben werden kann. Einfach ändern kann man diese Angaben beispielsweise mit dem Firefox-Plugin ‘Modify Headers’. In meinem Beispiel schreibe ich in den User-Agent nun ‘<?php echo ‘test’; ?>’. Das steht dann später in den Access-Logs so drin:

x.x.x.x - - [09/Jun/2011:12:16:45 +0200] "GET/x.php HTTP/1.1" 200 456 x.x "-" "" "-"

Ruft man das angegebene Skript nun wie folgt auf

http://example.com/index.php?page=/var/log/apache2/access.log

wird der dort mitgegebene PHP-Code ausgeführt. Der Angreifer kann hier nun einen beliebigen PHP-Code mitsenden. Zum Beispiel könnte er mit einem Befehl erst einmal einen PHP-Dateimanager auf dem Webspace ablegen, um dann wiederum einfach und komfortabel auf dem Webspace arbeiten zu können.

Warum ich?

Einige werde sich jetzt fragen, warum ich? Ich habe mir hier doch nur eine eigene, private und selbst geschriebene PHP-Seite erstellt. Warum greift man mich denn an?

Das ist sehr einfach zu beantworten: Bei den meisten Angriffen im Internet geht es nicht gezielt darum, dem Webseitenbetreiber zu schaden. Vielmehr will man den Besuchern des Betreibers schaden. Ein Angreifer kann jetzt auf der betroffenen Seite Schadcode verbreiten, eine Phishing-Seite bereitsstellen oder Spam-Emails versenden. All dies dient nur seinem Zweck und hat nichts mit einer persönlichen oder geschäftlichen Abneigung gegenüber dem Seitenbetreiber zu tun.

Und wie bin ich ins Visier der Angreifer geraten?

Die Angreifer können bequem nach Ihren Opfern suchen. In dem hier ausgeführten Beispiel wird immer die Variable $_GET['page'] verwendet. Diese wird in einigen Internet-Tutorials verwendet und ist damit ein guter Anhaltspunkt bei der Opfersuche. Die Variable ist bei einem Besuch Ihrer Webseite im Browser zu sehen und auch in den entsprechenden Links hinterlegt. Google erkennt ebenfalls diese Variable und indexiert die URL genau so.

In der Google-Suchmaschine kann man dann gezielt danach suchen. Hier ist nicht nur die Eingabe von Suchbegriffen möglich, die dann im Inhalt der Seite gesucht werden, sondern auch das gezielte Suchen nach bestimmten URL-Bestandteilen. Der Angreifer kann also vorher bei Google folgendes eingeben:

inurl:'index.php?page='

Als Ergebnis erhält er viele Internet-Seiten, die genau diese Variable verwenden. Durch Ausprobieren, findet der Angreifer dann die unsicheren Seiten heraus und kann diese nun angreifen.

Und wie sichere ich mich jetzt dagegen ab?

In der Eigenprogrammierung ist es das A und O, dass alle Eingaben, die vom Benutzer angegeben und im Skript verwendet werden, entsprechend geprüft werden. Im Falle einer PHP-Seite mit einer fixen Anzahl an dynamisch zu ladenden Seiten, ist die sicherste Variante der ‘switch’:

$page = $_GET['page'];
switch($page) {
    case 'kontakt': include('contact.php');
                    break;
    case 'impressum': include('impressum.php');
                      break;
   default: include('home.php');
}

Damit können auch wirklich nur Inhalte geladen werden, die vom Programmierer vorgesehen sind. Im Falle einer nicht vorhersehbaren Anzahl an dynamisch zu ladenden Seiten, kann man folgende Punkte beachten:

• Ein bestimmtes Muster vorgeben, dass die Seitennamen erfüllen müssen.
• Alle Seiten nur aus einem bestimmten Ordner laden.
• Nur lokale Seiten zulassen.

In der Verarbeitung könnte das dann folgendermaßen aussehen:

if (file_exists('pages/'.$page.'.php');) {
    if ((substr($page, 0, 5) == 'page.') &&
        (preg_match('/^[a-z]+$/', substr($page, 6)))) {
        include('pages/'.$page.'.php');
    } else {
        include('pages/page.home.php');
    }
} else {
    include('pages/page.home.php');
}

So wird überprüft, ob die Datei lokal existiert, ob die ersten 5 Zeichen ‘pages.’ entsprechen und ob die restlichen Zeichen ab Stelle 6 nur kleine Buchstaben sind. Damit kann man keine Sonderzeichen mehr mit angeben.

Bin ich sicher, wenn ich ein CMS nutze?

Ganz klar: Nein. Auch in Content Management Systemen gibt es immer wieder Sicherheitslücken. Wie viele das teilweise sind, kann man in einer zentralen Datenbank, wie zum Beispiel der Exploit-Database nachprüfen. Hier tauchen auch immer wieder RFI und LFI-Lücken auf.

Bei der Nutzung von einem CMS ist es daher unbedingt notwendig, Folgendes zu beachten:

• Sicherheitsmaßnahmen (Dateirechte anpassen, Passwortschutz auf bestimmte Verzeichnisse) die vom Hersteller empfohlen werden, durchführen.
• Regelmäßig und in kurzen Abständen überprüfen ob es eine Aktualisierung für das genutzte CMS gibt und diese einspielen.
• Regelmäßig überprüfen ob die eigene Webseite kompromittiert wurde. Hier kann man zum Beispiel täglich kontrollieren welche Dateien sich auf dem Webspace geändert haben.

Viele CMS-Hersteller bieten als Hilfe dazu entsprechende News-Seiten an. Dort werden neue Versionen veröffentlicht, aktuelle Sicherheitslücken beschrieben und auch Gegenmaßnahmen erklärt. Wenn Ihr CMS-Hersteller so etwas nicht anbietet, ist es eine Überlegung wert, das CMS zu wechseln.

Das ist mir alles viel zu kompliziert!

Wer sich damit gar nicht beschäftigen will oder kann, der ist bei uns genau richtig aufgehoben. Wir bieten genau diesen Service an. Wir sichern Ihre CMS-Installation grundsätzlich ab, machen regelmäßig die Aktualisierungen für Sie, stellen Lösungen bereit, wenn Ihr CMS-Hersteller noch nicht reagiert hat und machen Ihren Webspace wieder sauber, wenn es schon zu spät ist, denn …

uns interessiert’s!