Krótko wprowadzając, dystrybucja Trixbox to system, który z założenia ma pełnić funkcje centrali telefonicznej (za pomocą oprogramowania centrali o otwartym kodzie źródłowym Asterisk). Choć sama dystrybucja zasadniczo jest instalowana na maszynach w sieciach wewnętrznych, niedostępnych bezpośrednio z sieci Internet to do napisania niniejszej wiadomości skłoniło mnie opublikowanie błędu umożliwiającego uzyskanie uprawnień administratora (root) poprzez główny panel zarządzający całym systemem (WWW). Przyglądając się uważniej samemu błędowi okazało się, że w dystrybucji Trixbox zachodzi szereg małych błędów, które po odpowiednim zebraniu w całość umożliwiają całkowite przejęcie maszyny. Gdyby którykolwiek z kroków był skonstruowany bardziej bezpiecznie – atak by się nie powiódł. Poniżej przeprowadzę krótką analizę tego ciekawego w mojej opinii błędu.
Pierwsza część błędu znajduje się w aplikacji WWW odpowiedzialnej za zarządzanie systemem. Istnieje możliwość przemycenia do zmiennej langChoice, wysłanej za pomocą metody POST, wartości innej niż zakłada aplikacja. Wadliwy kod wygląda w ten sposób:
if(isset($_POST[’langChoice’])){ $langChoice = $_POST[’langChoice’];
$_SESSION[’trixbox_Language’] = $langChoice;
$language = $_SESSION[’trixbox_Language’];
czyli zmiennej $language przyporządkowane są dane z $_POST[’langChoice’], na którą mamy bezpośredni wpływ. Główny problem znajduje się w:
include(’modules/’.$value.’/language/’.$language.’.php’);
Wysyłając do serwera zmienną langChoice w postaci: langChoice=../../../../../../../../../../etc/passwd%00 doprowadzamy do tego, że mamy możliwość wykonania ataku LFI (Local File Include) i załączenia pliku (w tym wypadku /etc/passwd) znajdującego się na atakowanym serwerze. Co ważne do ataku wykorzystujemy przekazanie znaku %00 (null byte), którego zadaniem jest przerwanie przetwarzania danych tak aby znajdujące się na końcu linii .php zostało zignorowane. W ten sposób zostaje zaincludowany (załączony) plik:
modules/$value/language/../../../../../../../../../../etc/passwd
Aby działała sztuczka ze znakiem %00 musimy posiadać wersję PHP nie odporną na tego typu atak. W dystrybucji Trixbox akurat z taką mamy do czynienia. Dodatkowo ustawienia PHP muszą umożliwiać nam wykonanie powyższych akcji – akurat w wypadku Trixboxa – umożliwiają.
Mamy więc możliwość uruchomienia lokalnego kodu PHP z uprawnieniami serwera WWW. Jednak kodu znajdującego się jedynie na serwerze Trixbox. I tutaj osoba, która znalazła błąd wykazała się pomysłowością godną gościa od bajki z zaczarowanym ołówkiem. Dane sesyjne w PHP są przechowywane w katalogu w plikach sess_$tutajunikalneID. Oczywiście wszystko zależy od konfiguracji PHP. W przypadku Trixboxa, dane te są umieszczane w katalogu /tmp/.
Trik polega na przesłaniu danych sesyjnych, które zawierać będą złośliwy kod (choćby uruchomienie dowolnej komendy). Dane te – zostaną zapisane w pliku /tmp/sess_$idsesji. $idsesji jest nam znane. W związku z tym wracając do naszego początkowego błędu, załączamy plik znajdujący się lokalnie na serwerze langChoice=../../../../../../../../../../tmp/sess_$phpsessionid%00, a w nim znajdują się uprzednio przesłane dane.
Mamy więc możliwość zdalnie, wysłania dowolnego kodu, który następnie zostanie uruchomiony z uprawnieniami użytkownika serwera WWW.
Idąc dalej – podczas instalacji systemu Trixbox, do pliku systemowego /etc/sudoers dodawane są następujące linijki:
asterisk ALL = NOPASSWD: /sbin/shutdown
asterisk ALL = NOPASSWD: /usr/bin/nmap
asterisk ALL = NOPASSWD: /usr/bin/yum
asterisk ALL = NOPASSWD: /bin/chown
asterisk ALL = NOPASSWD: /bin/chmod
asterisk ALL = NOPASSWD: /bin/touch
asterisk ALL = NOPASSWD: /sbin/service
asterisk ALL = NOPASSWD: /sbin/init
asterisk ALL = NOPASSWD: /sbin/route
asterisk ALL = NOPASSWD: /bin/hostname
asterisk ALL = NOPASSWD: /bin/ln
asterisk ALL = NOPASSWD: /bin/bash
Oznaczają one tyle, że użytkownik asterisk będzie posiadał uprawnienia do uruchamiania powyższych poleceń z uprawnieniami administratora (poprzez systemowy wrapper sudo). Najciekawsza jest tutaj ostatnia linijka, która oznacza tyle, że zalogowany jako użytkownik asterisk (użytkownik centralki telefonicznej) możemy uruchomić powłokę /bin/bash z uprawnieniami administratora (bez podawania nawet swojego hasła). Ten błąd jest przykładem – jak nie ułatwiać sobie pracy, gdyż może mieć to bezpośredni wpływ na bezpieczeństwo systemu czy aplikacji.
Znów reasumując. Wysyłamy zdalny kod na serwer, załączamy go do interpretera PHP i uruchamiamy. Za pomocą komendy: sudo /bin/bash uzyskujemy uprawnienia administratora [oklaski]!!!
Spostrzegawczy czytelnik od razu zauważy, że coś tutaj jest nie tak. Zwyczajowo serwer WWW uruchamiany jest z uprawnieniami użytkownika apache/nobody/www. A wpis w pliku /etc/sudoers jasno pokazuje, że komendę /bin/bash, może uruchomić jedynie użytkownik asterisk.
Jednak przyglądając się bardziej szczegółowo konfiguracji serwera WWW:
egrep -i „^User|^Group” httpd.conf
User asterisk
Group asterisk
okazuje się, że w systemie Trixbox – serwer WWW uruchamiany jest z uprawnieniami użytkownika asterisk!!! Kolejna mała dyrektywa mająca tak drastyczne znaczenie. Błąd, błędy, błędami pogania.
W sumie tyle :} Mała, krótka analiza. Szereg zależności. Wiele możliwości. A na koniec całkowite przejęcie systemu. Zakończenie ma być proste – pamiętajcie, każdy nawet najdrobniejszy błąd – MA ZNACZENIE. Kropka…