Odkrywanie wiader 25S AWS S3

Problemy z uprawnieniami segmentów AWS S3 są tak stare, jak sama usługa. Myślę, że 2 najbardziej znane badania na ten temat zostały przeprowadzone przez Skyhigh, wskazując, że 7% wszystkich segmentów S3 jest otwartych, a Rapid7 wskazując, że nawet 17% jest otwartych. Dzisiaj jesteśmy w 2018 roku i postanowiłem sprawdzić, jaki jest obecny stan problemu. Dodatkowo chcę zaprezentować moje techniki przeprowadzania takich badań - jeśli przegapiłem jakąś sprytną, daj mi znać w komentarzach.

Zacznijmy od teorii

Wszystkie segmenty AWS S3 mogą być dostępne przy użyciu następujących adresów URL:

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

lub używając AWS CLI:

$ aws s3 ls --region [nazwa_ regionu] s3: // [nazwa_pola]

Nieczęsto ludzie wskazują na potrzebę użycia parametru regionu. Jednak niektóre segmenty nie działają bez określenia regionu. Nie widzę wzoru, gdy działa, a gdy nie, więc dobrą praktyką jest zawsze dodawanie tego parametru :)

Ogólnie mówiąc, znalezienie prawidłowego segmentu jest równoznaczne ze znalezieniem poddomeny s3.amazonaws.com lub [aws_endpoint] .amazonaws.com. Poniżej omówię 4 metody, które mogą być pomocne w tym zadaniu.

Bruteforcing

Każda nazwa segmentu musi być unikalna i może zawierać tylko od 3 do 63 znaków alfanumerycznych z kilkoma wyjątkami (może zawierać „-” lub „.”, Ale nie można jej uruchomić ani zakończyć). To powiedziawszy, jesteśmy uzbrojeni w wiedzę wystarczającą do znalezienia wszystkich wiader S3, ale bądźmy szczerzy - działałoby to raczej w przypadku krótkich nazw. Niemniej jednak ludzie używają pewnych wzorców przy nazywaniu nazw, np. [nazwa_firmy] -dev lub [nazwa_firmy]. kopie zapasowe. Gdy szukasz wiadra konkretnej firmy, możesz łatwo zautomatyzować proces weryfikacji tak dobrze znanych wzorców za pomocą narzędzi takich jak LazyS3 lub aws-s3-bruteforce. Załóżmy, że mamy firmę Rzepsky. Proste polecenie: $ ruby ​​lazys3.rb rzepsky ujawnia wiadro rzepsky-dev:

Ale co, jeśli chcesz zebrać jak najwięcej wiader bez konkretnej nazwy na początek? Czytaj dalej ten post;)

Wayback Machine

Czy słyszałeś kiedyś o Wayback Machine? Cytując Wikipedię:

Wayback Machine to cyfrowe archiwum World Wide Web i innych informacji w Internecie stworzone przez Internet Archive.

Niektóre zasoby w tym cyfrowym archiwum są przechowywane w infrastrukturze Amazon. Biorąc to pod uwagę, jeśli Wayback Machine zindeksował tylko jedno zdjęcie w segmencie S3, możemy pobrać te informacje i sprawdzić, czy ten segment zawiera zasoby publiczne. Nawet gdy indeksowane zdjęcie jest już usunięte (lub odmowa dostępu do niego), nadal masz nazwę wiadra, co daje nadzieję na znalezienie interesujących plików w środku. Aby zapytać API Wayback Machine, możesz użyć modułu Metasploit o nazwie enum_wayback:

Jak możesz pamiętać od początku tego postu, możesz odwoływać się do zawartości segmentu również przy użyciu adresu URL ze specyfikacją regionu. Tak więc, aby uzyskać jeszcze lepsze wyniki, możemy sprawdzić poddomeny każdego możliwego punktu końcowego Amazon S3 za pomocą prostego bash one-liner:

$ podczas odczytu -r region; do msfconsole -x "use \ auxiliary / scanner / http / enum_wayback; ustaw DOMAIN $ region; \
ustaw OUTFILE $ region.txt; biegać; exit "; done 

Bardzo często Wayback Machine zwraca kilka tysięcy zdjęć umieszczonych w jednym wiadrze. Musisz więc wykonać kilka operacji, aby wyciągnąć tylko prawidłowe i unikalne nazwy segmentów. Programy takie jak cut i awk są tutaj świetnymi przyjaciółmi.

Wayback Machine dał mi 23498 potencjalnych wiader w postaci 398,7 MB plików tekstowych. 4863 z tych wiader było publicznie otwartych.

Zapytania stron trzecich

Inną techniką, którą chciałbym wprowadzić, jest wysyłanie zapytań do stron trzecich, takich jak Google, Bing, VirusTotal itp. Istnieje wiele narzędzi, które mogą zautomatyzować proces pozyskiwania interesujących informacji z usług zewnętrznych. Jednym z nich jest Sublist3r:

Ponownie powinniśmy przeszukać poddomeny każdego regionu, a następnie wyciągnąć tylko unikalne nazwy segmentów. Szybki, jednoliniowy podkład:

$ podczas odczytu -r region; wykonaj python3 sublist3r.py -d $ region \
> $ region.txt; done 

daje wynik 756, z którego… tylko 1 wiadro było kolekcjonerskie. Piwo dla administratorów!

Wyszukiwanie w dziennikach przezroczystości certyfikatów

Ostatnią techniką, którą chciałbym przedstawić, jest wyszukiwanie nazw segmentów poprzez obserwowanie dzienników przezroczystości certyfikatów. Jeśli nie znasz przezroczystości certyfikatów, zalecamy obejrzenie tej prezentacji. Zasadniczo każdy wydany certyfikat TLS jest rejestrowany, a wszystkie dzienniki są publicznie dostępne. Głównym celem tego pomysłu jest sprawdzenie, czy któryś certyfikat nie jest błędnie lub złośliwie użyty. Jednak idea dzienników publicznych ujawnia wszystkie domeny, w tym… tak, również segmenty S3. Dobrą wiadomością jest to, że istnieje już dostępne narzędzie, które wyszukuje Ciebie - strumień danych. Jeszcze lepszą wiadomością jest to, że to narzędzie sprawdza również uprawnienia do znalezionego wiadra. Spróbujmy:

$ python3 bucket-stream.py --threads 100 --log

Po sprawdzeniu 571134 możliwości skaner kubełkowy zwrócił mi 398 ważnych wiader. 377 z nich było otwartych.

Weryfikowanie zawartości wiadra

W porządku, znaleźliśmy tysiące nazw wiader i co dalej? Możesz na przykład sprawdzić, czy którykolwiek z tych segmentów zezwala na publiczny lub Dowolny uwierzytelniony użytkownik AWS (który jest zasadniczo taki sam jak publiczny) dostęp. W tym celu możesz użyć mojego skryptu BucketScanner - po prostu wyświetla listę wszystkich dostępnych plików, a także weryfikuje uprawnienia WRITE do segmentu. Jednak na potrzeby tych badań zmodyfikowałem metodę bucket_reader w następujący sposób:

def wiad_reader (nazwa_ wiadra):
    region = get_region (nazwa_kopy)
    jeśli region == „Brak”:
        przechodzić
    jeszcze:
        bucket = get_bucket (nazwa_ wiadra)
        wyniki = „”
        próbować:
            dla s3_object w bucket.objects.all ():
                jeśli s3_object.key:
                    drukuj „{0} jest kolekcjonerski” .format (nazwa_bufora)
                    results = "{0} \ n" .format (nazwa_powrotu)
                    append_output (wyniki)
                    przerwa

Chociaż nie jest to najbardziej elegancki sposób, w jaki spełnia swoje zadanie - jeśli tylko jeden plik można było zebrać w wiadrze, mój zmodyfikowany skaner zgłasza to wiadro jako kolekcjonowane.

Ryzyko

Wśród publicznie dostępnych plików można znaleźć naprawdę interesujące. Ale wyciek poufnych danych to nie jedyne ryzyko.

Niektóre wiadra można publicznie zapisać. Na pewno osoba atakująca może użyć takiego wiadra jako punktu dystrybucji złośliwego oprogramowania. Jest to jeszcze bardziej przerażające, jeśli używasz takiego wiadra do dystrybucji legalnego oprogramowania wśród swoich pracowników - wyobraź sobie taki scenariusz: kierujesz wszystkimi nowicjuszami, aby instalowali oprogramowanie z wiadra firmy, a to oprogramowanie zostało już nadpisane przez atakującego zainfekowany instalator. Inną odmianą tego scenariusza byłoby trollowanie badaczy z S3 - np. przesyłając zainfekowany plik o kuszącej nazwie, np. „Raport o wynagrodzeniach - 2017.pdf” (oczywiście wszyscy odpowiedzialni badacze zawsze pobierają niezaufane pliki do środowiska piaskownicy, prawda?)

Innym ryzykiem związanym z publicznie zapisywanymi segmentami jest… utrata wszystkich danych. Nawet jeśli nie masz uprawnień DELETE do obiektów segmentu, ale tylko uprawnienie WRITE, możesz nadal zastąpić dowolny plik. Biorąc to pod uwagę, jeśli zastąpisz dowolny plik pustym plikiem, oznacza to, że ten plik nie jest już dostępny dla nikogo. Rzućmy okiem na ten przykład:

Jedynym mechanizmem, który może zapisać dane w takim scenariuszu, jest włączenie wersji. Jednak ten mechanizm może być drogi (podwaja rozmiar używanej przestrzeni w wiadrze) i niewiele osób decyduje się z niego skorzystać.

Słyszałem też argument:

No dalej, to tylko wiadro do celów testowych.

Cóż, jeśli wiadro „testowe” stanie się miejscem przechowywania nielegalnych treści, to… przepraszam stary, ale to karta kredytowa jest przypięta do tego konta.

Jakaś świetlana przyszłość?

Problem z uprawnieniami segmentów S3 nadal istnieje i nie oczekuję spektakularnej zmiany w najbliższej przyszłości. Ludzie IMHO zapewniają publiczny dostęp, ponieważ zawsze działa - nie musisz się martwić o określenie uprawnień, gdy usługa S3 współpracuje z innymi usługami. Innym powodem może być prosty błąd w konfiguracji uprawnień (np. Umieszczenie znaku „*” w niewłaściwym miejscu w polityce segmentu) lub niezrozumienie predefiniowanych grup (np. Grupa „Dowolne uwierzytelnione konto AWS” może być nadal konfigurowana przez AWS CLI).

Innym problemem jest to, jak zgłosić takie problemy? Do wiadra nie ma przypiętego e-maila, więc nigdy nie możesz mieć pewności, z kim możesz się skontaktować. Nazwy wiader mogą oznaczać, że należą do firmy X, ale pamiętaj, że każdy może ją swobodnie nazwać. Uważaj więc na trollery!

Podsumowanie

W przypadku zeskanowanych wiader 24652 udało mi się zebrać pliki z 5241 wiader (21%) i przesłać dowolne pliki do 1365 wiader (6%). Na podstawie wyników mogę bez wątpienia stwierdzić, że problem nadal istnieje. Chociaż niektóre segmenty są celowo otwierane (np. Zawiera zdjęcia, broszury firmowe itp.), Żadne z nich nie powinno być publicznie dostępne. Jestem prawie pewien, że istnieją inne fajne metody znajdowania jeszcze większej liczby segmentów, więc jedynym rozsądnym środkiem zaradczym wydaje się być… ustawienie odpowiednich uprawnień do segmentu

Proszę również znaleźć mój Siedmiostopniowy przewodnik po zabezpieczaniu królestwa AWS.