TP-Link WA901N Vulnerability - Brute force management interface password via SSH service

This post contains detailed information about a security research that i have been conducting on a TP-Link WA901N router. The vulnerability was disclosed, confirmed and fixed by TP-Link before this post was created.

Intro

Following the research I started in a PREVIOUS POST, I discovered a vulnerability in the TP-Link WA901N router that allows an attacker to brute force the management interface password via the exposed SSH service. The SSH service is available, but is not configured so it cannot be used to access the device, and for some odd reason not only it shares the same password as the management web interface but also, when performing an authentication it only checks for the password, accepting any given user! This makes it extremely easy for an attacker, already in the network, to brute force the management password and get full control over the router.

This vulnerability is specially dangerous since it bypasses the security mechanism implemented by TP-Link in the web interface, which locks it for 2 hours after 10 failed attempts.

• Affected firmware: 3.16.9 Build 200703 (and inferior)
• Fixed firmware: 3.16.9 Build 220701 (available HERE

History

• 26/05/2022 - Vulnerabilty disclosed to TP-LINK.
• 22/05/2022 - TP-LINK sent a beta version firmware so I could test and confirm the vulnerability was fixed.
• 23/05/2022 - I confirmed the vulnerability was fixed in the beta version firmware.
• 04/07/2022 - TP-Link uploaded the new firmware - available HERE
• 04/07/2022 - CVE-ID requested

Vulnerability

After I got access to the router internal system I started doing some reconnaissance by firing nmap and performing a quick scan to see that what interfaces this device was exposed.

The SSH port is exposed which I was able to confirm by viewing the router running processes.

Going to /proc/430/cmdline I was able to see the full command that was issued to start the dropbear service

    /usr/bin/dropbear -p 22 -r/tmp/dropbear/dropbear_rsa_host_key -d/tmp/dropbear/dropbear_dss_host_key -A/tmp/dropbear/dropbearpwd

I went to the /tmp/dropbear folder and got the content of the dropbearpwd file

So, with that hash I went to crackstation in order to see if that was a known hash.

Not only I got a hit in crackstation but also, the password “test123” was the same password that I had set to access to management interface when I first set up the router… Trying it out I was able to confirm that this password was accepted but no shell was given.

After some research I found that the dropbear service was not configured so that was the reason I was not getting a shell, but I also found that this service was only checking for the given password and completely ignoring the username. Testing it with Hydra I confirmed it.

TP-Link went to all the trouble of implementing a lock down of 2 hours in the web interface after 10 failed attempts to prevent brute force attacks and this vulnerability completely bypasses that security mechanism.

I have also done a sanity check, where I changed the password in the management interface and I was able to confirm that the hash in the dropbearpwd file changed accordingly. This means an attacker on the same network can use this service (that for some reason is exposed although not configured) to brute force the management interface password (available on 192.168.0.254) in order to get full control over the device.

Patch notes

TP-Link fixed this issue by locking the SSH service for 120 minutes after 10 failed attempts.

Although this patch kind of fix the issue, since the SSH service is not even being used (apparently… need to investigate more) I would have liked to see it removed instead, but that is just my humble opinion.