W dzisiejszych czasach powszechną praktyką jest przeprowadzanie okresowych testów bezpieczeństwa lokalnej sieci, jednakże rzadko kiedy właściciele firm decydują się na podobne testy ich środowisk chmurowych. Musimy zrozumieć nowe zagrożenia i ryzyka, które pojawiły się wraz z usługami chmurowymi oraz jak powinniśmy zmienić nasze podejście do ich testowania. Celem prezentacji jest pokazanie konieczności testowania środowiska chmurowego oraz jak bardzo różni się ono od testów środowiska opartego o klasyczną architekturę. W formie dema przedstawiony zostanie przykładowy atak na firmę wykorzystującą usługi AWS. Wykorzystując podatność w aplikacji webowej, a następnie szereg drobnych zaniedbań w konfiguracji AWS, prelegent pokaże jak potencjalny atakujący może krok po kroku przejąć rolę administratora AWS, a następnie usunąć wszystkie dowody swojej aktywnności. Na podstawie przeprowadzonego ataku i zebranych wniosków odpowie na pytanie "jak powinien wyglądać test bezpieczeństwa chmury?".

1. Testowanie bezpieczeństwa chmury
na przykładzie AWS
Paweł Rzepa (pawel.rzepa@securing.pl) Rzepsky

7. Czy projektując system informatyczny
bierzemy pod uwagę wszystkie
zagrożenia?
Rzepsky

8. Przeanalizujmy przykładowy atak…
Rzepsky

9. Architektura
„od zewnątrz”
Rzepsky

10. Co to są metadane?
• Dane o twojej instancji:
• Dostępne TYLKO z twojej instancji pod
adresem:
http://169.254.169.254/latest/meta-data
Rzepsky

11. Dostęp do roli poprzez błąd w
aplikacji (SSRF)
Rzepsky

12. Co atakujący
może zrobić z
takimi
uprawnieniami?
Rzepsky

13. Rzepsky

14. Eskalacja uprawnień Rzepsky

16. Co poszło nie tak?
• Podatna aplikacja
• Nadmiarowe uprawnienia
przypisane do „testowej” instancji
• Brak monitorowania użycia kluczy
roli poza instancją
Rzepsky

17. Ukrywanie akcji przed wykryciem

18. CloudTrail: monitoring wszystkich regionów
Rzepsky

19. CloudTrail: ukrywanie akcji
Rzepsky

21. Rzepsky

22. Co poszło nie tak?
• Brak monitoringu wrażliwych akcji
• Brak mechanizmów zapewniających
niezaprzeczalność logów (np. kopiowanie
logów w bezpieczne miejsce)
Rzepsky

23. Jak testować chmurę?
Rzepsky

24. Jak testować chmurę?
Przegląd architektury
– Czy nie ma „dodatkowych” komponentów (np.
kryptokoparka na boku 😉 )?
– Czy sama koncepcja systemu jest bezpieczna (np.
monitoring wrażliwych akcji bez uruchamiania
procesu reagowania)?
Rzepsky

25. Jak testować chmurę?
Przegląd konfiguracji usług
– Czy każda usługa jest skonfigurowana zgodnie z
najlepszymi praktykami (np. czy pracownik może
„podnieść” swoje uprawnienia)?

26. Jak testować chmurę?
Testy wrażliwych usług
– Testy aplikacji (np. SSRF/RCE/XXE)
– Testy serverless (np. „event injection” w Lambda)
Rzepsky

27. Jak testować chmurę?
Weryfikacja procesu monitorowania
– Czy możliwa jest ingerencja w zbierane logi (np. brak
kopiowania logów do odseparowanego miejsca)?
– Czy monitorowane są wrażliwe operacje (np.
tworzenie nowego użytkownika/nowych kluczy)?
– Czy jest zdefiniowany proces reagowania na wrażliwe
operacje?
Rzepsky

28. Czy
Czy jest się czego obawiać?

29. Rzepsky

31. Extras
CloudGoat: https://bit.ly/2TKxczt
CloudGoat walkthrough: https://bit.ly/2u4QYXO
Pacu: https://bit.ly/2SYJKyX
7 kroków do zabezpieczenia AWS: https://bit.ly/2EN7yAs
CloudMapper: https://bit.ly/2NV6zSY
PacBot: https://bit.ly/2FvVhTk
Prowler: https://bit.ly/2kxy879
SecurityMonkey: https://bit.ly/2KYl4X7
Rzepsky

32. Testuj swoją chmurę!!!
Rzepsky

33. Zapraszam na nasze stoisko na mini
prezentacje:
• Aplikacje mobilne i jak je złamać?
• Krótka historia o phishingu
• Ciekawe przypadki podatności XXE
• Krk Analytica – studium wycieku danych z
chmury AWS

34. DZIĘKUJĘ ZA UWAGĘ.
pawel.rzepa@securing.pl