TP-Link TL-WR940N: 1-days analysis after story. (CVE-2022-43636 & CVE-2022-43635)
After finished my 1-days analysis, I’ve looked into other function of the web service binary and found a funny bug in the authenticate process.
I/ Login Process
Before we talk about the bug, let’s have a look at the communication between client and device.
As you can see above is the simple flow chart of login sequence. First, the client send a request for RSA key and receive a json contain RSA public key (n,e) and a random number (seq). After that, the client will send a login.json file which contain encrypted login information to device.
Before we continue, I would like to explain how this login.json was created. Let’s start with the “data” first. This “data” is the encrypted AES of a json {"name" : "admin", "password" : user’s password}. The AES key and iv were random generated by client and stored in “sign”. The “sign” is a string contain AES key&iv, md5 hash of username and password (md5(“admin” + user’s password)), and a number which is sum of seq and data length. The “sign” plaintext will look like this:
“key=1649299909049523&iv=1649299909049903&h=21232f297a57a5a743894a0e4a801fc3&s=15485”.
This “sign” will be encrypted using public RSA key that client receive from device.
After receive login.json from client, device will decrypt “sign” to get AES key&iv then use it to decrypt “data”. If the username and password is correct, the device will save AES key&iv, set Authorization cookie = seq and send valid session ID back to client.
Finally, with the session ID, client will redirect user to device’s Index.htm.
II/ The bug
The login sequence is pretty secure. However, look like the dev has made a mistake during coding:
The idea is if the username and password is correct, function AuthPass() will set Authorization cookie = seq and return. After that, json file contain valid session ID is created and sent back to client. On the other hand, the process just quit as the username and password is incorrect. In reality, since AuthPass() always return 0, I can easily get a valid session ID just by send a login request. Of course, without the correct password, our seq number can’t be set as Authorization cookie, so I can’t login into device. However, previous session’s Authorization cookie is still in the memory (Session ID can be expired or delete when user click “logout” button but Authorization cookie won’t) and can only be replaced by another successful login that overwrite the previous seq. Moreover, seq is a random number with 3-5 digits so it isn’t too hard for brute-force. With the correct seq number, I can easily extract any config information on the router. Of course, the response’s variables like the Wifi ssid or password was encrypted with AES. But the device is using AES key&iv from my login request instead of previous login session, so the decryption is not a problem.
Also, I found out that both Backup & Restore feature and Firmware Upgrade feature only check session ID and Authorization cookie, so attacker can use these functions to change the router config or downgrade firmware version for further exploit.
