[lug] What do you do about hackers (in the current sense of uninvitedobnoxious intruders)

[D. Stimits]

Bear Giles wrote:
> 
> > > Is there anything that can or shoud be done about folks trying to access
> > > /etc/passwd?
> >
> > This is normal for all kinds of authentication.
> 
> It's normal for all kinds of local authentication.  But anyone asking
> for it via the network should be viewed with extreme suspicion.

Depends. For NFS, quite a few PAM based auths, and I'm sure more that
depend on either a system directory of users (I'm loosely including
multiple means of doing this), all access it. Reading it is not a
problem. The suspicious nature is if they download it or the whole file
and are not interested in using functions that simply validate a given
name and pass. Some distributed authentications will access this, but it
will be via a system library function, not a read of the whole file.

> 
> > Stopping it prevents
> > even valid logins. That is why shadow passwords exist. The non-shadowed
> > versions still save passes in a one-way hash, but nowadays could be
> > cracked with a good dictionary (assuming old crypt functions; crypt with
> > sha-1 or md5 might be a *long* session, unless a set of high-probability
> > words were used for a pass and the cracker tests those first).
> 
> You still need salt.  Let's assume a dictionary of a million passwords.
> Hell, let's go for 10 million passwords.  SHA-1 is 20 bytes, plus another
> 12 bytes for the password itself.  That's only 320 MB, half a CD-R.  The
> other half of the CD-R could contain the same dictionary hashed with MD-5.
> If I use a B-tree index with a blocksize of 4k, that's a branching factor
> of a bit over 100.  So we're looking at 4 seeks (100^4 > 10 million) to
> look up any hash.

The first 2 characters are the salt for old crypt, and significantly
more for MD5. So it gives you the relevant salt, but that would mean you
would have to generate the entire dictionary with that one salt, or at
least until you hit the right combination. This is why it is suspicious
to see a download of the whole password file: It gives the opportunity
to use a pre-generated dictionary set based on the specific salt. Most
login functions have time delay increases or max errors before they
timeout for a while. Downloading the file itself does not present this
problem, so it isn't really a problem to see access via normal library
functions, only access via downloading or copy of the file is really
suspicious. Of course shadowed password files don't give away salts, nor
opportunity for a dictionary to compare one-way hashes (though they
still tell you who all the users are and what shells they use).

> 
> But with 12 bits of salt that 320 MB is bumped to 1.3 TB.  No longer
> impossible, but not something the casual attacker will have access to.
> 
> > Do you
> > have shadow on? If so, don't worry about someone reading it or even
> > copying it.
> 
> Unless it's being returned by a server with root access.

I don't know of any even semi-modern Linux distros that use root access
(of course there is IIS on win that runs as administrator, and plays
suid games to make it appear less vulnerable, but has just as many games
available to get admin level back). If someone has root access though,
almost none of the above matters anymore, it's already way too late.

> 
> BTW, it's usually not a good idea to encourage attackers but in this
> case I wouldn't mind a little servlet that dutifully returned a response
> to any "*/etc/passwd" file:
> 
>   root:x:0:0:root:/root/bin/bash
>   a:x:1:1:a:/home/a/a:/bin/bash
>   aa:x:2:2:aa:/home/a/aa:/bin/bash
>   aaa:x:3:3:aa:/home/a/aaa:/bin/bash
>   ...
>   zzzzzzzz:x:3512479453921:3512479453921:/home/z/zzzzzzzz:/bin/bash
> 
> Think their system could handle an /etc/password file with approx.
> 3.5 trillion entries?  (what is the number of valid user names?)
> The mere fact that a monster file containing a bogus password file
> should cause alarm among most competent sysadmins.  (Insert obcomment
> about MCSE here.)

Actually, a variation on this would be fun. Make it so that fake
accounts have passwords that if a dictionary finds it, and someone tries
to use it, a network sniffer triggers alarms and traces whatever it is
trying to use that name with the unencrypted pass (honeypot?).

> 
> > > 217.82.33.200 - - [12/Apr/2002:13:28:10 -0600] "GET
> > > HTTP://www.microsoft.com/ HTTP/1.0" 200 5714
> 
> I think this was a request for your server to act as a proxy.  If it
> succeeded, your server could be used to launch attacks on others... and
> you would catch any flak.

I would be highly surprised if the original attacker wasn't themself a
cracked machine.

D. Stimits, stimits at idcomm.com

> 
> Bear
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug