Router and Infrastructure Hacking First we take Manhattan, then we take Berlin

1
Router and Infrastructure HackingFirst we take
Manhattan, then we take Berlin

• Raven Alder, NMRC

2
Why bother?

• Control over your backbone is control over your
  data
• Man in the middle attacks, rerouting, selective
  data interruption
• Security for infrastructure lagging as a
  priority, operational awareness/caring not always
  present

3
You already know how

• Basic pen-test methodology holds, but particulars
  vary.
• Reconnaissance may now include who are their
  known BGP peers, what do the route servers say
  about how their block is propagated, do they
  list human POCs with the registrar.
• Gather data, map network/targets, attack, review,
  recurse.
• What hardware are they using? What version of
  software? What management or routing protocols?

4
Good backbone recon

• Stack fingerprinting is spottier, not helped by
  many many many possible code trains.
• Feed nmap database when you find something that
  you know
• Try service identification, looking in particular
  for CDP and SNMP
• Check for OOB access modems -- war dialing lives
  again, and many modems are poorly protected

5
Major surfaces of attack

• Weak passwords (boring but successful)
• Poorly defended web/admin interfaces
• Social engineering
• Authentication server hijack
• Tactical DoS/infrastructure replacement
• Protocol sniffing (easier than youd think)
• Direct attack/overflow
• Routing manipulation

6
Weak Passwords

• Defaults still enabled on an amazing number of
  infrastructure devices, great lists online
  (http//www.phenoelit.de/dpl/dpl.html)
• The more obscure the device, the more likely that
  the default has not been changed
• Admins often do not think to limit access to
  infrastructure devices, outward-facing or DMZ
  ones in particular
• Cracking and forcing programs increasingly
  popular -- MD5s can be fed to John the Ripper,
  cisco_torch or hydra to peg the routers

7
Web/Admin interfaces

• Often still open to world, should not be,
  vulnerable to standard webapp attacks. (Cookie
  LoggedIn True!)
• Look up the admin port if you can identify the
  device type , investigate defaults, known vulns.
• Reuse passwords, write similar crackers

8
Social Engineering (still works)

• Im Jane from RIPE, and we wish to verify your
  IP allocation we just need to log in and dump a
  copy of your routing table
• For attacks requiring physical access, a shiny
  hat will often get you access to the telco
  closet. (Extant outages hasten this.)
• Etc., etc., standards.

9
Authentication server hijack

• Many auth servers are running on poorly secured
  boxes, and are vulnerable to either OS exploits
  or attacks against the service itself.
• If you own the authentication server, you can
  grant yourself access to anything that queries it.

10
Tactical DoS/replacement

• Auth servers often DoSable
• Insert your own box after youve downed it
  (requires physical access or an appropriate
  wireless segment).
• This works for other devices, too -- end routers
  are also good things to become.
• Is a failover or backup path easier to
  compromise? Can you trigger a failure?
• When wireless is involved, this becomes far, far
  easier.

11
Protocol sniffing

• Many routing protocols broadcast to find
  neighbors.
• Many routing operators dont know/care that edge
  interfaces should be passive.
• Even many secure versions of the protocols do
  things like passing auth data in the clear.
• Again, wireless makes this worse.

12
Direct attack/overflow

• Possible though not publicly popular against some
  routers
• Many memory management bugs have the capability
  to become these, though stack and heap watchdog
  processes must still be addressed if present on
  the platform
• Extant bugs in incorporated software may be
  carried right along in, and updating/versioning
  is not always swift.

13
Routing manipulation

• If you can peer with a router, you can usually
  manipulate its routing tables
• With zebra or similar software suites, making a
  router-on-a-stick is easy
• Since more-specific routes are generally
  preferred, you can advertise someone elses space
  back to them and get priority
• Hijacking will be noticed (if not always
  understood), be aware
• You can also add a currently unused subnet routed
  to you (stealthier), or hijack someone elses
  block.

14
The trouble with logging

• Many infrastructure devices only log locally.
  This makes erasing evidence of a successful
  hijack easier.
• When such devices do log centrally, often
  authentication is cleartext or nonexistent. This
  leaves the messages open to interception and the
  log server open to DoS.
• Surprisingly few people watch the router logs
  unless theres a Problem, and even then, often
  only ACL denies and local error conditions are
  logged. This works to the attackers advantage.

15
Tools for the backbone pen-tester

• eigrp.pl in EIGRP Tools, http//www.hackingciscoex
  posed.com/?linktools
• Zebra for OSPF (http//www.zebra.org/)
• Yersinia for HSRP, CDP, and other layer 2 attacks
  (http//www.yersinia.net)
• Phenoelit's IRPAS and VIPPR tools
  (http//www.phenoelit.de/fr/tools.html)
• Cisco torch (http//packetstormsecurity.org/cisco/
  )
• CDP-tools for lying (http//freshmeat.net/projects
  /cdp-tools/)
• Hydra for brute force, Nmap amap for id

16
How difficult is this?

• Not many people with both the skillset and
  interest, but the number is on the rise
• A ticked off network engineer can wreak some
  serious damage
• More widespread interest after Ciscogate
• Hacking Cisco Networks Exposed book published
  last year, many tools referenced there have wider
  infrastructure capabilities

17
Defense best practices

• Test your infrastructure like you test your
  servers.
• White-box pen-testing, design audit
• Support with policy and incident response
  planning
• Patch management -- update IOS/CatOS/JunOS as
  needed

18
Policy and contracts

• Talk with your ISPs about security and
  responsiveness
• DDoS mitigation well known, but make sure theyll
  support you with other security issues
• Establish a good relationship before things are
  on fire.
• Have a security contact, just in case.

19
Incident Response

• Have network people designated as area-specific
  contacts in case of a security incident.
• Log verbosely enough to do good post-mortem
  analysis in the event of an attack.
• Tie this in to your existing security policy

20
Proactive backbone audit

• Check for leaking information -- a packet sniffer
  on your edge or untrusted networks will tell you
  a lot.
• Make sure that routing and management traffic is
  encrypted and authenticated whenever possible.
• Minimize unnecessary chatter when not debugging.

21
Encryption

• Use SSH rather than telnet to manage
  infrastructure devices
• SSHv2 beats SSHv1, but SSHv1 is better than plain
  old telnet
• Choose IOS images that support encryption
• Encrypt logs as they transit the network whenever
  possible

22
Authenticate routing

• Use BGP MD5 authentication with BGP peers
• Other internal gateway protocols will allow
  authentication keys to be added -- EIGRP, OSPF,
  IS-IS
• This reduces the risk of an outsider spoofing
  traffic as one of your routers

23
Stay wired

• Routing and management traffic over wireless is
  often the worst of all worlds
• Take extra security precautions, as just anyone
  can drive up and start talking to you.
• This isnt just not securing your data, its
  advertising.

24
Protect your auth servers

• Pen-testers attacking your authentication servers
  can hit gold.
• Logins for the entire network, or for net admins,
  are very valuable
• Never use cisco/cisco or other vendor defaults.
• Choose strong passwords that wont be brute
  forced.

25
Adopt defense in depth

• If your auth server is compromised, you want to
  see it. Firewalls, IDS, verbose logging on your
  devices, and an active monitoring system will all
  help.
• Management and policy support is crucial.
  Without this, even the best techies can fail.

26
Filter wisely

• Dont allow people to announce private net-space
  or your own blocks to you. Its probably bad.
• Only announce your own netblocks out. Egress
  filtering will save you embarassment.
• Consider bogon filtering.

27
Filtering, v2

• Only allow management workstations to connect to
  infrastructure devices
• Firewall your network sanely -- default deny is
  your friend
• Flag anomalous traffic coming from infrastructure
  devices compromised machines may show it (spam
  over telnet)

28
Update IOS/CatOS/JunOS

• Standardize on as few versions as possible that
  support your needed features
• Update when theres a new security threat.
• Work with your vendor to choose the right version
  for your network, and test thoroughly in the lab
  before deploying.

29
Lock down your devices

• Follow the secure router and BGP templates
• http//www.cymru.com/Documents/secure-ios-template
  .html
• http//www.cymru.com/Documents/secure-bgp-template
  .html
• http//www.cymru.com/gillsr/documents/junos-bgp-te
  mplate.pdf

30
What do I look for?

• Uptime and availability issues
• Sudden processor/memory spikes
• Read relevant mailing lists -- NANOG, your
  incident response list of choice
• Vulnerability disclosures or vendor notifications

31
Incorporating this

• Add a backbone device audit into your periodic
  network assessments
• Plan for patching and incident response just like
  any other network device
• Have your admins stay current via mailing lists
  and vendor bulletins
• Backbone security should be part of defense in
  depth

32
New areas of research

• Backbone/management crypto implementation testing
• Fuzzing of backbone protocols
• Exploit code vs. devices
• Strong mutual authentication

33
Creating new problems

• Identify the areas where you can input data or
  cause device state change.
• Figure out what you want from them. DoS?
  Authentication bypass? Access?
• The majority of new bugs found are not
  theoretically new attacks, theyre poor
  implementations of existing tech. Try what you
  know -- it may work.

34
Questions, comments, and flung tomatoes

• Case studies?
• War stories?
• Other?

35
Thanks for listening.

• raven_at_oneeyedcrow.netraven_at_nmrc.org