Pen-Testing the Backbone Raven NMRC raven nmrc org

Pen-Testing the Backbone Raven || NMRC raven@nmrc. org

Cultural differences ● ● Security geeks and ISP geeks tend to model disclosure and vulnerability handling differently. ISP engineers tend to believe in limited, tiered disclosure. Most people here are likely to disagree with that. A balance must be struck for maximum efficiency and security.

White box or black box? ● ● Black box testing is good for external recon and data gathering. However, it's far more difficult and likely to be destructive in implementation. Many backbone vulnerabilites are denial-ofservice oriented. Since people get unhappy when you break their ISP, white-box testing is preferred.

Initial Reconnaissance ● ● Choose your target – search the registars for their address blocks, allocated autonomous systems, and other data. (Contacts if not role account, etc. ) Look on route servers and Internet maps to try to determine their peering. Throw everything you get into Google, recurse when necessary to build a profile of the network. Check mailing list archives for likely config details and public peering points.

Vendor-specific details ● ● ● Each vendor has their own advisory and vulnerability disclosure practices. Become familiar with these for each vendor on your target network. Acquire CCO, Juniper, etc. site logins when necessary to supplement vulnerability information. Don't forget the switches – this should go for all your network gear.

Code train vulnerabilities ● ● ● Check the vulnerabilities specific to each code train implemented in your network. Also check vulnerabilities in stacks/implementations that your current code train is derived from. BSD vulnerabilities are worth checking for Cisco and Jun. OS boxes, for example – a BSD telnet vulnerability (http: //www. osvdb. org/displayvuln. php? osvdb_id=809) also affected Cisco Cat. OS boxes. (http: //www. cisco. com/warp/public/707/catos-telrcv-vuln-pub. shtml) Some scanners incorporate these checks, but many may need to be done by hand. Beware of unintentional Do. S while scanning.

Failure paths and trust relationships ● ● Architectural review – check for redunancy, network robustness, and security. Do your authentication means have redundancy? Fallback? What is the weakest form of authentication one can force? (Reverting to no auth on a RADIUS server: http: //www. osvdb. org/displayvuln. php? osvdb_id=17644) ● ● Once authenticated, is trust transitive? Can one log in directly from one backbone router to another? Are source IP addresses restricted? Is there a single point of transit or authentication failure? What happens when it fails?

Failure and Trust II ● ● If there is centralized authentication, how many servers are there? Are they hardened? Are authentication credentials sent cleartext? Where can you access the authentication server from? Often it's whitelisted in ACLs, so once owned, it's a free ticket into the infrastructure. Can one set up a Mit. M attack against the authentication server to harvest credentials? Is the auth server itself vulnerable? (RADIUS exploit goes here. )

Ob. Slide – Physical Security ● ● Make sure all data centers and peering points have good physical security. Test this. Repeatedly. Often. Many of these attacks are only possible with local injection or access. Make sure that doesn't happen. Good physical security is half the game.

Data Leaks ● Check for data leaks at the network border – connect to the switch and fire up a sniffer. This is particularly valuable at an exchange point with a port in promiscuous mode. – Cisco Discovery Protocol – Routing protocol information – Leaked switching data

Protocol injection – speak my route? ● ● If you can see the data, you can spoof the data. Fake a routing annoucement and inject it. See if it gets picked up. Fake spanning tree. Fake CDP. For a ghetto Do. S attack, tear down links with spoofed packets. (Almost no clients want this level of testing. ) Many routing protocol implementations are unauthenticated. This is obviously insecure.

Rogue router ● ● Connecting a new router to many data centers is easier than you'd think. Plug in to the exchanging switch. Depending on what data is being advertised, try to speak their routing protocols with a similar configuration. Depending on your contract with the client, you may even be able to replace their router with one of your own.

Pwn 3 d router ● ● ● If you have been able to get authentication credentials, or force a login (cisco/cisco, admin/company name, etc. ), router hijack is possible. Traffic redirection into a tunnel of your choice is possible -- GRE tunnels are popular in the wild among blackhats. You may be able to advertise additional netblocks in a preferred fashion without authorization, affecting routing for the whole network.

Netblock hijack ● ● It is also possible to announce and route other peoples' netblocks without authorization, if you can convince your upstream to take the route. This happened – attackers stole a legitimately owned large netblock, announced it through their ISP, spammed and sent malware for about a week, and disconnected. This left the original owners nullrouted for a week, blacklisted everywhere, and with a huge mob of angry people at their door.

Configuration Review ● Check the configurations of your client against: – Secure BGP Template http: //www. cymru. com/Documents/secure-bgp-template. html – Secure IOS Template http: //www. cymru. com/Documents/secure-ios-template. html – Secure Jun. OS Template http: //www. cymru. com/gillsr/documents/junos-template. pdf – Secure Jun. OS BGP Template http: //www. cymru. com/gillsr/documents/junos-bgp-template. pdf

Peering Security ● ● Check the peering configuration of your target network. Data may be advertised from route servers. Ensure that authentication is in place for peering changes. Ensure that machines which are used for network policy are well secured.

Consider filtering best practices ● ● ● A recent survey by the RPSec Working Group of operators got a very rough idea of current filtering practices in the wild. The results indicate that many people, even security-aware backbone operators, are still not using all the tools at their disposal. Change management/network engineer time too expensive under their current business model? Or do they not care?

RPSec Survey Results – Yes Answers ● Incoming AS path filter for each of your BGP customers? (60%) ● Incoming prefix filter for each of your BGP customers? (80%) ● Set one or more communities for (BGP) customer routes? (80%) ● Outgoing AS path filter towards your peers/upstreams? (40%) ● Outgoing prefix filter towards your peers/upstreams? (53%) ● ● ● Filter outgoing updates towards your peers/upstreams based on communities? (67%) Do you need to make BGP configuration changes on more than one router when adding a BGP customer? (20%) 15 people surveyed – small sample size, but relevant placement(http: //www 1. ietf. org/mailarchive/web/rpsec/current/msg 01276. html)

Backbone vulnerabilities ● ● ● Where do you get your vuln info? Vendors – Cisco, Juniper, etc have internal bug databases requiring a customer login Mailing lists – public vulnerability announcements Vulnerability databases – OSVDB, CVE, etc. Previous work in the field done by FX, Paul Watson, Mike Lynn Ongoing work by many researchers

FX's Cisco research ● ● Cisco EIGRP spoofed packet neighbor saturation bug (http: //www. osvdb. org/displayvuln. php? osvdb_id=18055) Cisco IOS CDP Neighbor Announcement Do. S – (http: //www. osvdb. org/displayvuln. php? osvdb_id=1969) Other vulnerabilities include GRE attacks, a Cisco IOS TFTP Server Advisory, Cisco VPN Concentrator Do. S code, Cisco ICMP Advisory, and Cisco memory mapping and remote exploits (http: //www. phenoelit. de/ultimaratio/index. html) IRPAS tool for pen-testing (http: //www. phenoelit. de/irpas/)

Paul Watson and the TCP Window ● ● TCP stacks on backbone equipment (among others) failed to check RST packets against the window size as well as the sequence number. This allowed unauthenticated BGP sessions to have source and destination port guessed, spoofed, and easily reset. (http: //www. osvdb. org/displayvuln. php? osvdb_id=4030) In addition to strengthening the Cisco TCP stack with a patched version of IOS, MD 5 checksums on BGP sessions (“BGP password”) were implemented as a workaround. However, many NANOG engineers deemed this unnecessary after the facts were disclosed, and rolled back to unauthenticated sessions.

Mike Lynn and the remote shell ● ● ● Cisco box compromised, using a probable heap overflow in their processing of IP v 6 packets. Cisco box shoveled a shell with full enable privileges to a listening console session. For the first time, remote exploitation of a box running Cisco IOS appears demonstrably possible. Definitions of local exploit vs. remote exploit in question – how was he connected to the box? Looked remote to me.

This isn't the remote root you're looking for. ● ● Suddenly, Mike Lynn's talk has gone missing from the Black Hat handouts. Suddenly, Mike Lynn's presentation is no longer on the Black Hat CD. ● Suddenly, Mike Lynn's slides are not available. ● Lawsuits and threats abound.

Why we need disclosure ● "I feel I had to do what's right for the country and the national infrastructure, " he said. "It has been confirmed that bad people are working on this (compromising IOS). The right thing to do here is to make sure that everyone knows that it's vulnerable. " -- Mike Lynn, as quoted Wednesday in Security. Focus (http: //www. securityfocus. com/news/11259)

Suing researchers into oblivion is not the way to achieve security. ● ● Cisco and ISS filed suit against Mike Lynn on Wednesday afternoon, with a temporary restraining order prohibiting him from speaking about this exploit. (http: //www. securityfocus. com/news/11259) Thursday, an accord was reached between the parties, and an injunction was signed prohibiting Mike Lynn from ever talking about his exploit again. All materials had to be returned to Cisco. (http: //www. networkworld. com/news/2005/072805 -cisco-settlement. html) ● This is stupid. Pretending the problem didn't happen will not make it go away. The black hats certainly won't ignore it.

Dear Cisco and ISS ● ● In order to take security seriously, you must practice responsible disclosure. Ostrich tactics are not responsible disclosure. Hiding known vulnerabilites and trying to gag researchers even after a fix is available hurts both your reputations and the securityof the Internet. Developing and fostering good relationships with security researchers will help improve your products, and the Internet at large. Duh.

What he said – Mike Lynn Recap ● ● Heap overflows are far more common in IOS than straightforward stack exploitation. Watch for the Cisco watchdog check_heaps process, which will induce a router crash if it detects memory corruption. Cisco routers generally crash rather than attempting recovery, so you have one shot at your overflow before the router goes down. However, the crash process itself is interruptable.

What he said, II ● ● ● By interrupting the crashing process, and feeding the router a state where it already believes it's crashing, you can buy yourself some time. Spreading memory corruption on the heap is still a problem, so you'll have to manage that yourself in shellcode, or have 2 to 5 minutes before router memory failure is complete. Once you have gained execution, the router is yours, though you may have to disable interrupts from the hardware to keep the processor.

What he said, III ● ● ● Through methods like these, you can induce the remote box to shovel an enabled shell back to your listener. Root. Game over. Lynn indicated that about one in ten Cisco vulnerabilities looked promising for this sort of exploitation. Anything talking about memory corruption inducing a crash is a good start. ● http: //www. cisco. com/en/US/products/hw/routers/ps 354/products_field_notice 09186 a 00800946 c 8. shtml ● http: //www. cisco. com/en/US/products_security_advisory 09186 a 008029 e 189. shtml ● http: //www. cisco. com/en/US/products_security_advisory 09186 a 00803 be 77 c. shtml ● http: //www. cisco. com/en/US/products_security_advisory 09186 a 00803 be 7 d 9. shtml

What Cisco said, and didn't ● Cisco recently released an advisory warning about vulnerabilites in their IP v 6 processing. (http: //www. cisco. com/warp/public/707/cisco-sa-20050729 -ipv 6. shtml) ● “Cisco Internetwork Operating System (IOS®) Software is vulnerable to a Denial of Service (Do. S) and potentially an arbitrary code execution attack from a specifically crafted IPv 6 packet. The packet must be sent from a local network segment. Only devices that have been explicitly configured to process IPv 6 traffic are affected. Upon successful exploitation, the device may reload or be open to further exploitation. ”

Local vs. Remote Exploit, v 2. 0 ● In their advisory, Cisco claims the IP v 6 vulnerability only works if. . . “The packet must be sent from a local network segment. ” (http: //www. cisco. com/warp/public/707/cisco-sa-20050729 -ipv 6. shtml) ● ● A packet sent from one machine on your local subnet to another *is still a remote attack*. This sounds suspiciously like a remote root to me.

See for yourself. ● ● ● Input validation is good. Check the sources – validate Cisco's own advisories against their Full Disclosure archived postings, in case they change. Read FX's details of Cisco memory management on the heap for helpful disassembly and overflow technical details. http: //www. phenoelit. de/ultimaratio/index. html Also, there is http: //cryptome. org/lynn-cisco. zip

Towards a more complete methodology ● ● ● Treat backbone devices like computers – they do have vulnerabilities, and these can be tested and exploited. Treat backbone devices like very important computers – avoid Do. S outside the test lab without your client's permission, and tread carefully even with it. In time, these test tools will also become automated, and part of a pen-tester's kit. We're still kind of in the Dark Ages now.

Mirrors of this talk ● http: //www. nmrc. org/dc 13/Pen. Testing. The. Backbone. ppt ● http: //www. oneeyedcrow. net/tech/Pen. Testing. The. Backbone. ppt ● http: //www. infowarrior. org/users/rforno/raven-bh 05. pdf ● http: //www. attrition. org/misc/ee/Pen. Testing. The. Backbone. ppt ● http: //www. abditum. com/cisco/Pen. Testing. The. Backbone. ppt ● More mirrors to come

Thank you ● ● ● Feel free to contact me regarding this talk, or with feedback or additional ideas, at raven@nmrc. org Thanks also to Jericho and the OSVDB team, for prompt attention to vulnerability disclosure Thanks to my mirror sites, and to the EFF, for supporting security research and free speech.