EXOTIC SILICON
“Buggy bridges”
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.
Bug overview
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:
2. Enable, (local), access to ssh and the web interface in system/administration/access control:
3. Disable remote access to ssh and the web interface in system/administration/access control:
4. Configure Network / Interfaces / General / lan as a bridge:
5. Configure mob1s1a1:
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:
Result:
Remote access to the ssh and web servers even when this functionality is disabled.
Limitations:
Workarounds
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.
Firstly, it relies on Javascript for it's operation and after spending some time filling it in, upon trying to submit it we were told that one of the fields that we had indeed dutifully filled in was required. The system seemed to be treating it as if it was empty.
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.