Was man aus verblüffenden Penetrationstests lernen kann

Können Penetrationstests uns überhaupt verblüffen? Je nachdem wer und wie sie durchgeführt werden, können sie dich zum Lachen bringen, oder zum Weinen. Hoffen wir in diesem Beitrag eher auf die erste Variante. Für alle, die mit dem Begriff nichts anfangen können möchte ich keine Kure Definition geben. Doch vorher warum das Ganze?

Yaseen Ahmed hat eine wunderbare Antwort auf Quora.com geschrieben zu einer Frage, die dem Blogtitel ähnelt:

What are some intriguing pentesting stories?

Ich möchte beide Geschichten, die er erzählt kurz in die deutsche Sprache bringen und dann auf die Probleme und Lösungen eingehen, damit dir das nicht ebenso passiert. Doch vorher klären wir kurz was ein Penetrationstest überhaupt ist.

Was ist ein Penetrationstest?

Kurz gesagt: Ein Penetrationstests wird das systematische Ausprobieren von Angriffen auf ein oder mehrere Ziele beschrieben. Das ganze wird mit Hilfe spezieller Software so realisiert, dass die eintreffenden Daten strukturiert abgelegt und im besten Falle, in Form eines schönen Berichtes, exportiert werden. Unabhängig von den technischen Raffinessen hinter jedem einzelnen Angriff natürlich, die zum Teil in die Tausende gehen können. Je nach Art und Weise des Vorhabens natürlich.

Wenn die Bank die Hosen runter lässt

Webanwendungen sind seit längerer Zeit angesagt. Nur selten ist der User alleine und offline auf seinem PC unterwegs, oder? So ist es meistens, aber auch das Bankgeschäft hat sich geändert. Ich hab vor langer Zeit sogar noch Papierüberweisungen geschrieben, aber das ist wirklich 10 Jahre her, wenn nicht sogar noch länger. Heute nutzen wir alle meistens Online Banking, nicht weil es sicher ist, oh nein! Es ist bequem vom Sofa aus Überweisungen zu tätigen. Aber genau diese Bequemlichkeit kann Probleme mit sich bringen.

Das Fundament des Problems

Damit deine Bank dir Online Banking zur Verfügung stellen kann, muss sie einen Webserver im Internet erreichbar haben. Dieser sollte eine Bankinganwendung installiert haben, die über einen Webserver wie Apache, nginx oder IIS, verfügbar ist. Du bist aber nicht der einzige Kunde und damit die Bank zwischen den vielen Kunden unterscheiden kann, muss sie dich zur Authentifizierung zwingen. Du musst deinen Benutzernamen und dein Passwort eingeben und erst dann solltest du auf dein persönliches Konto kommen. Soweit so gut.

Was läuft schief?

HTTP RequestBesagte Bankinganwendung kann schlampig entwickelt worden sein. Ein gewöhnliches Formularfeld hat ja meistens ein paar Eingabefelder und einen Absenden-Button. Die Daten, die vom Benutzer eingetippt werden, können auf zwei unterschiedliche Wege an den Server geschickt werden:

  • GET
  • POST

Achte auf die Unterschiede an Hand der URL erkennen. Hat die URL plötzlich viele seltsame Zeichen zu verbuchen, so handelt es sich um einen GET Request. Hier ein Beispiel:

http://www.die-fail-bank.ohnein/index.php?username=heinz&password=pw1234

Bei einem POST Request sieht man diese Parameter nicht. Und genau hier liegt die Gefahr. Die von Yaseen Ahmed erwähnte Bank hat jedem Zugang zum Konto gewährt, der lediglich den usernamen ausgefüllt an den Server sendet. Natürlich geht das auch über POST, aber ich denke mit dem GET Request sieht man dies besser, denn es ist erschreckend, dass man über die URL:

http://www.die-fail-bank.ohnein/index.php?username=heinz

einfach so auf das Konto von Heinz zugreifen kann, ohne Passworteingabe?

Lösung

Die Lösung an der Stelle ist nur dann ohne weiteres klar, wenn der Programmcode dahinter bekannt ist. Wir könnten beispielsweise bei einem PHP Programm beide Felder abfragen:

if(isset($_GET['username']) && (isset($_GET['password'])))
{
$pruefungsErgebnis = pruefe_username_und_passwort();
if($pruefungsErgebnis == true)
{
zeige_konto_an($_GET['username']);
}
else
{
zeige_login_schlaegt_fehl();
}
}
else
{
echo "zu wenig angaben! bitte username und passwort angeben";
}

Blog aktiv unterstützen

Devisenhandel mit persönlichem Wechselkurs

Banken haben es wohl in sich. Zumindest handelt auch die zweite Geschichte von einer Bank. Dieser Fall hier lässt nämlich Manipulationen zu. Das heißt, sobald sich ein User authentifiziert und beispielsweise Devisenhandel betreiben möchte, kann er während einer Transaktion den Wechselkurs manipulieren. Ein Beispiel:

  • Ohne Manipulation: Du kaufst 100 USD und bezahlst dafür 90 Euro. Der Kurs ist damit 0,90 beim Kauf.
  • Mit Manipulation: Du kaufst 100 USD und bezahlst dafür 9 Euro. Die Anwendung hat dich den Kurs von 0,90 auf 0,09 manipulieren lassen.

Wie kann man das Problem lösen?

TamperDataZunächst ist die Frage: Wie sieht die momentane Implementierung aus? Das kann ich auf Grund der fehlenden Informationen leider nicht wissen. Aber ich kann von folgendem Szenario ausgehen:

Das Formular, welches die Konfiguration für die Order beinhaltet, hat wohl ein verstecktes Formularfeld für den Kurs. Bei der Erzeugung des Formulars hat der Server vermutlich den aktuellsten Kurs mit an das Formular geschickt, damit der Kunde zu genau diesem “eingefrorenem” Kurs kaufen oder verkaufen kann. Geeignete Tools können die Daten kurz vor dem Versand abfangen und passend manipulieren. Das versteckte Feld also von 0,90 auf 0,09.

<form action="post" method="createOrder">
<input name="usd" type="text" value="Hier die USD eintragen!">
<input name="kurs" type="hidden" value="0.90">
<input type="submit" name="Order aufgeben">
</form>
<p>Aktueller Kurs: <strong>0.90</strong></p>

Das Formular sendet die Daten an den Server also zurück und zwar an die Funktion createOrder, die dann serverseitig in PHP oder einer anderen Sprache die Order durchführt. Wir können die Daten aber auch abfangen und speziell das Attribut value beim Input Feld mit dem Namen kurs ändern. Dazu braucht man auch keine großen Programmierkenntnisse. Es reicht das TamperData Plugin für Firefox völlig aus. Ich nutze es meistens zu Debugging Zwecken bei der Entwicklung.

Lösung

Ich speichere einfach den Kurs, den ich an den Kunden übermittle zusätzlich eingefrohren in einer temporären Datenbank ab. Schließlich übermittle ich den Kurs an den Kunden ja nur, damit er diesen kennt. Kommt ein POST Request zurück und der Kurs hat sich verändert, so wird die Order verworfen. Andernfalls passt alles und die Order ist gültig.

Fazit

Durch Penetrationstests anderer und deren Berichte kann man sehr viel lernen. Beide Beispiele in diesem Beitrag fallen unter die OWASP Top10, also die Sammlung der Sicherheitslücken bei Webanwendungen, die am häufigsten vorkommen. Natürlich kann man sich die Liste selbst anschauen und trocken durchgehen, aber anschauliche Beispiele wie diese hier helfen dir beim nächsten Mal daran zu denken, wie du es richtig machen kannst. Augen auf bei der Webentwicklung!

Bücher zum Thema

 

Beitragsbild: Apache Helicopter Firing Rockets verändert, von Defense Images – CC BY-SA 2.0

Artikel teilen:

Kommentar verfassen