it-swarm.com.de

Was ist der Zweck der Ablaufzeit in signierten S3-URLs?

Mit S3 können Sie Medienanforderungen über eine signierte URL authentifizieren. Diese URL kann eine Ablaufzeit enthalten, nach der die URL nicht mehr gültig ist ( http://docs.aws.Amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#RESTAuthenticationQueryStringAuth ). Was ist der Punkt des Ablaufs, da die URL-Signatur von HMAC-SHA1 generiert wird (was meiner Meinung nach für Brute Force nicht durchführbar ist?)? Soll Brute Forcing verhindert werden (d. H. Die Sicherheit der Medien-URLs erhöht werden)? Oder ist die URL unabhängig von der Ablaufzeit sicher und die Ablaufzeit wird bereitgestellt, um einen domänenspezifischen Ablauf bereitzustellen (dh einem Kontoauszug kann eine Ablaufzeit von einer Stunde zugewiesen werden, damit ein böswilliger Benutzer mit Zugriff auf die Netzwerkanforderungen eines Computers dies nicht kann nicht später abrufen).

Zusammenfassend: Ist die Signatur der S3-URL unabhängig von der Ablaufzeit sicher? Oder ist eine relativ kurze Ablaufzeit erforderlich, um die Mediensicherheit zu gewährleisten?

10
John Lucas

Die Ablaufzeit dient dazu, die Lebensdauer der Berechtigung zur Ausführung der zulässigen Aktion durch Personen zu begrenzen, die im Besitz der signierten URL sind.

Die Ablaufzeit in einer URL kann natürlich nicht geändert werden, ohne die Signatur ungültig zu machen, da dies eine der Eingaben in HMAC ist, aber die Ablaufzeit selbst trägt nichts zur tatsächlichen Sicherheit des Signaturalgorithmus selbst bei weil:

  • obwohl der gehashten Nachricht Informationen hinzugefügt werden, werden keine geheimen Informationen hinzugefügt

  • die Tatsache, dass eine URL "abgelaufen" ist, hindert einen böswilligen Akteur nicht daran, sie brutal zu erzwingen, wenn wir davon ausgehen, dass Brute-Forcing rechnerisch machbar ist ... weil Sie S3 nicht benötigen, um zu bestätigen, dass Sie mein Signaturgeheimnis brutal erzwungen haben . Wenn Ihr Signaturalgorithmus dieselbe Ausgabe erzeugt, die ich basierend auf derselben Eingabe gemacht habe, gewinnen Sie. Sicher, diese spezifische URL, die Sie hatten, ist jetzt abgelaufen, aber jetzt haben Sie mein Signaturgeheimnis und können jede beliebige URL mit beliebiger Ablaufzeit signieren .

Bitte beachten Sie, dass nichts, was ich hier sage, bedeuten soll, dass ich glaube, dass die Sicherheit des Signaturalgorithmus fehlerhaft ist. Mein einziger Punkt ist, dass die Ablaufzeit keinen Einfluss auf die Sicherheitsstufe hat, die der Algorithmus bei Ablauf der Ablaufzeit bieten würde waren keine Komponente.

Aus Gründen der Klarheit ist die Ablaufzeit per Definition manipulationssicher, da die Ablaufzeit Teil der signierten Nachricht ist. Eine gültige URL von mir, die gestern abgelaufen ist, kann nicht auf "morgen ablaufen" geändert werden und ihre Signatur ist noch gültig.

Der von Ihnen erwähnte Signature Version 2-Algorithmus ist sehr einfach. Konzeptionell kanonisieren Sie die Anforderung, die Sie stellen möchten, und führen sie dann über HMAC aus. Nichts an der Anfrage ist geheim, außer für den geheimen Schlüssel. Die Anforderung selbst (die Eingabenachricht an die HMAC-Funktion), einschließlich der Ablaufzeit, enthält keine versteckten Komponenten. Dies war nicht möglich, da S3 dann nicht in der Lage wäre, dieselbe Signatur zu generieren, da ich keine geheime Mitteilung über die bevorstehende Anfrage - so funktioniert der Signaturalgorithmus - für eine bestimmte Anfrage (HTTP-Verb, Inhalt) erhalten hätte -MD5-Header-Wert, wenn er gesendet wird, Content-Type-Header-Wert, wenn er gesendet wird, Ablaufzeit, kanonisierte X-Amz - Header, wenn sie gesendet werden, und schließlich /${bucket}/${key}{$canonical_query_string}, Alle diese Elemente zusammen mit \n dazwischen verkettet.

S3 kennt mein Geheimnis (wie anscheinend alle AWS-Services, damit sie meine Anforderungen validieren können) und versucht, dieselbe Signatur wie ich zu generieren. Wenn dies erfolgreich ist, ist die Anforderung zulässig, wenn der Benutzer, dessen Anmeldeinformationen die Anforderung signiert haben, die Anforderung tatsächlich stellen darf.

Wenn Sie im Besitz einer signierten URL sind, die ich generiert habe, können Sie dies brutal tun, indem Sie die Nachricht reproduzieren, die ich signiert hätte (Sie wissen bereits alles, was Sie benötigen, von der URL, um dies zu tun) und zu dem Zeitpunkt, zu dem Sie berechnen das gleiche Signature Ich habe Sie in meiner signierten URL angegeben, Sie haben meinen geheimen Schlüssel geknackt. Für eine bestimmte Anfrage und Ablaufzeit kann es nur genau eine korrekte Signatur geben.

Viel Glück bei diesem Cracking-Projekt natürlich, denn ich habe meinen Schlüssel (und das dazugehörige Geheimnis) aus dem aktiven Status gedreht und ihn nach einigen Wochen oder Monaten deaktiviert, lange bevor Sie eine sinnvolle Chance haben, ihn zu knacken.

Aber der Punkt ist, dass Sie, genau wie bei jeder anderen Komponente, die in die Nachricht eingeht, die ich HMAC-ing bin, &Expires= In der URL sehen und wissen, welcher Wert dorthin geht, um die ursprüngliche Nachricht zu reproduzieren Ich habe unterschrieben. Das Ablaufen erschwert Ihre Aufgabe nicht.

Nein, der Ablauf dient ausschließlich der Kontrolle der gültigen Lebensdauer einer signierten URL, die ich verteile. Dabei wird davon ausgegangen, dass der unbefugte Zugriff auf diese URL einige Zeit in Anspruch nimmt. Je vertraulicher die Informationen im Allgemeinen sind, desto kürzer sollten Sie die Ablaufzeit der Anforderung festlegen.


Randnotizen: Durch die Einbeziehung der Ablaufzeit erhalten die Back-End-Server auch eine geringfügige Optimierung, die Sie selbst nachweisen können. Die Ablaufzeit wird zuerst überprüft . , bevor die Gültigkeit der Signatur überprüft wird. Es macht schließlich keinen Sinn, CPU-Zyklen damit zu verbringen, eine Signatur zu überprüfen, die von einer Ablaufzeit begleitet wird, die eindeutig anzeigt, dass sie abgelaufen ist. S3 scheint diese unnötige Arbeit kurzzuschließen, indem derselbe Fehler "Anforderung ist abgelaufen" zurückgegeben wird, wenn die Ablaufzeit abgelaufen ist, unabhängig davon, ob die Signatur gültig ist oder nicht. Sie können dies bestätigen, indem Sie die Ablaufzeit einer gültigen Anforderung manuell ändern. Wenn Sie es auf die Vergangenheit setzen, wird die Signatur ungültig, aber der Fehler lautet "Anforderung ist abgelaufen". Wenn Sie es auf die Zukunft setzen, macht dies auch die Signatur ungültig, aber der Fehler, den Sie erhalten, zeigt an, dass die Signatur ungültig ist.


Außerdem: Signature Version 4 ist ein viel komplexerer - und noch sicherer - Algorithmus als V2, der 5 verschachtelte Iterationen von HMAC-SHA256 verwendet ... und es gibt keine 5 Iterationen, weil die falsche Vorstellung besteht, dass "mehr besser ist" . "

In Wahrheit hat es eine Weile gedauert, bis die Implikationen des Entwurfs dieses Algorithmus bei mir angekommen sind, und es scheint ziemlich brillant zu sein.

Wenn Sie die Ebenen zurückziehen, wird deutlich, dass AWS diesen Algorithmus so konzipiert hat, dass das Vertrauen intern (dh innerhalb von AWS) nach dem Prinzip der geringsten Berechtigungen delegiert wird.

Die innerste HMAC-Iteration ist eine Nachricht, die aus dem heutigen Datum besteht und mit einem Geheimnis signiert ist, das aus der Zeichenfolge "AWS4" + my secret besteht. Das ist der DateKey. Es ist nur für 7 Tage gut. Das zentrale Sicherheits-Repository von IAM ist die einzige Entität, die mein Geheimnis und meinen DateKey kennt.

Die nächste Iteration signiert den Literalnamen der AWS-Region (z. B. us-west-2) Unter Verwendung der Ausgabe des DateKey, um den DateRegionKey abzuleiten. IAM kann diesen Wert dann an seine Subsysteme in jeder Region liefern, sodass sie alles wissen, was sie wissen müssen, um meine Signaturen für ihre Region zu validieren, jedoch nicht global.

Als nächstes wird der AWS-Dienstname (z. B. s3) Mit dem DateRegionKey signiert, um den DateRegionServiceKey zu generieren. Mit jeder Region können die IAM-Subsysteme dieses Geheimnis für jeden Dienst generieren und jedem Dienst alles liefern, was der Dienst wissen muss, um meine Signaturen für ihren Dienst innerhalb dieser einen Region zu authentifizieren - und (wieder) nichts weiter.

Dann wird die Zeichenfolge "aws4_request" mit dem DateRegionServiceKey signiert, um meinen täglichen Signaturschlüssel zu bilden. Da "aws4_request" im Wesentlichen nur eine Zeichenfolge ist, kann jeder Dienst den Signaturschlüssel ableiten (anstatt ihn zu speichern), den ich heute zum Signieren von Anforderungen verwenden werde, und verfügt somit nur über die benötigten Informationen und nicht mehr.

Schließlich wird mein täglicher Signaturschlüssel verwendet, um jede kanonisierte Anfrage zu signieren.

Sehen Sie, was sie dort getan haben?

Kein System außer dem IAM-Kernsystem muss mein eigentliches Geheimnis kennen. Wenn beispielsweise die Infrastruktur einer S3-Region intern verletzt würde (wie unwahrscheinlich dies auch sein mag), würden die Informationen, die ein Angreifer erhalten könnte, ihnen mein tatsächliches Geheimnis nicht verraten - nur das Geheimnis, das S3 in dieser Region bekannt war. Wenn die regionale Infrastruktur verletzt würde, wären die erhaltenen Anmeldeinformationen in anderen Regionen usw. entlang der Kette bis zur Wurzel nutzlos.

Der V4-Algorithmus ist das Kernstück eines scheinbar sicheren, global verteilten, geheimen Signaturschlüssel-Delegierungssystems, bei dem intern alles auf einer Wissensbasis ist. Wie ich schon sagte ... es scheint ziemlich brillant.

7

Dies ist im folgenden Szenario hilfreich:

Sie möchten beispielsweise Videodateien bereitstellen, jedoch nur für bestimmte Benutzer. Sie möchten es ihnen erschweren, URLs gemeinsam zu nutzen.

Bob meldet sich bei Ihrer Site an und wählt ein Video aus. Sie generieren und HMAC die URL mit der Ablaufzeit, die auf 5 Sekunden festgelegt ist. Die Seite wird in 1 Sekunde geladen und der eingebettete Videoplayer sendet die Anfrage an AWS. Die URL ist noch gültig.

Bob sieht sich die HTML-Quelle an, findet die Video-URL, kopiert sie und sendet sie an seinen Freund. Der Freund öffnet die URL, sie ist jedoch abgelaufen.

9
Neil McGuigan

Auch wenn SHA1 nicht sicher sein soll, ist HMAC-SHA1 wahrscheinlich nicht betroffen. AFAIK, auch HMAC-MD5 ist noch sicher. Alle möglichen bekannten Angriffe zielen darauf ab, sich direkt nicht an HMAC zu hacken. Auch eine einzige Kollision von SHA1 ist noch nicht bekannt und es wäre immer noch sehr teuer und zeitaufwändig, sie zu finden.

In Bezug auf die S3 URL exp. Zeit, denke ich, wurde nicht erwähnt, um irgendwie SHA1-HMAC-Sicherheit zu liefern.

Überprüfen Sie einfach den Link: Wird HMAC-MD5 als sicher für die Authentifizierung verschlüsselter Daten angesehen?

1
smrt28