CVE-2017-20233
Executive Summary
CVE-2017-20234 is a firewall filtering vulnerability in Hirschmann HiLCOS products, including OpenBAT, BAT450, WLC, and BAT867. The flaw allows IPv4 multicast and broadcast traffic to bypass configured firewall rules when management IP address filtering is disabled. An attacker with network access can inject or observe multicast and broadcast packets that should have been blocked, leading to potential information disclosure and network manipulation. The CVSS score is 5.4 (Medium), and no public exploit or patch is currently available. This vulnerability is particularly concerning for industrial and enterprise environments where Hirschmann devices are used for critical network segmentation.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability is not related to any software package registry (NPM, PyPI, Go, Ruby). It affects embedded firmware on Hirschmann networking hardware. No supply chain implications are present.
CVSS Breakdown & Threat Level
- CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
- Base Score: 5.4 (Medium)
- Attack Vector: Network (AV:N) – Exploitable remotely without physical access.
- Attack Complexity: Low (AC:L) – No special conditions required.
- Privileges Required: None (PR:N) – No authentication needed.
- User Interaction: None (UI:N) – No user action required.
- Scope: Unchanged (S:U) – Impact confined to the vulnerable component.
- Confidentiality Impact: Low (C:L) – Limited information disclosure via observed multicast/broadcast traffic.
- Integrity Impact: Low (I:L) – Limited ability to inject malicious multicast/broadcast packets.
- Availability Impact: None (A:N) – No denial-of-service impact.
Threat Level: Medium. The vulnerability allows bypassing firewall rules, which can lead to network reconnaissance and potential lateral movement. However, the impact is limited to multicast/broadcast traffic, and no public exploit exists.
Deep Dive & Mechanics
The vulnerability resides in the firewall filtering logic of Hirschmann HiLCOS firmware. When management IP address filtering is disabled, the firewall fails to correctly process IPv4 multicast (224.0.0.0/4) and broadcast (255.255.255.255) traffic. This means that even if an administrator configures rules to block such traffic, the packets are still forwarded or processed by the device.
Root Cause: The firewall rule evaluation logic does not check for multicast/broadcast destination addresses when management IP filtering is turned off. This is likely due to an oversight in the packet classification code, where the firewall assumes that only unicast traffic needs filtering when management filtering is disabled.
Attack Scenario:
- An attacker on the same network segment sends a crafted multicast packet (e.g., IGMP query or multicast DNS) to the vulnerable device.
- The device’s firewall, configured to block such traffic, incorrectly forwards the packet to internal hosts or processes it itself.
- The attacker can observe responses or inject malicious multicast data, potentially poisoning caches or disrupting services.
Affected Products:
- Hirschmann OpenBAT
- Hirschmann BAT450
- Hirschmann WLC
- Hirschmann BAT867
All running HiLCOS firmware versions are presumed vulnerable unless patched.
Vulnerable vs. Patched Code
No patch is available. The vulnerable code is in the firewall packet processing module of HiLCOS firmware. A hypothetical fix would involve adding a check for multicast/broadcast destination addresses in the firewall rule evaluation function, regardless of management IP filtering status.
Vulnerable Code (Conceptual):
// Vulnerable: Only checks unicast when mgmt_filter is disabled
if (mgmt_filter_enabled) {
if (is_multicast(packet) || is_broadcast(packet)) {
apply_filter_rules(packet);
}
} else {
// No filtering for multicast/broadcast
forward_packet(packet);
}
Patched Code (Conceptual):
// Patched: Always filter multicast/broadcast
if (is_multicast(packet) || is_broadcast(packet)) {
apply_filter_rules(packet);
} else if (mgmt_filter_enabled) {
apply_filter_rules(packet);
} else {
forward_packet(packet);
}
Exploitation & Lab Setup
Red Team (Exploitation)
No public exploit code exists. However, an attacker can test the vulnerability using standard network tools.
Lab Setup:
- 1 Hirschmann device (e.g., BAT450) with HiLCOS firmware, management IP filtering disabled.
- 1 attacker machine (Kali Linux) on the same VLAN.
- 1 victim machine (Windows/Linux) behind the device.
Steps:
- Configure the Hirschmann device to block all multicast traffic (e.g., deny IGMP).
- From the attacker machine, send a multicast packet:
# Send a multicast ping to 224.0.0.1 ping -I eth0 224.0.0.1 -c 1 - Observe if the victim machine receives the ping (using tcpdump on victim).
- If the victim receives the packet, the firewall bypass is confirmed.
Advanced Exploitation:
- Use
scapyto craft malicious multicast DNS (mDNS) packets to poison local DNS caches. - Inject IGMP queries to disrupt multicast group membership.
Blue Team (Defense)
Detection:
- Monitor for unexpected multicast/broadcast traffic on network segments where Hirschmann devices are deployed.
- Use network flow analysis (NetFlow/IPFIX) to identify anomalous multicast patterns.
Mitigation:
- Enable management IP filtering on all Hirschmann devices.
- Implement strict ACLs on upstream routers to block unnecessary multicast/broadcast traffic.
- Segment Hirschmann devices into isolated VLANs.
Indicators of Compromise (IOCs)
Network Traffic:
- Unexpected multicast packets (224.0.0.0/4) from non-standard sources.
- Broadcast packets (255.255.255.255) with unusual payloads.
- IGMP queries from unauthorized hosts.
Logs:
- Hirschmann device logs showing firewall rule bypass events (if logging is enabled).
- Syslog entries with "multicast" or "broadcast" keywords from the device.
Host-Based:
- Unusual mDNS or LLMNR responses on the network.
- ARP cache poisoning indicators (duplicate IP-MAC mappings).
Detection Engineering
YARA Rule
rule CVE_2017_20234_Hirschmann_Firewall_Bypass {
meta:
description = "Detects network traffic patterns associated with CVE-2017-20234 firewall bypass"
author = "Valters IT"
date = "2025-04-10"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2017-20234"
strings:
$multicast_ip = { E0 00 00 [2] } // 224.0.0.x
$broadcast_ip = { FF FF FF FF }
$igmp_query = { 11 [2] } // IGMP query type
condition:
any of them
}
Sigma Rule
title: Hirschmann Firewall Bypass - Multicast/Broadcast Traffic
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects multicast or broadcast traffic that may indicate exploitation of CVE-2017-20234
author: Valters IT
logsource:
category: network_flow
product: netflow
detection:
selection:
destination_ip:
- '224.0.0.0/4'
- '255.255.255.255'
condition: selection
falsepositives:
- Legitimate multicast applications (e.g., video streaming)
level: medium
Suricata Rule
alert ip any any -> 224.0.0.0/4 any (msg:"CVE-2017-20234 Hirschmann Firewall Bypass - Multicast Traffic"; classtype:attempted-recon; sid:1000001; rev:1;)
alert ip any any -> 255.255.255.255 any (msg:"CVE-2017-20234 Hirschmann Firewall Bypass - Broadcast Traffic"; classtype:attempted-recon; sid:1000002; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Enable management IP filtering on all Hirschmann HiLCOS devices.
- Review and tighten firewall rules to explicitly block multicast/broadcast traffic.
- Isolate Hirschmann devices on dedicated VLANs with strict ACLs.
Long-Term Fix:
- Contact Hirschmann support for a firmware patch (if available).
- Monitor vendor advisories for updates.
- Consider replacing affected devices if no patch is released.
Workaround:
- Use external firewalls to filter multicast/broadcast traffic before it reaches Hirschmann devices.
- Disable unnecessary multicast protocols (e.g., IGMP snooping) on the device.
Valters IT
Securing Your Digital Frontier
{/* [Security Hash: 9491A1CFB770E01F64A587AB] */}
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.