We sometimes require internet connectivity in situations where a traditional connection is not easily possible. 4G routers provide an answer to this problem by providing connectivity to a variety of devices and systems without the need for a fixed internet connection. They typically have one thing in common – a web based management interface.
The dangers of exposing such interfaces to the public are well known and yet it’s regularly done. There are many reasons for this, but in the case of 4G routers, practicality is a large factor. Managing a device is easiest to do remotely after all. To account for this, default credentials are typically (and hopefully) swapped for obscure usernames and strong passwords, and IP address black or white listing is a common feature. Further restrictions and access controls for these interfaces are always recommended but a quick search on Google will demonstrate that this is not always the case.
This post discusses a vulnerability discovered by Nettitude which existed in the latest firmware in a series of Teltonika routers. Nettitude contacted the manufacturer and new firmware to patch the issue is now available. It is highly advised that any vulnerable devices are brought up to date with the latest firmware as soon as possible due to the nature of the vulnerability and ease of exploitation.
What is CVE-2017-8116?
CVE-2017-8116 is an unauthenticated remote command execution vulnerability which is performed as root on the remote router. All that is required for exploitation is access to the web based management interface (LuCI) and a device operating Teltonika RUT9XX firmware <= version 00.03.265.
The routers known to be affected by this issue are Teltonika RUT900, RUT905, RUT950 and RUT955.
The firmware is based off OpenWRT and the source code is provided by Teltonika on their website under the GNU General Public Licence (“GPL”).
The management interface for the Teltonika routers, known as LuCI, is part of OpenWRT and built from the LUA programming language. However, the source code for LuCI found in the Teltonika routers has been modified to suit the requirements of the manufacturer. The vulnerability discovered in this interface exists due to ineffective sanitisation of user input. This includes input provided on the login page of the management interface.
The source of this issue…
One of the files, named sysauth.htm, that users interact with when accessing the login page for the management interface, can be found in the source code bundle and is in the screenshot below. The following images are taken from the source code from firmware version 00.03.143 which, at the time of writing, is publicly available from Teltonika’s website.
As can be seen at the top of this image, the sysauth page utilises a number of resources. One such resource is a LUA file called dispatcher.lua (highlighted in the screenshot above). When a user attempts login, the dispatcher.lua file handles part of the event by logging various information such as the time of the event, the source IP address and the username which was submitted. Does anything look a little suspicious in the line highlighted below?
The user variable contains the input from the username field provided by the user when submitting the login request. Additionally, it looks like we are calling /usr/bin/logger directly and passing user controlled input to it. Let’s have a closer look at the function sys.exec().
As can be seen above, ultimately, the user input is being supplied directly to the system shell. Exploitation of this issue is performed by breaking out of the expected command and then supplying our own command to be executed.
A partial fix?
Interestingly, somewhere in the development history of this firmware, the source code changed to include some sanitisation of specific characters. The firmware that was shipped with our device was 00.02.419 and did not appear to include any sanitisation. However, in the next version of source code found, 00.02.700, the following function is visible, indicating that this issue was identified within this firmware in the past.
Some characters which can be used for command injection attacks have been filtered here, but not all. Most importantly, redirection for input and output are still accepted in the username field. In older firmware versions, breakout was possible by simply issuing the desired command between two tick characters within the username field. However, in newer versions exploitation requires the use of redirection characters.
Exploits old and new
For a proof of concept, we can simply issue a command and output the response into file that we have access to. As this is a web service, outputting the result into a file on the web root directory can allow us to view the file by simply browsing to it. The following is a screenshot of exploitation on an older version of the firmware.
As the newer versions filter tick characters, instead we can use redirection to gain command execution on the device. After issuing the command, a new file is created in the root of the website as before. However, as the ticks have been filtered, there is nothing currently controlling the end of our command and, as such, the output gets placed into a file, the name of which contains the left over text.
To fully control the filename and end the command in the expected place, a linefeed character can be used to end the command. This can be sent via URL encoding %0A to the web service. Once executed, the expected output is available from the specified filename as it was with the exploit using the ticks which worked against the older firmware versions.
Be proactive
Exploitation of this issue is very stable, extremely easy and can be used to add users to the device, tap network traffic, modify iptables rules and far more. Unfortunately, these routers contain strings which make it no problem at all to fingerprint with search engines (deliberately not discussed). Pages of results can be found through a quick Google search at the time of writing. If these devices are being utilised by your organisation, it is highly recommended that the latest firmware is installed as soon as possible. It is highly likely that this attack will be searched for and exploited automatically in the near future.
Metasploit Modules
Nettitude has developed two Metasploit modules for identification and exploitation of this vulnerability:
- https://github.com/nettitude/metasploit-modules/blob/master/teltonika_cmd_exec.rb
- https://github.com/nettitude/metasploit-modules/blob/master/teltonika_add_user.rb
Disclosure timeline
- Nettitude contacted Teltonika: 20/04/2017
- Second attempt at contact: 24/04/2017
- Initial response from Teltonika: 25/04/2017
- Provided further details to Teltonika: 26/04/2017
- Teltonika acknowledged and distributed fix: 04/05/2017
- Public disclosure: 20/06/2017
