Utforska 25K AWS S3 hinkar

Problem med AWS S3-skopans behörigheter är lika gamla som själva tjänsten. Jag tror att två av de mest kända undersökningarna om denna fråga utfördes av Skyhigh som pekade på att 7% av alla S3-hinkar är öppna och av Rapid7 som påpekade att även 17% är öppna. Idag är vi 2018 och jag har bestämt mig för att kontrollera vad som är aktuell status för problemet. Dessutom vill jag presentera mina tekniker för att utföra sådan forskning - om jag missade någon smart, vänligen meddela mig i kommentarerna.

Låt oss börja med någon teori

Alla AWS S3-hinkar kan vara tillgängliga med följande URL: er:

https: // [bucket_name] .s3.amazonaws.com /
https: // [aws_endpoint] .amazonaws.com / [bucket_name] /

eller med AWS CLI:

$ aws s3 ls - region [region_name] s3: // [bucket_name]

Ofta pekar människor på behovet av att använda en regionparameter. Vissa hinkar fungerar dock inte utan att ange en region. Jag ser inte ett mönster när det fungerar och när det inte är så bra är det alltid att lägga till den här parametern :)

Så generellt sett att hitta en giltig hink är lika med att hitta ett underdomän till s3.amazonaws.com eller [aws_endpoint] .amazonaws.com. Nedan kommer jag att gå igenom fyra metoder som kan vara till hjälp i den här uppgiften.

Bruteforcing

Varje skopnamn måste vara unikt och kan innehålla bara 3 till 63 alfanumeriska tecken med några få undantag (kan innehålla ‘-‘ eller ‘.’ Men det kan inte startas eller slutas med). Med det sagt är vi vapen med kunskap tillräckligt för att hitta alla S3-hinkar, men låt oss vara ärliga - det skulle fungera snarare för korta namn. Ändå brukar människor använda vissa mönster i namngivning, t.ex. [company_name] -dev eller [company_name] .backup. När du söker efter ett visst företags hink kan du enkelt automatisera en process för att verifiera sådana välkända mönster med verktyg som LazyS3 eller aws-s3-bruteforce. Låt oss säga att vi har ett företag som heter Rzepsky. Ett enkelt kommando: $ ruby ​​lazys3.rb rzepsky avslöjar en rzepsky-dev-hink:

Men tänk om du vill skörda så många hinkar som möjligt utan något specifikt namn till att börja med? Fortsätt läsa det här inlägget;)

Wayback-maskin

Har du någonsin hört talas om Wayback Machine? Citera Wikipedia:

Wayback Machine är ett digitalt arkiv med World Wide Web och annan information på Internet skapad av Internet Archive.

Vissa resurser i detta digitala arkiv lagras i Amazon-infrastruktur. Med det sagt, om Wayback Machine har indexerat bara ett foto på en S3-hink, kan vi hämta denna information och kontrollera om den här hinken innehåller några offentliga resurser. Även när det indexerade fotot redan har tagits bort (eller tillgång till det nekas) har du fortfarande namnet på skopan, vad ger hopp om att hitta intressanta filer inuti. För att fråga API: s Wayback Machine kan du använda en Metasploit-modul som heter enum_wayback:

Som du kanske kommer ihåg från början av det här inlägget kan du hänvisa till hinkens innehåll också med en URL med regionspecifikation. Så för att få ännu bättre resultat kan vi kontrollera underdomäner för alla möjliga Amazon S3-slutpunkter, med en enkel bashögfodral:

$ medan läs -r region; gör msfconsole -x "använd \ extra / skanner / http / enum_wayback; ställ in DOMAIN $ region; \
ställa in OUTFILE $ region.txt; springa; exit "; gjort 

Mycket ofta ger Wayback Machine dig några tusentals bilder placerade i bara en hink. Så du måste göra några åtgärder för att bara ta ut giltiga och unika skopnamn. Program som cut and awk är fantastiska vänner här.

Wayback Machine gav mig 23498 potentiella skopor i form av 398,7 MB txt-filer. 4863 av dessa hinkar var öppna.

Fråga 3: e parter

En annan teknik som jag skulle vilja introducera är att fråga tredje part, som Google, Bing, VirusTotal etc. Det finns många verktyg som kan automatisera processen för att skörda intressant information från externa tjänster. En av dem är Sublist3r:

Återigen bör vi söka underdomäner i varje region och sedan dra ut endast unika skopnamn. En snabb bashöjd:

$ medan läs -r region; gör python3 sublist3r.py -d $ region \
> $ region.txt; gjort 

ger som resultat 756 varifrån ... endast en hink var insamlingsbar. Öl till administratörerna!

Söker i certifikattransparensloggar

Den sista tekniken som jag skulle vilja presentera dig söker skopnamn genom att titta på certifikattransparensloggar. Om du inte känner till certifikattransparens rekommenderar jag att du tittar på denna presentation. I princip loggas varje utfärdat TLS-certifikat och alla dessa loggar är offentligt tillgängliga. Huvudmålet med denna idé är att verifiera om något certifikat inte används felaktigt eller skadligt. Men idén om offentliga loggar avslöjar alla domäner, inklusive ... ja, S3-hinkar också. Goda nyheter är att det redan finns ett tillgängligt verktyg som söker efter dig - hinkströmmen. Ännu bättre nyheter är att det här verktyget också verifierar behörigheter till den hink som den hittade. Så låt oss göra det:

$ python3 bucket-stream.py - trådar 100 - logg

Efter att ha kontrollerat 571134 möjligheter gav hink-skannern tillbaka 398 giltiga skopor. 377 av dem var öppna.

Verifierar skopans innehåll

Okej, vi hittade tusentals skopnamn och vad händer nu? Tja, du kan till exempel kontrollera om någon av dessa hinkar tillåter allmänhet eller för alla autentiserade AWS-användare (som i princip är samma som offentliga) åtkomst. För det ändamålet kan du använda mitt skript BucketScanner - det listar helt enkelt alla tillgängliga filer och verifierar också WRITE-behörigheterna till en hink. För ändamålet med denna forskning ändrade jag emellertid en bucket_reader-metod på följande sätt:

def bucket_reader (bucket_name):
    region = get_region (bucket_name)
    om region == 'Ingen':
        passera
    annan:
        bucket = get_bucket (bucket_name)
        resultat = ""
        Prova:
            för s3_object i bucket.objects.all ():
                om s3_object.key:
                    tryck "{0} är samlingsbart" .format (bucket_name)
                    results = "{0} \ n" .format (bucket_name)
                    append_output (resultat)
                    ha sönder

Även om det inte är det mest eleganta sättet det gör sitt jobb - om bara en fil var samlingsbar i skopan, så rapporterar min modifierade skanner den här skopan som samlingsbar.

Riskerna

Bland de offentligt tillgängliga filerna kan du hitta riktigt intressanta filer. Men att läcka av känsliga data är inte den enda risken.

Vissa hinkar är offentligt skrivbara. För att en angripare kan använda en sådan hink som en distributionsplats för skadlig programvara. Det är ännu mer skrämmande om du använder en sådan hink för att distribuera en legit programvara bland dina anställda - föreställ dig ett sådant scenario: du guider alla nykomlingar att installera en programvara från företagets hink och den här programvaran skrivs redan över av en angripare med infekterad installerare. Den andra variationen av detta scenario skulle vara trollande S3-forskare - t.ex. genom att ladda upp infekterad fil med ett frestande namn, som "Lönrapport - 2017.pdf" (naturligtvis laddar alla ansvariga forskare alltid ned pålitliga filer till sandlådan, eller hur?)

En annan risk med offentligt skrivbara hinkar är ... att du kan förlora all din data. Även om du inte har DELETE-behörigheter för att skopa objekt, men bara en WRITE-behörighet kan du fortfarande skriva över alla filer. Med det sagt, om du skriver över någon fil med tom fil betyder det att den här filen inte längre är tillgänglig för någon. Låt oss ta en titt på det här exemplet:

Den enda mekanism som kan spara dina data i ett sådant scenario är att aktivera en versionering. Emellertid kan denna mekanism vara dyr (den fördubblar storleken på använt utrymme i din hink) och inte många väljer att använda den.

Jag har också hört ett argument:

Åh, kom, det är bara en hink för testningsändamål.

Tja, om din "test" -hink blir ett lagringsutrymme för olagligt innehåll, så ... sorry dude men det är ditt kreditkort som är fäst på det här kontot.

Någon ljusare framtid?

Problemet med S3-hinkbehörigheter finns fortfarande och jag förväntar mig inte en spektakulär förändring inom närmaste framtid. IMHO-människor ger allmänheten tillgång, eftersom det alltid fungerar - du behöver inte oroa dig för att ange behörigheter när en S3-tjänst samarbetar med andra tjänster. Det andra skälet kan vara ett enkelt misstag när du konfigurerar behörigheter (t.ex. att sätta ett "*" -tecken på en fel plats i en hinkpolicy) eller inte förstå fördefinierade grupper (t.ex. en grupp "Alla autentiserade AWS-konton" kan fortfarande ställas in via AWS CLI).

Ett annat problem är hur man rapporterar sådana problem? Det finns inget e-postmeddelande i skopan så att du aldrig kan vara säker på vem du ska kontakta. Namnen på hinkar kan indikera att de tillhör företag X, men kom ihåg att vem som helst kan lösa det. Så se upp för trollare!

Sammanfattning

För 24652 skannade skopor kunde jag samla filer från 5241 skopor (21%) och ladda upp godtyckliga filer till 1365 skopor (6%). Baserat på resultaten kan jag utan tvekan säga att problemet fortfarande existerar. Medan vissa hinkar öppnas avsiktligt (serverar t.ex. vissa bilder, företagsbroschyrer etc.), bör ingen av dem vara offentligt skrivbara. Jag är ganska säker på att det finns andra coola metoder för att hitta ännu fler hinkar, så det enda rimliga motåtgärdet verkar vara ... ställa in rätt behörigheter för din hink

Vänligen hitta min sju-steg-guide för att skydda ditt AWS Kingdom.