Pen-Testing the Backbone Raven || NMRC [e-mail]

1
Pen-Testing the BackboneRaven
NMRCraven_at_nmrc.org
2
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.

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

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

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

6
Code train vulnerabilities

• Check the vulnerabilities specific to each code
  train implemented in your network.
• Also check vulnerabilities in stacks/implementatio
  ns 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.p
  hp?osvdb_id809) 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.

7
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/disp
  layvuln.php?osvdb_id17644)
• 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?

8
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.)

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

10
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

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

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

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

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

15
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/gil
  lsr/documents/junos-bgp-template.pdf

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

17
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?

18
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-archi
  ve/web/rpsec/current/msg01276.html)

19
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

20
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_id196
  9)
• 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.d
  e/irpas/)

21
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.ph
  p?osvdb_id4030)
• 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.

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

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

24
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)

25
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/1125
  9)
• 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/07
  2805-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.

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

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

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

29
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/ps3
  54/products_field_notice09186a00800946c8.shtml
• http//www.cisco.com/en/US/products/products_secur
  ity_advisory09186a008029e189.shtml
• http//www.cisco.com/en/US/products/products_secur
  ity_advisory09186a00803be77c.shtml
• http//www.cisco.com/en/US/products/products_secur
  ity_advisory09186a00803be7d9.shtml

30
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-20
  050729-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.

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

32
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/ultim
  aratio/index.html
• Also, there is http//cryptome.org/lynn-cisco.zip

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

34
Mirrors of this talk

• http//www.nmrc.org/dc13/PenTestingTheBackbone.ppt
  
• http//www.oneeyedcrow.net/tech/PenTestingTheBackb
  one.ppt
• http//www.infowarrior.org/users/rforno/raven-bh05
  .pdf
• http//www.attrition.org/misc/ee/PenTestingTheBack
  bone.ppt
• http//www.abditum.com/cisco/PenTestingTheBackbone
  .ppt
• More mirrors to come

35
Thank you

• Feel free to contact me regarding this talk, or
  with feedback or additional ideas, at
  raven_at_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.