 Wir sind froh um Feedback auf Twitter mit dem Hashtag C3T. Hallo zusammen. Danke, dass ihr alle da seid. Ich heiße Rich Jones, ich bin der Sonder von gun.io. Wir machen Freelance Jobs für Hacker. Ich habe auch ZEPA erschellt, das ein Framework ist. Es kann jede wirkliche Python-Webapplikation auf AWS Lambda laufen lassen. Man kann Anwendung dort bauen. Man kann 500.000 Operationen gleichzeitig globale abarbeiten. Ich habe es zuerst 6 Monate vor 6 Monaten bei einem Event bei der Seabase vorgestellt. Es wird tatsächlich auch von einigen großen Firmen benutzt, die Leute das ausprobieren. Herzlich willkommen zu meinem Talk. Der Titel heißt Gammon Six Milliseconds. Fans der Titel bekommen eine Zulassung bei Konferenzen. Eine kurze Umfrage. Wer von den hier Anwesenden ist vertraut mit AWS Lambda? Eine deutliche Mehrheit. Wie war das alles früher? Früher würde der Web-Server sich zum Datemann-Server verbinden. Und das wäre mehr oder weniger die ganze Anwendung. Eine einzelne Anwendung. Man würde dann auch viele Anwendungen von diesem einen Server laufen lassen. Man könnte dann eine Shell auf dem Server bekommen usw. Und alle waren glücklich damit. Mit der serverlosen Architektur haben wir keinen permanenten Web-Server mehr, sondern wir nutzen den Web-Service AWS Lambda, das keine permanente Infrastruktur bereitstellt, sondern die Anwendung bleibt im Cash bei Amazon AWS und pro Request wird eine Instanz dort gestartet, um den Request zu behandeln. Das heißt, pro Request wird ein Container gestartet, der Code wird behandelt und immer wieder gestoppt. Der Code läuft basierend auf Events oder wird durch Events gestartet und das macht das alles sehr skalierbar. Dadurch, dass wir einfach proportional zur Anzahl von Request-Servers bauen können, verteilt über die Amazon Infrastruktur. Es ist deutlich günstiger, weil man pro Millisekunde abgerechnet wird. Das heißt, wir landen bei 0,992 Euro pro Millisekunde. Man muss sich z.B. um Sicherheitsupdates von den Betriebsstämmen kümmern, da man ja eben nur seinen eigenen Code laufen lässt und der Amazon sich um das Betriebsstämme darunter kümmert. Das heißt, in der Summe, wir brauchen keine Ops-Leute mehr und wir können uns auf den Code konzentrieren. Einige typische Anwendungsfälle in diesen Produktionen gibt. Für Webserver, wenn man z.B. Zappa benutzt, um Django-Anwendungen laufen zu lassen, da könnte man das API-Gateway nutzen. Anderer Nutzungsfall ist Asynchrone-Datenverarbeitung. Das heißt, wenn man z.B. eine Daten-Upload an Amazon S3 hat, dann würde das über Lambda in einem Dynamo-DBS-Sor gespeichert werden und dann könnte die Lambda-Funktion auf dem Bucket arbeiten und dann einen neuen Bucket erstellen mit den modifizierten Daten. Chatbots ist ein anderer oft genutzer Anwendungsfall, wenn man z.B. einen SMS oder SCS hat, könnte man die in einer Lambda-Funktion bearbeiten und dann z.B. wieder eine SCS oder einen SMS erzeugen. Andere großen Themen sind finanzielle oder medizinische oder wissenschaftliche Anwendungen, wo dann auch wieder Zustand in S3 gespeichert würde und dann durch Lambda-Funktionen verarbeitet wird und wieder in S3 gespeichert wird. Das heißt, wir sehen, dass die Lambda-Funktion quasi die Q von Daten, also die Liste an Daten verarbeitet. Es gibt noch zahlreiche weitere Beispiele dafür, aber das waren so die allgemeinsten. So, wenn man jetzt solche Anwendungen angreifen wollen würde, könnte man das vielleicht machen, aber es wäre von nicht besonders langen Dauer, weil der Container sofort wieder gelöscht wird, sobald die Funktion abgearbeitet ist. Was heißt das für uns als Hacker? Es ist schwerer anzugreifen, es ist schwerer, da persistente Angriffe zu installieren, weil eben der Service direkt wieder verschwindet oder der Container direkt wieder verschwindet. Es gibt auch keine Sysadmins oder Ähnliches, die irgendwelche Fehler machen könnten, die dann zu Privilegiascalation oder Änchen Dinge führen und außerdem ist das ganze Dateisystem schreibgeschützt, das heißt nur lesbar, und das macht es besonders schwer, eine permanente Attacke zu installieren im Container. Außer haben wir keinen Innitsystem im Container, das heißt, wir können dort auch keine Angriffe verstecken. Es ist auch schwieriger, Daten daraus zu extrahieren, zum Beispiel das Virtual Private Cloud Feature von Amazon, das verhindert das. Da ist kein Netzwerk-Zugriff, einfach trauriges Face. Wenn Bezos die Türcloth öffnet, ein Fenster. Wir lernen ein bisschen Erkennung, Infiltration und wie man rausbekommt und ein bisschen Aufräumen. Das erste, auf Klärung. Wiederum wir wissen, was wir alles angreifen. Da sind zwei Attack-Angriffoberflächen. Die äußere Attack-Angriffoberfläche, das API-E-Gate, serviert dynamischen Content aus der Cloud Front. Der Teilhochladung ist ziemlich einfach. Wenn ihr auf den Header guckt, es ist S3, wenn ihr auf den E-Mail-Header guckt, dann seht ihr Amazon NCS. So ist auch der innere Angriffoberfläche. Das können wir nicht direkt angreifen. Aber wir können Qs, das bedeutet eine ganz lange Sache, Qs rein, langlaufende Angriffe. Das heißt auch Datenbank-Irreignisse und Benutzer-Events. Das kann auch noch eine... Und das Log-System kann auch eine Quelle sein. Wie benutzen wir das Ganze zum Angreifen? Lambda Funktion ist einfach, was die Applikation ist. Das ist eine Rub-Goldberg-Maschine. Ich habe es von den Übersetzern gelernt, dass ihr das Nonsense-Maschinen nennt. Um herauszufinden, was funktioniert, benutzt wir ein Prozess, der heißt Destruktive Mechanik. Und das bedeutet, den Blitz in den Motor zu spritzen und zu gucken, was passiert. Wir greifen die Eventquellen selbst an. Das heißt, wir triggern quasi jede Quelle, die es so gibt, und gucken dann mal, was dabei rauskommt. Was wird zum Beispiel möglich? Desigualisierungsfehler, serviceitige Einfügung in der Datenquelle. Und so wird zum Beispiel ein einfaches Beispiel dazu. Wir hätten verbundenen Code. Hier ist ein Listing davon. Es verbindet sich zu einem S3-Bockel. Und ruft irgendein Prozess auf dem Schlüssel in den Bucket auf. Was passiert jetzt aber, wenn wir ein Objekt erstellen mit dem gezeigten Call Kommando, dass dann den Keyname zeigt? Wie könnte man das dann ausbeuten oder nutzen? Das heißt, was ist eigentlich ein Lambda? Das heißt, was ist eigentlich Wert da zu extrahieren? Das heißt, wenn wir da schauen, was wir dort ausführen können, wenn wir da schauen, der Lambda-Händler selber braucht immer einen bestimmten Event-Kontext. Wenn wir uns da so umschauen, sieht das alles etwas aus wie eine Retail-6-Installation. Interessanterweise als Rullpifons 2, 7 und 3, 4, Node.js, Perl, Budo 3, GTC und Perl, also alles, was wir gerne mögen. Wenn wir uns ein bisschen umschauen, sehen wir, dass ein Betriebssystem namens Amazon Linux laufen lässt, das ist das Standardbetriebssystem für EC2 ist. Und jetzt stellt sich die Frage, wenn es ein EC2-Server ist, können wir dann den Meta-Info-Server zugreifen für diejenigen, die das nicht kennen, aus dem Docs von Amazon steht. Instanz-Meterdaten sind Meta-Daten, die laufenden Instanzen betreffen, das heißt, jeder, der diese Instanz-Meterdaten zugreifen kann, kann Informationen wie zum Beispiel Nutzerschlüsse und so weiter extrahieren über den laufenden Container. Was passiert, wenn man auf den Server zugreift? Das funktioniert nicht, aber das ist sowieso gut zu merken, wenn man EC2 angreift. So, schauen wir uns mal die Environment-Variablen an. Was sehen wir da so alles drin? Wir sehen zum Beispiel AWS-Session-Tokens und Security-Tokens drin. Das sieht schon mal ganz interessant aus, alles. Wenn wir uns dann noch anschauen, was das Identity- und Access-Management-System von Amazon AWS anschauen, dann sehen wir, das System gibt Pro-Resource und Pro-Operationen eine Autosierungsmechanismus. Und das macht unseren, ja, unsere Mission hier etwas schwerer. Aber es hat auch einige Probleme. Und wenn man sich die Doku durchliest und Amazon die ziemlich alt ist und sowieso etwas schlimm zu lesen ist, dann finden wir da nicht besonders viel. Wichtig ist hierbei, alles, was wir so Interessantes machen, hängt davon ab, dass unser Opfer ein schlecht konfiguriertes Amazon-IAM-System hat, also das Auto-Invisionssystem. Und ansonsten ist das alles relativ sicher. Aber wir gehen jetzt halt davon aus, dass es schlecht konfiguriert ist. Das heißt, wir schauen uns jetzt eine Security-Policy an, wie das AM Passroll benutzt, die einen temporären Nutzer anlegt und dann die Zugangsarten dieses Nutzers in den Lambda-Funktionsumgebungen injiziert. Das heißt, das hier ist die AWS Lambda-VPC-Execution-Roll, die direkt von Amazon selbst kommt. Wir sehen hier zum Beispiel Ressourc-Sternchen, das heißt, wir haben alle Zugriff auf alles, was dieser, auf was dieser Account Zugriff hat und das werden wir später nutzen, um in das Opfer anzugreifen. Wo lebt der Code? Wenn wir die Umgebungsvariablen überprüfen, dann sehen wir, der Schlüsselwert ist für Lambda Test Group. Wir werden einfach unseren Subbac-Door-Ketten-Subbac-Door in, das funktioniert, ich weiß, nur ein Lesensystem ist. Es überlebt nicht für andere Benutzer, um die Funktionen zu aufzurufen, weil es nicht mehr Speicher ist. Das lebt nur für den HTTP-Riffgeist. Wie installiere ich diese tollen Hacking-Tools auf diesem System? Glücklicherweise ist der Temp-Platz auf der Versplatte für normale Dateien, die Lesen- und Schreibüberrichtung brauchen. Temp ist Schreib- und Lese-Bereich. Das beschreibt das als immer voll Disk-Cupacity. Für Performance-Gründe ist es cached, eine Arbeitsspeicher. Weil Temp eine Remdisk ist, ist es cached. Wenn wir unsere Tools aufbauen, können wir das nutzen. Wir müssen die Funktionen in einem Speicher behalten, den wir es häufiger aufrufen. Die Zeit ist 4 Minuten und 30 Sekunden. Was das NDA euch erzählt, fragt mich nicht. Was toll ist, das greift auch für laugenlaufende Prozesse. Es ruft den Prozess auf und benutzt dann wieder. Jetzt können wir den Linux X86-Firmware aufbauen. Das ist das NDA-Firmware. Das ist das NDA-Firmware. Das ist das NDA-Firmware. Wir können unsere tool installieren. Wir können sie auf Lambda-Funktionen tun und sie aufrufen. Sie haben einige Schlüsse und Tools. Sie wollen natürlich erst das erst tun. Wir können auch mit den 가서-Rechts mit dem CSI-Tool noch ein paar hierhin auswählen. Das heißt, wenn wir mit dem Amazon-AWS-Kommandant Amazon, AWS Kommando Zeilentruhe, diese Pemise uns anzeigen lassen können wir zum Beispiel neue Nutzer anlegen, Datenbanken löschen und so weiter, das ist quasi Game Over. So irgendwie ein kleiner Ausflug zwischendurch, wenn ihr hier irgendwie den Jackpot findet, also irgendwo die ganze Zeit Sternchen überall, seht bei allen Permissions, und meint ihr habt da was Groß gefunden, macht nichts Böses damit, sendet nicht mal die ganzen E-Mails an irgendwem. Bug Bounties sind langweilig, Spionage ist langweilig, nutzt deine Fähigkeiten, um so Sachen aufzumachen für irgendwas Cooles. Macht nichts Böses. Das ist mir wirklich wichtig. Ich glaube wir verlieren hier etwas ästhetische Qualität in unserer Kultur hier, alles zugunstenvollen, unseren Karrieren und so weiter. Ich denke, dass der ästhetische Wert tatsächlich über die Zeit deutlich höheren Wert hat als temporäre Bug Bountie Erfolge und so weiter. Also bleibt irgendwie auf dem Boden der Tatsachen, auch wenn ihr Sternchen, also etwas wahrscheinlicher als Sternchen, werdet ihr wahrscheinlich halbwegs strikte Zugangsberechtigungen sehen, z.B. eingeschränkte Berechtigungen, Dateien oder 3 Objekte oder Datenbanken zuzunehmen, aber auch das können wir für bösartige Zwecke benutzen. Z.B. wie können wir Daten da rausziehen, exfiltration. So, wenn wir also, da wir in der Laufzeitumgebung von diesen Cloud Provider arbeiten, können wir dessen ganze Dienste nutzen, um Daten da raus zu extrahenden. Selbst wenn wir keine direkte Internetverwendung haben. Wir können z.B. wenn wir in einem Kontext darauf eine E-Mail senden und so die Daten, die wir da gefunden haben, extrahieren. Wir könnten SMSen schicken über SMS-Gateways, die von den Cloud Provider angeboten werden. Etwas schwieriger wäre es dann schon, wenn man jetzt nur S3 Objekte hat, könnte man den ganzen Anwendungsquellcode in ein 7 Datei packen und auf S3 hochladen und damit hätten wir den gesamten Quellcode des Unternehmens extrahiert. Das heißt, hier seht ihr nochmal die allgemeine Architektur für eine Big Data Anwendung, die Amazon Lambda benutzt. Hier ein Zitat Amazon, VBC stellt zahlreiche Security Features bereit. Der Vorteil davon ist, es ist sehr einfach, da Fehler zu machen, weil es eben relativ komplexe Security Protests sind, die konfiguriert werden müssen. Das heißt, wir nutzen Lambda, um quasi durch die Amazon Virtual Private Cloud Umgebung durchzukommen. Also ein Loch durch die Virtual Private Cloud zu finden. Okay, das heißt, ohne das VBC-Network überhaupt anzufassen, was kann man dann machen? Wir laden die beseitige Datei hoch, die ich hier mit so einem Cybertotenkopf gezeigt habe. Erster Schritt ist dann, so Canaries zu installieren. Das heißt, wir versuchen zuerst auf irgendeine Art und Weise diese Informationen rauszugeben, eben über diese Canaries, damit wir in irgendeiner Weise bidirektionale Kommunikation haben. Bisher haben wir ja nur Daten reingeschoben über das Gateway, und jetzt müssen wir da irgendwie wieder ein Ruckweg bekommen. So, das heißt, unser Ziel in diesem Fall sind die Daten, die in der Datenmarke gespeichert sind. Also, das heißt, wir haben ja normalerweise keinen direkten Zugriff aus der Lambda-Ungerung auf die Datenbank, weil die Datenbank ja in einem isolierten Private Cloud Kontext läuft. Das heißt, wir können SQL und eine Technik benutzen, um Celery zu infizieren. Aber wir nutzen halt diesen Pickle Celery Fehler, um auf dem Datenbank Cluster, das in dem Virtual Private Cloud Teil läuft, laufen zu lassen. So, das Problem ist jetzt, jetzt können wir nicht mehr kommunizieren, weil wir haben unseren Code in den Virtual Private Cloud Teil geschoben, aber der ist ja isoliert voneinander. Und jetzt kommt eben dieser Teil rein, dass wir dadurch, dass uns jemand vergessen hat, die Permission Network Interfaces zu erstellen, zu blocken, und wir können eben in dem VPC einen Network Interfaces erstellen. Und wir können eben die Metadaten darüber auf dieses Network Interfaces schreiben und können diese Informationen zurück durch eben den folgen Rückkanal, den wir uns aufgebaut haben mit den Canaries extrahieren. Was das nett ist, ähnlich, ist der Comput-Cluster möglich, DNS-Einträge zu und es ist möglich, Cues und Einmal zu erzeugen. Seid kreativ, dass viel was ihr ausprobieren könnt, dass eine einfache überlappende Erlaubnis ist genug, um Dateien rauszutragen. Ihr könnt Informationen in Länge der Queue, Verschlussung, das dann austragen. Ihr könnt alles nutzen, wie die Network Interfaces, das ist ziemlich cool. Was ist das, wenn Sie den Bug fixieren? Persistenz. Wie können wir das fixen ohne permanente Infrastruktur? Ein praktisches Lambda-Feature ist es nützlich, dass Sie euch Labels für diese Funktionen und speichern all die Funktionen mit alias für euch. Was praktisch ist für application maintainers, sie können ihre Dateien taggen und da ist ein Auditrail und wir können das auch nutzen, um so eine Melvia ständig zu machen. Wir können eine Backdoor-Version hochladen und wir können es dann da verstecken, falls wir das Access-Azugriff brauchen. Eine alternative Route ist, was bei Travis oder irgendwelchen CAs das System benutzt, ist Cloud Information. Wir benutzen den Code, der permanent läuft. Wir infizieren einfach den Code, der auf der S3 läuft. Und das nächste Mal, wenn die CAs die Applikation update, benutzen Sie den infizierten Code. Das ist nützlich. Wenn wir Zugriff zu den Codebuckets haben, zu dem Code einmal nach, wir benutzen alle anderen Lambda Funktionen in einem Haufen zu infizieren. Das Beste ist, alles serverlos zu behandeln. Wir haben die Lambda Foo, die ausgelöstet, wenn eine SQS ausgeführt. Das ist eine Funktion, die alle alias bis zurück zur ersten. Wir sind eine Funktion mit einer Hintertür auszubasteln. Und dann können wir das im alias bis zur ersten Funktion zurücksetzen, dass unseren Hintertür-Code ausführt. Weil immer neuer Code ist updated durch den S3 Heimat. Das wird auf jeden Fall die Ausführung von unserer Melvia ausführen. Und dann uns mit unserer Hintertür infizieren. Und dann haben wir eine Funktion, eine Time with the Hintertür überall drin. Neuer Code ableidet unsere Version. Ich werde hier schnell gehen, weil es aufräumlich ist. Vorsichtig wäre, wenn man hier haben muss, die haben einige IDs. Dann gibt es noch die Log Groups, weil die den Umgebungsvariablen verfügbar sind. Wir können hoffen, dass sie auf die Logs gucken, das ist nicht gut. Eine bessere Technik ist, nichts am Anfang zu loggen. Diese Funktionen haben eine sehr kleine Speichergröße. Wenn wir den Speicher überschreiben von der Funktion, dann ist das nicht genug Speicher, um das Logging durchzuführen. Und wir packen uns ein Canary Code. Und dann zählt das nicht als Invocation Error. So, eine Sache, die man dabei bedenken sollte, dann könnte es tatsächlich doch dazu kommen, dass ein Lock-Eintag erstellt wird, wenn das zu schnell passiert. Teil 6, Suthese. Frohe Weihnachten, alle. Ich bin Santa Claus und gebe euch ein Geschenk. Ich gebe euch ein AWS Lambda Infektions-Toolkit. Das heißt MacKenzie und ihr könnt quasi die ganzen Tricks, über die wir heute gesprochen haben, nochmal selber ausprobieren. Ja, das Ganze findet sich auf GitHub, da der URL, die eben gezeigt wurde, zusammenfassend sehen wir das servalose Architekturen, da kann man neue Hindernisse zeigen. Und der haben wir trotzdem weggefunden, um diese Hindernisse zu umgehen, wenn wir den Code, also wenn wir diese Dienste exploiten wollen. Danke für eure Aufmerksamkeit. Und jetzt geht es weiter mit Fragen. Thanks a lot, Rich. Unfortunately we don't have any time left for Q&A, but are you going to be around for questions? Perfect. Wir haben doch keine Zeit für Fragen. Ihr könnt nach vorne kommen, wenn ihr noch weitere Fragen habt.