Jay documents a low-severity vulnerability in the RUT-240
Debugging an issue with the RUT-240 in bridge mode
Update 20230519: The vulnerability described here has been assigned CVE-2023-31728, and is fixed in firmware version 07.04.2. For more details see our resolution follow-up page.
As briefly mentioned in the main article about using the RUT-240 in bridge mode, whilst testing various configurations of the device we discovered an issue that could lead to it's internal services, (such as ssh and the web configuration interface), being accessible remotely over the internet when they appeared from the settings to be configured to allow access only from locally connected devices.
It's important to note that whilst the services would be remotely exposed, and login attempts could be made, actual authenticated access would still require valid login credentials.
In simple terms, a valid username and password combination, or a valid ssh key is still required.
However, this remains an issue that should be addressed, because units with simple or easily guessed passwords may be targeted, and there also exists the possibility of as yet unknown but exploitable bugs in the network stack, webserver, and other running code. In other words, it's quite reasonable and sensible to want to prevent any remote access at all to services that permit control over the device.
The issue can be seen by enabling local ssh and http access, and disabling remote ssh and http access.
When the RUT-240 is in bridge mode, with the cellular interface bridged to the LAN interface, packets received from the cellular interface are effectively treated as being local.
Local-only services are bound to the globally scoped addresses, and firewall rules blocking access from the WAN zone do not block incoming requests to them.
Steps to reproduce
The following steps allow owners of these devices to configure their own RUT-240 to exhibit the bug for further testing and analysis.
They do not provide a way to exploit a remote RUT-240 which is not already vulnerable, and to which you do not already have valid login credentials!
1. Use the following configuration:
RUT-240 with latest firmware as of 20230405 - RUT2_R_00.07.04_1
SIM card with IPv6 connectivity
No device connected to the ethernet WAN socket
Computer connected to the ethernet LAN socket
2. Enable, (local), access to ssh and the web interface in system/administration/access control:
Option 'Enable SSH access' - ON
Option 'Enable HTTP access' - ON
3. Disable remote access to ssh and the web interface in system/administration/access control:
Option 'Enable remote HTTP access' - OFF
Option 'Remote SSH access' - OFF
4. Configure Network / Interfaces / General / lan as a bridge:
Physical settings/bridge interfaces - ON
Interfaces - eth0
5. Configure mob1s1a1:
PDP type: IPv4/IPv6
The RUT-240 will be assigned a global IPv6 block by the ISP, (which is also passed to the connected device by slaac if RAS is set to server mode), and the device will use one or two global IPv6 addresses for itself.
Observe that it is possible to connect to SSH and the web interface over the internet using the global IPv6 addresses, even though we supposedly disabled access in step 3 above.
Also observe that due to the interfaces being bridged, it is not possible to restrict access using a firewall rule with source zone 'WAN', as this does not match the incoming packets on the mob1s1a1 cellular data interface whilst in bridge mode.
We consider that the correct behaviour would be:
To bind the internal services only to the IPv6 unique local addresses in the fd00::/8 range.
To not bind them to the global IPv6 addresses that are provided by the ISP and exposed on the cellular interface, unless 'Remote SSH access' or 'Enable remote HTTP access' is enabled.
To ensure that packets coming in on the cellular interface are correctly considered by the firewall to be in the WAN zone, even when running in bridge mode.
Remote access to the ssh and web servers even when this functionality is disabled.
Valid credentials are still required to actually log in and control the device.
The vulnerability requires bridge mode to be enabled, which is not a default configuration.
The IPv6 address space is very large, and unless the IPv6 suffix option is set with an easy to guess value the global IPv6 addresses assigned to the router will not easily be found by scanning.
Simple and effective workarounds exist, (detailed below).
The main workaround is to add a firewall rule blocking IPv6 access to 'any router IP this device', with source zone LAN or ANY. This will block the packets from the internet via the mob1s1a1 cellular data interface.
However, it will also block local access over IPv6 from the device connected to the LAN socket.
To re-permit access from such a machine, we can add a separate 'pass' rule to allow traffic from that specific device only, based on it's ethernet MAC address.
If both ssh and the web interface are enabled for local access, but one of them is not actually used, then that service can be disabled completely. This reduces the exposed attack surface from two services to one.
The facility to block IP addresses after a number of failed login attempts exists in System / Administration / Access control / Security.
Simple installations which do not require bridge functionality but are currently using it can be re-configured to use NAT mode instead.
Whilst not recommended, if IPv6 connectivity is provisioned but not used it can be disabled temporarily until a better mitigation is available.
As a last resort, changing the services to run on a non-default port might reduce the number of access attempts.
Trying to report the issue
“Solving captchas and filling in awkward web forms is a pure waste of our time.”
When Exotic Silicon discovered this bug, we promptly tried to contact Teltonika Networks to report it.
Unfortunately, the process of making contact was and continues to be somewhat tedious, and we strongly suspect that this is why, as of the time of publishing this information along with the related article 48 hours after our first contact attempt, we have not had any response from them.
The only specific communications channel that we could find for reporting security issues was a web-based form. In general, we would much prefer a simple e-mail address, but a web form obviously shouldn't be too much of a problem for us to deal with.
Unfortunately, this contact form was badly designed.
As if this wasn't tedious enough, the form also requires the user to complete a captcha, which is already quite irritating and tiresome the first time you have to do it. Second and subsequent attempts because the form didn't submit properly on previous attempts quickly become even more tiresome.
But that's not all. The form is painted over the main webpage content, and whilst trying to de-focus all of the fields to debug the spurious 'required field' message, we clicked to the side of it, which promptly made the whole form - along with the data we had entered - disappear completely.
Also, for some reason the field for the actual main text of the bug report is only a single line high. This makes entering and editing text interactively somewhat cumbersome, but even pasting in text from an external document is a bad experience because it doesn't allow for line breaks. So you can't be sure that your neatly formatted list of steps to reproduce the bug will be easily comprehensible if and when it's eventually received.
Honestly, when presented with a system like this, it's easy to feel as if our time is just being wasted, and that the burden of avoiding unwanted form submissions is being passed from the recipient to the sender.
Eventually the request to complete yet another captcha became too much, so we decided to find an e-mail address and try to make contact that way.
We found what seemed like the most generic contact address published, and send a short e-mail explaining that we had discovered a security bug, that we hadn't been able to use to contact form to submit the details, and asking for an e-mail address to send further details to. A very simple request.
Our outbound SMTP server logs show that our e-mail was accepted by the receiving SMTP server with a 250 response code at 21:53:23 UTC on 20230403.
Yet 48 hours later, nobody from Teltonika Networks has contacted us.
Maybe our e-mail has failed to pass an over-zealous filter, and is sitting in a junk folder somewhere.
The upshot of all this is that if you are a company in the IT industry, it's a good idea to regularly check that your communication channels for important issues such as vulnerability reporting are open, fully accessible, and do not place an undue burden on people trying to report issues for your benefit!
Here at Exotic Silicon, we test a lot of equipment in a lot of different configurations. We find bugs, and we don't mind spending a few minutes to pass this information to the manufacturers.
But we have work to do, and solving captchas and navigating awkward webpages is a pure waste of our time.