19 lipca 2019 roku do Capital One dotarła wiadomość, której obawia się każda nowoczesna firma – doszło do naruszenia bezpieczeństwa danych. Dotknęło to ponad 106 milionów ludzi. 140 000 numerów ubezpieczenia społecznego w USA, milion numerów ubezpieczenia społecznego w Kanadzie. 80 000 kont bankowych. Nieprzyjemne, prawda?
Niestety, włamanie nie nastąpiło 19 lipca. Jak się okazuje, Paige Thompson a.k.a. Niekonsekwentny, dopuścił się tego w dniach 22–23 marca 2019 r. To jest prawie cztery miesiące temu. Tak naprawdę tylko dzięki pomocy zewnętrznych konsultantów Capital One był w stanie odkryć, że coś się wydarzyło.
Były pracownik Amazona został aresztowany, grozi mu grzywna w wysokości 250 XNUMX dolarów i pięć lat więzienia… ale nadal pozostaje wiele negatywnych opinii. Dlaczego? Ponieważ wiele firm, które ucierpiały z powodu ataków hakerskich, próbuje zrzucić z siebie odpowiedzialność za wzmocnienie swojej infrastruktury i aplikacji w obliczu wzrostu cyberprzestępczości.
W każdym razie możesz łatwo wyszukać tę historię w Google. Nie będziemy wchodzić w dramaty, ale porozmawiamy o tym techniczny stronę sprawy.
Po pierwsze, co się stało?
W Capital One działało około 700 wiader S3, które Paige Thompson skopiowała i wyssała.
Po drugie, czy jest to kolejny przypadek źle skonfigurowanej polityki segmentu S3?
Nie tym razem. Tutaj uzyskała dostęp do serwera z niepoprawnie skonfigurowaną zaporą ogniową i stamtąd przeprowadziła całą operację.
Czekaj, jak to możliwe?
No cóż, zacznijmy od zalogowania się na serwer, choć nie mamy zbyt wielu szczegółów. Powiedziano nam jedynie, że stało się to przez „źle skonfigurowaną zaporę ogniową”. A więc coś tak prostego, jak nieprawidłowe ustawienia grupy zabezpieczeń lub konfiguracja zapory aplikacji internetowej (Imperva) lub zapory sieciowej (iptables, ufw, shorewall itp.). Capital One jedynie przyznał się do winy i stwierdził, że zamknął dziurę.
Stone powiedział, że Capital One początkowo nie zauważyło luki w zaporze ogniowej, ale szybko zareagowało, gdy się o niej dowiedziało. Stone powiedział, że z pewnością pomógł w tym fakt, że haker rzekomo pozostawił kluczowe informacje identyfikujące w domenie publicznej.
Jeśli zastanawiasz się, dlaczego nie zagłębiamy się w tę część, zrozum, że ze względu na ograniczoną ilość informacji możemy jedynie spekulować. Nie ma to sensu, biorąc pod uwagę, że włamanie zależało od dziury pozostawionej przez Capital One. I jeśli nie powiedzą nam więcej, wymienimy po prostu wszystkie możliwe sposoby, w jakie Capital One pozostawiło otwarty serwer, w połączeniu ze wszystkimi możliwymi sposobami, w jakie ktoś może skorzystać z jednej z tych różnych opcji. Te wady i techniki mogą obejmować zarówno szalenie głupie przeoczenia, jak i niezwykle złożone wzorce. Biorąc pod uwagę zakres możliwości, będzie to długa saga bez prawdziwego zakończenia. Dlatego skupmy się na analizie tej części, w której mamy fakty.
Zatem pierwsza zasada jest następująca: dowiedz się, na co pozwalają Twoje zapory ogniowe.
Ustanów politykę lub odpowiedni proces zapewniający, że otwierane jest TYLKO to, co należy otworzyć. Jeśli korzystasz z zasobów AWS, takich jak grupy zabezpieczeń lub sieciowe listy ACL, oczywiście lista kontrolna do audytu może być długa… ale podobnie jak wiele zasobów jest tworzonych automatycznie (tj. CloudFormation), możliwe jest również zautomatyzowanie ich audytu. Niezależnie od tego, czy jest to domowy skrypt skanujący nowe obiekty w poszukiwaniu błędów, czy coś w rodzaju audytu bezpieczeństwa w procesie CI/CD... istnieje wiele łatwych opcji uniknięcia tego.
„Zabawna” część tej historii jest taka, że gdyby Capital One w ogóle zatkał dziurę… nic by się nie stało. I szczerze mówiąc, zawsze szokujące jest zobaczyć, jak coś naprawdę się dzieje dość proste staje się jedyną przyczyną włamania do firmy. Zwłaszcza tak duży jak Capital One.
A więc haker w środku – co stało się dalej?
Cóż, po włamaniu się do instancji EC2... wiele może pójść nie tak. Praktycznie chodzisz po ostrzu noża, jeśli pozwolisz komuś posunąć się tak daleko. Ale jak dostał się do wiader S3? Aby to zrozumieć, omówmy role IAM.
Zatem jednym ze sposobów uzyskania dostępu do usług AWS jest bycie użytkownikiem. OK, to jest dość oczywiste. Ale co, jeśli chcesz zapewnić innym usługom AWS, takim jak serwery aplikacji, dostęp do swoich segmentów S3? Po to właśnie są role IAM. Składają się z dwóch elementów:
- Polityka zaufania – jakie usługi lub osoby mogą korzystać z tej roli?
- Polityka uprawnień – na co pozwala ta rola?
Na przykład chcesz utworzyć rolę IAM, która umożliwi instancjom EC2 dostęp do segmentu S3: Po pierwsze, rola ma skonfigurowaną politykę zaufania, zgodnie z którą EC2 (cała usługa) lub określone instancje mogą „przejąć” tę rolę. Zaakceptowanie roli oznacza, że może używać uprawnień roli do wykonywania działań. Po drugie, Polityka uprawnień pozwala usłudze/osobie/zasobowi, który „przyjął tę rolę”, na wykonanie dowolnego działania na S3, niezależnie od tego, czy chodzi o dostęp do jednego konkretnego segmentu… czy ponad 700, jak w przypadku Capital One.
Gdy znajdziesz się w instancji EC2 z rolą IAM, możesz uzyskać poświadczenia na kilka sposobów:
- Możesz poprosić o metadane instancji pod adresem
http://169.254.169.254/latest/meta-dataPod tym adresem możesz między innymi znaleźć rolę IAM z dowolnym kluczem dostępu. Oczywiście tylko jeśli jesteś w instancji.
- Użyj interfejsu AWS...
Jeśli zainstalowany jest interfejs CLI AWS, ładowane są poświadczenia z ról IAM, jeśli są obecne. Pozostaje tylko pracować PRZEZ instancję. Oczywiście, gdyby ich Polityka Zaufania była otwarta, Paige mogłaby zrobić wszystko bezpośrednio.
Zatem istotą ról IAM jest to, że pozwalają niektórym zasobom działać W TWOIM IMIENIU w INNYCH ZASOBACH.
Teraz, gdy już rozumiesz rolę IAM, możemy porozmawiać o tym, co zrobiła Paige Thompson:
- Dostęp do serwera (instancja EC2) uzyskała poprzez dziurę w firewallu
Niezależnie od tego, czy chodzi o grupy zabezpieczeń/listy ACL, czy o własne zapory sieciowe aplikacji internetowych, lukę prawdopodobnie łatwo było załatać, jak stwierdzono w oficjalnych dokumentach.
- Będąc na serwerze, mogła zachowywać się „tak, jakby” sama była serwerem
- Ponieważ rola serwera IAM umożliwiła S3 dostęp do ponad 700 zasobników, mógł uzyskać do nich dostęp
Od tego momentu wystarczyło jej jedynie wydać komendę List Bucketsa potem polecenie Sync z interfejsu wiersza polecenia AWS...
. Zapobieganie takim szkodom jest powodem, dla którego firmy tak dużo inwestują w ochronę infrastruktury chmurowej, DevOps i ekspertów ds. bezpieczeństwa. A jak wartościowa i opłacalna jest migracja do chmury? Do tego stopnia, że nawet w obliczu coraz większych wyzwań związanych z cyberbezpieczeństwem !
Morał z tej historii: sprawdź swoje bezpieczeństwo; Przeprowadzaj regularne audyty; Przestrzegaj zasady najniższych uprawnień w zakresie zasad bezpieczeństwa.
( Możesz zobaczyć pełny raport prawny).
Źródło: www.habr.com