CVE-2023-31728

Executive Summary

CVE-2023-31728 exposes a configuration bypass vulnerability in Teltonika RUT240 industrial routers running firmware versions prior to 07.04.2. When the device is operating in bridge mode, SSH and HTTP management services are unintentionally exposed on the IPv6 WAN interface, despite the user interface indicating these services are restricted to the LAN interface. This misconfiguration allows an unauthenticated, remote attacker on the IPv6 WAN to access the router's management interfaces, potentially leading to unauthorized configuration changes, network reconnaissance, or lateral movement within the industrial network.

The vulnerability has a CVSS base score of 5.3 (Medium) due to the low attack complexity, network attack vector, and no required privileges, but the impact is limited to information disclosure and potential unauthorized access. No public proof-of-concept (PoC) or exploit code is currently available, and the EPSS score is 0.0%, indicating low exploitation activity in the wild. However, given the critical role of these devices in industrial IoT environments, the risk of targeted attacks remains significant.

Supply Chain & Package Security

This vulnerability is not related to any software package registry (NPM, PyPI, Go, Ruby). It is a firmware-level misconfiguration in Teltonika's proprietary embedded system.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely over the IPv6 WAN.
• Attack Complexity (AC): Low (L) – No special conditions required; the service is exposed by default in bridge mode.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component is the router itself.
• Confidentiality (C): Low (L) – Limited information disclosure (router configuration, network topology).
• Integrity (I): None (N) – No direct data modification.
• Availability (A): None (N) – No denial of service.

CVSS Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Threat Level: Medium (5.3). The vulnerability is easy to exploit but limited in impact. However, in an OT/ICS context, the ability to access the router's management interface could be a stepping stone for more severe attacks.

Deep Dive & Mechanics

The vulnerability stems from a logic error in the router's firewall and service binding configuration when operating in bridge mode. In bridge mode, the router acts as a transparent layer-2 bridge, forwarding traffic between LAN and WAN without performing NAT. The firmware's web UI and SSH service binding logic incorrectly evaluates the network interface configuration, failing to apply the intended access control lists (ACLs) to the IPv6 WAN interface.

Specifically, the router's iptables rules or equivalent firewall rules are not updated to restrict SSH (port 22) and HTTP (port 80) services to the LAN interface when bridge mode is enabled. The UI displays the correct configuration (services bound to LAN only), but the underlying firewall rules are not enforced on the IPv6 WAN interface. This allows any IPv6-capable host on the WAN side to reach the router's management services.

The root cause is likely a missing conditional check in the firmware's network configuration script that fails to re-apply firewall rules when the bridge mode is toggled. The IPv6 WAN interface inherits the default "allow all" policy instead of the "LAN only" policy.

Vulnerable vs. Patched Code

Since the firmware is proprietary, no source code diff is available. However, based on the advisory, the patch (firmware version 07.04.2) corrects the firewall rule generation logic.

Vulnerable Behavior (firmware < 07.04.2):

• Bridge mode enabled.
• Firewall rules for SSH/HTTP are applied only to the IPv4 LAN interface.
• IPv6 WAN interface has no explicit deny rules for SSH/HTTP.
• Result: Services accessible via IPv6 WAN.

Patched Behavior (firmware >= 07.04.2):

• Bridge mode enabled.
• Firewall rules for SSH/HTTP are correctly applied to all interfaces except the intended LAN.
• IPv6 WAN interface has explicit deny rules for SSH/HTTP.
• Result: Services accessible only via LAN.

Hypothetical vulnerable configuration snippet (pseudo-code):

# Vulnerable: Only applies to LAN interface
iptables -A INPUT -i lan -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i lan -p tcp --dport 80 -j ACCEPT
# Missing: Deny rules for WAN interfaces

Hypothetical patched configuration snippet:

# Patched: Explicitly denies WAN interfaces
iptables -A INPUT -i wan -p tcp --dport 22 -j DROP
iptables -A INPUT -i wan -p tcp --dport 80 -j DROP
iptables -A INPUT -i lan -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i lan -p tcp --dport 80 -j ACCEPT

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Teltonika RUT240 with firmware < 07.04.2 in bridge mode.
• An IPv6-capable attacker machine on the same WAN segment (or reachable via IPv6 routing).
• The router's IPv6 WAN address (can be discovered via Shodan or local network scanning).

Exploitation Steps:

1. Discover the target: Use Shodan with the dork title:"RUT240" or scan the IPv6 range with nmap.

   nmap -6 -p 22,80 --open <target_ipv6>/64
   

2. Verify exposure: Attempt to connect to SSH or HTTP on the router's IPv6 WAN address.

   ssh admin@<router_ipv6>
   curl -6 http://[<router_ipv6>]/
   

3. Access the management interface: If SSH is exposed, attempt default credentials (e.g., admin:admin01). If HTTP is exposed, access the web UI and attempt to log in.

4. Post-exploitation: Once authenticated, an attacker can:

   • Modify firewall rules to allow further access.
   • Extract configuration files (e.g., VPN credentials, network topology).
   • Use the router as a pivot point to attack internal OT devices.

No public exploit code is available. The exploitation is straightforward service exposure.

Blue Team

Detection and Response:

1. Monitor for unexpected IPv6 connections: Use network monitoring tools to detect SSH or HTTP connections to the router from external IPv6 addresses.

   tcpdump -i any -n 'ip6 and (port 22 or port 80) and not src net <trusted_lan_prefix>'
   

2. Check router configuration: Log into the router and verify the firewall rules.

   iptables -L -n -v
   

   Look for missing DROP rules on the WAN interface for ports 22 and 80.

3. Firmware version check: Ensure the router is running firmware 07.04.2 or later.

   cat /etc/version
   

4. Honeypot deployment: Deploy a fake RUT240 honeypot on the IPv6 WAN to detect scanning activity.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Inbound IPv6 TCP connections to port 22 or 80 from unknown external IPv6 addresses.
  • Unusual SSH login attempts from IPv6 addresses not in the trusted LAN range.
  • HTTP requests to the router's web interface from IPv6 addresses.

• Host IOCs (on the router):

  • Firewall rules missing DROP entries for WAN interfaces on ports 22 and 80.
  • Unauthorized configuration changes (e.g., new VPN tunnels, modified firewall rules).
  • New SSH keys or user accounts.

• Log IOCs:

  • /var/log/messages entries showing SSH or HTTP connections from unexpected IPv6 addresses.
  • iptables log entries (if logging is enabled) showing packets hitting the INPUT chain on WAN interface.

Detection Engineering

YARA Rule

rule CVE_2023_31728_Teltonika_RUT240_Exposed_Services {
    meta:
        description = "Detects Teltonika RUT240 firmware versions vulnerable to CVE-2023-31728"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2023-31728"
        hash = "unknown"
    strings:
        $firmware_version = "07.04.1" nocase
        $firmware_version2 = "07.04.0" nocase
        $bridge_mode = "bridge" nocase
        $ssh_config = "port 22" nocase
        $http_config = "port 80" nocase
    condition:
        any of ($firmware_version*) and $bridge_mode and ($ssh_config or $http_config)
}

Sigma Rule

title: CVE-2023-31728 - Teltonika RUT240 Exposed Management Services via IPv6 WAN
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects inbound IPv6 connections to SSH or HTTP on Teltonika RUT240 routers from external IPv6 addresses.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2023-31728
logsource:
    category: network_connection
    product: linux
    service: iptables
detection:
    selection:
        src_ip|startswith: "2001:"  # Example global unicast IPv6 prefix
        dst_port:
            - 22
            - 80
        protocol: tcp
    condition: selection
falsepositives:
    - Legitimate remote management from trusted IPv6 ranges (should be whitelisted)
level: high

Suricata Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 22,80 (msg:"CVE-2023-31728 - Teltonika RUT240 Exposed SSH/HTTP via IPv6 WAN"; flow:to_server,established; ip_proto:6; ip6; content:"SSH"; depth:4; offset:0; classtype:attempted-recon; sid:1000001; rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"CVE-2023-31728 - Teltonika RUT240 Exposed HTTP via IPv6 WAN"; flow:to_server,established; ip_proto:6; content:"GET /"; http_method; classtype:attempted-recon; sid:1000002; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade firmware: Update all Teltonika RUT240 devices to firmware version 07.04.2 or later. This is the only complete fix.
2. Disable bridge mode if not required: If bridge mode is not essential, switch to router mode (NAT) to avoid the vulnerability.
3. Restrict IPv6 WAN access: If bridge mode is required, manually add firewall rules to block SSH and HTTP on the IPv6 WAN interface.

   ip6tables -A INPUT -i wan -p tcp --dport 22 -j DROP
   ip6tables -A INPUT -i wan -p tcp --dport 80 -j DROP
   

4. Change default credentials: Ensure all devices use strong, unique passwords for SSH and HTTP access.

Long-term Mitigations:

1. Network segmentation: Place RUT240 routers behind a perimeter firewall that restricts inbound IPv6 traffic to only necessary services.
2. Monitoring: Deploy the detection rules above to monitor for exploitation attempts.
3. Vendor communication: Contact Teltonika for additional security advisories and ensure all devices are on a supported firmware track.

Workaround (if patching is not possible):

• Disable IPv6 on the WAN interface if IPv6 is not required.
• Use a VPN to access the management interface instead of exposing it directly.

Valters IT