[plug] Trade [flame alert]

Christian christian at global.net.au
Tue Feb 29 12:44:02 WST 2000


Jeremy Malcolm wrote:

> Ah, but you wouldn't do it that way.  You would forge your mail
> headers and send it as a trojan (eg. attaching it to one of those joke
> email greeting files).  Admittedly this only works for Windows people,
> and stupid ones at that.  (It has always struck me as bizarre how the
> same people that get sucked into those virus hoax emails are the same
> people who send around 2Mb binary attachments.)

Even if you pretend to be someone else, what admin is going to install
an arbitrary program received by email from a stranger?  The attack
won't work.

> The example is not important.  The idea behind it is.  I haven't done
> much hacking-in-the-bad-sense (basically only to this one person, with
> permission), but I found that what you call "social engineering"
> attacks, and what I would call "lateral thinking", are much more
> successful than focussing on application security holes (how many
> years ago was the qpopper problem fixed, and how many skript-kiddies
> are still trying it?).

I call it "social engineering" because that is the name of this class of
attacks.  However, if you do a brief threat analyses, then you will
probably find that the biggest threat to your machines aren't your
friends and people you know but random, anonymous strangers on the other
side of the world who know nothing more about your system than it's IP
address.  Hence the social engineering attacks, while clever in some
ways, may not tell you as much as you would hope about the security of
your network.

As for qpopper, there was a vulnerability discovered in last month which
gives a remote user (who already knows a username and password) access
on the machine.  There was also an anonymous remote root problem with
qpopper four months ago.  Perhaps you should re-think your view on
application security holes?

> A few more examples that I found useful were:
> 
> (a)     if they use a Web mail service (which this guy did), click "I have
> lost my password", read the "password hint" question that it asks you,
> and do some research to find the answer (eg. ring up a member of his
> family to ask when his birthday is);

No admin in his right mind would use the same password.  This attack is
useless in the current context.

> (b)     if you know the person's family (which I did) or workmates, make
> an excuse to pay them a visit and gain physical access to his computer
> (which didn't actually work for me on that occasion);

Also useless since most of the people attacking your systems won't know
your family.

> (c)     once you find out enough of his passwords, but if the server
> itself only has SSH access and you don't have his private key, work
> out what other systems he has an account on, and see if you have an
> account on one of them yourself, or can access any of them via telnet.
>  Then once you've hacked that account, you can SSH to the server.

I like the way you gloss over "once you've hacked that account".  Even
if you get an account there you still need to provide a password or RSA
key to log into the next server.  This isn't an attack at all.

> The critical element in all of this is finding out the person's
> passwords and there are myriad ways of doing this, most of which are
> reliant on a bit of imaginative thinking.  This is the reason why I
> said that the first thing I would do when trying to hack a server is
> to discover the person's passwords.

I agree that passwords are a very weak authentication mechanism,
however, in light of this they are becoming increasingly irrelevant.  Do
you recall when the root password for that Linux PPC "hack challenge"
machine was publicised?  Also, the actual compromise that eventually was
achieved primarily using an insecure CGI script -- the publicly-known
root password was somewhat irrelevant.

Regards,

Christian.



More information about the plug mailing list