[ CVE-2022-40602 ] ZyXEL LTE3301-M209 - "Backdoor" credentials

Hi Folks,

as a continuation from the previous post, we're going to take a look at ZyXEL LTE3301-M209.

[!] Togheter with Zyxel PSIRT, we decided not to reveal the credentials. In addition, due to the impact it may have, some steps are skipped.

 

The telnet "backdoor" is not limited to the D-Link DWR-921 and seems to be present on the ZyXEL LTE3301-M209 as well. 

FW version: 20191202 V1.00(ABLG.4)C0 

MD5:8A2C093431456BFDC8D3DD0403EC1632

Same speech, let's go straight to the commander elf, as seen in the previous post:

commander elf from ZyXEL fw

 
same amit* functions, same producer means same backdoor?! Not really.

In the first case, since having the D-Link phisically, I had a chance by rdcsman tool to read the password from the device. I now have no phisical access to the device and I have to dig the password out from the config.

The firmware is basically a merge of 3 sections, the LZMA section is the kernel, at  0x148CD6 the root-fs and at  0x90BD36 the www content.

Inside the last Squashfs there is a [censored] file which is contains at 0x10 the Zlib magic bytes.

To unpack the file you can use openssl or zlib-flate in unix or alternatively transform the zlib into a gzip file in windows and make it readable by 7zip.

Going brutally down by strings there is no one good telnet password however....

WebUI Credentials

An interesting sequence appeared: username / WebUIFakePassword .

By looking at telnet creds I've actually landed on something which looks like a backdoor in the webUI!!

[few steps are hidden]

Same as before and unpack the config.dat is going to contain the telnet login password: "TelnetFakePassword"

Let's put things togheter:
On ZyXEL LTE3301 we have two ways to own the device:

1) webUI credentials --> username / WebUIFakePassword

2) telnet credentials  --> root / TelnetFakePassword

An additional note: from what i see, telnet password is not included in the reset.dat so, if rewritten, it may remain permanently modified regardless of reset.

Upgrade your device with the latest firmware ASAP! 

History:
12 Sep 2022: Vulnerability reported to ZyXEL

13 Sep 2022: ZyXEL asks for detail in order to replicate the vulnerability.
13 Sep 2022: Details sent to ZyXEL.

14 Sep 2022: ZyXEL confirm that the issues only affect the LTE3301-M209 model. They're working to the vendor to fix it. They asks to keep information confidential until patch has released.
17 Sep 2022: Waiting for the patch.

19 Oct 2022: The issue is now tracked by CVE-2022-40602
22 Nov 2022: ZyXEL's security bullettin published. Firmware fix has been released. 

24 Dec 2022 Hopefully users has now updated their own devices, It's time to make my blog post public.

Cheers!
RE-Solver

[D-Link DWR-921 | DWR-925 | DWR-118 ] Hardcoded backdoor implemented by vendor

Hi Folks,

I owned a D-Link DWR-921 HW:C3 with OpenWRT, but once no longer in use I decided to put the stock firmware back and as consequence the need to have a console root access. 😁

This device has been probably made by AMIT Enabling Wireless M2M-IoT - amit.com.tw

[!] Due to the impact it may have, credentials are hidden.

The FW image itself is basically standard, except for the squashfs header, which are in a non standard format and the unpack fails, no matter which tool you're gonna use.
By hand-made analysis, a pretty easy header portion swap has restored the structure. *Ask me on comments below or twitter if you wanna know more about that topic.*

My mainly goal was to get a console, telnet or ssh, or whatever.

 

Keep in mind: The /etc/passwd file has the login credentials for root with this encoded password:

root:$1$$N76hdwGfg11g0KdKbtyh21:0:0:root:/root:/bin/ash

 

A quick online search and the corresponding plaintext password is: amittima (the productor name palindromized: Amit Company)
Good to know, but not very useful at the moment, since there is no remote console available.

I started out with the belief that I had to find a controllable variable for a quick code injection, I would not have expected such a blatant backdoor nowdays.
A brief check on rcS to get an idea of how the boot process is structured, and a quick shoot with Ghidra on httpd and commander ELFs.
Among all the strings in httpd, "telnetd -b 0.0.0.0" was the most interesting one.
A picture speaks more than a thousand words.

httpd

 

Yes, a GET request at the url http://ipmodem/atsq.txt cause the system call which starts the telnetd process on all interfaces. Yeah, all interfaces, WAN included. {facepalm}

Telnet service is up and running, but with the root/amittima tuple won't allow us to login.
In a few forums other users wrote they were unable to login as well

Serial console is enable by default on router serial, so I took the advantage with a USB-TTL interface to give a check on the passwd file:

# cat /ram/etc/passwd
root:$1$$taSOMETHINGYOUHAVENOTTOKNOWJ41:0:0:root:/root:/bin/ash
nobody:$1$$qRPK7m23GJusamGpoGLby/:99:99:nobody:/var/usb:/sbin/nologin
ftp:$1$$qRPK7m23GJusamGpoGLby/:14:50:FTP USER:/var/usb:/sbin/nologin 

The password must be overwritten by some process during the boot.
The /sbin/commander ELF is the only which contains "/etc/passwd" in the strings and has a file write attribute to that file.

commander

Router settings in the flash are managed by csman and the root password is going to be ridden by csman and then encrypted by standard crypt(...) call.
Empty salt "$1$" confirmed already in the passwd file.
rdcsman is the console application included into the firmware to read variables into the config mtd partition structured in a way which I want to ignore.

 #  rdcsman 0x1 str
DLinkPassword

Put things togheter:

1) turn on the telnet: a GET request to routerip/atsq.txt (a browser is fine)
2) root credentials are: root/DLinkPassword

  And that's it, we're in!

telnet

 

But, wait a sec... what if I search for RT305XL on shodan? I hopfully expect zero results but there are several of them.

Bonus: 

D-Link  DWR-925 telnet access --> root / DLinkPassword2

D-Link  DWR-118 telnet access --> root / DLinkPassword

History:
12 Sep 2022: Vulnerability reported to D-Link

19 Sep 2022: No response, 2nd warning through email sent. 

27 Sep 2022: D-Link has released a security bullettin. But they're not going to fix the backdoor.

Cheers!
RE-Solver