W części 2 naszej serii hakerów AWS, przyjrzymy się serwerowi automatyki open-source Jenkins.

Jenkins pomaga zautomatyzować te części rozwoju oprogramowania, które są związane z budową, testowaniem i wdrażaniem, i odgrywa główną rolę w zapewnieniu ciągłej integracji i dostawy.

Jest również wykorzystywany jako narzędzie zarządzania, pomagające w tworzeniu potoków do budowy, testowania i wdrażania infrastruktury chmury; jest to popularny wybór dla wielu zespołów programistycznych, które pracują w chmurze AWS.

W tym artykule omówimy potencjalne problemy z bezpieczeństwem i ustalimy, co można zrobić, aby zabezpieczyć konta AWS przed niepożądanym dostępem przez Jenkinsa.

Tak więc, bez dalszej zwłoki, zapnijmy pasy i uruchommy zapłon.

Hack i Slash

Jenkins wymaga wielu przywilejów do rozmieszczania i niszczenia infrastruktury i zasobów w chmurze, co czyni go doskonałym punktem wejścia dla hakerów!

Dlatego większość firm zazwyczaj ogranicza dostęp, ukrywając go za wirtualną siecią prywatną (VPN), udostępniając go tylko swoim pracownikom.

Zdarza się jednak, że serwer Jenkins firmy jest publicznie dostępny, a anonimowi użytkownicy korzystają z niego na różnych poziomach dostępu - najłatwiej jest uzyskać uprawnienia tylko do odczytu.

Jeszcze raz zakładając mój biały kapelusz, pozwolę sobie najpierw rzucić nieco światła na ten konkretny typ dostępu.

Spalony po przeczytaniu

Zdziwiłbyś się, jakie szkody można wyrządzić "tylko" za zgodą tylko do odczytu. Dostęp do danych uwierzytelniających AWS, danych i tajnych informacji... te i inne mogą być ujawnione - jeśli wiesz, gdzie je znaleźć.

Przyjrzyjmy się trzem konkretnym punktom wejścia, które mogą zapewnić potencjalny dostęp do pewnych soczystych szczegółów.

Miejsce pracy

W Jenkins, Workspace daje Ci przegląd i łatwy dostęp do struktury projektu i plików projektu.

Tutaj nieautoryzowany użytkownik może w prosty sposób znaleźć kod źródłowy danej aplikacji, który następnie może wykorzystać w połączeniu z uprawnieniem tylko do odczytu do podglądu wszystkich plików projektu.

Oprócz kodu źródłowego można tu również znaleźć pliki konfiguracyjne, zrzuty danych, pliki CSV zawierające PII lub nawet zrzuty baz danych.

To wszystko jest dobre i dandysowskie, ale oto prawdziwy kicker: w plikach konfiguracyjnych, a nawet zakodowanych na twardym dysku w aplikacji, można znaleźć zwykłe tekstowe poświadczenia AWS.

Gdy haker znajdzie to, może zrobić tyle, ile pozwala mu na to Polityka JA dołączona do tego użytkownika.

Przy okazji: kolejnym punktem wejścia jest Step Workspace. Jeśli pracujesz z rurociągami, to właśnie tutaj dostępna jest struktura projektu i pliki w rurociągach.

Zmienne środowiskowe

Są one definiowane indywidualnie dla każdej pracy i są dostępne tylko w trakcie jej wykonywania. Dzięki autoryzacji tylko do odczytu można tu znaleźć klucze dostępu AWS, loginy, hasła i inne wrażliwe informacje. Strona Zmienne środowiskowe jest dostępna dla większości już zrealizowanych zadań.

Dziennik konsoli

Dziennik konsoli zawiera wyniki i dane wyjściowe każdego polecenia wykonanego dla każdego zadania. Można tu znaleźć wiele ciekawych informacji, takich jak dzienniki referencji, punktów końcowych i adresów e-mail.

Przykładowe zadania, które znalazłem, zawierające poufne dane:

• Tworzenie nowych użytkowników AWS IAM (i drukowanie kluczy dostępu);
• Generowanie tymczasowych kluczy dostępu AWS za pomocą STS (i drukowanie ich);
• Testowanie aplikacji na różnych poziomach dostępu (oraz drukowanie używanych loginów i haseł).

Nazwa użytkownika/hasło pozwala np. na zalogowanie się do środowiska scenicznego, w którym test został przeprowadzony. Teraz środowisko sceniczne można podłączyć do produkcyjnej bazy danych. A kiedy tak się dzieje, to jesteśmy w nim po raz pierwszy!

Praca dla wszystkich!

Kolejny poziom dostępu, powszechnie spotykany na publicznie eksponowanych maszynach Jenkinsa, pozwala każdemu anonimowemu użytkownikowi na stworzenie pracy Jenkinsa.

Zadanie może być skryptem, który jest następnie uruchamiany przez maszynę Jenkinsa. Oznacza to, że możesz stworzyć dowolny skrypt, a Jenkins uruchomi go za Ciebie.

Czy chcesz wyodrębnić tymczasowe klucze dostępu z metadanych Jenkinsa EC2? Nie ma problemu:

Curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Chcesz klucze dostępu przechowywane w Jenkins Credentials? Nie ma problemu, wydrukuj je na ekranie lub wyślij e-mail.

A może Jenkins użyje klawiszy dostępu użytkownika IAM zamiast roli? Świetnie:

cat ~/.aws/credentials

Jeśli to nie wystarczy, jest jeszcze jeden potężny poziom uprawnień - Manage Jenkins.

Jenkins, Fetch!

Ten typ dostępu pozwala na otwarcie strony "Zarządzaj Jenkinsem" ze wszystkimi szczegółami konfiguracji.

Dzięki temu poziomowi uprawnień możesz podglądać (i modyfikować!) bieżącą konfigurację wszystkich rozszerzeń. Może on dać ci adresy e-mail, klucze prywatne, dane uwierzytelniające, adresy repozytorium git i inne.

Manage Jenkins daje również dostęp do konsoli skryptów. Konsola ta może być wykorzystana do uruchamiania dowolnych skryptów bez konieczności wykonywania zadania. Scenariusze ataków są podobne do poprzedniego poziomu dostępu z tworzeniem zadań. Ale konsola jest również użyteczna do odszyfrowania danych uwierzytelniających Jenkinsa. Wystarczy złapać hash interesującego poświadczenia (zobacz pole formularza html) i uruchomić następujący skrypt:

hashed_credential='credential-hash-value' decrypted_credential = hudson.util.Secret.decrypt(hashed_credential) println(decrypted_credential)

Wydrukuje on wartość ukrytą za wybranym hashem poświadczenia.

Jeśli uzyskasz dostęp do kluczy dostępu do AWS, które należą do Jenkinsa, możesz zrobić wszystko, na co pozwala ci Jenkins. 

Wszystkie powyższe przykłady są prawdziwe i możliwe. Aby zilustrować, że tak się rzeczywiście dzieje, pozwolę sobie opowiedzieć małą historię jednej ze spraw, w którą byłem ostatnio zaangażowany.

Story Time

Kilka miesięcy temu PGS Software przeprowadziło audyt bezpieczeństwa dla jednego z naszych klientów. W ramach tego audytu otrzymałem referencje AWS do konta klienta z dostępem tylko do odczytu.

Korzystając z tych referencji, sprawdziłem każdą część infrastruktury projektu - i niedługo potem znalazłem maszynę Jenkinsa działającą na jednym z regionów AWS.

Maszyna ta znajdowała się w publicznej podsieci i posiadała publiczny IP. Wyglądało też na to, że została stworzona przy użyciu szablonów terraform. Grupa bezpieczeństwa pozwoliła każdemu na dostęp do niej (0.0.0.0/0).

Niestety, istniała strona logowania bez dostępu anonimowego.

Znalazłem też pełny dziennik z provisioningu instancji Jenkinsa na CloudWatch. Co zaskakujące, log zakończył się danymi uwierzytelniającymi nowo utworzonego użytkownika administratora Jenkinsa.

Otworzyłem więc stronę logowania Jenkinsa po raz kolejny - ale tym razem udało mi się zalogować do konta administratora. Sprawdzając rolę IAM Role i Zasady dołączone do EC2, wiedziałem już, że Jenkins posiada politykę AWS AdministratorAccess dołączoną do tej roli, więc teraz mam pełny dostęp do konta AWS.

Klient założył, że jego konto jest zabezpieczone, ponieważ użytkownicy muszą się logować. Nie liczyli na to, że dane do logowania będą łatwo dostępne w logu CloudWatch z uprawnieniem tylko do odczytu.

hbspt.cta.load(6429962, '6dacb745-55ce-483b-bac2-1c601291df4a', {});

Dlaczego to się stało?

Powyższe punkty dostępu nie muszą być podatne na zagrożenia. Jak wspomniano w moim ostatnim artykule, bezpieczeństwo cybernetyczne jest strategią, która musi zostać wdrożona na wszystkich frontach.

Jeśli ujawnisz swoje sekrety wiatrowi, nie powinieneś winić go za ujawnienie ich drzewom. `H. Kahlil Gibran

Wszelkie naruszenia bezpieczeństwa stają się możliwe, gdy środki bezpieczeństwa nie są stosowane konsekwentnie i skutecznie. W przypadku Jenkinsa możemy zidentyfikować cztery główne problemy:

Jenkins jest publicznie dostępny

Nieposiadanie VPN może mieć poważne konsekwencje. Internet to ogromna dżungla łączności, która ma swój udział w drapieżnikach, i nie zawahają się skoczyć na łatwą zdobycz. Jeśli nie ma VPN, należy go zablokować przynajmniej na poziomie grupy bezpieczeństwa, pozwalając na łączenie się tylko z zatwierdzonymi IP. Domowe IP Twoich pracowników nie są uważane za bezpieczne, ponieważ pojedynczy IP może pokryć połowę dużego miasta.

Firma Jenkins Security jest wyłączona

Jenkins ma pewne opcje bezpieczeństwa. Na przykład, domyślnie wymaga on zalogowania się. Jednak ustawienie tych opcji może być uciążliwe i czasochłonne, dlatego niektóre firmy decydują się na wyłączenie modułu bezpieczeństwa i... zapomnienie o nim później. "Skąd ktoś zna IP mojej nowo utworzonej maszyny Jenkins? Tylko moi pracownicy o tym wiedzą, i nie muszą się logować, żeby robić rzeczy".

Zła konfiguracja Wirtualnego Gospodarza (Virtual Host Configuration)

Dostęp do domeny jest prawidłowo `ograniczony,`ale dostęp IP wykorzystuje domyślny `host` bez żadnych ograniczeń. Oznacza to, że gdy spróbuję otworzyć https://jenkins.example.com połączenie NIE będzie dozwolone. Ale wtedy jeśli spróbuję z IP za tą domeną, użyje innego pliku konfiguracyjnego na serwerze i wpuści mnie.

Złamana zasada najmniejszego uprzywilejowania

"Daj każdemu prawa administratora, może w pewnym momencie będzie mu to potrzebne". To jest wspólne - prawa administratora są przyznawane ludziom, bo myślą, że w pewnym momencie mogą ich potrzebować. Może się to zdarzyć wtedy, gdy nie chcesz, aby co 5 minut, co jakiś czas, co 5 minut, twoje prowadzenie techniczne było kłopotliwe z prośbą.

Jak uniknąć tych przecieków

Powyższych punktów można zdecydowanie uniknąć przy zastosowaniu odpowiednich środków i strategii bezpieczeństwa. Oto kilka wskazówek, co można zrobić, aby zabezpieczyć swoje konta AWS z systemem Jenkins.

1. Upewnij się, że Jenkins jest dostępny tylko z sieci lokalnej lub korzystaj z VPN.
2. Upewnij się, że ustawienia zabezpieczeń w Jenkins są prawidłowo skonfigurowane - sprawdź domenę i bezpośredni dostęp IP.
3. Daj Jenkinsowi dostęp do swojego środowiska AWS tylko w razie potrzeby.
4. Zasada Najniższej Prywatności to Twój przyjaciel.

Podsumowanie

Bezpieczeństwo to niekończąca się historia. Rozwijając swoją firmę i rozpoczynając korzystanie z większej ilości narzędzi cyfrowych, musisz mieć pewność, że będziesz na bieżąco ze słabościami swoich platform i kont. Edukacja i prowadzenie wewnętrznych i zewnętrznych audytów bezpieczeństwa pomoże Ci zrozumieć i posiadać narzędzia do zabezpieczania Twoich systemów i środowisk AWS.

Ostatecznym zabezpieczeniem jest zrozumienie rzeczywistości. ` H. Stanley Judd

Moja rada dla Ciebie jest taka, aby analiza bezpieczeństwa każdego elementu Twojego rozwiązania cyfrowego była standardową praktyką. W ten sposób zachowają Państwo kontrolę i będą mogli odeprzeć wszystkich niepożądanych intruzów.