AWS - Lambda Privesc
lambda
Weitere Informationen zu lambda in:
AWS - Lambda Enumiam:PassRole
, lambda:CreateFunction
, (lambda:InvokeFunction
| lambda:InvokeFunctionUrl
)
iam:PassRole
, lambda:CreateFunction
, (lambda:InvokeFunction
| lambda:InvokeFunctionUrl
)Benutzer mit den Berechtigungen iam:PassRole
, lambda:CreateFunction
und lambda:InvokeFunction
können ihre Berechtigungen eskalieren.
Sie können eine neue Lambda-Funktion erstellen und ihr eine vorhandene IAM-Rolle zuweisen, wodurch der Funktion die Berechtigungen zugewiesen werden, die mit dieser Rolle verbunden sind. Der Benutzer kann dann Code in diese Lambda-Funktion schreiben und hochladen (zum Beispiel mit einer rev shell).
Sobald die Funktion eingerichtet ist, kann der Benutzer ihre Ausführung auslösen und die beabsichtigten Aktionen, indem er die Lambda-Funktion über die AWS-API aufruft. Dieser Ansatz ermöglicht es dem Benutzer effektiv, Aufgaben indirekt über die Lambda-Funktion auszuführen, wobei er mit dem Zugriffslevel arbeitet, das der zugehörigen IAM-Rolle zugewiesen ist.\
Ein Angreifer könnte dies ausnutzen, um eine rev shell zu erhalten und das Token zu stehlen:
Du könntest auch die Berechtigungen der Lambda-Rolle von der Lambda-Funktion selbst ausnutzen. Wenn die Lambda-Rolle genügend Berechtigungen hatte, könntest du sie verwenden, um dir Administratorrechte zu gewähren:
Es ist auch möglich, die Anmeldeinformationen der Lambda-Rolle zu leaken, ohne eine externe Verbindung zu benötigen. Dies wäre nützlich für Netzwerk-isolierte Lambdas, die für interne Aufgaben verwendet werden. Wenn unbekannte Sicherheitsgruppen Ihre Reverse-Shells filtern, ermöglicht Ihnen dieses Stück Code, die Anmeldeinformationen direkt als Ausgabe der Lambda zu leaken.
Potenzielle Auswirkungen: Direkter Privesc auf die beliebige Lambda-Dienstrolle, die angegeben ist.
Beachten Sie, dass selbst wenn es interessant aussieht, lambda:InvokeAsync
nicht allein erlaubt, aws lambda invoke-async
auszuführen, Sie benötigen auch lambda:InvokeFunction
.
iam:PassRole
, lambda:CreateFunction
, lambda:AddPermission
iam:PassRole
, lambda:CreateFunction
, lambda:AddPermission
Wie im vorherigen Szenario können Sie sich die Berechtigung lambda:InvokeFunction
gewähren, wenn Sie die Berechtigung lambda:AddPermission
haben.
Potenzielle Auswirkungen: Direkte Privilegieneskalation auf die beliebige Lambda-Dienstrolle, die angegeben ist.
iam:PassRole
, lambda:CreateFunction
, lambda:CreateEventSourceMapping
iam:PassRole
, lambda:CreateFunction
, lambda:CreateEventSourceMapping
Benutzer mit iam:PassRole
, lambda:CreateFunction
und lambda:CreateEventSourceMapping
Berechtigungen (und möglicherweise dynamodb:PutItem
und dynamodb:CreateTable
) können indirekt Privilegien eskalieren, selbst ohne lambda:InvokeFunction
.
Sie können eine Lambda-Funktion mit bösartigem Code erstellen und ihr eine vorhandene IAM-Rolle zuweisen.
Anstatt die Lambda direkt aufzurufen, richtet der Benutzer eine vorhandene DynamoDB-Tabelle ein oder nutzt sie, indem er sie über eine Ereignisquellenzuordnung mit der Lambda verknüpft. Diese Einrichtung stellt sicher, dass die Lambda-Funktion automatisch ausgelöst wird, wenn ein neuer Eintrag in die Tabelle erfolgt, entweder durch die Aktion des Benutzers oder einen anderen Prozess, wodurch die Lambda-Funktion indirekt aufgerufen und der Code mit den Berechtigungen der übergebenen IAM-Rolle ausgeführt wird.
Wenn DynamoDB bereits in der AWS-Umgebung aktiv ist, muss der Benutzer nur die Ereignisquellenzuordnung für die Lambda-Funktion festlegen. Wenn DynamoDB jedoch nicht verwendet wird, muss der Benutzer eine neue Tabelle mit aktivierten Streaming erstellen:
Jetzt ist es möglich, die Lambda-Funktion mit der DynamoDB-Tabelle zu verbinden, indem eine Ereignisquellenzuordnung erstellt wird:
Mit der mit dem DynamoDB-Stream verknüpften Lambda-Funktion kann der Angreifer indirekt die Lambda auslösen, indem er den DynamoDB-Stream aktiviert. Dies kann erreicht werden, indem ein Element in die DynamoDB-Tabelle eingefügt wird:
Potenzielle Auswirkungen: Direkte Privilegieneskalation auf die angegebene Lambda-Dienstrolle.
lambda:AddPermission
lambda:AddPermission
Ein Angreifer mit dieser Berechtigung kann sich selbst (oder anderen) beliebige Berechtigungen gewähren (dies erzeugt ressourcenbasierte Richtlinien, um den Zugriff auf die Ressource zu gewähren):
Potenzielle Auswirkungen: Direkte Privilegieneskalation zum Lambda-Dienstrolle durch Gewährung der Berechtigung zur Modifikation des Codes und dessen Ausführung.
lambda:AddLayerVersionPermission
lambda:AddLayerVersionPermission
Ein Angreifer mit dieser Berechtigung kann sich selbst (oder anderen) die Berechtigung lambda:GetLayerVersion
gewähren. Er könnte auf die Schicht zugreifen und nach Schwachstellen oder sensiblen Informationen suchen.
Potenzielle Auswirkungen: Potenzieller Zugriff auf sensible Informationen.
lambda:UpdateFunctionCode
lambda:UpdateFunctionCode
Benutzer, die die Berechtigung lambda:UpdateFunctionCode
besitzen, haben die Möglichkeit, den Code einer bestehenden Lambda-Funktion, die mit einer IAM-Rolle verknüpft ist, zu ändern.
Der Angreifer kann den Code der Lambda-Funktion ändern, um die IAM-Anmeldeinformationen zu exfiltrieren.
Obwohl der Angreifer möglicherweise nicht die direkte Fähigkeit hat, die Funktion auszulösen, ist es wahrscheinlich, dass die Lambda-Funktion, wenn sie bereits vorhanden und betriebsbereit ist, durch bestehende Workflows oder Ereignisse ausgelöst wird, wodurch die Ausführung des modifizierten Codes indirekt erleichtert wird.
Potenzielle Auswirkungen: Direkte Privilegieneskalation auf die verwendete Lambda-Dienstrolle.
lambda:UpdateFunctionConfiguration
lambda:UpdateFunctionConfiguration
RCE über Umgebungsvariablen
Mit diesen Berechtigungen ist es möglich, Umgebungsvariablen hinzuzufügen, die dazu führen, dass die Lambda willkürlichen Code ausführt. Zum Beispiel ist es in Python möglich, die Umgebungsvariablen PYTHONWARNING
und BROWSER
auszunutzen, um einen Python-Prozess willkürliche Befehle ausführen zu lassen:
Für andere Skriptsprachen gibt es andere Umgebungsvariablen, die Sie verwenden können. Für weitere Informationen überprüfen Sie die Unterabschnitte der Skriptsprachen in:
RCE über Lambda Layers
Lambda Layers ermöglicht es, Code in Ihrer Lambda-Funktion einzuschließen, aber separat zu speichern, sodass der Funktionscode klein bleiben kann und mehrere Funktionen Code teilen können.
Innerhalb von Lambda können Sie die Pfade überprüfen, von denen Python-Code geladen wird, mit einer Funktion wie der folgenden:
Diese sind die Orte:
/var/task
/opt/python/lib/python3.7/site-packages
/opt/python
/var/runtime
/var/lang/lib/python37.zip
/var/lang/lib/python3.7
/var/lang/lib/python3.7/lib-dynload
/var/lang/lib/python3.7/site-packages
/opt/python/lib/python3.7/site-packages
/opt/python
Zum Beispiel wird die Bibliothek boto3 von /var/runtime/boto3
geladen (4. Position).
Ausnutzung
Es ist möglich, die Berechtigung lambda:UpdateFunctionConfiguration
zu missbrauchen, um eine neue Schicht zu einer Lambda-Funktion hinzuzufügen. Um beliebigen Code auszuführen, muss diese Schicht eine Bibliothek enthalten, die die Lambda importieren wird. Wenn Sie den Code der Lambda lesen können, könnten Sie dies leicht finden, beachten Sie auch, dass es möglich sein könnte, dass die Lambda bereits eine Schicht verwendet und Sie die Schicht herunterladen und Ihren Code dort hinzufügen könnten.
Zum Beispiel, nehmen wir an, dass die Lambda die Bibliothek boto3 verwendet, dies wird eine lokale Schicht mit der letzten Version der Bibliothek erstellen:
Sie können ./lambda_layer/boto3/__init__.py
öffnen und die Hintertür im globalen Code hinzufügen (eine Funktion zum Exfiltrieren von Anmeldeinformationen oder um beispielsweise eine Reverse-Shell zu erhalten).
Dann zippen Sie das ./lambda_layer
-Verzeichnis und laden die neue Lambda-Schicht in Ihr eigenes Konto hoch (oder in das des Opfers, aber möglicherweise haben Sie dafür keine Berechtigungen).
Beachten Sie, dass Sie einen Python-Ordner erstellen und die Bibliotheken dort ablegen müssen, um /opt/python/boto3 zu überschreiben. Außerdem muss die Schicht mit der verwendeten Python-Version der Lambda kompatibel sein, und wenn Sie sie in Ihr Konto hochladen, muss sie in der gleichen Region sein:
Jetzt machen Sie die hochgeladene Lambda-Schicht für jedes Konto zugänglich:
Und füge die Lambda-Schicht zur Opfer-Lambda-Funktion hinzu:
Der nächste Schritt wäre, entweder die Funktion selbst aufzurufen, wenn wir können, oder zu warten, bis sie auf normale Weise aufgerufen wird – was die sicherere Methode ist.
Eine diskretere Möglichkeit, diese Schwachstelle auszunutzen, findet sich in:
AWS - Lambda Layers PersistencePotenzielle Auswirkungen: Direkte Privilegieneskalation zur Lambda-Dienstrolle, die verwendet wird.
iam:PassRole
, lambda:CreateFunction
, lambda:CreateFunctionUrlConfig
, lambda:InvokeFunctionUrl
iam:PassRole
, lambda:CreateFunction
, lambda:CreateFunctionUrlConfig
, lambda:InvokeFunctionUrl
Vielleicht sind Sie mit diesen Berechtigungen in der Lage, eine Funktion zu erstellen und sie über die URL auszuführen... aber ich konnte keinen Weg finden, dies zu testen, also lassen Sie es mich wissen, wenn Sie es tun!
Lambda MitM
Einige Lambdas werden sensible Informationen von den Benutzern in Parametern empfangen. Wenn Sie RCE in einem von ihnen erhalten, können Sie die Informationen, die andere Benutzer an sie senden, exfiltrieren, überprüfen Sie es in:
AWS - Steal Lambda RequestsReferenzen
Last updated