Great exploit chain starts with a newline injection, leading to the ability to write “2” to any file culminating in a login and root code execution, all doable with remotely hosted javascript.

Uncontrolled File Write

You can read a bit more about the authentication system in the “Draconian Fear” vulnerability report, but for here what matters is that when a new login comes in the username, password and some other information like where to write the results to are written to a file with newline separating each field. Then another program is signaled to process the new login and it writes the results out.

The first problem in this chain being that a newline might be part of the username or password and that breaks program that processes the login. By injecting your own newline you can take control of the file where the results will be written. While the attacker can write any file, the contents of that file will be based on the results of the login, so “2” for a bad login, “3” for too many failed attempts.

Session Validation

While the file contents are pretty limited, due to some unchecked issues while parsing “2” will read as a valid session file. This is because the parsing of the file calls fscanf("%d\n%u\n%u\n%u\n%u\n%s\n%d\n") to read everything but does not check the return value to ensure enough data was actually read. This leaves most fields with their inital “0” value.

In order to write the session file though you need to know what file is used for your session, the session file is based on an encrypted value sent in the X-CSRF-XSID header. Fortunately for the attacker, when the decryption of that header fails, the return value is never checked and the value remains blank, and the file /var/tmp/sess/login_http_ will be used without any session id on the end.

The last challenge to getting the fake session accepted is that the session creation time will be 0 which will generally be considered too old of a session and rejected due to age. The session creation time is based on the seconds since last rebook, so getting the device to reboot and then performing this attack will result in a valid session

Reboot Denial of Service Attack

Using the prior attack one could target three sysctl files to enable crashing when out of memory:

• /proc/sys/vm/panic_on_oom
• /proc/sys/kernel/panic
• /proc/sys/kernel/panic_on_oops

Then to cause the device to run out of memory, simply performing a file upload against any endpoint will result in the file being written to a location that is backed by RAM. After the reboot the fake session will be considered valid and the attack will be authenticated against the device.

Code Injection

Once logged in the diag_traceroute method in set.cgi is vulnerable to trivial shell injection through the hostname field However it is worth mentioning that though this is a bug, code execution isn’t exactly a privilege escalation in this case as an attacker could legitimately perform other actions that would result in code execution like changing out teh firmware on the device.