Re: How could this account have been cracked?


"robb@xxxxxxx" <robb@xxxxxxx> wrote in
news:1159213301.256959.273420@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

Thanks for the replies -

Ian Kilgore wrote:
Can you clarify on the meaning of 'console'? Do you mean you logged
in to the compromised machine remotely from a box in your office, or
do you mean that you logged into the compromised machine via /its/
console (ie not remotely)?

Yes - from the Machine's console.

So the account's existence was probably not revealed by the login (if
there were already a keylogger on the system, you were flat screwed from
the start). Don't rule out the possibility that the account was
discovered through one of several well-known user-enumeration attack
techniques (i.e. apache returning 404 not found for x.x.x.x/~bogus_user
and 403 forbidden for x.x.x.x/~valid_user, and therefore allowing
straightforward enumeration of accounts).

Also don't rule out that the original compromise was not made via this
account, but via some other remote hole. Once having access to the
system, listing /etc/passwd (not the shadow, but that's irrelevant for
usernames) is easy as pretty much any user. If the password was weak,
then it could have been subsequently compromised after discovery of the
account name (and it was probably an account worth noting, i.e. in the
wheel group, etc).



I never connected remotely to the box as that user.
process, etc.

Arguably, that sounds like there was no 'person' involved, just an
ssh bot.

Interesting.

I realized that my security scheme had lagged behind my lifestyle: I
only now ever connect remotely from one location, and so I now deny
all ssh connections by default and allow just the one.

Does anyone know - is there a rootkit that can circumvent hosts.deny
as I described above?



Irrelevant really, hosts.allow/deny will be in force before your system
is compromised. After it is compromised, you don't have control of the
system anyhow, and it won't really matter. They could have a shell
connected back OUT to themself as easily as open an incoming port.

-Nathanael


.

Relevant Pages

  • Re: DJBs students release 44 *nix software vulnerability advisories
    ... In the nasm case, a local use must run nasm ... therefore requireing a local account. ... In my opinion, remote exploits are ... > compromise the target account. ...
    (Bugtraq)
  • Re: Ten least secure programs
    ... djbdns) or no history of anything major or that would compromise the ... remote exploits, though these are all multi-user systems that I speak of, ... Server administration, security, programming, consulting. ... marketshare. ...
    (Security-Basics)
  • Re: DJBs students release 44 *nix software vulnerability advisories
    ... Then you install NASM. ... compromise your account. ... That is why it is considered remote. ... compromise the target account. ...
    (Bugtraq)
  • Re: More FYI
    ... > corporate networks for remote client computers. ... > A remote attacker may exploit this flaw to remotely compromise any VPN-1 ... > has developed functional exploit code for this vulnerability and has ... Attackers will be able to run commands under the ...
    (comp.security.firewalls)
  • Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
    ... If by remote you mean "live interaction by the hacker at the point ... , then no, it's not a remote attack. ... remote compromise) is that the result of a successful attack is ... Hosted and sponsored by Secunia - http://secunia.com/ ...
    (Full-Disclosure)