Router and Infrastructure Hacking

First we take Manhattan, then we take Berlin…

Raven Alder, NMRC

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

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?

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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

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.

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

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

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

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.

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.

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.

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)

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.

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

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

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

New areas of research

Backbone/management crypto implementation testing

Fuzzing of backbone protocols Exploit code vs. devices Strong mutual authentication

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.

Questions, comments, and flung tomatoes

Case studies? War stories? Other?

Thanks for listening.

raven@oneeyedcrow.netraven@nmrc.org