Transcript attrition.org

Pen-Testing the Backbone
Raven || NMRC
[email protected]
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.
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-ofservice oriented.
Since people get unhappy when you break their
ISP, white-box testing is preferred.
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.
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.
Code train vulnerabilities
●
●
●
Check the vulnerabilities specific to each code train
implemented in your network.
Also check vulnerabilities in stacks/implementations 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.php?osvdb_id=809) 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.
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/displayvuln.php?osvdb_id=17644)
●
●
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?
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.)
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.
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
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.
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.
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.
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.
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/gillsr/documents/junos-bgp-template.pdf
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.
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?
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/mailarchive/web/rpsec/current/msg01276.html)
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
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_id=1969)
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.de/irpas/)
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.php?osvdb_id=4030)
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.
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.
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.
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)
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/11259)
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/072805-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.
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.
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.
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.
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/ps354/products_field_notice09186a00800946c8.shtml
●
http://www.cisco.com/en/US/products/products_security_advisory09186a008029e189.shtml
●
http://www.cisco.com/en/US/products/products_security_advisory09186a00803be77c.shtml
●
http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7d9.shtml
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-20050729-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.”
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.
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/ultimaratio/index.html
Also, there is http://cryptome.org/lynn-cisco.zip
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.
Mirrors of this talk
●
http://www.nmrc.org/dc13/PenTestingTheBackbone.ppt
●
http://www.oneeyedcrow.net/tech/PenTestingTheBackbone.ppt
●
http://www.infowarrior.org/users/rforno/raven-bh05.pdf
●
http://www.attrition.org/misc/ee/PenTestingTheBackbone.ppt
●
http://www.abditum.com/cisco/PenTestingTheBackbone.ppt
●
More mirrors to come
Thank you
●
●
●
Feel free to contact me regarding this talk, or with
feedback or additional ideas, at [email protected]
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.