Leveraging Router & Infrastructure Hacking for Cybersecurity Fortification

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 you’d 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) • “I’m 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 you’ve 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 don’t 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 else’s 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 else’s 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 there’s a Problem, and even then, often only ACL denies and local error conditions are logged. This works to the attacker’s advantage.

15. Tools for the backbone pen-tester • eigrp.pl in EIGRP Tools, http://www.hackingciscoexposed.com/?link=tools • 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 they’ll 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 isn’t just not securing your data, it’s *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 won’t 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 • Don’t allow people to announce private net-space or your own blocks to you. It’s 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 there’s 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-template.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, they’re 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@oneeyedcrow.netraven@nmrc.org