Seit letztem Freitag ist eine Sicherheitslücke in ASP.NET bekannt und in diversen Blogs und Tweets heisst es, dass man unbedingt den Workaround einspielen soll. Doch was steckt hinter dieser Sicherheitslücke?
Die Attacke wird bekannt
Letzte Freitag ist unter dem etwas kryptischen Titel "Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps” eine Sicherheitslücke in ASP.NET bekannt geworden. Da ich mich mit Verschlüsselung und co. nicht genau auskenne, werde ich es in meinen einfachen Worten wiedergeben, wie ich es selbst verstanden habe. Das bedeutet aber auch, dass hier Mist stehen könnte ;)
Der Viewstate oder irgendwelche ASP.NET Sessions werden im Cookie als Hash gespeichert. Um die Sachen wieder zu entschlüsseln wird der Machine Key von .NET genommen. Leider ist die Implementation von dem Verschlüsselungsalgorithmus anfällig.
Ich habe ein super, genialen Blogpost gefunden, der allgemein die gesamte Attacke beschreibt und nutze das auch selber als Quelle.
Die Attacke
"Oracle” hat nichts mit der Firma Oracle zutun, sondern wird in der Verschlüsselung verwendet. Der Angriff der aktuell gefahren wird, ist auch als "Oracle Padding” bekannt. Die "Pad Buster” Attacke selbst ist sehr gut in diesem Blogpost beschrieben. Ganz grundsätzlich werden immer Blöcke mit einer festen Anzahl an Byte gefüllt, so z.B. hier als die Wörter "FIG”,”BANANA”, "AVOCADO”, "PLANTAIN” & "PASSIONFRUIT”. Die "gepadded” Varianten müssen entsprechen noch mit Füllbytes ausgefüllt werden:
Im ASP.NET Universum schickt der Angreifer irgendwelche Hashs an eine bestimmte Adresse (komm ich weiter unten noch genauer drauf).
- Wenn der Webserver valide & richtig "gepadded” Daten erhält bekommt der Aufrufer die Antwort (HTTP 200)
- Wenn es nicht richtig "gepadded” wird, dann wird ein Fehler zurück gegeben (HTTP 500)
- Wenn der Webserver zwar valide Daten, aber nicht richtig "gepadded” Daten enthält wird meist eine CustomErrorPage mit HTTP 200 zurückgegeben.
Nach und nach kann so der Angreifer durch einen Fehler im Framework den Key zum Hashen erraten. Wie gesagt, dass nur ganz grob. Genauer wird es hier.
Microsofts Reaktion
Das Microsoft Security Research & Defense hat einen allgemeinen Blogpost zur Lücke veröffentlicht. ScottGu hat hinterher noch einen "entwicklernaheren” Blogpost veröffentlicht. Es gibt auch ein .vbs Script mit dem man im IIS checken kann, ob irgendwelche Anwendungen betroffen sind.
Die Lösung/Workaround die Microsoft vorschlägt
Der Workaround klingt erst mal seltsam. ALLE Fehler die in der Webanwendung auftreten sollen ein und dieselbe Fehlerseite zurückliefern.
In ASP.NET V1.0 bis ASP.NET V3.5 in der web.config:
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</configuration>In ASP.NET ASP.NET V3.5 SP1 & ASP.NET 4.0 in der web.config:
<configuration>
<system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
</system.web>
</configuration>Die Error.aspx:
<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
void Page_Load() {
byte[] delay = new byte[1];
RandomNumberGenerator prng = new RNGCryptoServiceProvider();
prng.GetBytes(delay);
Thread.Sleep((int)delay[0]);
IDisposable disposable = prng as IDisposable;
if (disposable != null) { disposable.Dispose(); }
}
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
An error occurred while processing your request.
</div>
</body>
</html>Zur Erklärung:
Egal ob ein Serverfehler wegen 404 oder 500 auftritt, es wird immer dieselbe Fehlerseite und Meldung zurückgegeben. Eine kleine Besonderheit um den Angreifer die Informationsquelle zu kappen: Beim Aufruf der Error.aspx wird eine zufällige Verzögerung verursacht.
Wozu das?
Wie weiter oben beschrieben, benötigt der Angreifer Informationen, ob der gehashte Wert komplett falsch war (HTTP 500) oder so nur nicht vorhanden (Fehlerseite, aber HTTP 200). Wenn man nun alle Fehler auf dasselbe führt weiß der Angreifer erst einmal weniger. Allerdings könnte der Angreifer anhand der Reaktionszeit des Server (vll. (?) ich bin kein Experte ;) ) schätzen, ob es HTTP 500 wäre oder nicht. Daher die zufällige Zeit zur Reaktion. So sollte der Angreifer nie genau wissen, ob der Hash langsam in die richtige Richtung geht oder nicht.
Das klingt alles recht abstrakt... betrifft mich das?
Je nachdem wie die Anwendung gestrickt ist, kann das SEHR große Auswirkungen haben. Von den Entdeckern der Lücke gibt es ein recht beeindruckendes Video. Dabei knacken Sie recht schnell den Machine Key und erstellen sich einfach ein Cookie auf dem Client, mit dem man als SuperUser in .NET Nuke angemeldet ist:
Ok... "Sessions” kapern... ScottGu schrieb das man auch .config Files runterladen könnte?!
In ScottGus Blogpost findet sich auch folgende Warnung:
An attacker using this vulnerability can request and download files within an ASP.NET Application like the web.config file (which often contains sensitive data).
At attacker exploiting this vulnerability can also decrypt data sent to the client in an encrypted state (like ViewState data within a page).
Ich fragte mich dann, wie man denn bitte auf die .config Files zugreifen könnte. Immerhin sollte dies über den IIS geblockt werden. Aber, es gibt ein kleines Feature namens WebResource.axd (Webresources).
Scripts, CSS oder andere Sachen können über bestimmte URLs eingebunden werden:
<script src="/WebResource.axd?d=8KdqlbnKlEkJNojRMjxtSxbXkp67u-rzhy_VoqsYA901&t=634200755509128189" type="text/javascript"></script>
Dabei steht der "d”-Parameter für einen verschlüsselten Pfad, den ASP.NET entsprechend (durch das entschlüsseln mit dem Machine Key) ausliesst und zurückliefert. D.h. wenn man den Key knackt, könnte man sich z.B. die web.config oder irgendwelche anderen Daten rein über eine HTTP Verbindung zurückgeben lassen.
Schon heftig, oder?
Damit man nicht auf Heise.de landet...
... sollte man bei jeglichen ASP.NET Anwendungen den Workaround anwenden. Sharepoint oder ASP.NET MVC Apps sind wahrscheinlich genauso betroffen. Bis auf die Entdecker der Lücke (und wahrscheinlich ein paar Profihacker ausserhalb und innerhalb von Microsoft) hat wahrscheinlich noch keiner ein simples "Script-Kiddy” Tool hergestellt. Das Python Script im dem YouTube Video wäre wahrscheinlich verherrender als die Java Version - mit der Javaversion hab ich es jedenfalls nicht geschafft ;)
Also: Wenn selbst die Micosoftis diese Lücke ernst nehmen - agieren, statt reagieren! In ScottGus Posts gibt es das .vbs Script. Einfach mal prüfen :)
Aufruf über
cscript <path>/<file>.vbs
Quellen
Ich kann folgenden Blogposts nur empfehlen:
