Poważna luka w domyślnych ustawieniach pam.d Ubuntu
pam.d, czyli Pluggable Authentication Modules to zestaw bibliotek odpowiedzialnych za zarządzanie uwierzytelnianiem usług w systemie Linux. Dzięki niemu przydzielane są odpowiednie uprawnienia dla procesów potomnych sshd czy sposób zarządzania uprawnieniami po zmianie użytkownika poleceniem su.
Dość dawno temu pisałem o fork bomb. Dziś postanowiłem sprawdzić, jak zareaguje mój system na forkbomba. Ustawiłem restrykcyjne zabezpieczenia poprzez /etc/security/limits.conf, zalogowałem się poprzez ssh na nieupoważnionego do wykonywania zmian użytkownika i wykonałem niszczycielską komendę. System przetrwał :-). Zadowolony udałem się na spoczynek, jednak przypomniałem sobie o pewnym kruczku.
Powtórzyłem moje działania, logując sie jednak poprzez komendę "su" na wybranego użytkownika... I zwiesiłem system..
System Ubuntu w domyślnej konfiguracji posiada źle skonfigurowany plik /etc/pam.d/su !
Pozwala to na obejście wszystkich limitów zawartych w pliku /etc/security/limits.conf. Wystarczy, że użytkownik naszego teoretycznie zabezpieczonego serwera wykorzysta po zalogowaniu się komendę "su" omijając w ten sposób nasze misternie skonstruowane limity. Niezabezpieczenie się na tak prosty atak może być fatalne w skutkach dla naszego systemu.
Oto krótki pokaz, w jaki sposób obejść zabezpieczenia systemu Ubuntu.
haxor_pwned@omega:~$ groups haxor_pwned serwer haxor_pwned@omega:~$ ulimit -u 10
Użytkownik nie posiada żadnych uprawnień grupowych i należy do grupy "serwer", która narzuca limit 10 procesów.
Załóżmy, że użytkownik haxor_pwned ma kolegę (niech się nazywa gorion, a co mi tam:P:P), który na naszym serwerze posiada konto o mniejszych ograniczeniach (dla przykładu - 20 procesów).
gorion@omega:~$ groups gorion serwer2 gorion@omega:~$ ulimit -u 20
Jak widzimy, gorion należy do grupy serwer2, której limit został ustalony na 20 procesów. Przeprowadźmy zatem "atak".
Haxor przekazuje hasło naszemu gorionowi, ten loguje się na konto Haxora i...
gorion@omega:~$ su haxor_pwned Password: haxor_pwned@omega:/home/testowy2$ groups haxor_pwned serwer haxor_pwned@omega:/home/testowy2$ ulimit -u 20
Haxor należący do grupy o mniejszych uprawnieniach posiada uprawnienia konta, z którego nastąpiło przelogowanie! Prawie jak w TVN...
Żarty na bok - to poważna luka w zabezpieczeniach i nie mam zielonego pojęcia, czemu Canonical umożliwia tak nierestrykcyjną politykę pam.d!
Jak się zabezpieczyć? Wszystkiemu winny jest plik:
# vi /etc/pam.d/su
W którym musimy dodać poniższą linijkę.
session required pam_limits.so
Od kolejnego zalogowania nasz system zabezpieczeń zacznie działać poprawnie... Wreszcie...
Powyższy artykuł ma na celu ujawnienie problemu i próbę załatania błędu w systemie, nie jest on pokazem umiejętności "hakerskich" ani HowTo "jak skrakować koledze serwera". Polecam sprawdzenie Waszych plików konfiguracyjnych, bo jak widać nie zawsze zabezpieczony = bezpieczny.
Dlatego, konta z dostępem do shell'a to rozpasanie userów. Spędzają ( userzy ) adminom sen z oczu po poobiedniej drzemce.
Hm, w fesity ta linijka jest już w podanym przez ciebie pliku, ale jest zachaszowana/zahaszowana - nie wiem jak się to pisze :) Mam ją od..aszować?
Poważna luka w bezpieczeństwie - chyba troche przesadzasz.
Jeśli poważna luka w bezpieczeństwie polega na przekazaniu hasła, a zdobywca tegoż jedyne co może to uruchomić więcej procesów, to nie jest żadna nowoodkryta poważna luka, a tylko znana od dawna podstawowa i najpoważniejsza luka w bezpieczeństwie wszystkich systemów: użytkownik.
Współpraca uprawnionego do logowania użytkownika (nawet takiego bez dużych uprawnień, a Ty przedstawiasz przypadek odwrotny) to połowa sukcesu w każdym ew. włamaniu.
Nigdy nie lubiłem pam.
Powieszę się, gdy Patrick zaimplementuje pam w slacku. Ale, znając jego podejście, na szczęście tego prawdopodobnie nie zrobi.
Może i przesadzam - zawsze najsłabszym ogniwem wszystkim systemów komputerowych jest człowiek. Nie ma jednak wątpliwości, że to niedopatrzenie ze strony Canonical jest poważne i powinni oni coś z tym zrobić.
Moim zdaniem, to nie wygląda na błąd, wręcz przeciwnie, celowe działanie.
Dlaczego użytkownik, który ma większe uprawnienia, miałby mieć nagle pomniejszone, przez sam fakt, że robi su na innego?
Twoje 'rozwiązanie' sprawia, że będąc rootem i robiąc su na dowolnego użytkownika, mamy takie ograniczenia jak i ów użytkownik. Ja takiej funkcjonalności osobiście nie chciałbym.
Podsumowując, imho, dla mnie powinno być tak jak jest domyślnie.
dopisane: P.S. wartałoby wspomnieć, kto jest autorem tamtej forkbomby, nie uważasz?
@GiM - Po co wykonywać su z roota, skoro root ma te same uprawnienia co wszyscy użytkownicy razem wzięci? Su wykonane z roota jest samo w sobie niebezpieczne, lepiej już wykonać "login" i zalogować się na innego użytkownika. Mnożenie sobie sesji w terminalu nie jest dobrym przyzwyczajeniem.
Ten typ "ataku" wykorzystywany jest bardzo często - uzyskanie uprawnień użytkownika "wyższego rangą" na użytkowniku o niższym statusie. Eskalacja uprawnień. I to jest niebezpieczne.
1) Wytłumacz mi, bo chyba nie rozumiem, jakie niebezpieczeństwa związane są z robieniem su, na użytkownika, którego TYLKO JA używam?
2) O jakiej eskalacji uprawnień ty mówisz? Nie można tu mówić o eskalacji uprawnień, to że użytkownik ma 'wieksze/szersze' uprawnienia, jest tylko kwestią tego, że MIAŁ większe/szersze uprawnienia jako INNY UZYTKOWNIK do którego konta miał dostęp! To nie jest eskalacja uprawnień.
Gorion@omega? uuuu Uważaj bo ściągniesz jego gniew na siebie, a wtedy biaga Tobie ;-)
O_o
o_O
o_o
o_o'
A gdzie dziura?
Nie rozumiem w czym problem: przecież to gorion będzie odpalał te 20 procesów, nie haxor...
A jak po twojej zmianie się zachowuje su na użytkownika z konta roota? Może się okazać, że będzie niemożliwe, bo użytkownik docelowy wyczerpał limity (nie wiem jak to działa, zgaduję). A su -l działa inaczej?