Włamanie się na konto AWS - Część 1: Atlassian Apps

2 października 2020

Ponieważ nasza coraz bardziej zaawansowana technologia tworzy coraz więcej wzajemnie powiązanych systemów, potrzeba większego bezpieczeństwa staje się ważniejsza niż kiedykolwiek wcześniej. Jednak bezpieczeństwo cybernetyczne nie jest już równoznaczne z tworzeniem zapory sieciowej lub oprogramowania antywirusowego; jest to proces obejmujący politykę, szkolenia, zgodność z przepisami, ocenę ryzyka i infrastrukturę. Brak tego procesu może prowadzić do utraty ważnych danych i utraty reputacji.

W tym artykule przedstawię koncepcję White Hat Hacking i pokażę, jak udało mi się uzyskać dostęp do konta AWS poprzez niezabezpieczoną i przestarzałą maszynę Jira.

Więc zanurkujmy od razu!

White Hats kontra Black Hats

Trick to Covering all Bases

Potrzeba solidnego bezpieczeństwa jest szczególnie istotna w przypadku rozwiązań w chmurze, ponieważ Twoje dane stale przepływają z jednego punktu do drugiego. Jeśli nie są one odpowiednio zabezpieczone, dane te mogą być podatne na wykorzystanie w drodze z punktu końcowego do punktu końcowego.

Są ludzie, którzy mogą chcieć nie tylko zakłócić Twoją stronę internetową, komunikację i aplikacje dla zysku finansowego, ale również zaszkodzić Twojej reputacji. Działają oni w ciemności, z dala od głównego nurtu i specjalizują się w wykorzystywaniu luk i słabych punktów.

Tak więc, pytanie za milion dolarów brzmi: gdzie są słabe punkty w twoich systemach?

CISO Société Générale, Stephane Nappo, powiedział kiedyś, że "jednym z głównych zagrożeń cybernetycznych jest myślenie, że nie istnieją". Identyfikacja zagrożenia bezpieczeństwa za pomocą konwencjonalnych metod testowania, takich jak testy jednostkowe, integracyjne, dymne i regresyjne, może być rzeczywiście trudna.

Częściej niż nie, testy te - zazwyczaj przeprowadzane z wewnątrz własnej organizacji - nie zawsze zdołają realnie stworzyć warunki, które istnieją dla kogoś, kto chce się dostać z zewnątrz organizacji.

Potrzeba złodzieja, aby złapać złodzieja idzie stare powiedzenie. Jest to również prawdziwe w sferze cyfrowej. W połączeniu z solidną strategią bezpieczeństwa, zasada ta stanowi podstawę etycznego hakowania, zwanego również hakowaniem w białych kapeluszach.

Czym jest hakerstwo w białych kapeluszach?

W przeciwieństwie do powszechnego przekonania, hakerzy nie zawsze są złośliwi!

Generalnie rozróżniamy hakerów w czarnych kapeluszach od hakerów w białych kapeluszach - wszyscy z nich mają zazwyczaj głęboką wiedzę na temat włamywania się do systemów komputerowych i omijania protokołów bezpieczeństwa. Różnica polega na intencji.

Haker w białym kapeluszu jest ekspertem ds. bezpieczeństwa, który odkrywa zagrożenia bezpieczeństwa w oprogramowaniu, które następnie zgłasza właścicielowi w celu wprowadzenia odpowiednich środków bezpieczeństwa; haker w białym kapeluszu zawsze działa w dobrych intencjach.

Jakie są dokładnie te intencje? Aby zwiększyć ogólne bezpieczeństwo Twoich systemów

I jeszcze hakerzy, których wszyscy znamy z filmów: hakerzy w czarnych kapeluszach. Są to eksperci ds. bezpieczeństwa, którzy zamierzają wykorzystywać odkryte naruszenia bezpieczeństwa, aby czerpać z nich korzyści - oczywiście bez uprzedniej zgody właściciela systemu. Ich głównym celem jest wymuszanie, niszczenie reputacji i inne niebezpieczne rzeczy - jestem pewien, że widzieliście już nagłówki.

Ważny element procesu zapewniania jakości

To gra w kotka i myszkę: białe kapelusze próbują odkryć wyczyny systemowe i zlecić ich naprawę, zanim czarne kapelusze będą mogły z nich skorzystać.

Zewnętrzne hakowanie białych kapeluszy powinno być istotną częścią procesu zapewniania jakości w organizacji, ponieważ wypełnia lukę, której testerzy penetracji wewnętrznej nie mogą wypełnić - nawet jeśli realistyczne okoliczności są symulowane. Dzieje się tak dlatego, że zazwyczaj pracują w ramach określonych zadań, a co najważniejsze, często nie są osobiście zmotywowani do kopania naprawdę głęboko.

Jako badacz bezpieczeństwa często zakładam stary biały kapelusz i przeszukuję Internet w poszukiwaniu podatnego na zagrożenia oprogramowania. Podczas moich poszukiwań znajdę właśnie to - źle skonfigurowane maszyny. Sztuczka polega na znalezieniu właściciela danej maszyny. To jest kluczowe wyzwanie, które ja - podobnie jak moi koledzy, hakerzy w czarnych kapeluszach - staram się rozwiązać.

CTO jednej z firm, którym pomogłem zatkać pewne luki w zabezpieczeniach, ujął to w ten sposób:

"To tak, jakbyś natknął się na dom z otwartymi drzwiami, wszedł od razu, żeby sprawdzić, co jest w środku, znalazł zdjęcie właściciela, a potem zadzwonił do nich i powiedział, że twoje rzeczy są zagrożone."

Kiedy robisz testy penetracyjne z wnętrza organizacji, zazwyczaj po prostu zgłaszasz słabe punkty bez sprawdzania wiarygodności, ponieważ wiesz, do kogo należy dom. Ale to jest dokładnie to, co robią hakerzy w czarnych kapeluszach - ich główny cel będzie często nieznany im na początku. Będą próbowali wszystkiego, aby znaleźć referencje. A kiedy to zrobią, mogą zacząć przynosić zyski.

Jak już mówiłem, trzeba jednego z nich poznać!

Jak włamałem się na konto AWS

Cyber Cold Case czy Current Risk?

W trakcie moich poszukiwań, aby dowiedzieć się więcej o skutecznym zabezpieczaniu rozwiązań w chmurze, czasami wykonuję testy penetracyjne, aby sprawdzić, na ile bezpieczne jest dane oprogramowanie. Zazwyczaj znajduję ciekawe tematy w Cyber Security Subreddit i wykorzystuję db, a następnie decyduję się zgłębić coś więcej.

Podczas ostatniego "nalotu rekonesansowego", przeszedłem przez kilka starych luk w oprogramowaniu Atlassian, które zostały odkryte już w 2018 roku, aby sprawdzić, czy niektóre firmy nadal są podatne na zagrożenia. W 2018 roku błąd ten był dość powszechny i wiele firm zakodowało się, aby naprawić tę lukę w zabezpieczeniach - ale nie wszystkie, jak się okazało.

Zacząłem od przeszukiwania Internetu za pomocą wyszukiwarek takich jak Shodan, Censys czy BinaryEdge, które indeksują odpowiedzi z różnych portów na wszystkich IP i stale monitorują Internet pod kątem luk w zabezpieczeniach. Podczas moich poszukiwań znalazłem wiele maszyn, na których uruchomione było przestarzałe oprogramowanie Jira.

W przypadku wersji oprogramowania Jira w wersji poniżej v7.3.5 chodzi o to, że zawierają one podatny na zagrożenia otwarty serwer proxy, który może być używany anonimowo do zwracania wszelkich danych z sieci wewnętrznych.

Załóżmy, że serwer Jira działa pod następującym adresem:

https://example.com/secure/Dashboard.jspa

Wiedziałem więc, że Jira w tej wersji zawierał ten błąd, ale aby się upewnić, sprawdziłem podatną wtyczkę, aby potwierdzić, że luka nadal istnieje w tej maszynie. I tak się stało!

Dowód koncepcji - próbowałem otworzyć google.com pod domeną example.com:

https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com

Następnie upewniłem się, że maszyna działa na AWS, sprawdzając nazwę DNS. Stwierdziłem, że to IP należy do instancji EC2 w AWS, więc byłem na dobrej drodze - i zagłębiłem się w znane mi terytorium.

Kopiąc trochę głębiej

Teraz wiem, że instancja EC2 może pytać o lokalny adres dla danych użytkownika i metadanych.

Dane użytkownika to skrypt, który użytkownik dostarcza do maszyny, która ma zostać wykonana po uruchomieniu maszyny. Dane użytkownika czasami zawierają poufne informacje.

Z drugiej strony, metadane zawierają szczegóły dotyczące instancji EC2, takie jak Region AWS, Strefa dostępności, nazwa klucza SSH - a gdy dołączona jest jakaś rola IAM, można nawet wyodrębnić tymczasowe dane uwierzytelniające! EC2 instance generuje te tymczasowe dane uwierzytelniające w celu komunikacji z innymi usługami AWS. Możesz je wyodrębnić i używać ich z lokalnej maszyny.

Więc to jest to, co ja zrobiłem! Po prostu poprosiłem o metadane EC2.

https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/

Dostaniesz się do jego mięsa

W zależności od polityki używanej przez rolę przypisaną do instancji EC2, możesz robić z nią różne rzeczy. Jeśli dana rola pozwala tylko na wysyłanie logów do CloudWatch, możesz na przykład zalać CloudWatch dziwnymi danymi, aby go zmylić i wymusić restart instancji lub zainicjować autoskalowanie.

Ale czasami ludzie popełniają błąd nie przestrzegając zasady najmniejszego przywileju, tj. nie pozwalając danej roli tylko na taki dostęp do informacji, aby mogła wykonywać swoją pracę.

Tak więc, może się zdarzyć, że do danej roli dołączona jest polityka AdministratorAccess, a wtedy instancja JIRA może być wykorzystana do prawie wszystkiego: tworzenia zasobów, modyfikowania zasobów, kończenia zasobów, szyfrowania, odszyfrowywania, dostępu do danych rozliczeniowych itp.

Meta dane zwróciły punkt końcowy "iam/", który jest dostępny tylko wtedy, gdy do instancji jest dołączona rola.

Poproszenie o tymczasowe poświadczenie roli dało mi świeży dostęp do AWS, tajne klucze i token sesji:

https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/iam/security-credentials/EXT-JIRA-SERVER-1-ROLE

Dobrze jest również znać region, w którym tworzone są zasoby, ponieważ jest to wymagane, gdy chcesz korzystać z AWS CLI. Można to również wydobyć z metadanych:

https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/placement/availability-zone.

Dzięki tym wszystkim informacjom można za pomocą AWS CLI sprawdzić, jakie działania są możliwe przy użyciu tej roli.

Mój skrypt początkowo po prostu poprosił o listę wiader S3, listę użytkowników JA i informacje o rozliczeniach z ostatniego miesiąca.

Wszystkie prośby zakończyły się powodzeniem. Zazwyczaj oznacza to, że do roli dołączona jest polityka AdministratorAccess, ponieważ zazwyczaj tylko administratorzy mają dostęp do informacji bilingowych.

Aby zidentyfikować właściciela, dodatkowo poprosiłem o dane organizacji AWS i domeny Route53.

Złośliwe uczynki i jak ich unikać

Jak wspomniano wcześniej, za pomocą urządzenia Jira można uzyskać dostęp do sieci wewnętrznej, w której się znajduje. Wszystkie prywatne strefy hostowane (przykład.local) są również otwarte dla Ciebie.

Różne aplikacje Atlassian, które mogą działać tylko w sieci wewnętrznej - jak Confluence lub BitBucket - są teraz otwarte dla mnie. Czasami nawet nie było potrzebne logowanie, ponieważ był to zasób lokalny, a ponieważ mam do niego dostęp z Jira, system myśli, że jestem w sieci wewnętrznej.

Z takim dostępem, haker w czarnym kapeluszu mógłby:

stworzyć dla siebie użytkownika JA, stworzyć dodatkowe klucze dostępu dla istniejących użytkowników, dołączyć role administratora do innych wrażliwych usług, kopiować obiekty z wiader S3, tworzyć AMI z uruchomionych instancji i uruchamiać nowe ze swoimi kluczami do logowania, udostępniać AMI innym kontom AWS, usuwać wszystko z konta, opuszczać Organizację AWS, usuwać logi CloudTrail i inne...

Powyższa lista ilustruje wiele opcji, które haker w czarnym kapeluszu ma do dyspozycji, aby pomieszać z Twoim kontem AWS. Więc, co poszło źle w tym przykładzie?

Złamana zasada najmniejszych uprawnień - Każdy użytkownik, program lub proces powinien mieć tylko minimum uprawnień, aby móc wykonywać swoje funkcje. W tym przypadku rola administratora przypisana do EC2 nadała mu nieograniczone uprawnienia. Przestarzałe oprogramowanie - Aktualizacje oprogramowania mogą zawierać nowe lub ulepszone funkcje oraz lepszą kompatybilność z innymi urządzeniami i aplikacjami. Ale co ważniejsze, zapewniają również poprawki bezpieczeństwa. W tym przypadku był to dobrze znany exploit z 2018 roku, który pozwolił na łatwe wydobycie poufnych informacji. Atlassian naprawił ją już dawno temu, ale użytkownicy, którzy nie naprawili swoich aplikacji, nadal są podatni na zagrożenia.

Wrażliwe aplikacje i ich wersje:

Bambus < 6.0.0 Confluence < 6.1.3 Jira < 7.3.5 Bitbucket < 4.14.4 Crowd < 2.11.2 Crucible & Fisheye < 4.3.2

Dobrze wydane pieniądze, ale niezbyt dobrze zabezpieczone.

Na długiej liście przeciekających kluczy dostępu znalazłem. Niektóre dawały mi dostęp do kont, na które wydawano prawie 100.000 dolarów miesięcznie na AWS.

Oto podział poniesionych kosztów, zaczerpnięty z informacji bilingowych:

Miesięczne wydatki na AWS w $

AWS CloudTrail: 0.00 AWS Config: 66,92 AWS Direct Connect: 25,25 AWS Glue: 0,00 AWS IoT: 0,00 AWS Key Management Service: 45,80 AWS Lambda: 298,20 AWS Secrets Manager: 0,00 Amazon DynamoDB: 24,94 Amazon EC2 Container Registry (ECR): 0,06 Amazon EC2 Container Service: 0,00 Amazon ElastiCache: 1.041.44 EC2 - Inne: 6976.19 Amazon Elastic Compute Cloud - Compute: 61,008.41 Amazon Elastic File System: 3.61 Amazon Elastic Load Balancing: 2.020.69 Amazon Elasticsearch Service: 1.686.58 Amazon Kinesis: 145.08 Amazon Relational Database Service: 2.270.92 Amazon Route 53: 1.148.44 Amazońska prosta usługa e-mail: 2.67 Amazońska prosta usługa powiadomienia: 0.01 Amazońska prosta usługa kolejki: 0.00 Amazońska prosta usługa składowania: 1.770.76 Amazońska prostaDB: 0.00 Amazońska prosta usługa tłumaczenia: 0.08 Amazon Virtual Private Cloud: 559.91 Amazon CloudWatch: 345.10 Podatek: 7.673.75 OGÓŁEM MIESIĄCY WYDANY NA WARSZAWĘ: 87.114.84 USD

Jak widać, firma ta korzysta z wielu zasobów AWS. Jednak ich środki bezpieczeństwa mogą być zdecydowanie ulepszone!

Znalezienie Właścicieli

Aby znaleźć odpowiedzialną organizację, można to zrobić na kilka sposobów. Oto kilka metod, których często używam, aby znaleźć tożsamość.

Nazwa domeny z certyfikatu SSL Domeny z hostowanych stref Route53 Nazwy domen z listy kubełków S3 Adresy e-mail z listy użytkowników IAM Imię, Nazwisko z listy użytkowników IAM -> LinkedIn URLs/Logos na stronie logowania Jira AWS Organizacja główne konto płatnicze e-mail główny użytkownik AWS konto główny użytkownik e-mail Odpowiedzialny adres e-mail ujawnienia ze strony kontaktowej Adres e-mail ochrony danych ze strony prywatności

Podsumowanie

Po znalezieniu właścicieli maszyny Jira, skontaktowałem się z nimi, aby poinformować ich o luce w ich bezpieczeństwie. Powiedzieli, że moje odkrycie naprawdę ich zaszokowało, a luka została natychmiast naprawiona.

Powiedzieli również, że wprowadzą pewne zmiany w swoich zasadach bezpieczeństwa w chmurze i ponownie ocenią zarządzanie dostępem.

Dobrą praktyką jest podziękowanie osobie odpowiedzialnej za odpowiedzialne ujawnienie za pomocą Bug Bounty - nagrody przyznawanej badaczowi bezpieczeństwa za zwrócenie uwagi na problemy związane z bezpieczeństwem. Motywuje to badacza do kontynuowania jego pracy polegającej na pomaganiu firmom w tworzeniu bardziej rygorystycznych procesów bezpieczeństwa.

Niestety, tym razem nie było żadnej nagrody za błędy!

Co więc można zrobić, aby nie narażać swoich danych w sposób opisany powyżej?

Stosować zasadę najmniejszych uprawnień - Ograniczyłoby to ryzyko nieautoryzowanego dostępu do krytycznych systemów lub wrażliwych danych za pośrednictwem kont użytkowników, urządzeń lub aplikacji niskiego poziomu. Regularne aktualizowanie oprogramowania - Oprócz nowych funkcji i większej kompatybilności, głównym składnikiem aktualizacji oprogramowania jest większe bezpieczeństwo.

W związku z tym zostawiam Państwu kolejną notatkę. Tym razem od wielkiego amerykańskiego pisarza Henry'ego Davida Thoreau prosto z jego opus magnum, Waldena.