From: Pablo Fernández (newsclient@teamq.info)
Date: Wed May 18 2005 - 12:12:39 EDT
First things first, on the disclosed username thing, as you say the only
attack that pops up to my head is a bruteforce attack (assuming that
your web isn't vulnerable to SQL injection). You can easily prevent a
bruteforce attack counting the number of login failures on a particular
user. Paypal does it, Hotmail does it, VNC >= 3.1 does it and many more
too, all you have to do is record the number of login failures since
last proper authentication, if that number reaches to 15 (or 90,
crackers should be reaaaly lucky to get in the first 100 tries) the
account should be blocked and manually reactivated once the user is
validated.
Anyway, don't think your system has been compromised just because a
username has been disclosed, I can also assume you have a username
Roger.Olstad in the host pax.priv.no, but there's not much to with that
(other than a bruteforce attack...).
Now, on the "web-server audit", yes, there's some software capable of
bruteforcing using thread modes, I just read a bit about it, but never
really tested it, it's called AccessDriver. Anyway an script in perl,
bash, php or whatever you want is reaaaally easy to make...
And on the password strength checking there're many ways to do it, you
could try to crack them with john the ripper and a basic dictionary (or
with the -incremental flag). I know PAM has some module for checking
strength too, you could do some research on that as well.
Well, that's it, I think I cover all the topics, just hope this helps a
bit.
Bye!
Pablo Fernández
attached mail follows:
Hi!
I have this web-based service/directory which offers users access through a username/password-authentication process. I am wondering what if some of the usernames are compromised, and I actually don't want to change the username? Are there any tools able to run some kind of bruteforce-attack or something, against my web-authentication? Other alternatives? Do I really have to consider my whole system as compromised just because a username may be lost?
In addition, does anyone know of any tool that can help me audit the web-server regarding to passwordpolicy, passwordstrength etc.
I appreciate all relevant answers :-)
Very best
R
-----Original Message-----
From: Erik Kamerling [mailto:ekamerling@snaplen.com]
Sent: 17. mai 2005 16:13
To: pen-test@securityfocus.com
Subject: Re: Cisco VPN Concentrator GUI
My original response never made it so here it is again.
On Sunday 15 May 2005 23:09, kaps lock wrote:
> i cant find any vulenrabilites on the net ....to
> explain to the person....only thing i can think of is
> brute forcing the username pasword field...which is
> again a challenge for web vpn..any ideas??
> thanks
Hi Kaps Lock,
You might want to impart info to your client regarding the common sense
security measure of limiting access to the HTTPS interface on the
concentrator to only trusted management hosts or internal networks.
Enabling uncontrolled public side HTTP(S) management of a VPN concentrator
gives out way more info re: their VPN than most people would want IMHO.
I don't believe HTTP(S) is enabled by default (at least on a public interface)
on a 3000 series concentrator so someone turned it on most likely.
3000 series concentrators are vulnerable to a SSL attack prior to version
4.1.7.A so you might want to point this out to them. The attacker does not
need to authenticate and can effectively reload the device or make it drop
user connections.
Here is the advisory ->
http://www.cisco.com/warp/public/707/cisco-sa-20050330-vpn3k.shtml
And a more general view on 3000 vulnerabilities ->
http://www.cisco.com/warp/public/707/vpn3k-multiple-vuln-pub.shtml
Best Wishes,
Erik Kamerling
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:21 EDT