Z nowego badania wynika, że osoba atakująca mogła wykorzystać lukę związaną z usługą routingu ruchu Amazon Web Service znaną jako Application Load Balancer w celu ominięcia kontroli dostępu i złamania zabezpieczeń aplikacji internetowych. Usterka wynika z problemu z implementacją u klienta, co oznacza, że nie jest spowodowana błędem oprogramowania. Zamiast tego narażenie zostało wprowadzone przez sposób, w jaki użytkownicy AWS konfigurowali uwierzytelnianie za pomocą Application Load Balancer.
Kwestie wdrożeniowe są kluczowym elementem bezpieczeństwa w chmurze w taki sam sposób, w jaki zawartość pancernego sejfu nie jest chroniona, jeśli drzwi pozostaną uchylone. Naukowcy z firmy ochroniarskiej Miggo znaleziony że w zależności od konfiguracji uwierzytelniania modułu równoważenia obciążenia aplikacji osoba atakująca może potencjalnie zmanipulować jego przekazanie do zewnętrznej usługi uwierzytelniania korporacyjnego w celu uzyskania dostępu do docelowej aplikacji internetowej oraz przeglądania lub wydobywania danych.
Naukowcy twierdzą, że przeglądając publicznie dostępne aplikacje internetowe, zidentyfikowali ponad 15 000, które wydają się mieć podatne konfiguracje. AWS kwestionuje jednak te szacunki i twierdzi, że „niewielki ułamek procenta klientów AWS ma aplikacje potencjalnie źle skonfigurowane w ten sposób, czyli znacznie mniej niż szacują badacze”. Firma twierdzi również, że kontaktowała się z każdym klientem ze swojej krótszej listy, aby zalecić bezpieczniejsze wdrożenie. AWS nie ma jednak dostępu ani wglądu w środowiska chmurowe swoich klientów, więc dokładna liczba ma jedynie charakter szacunkowy.
Badacze Miggo twierdzą, że natknęli się na problem podczas pracy z klientem. „Odkryto to w rzeczywistych środowiskach produkcyjnych” – mówi dyrektor generalny Miggo, Daniel Shechter. „Zaobserwowaliśmy dziwne zachowanie w systemie klienta — wydawało się, że proces sprawdzania poprawności był realizowany tylko częściowo, jakby czegoś brakowało. To naprawdę pokazuje, jak głębokie są współzależności między klientem a dostawcą”.
Aby wykorzystać problem z implementacją, osoba atakująca konfiguruje konto AWS i moduł równoważenia obciążenia aplikacji, a następnie jak zwykle podpisze własny token uwierzytelniający. Następnie osoba atakująca wprowadza zmiany w konfiguracji, tak aby wyglądało na to, że token wydała usługa uwierzytelniania celu. Następnie osoba atakująca zmusiłaby AWS do podpisania tokena tak, jakby legalnie pochodził z systemu celu i użycia go w celu uzyskania dostępu do docelowej aplikacji. Celem ataku musi być konkretnie źle skonfigurowana aplikacja, która jest publicznie dostępna lub do której osoba atakująca ma już dostęp, ale która umożliwiłaby jej eskalację uprawnień w systemie.
Amazon Web Services twierdzi, że firma nie postrzega fałszowania tokenów jako luki w systemie równoważenia obciążenia aplikacji, ponieważ zasadniczo jest to oczekiwany wynik wyboru określonej konfiguracji uwierzytelniania. Jednak po tym, jak badacze Miggo po raz pierwszy ujawnili swoje odkrycia firmie AWS na początku kwietnia, firma dokonał dwóch zmian w dokumentacji nastawione na aktualizację zaleceń dotyczących implementacji uwierzytelniania modułu równoważenia obciążenia aplikacji. Jedna z nich, od 1 maja, zawierała wytyczne dot dodaj potwierdzenie zanim moduł równoważenia obciążenia aplikacji podpisze tokeny. 19 lipca firma dodała również wyraźne zalecenie, aby użytkownicy ustawiali swoje systemy tak, aby odbierały ruch wyłącznie z własnego modułu równoważenia obciążenia aplikacji za pomocą funkcji zwanej „grupami zabezpieczeń”.
