Na zajęciach z bezpieczeństwa IT chcę pokazać uczniom eskalację uprawnień. Aby to zrobić, przejrzałem exploit/linux/local
listę w Metasploit Framework, znajdując (między innymi) exploit/linux/local/sock_sendpage
od sierpnia 2009 roku.
Skonfigurowałem maszynę wirtualną z 32-bitowym Ubuntu Server 9.04 ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) od kwietnia 2009. uname -r
Daje mi 2.6.28-11-generic
. Zgodnie z opisem exploita
Uważa się, że dotyczy to wszystkich wersji systemu Linux 2.4 / 2.6 od maja 2001 r .: 2.4.4 do wersji 2.4.37.4 włącznie; 2.6.0 do 2.6.30.4 włącznie
Wydaje się więc, że skonfigurowany przeze mnie serwer Ubuntu powinien nadawać się do demonstracji. Nie udało mi się jednak uruchomić go.
Dodałem (zwykłego) użytkownika na serwerze i działa dostęp do SSH. Z poziomu Metasploit Framework mogę utworzyć sesję SSH przy użyciu auxiliary/scanner/ssh/ssh_login
. Jednak kiedy uruchamiam exploita, otrzymuję
[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)
[*] Exploit completed, but no session was created.
Nie otrzymuję żadnych dalszych informacji, nawet jeśli ustawię wartość DEBUG_EXPLOIT
true. /tmp
jest zapisywalny, również z sesji SSH Metasploit:
$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])
$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])
total 0
-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt
Próbowałem też ustawić WriteableDir
katalog domowy użytkownika na serwerze, ale bez żadnych zmian. Czego tu brakuje? Czy ta wersja serwera Ubuntu (której celowo nie zaktualizowałem!) Nie jest zagrożona?
źródło
Odpowiedzi:
Wydanie 9.04 było obsługiwane do 23 października 2010 r. Znaleziona luka została zgłoszona w sierpniu 2009 r. Wydaje się uzasadnione, że ponieważ wydanie było wciąż aktualne i obsługiwane w tym czasie, ISO zostało załatane, a pobrana wersja była wersją, która jest nie jest już wrażliwy.
Co więcej, wydajesz się całkiem ładnie wykazać, że nie jest wrażliwy. W końcu próbowałeś wykorzystać exploita i wygląda na to, że się nie udało.
Dlaczego nie spróbujesz nowszego exploita? Coś takiego jak CVE-2013-2094, który powinien również wpłynąć na przykład na Ubuntu .
źródło
pkexec
exploit, czy sprawdziłeś wersjęlibpolkit-backend-1
? Strona, do której prowadzi link, stwierdza, że podatność wymaga wersji starszej niż0.94-1ubuntu1.1
.dpkg -s libpolkit2
zainstalowaną wersją jest0.9-2ubuntu1
.To nie odpowiada na konkretne zapytanie, a raczej daje więcej możliwości prywatnego wyboru, aby pokazać uczniom ...
Możesz także rozważyć dwie następujące konfiguracje administratora, które mogą prowadzić do esc esc na 'nix (istnieje wiele innych sposobów na pominięcie konfiguracji skrzynki' nix, która może zezwalać na esc esc, więc rozważ to zaostrzenie apetytu) …
pliki binarne suid i guid będące własnością root / root group (
find / -uid 0 -perm -4000 -type f 2>/dev/null
ifind / -uid 0 -perm -2000 -type f 2>/dev/null
) i sprawdź, czy można je zapisywać na całym świecie, aby umożliwić użytkownikom o niskich uprawnieniach ich zmianę; folder, w którym się znajdują, jest zapisywalny przez użytkownika o niskich uprawnieniach - w celu ewentualnego wstrzyknięcia ścieżki biblioteki. Co z bibliotekami, których używają - czy można je zmienić: sprawdź wartości dowolnychDT_RPATH
iDT_RUNPATH
nagłówków ELF w plikach binarnych za pomocą jednego z następujących poleceń:objdump -x
...readelf -a
...scanelf
(z PaX)elfdump
(od Słońca)readelf -a binary | grep PATH
sudoers
wadyNOPASSWD
- Lokalny atakujący może użyć tego dostępu do zwiększenia swoich uprawnień w systemie operacyjnym, gdy użytkownik zapomni zablokować ekranBrak plików wykonywalnych w Sudoers - Niektóre pliki wykonywalne w
/etc/sudoers
pliku nie istnieją. Jeśli pliki wykonywalne są tworzone, można je uruchamiać za pomocą sudo jako root, co pozwoliłoby na zwiększenie uprawnień.Osierocone wpisy sudoers -
/etc/sudoers
plik może zawierać wiele osieroconych wpisów, dla których nie ma w nim odpowiedniego konta/etc/passwd
. Jeśli użytkownik został utworzony z jedną z osieroconych nazw, zapewniłby mu to możliwość zwiększenia uprawnień do pełnego dostępu do konta root.Niektóre programy nie powinny być w stylu sudo
vi
, używać:e
lub Ctrl o używać:w
do uzyskiwania dostępu/etc/shadow
.Niepoprawnie przemyślane / złe polecenie użyte w pliku sudoers - często widuję
httpd
w sudoers - więc spróbuj jako użytkownik o niskim poziomie uprawnień z dostępem sudo, aby uruchomić tylko to polecenie (sudo -l
lubsudo -ll
pokaże, co użytkownik może zrobić):sudo /usr/bin/httpd -t /etc/shadow
i spójrz na błąd.perms plików poleceń i plików wymienionych w sudoers są słabe - zobacz mój wcześniejszy akapit na temat plików binarnych suid i guid będących własnością root
źródło