Michael Lynn is not the only person out there reverse engineering
routers, switches, printers and other embedded systems. Lynn's
presentation gave far less info than other people have published.
One person has published detailed instructions on how to exploit
IOS including code to do the exploit and an example scenario
of how to use it.
Contrary to what some may be worrying about, it it not the GSRs
that are most at risk. It is those old 2500's that are connected to
your customers. Imagine that one of those customer routers is
exploited, the hacker installs a tunnel, and then proceeds to
anonymously probe the customer's network. This is the real risk
and it may very well be happening right now to one of your customers.
The following is one of the slides from a black hat presentation
which is basically a primer on reverse engineering and
exploiting embedded systems.
--------8X----------------------
How to protect
Cisco specific
! Have no overflows in IOS
! Keep your IOS up to date
! Do not run unneeded services (TFTP)
! Tell your IDS about it. Signature:
\xFD\x01\x10\xDF\xAB\x12\x34\xCD
! debug sanity might stop less
experienced attackers
! The hard way: config-register 0x00
! Perform logging on a separate segment
! Protect your syslog host
---------8X-----------------------
Other slides in the presentation talk about exploits in networked
HP printers and various other brands of switches and routers.
I think this should serve as a wakeup call to the entire industry that
current engineering practices are not good enough any more.
We should all be looking to the security auditing work done by
the OpenBSD team for an example of how systems can be
cleaned up, fixed, and locked down if there is a will to do so.
--Michael Dillon
Michael.Dillon@btradianz.com writes:
We should all be looking to the security auditing work done by
the OpenBSD team for an example of how systems can be
cleaned up, fixed, and locked down if there is a will to do so.
Beer, unsupported assertions, and lack of rigorous audit methodology
can be blended together to make one's code more secure?
---Rob
> We should all be looking to the security auditing work done by
> the OpenBSD team for an example of how systems can be
> cleaned up, fixed, and locked down if there is a will to do so.
Beer, unsupported assertions, and lack of rigorous audit methodology
can be blended together to make one's code more secure?
Perhaps you aren't aware of what the OpenBSD team accomplished?
Their techniques may not be rigorously documented but they
have been used in other projects:
ABSTRACT
This chapter reports on our experiences with POSSE, a project
studying ?Portable Open Source Security Elements? as part of the
larger DARPA effort on Composable High Assurance Trusted Systems.
We describe the organization created to manage POSSE and the
significant acceleration in producing widely used secure software
that has resulted. ...
The OpenBSD team provide a brief overview of their process here:
http://www.openbsd.org/security.html
And a security consulting company describes the lessons of
OpenBSD here:
http://www.openlysecure.org/openbsd/security/sec_lessons
Their process has some parallels in the activities of groups like
the Columbia Accident Inquiry Board and the 911 Commission.
Openness, rigourous examination, attention to detail...
--Michael Dillon
<...>
Contrary to what some may be worrying about, it it not the GSRs
that are most at risk. It is those old 2500's that are connected to
your customers. Imagine that one of those customer routers is
exploited, the hacker installs a tunnel, and then proceeds to
anonymously probe the customer's network. This is the real risk
and it may very well be happening right now to one of your customers.
While I hate to possibly give ideas to (real) black hats in a public form but no doubt some have thought of this anyway....injecting routes into BGP to steal traffic. A crafty enough person could move traffic back over a tunnel or series of tunnels to be snooped. Yes, theoretically, it'd be noticed fairly soon, but how quickly is soon enough for $xyz critical application? That worries me more, because it only takes one insecure unfiltered setup (or even partially unfiltered setup) to announce something they shouldn't. Hopefully it wouldn't be global-reaching, but, it could be. How much do you trust your peers? How much should you? How much do you have to? For customers, it's obvious, for transit peers, maybe less so.
Just my two cents worth...
<...>
what unsupported assertions? The project's record speaks for itself.
Don't confuse Theo's lack of social graces with a lack of polish on
the project he leads (a common mistake).
You might bust out google and try and see what the oldest reference you can find to Robert Seastrom being associated with bsd development is...
Nanog-l is not someplace that we can rationally have a discussion of BSD internals or differing *BSD development/management styles.