Dlaczego wszyscy są tak zaniepokojeni etc / passwd?

36

Oto zawartość mojej błędnej maszyny tego konkretnego pliku:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/us$
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:100:103::/home/syslog:/bin/false

Czy ktoś mógłby mi wyjaśnić, dlaczego źle jest, jeśli jakiś zły facet może zdobyć ten plik z mojego serwera produkcyjnego?

zabawny gość
źródło
19
W dawnych czasach zawierał zaszyfrowane hasła dla każdego użytkownika - gdzie teraz jest: x:. Jeśli go masz (co było łatwe, ponieważ wszyscy mogą je odczytać, więc potrzebujesz tylko jednego loginu), możesz złamać hasło metodą brutalnej siły. Teraz są przechowywane w / etc / shadow, który nie jest czytelny dla wszystkich, więc mniej prawdopodobne jest, że „wyjdzie”, ale który miałby ten sam problem, gdyby tak się stało.
Mark Smith
8
Na przykład mogę powiedzieć, że masz serwer WWW na tym komputerze. W połączeniu z adresem IP może być możliwe do włamania>: - D
Rinzwind
3
@MarkSmith Zawierał zaszyfrowane hasła, kiedy? AFAIK zaczął życie jako hashowane hasła. Z pewnością odkąd pierwszy raz użyłem Uniksa w 1982 roku.
user207421,
3
@funguy: Użytkownik www-data jest zwykle używany przez serwery internetowe. Ubuntu i prawdopodobnie Debian używali tego użytkownika jako domyślnego użytkownika Apache.
Lie Ryan,
3
@ funguy www-data jest domyślnym użytkownikiem apache. Jest więcej: uucp to uniks na kopie unix; oznacza to, że kopiujesz pliki między systemami. „Irc” i „komary” są również łatwe do wykrycia.
Rinzwind

Odpowiedzi:

47

Najważniejsze jest to, że Pentesters / biało-kapelusze / etycznych hakerów, a także cel czarny kapelusz /etc/passwd jako proof of concept, jako sprawdzian możliwości uzyskania dostępu do systemu.

Technicznie /etc/passwdnie jest to takie straszne. Kiedyś przechowywał prywatne dane, oczywiście hasła, ale na dzień dzisiejszy powinieneś się bardziej martwić /etc/shadow- większość systemów Linux używa obecnie shadowzestawu narzędzi do przechowywania zaszyfrowanego i solonego hasła /etc/shadow, które w przeciwieństwie do innych /etc/passwdnie jest światem -czytelny. (chyba że użyjesz pwunconvpolecenia, które faktycznie przenosi zaszyfrowane hasła z powrotem do `/ etc / passwd).

Jedyną mniej lub bardziej wrażliwą informacją są nazwy użytkowników. Jeśli masz sshdlub telnetna serwerze i nazwę użytkownika ze słabym hasłem, istnieje możliwość ataku siłowego.

Nawiasem mówiąc, twoje pytanie zostało zadane wcześniej . Tutaj po prostu odtworzyłem niektóre z wymienionych tam pojęć.

Mały dodatek: jest to trochę zbyt daleko idące, ale zauważyłem, że masz bashjako root root. Załóżmy, że masz w systemie użytkownika, który ma bashpowłokę, a nawet gorzej - ten użytkownik jest sudoer. Teraz, jeśli bash jest przestarzały lub niezałatany, osoba atakująca może próbować wykorzystać lukę Shellshock w celu kradzieży danych lub wykonania bomby wideł, aby tymczasowo wyłączyć system. Tak, technicznie rzecz biorąc, /etc/passwdnie jest to wielka sprawa, ale daje atakującemu pojęcie o niektórych informacjach o tym, co należy podjąć

Dodatkowa edycja, 18.11.2016

Po wykorzystaniu serwera Ubuntu na Oceanie cyfrowej na chwilę, to przyszło do mojej uwagi, że większość ataków brute force przeciwko mojego serwera przeprowadzono dla rootużytkownika - 99% wpisów do nieudanej hasło w /var/log/auth.logbyły za root. /etc/password, jak wspomniałem wcześniej, pozwala atakującemu spojrzeć na listę użytkowników, nie tylko użytkowników systemu, ale także użytkowników, co oznacza więcej potencjalnych miejsc ataku. Pamiętajmy, że nie wszyscy użytkownicy są świadomi bezpieczeństwa i nie zawsze tworzą silne hasło, więc osoba atakująca na błąd ludzki lub zbytnią pewność siebie ma dość duże szanse na wygraną.

Sergiy Kolodyazhnyy
źródło
6
+1, świetna odpowiedź. Dodając do tego, chciałbym również powiedzieć, że ogólnie informacja jest potęgą; pomijając niesławny Shellshock, można na przykład zebrać informacje o uruchomionych procesach, które również można wykorzystać; na przykład na komputerze OP działa Apache, a to jeszcze jedna potencjalna dziura, która pozostała nie odkryta
kro
1
Hmm ... Czy zasugerowałbyś zmianę domyślnych nazw użytkowników, aby zmylić atakującego?
Freedo,
@ Freedom To nie pomaga. Identyfikatory użytkownika i grupy pozostają takie same, jeśli zmienisz logowanie. Na przykład, oto moja testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. Po biegnę sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , wpis ma inną nazwę, ale i uid gid są takie same: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. Jeśli hasło pozostanie niezmienione, atakujący może zgadywać i nadal łamać system. Wymaganie, aby hasło wygasało i było zmieniane co jakiś czas, jest lepszym podejściem, ale również nie jest kuloodporne.
Sergiy Kolodyazhnyy
1
Przydatna jest zmiana domyślnych nazw użytkowników dla tych kont, które mają loginy SSH (lub inne loginy zdalne). Zmienia się oczywiście domyślne porty dla tych loginów. Wszystko, co pozwala trzymać dzienniki z dala od miliardów przypadkowych skanów drive-by przez dzieciaków ze skryptów, oznacza, że ​​możesz skupić się na bardziej celowych atakach. Jeśli Twoje niestandardowe nazwy pojawiają się w dziennikach nieudanego logowania, wiesz, że to poważna próba zalogowania się, a nie jazda.
Dewi Morgan
11

Aby zalogować się do komputera, musisz znać zarówno nazwę użytkownika, jak i hasło.

/etc/passwd dostarcza informacji o użytkownikach, co daje połowę potrzebnych informacji i wykorzystanych do włączenia skrótu hasła.

Skrót jest czymś obliczonym na podstawie hasła. Trudno jest znaleźć hasło z skrótu, ale nie na odwrót. Jeśli masz jedno i drugie, możesz spróbować brutalnej próby znalezienia hasła offline, a następnie spróbuj połączyć się z komputerem dopiero po jego znalezieniu.

Dzisiaj poprawiono bezpieczeństwo, ponieważ skróty są przechowywane w innym pliku, /etc/shadowktóry domyślnie nie jest czytelny dla większości użytkowników.

Ale gdybym miał dostęp do obu /etc/passwdi /etc/shadowprawdopodobnie mógłbym znaleźć twoje hasło za pomocą ataku „słownikowego” brutalnej siły. Ponieważ mogę to zrobić lokalnie na moim komputerze, nie zauważysz wielu nieudanych prób znalezienia twojego hasła i będę musiał ponownie połączyć się z twoim komputerem, gdy tylko poznam hasło. Mogę wtedy robić, co chcę.

Więcej informacji znajduje się tutaj na Wikipedii

Warren Hill
źródło
Wygląda na to, że powinieneś wspomnieć tutaj o „tęczowych stołach”, aby dać pojęcie o tym, jak działa ten atak brutalnej siły.
Rick Chatham