Security Tip of the day: Handling brute-force login attempts
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.
PWS Bankers 2.0
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 "...as 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.
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.
- 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.
Pedro Bueno <pbueno //&&// isc. sans. org >
XP local privilege escalation demonstrated
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.
Firefox 1.5.0.6 release imminent
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 1.5.0.5. Apparently, not all updates rushed out while a Blackhat conference is going on have a sinister reason :-).
Update 03:48 UTC: Firefox 1.5.0.6 is formally released. The release notes confirm it fixes an issue with Windows Media.
Comments