On Tuesday, February 16th, Google’s security team announced a significant vulnerability in glibc . The vulnerability relates to the handling of DNS packets, and many Cisco systems are vulnerable to it if an attacker can cause an affected device to perform a DNS lookup against an attacker-controlled DNS server. As many services (ssh, some web servers, mail servers) do perform these requests in an externally controllable fashion, the risk and exposure of this vulnerability are extremely significant.
Cisco released their advisory for this issue on the 18th. Because of the extensive use of Linux in newer switching and routing products, UC servers, and security and management appliances, the potential scope of the issue is vast. Cisco is presently still in the process of qualifying products to determine if and how they are affected.
Here is an example of how the most common attack vector works. The attacker connects to a service (Mail, Video Conferencing, SSH, Web) that performs a DNS lookup, this could be a reverse lookup of the connecting service, it could also be a forward lookup triggered by the details of the request and protocol. The attacker returns hostile DNS traffic that then impacts the client device:
Cisco Products Most at Risk
The products most at risk to this vulnerability are those that are most exposed to potential attackers. In most enterprise environments this constitutes first external users, then internal users. In this blog post, we’ll first address edge devices, discuss general mitigation techniques and finally highlight some information on IPS solutions.
At the enterprise, with the edge devices in Cisco’s product suite, our expectation is to find firewalls and border routers, as well as Expressway. In most common configurations, we don’t expect the firewalls and border routers to be vulnerable. These devices are rarely configured to make use of DNS servers. As the risk is caused by DNS resolution, a product that does not have a DNS resolver configured should not be affected by the issue. DNS inspection does not, to our knowledge, make use of the affected glibc code. Most ASA devices and edge firewalls are not configured to resolve DNS. Traditional IOS is not affected. If you have a real need to use DNS services on these devices, there are still mitigation methods available to you, we are in the process of developing edge and DNS server based configurations to mitigate these issues, however, they presently have a significant impact on DNS functionality. We plan to continue update the Stack8 blog with more details on these techniques as well as their impact.
For an ASA to be vulnerable, the dns domain lookup command must specify an interface and a dns server group must be configured. Here’s an example of a vulnerable configuration:
dns domain-lookup outside
dns server-group DefaultDNS
name-server 184.108.40.206 220.127.116.11
We recommend first validating if the DNS server is actually used; look for objects referencing a fqdn on devices running ASA 8.3 and newer, if it isn’t, then the best course of action is to remove the dns domain lookup command. If this isn’t possible please see the subsequent sections on mitigation below.
Border routers running IOS XE (e.g. ASR 1k) may also be vulnerable to this issue. Look for references to the ip name-server command:
ip name-server 18.104.22.168 22.214.171.124
By default, a router will also perform broadcast DNS lookups if no DNS server is specified. This can be disabled using the “no ip domain lookup” command. If your device is actively making use of DNS and this functionality cannot be disabled then please see the subsequent sections on mitigation below.
Border routers running IOS XR (e.g. ASR 9k) may also be vulnerable to this issue. Again it is not common to configure these devices with a DNS server. Look for the presence of the following command configuring a DNS server.
domain name-server 126.96.36.199 188.8.131.52
You can completely disable DNS resolution on IOS XR using the domain lookup disable command:
domain lookup disable
If you can’t disable DNS then please see the subsequent sections on mitigation below. ≈
Expressway and other Products
Expressway is one of the most at-risk devices because it’s core functionality, unlike most other edge products, is highly dependent on DNS. At present, there is no clear statement on the level of risk for this product, however, we believe it to be vulnerable as it is definitely a Linux-based appliance. A large number of Cisco’s other products, particularly in the UC, Management (Prime) and Security space are also Linux based and likely to be affected to some degree.
Network Level Mitigation
As the vulnerability can only be exploited by larger packets, the following configurations should block traffic that uses UDP packets larger than 512 bytes and TCP packets larger than 1024. It is possible to configure border devices to drop this traffic. Be aware that this could have an impact on DNS performance as well as CPU load on devices that are not presently configured for inspection. Extreme caution is required while making these configuration changes and assessing their impact. Unfortunately, this change can block substantial amounts of valid DNS traffic. The following rules will need to be carefully tested before implementation to ensure that there is no operational impact in your environment. We leave it to the readers discretion to decide specifically how to balance level of risk and service impact in their environment.
Blocking Large DNS Packets
Based on the default policy map of:
policy-map type inspect dns preset_dns_map
message-length maximum client auto
message-length maximum 512
inspect dns preset_dns_map
We will make the following changes:
policy-map type inspect dns preset_dns_map
no message-length maximum client auto
Unfortunately, this change only impacts UDP and not TCP DNS traffic, as such it is not a complete solution to blocking potentially hostile traffic. Please let us know if you’re aware of another method in the comments and we’ll update the post.
This policy-map will drop DNS traffic exceeding 512 bytes of udp or 1024 bytes of tcp for specific hosts mentioned in the glibc-block-tcp-traffic-acl and glibc-block-udp-traffic-acl ACLs.
permit tcp any eq domian host 192.168.1.2
ip access-list extended glibc-block-udp-traffic-acl
permit udp any eq domain host 192.168.1.2
match access-group name glibc-block-udp-traffic-acl
match packet length min 513
class-map match-all glibc-tcp-traffic-class
match access-group name glibc-block-tcp-traffic-aclmatch packet length min 1025
match packet length min 1025
police 8000 conform-action drop
police 8000 conform-action drop
service-policy output glibc-traffic-policy
Name Server Reconfiguration
There are configuration changes that can be made to DNS servers that reduce the size of DNS requests. One change that has a very substantial impact on DNS query size is disabling DNSSEC. This does increase the potential security impact of a MITM attacker but it also allows you to complete most DNS queries with much smaller packets. Here are the configuration changes required to address this issue on BIND and Active Directory, similar changes should be possible on other platforms.
Adding the following to your named.conf to disable DNSSEC and EDNS:
Run the following commands and restart the DNS service in order to disable DNSSEC and EDNS
dnscmd /enableednsprobes 0
dnscmd /enablednssec 0
And restart the DNS service.
There are currently some snort rules available for this threat, they are already included in Sourcefire 2016-02-18 ruleset update.
Palo-Alto has implemented detection for exploitation of this vulnerability in emergency update 560, signature id 38898, we recommend changing the action from the default of alert to drop or reset both.
If you’re interested in ongoing support or project-based support; we would love to talk to you about your environment and your specific needs.
Other Blogs You Might Enjoy
Ready to take your unified communications from headache to hassle-free?
No throwing darts at proposals or contracts. No battling through the back-end. No nonsense, no run-around.