Einer neuen Studie zufolge könnte eine Schwachstelle im Traffic-Routing-Dienst von Amazon Web Service namens Application Load Balancer von einem Angreifer ausgenutzt worden sein, um Zugriffskontrollen zu umgehen und Webanwendungen zu gefährden. Der Fehler ist auf ein Client-Implementierungsproblem zurückzuführen, was bedeutet, dass er nicht durch einen Softwarefehler verursacht wird. Stattdessen wurde die Gefährdung dadurch verursacht, wie AWS-Benutzer die Authentifizierung mit Application Load Balancer konfigurierten.
Implementierungsprobleme sind ein entscheidender Teil der Cloud-Sicherheit, ebenso wie der Inhalt eines geschützten Tresors nicht geschützt ist, wenn die Tür offen gelassen wird. Forscher des Sicherheitsunternehmens Miggo haben herausgefunden, dass ein Angreifer je nach Konfiguration der Application Load Balancer-Authentifizierung möglicherweise die Weiterleitung an einen Unternehmensauthentifizierungsdienst eines Drittanbieters manipulieren kann, um Zugriff auf die anvisierte Webanwendung zu erhalten und Daten anzuzeigen oder herauszufiltern.
Forscher sagen, dass sie bei der Untersuchung öffentlich verfügbarer Webanwendungen mehr als 15.000 davon identifiziert haben, die offenbar anfällige Konfigurationen aufweisen. AWS bestreitet diese Schätzung jedoch und sagt, dass „ein kleiner Bruchteil von einem Prozent der AWS-Kunden Anwendungen haben, die möglicherweise auf diese Weise falsch konfiguriert sind, was deutlich weniger ist als die Schätzung der Forscher.“ Das Unternehmen gibt außerdem an, jeden Kunden auf seiner engeren Auswahl kontaktiert zu haben, um eine sicherere Implementierung zu empfehlen. AWS hat jedoch keinen Zugriff auf oder Einblick in die Cloud-Umgebungen seiner Kunden, sodass genaue Zahlen nur Schätzungen sind.
Miggo-Forscher sagen, sie hätten dieses Problem bei der Arbeit mit einem Kunden entdeckt. „Dieses Problem wurde in realen Produktionsumgebungen entdeckt“, sagt Daniel Shechter, CEO von Miggo. „Wir haben im System eines Kunden ein seltsames Verhalten beobachtet: Der Validierungsprozess schien nur teilweise abgeschlossen zu sein, als würde etwas fehlen. Dies zeigt deutlich, wie tief die gegenseitigen Abhängigkeiten zwischen Kunde und Lieferant sind. »
Um das Implementierungsproblem auszunutzen, könnte ein Angreifer ein AWS-Konto und einen Application Load Balancer konfigurieren und dann wie gewohnt sein eigenes Authentifizierungstoken signieren. Dann würde der Angreifer Konfigurationsänderungen vornehmen, um den Anschein zu erwecken, dass der Authentifizierungsdienst seines Ziels das Token ausgestellt hat. Der Angreifer würde dann AWS auffordern, das Token zu signieren, als käme es rechtmäßig vom System des Ziels, und es für den Zugriff auf die Zielanwendung zu verwenden. Der Angriff muss gezielt auf eine falsch konfigurierte Anwendung abzielen, die öffentlich zugänglich ist oder auf die der Angreifer bereits Zugriff hat, die es ihm aber ermöglichen würde, seine Berechtigungen im System zu erhöhen.
Laut Amazon Web Services betrachtet das Unternehmen Token-Fälschung nicht als Schwachstelle im Application Load Balancer, da dies im Wesentlichen ein erwartetes Ergebnis einer bestimmten Konfiguration der Authentifizierung ist. Doch nachdem Miggo-Forscher ihre Ergebnisse Anfang April AWS mitgeteilt hatten, nahm das Unternehmen zwei Änderungen in der Dokumentation vor, um seine Implementierungsempfehlungen für die Application Load Balancer-Authentifizierung zu aktualisieren. Eine davon enthielt ab dem 1. Mai eine Anleitung zum Hinzufügen einer Validierung, bevor Application Load Balancer Token signiert. Und am 19. Juli fügte das Unternehmen außerdem eine ausdrückliche Empfehlung hinzu, dass Benutzer ihre Systeme mithilfe einer Funktion namens „Sicherheitsgruppen“ so konfigurieren sollten, dass sie Datenverkehr nur von ihrem eigenen Application Load Balancer empfangen.