Korzystanie z usług bezpieczeństwa AWS w celu ochrony przed podatnością Log4j, jej wykrywanie i reagowanie na nią

W tym poście przedstawimy wskazówki, które pomogą klientom, którzy reagują na niedawno ujawnioną podatność w zabezpieczeniach log4j. Obejmuje to, co możesz zrobić, aby ograniczyć ryzyko wystąpienia tej podatności, jak możesz spróbować określić, czy jesteś podatny na problem, a następnie, co możesz zrobić, aby zaktualizować swoją infrastrukturę za pomocą odpowiednich poprawek.

Daty aktualizacji:

31 Grudnia 2021: Wprowadzono niewielką aktualizację do drugiego akapitu w sekcji Amazon Route 53 Resolver DNS Firewall

29 Grudnia 2021: Dodano akapit w sekcji Detect, aby zapewnić wskazówki dotyczące sprawdzania, czy log4j istnieje w środowisku.

23 Grudnia 2021: Sekcja GuardDuty została zaktualizowana w celu opisania nowych etykiet zagrożeń dodanych do określonych wyników w celu nadania kontekstu log4j.

21 Grudnia 2021: Dodano więcej informacji rejestrowania zapytań DNS w Route 53 Resolver.

20 Grudnia 2021: Post został zaktualizowany, aby zawierał informacje o zaporze Amazon Route 53 Resolver DNS Firewall.

17 Grudnia 2021: Dodano więcej informacji na temat używania Athena do zapytań VPC

16 Grudnia 2021: Sekcja Respond została zaktualizowana, aby zawierała informację o IMDSv2 oraz mitygacji dla usług kontenerowych

Podatność log4j (CVE-2021-44228, CVE-2021-45046) jest krytyczną podatnością (podstawowy wynik CVSS 3.1 równy 10,0) we wszechobecnej platformie logowania Apache Log4j. Ta podatność umożliwia osobie atakującej zdalne wykonanie kodu na platformie, której dotyczy. Wersja 2 log4j, między wersjami 2.0-beta-9 i 2.15.0, jest zagrożona.

Podatność wykorzystuje interfejs Java Naming and Directory Interface (JNDI), który jest używany przez program Java do wyszukiwania danych, zazwyczaj za pośrednictwem katalogu, zwykle katalogu LDAP w przypadku tej podatności.

Poniższy obraz 1 przedstawia przebieg ataku log4j JNDI.

W celu natychmiastowej reakcji, zobacz post na blogu i użyj narzędzia zaprojetkowanego jako hotpatch dla działającej maszyny JVM przy korzystaniu z log4j 2.0+. Tutaj Steve Schmidt również omówił temat hotpatch.

Ochrona

Możesz korzystać z wielu usług AWS w celu zminimalizowania ryzyka narażenia na podatność log4j. Możesz zastosować podejście warstwowej kontroli, oraz/lub dobrać i wybrać sposoby kontroli wymienione poniżej, aby ograniczyć zagrożenie.

AWS WAF

Użyj AWS Web Application Firewall, zgodnie z AWS Managed Rules for AWS WAF, aby pomóc w ochronie twojej dystrybucji Amazon CloudFront, REST API Amazon API Gateway, Application Load Balancer, lub zasobów GraphQL API AWS AppSync.

• AWSManagedRulesKnownBadInputsRuleSet, w szczególności reguła Log4JRCE, która pomaga sprawdzać żądanie pod kątem obecności podatności Log4j.
  Przykładowe wzory zawierają ${jndi:ldap://example.com/}.
• AWSManagedRulesAnonymousIpList, w szczególności reguła AnonymousIPList, która pomaga sprawdzać adresy IP źródeł znanych z anonimizacji informacji klienckich.
• AWSManagedRulesCommonRuleSet, w szczególności reguła SizeRestrictions_BODY, która weryfikuje czy wielkość żądania ma najwyżej 8 KB (8,192 bitów).

Należy również rozważyć zaimplementowanie reguł WAF, które odmawiają dostępu, jeśli w żądaniu nie podano prawidłowej wartości nazwy FQDN nagłówka HTTP Host Header. Może to pomóc zmniejszyć prawdopodobieństwo, że skanery skanujące przestrzeń adresów IP w Internecie dotrą do zasobów chronionych przez WAF za pośrednictwem żądania z nieprawidłowym Host Headerem, takim jak adres IP zamiast FQDN. Aby to osiągnąć, można również użyć custom Application Load Balancer listener rules.

Jeśli korzystasz z AWS WAF Classic, będziesz musiał się zmigrować do AWS WAF lub utworzyć własny regex pasujący do warunków.

Posiadasz wiele kont? Postępuj zgodnie z tymi instrukcjami, aby korzystać z AWS Firewall Manager, do centralnego wdrożenia reguł AWS WAF w całej organizacji AWS.

Amazon Route 53 Resolver DNS Firewall

Możesz użyć zapory Route 53 Resolver DNS Firewall, zgodnie z listami z AWS Managed Domain Lists, aby pomóc proaktywnie chronić zasoby za pomocą rozpoznawania wychodzącego ruchu DNS. Zalecamy powiązanie zapory Route 53 Resolver DNS Firewall z regułą skonfigurowaną do blokowania domen na liście AWSManagedDomainsMalwareDomainList, która została zaktualizowana we wszystkich obsługiwanych regionach AWS z domenami zidentyfikowanymi jako hostujące złośliwe oprogramowanie używane w połączeniu z podatnością log4j. AWS będzie nadal dostarczać aktualizacje domen dla zapory Route 53 Resolver DNS Firewall za pośrednictwem tej listy.

Dodatkowo musisz wziąć pod uwagę zablokowanie wychodzącego portu 53, aby zapobiec korzystaniu z zewnętrznych niezaufanych serwerów DNS. To pomoże wymusić, aby wszystkie żądania DNS przepływały przez zaporę DNS Firewall i zapewni, że ruch DNS jest widoczny dla GuardDuty. Pomocne może być również użycie zapory DNS Firewall do zablokowania rozpoznawania DNS niektórych domen najwyższego poziomu kodu kraju (ccTLD), z którymi zasoby VPC nie mają uzasadnionego powodu się łączyć. Przykłady ccTLD, które możesz chcieć zablokować, mogą być zawarte w known log4j callback domains IOCs.

Dodatkowo rekomendowane jest włączenie rejestrowania zapytań DNS, które umożliwia identyfikowanie oraz kontrolowanie potencjalnie dotkniętych zasobów w ramach VPC, poprzez nadzorowanie logów DNS pod kątem obecności zablokowanych zapytań wychodzących z powodu podatności log4j lub innych znanych złośliwych miejsc docelowych. DNS query logging is also useful in helping identify EC2 instances vulnerable to log4j that are responding to active log4j scans, which may be originating from malicious actors or from legitimate security researchers. Rejestrowanie zapytań DNS jest również przydatne w identyfikacji podatnych instancji EC2, które odpowiadają na aktywne skany log4j, które mogą pochodzić ze złośliwych podmiotów lub od legalnych badaczy bezpieczeństwa. W obu przypadkach instancje odpowiadające na takie skany potencjalnie posiadają podatność na log4j i należy się nimi zająć. Firma GreyNoise monitoruje skany log4j i udostępnia domeny wywołań tutaj. Niektóre ważne domeny, które klienci mogą chcieć zbadać pod kątem aktywności logów, ale niekoniecznie zablokować, to: *interact.sh, *leakix.net, *canarytokens.com, *dnslog.cn, *.dnsbin.net oraz *cyberwar.nl.

AWS Network Firewall

Klienci mogą użyć zgodnych z Suricata reguł IDS/IPS w AWS Network Firewall, aby wdrożyć wykrywanie i ochronę sieciową. Chociaż Suricata nie posiada detektora protokołu dla LDAP, jest możliwe wykrywanie tych wywołań LDAP za pomocą Suricata. Reguły Suricata open source dotyczące Log4j są dostępne w corelight, NCC Group, ET Labs oraz CrowdStrike. Reguły te mogą pomóc w identyfikacji skanowania, a także po wykryciu podatności log4j. Ponieważ obecnie ma miejsce duża liczba łagodnych skanowań, zalecamy klientom skoncentrowanie się najpierw na potencjalnych działaniach post-exploitation, takich jak ruch wychodzący LDAP z ich VPC do niezaufanych miejsc docelowych w Internecie.

Zalecamy również, aby klienci rozważyli zaimplementowanie reguł egzekwowania portów/protokołów wychodzących, które monitorują lub uniemożliwiają instancjom dostęp do protokołów, takich jak LDAP, korzystanie z niestandardowych portów LDAP (53, 80, 123 i 443). Monitorowanie lub zapobieganie używaniu wychodzącego portu 1389 może być szczególnie pomocne w identyfikowaniu systemów, które zostały uruchomione przez skanery internetowe w celu wykonywania połączeń wychodzących. Zalecamy również, aby systemy bez uzasadnionej biznesowej potrzeby inicjowania połączeń sieciowych z Internetem nie miały domyślnie takiej możliwości. Filtrowanie i monitorowanie wychodzącego ruchu sieciowego jest nie tylko bardzo pomocne z log4j, ale także w identyfikowaniu innych klas podatności.

Use IMDSv2

We wczesnych dniach istnienia podatności log4j badacze zauważyli, że gdy host został zhakowany za pomocą początkowej podatności JDNI, osoby atakujące czasami próbują przechwycić dane uwierzytelniające z hosta i wysłać je za pomocą jakiegoś mechanizmu, takiego jak wyszukiwanie LDAP, HTTP lub DNS. Zalecamy, aby klienci używali ról uprawnień IAM zamiast długoterminowych kluczy dostępu i nie przechowywali poufnych informacji, takich jak dane uwierzytelniające, w zmiennych środowiskowych. Klienci mogą również wykorzystać AWS Secrets Manager do przechowywania i automatycznej rotacji poświadczeń bazy danych zamiast przechowywania długoterminowych danych uwierzytelniających bazy danych w zmiennych środowiskowych hosta. Zobacz wymagane wskazówki tutaj i tutaj, jak zaimplementować Secrets Manager w swoim środowisku.

Aby zabezpieczyć się przed takimi atakami w AWS, gdy mogą być używane role EC2 — i zachować prywatność wszystkich danych IMDS — klienci powinni rozważyć wymaganie użycia Instance MetaData Service w wersji 2 (IMDSv2). Ponieważ IMDSv2 jest domyślnie włączony, możesz wymagać jego użycia, wyłączając IMDSv1 (który jest również domyślnie włączony). Dzięki IMDSv2 żądania są chronione przez początkową interakcję, w której proces wywołujący musi najpierw uzyskać token sesji z HTTP PUT, a kolejne żądania muszą zawierać token w nagłówku HTTP. To znacznie utrudnia atakującym przechwycenie poświadczeń lub jakichkolwiek innych danych z IMDS. Aby uzyskać więcej informacji na temat korzystania z IMDSv2, zapoznaj się z tym blogiem i dokumentacją. Chociaż wszystkie najnowsze zestawy SDK i narzędzia AWS obsługują IMDSv2, podobnie jak w przypadku wszelkich potencjalnie niezgodnych wstecznie zmian, przetestuj tę zmianę na reprezentatywnych systemach przed jej szerokim wdrożeniem.

Wykrycie

W tym poście omówiono, jak potencjalnie ograniczyć możliwość wykorzystania tej podatności. Następnie skupimy się na usługach AWS, które mogą pomóc w wykryciu, czy ta podatność istnieje w Twoim środowisku.

Amazon Inspector

Jak pokazano na rysunku, zespół Amazon Inspector stworzył reguły w celu zidentyfikowania istnienia tej podatności w instancjach Amazon EC2 i obrazach Amazon Elastic Container Registry Images (Amazon ECR). Dzięki nowemu Amazon Inspector, skanowanie jest zautomatyzowane i ciągłe. Ciągłe skanowanie jest napędzane zdarzeniami, takimi jak publikowanie nowych pakietów oprogramowania, nowych instancji oraz nowych powszechnych podatności w zabezpieczeniach i narażenia (CVE).

Przykładowo, kiedy zespół Inspector dodał obsługę podatności log4j (CVE-2021-44228 & CVE-2021-45046), Inspector natychmiast zaczął szukać tej podatności we wszystkich obsługiwanych instancjach zarządzanych przez AWS Systems Manager , w których Log4j został zainstalowany za pomocą menedżerów pakietów systemu operacyjnego (OS) i gdzie ten pakiet był obecny w obrazach kontenerów Amazon ECR zgodnych z Maven. Jeśli ta podatność jest obecna, wyniki zaczną pojawiać się bez żadnych ręcznych działań. Jeśli używasz Inspector Classic, musisz upewnić się, że przeprowadzasz ocenę wszystkich swoich instancji Amazon EC2. Możesz postępować zgodnie z tą dokumentacją, aby upewnić się, że tworzysz cel oceny dla wszystkich swoich instancji Amazon EC2. Oto dalsze szczegóły dotyczące aktualizacji skanowania kontenerów w prywatnych rejestrach Amazon ECR.

GuardDuty

Oprócz wykrycia obecności tej podatności za pośrednictwem usługi Inspector zespół Amazon GuardDuty zaczął również dodawać wskaźniki naruszenia bezpieczeństwa związanego z wykorzystaniem podatności Log4j i będzie to robić nadal. GuardDuty będzie monitorować pod kątem prób dotarcia do podejrzanych adresów IP lub wpisów DNS, a także może znaleźć aktywność po wykorzystaniu podatności na podstawie ustaleń behawioralnych opartych na anomaliach. Na przykład, jeśli instancja Amazon EC2 zacznie komunikować się na nietypowych portach, GuardDuty wykryje tę aktywność i utworzy znalezienie Behavior:EC2/NetworkPortUnusual. Ta aktywność nie ogranicza się jednak do wykrycia NetworkPortUnusual. GuardDuty ma wiele różnych wniosków związanych z aktywnością post exploit, takich jak naruszenie danych uwierzytelniających, które mogą być widoczne w odpowiedzi na naruszone zasoby AWS. Listę wniosków GuardDuty można znaleźć w dokumentacji GuardDuty.

Aby wspomóc identyfikowanie i ustalanie priorytetów problemów związanych z CVE-2021-44228 i CVE-2021-45046, zespół GuardDuty dodał etykiety zagrożeń do szczegółów znalezisk dla następujących typów znalezisk:

Backdoor:EC2/C&CActivity.B

Jeśli wywołane IP jest powiązane z Log4j, pola powiązane ze znaleziskiem będą zawierały następujące wartości:

• service.additionalInfo.threatListName = Amazon
• service.additionalInfo.threatName = Log4j Related

Backdoor:EC2/C&CActivity.B!DNS

Jeśli nazwa wywołanej domeny jest powiązana z Log4j, pola powiązane ze znaleziskiem będą zawierały następujące wartości:

• service.additionalInfo.threatListName = Amazon
• service.additionalInfo.threatName = Log4j Related

Behavior:EC2/NetworkPortUnusual

Jeśli instacja EC2 komunikowała się na portach 389 lub 1389, wtedy severity znaleziska będzie zmieniona na High, a także pola znaleziska będą zawierały następujące wartości:

• service.additionalInfo.context = Possible Log4j callback

Security Hub

Obecnie wielu klientów korzysta również z AWS Security Hub wraz z usługami Inspector i GuardDuty do agregacji alertów oraz umożliwienia automatycznej korekty i reagowania. Na krótką metę zalecamy używania Security Hub do skonfigurowania alertów za pośrednictwem AWS Chatbot, Amazon Simple Notification Service lub systemu zgłoszeń w celu widoczności, gdy Inspector znajdzie tę podatność w Twoim środowisku. W dłuższej perspektywie zalecemy korzystanie z Security Hub, aby w razie potrzeby włączyć automatyczne korygowanie i reagowanie na alerty bezpieczeństwa. Oto pomysły jak skonfigurować automatyczne korygowanie i reagowanie za pomocą Security Hub.

Logi przepływu VPC

Klienci mogą używać zapytań Athena lub CloudWatch Logs Insights w swoich logach przepływu VPC, aby łatwiej identyfikować zasoby VPC powiązane z aktywnością sieci wychodzącej po log4j post exploitation. Wersja 5 logów przepływu VPC jest szczególnie przydatna, ponieważ zawiera pole „flow-direction”(kierunek przepływu). Zalecamy klientom rozpoczęcie od zwrócenia szczególnej uwagi na połączenia wychodzące z sieci przy użyciu portu docelowego 1389, ponieważ użycie wyjścia tego portu jest mniej popularne w legalnych aplikacjach. Bezpłatne usługi reputacji IP, takie jak VirusTotal, GreyNoise, NOC.org oraz ipinfo.io mogą dostarczyć przydatnych informacji związanych z publicznymi adresami IP znalezionymi w zarejestrowanej aktywności.

Uwaga: Jeśli masz środowisko Microsoft Active Directory w przechowywanych dziennikach przepływu VPC, możesz zobaczyć fałszywe alarmy z powodu użycia portu 389.

Walidacja za pomocą narzędzi typu open source

Ze względu na zmieniający się charakter różnych podatności log4j, ważne jest aby sprawdzić czy aktualizacje, poprawki i środki zaradcze w twoim środowisku rzeczywiście działają w celu ograniczenia potencjalnego wykorzystania podatności log4j. Możesz użyć narzędzi typu open source, takich jak publiczne adresy IP AWS , aby uzyskać listę wszystkich twoich obecnych publicznych adresów IP dla konta AWS, a następnie aktywnie skanować te adresy IP za pomocą log4j-scan korzystając z tokena a DNS Canary Token, aby uzyskać powiadomienie o tym, które systemy nadal mają podatność log4j i mogą zostać wykorzystane. Zalecamy okresowe skanowanie w ciągu kilku tygodni, aby upewnić się, że nadal obowiązują wszelkie środki zaradcze oraz żadne nowe systemy nie są podatne na problem log4j.

Reagowanie

Pierwsze dwie sekcje omówiły sposoby zapobiegania potencjalnym próbom wykorzystania oraz jak wykryć obecność podatności i potecjalnych prób jej wykorzystania. W tej sekcji skupimy się na krokach, które możesz podjąć, aby złagodzić tę podatność. Jak mówiliśmy na początku, zalecaną natychmiastową reakcją jest śledzenie tego wątku oraz użycie narzędzia zaprojektowanego do wykonywania tzw. Hotpatch’a na działającej maszynie JVM przy korzystaniu z log4j 2.0+. Tutaj Steve Schmidt również omówił temat hotpatch.

AWS Patch Manager

Jeśli korzystasz z AWS Systems Manager Patch Manager i masz ustawione krytyczne poprawki do natychmiastowej instalacji w patch baseline, twoje instancje EC2 będą już miały zainstalowaną ten patch. Ważne jest, aby pamiętać, że to jeszcze nie jest koniec. Następnie musisz zaktualizować ścieżkę klasy wszędzie tam, gdzie biblioteka jest używana w kodzie aplikacji w celu upewnienia się, że używasz najbardziej aktualnej wersji. Za pomocą AWS Patch Manager możesz patch’ować węzły zarządzane w środowisku hybrydowym. Sprawdź tutaj dalsze szczegóły dotyczące implementacji.

Container mitigation

Aby zainstalować hotpatch wymieniony wcześniej na węzłach EKS cluster worker, AWS opracował RPM, który wykonuje hotpatch na poziomie JVM, który wyłącza wyszukiwanie JNDI z biblioteki log4j2. Apache Log4j2 node agent to projekt open source zbudowany przez zespół Kubernetes w AWS. Aby dowiedzieć się więcej o tym jak zainstalować tę usługę, odwiedź tę stronę Github.

Po zidentyfikowaniu, obrazy kontenerów ECR będą musiały zostać zaktualizowane by móc korzystać z poprawionej wersji log4j. Następnie musisz się upewnić, że wszystkie kontenery zbudowane z podatnym obrazem kontenera ECR zostaną zaktualizowane tak, aby jak najszybciej używać nowego obrazu. Może się to różnić w zależności od usługi używanej do wdrażania tych obrazów. Przykładowo, jeśli korzystasz z Amazon Elastic Container Service (Amazon ECS), możesz chcieć zaktualizować Service, aby wymusić nowe wdrożenie, które spowoduje pobranie obrazu przy użyciu nowej wersji log4j. Sprawdź dokumentację, która obsługuje metodę używaną do wdrażania kontenerów.

Jeśli używasz aplikacji opartych na Javie w kontenerach Windows, postępuj zgodnie ze wskazówkami firmy Microsoft tutaj.

Zalecamy rotację poświadczeń aplikacji i odwołanie istniejących poświadczeń natychmiast po zainstalowaniu poprawki.

Strategie łagodzenia skutków w przypadku braku możliwości aktualizacji

W przypadku, gdy nie możesz zaktualizować do wersji, która domyślnie blokuje dostęp do JDNI, lub jeśli nadal określasz swoją strategię dotyczącą tego, jak zamierzasz naprawić swoje środowisko, możesz złagodzić tę podatność, zmieniając konfigurację log4j. Aby zaimplementować tę mitygację w wydaniach >=2.10, musisz usunąć klasę JndiLookup ze ścieżki klas: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Bardziej wyczerpującą listę kroków mitygujących dla określonych wersji można znaleźć na stronie Apache.

Podsumowanie

W tym poście opisaliśmy kluczowe usługi bezpieczeństwa AWS, które umożliwiają przyjęcie warstwowego podejścia, aby pomóc chronić przed, wykrywać i reagować na ryzyko związane z podatnością log4j. Zachęcamy do dalszego monitorowania biuletynów AWS dotyczących bezpieczeństwa; AWS będzie kontynuował aktualizację biuletynów o działania naprawcze po stronie modelu współodpowiedzialności.

Biorąc pod uwagę wagę tej podatności, zachęcamy do zwrócenia szczególnej uwagi na nią i odpowiedniego nadania priorytetu wdrażaniu mechanizmów kontrolnych przedstawionych w tym poście.

źródło: AWS