One of the things that have stopped many
people of having executed commands on
the router side is that the lg uses
autocommand (rsh) on the router side.
This very effectively prevents the usage
of control chars to manipulate the router.
You simply receive
"sh ip bgp ^... sh us"
"invalid autommand:"
Please note, that this is really invalid
autocommand.
If you use telnet the above automatically
[if you miss control chars through the input]
goes directly to the router, end gets
executed.
One of the best solutions to this and other
problems related to the lg exploitations
is to deny authorization of commands on the
router side, that are not net mngmt related.
This can be done through 2 different approches:
1. Tacacs+ authorization
2. Exclude the non-relevant commands on the router
side through the exec-level control of the cisco
routers.
Of course, the server side, is vuln. too.
I have seen the early versions of lg, or home
made corrections to some lg codes, that pass
shell meta characters too.
And the problems mentioned like
sh ip bgp
selected but you added something at the box,
as *.$ or bgp nei works on most of the lg codes.
But my point is that may be rsh is better than
telnet.
Please, note that control chars may be passed to
the router only if the LG is configured to use
telnet.
If it uses rsh and it is done on the router side
with autocommand, then it passes control chars to
the router, but they cannot be executed.
With telnet you have terminal emulation and on the
cisco side you have full blown vtXX terminal
which accepts and recognizes control chars...
This can be disabled [on the cisco side] with
"no terminal emulation" under the conf t ...
and vty .. ..
I am no sure if this will stop the cisco to
interpret the control chars send to it.
-----
Hi list,
I answered the original post but the
submission did not go through.
In brief: the original David Kern looking
glass has a number of
problems. These are inherited in most code derived
from it:
1. The only security measure used in the code
is a http-referer check
which is a parameter suppplied by the user and can be
changed at will.
2. The parameters supplied to a rsh executed
on the local machine are
not checked. It is executed via fork/exec, not a perl
pipe open so shell
expansions cannot be used, but it still leaves
possibilities for supplying rsh
with bogus arguments
3. The parameters suppplied to the router are
not checked properly. The
only check in the original looking glass is a check
for NULL param so that the
router does not try to do a full BGP dump. This check
is bogus as well because
one can supply an argument of a regular expression to
the sh ip bgp. This
argument can resolve to the full BGP table and cause
arbitrary additional
router load. So any router accessible via non-fixed lg
can be effectiviely
DOSed up to full CPU load.
The solution to this unfortunately is full
rewrite from scratch using
CGI.pm, perl's Net::telnet instead of rsh/fork/exec
and proper parameter
checking/mangling.
I have done this in the past so at least a few
LGs I know of are not
vulnerable ;-)
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
