GCP - Network Docker Escape
Aanvanklike Toestand
In beide write-ups waar hierdie tegniek gespesifiseer word, het die aanvallers root-toegang binne 'n Docker-houer wat deur GCP bestuur word, verkry met toegang tot die gasheer-netwerk (en die vermoëns CAP_NET_ADMIN en CAP_NET_RAW).
Aanval Verduideliking
Op 'n Google Compute Engine-instantie toon gereelde inspeksie van netwerkverkeer tallose gewone HTTP-versoeke na die metadata-instantie by 169.254.169.254. Die Google Guest Agent, 'n oopbron-diens, maak gereeld sulke versoeke.
Hierdie agent is ontwerp om veranderinge in die metadata te monitor. Merkwaardig sluit die metadata 'n veld vir SSH-publieke sleutels in. Wanneer 'n nuwe publieke SSH-sleutel by die metadata gevoeg word, magtig die agent dit outomaties in die .authorized_key-lêer. Dit kan ook 'n nuwe gebruiker skep en hulle by sudoers voeg indien nodig.
Die agent monitor veranderinge deur 'n versoek te stuur om alle metadata-waardes outomaties te herwin (GET /computeMetadata/v1/?recursive=true). Hierdie versoek is ontwerp om die metadata-bediener te laat reageer slegs as daar enige verandering in die metadata sedert die laaste herwinning is, geïdentifiseer deur 'n Etag (wait_for_change=true&last_etag=). Daarbenewens word 'n timeout-parameter (timeout_sec=) ingesluit. As geen verandering binne die gespesifiseerde timeout plaasvind nie, reageer die bediener met die ongewysigde waardes.
Hierdie proses maak dit moontlik vir die IMDS (Instance Metadata Service) om na 60 sekondes te reageer as geen konfigurasieverandering plaasgevind het nie, wat 'n potensiële venster skep vir die inspuiting van 'n vals konfigurasierespons na die gasheeragent.
'n Aanvaller kan hiervan misbruik maak deur 'n Man-in-the-Middle (MitM) aanval uit te voer, waarby die respons van die IMDS-bediener vervals word en 'n nuwe publieke sleutel ingespuit word. Dit kan ongemagtigde SSH-toegang tot die gasheer moontlik maak.
Ontsnappingstegniek
Hoewel ARP-spoofing nie effektief is op Google Compute Engine-netwerke nie, kan 'n aangepaste weergawe van rshijack ontwikkel deur Ezequiel gebruik word vir pakketsinspuiting in die kommunikasie om die SSH-gebruiker in te spuit.
Hierdie weergawe van rshijack maak dit moontlik om die ACK- en SEQ-nommers as opdragreël-argumente in te voer, wat die vervalsing van 'n respons voor die werklike Metadata-bediener-respons fasiliteer. Daarbenewens word 'n klein Shell-skripsie gebruik om 'n spesiaal vervaardigde payload terug te gee. Hierdie payload veroorsaak dat die Google Guest Agent 'n gebruiker wouter skep met 'n gespesifiseerde publieke sleutel in die .authorized_keys-lêer.
Die skripsie gebruik dieselfde ETag om te voorkom dat die Metadata-bediener die Google Guest Agent onmiddellik in kennis stel van verskillende metadata-waardes, en vertraag sodoende die respons.
Om die vervalsing uit te voer, is die volgende stappe nodig:
Monitor versoek na die Metadata-bediener met behulp van tcpdump:
Soek na 'n lyn soortgelyk aan:
Stuur die vals metadata data met die korrekte ETAG na rshijack:
Hierdie stap gee die publieke sleutel toestemming, wat SSH-verbinding met die ooreenstemmende private sleutel moontlik maak.
Verwysings
Last updated