Ostatnio, Datadog opublikował swój raport na temat technik ataków które widzieli ze złośliwych adresów IP, które miały wpływ na wiele środowisk AWS od końca 2023 do początku 2024 roku. Ujawnili oni wyniki dwóch różnych rodzajów ataków, z których każdy ujawnia inny poziom zaawansowania.

Na szczęście żadne środowiska produkcyjne nie zostały naruszone, ani nie uzyskano dostępu do żadnych danych klientów podczas tych ataków. Jesteśmy wdzięczni zespołowi Datadog za przejrzystość w raporcie, ponieważ z tych prób możemy wyciągnąć kilka ważnych wniosków na temat tego, jak zwykle zachowują się atakujący.

Opowieść o dwóch atakach

W obu typach ataków opisanych w raporcie Datadog, podobnie jak w większości wszystkich ataków, atakujący zdobyli początkową przyczółek przy użyciu nielegalnie zdobytych danych uwierzytelniających. W tym przypadku winny był wyciek kluczy użytkowników IAM. Zdecydowanie zalecamy przeczytanie artykułu Datadog, aby uzyskać dogłębne spojrzenie, ale oto ogólne podsumowanie tego, co się stało.

Wyrafinowany atak mający na celu uniknięcie wykrycia

W pierwszym ataku, po uzyskaniu początkowego dostępu, przeciwnik wzmocnił swoją pozycję, tworząc nowe konta administratora, które umożliwiłyby im stały dostęp w przypadku zakończenia początkowego dostępu. Następnie skupili się na eskalacji uprawnień poprzez manipulację kontami. Następnie przejrzeli każdą usługę lub zasobnik, do którego mogli uzyskać dostęp, aby sprawdzić, czy jest coś, co można wykorzystać lub ukraść, zwłaszcza więcej danych uwierzytelniających, które umożliwiały szerszy dostęp.

Ostatecznie próbowali utworzyć nowe instancje EC2 w innym regionie, kiedy to atak zakończył się niepowodzeniem. Gdyby Datadog nie monitorował podejrzanych działań poza ich normalnymi regionami, atak ten mógłby trwać aż do terminu płatności rachunku. Jest to dobre przypomnienie, że powierzchnia ataku jest szersza, niż można początkowo podejrzewać.

Zespół Datadog zmapował ten proces, podsumowując jeden z ataków następującą ilustracją.

W przypadku haseł użytkowników root dobrym pomysłem jest regularna rotacja haseł i regularne upewnianie się, że ścieżka resetowania hasła jest również bezpieczna. W przypadku innych haseł, AWS ma jasną ścieżkę do użycia Secrets Manager i kilka prostych skryptów do automatycznej rotacji sekretów tak często, jak Państwo chcą.

Proszę zawsze pamiętać o zasadzie najmniejszego przywileju

Istnieją dwie rzeczy, które są prawdziwe w odniesieniu do kont Root w AWS:

1. Są one potężne, a zatem potencjalnie niebezpieczne.
2. Nie powinny być używane do niczego poza najwyższym poziomem administracji.

Zamiast tego należy utworzyć użytkowników z ograniczonymi uprawnieniami, jak najściślej związanymi z konkretnym zadaniem, zgodnie z zasadą Zasada najmniejszych uprawnień.

Jeśli dostęp zostanie skradziony lub udostępniony jednemu z tych użytkowników, atakujący będą mieli bardzo ograniczone uprawnienia i najprawdopodobniej nie byliby w stanie zajść tak daleko, jak zrobili to atakujący w ustaleniach Datadog.

Żadne hasło nie jest lepsze niż hasło krótkotrwałe

Najbezpieczniejsze hasło to takie, które nie istnieje. W AWS i u większości innych dostawców usług w chmurze istnieje wyraźne i bezpieczne hasło. dobrze omówiona ścieżka do wyeliminowania większości haseł poprzez użycie ról IAM. Przypisanie użytkownikowi lub aplikacji roli zapewni im tymczasowy dostęp w razie potrzeby. Takie podejście pozwala również uzyskać bardzo szczegółowe uprawnienia w ramach zdefiniowanych ról, co oznacza, że dostęp jest przyznawany tylko w ściśle określonych okolicznościach.

Jak pokazał drugi typ ataku, gdy atakujący tworzy nowe konto użytkownika, nie przypisuje mu ról IAM. Daje im hasła. Powinno to dać Państwu trochę do myślenia, jeśli nadal używają Państwo długotrwałych haseł dla swoich zaufanych użytkowników.

Proszę usunąć nieaktualne i niepotrzebne dane uwierzytelniające

W pewnym momencie w historii Państwa aplikacji w chmurze prawdopodobnie ktoś użył długotrwałego hasła, aby umożliwić dostęp niezbędny do działania aplikacji. W najlepszym scenariuszu, całkowicie usunięto te poświadczenia, unieważniono je i dostosowano kod, aby korzystał z reguł IAM lub menedżera sekretów.

Istnieje również scenariusz, w którym te stare hasła są nadal w commitach Git z wczesnych dni projektu i są nadal ważne. Proszę skorzystać z narzędzi do tajnego skanowania, które mogą przejrzeć całą historię Git i każdą gałąź, aby poinformować Państwa o tym i w razie potrzeby zaradzić sytuacji. Istnieje wiele narzędzi i platform.

Otrzymywanie powiadomień o wyciekach lub naruszeniach po raz pierwszy

W obu tych przypadkach zbadanych przez Datadog, początkowy dostęp pochodził z wycieku danych uwierzytelniających. Istnieje wiele sposobów, w jakie atakujący może zdobyć te tajemnice, ale na podstawie tego, co widzieliśmy, mogli znaleźć je publicznie na GitHub. Najlepiej byłoby, gdyby dowiedzieli się Państwo o tym, gdy tylko pojawią się one publicznie, aby mogli Państwo podjąć działania w celu ochrony swojej organizacji.

Zalecamy połączenie honeytogenów i agresywnego monitorowania publicznego. Są to dwa różne podejścia, ale nakładają się na siebie i dobrze się uzupełniają. Jeśli honeytoken zostanie wdrożony w prywatnym repozytorium, a następnie kod ten wycieknie do wiadomości publicznej, honeytoken uruchomi się niemal natychmiast, informując o problemie.

Uczenie się na podstawie badań

Jesteśmy bardzo wdzięczni za badania przeprowadzone przez naszych partnerów z zespołu Datadog i innych specjalistów ds. bezpieczeństwa, którzy ujawniają tak dogłębne odkrycia. Z tych odkryć możemy się wiele nauczyć, nawet jeśli nie doprowadziły one do udanych naruszeń przyciągających nagłówki gazet lub wycieków danych klientów. Miejmy nadzieję, że Państwa organizacja może zastosować te lekcje i nigdy nie padnie ofiarą tych atakujących.

Bezpieczeństwo to podróż, a nie stały stan, który można trwale osiągnąć.