Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Security Tip of the day: Handling brute-force login attempts

Published: 2006-08-03
Last Updated: 2006-08-31 00:31:15 UTC
by William Stearns (Version: 2)
0 comment(s)
        Dustin wrote in to say that he had an ssh brute-force login program making over 4500 attempts over 2.5 hours today.  It appears none of them were successful.

        Brute-force login tools exist for just about any service that allows remote access.  How do you fight these?  Here are a number of approaches that can be used separately, or better yet, use all of them.  Make sure you have permission to do these.

- Make sure none of your user accounts have easy to guess passwords. Run a password cracker like crack or John the Ripper against your password collection to see if any are simple english words or easily guessed.

- Use a one-time password program or hardware password generator like those from Cryptocard or RSA.  Even if a password is viewed, it can't be re-used later.

- Disable remote root/Administrator logins on your systems.  It will still be possible to log in as a non-priviledged user and become the super-user, you just can't log in directly.

- Provide ssh key based logins to all your users, and when everyone's comfortable using them, disable password logins entirely.

- Run SSH on a different port.  SSH has no trouble doing this.  You need to tell the ssh server to run on a new port, tell any firewalls in front of those machines to allow connections to the new port, and tell any ssh client programs that need to connect to those machines to use the new port.

- Ban the IP addresses of tools that try to do brute-force logins.  A number of readers have written in with suggestions of tools to automatically ban scanners:  Chris: fail2ban, fail2ban howto, Ian: sshdfilter, Herb: denyhosts, Keith: Buford (no link at the moment).

- Submit your logs to Dshield so that attackers can be identified from their attacks on multiple systems.

- Limit logins to just the IP addresses of your known client machines.

Keywords: ToD
0 comment(s)

PWS Bankers 2.0

Published: 2006-08-03
Last Updated: 2006-08-03 22:23:01 UTC
by Pedro Bueno (Version: 2)
0 comment(s)

PWS-Bankers 2.0

Some time ago I was reading about Phishing 2.0 , as the evolution of Phishing attacks. In that case, the miscreants were making use of multiple and different attacks tying to beat the new security methods adopted by the financial institutions, like One Time password. According the news report, Horward Schmidt said " more people become aware of current "phishing" scams, the cyber criminals often get even more clever, and create new, more sophisticated techniques,". That's the famous cat and mouse game.

The new security methods adopted by banks were created in response to the huge amount of attacks suffered by their customers and the huge amount of money that they are loosing over the years, and it was working, until the miscreants decided to create new techniques to defeat them.

Well, I have been talking to my fellow handlers before put this here, because I don't want someone calling me "hype maker",:) ,and I would like to present you another term: Banker 2.0.

 But what is Banker 2.0?

This represents the evolution of the banker trojans as well, to try to defeat the new bank security measures implemented for their customers.

Yesterday I was playing with a pws-banker trojan sample. In short, it was telling that it was a Bank Application to 'update' the bank digital certificate. Some Brazilian banks are adopting digital certificates for some large customers, so some transactions can only be done with those certificates.

 The interesting characteristics were:

  • was targeting just one south american bank
  • was asking for the bank digital certificate password
  • was harvesting the hard-drive for all *.key and *.crt files
  • was sending the Cert password and all *.key and *.crt files to a gmail account.

 McAfee AvertLabs has a good description of it, with screenshots:

So, banks are trying, with OTP, Tokens, Digital Certificates...but the bad guys are doing it as well creating new techniques to defeat them...the question is, where are the banks failing?

Pedro Bueno <pbueno //&&// isc. sans. org >

0 comment(s)

XP local privilege escalation demonstrated

Published: 2006-08-03
Last Updated: 2006-08-03 12:59:40 UTC
by Arrigo Triulzi (Version: 2)
0 comment(s)
An excellent Flash animation showing the latest XP local privilege escalation has been published and it clearly demonstrates how trivial it is to "upgrade" from a user with administrative privileges to SYSTEM (the same but for unprivileged users is currently disputed, more at the CVE entry covering the issue and on the Bugtraq archives).

How does it work?

It is actually quite simple: normally a scheduler is used for running non-interactive programs unattended, for example anti-virus updates (in the "baddies" world it is used for scheduling netcat backdoors but this is hardly "normal usage"). 

In this example the user decides to schedule running "cmd.exe" (the Windows command line prompt) rather than a non-interactive program.  When the scheduler triggers it starts cmd.exe which opens a new command-line window.

The problem is that the scheduler runs as the "SYSTEM" user which under Windows is an all-powerful user used for system tasks (the Windows equivalent of "root" under Unix) and, as this video demonstrate, it does not "drop privileges" (that is to say: "take on the privileges of the user requesting the scheduled job") before running the command.

When the command is finally run at the specified time it therefore hands you a command line prompt with SYSTEM privileges.

Is there a fix? Or indeed, why is this a problem?  Well, the fix would be to stop the scheduler which breaks lots of other things (e.g. anti-virus updates) but which an adminstrator can easily restart... Now, is it really a problem since an administrator doesn't gain much? Well, it should not be the case that running a scheduled job lands you different privileges by default and, of course, should it turn out that administrative privileges are not needed then it becomes a far bigger issue as any user could gain SYSTEM privileges.

Important note: do not watch this at work with your loudspeakers turned on (bad language disclaimer...).  Headphones strongly recommended.

Thanks to fellow-handler Swa for precious extra information.
0 comment(s)

Firefox release imminent

Published: 2006-08-03
Last Updated: 2006-08-03 02:52:10 UTC
by Jim Clausing (Version: 2)
0 comment(s)
It appears that the Mozilla folks are about to release Firefox (don't rush out and try to download it yet, the main Firefox page doesn't show it yet and for most of us, the automatic check will alert us to its availability).  No details at the moment on what this one fixes, but coming so quickly on the heals of, I would imagine that there must be some security implications.  We'll update this story as soon as the Release Notes are available.  And thank you to our ever faithful reader, Juha-Matti for alerting us to this.

Update 20:27 UTC:  If Bugzilla can be belived, all this update does is fix an issue with "mms://" and related multi-media URLs that have been broken in Apparently, not all updates rushed out while a Blackhat conference is going on have a sinister reason :-).

Update 03:48 UTC: Firefox is formally released.  The release notes confirm it fixes an issue with Windows Media.
0 comment(s)
Diary Archives