- CVE-2020-24336 – The code for parsing DNS records in DNS response packets sent over NAT64 does not validate the length field of the response records, allowing attackers to corrupt memory.
- CVE-2020-24338 – The function that parses domain names lacks bounds checks, allowing attackers to corrupt memory with crafted DNS packets.
- CVE-2020-25111 – A heap buffer overflow occurring during the processing of the name field of a DNS response resource record, allowing an attacker to corrupt adjacent memory by writing an arbitrary number of bytes to an allocated buffer.
Forescout has communicated with the affected vendors, and GitHub’s security team is also assisting in identifying the affected TCP/IP repositories. However, according to Forescout, only the Contiki-NG, PicoTCP-NG, FNET, and Nut/Net projects have released patches for the vulnerabilities. The uIP, Contiki, and PicoTCP projects have not yet released patches.
How can I mitigate the impact of AMNESIA:33?
A: Forescout recommends six best practices to protect your organization:
• Assess your risk. Perform a thorough risk assessment before deploying mitigations. This includes identifying potentially vulnerable devices, their business context and criticality, and their communication pathways and internet exposure. Based on this assessment, determine what level of mitigation is required.
• Rely on internal DNS servers. Configure devices to rely on internal DNS servers whenever possible and closely monitor external DNS traffic, as several vulnerabilities in AMNESIA:33 are related to DNS clients, which require a malicious DNS server to reply with malicious packets.
• Disable or block IPv6 traffic. Since several vulnerabilities in AMNESIA:33 relate to IPv6 components, disable or block unnecessary IPv6 network traffic
• Segment to mitigate risk. For unpatchable IoT and OT devices, use segmentation to minimize their network exposure and the likelihood of compromise without impacting mission-critical functions or business operations. Segmentation and zoning also limit the blast radius and business impact if a vulnerable device becomes compromised.
• Patch when possible. The best mitigation is to identify and patch vulnerable devices. However, this is easier said than done because:
• Patches may not be available for an embedded component from the IoT or OT device vendor.
• Directly patching an embedded component may void the device manufacturer’s warranty.
• A device may be part of a mission-critical function or high-availability business operation and may not be patchable until a future scheduled maintenance window.
Patch devices when possible, and use segmentation for risk mitigation when devices can’t be patched.
• Monitor for malformed packets. Monitor all network traffic for malformed packets (for example, having non-conforming field lengths or failing checksums) that try to exploit known vulnerabilities or possible zero days, since many vulnerabilities are related to IPv4 and other standard components of stacks. Anomalous and malformed IP traffic should be blocked, or network operators should receive alerts regarding their presence.