Identifying and Mitigating Exploitation of the GRE Decapsulation Vulnerability

Available Languages

Updated:December 25, 2011
Document ID:1487390063048121

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Identifying and Mitigating Exploitation of the GRE Decapsulation Vulnerability

Advisory ID: cisco-amb-20060912-gre

https://sec.cloudapps.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20060912-gre

Revision 1.0

For Public Release 2006 September 12 17:00 UTC (GMT)

Contents

Cisco Response
Device-Specific Mitigation and Identification
Additional Information
Revision History
Cisco Security Procedures
Related Information

Cisco Response

Vulnerability Characteristics

The Cisco IOS GRE decapsulation vulnerability can be exploited remotely with no authentication and no user interaction is necessary. If exploited, the attacker may cause Cisco IOS? software to forward specially crafted IPv4 packets which potentially could be used to bypass access-control lists. The attack vector is through IP protocol 47, Generic Routing Encapsulation (GRE). This vulnerability is not covered by a CVE ID.

This document contains information to assist Cisco customers in mitigating attempts to exploit the Cisco IOS GRE decapsulation vulnerability. This vulnerability affects devices running Cisco IOS software configured with GRE tunnels. As originally defined in RFC1701, the GRE Header field contains a number of flag bits which have been deprecated by RFC2784. Versions of Cisco IOS software that support RFC2784 are not affected by this vulnerability.

Vulnerable, non-affected and fixed software information is available in the PSIRT Security Response:

Cisco Security Response to: Cisco IOS GRE Decapsulation Vulnerability

Mitigation Technique Overview

Cisco devices provide several countermeasures for the Cisco IOS GRE decapsulation vulnerability. Tunnel protection in the form of IPSec encapsulation is the most effective means of attack mitigation. This attack may also be mitigated by applying an access list in the inbound direction of GRE traffic and filtering the GRE protocol from all but trusted source addresses. It should be noted that an attack may still be successful if the GRE packet is spoofed using a trusted source IP address permitted by the applied access list.

Risk Management

Organizations are advised to follow their standard risk evaluation and mitigation processes to determine the potential impact of [this vulnerability|these vulnerabilities]. Triage refers to sorting projects and prioritizing efforts that are most likely to be successful. Cisco has provided documents that can help organizations develop a risk-based triage capability for their information security teams. Risk Triage for Security Vulnerability Announcements and Risk Triage and Prototyping can help organizations develop repeatable security evaluation and response processes.

Device-Specific Mitigation and Identification

Specific information on mitigation and identification is available for these devices

Internet Edge and GRE Termination Routers

caution Caution: The effectiveness of any mitigation technique is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation: Interface Access List

The following access list permits IP protocol number 47 (GRE) packets from a single known host (i.e., 192.0.2.1) and destined for the IOS router itself (i.e. 192.0.2.2). All other GRE packets are filtered.

Added access list entries should be implemented as part of a Transit Access Control List that filters transit and edge traffic at network ingress points.

For more information on ACLs, refer to Transit Access Control Lists: Filtering at Your Edge.



!-- Allow the GRE protocol from trusted source addresses only.
!-- Block GRE from all other source addresses.


access-list 100 permit gre host 192.0.2.1 host 192.0.2.2
access-list 100 deny gre any any


!-- Permit all other traffic not specifically blocked.


access-list 100 permit ip any any


!-- Apply access list to interface in the inbound direction.


interface Ethernet 0/0
ip access-group 100 in

Mitigation: Anti-Spoofing

This vulnerability can be exploited by a spoofed packet. Anti-spoof protection in the form of unicast Reverse Path Forwarding can provide limited mitigation if properly configured. This feature should not be relied upon to provide 100% mitigation since spoofed packets may still enter the network from the interface expected by uRPF or allowed by anti-spoofing access lists. Also care must be taken to ensure that the appropriate uRPF mode (loose or strict) is configured to ensure that legitimate packets are not dropped.

Additional information about unicast Reverse Path Forwarding is available at http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_urpf.html.

Mitigation: GRE Tunnel ID

Applying a tunnel ID key may provide some mitigation against this issue, but the command is not intended as a security feature and the key can be found by sniffing legitimate GRE packets. For more information regarding this feature, please refer to Configuring Logical Interfaces - Configuring a Tunnel Identification Key.

On the Supervisor 720, GRE tunnels using an ID key are processed in software which may impact performance.

Identification

Once the interface access list is applied to the GRE ingress interface, the command show access-list <acl number> can be used to identify the number of packets being filtered. Filtered packets should be investigated to determine if they are attempts to exploit this issue. Following is example output for show access-list 100:

Edge-Router#show access-list 100
Extended IP access list 100
10 permit gre host 192.0.2.1 host 192.0.2.2 (141 matches)
20 deny gre any any (100 matches)
30 permit ip any any

In the above example, 100 GRE packets have been dropped by the access list configured inbound on interface Ethernet 0/0.

VPN Routers

caution Caution: The effectiveness of any mitigation technique is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation: GRE Protected by IPSec

Encrypting GRE tunnels with IPSec is the most effective means of attack prevention. For additional information about encrypting GRE with IPSec, refer to these resources:

Mitigation: Interface Access List

The following access list filters IP protocol number 47 (GRE) from all hosts. VPN routers terminating GRE encapsulated in IPSec should not receive clear text (unencrypted) GRE packets on the physical ingress interface.

Added access list entries should be implemented as part of a Transit Access Control List that filters transit and edge traffic at network ingress points.

For more information on ACLs, refer to Transit Access Control Lists: Filtering at Your Edge.

The following access list permits IPSec traffic from a single trusted host (i.e., 192.0.2.1) and destined for the IPSec terminating router itself (i.e., 192.0.2.2).


!-- Block all GRE to the IPSec terminating physical interface.


access-list 100 deny gre any any


!-- Permit ESP (IP protocol 50) and
!-- ISAKMP UDP ports 500 and 4500.


access-list 100 permit esp host 192.0.2.1 host 192.0.2.2
access-list 100 permit udp host 192.0.2.1 host 192.0.2.2 eq 500
access-list 100 permit udp host 192.0.2.1 host 192.0.2.2 eq 4500


!-- Permit all other traffic.


access-list 100 permit ip any any


!-- Apply access list to interface in the inbound direction.


interface Ethernet 0/0
ip access-group 100 in

The interface access list may need a specific access list permit entry for GRE packets from the GRE tunnel source IP address to the GRE tunnel destination IP address if the IOS version running on the device does not have the fix for Cisco bug ID CSCdu58486 (registered customers only) .

Mitigation: GRE Tunnel ID

Applying a tunnel ID key may provide some mitigation against this issue, but the command is not intended as a security feature and the key can be found by sniffing legitimate GRE packets. For more information regarding this feature, please refer to Configuring Logical Interfaces - Configuring a Tunnel Identification Key.

Identification

Once the transit access list is applied to the physical ingress interface, the command show access-list <acl number> can be used to identify the number of packets being filtered. Filtered packets should be investigated to determine if they are attempts to exploit this vulnerability. Following is example output for show access-list 100:

Edge-Router#show access-list 100
Extended IP access list 100
10 deny gre any any (100 matches)
20 permit esp host 192.0.2.1 host 192.0.2.2
30 permit udp host 192.0.2.1 host 192.0.2.2 eq 500
40 permit udp host 192.0.2.1 host 192.0.2.2 eq 4500
50 permit ip any any

In the above example, 100 GRE packets have been dropped by the access list configured inbound on interface Ethernet 0/0.

Cisco ASA and PIX Firewalls

caution Caution: The effectiveness of any mitigation technique is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Mitigation

The following access lists permit IP protocol number 47 (GRE) packets from a single trusted host (i.e., 192.0.2.1) and destined for the IOS router terminating GRE (i.e,. 192.0.2.2). All other GRE packets are filtered.

PIX 6.x


!-- Allow the GRE protocol from trusted source addresses only.
!-- Block GRE from all other source addresses.


access-list block-gre permit gre host 192.0.2.1 host 192.0.2.2
access-list block-gre deny gre any any


!-- Permit/deny all other traffic in accordance with existing security
!-- policies and configurations.
!-- Apply access list to interface inbound.


access-group block-gre in interface outside

PIX/ASA 7.x

As a transit device, only allow trusted source IP addresses to send GRE packets to devices inside of the firewall.


!-- Allow the GRE protocol from trusted source addresses only.
!-- Block GRE from all other source addresses.


access-list block-gre extended permit gre host 192.0.2.1 host 192.0.2.2
access-list block-gre extended deny gre any any


!-- Permit/deny all other traffic in accordance with existing security
!-- policies and configurations.
!-- Apply access list to interface in the inbound direction.


access-list block-gre extended permit ip any any
access-group block-gre in interface outside

Identification

PIX 6.x

In this example, 100 GRE packets have been received and blocked.

pix#show access-list block-gre
access-list block-gre; 2 elements
access-list block-gre line 1 permit gre host 192.0.2.1 host 192.0.2.2 (hitcnt=0)
access-list block-gre line 2 deny gre any (hitcnt=100)

PIX/ASA 7.x

In this example, 100 GRE packets have been received and blocked.

asa#show access-list block-gre
access-list block-gre; 2 elements
access-list block-gre line 1 extended permit gre host 192.0.2.1 host 192.0.2.2 (hitcnt=50)
access-list block-gre line 2 extended deny gre any (hitcnt=100)

In PIX/ASA 7.x, if GRE is allowed through the firewall, the command show conn | include GRE can be used to verify the specific GRE connections transiting through the firewall. Unexpected established GRE connections should be investigated to determine if they are attempts to exploit this issue. Following is example output for show conn | include GRE:

asa#show conn | include GRE
GRE out 192.0.2.1:0 in 192.0.2.2:0 idle 0:00:15 bytes 3120 flags
GRE out 192.0.2.1:0 in 192.0.2.2:0 idle 0:00:15 bytes 2600 flags

NetFlow

NetFlow can be configured on Internet Edge and GRE termination routers to determine if attempts are in progress to exploit this vulnerability.

router#show ip cache flow

IP packet size distribution (15014 total packets):
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .000 .000 1.00 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
  1 active, 65535 inactive, 2 added
  30 lager polls, 0 flow al loc failures
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 402120 bytes
  0 active, 16384 inactive, 0 added, 0 added to flow
  0 al loc failures, 0 force free
  1 chunk, 1 chunk added
  last clearing of statistics never
Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------         Flows     /Sec     /Flow  /Pt     /Sec     /Flow     /Flow
TCP-WWW              2      0.0         1    60      0.0       0.0      15.5
TCP-other            4      0.0         1    60      0.0       0.0      15.7
UDP-other            4      0.0         2   162      0.0       2.7      15.6
ICMP                11      0.0         4    85      0.0       3.0      15.7
GRE               2015     50.0       100   124      0.3       8.7      15.6
IP-other             1      0.0        34   136      0.0      33.3      15.6
Total:            2037     50.0         4   124      0.3       1.3      15.6

SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Fa0/0         192.168.0.1     Fa2/0         192.168.0.2     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.3     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.4     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.5     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.6     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.7     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.8     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.9     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.10    2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.11    2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.12    2F 0000 0000   100
---------- Output Truncated ----------

In the above example, there are a very high number of GRE (Protocol Hex 2F) flows from a single IP address to multiple destination IP addresses. On Internet edge routers and potentially on GRE termination routers, this may be indicative of an attempt to exploit this vulnerability and should be compared to baseline utilization of these ports on the monitoring devices.

To only view GRE (Protocol Hex 2F) flows, the command show ip cache flow | inc SrcIf|2F may be used as shown here:

Router#show ip cache flow | inc SrcIf|2F
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Fa0/0         192.168.0.1     Fa2/0         192.168.0.2     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.3     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.4     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.5     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.6     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.7     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.8     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.9     2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.10    2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.11    2F 0000 0000   100
Fa0/0         192.168.0.1     Fa2/0         192.168.0.12    2F 0000 0000   100
---------- Output Truncated ----------

Additional Information

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.

Revision History

Revision 1.0

2006-September-12

Initial public release.

Cisco Security Procedures

Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.

Related Information