Misbruik van metagegevens van instanties

Wat is Misbruik van metagegevens van instanties?

Nu het oudere tokenloze v1-protocol is toegestaan, beantwoordt de instance-metagegevensservice elk eenvoudig verzoek vanuit de instance, inclusief een verzoek om de tijdelijke inloggegevens van de instancerol. Dat verandert een gewone bug voor vervalsing van verzoeken aan de serverzijde in diefstal van cloudgegevens. U verwijst de source_url van een importfunctie naar 169.254.169.254, leest de toegangssleutel, het geheim en het sessietoken en gebruikt deze om gegevens te bereiken die de toepassing nooit zou kunnen bereiken. De oplossing is IMDSv2: vereist een sessietoken zodat een enkele vervalste GET niet kan worden voltooid, en stel de responshoplimiet in.

Wat je leert in Misbruik van metagegevens van instanties

• Als v1 is toegestaan, verstrekt de metadataservice rolreferenties aan alles wat een verzoek kan indienen vanuit de instance, zonder eigen authenticatie.
• Een bug bij het vervalsen van verzoeken in de applicatie wordt diefstal van cloudgegevens en vervolgens een draaipunt in het besturingsvlak.
• Het vereisen van een sessietoken verandert een enkel vervalst verzoek in een uitwisseling in twee stappen die de meeste vervalste bugs niet kunnen voltooien.
• Repareer dit in de instanceconfiguratie, omdat dit elke bug bij het vervalsen van verzoeken omvat, in plaats van de bug die is gevonden.

Misbruik van metagegevens van instanties — Trainingsstappen

1. Een server die voor u ophaalt

   Bob werkt bij Vurloch, een bedrijf waarvan de software gebouwinspecties uitvoert: schema's, rapporten en de toegangsgegevens die inspecteurs nodig hebben om eigendommen binnen te komen. Eén kenmerk valt hem op, omdat het ophalen zelf plaatsvindt. Inspecteurs kunnen een rapport importeren door een URL te plakken. De server van Vurloch haalt het op. Dat betekent dat Bob de server van Vurloch dingen kan laten vragen waar Bob niet direct bij kan.

2. Wat de functie eigenlijk doet

   Voordat hij het aanraakt, leest Bob wat de pagina te bieden heeft. Het is een importtool: plak een link naar een inspectierapport en Vurloch archiveert deze tegen de woning. Het interessante deel is wie het downloaden doet.

3. Gebruik de functie zoals bedoeld

   Hij begint het te gebruiken zoals een inspecteur dat zou doen: plak de rapport-URL van een partner en laat Vurloch deze ophalen. Wat hij in werkelijkheid doet, is het verzoek op de telefoon krijgen, zodat hij ernaar kan kijken.

4. De URL is slechts een parameter

   Het importeren werkte. Bob opent het netwerkpaneel en kijkt naar wat de pagina daadwerkelijk heeft verzonden, omdat een functie die URL's ophaalt alleen interessant is als hij de URL beheert.

5. Wijs het naar de metadataservice

   Er is één adres dat alleen antwoordt vanuit een cloudinstantie: de metadataservice, op een vast link-local IP. Hoewel het nog steeds het oudere tokenloze v1-protocol toestaat, verkoopt het de eigen rolreferenties van de instantie aan alles op de instantie dat daarom vraagt ​​met een gewone GET. Bob bewerkt het vastgelegde verzoek, vervangt de partner-URL door dat adres en verzendt het opnieuw.

6. Het heeft de inloggegevens opgehaald

   De server deed precies wat hem werd gevraagd en gaf terug wat er aan de andere kant uitkwam.

7. Wiens geloofsbrieven zijn deze

   Bob slaat de drie waarden op in een profiel en vraagt aan de cloud wie hij nu is.

8. Wat de server kon bereiken, maar dat de app nooit heeft blootgelegd

   De aanvraag kan aangifte doen tegen een pand. De rol erachter kan veel meer, en Bob gaat op zoek naar de gegevens die de app bewaart maar nooit uitdeelt. Hij streamt het inspectiearchief rechtstreeks naar zijn terminal. Bob beschikt over fysieke toegangsgegevens voor tienduizenden eigendommen, via een functie die alleen URL's ophaalt.

9. Waar de inloggegevens vandaan kwamen

10. De identiteit van de server, gebruikt als een persoon

    De monitoring van Vurloch markeert de rolleesopslag van de app-instantie waarvoor geen reden bestaat om deze aan te raken.