Transcript Mitigation of Backbone Vulnerabilities

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 areaspecific contacts in case of a security
incident.
 Log verbosely enough to do good postmortem 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 netspace 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/secureios-template.html
 http://www.cymru.com/Documents/securebgp-template.html
 http://www.cymru.com/gillsr/documents/jun
os-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.
[email protected]
[email protected]