>Roy wrote:
>>
>> I think you are wrong on this one. Dial in with something like
>> hyperterminal and DON'T use PPP. Access as !root and login. Turn
>> debugging on. Disconnect and watch the fun as someone tries a PPP
>> connection while debugging info comes out the port.
>
>If you do that with out issueing a "set debug off' and "reset console" then it
>doing what is expected.
I guess you aren't getting the point. The point is that if for instance
someone inadvertently got booted, they may not realize it and these flags
would stay on. In fact, it has been postulated that through social
engineering and this knowledge combined with a clueless sysadmin and you
could reap usernames and passwords in this way. Get a throwaway account
on your favorite bogus ISP. All you have to do is to get tech support to
fire up debug either manually or via one of these PPP support tools
claiming to have severe modem problems. (Better yet if they are leaving a
PPP monitor on via script, then you can launch an attack at o'dark-thirty
when there isn't anyone around to watch or stop you) Then once they have
done it, login and launch a DoS attack against the tech support guy's
machine till it dumps off (probably Windoze anyway). Then telnet in (if
this guy doesn't filter his own dialups - remember he is clueless) Or
just keep hitting the dial-in port until the debug in appears, capture it,
then use the freely available PPPDecoder or the new tool and reap
usernames and passwords. Viola!
The fundamental design of the system shouldn't require a manual login and
two commands to be issued to 'reestablish' security on the system. It
should turn the debug flag off when the session closes. The code would be
something like... Session closing, Was console set on this session?, If
yes, reset debug flags, reset console.
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>