pen-testing the backbone raven || nmrc [email protected]

35
Pen-Testing the Backbone Raven || NMRC [email protected]

Upload: sharyl-williams

Post on 30-Jan-2016

297 views

Category:

Documents


0 download

TRANSCRIPT

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

Pen-Testing the Backbone

Raven || [email protected]

Page 2: 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.

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

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-of-service oriented.

● Since people get unhappy when you break their ISP, white-box testing is preferred.

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

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.

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

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.

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

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 JunOS boxes, for example – a BSD telnet vulnerability (http://www.osvdb.org/displayvuln.php?osvdb_id=809) also affected Cisco CatOS 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 DoS while scanning.

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

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?

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

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 MitM attack against the authentication server to harvest credentials? Is the auth server itself vulnerable? (RADIUS exploit goes here.)

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

ObSlide – 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.

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

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

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

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 DoS 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.

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

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.

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

Pwn3d 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.

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

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 has 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.

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

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 JunOS Template http://www.cymru.com/gillsr/documents/junos-template.pdf

– Secure JunOS BGP Template http://www.cymru.com/gillsr/documents/junos-bgp-template.pdf

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

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.

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

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?

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

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://www1.ietf.org/mail-archive/web/rpsec/current/msg01276.html)

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

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

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

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 DoS – (http://www.osvdb.org/displayvuln.php?osvdb_id=1969)

● Other vulnerabilities include GRE attacks, a Cisco IOS TFTP Server Advisory, Cisco VPN Concentrator DoS 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/)

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

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, MD5 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.

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

Mike Lynn and the remote shell

● Cisco box compromised, using a probable heap overflow in their processing of IP v6 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.

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

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.

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

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 SecurityFocus (http://www.securityfocus.com/news/11259)

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

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.

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

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.

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

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.

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

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.

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

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/ps354/products_field_notice09186a00800946c8.shtml

● http://www.cisco.com/en/US/products/products_security_advisory09186a008029e189.shtml

● http://www.cisco.com/en/US/products/products_security_advisory09186a00803be77c.shtml

● http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7d9.shtml

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

What Cisco said, and didn't

● Cisco recently released an advisory warning about vulnerabilites in their IP v6 processing. (http://www.cisco.com/warp/public/707/cisco-sa-20050729-ipv6.shtml)

● “Cisco Internetwork Operating System (IOS®) Software is vulnerable to a Denial of Service (DoS) and potentially an arbitrary code execution attack from a specifically crafted IPv6 packet. The packet must be sent from a local network segment. Only devices that have been explicitly configured to process IPv6 traffic are affected. Upon successful exploitation, the device may reload or be open to further exploitation.”

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

Local vs. Remote Exploit, v2.0

● In their advisory, Cisco claims the IP v6 vulnerability only works if...“The packet must be sent from a local network segment.”(http://www.cisco.com/warp/public/707/cisco-sa-20050729-ipv6.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.

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

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

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

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 DoS 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.

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

Mirrors of this talk

● http://www.nmrc.org/dc13/PenTestingTheBackbone.ppt● http://www.oneeyedcrow.net/tech/PenTestingTheBackbone.ppt

● http://www.infowarrior.org/users/rforno/raven-bh05.pdf

● http://www.attrition.org/misc/ee/PenTestingTheBackbone.ppt

● http://www.abditum.com/cisco/PenTestingTheBackbone.ppt

● More mirrors to come

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

Thank you

● Feel free to contact me regarding this talk, or with feedback or additional ideas, at [email protected]

● 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.