Hacking for all!

http://chacker.pl

Platforma chmurowa Microsoftu jest znana jako Microsoft Azure. Jest uważana za platformę infrastruktury jako usługi (IaaS), ale Microsoft Azure nie zaczynał w ten sposób; zaczął jako technologia platformy jako usługi (PaaS). W związku z tym znaczna część oryginalnego systemu była ukierunkowana na doświadczenie wielodostępne z jego bazą użytkowników. Platforma chmurowa Microsoftu działa inaczej niż platforma Amazon w subtelny sposób, który my, jako atakujący, możemy nadużyć. Oto kilka przykładów różnic w Azure:

• Mechanizm, w którym musisz zorganizować zasoby, wpłynie na sposób działania kontroli dostępu.
• Standardowe maszyny wirtualne Azure mają o wiele więcej możliwości wykorzystania, z bardziej złożonym sposobem ograniczania dostępu.
• Tożsamości używają OpenID Connect, ponieważ Microsoft ściśle zintegrował Azure AD z Azure, co jest dużą różnicą w porównaniu ze statycznymi kluczami API AWS.

Trudno jest również omawiać Microsoft Azure bez omawiania Azure Active Directory firmy Microsoft. Przeczytasz fragmenty odnoszące się do platformy Azure, a zamiast tego skupiające się na usłudze Azure AD ze względu na ścisłą integrację obu systemów.

https://chacker.pl/

Jednym z bardzo tradycyjnych mechanizmów trwałości w standardowym systemie operacyjnym jest zaplanowane zadanie. W systemie Windows masz harmonogram zadań, a w systemie Linux masz demona cron. Każdy z tych systemów ma zdarzenie wyzwalające; zazwyczaj jest ono oparte na czasie i działaniu. Co by było, gdybyśmy mogli dowiedzieć się, jak wyzwolić zadanie w ekosystemie AWS, które zapewniłoby nam trwałość? Ryan Gerstenkorn z Rhino Security Labs napisał narzędzie oparte na Go, które może pomóc symulować dokładnie taką sytuację. Narzędzie nazywa się UserDataSwap. Może być bardzo przydatne, jeśli masz odpowiednie uprawnienia i wiesz, jak modyfikować źródło. Narzędzie napisane w Go ma statyczne polecenie rozruchu, które doda statycznie skompilowaną wersję Netcata i otworzy nasłuchiwacza tylnych drzwi. Port nasłuchiwacza pozostaje otwarty w systemie hosta. Pomyśl o tym jako o połączeniu bootloadera tylnych drzwi i modułu trwałości w systemie operacyjnym.

Jak zauważysz, najpierw uruchamiamy polecenie wyjściowe terraform (1), aby znaleźć lokalizację kontenera S3 dla naszego narzędzia. Robimy to w samym katalogu terraform. Następnie musimy zmodyfikować plik samconfig.toml (2) w katalogu UserDataSwap znajdującym się w instancji Kali w AWS. Plik wymaga modyfikacji jednego wpisu, którym jest wpis s3_sam_bucket (3):

Gdy plik samconfig.toml zostanie ukończony, możemy wykonać polecenia kompilacji i wdrożenia:

Pierwsze polecenie, make build (4), skompiluje aplikację lokalnie. Następnie uruchomienie polecenia make deploy (5) spowoduje utworzenie funkcji Lambda, która przyjmie most zdarzeń jako wyzwalacz. Będzie ona szukać instancji EC2, które się uruchamiają, a te instancje EC2, które się uruchamiają, wyzwolą most zdarzeń, aby wyzwolić funkcję Lambda. Po wyzwoleniu funkcji Lambda przyjmie ona identyfikator instancji jako cel i zapisze dane użytkownika. Funkcja Lambda poinstruuje serwer EC2, aby się wyłączył, zamienił dane użytkownika i uruchomił instancję. Po zakończeniu tego procesu wykona tę samą operację, aby zamienić z powrotem oryginalne dane użytkownika. Administratorowi będzie się wydawać, że EC2 po prostu działa znacznie wolniej niż zwykle. Ważne jest również, aby zauważyć, że skalowanie automatyczne nie zostało przetestowane i może spowodować, że sytuacja wymknie się spod kontroli. Nie włączaj skalowania automatycznego w tej konfiguracji. Implant, którego używamy, to port nasłuchujący Netcat na każdej instancji EC2 na porcie 1234. Teraz musimy zbudować serwer EC2 do testów! Na szczęście możemy przejść do innego katalogu Terraform, aby zbudować urządzenie ofiary (4):

W tym momencie musimy odczekać około 5 lub 6 minut, aby UserDataSwap wykonał wszystkie operacje, których potrzebuje. Możesz sprawdzić w grupie logów CloudWatch (https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#logsV2:log-groups), która byłaby najnowszą grupą ze słowami „UserDataSwap-UserDataSwapFunction”, aby zobaczyć status wykonania funkcji. Teraz spróbujemy połączyć się z systemem, który otworzyliśmy. Powłoka będąca surową powłoką gniazda może być połączona za pomocą netcat.

Teraz możemy połączyć się z naszą maszyną z tej samej sieci VPC, aby zobaczyć, że port jest rzeczywiście otwarty. Tutaj uruchamiamy polecenie nc (7) na maszynie docelowej; pamiętaj, że nie będzie żadnego monitu z netcat. Możemy uruchomić ls (8) i whoami (9), aby przetestować działanie.

Podsumowanie

Amazon Web Services to bardzo potężny i użyteczny zestaw narzędzi, który daje nam możliwość dostarczania usług, oprogramowania, aplikacji i innych rzeczy na taką samą skalę jak sam Amazon. Powinniśmy jednak patrzeć na Amazon Web Services nie jako na środowisko usług w chmurze, ale jako na system operacyjny. Dzieli wiele właściwości tradycyjnego systemu operacyjnego, eksponowanych w unikalny sposób. Ma model uprawnień podobny do naszych systemów operacyjnych, ma zestaw systemów plików i może uruchamiać, planować i pracować z aplikacjami i procesami. Mając to na uwadze, możemy również atakować i nadużywać Amazon Web Services w bardzo znajomy sposób. Mamy nadzieję, że ten rozdział rozpocznie Cię ścieżką bliższego przyjrzenia się Amazon Web Services.

https://chacker.pl/

Jak wspomniano wcześniej, RedBoto składa się z serii skryptów, a jeden ze skryptów służy do eksploatowania usług AWS. Niektóre skrypty RedBoto są zaprojektowane jako jednorazowe, z niewielką lub żadną jednolitością lub obsługą błędów. Mimo to dla wielu osób korzystających z nich praktyczność jest kluczowa. Uruchommy nasz pierwszy skrypt:

Skrypt describeInstances.py (1) to prosty skrypt wyliczeniowy EC2, który działa na liście regionów (2). Chociaż nie jest to pełna lista regionów, skrypt został zaprojektowany z myślą o prostocie, a nie złożoności. Możemy zobaczyć identyfikatory instancji (3), nazwę komputera i jego stan. Uruchommy następny skrypt:

UWAGA UserData to specjalne pole, które można osadzić w każdej instancji EC2, aby umożliwić dostosowywanie maszyny w czasie rozruchu. Typowy mechanizm używany do odczytu i wykonywania danych użytkownika to framework o nazwie cloudinit. Mechanizm ten jest zaprojektowany do uruchamiania opcjonalnych danych użytkownika podczas rozruchu w celu wykonywania operacji bootstrapowych w systemach operacyjnych. Możemy nadużywać tej funkcji, wstawiając lub odczytując dane użytkownika.

Następny skrypt describeUserData.py (4) przejdzie w ciemno przez każdą instancję i wyliczy wszystkie dane użytkownika (5) przechowywane w konfiguracji instancji. Jak widać, można tu przechowywać dowolną liczbę elementów, w tym nazwy użytkowników i hasła (6). To nie jest dobry wzorzec przechowywania informacji, ale nadal widzimy go w użyciu. Ważne jest, aby szukać haseł w danych użytkownika i innych kluczowych elementach danych.

Systemy operacyjne Windows w EC2 sprawiają, że dane użytkownika są o wiele bardziej interesujące. Częścią procesu tworzenia niektórych systemów operacyjnych Windows jest posiadanie nazwy użytkownika Administrator. Czasami pseudolosowo utworzone hasło jest szyfrowane przy użyciu klucza SSH używanego na koncie. Gdybyśmy mieli dostęp do tego klucza SSH, czy moglibyśmy odszyfrować tę wartość? RedBoto ma skrypt, który robi właśnie to:

WSKAZÓWKA: Upewnij się, że skopiowałeś swój ~/.ssh/id_rsa z dowolnego urządzenia, którego użyłeś do zbudowania swoich początkowych maszyn, na maszynę, którą atakujesz. Ważne jest również, aby zauważyć, że ta wersja getEC2WinCreds.py została zmodyfikowana, aby działała z naszymi laboratoriami. Oryginalny skrypt opiera się na fakcie, że mamy plik PEM dla naszego klucza SSH, ale używamy kluczy w formacie OpenSSH. Ta wersja nie próbuje deserializować plików PEM.

Używając pliku getEC2WinCreds.py (7), system automatycznie sprawdzi określony region i wyliczy wszystkie wystąpienia EC2 (8), szukając konkretnie platformy Windows jako klucza. Następnie skrypt przejdzie do każdego z zlokalizowanych identyfikatorów wystąpień i, używając klucza SSH jako klucza deszyfrującego, spróbuje odszyfrować każde z pól hasła (9). Zapewnia również wgląd w publiczny adres IP. Jeśli zostanie znaleziony, nastąpi zmiana, która ujawni port RDP w Internecie i umożliwi zdalny dostęp do urządzenia.

https://chacker.pl/

Jednym z największych wyzwań, z jakimi przyjdzie Ci się zmierzyć w przypadku wielu narzędzi AWS, jest kompletność pokrycia. Większość narzędzi ma ograniczenia dotyczące tego, co mogą zrobić bez wprowadzania przez nas zmian, a nadążanie za wysokim tempem zmian może być problemem. Zobaczmy, gdzie nasze narzędzia mają pewne ograniczenia i zalety:

Czy chciałbyś wykonać kilkaset wywołań API, aby spróbować zweryfikować, które uprawnienia do opisu (lub odczytu) masz w EC2 i Lambda? Prawdopodobnie nie. Jak możemy to zrobić w bardziej zautomatyzowany sposób? Po prostu używamy PACU i znajdujemy wszystkie uprawnienia — czy możemy?

Aby uruchomić narzędzie PACU z katalogu /opt/pacu (1) na komputerze Kali Linux, należy uruchomić plik Pythona cli.py (2). PACU organizuje kampanie według nazwy sesji; my nazwaliśmy naszą bieżącą sesję „ghh” (3). PACU może używać kluczy, które znajdują się już w ogólnym systemie operacyjnym. Aby to zrobić, użyjemy polecenia import_keys –all (4), aby zaimportować wszystkie profile i klucze zapisane w pliku poświadczeń. Po załadowaniu tych elementów możemy zacząć używać modułów. Jednym z modułów, których możemy użyć, jest moduł do wywoływania usługi IAM i brutalnego wymuszania uprawnień. Robimy to za pomocą polecenia run iam__bruteforce_permissions (5). Można by założyć, że jest to w 100% kompletny sposób na znalezienie wszystkich uprawnień w systemie, tak jak jest opisany. Tak nie jest. Jak zobaczysz później, to polecenie spróbuje wywołać API AWS, ale tylko dla określonych usług, takich jak EC2 i Lambda, i tylko dla bardzo wąskich wywołań API — głównie tych, które są przydatne w opisywaniu usług (polecenia oparte na odczycie). Możemy zobaczyć, co znaleźliśmy dla naszego klucza API, wywołując whoami (4). Polecenie wyświetli niektóre dozwolone i zabronione uprawnienia, ale nie jest ono w 100 procentach kompletne. Innym sposobem na osiągnięcie tego samego typu wyniku jest próba użycia każdego wywołania API. Następnie wyliczymy ec2_hosts (7) jako przykład walidacji naszych znanych uprawnień. Zobaczysz, że możemy wyliczyć większość danych EC2. PACU próbuje zbudować w pełni funkcjonalny moduł z dołączonymi bateriami do eksploatacji AWS, ale ma swoje wady. Nie zawsze zawiera każdy moduł, którego możesz potrzebować. Nie obsługuje również każdej usługi w AWS. Często musisz polegać na innych narzędziach, skryptach lub po prostu zwykłym interfejsie wiersza poleceń AWS, aby wykonać wiele ataków, które chcesz wykonać. Pokazujemy kilka przykładów w następnej sekcji. Chcemy jednak, abyś nadal korzystał z PACU, ponieważ ma on kilka przydatnych funkcji, takich jak:

• Zezwalanie użytkownikowi na backdoorowanie usługi EC2 za pomocą skryptu rozruchowego
• Umieszczanie adresu IP na białej liście w GuardDuty, czyli usłudze wykrywania zagrożeń z AWS
• Wykorzystywanie narzędzia Amazon SSM do wykonywania poleceń
• Backdoorowanie kont użytkowników poprzez dodanie zestawu kluczy API lub, w niektórych przypadkach, dodanie drugiego zestawu kluczy API
• Pobieranie różnych typów zestawów danych, takich jak migawki bazy danych RDS i pliki S3

UWAGA: Wiele działań w tej sekcji zostanie zalogowanych w komponentach CloudTrail konsoli AWS; jest to robione domyślnie. Chociaż rejestrowanie jest dobre, samo w sobie nie wystarczy, aby zrozumieć, co się dzieje. Potrzebujesz dodatkowych narzędzi, aby pobrać dzienniki i lepiej je zrozumieć, tak jak w standardowym systemie operacyjnym. Sekcja jest bardzo głośna i może pozostawić duży ślad.

https://chacker.pl/

RedBoto to kolejna kolekcja narzędzi, głównie jednorazowych skryptów, które obejmują bibliotekę Boto jak inne narzędzia, ale nie jest to framework. Zawiera jednak kilka godnych uwagi skryptów, które są warte wzmianki, ponieważ mogą pomóc w ofensywie w operacjach:

• Skrypt do wyliczania miejsc, w których włączono CloudTrail. Jest to przydatne do unikania narzędzi takich jak GuardDuty i innych systemów monitorowania i bezpieczeństwa. • Skrypt do sprawdzania, jaki typ danych użytkownika jest dostępny w systemie. Może być pomocny, ponieważ polecenie jest dość trudne dla początkujących użytkowników.

• Skrypt do uruchamiania poleceń za pośrednictwem systemu Amazon SSM, który jest menedżerem powszechnie używanych systemów.

https://chacker.pl/

Framework PACU firmy Rhino Security Labs jest jednym z najlepszych zamienników starszych narzędzi, takich jak WeirdAAL. WeirdAAL był jednym z pierwszych zestawów narzędzi, które można było wykorzystać do ataku na Amazon Web Services. Skrót ten oznaczał Weird Amazon Attack Library. PACU ma zbiór modułów, które otaczają bibliotekę, tworząc zestaw wywołań API, które mogą być używane w celach ofensywnych. Framework zawiera kilka klas modułów, które mogą pomóc atakującemu odkryć i nadużyć ekosystemu AWS. Oto kilka godnych uwagi:

• Moduły do ​​wyliczania uprawnień IAM
• Moduły do ​​wykonywania eskalacji uprawnień za pomocą EC2 i Lambda
• Moduły do ​​unikania wykrycia poprzez wyłączanie zabezpieczeń przed systemami takimi jak GuardDuty

• Możliwość wszczepienia tylnego wejścia PACU nie jest jednak w 100 procentach kompletna i nie ma wszystkiego, czego możesz chcieć. Pozwala jednak użytkownikowi wywołać AWS CLI z poziomu narzędzia, aby spróbować zapewnić dodatkową elastyczność. Jednym zastrzeżeniem jest to, że CLI nie będzie rejestrować danych wyjściowych i przechowywać ich w taki sam sposób, jak robią to moduły

https://chacker.pl/

Istniejące narzędzia atakujące AWS są napisane głównie w Pythonie i zbudowane na bibliotece Python Boto. Sama biblioteka pochodzi z AWS i stanowi serce AWS CLI. Możesz to szybko zidentyfikować, ponieważ większość bibliotek jest napisana z zaimportowaną biblioteką Boto. Większość z tych narzędzi wykonuje następujące działania dla określonych wywołań API:

• Podaj narzędziu klucz API lub, alternatywnie, dla określonych anonimowych modułów, użyj listy słów.
• Spróbuj wyliczyć uprawnienia dla określonej usługi, jeśli masz uprawnienia IAM do wyliczenia API.
• Spróbuj wywołać API bezpośrednio, najpierw używając wywołania DryRun do API, a następnie wykonaj działanie. Jeśli ci się uda, uzyskasz dostęp.

https://chacker.pl/

Narzędzia atakujące AWS mogą pomóc zautomatyzować wiele działań, które chcemy wykonać, a nie każde narzędzie jest wbudowane w ramy, do których jesteśmy przyzwyczajeni. Możemy jednak używać skryptów i narzędzi do wykonywania złożonych zapytań i ataków. Przyjrzyjmy się kilku z tych narzędzi, aby zrozumieć, jak najlepiej je wykorzystać i jak działają. Może to pomóc w zaprojektowaniu własnych narzędzi atakujących i wypełnieniu luki, którą znajdziesz w narzędziach ukierunkowanych na ataki dla AWS

https://chacker.pl/

Po utworzeniu środowiska otrzymujemy adres IP hosta AWS; dzieje się to jako wynik uruchomionego skryptu. Możesz użyć Kali Linux, którego posiadasz, lub Kali hostowanego w chmurze. Niektóre przykłady w tym laboratorium są zaprojektowane do pracy z wewnętrzną przestrzenią IP, która będzie dostępna tylko za pośrednictwem hostowanej wersji Kali. W tym laboratorium będziemy używać adresu IP, który może być inny niż ten, który będziesz mieć w swoich laboratoriach. Pokażemy Ci, jak klucze AWS można łatwo zobaczyć za pośrednictwem usługi Identity Metadata.

WSKAZÓWKA: Znajdowanie identyfikatorów kont AWS i kluczy AWS może być w pewnym sensie sztuką. Identyfikatory kont nie powinny być publiczne, a klucze AWS powinny być tajne. Mamy jednak dowody i wiedzę na temat przechowywania obu elementów w niezabezpieczonych obszarach, takich jak systemy zarządzania kodem źródłowym, takie jak GitHub, kod źródłowy w JavaScript wysyłany do przeglądarki i zakodowany na stałe w aplikacjach mobilnych. Znaleźliśmy je nawet przeszukujące sieć i odkryliśmy wyniki wyszukiwania w miejscach, w których pracują programiści, takich jak Trello. Biorąc pod uwagę, jak powszechny jest ten problem, istnieje armia botów, zarówno dobrych, jak i złych, które stale monitorują Internet w poszukiwaniu tych kluczy. Używając cURL, przeszukamy teraz usługę Identity Metadata Service w AWS.

W tym scenariuszu wyświetlany adres 3.234.217.218 jest adresem serwera dostępnego w Internecie. Maszyna jest ofiarą, którą atakujemy. Aplikacja, o której mowa, ma lukę w zabezpieczeniach SSRF (server-side request forgery) (1). SSRF umożliwiają wykonanie aplikacji w celu pobrania ruchu internetowego z dowolnej innej lokalizacji, do której serwer może się dostać, w tym aplikacji wewnętrznych.

UWAGA: SSRF-y takie jak ten można łatwo znaleźć jako 169.254.169.254, co jest dobrze znanym ciągiem. Możesz spróbować wykonać dodatkową pracę, aby ukryć wyniki systemu, na przykład konwertując 169.254.169.254 na inny format, taki jak ósemkowy, dziesiętny, a nawet notację IPv6 na IPv4. Użyjemy kilku z nich w całym laboratorium.

Jako atakujący kontrolujemy wykonywanie adresu URL, jak widać w kodzie, kierując go do wewnętrznego interfejsu API odpowiedzialnego za zarządzanie urządzeniem. Adres 169.254.169.254 jest podobny do 127.0.0.1 (pętla zwrotna) w naturze. Przestrzeń 169.254 jest nieroutowalnym, ale lokalnie znaczącym adresem. Adres 169.254.169.254, który widzisz tutaj, jest adresem metadanych instancji AWS. Jest to bardzo dobrze zdefiniowana i znana usługa, którą obsługuje AWS i prawie wszyscy dostawcy usług w chmurze. Metadane instancji mogą dostarczyć nam informacji o systemie, w którym się znajdujemy. Wynik tego zapytania pokazuje nam dwa konkretne katalogi, które chcielibyśmy zbadać. Pokazuje dwa katalogi o nazwie meta-data (2) i user-data (3). Zbadamy każdy z nich. Najpierw powinniśmy sprawdzić, z jakim typem hosta lub usługi próbujemy pracować. Czy to jest moduł równoważenia obciążenia? Czy to instancja Lambda? Jednym ze sposobów, w jaki możemy to sprawdzić, jest odwrotne wyszukiwanie DNS. To urządzenie może być instancją EC2; możemy to stwierdzić, używając odwrotnego wyszukiwania DNS, aby sprawdzić ten wynik, jak pokazano tutaj:

Rekord PTR ma tutaj określony format: ec2-3-234-217-218. To oznacza, że ​​usługa to EC2 i ma adres IP 3.234.217.128. Ponadto compute-1 jest identyfikatorem centrum danych us-east-1. Teraz wiemy, że jesteśmy w EC2. Przyjrzyjmy się pierwszej części tej usługi metadanych instancji:

Adres URL, którego używamy, odnosi się bezpośrednio do części usługi metadanych związanej z informacjami IAM. Ta instancja EC2 ma przypisaną rolę IAM (4). Sama usługa zwróci tylko dane systemu, który ją wywołuje. Każdy serwer będzie miał inny zestaw zwracanych wartości, ponieważ wartości są lokalnie istotne. Musimy przeszukać ten adres URL usługi, zanim będziemy mogli przeszukać następną część tej usługi, aby dodać naszą rolę:

Teraz mamy klucz API, który nam przekazano; klucz składa się z trzech części:

• AccessKeyId (5). Klucz dostępu, który jest tutaj wyświetlany, ma prefiks zaczynający się od ASIA; jest to tymczasowy klucz AWS z 6-godzinnym terminem ważności.
• SecretAccessKey (4). Jest to tajny klucz dostępu, którego zazwyczaj potrzebujemy z dowolnymi kluczami API od Amazon.
• Token (7). Jest to wartość tokena sesji — dodatkowy element uwierzytelniający do naszego użytku.

UWAGA: W tym przykładzie używamy usługi Identity Metadata Service (IMDS) v1; w domyślnym szablonie uruchamiania EC2 wdrożono zarówno IMDSv1, jak i IMDSv2. IMDSv2 chroni klientów przed tym wektorem ataku, wymagając dodatkowego wywołania HTTP w celu uzyskania tokena. Dodatkowe wywołanie HTTP to żądanie metody PUT, po którym następuje to samo GET. Użycie metody PUT do początkowego żądania tokena przerwałoby wektor ataku SSRF, ponieważ żądanie musiałoby używać żądań GET.

Są dwie krytyczne rzeczy, o których należy pamiętać, które naprawdę warto rozważyć, zmieniając w praktyce. Po pierwsze, wysłanie tego typu żądania lub otrzymanie tego wyniku może wywołać zaporę aplikacji internetowych (WAF). Po drugie, i być może ważniejsze, użycie tego klucza poza AWS wywoła usługę taką jak AWS GuardDuty. Jedną z jej standardowych reguł jest to, że GuardDuty szuka kluczy EC2 IAM używanych poza chmurą AWS.7 Chcielibyśmy użyć tych kluczy w chmurze AWS i na szczęście możemy uruchomić nasze własne maszyny, aby to zrobić. Musimy edytować dwa pliki na naszym komputerze: .aws/credentials i .aws/config. Te pliki znajdują się w katalogu głównym Twojego folderu domowego; dla użytkowników Kali będzie to /home/kali/.aws/credentials i /home/kali/.aws/config. Edytuj plik poświadczeń AWS, który znajduje się w katalogu /home/kali/.aws, aby mógł on lepiej odzwierciedlać wartości znajdujące się w poniższym bloku kodu. Plik poświadczeń musi zawierać ten blok kodu; upewnij się, że zwracasz uwagę na nazwy wartości i to, co kopiujesz i wklejasz. W szczególności musisz dodać sekcję aws_session_token, której nie zobaczysz w żadnym istniejącym pliku. Instrukcje dotyczące tego, co należy skopiować, podano poniżej.

Aws_access_key_id będzie wartością z naszego zamknięcia na górze o nazwie AccessKeyId. Aws_secret_access_key zostanie skopiowany z SecretAccessKey. Aws_session_token będzie pochodził z wartości Token. Plik /home/kali/.aws/config również będzie musiał zostać zmodyfikowany, aby uwzględnić sekcję [profile default]. Ważne jest, aby pamiętać, że region powinien być ustawiony. Wszelkie dodatkowe elementy, takie jak output, nie są krytyczne. Pominięcie output spowoduje, że output zostanie wydrukowany w formacie JSON.

Po poprawnym skonfigurowaniu pliku konfiguracyjnego AWS możemy przejść do zapytania do interfejsu API AWS w celu znalezienia informacji o koncie dla naszego klucza interfejsu API AWS:

Jeśli bloki kodu zostały umieszczone poprawnie, powinniśmy teraz otrzymać zapytanie zwrotne, które pokazuje, że działamy w przyjętej roli i przyjmujemy rolę naszej instancji EC2. Jest to równoważne z możliwością komunikowania się z domeną Active Directory, tak jakbyśmy próbowali użyć poświadczeń konta maszyny. Ale co możemy zrobić z tymi kluczami? Będziemy musieli to zbadać dalej.

https://chacker.pl/

Klucze API w AWS zapewniają użytkownikowi, deweloperowi lub usłudze programowy dostęp do systemu. Ten programowy dostęp może umożliwić pełną kontrolę systemu za pośrednictwem CLI. Klucze programowe mają określony format i zazwyczaj znajdziesz w użyciu dwa typy kluczy, które możemy wykorzystać, jak szczegółowo opisano w poniższej tabeli.

Chociaż istnieje więcej typów kluczy, do których możesz uzyskać dostęp, omówimy tylko dwa, w których identyfikator klucza zaczyna się od AKIA lub ASIA. Będziesz potrzebować sekretu tych kluczy, a w niektórych sytuacjach będziesz potrzebować tokena sesji. Klucze dostępu (AKIA) są szczególnie niebezpieczne; w przeciwieństwie do tymczasowego klucza AWS STS, nie wygasają, chyba że ktoś je odwoła i ręcznie obróci. Pamiętajmy o tym, gdy zaczniemy przeglądać nasze środowisko.