Your router/switch may be less secure than you think
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: http://www1.cs.columbia.edu/~angelos/Papers/posse-chapter.pdf 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
On 8/3/05, Robert E. Seastrom <rs@seastrom.com> wrote:
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?
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). -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 encrypted email to the latter address please http://darkuncle.net/pubkey.asc for public key
On Thu, 4 Aug 2005, Scott Francis wrote:
On 8/3/05, Robert E. Seastrom <rs@seastrom.com> wrote:
Beer, unsupported assertions, and lack of rigorous audit methodology can be blended together to make one's code more secure?
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. -- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
--On August 3, 2005 2:10:10 PM +0100 Michael.Dillon@btradianz.com wrote: <...>
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... <...>
participants (5)
-
Joel Jaeggli -
Michael Loftis -
Michael.Dillon＠btradianz.com -
Robert E.Seastrom -
Scott Francis