Re: Script Based Attacks & Form Hacks

[Stephen de Vries <stephen () corsaire com>]

On 22 Jul 2005, at 14:16, Vicente Aguilera wrote:
> > > To prevent automatic form submissions in login forms you can also  
> > > use:
> > >
> > > 1. One-time-logins/One-time-passwords
> > > For example, if the user password is: "a34.;(vad78!$" the   
> > > application can ask for the password: "Put the character   
> > > 1,5,2,6,8,9,10,4 of your password", and these positions could   
> > > change randomly.
> Automatic form submissions in login forms basically try to break  
> passwords or enumerate valid users (logins).
> If someone tries to guess a password with password cracking attacks  
> has not any more information in every attempt, because every time  
> the password is different. Password cracking attacks are not  
> effective with this method.

That's only true if the attacker can't duplicate the system for  
generating the one time password.  What I'm saying is that with the  
example given above, it will be trivial for an attacker to do this.

For example, on the server side, the app would:
1.  Pick 5 random numbers between 1 and 8 (assuming that all  
passwords have at least 8 chars), e.g. 1,5,2,6,8
2.  Present the login form and request that the user enter their  
username and the characters at positions 1,5,2,6,8 from their passwords.
3.  Process the details supplied, if incorrect goto 1.

To launch a brute force attack on this system, an attacker would:
1.  Get a dictionary of passwords.
2.  Write an automated script that grabs the login page from the  
target site and parses the HTML to extract the character positions  
requested.
3.  Run the script against the app and extract the character  
positions requested.  In this case 1,5,2,6,8.
4.  Read the current word from the dictionary.
5.  Extract characters 1,5,2,6,8
6.  Submit the login request with the username and the extracted  
characters.
7.  If the login fails, move to the next word in the dictionary and  
goto step 3


regards,
Stephen



> > > 2. Account lock
> > > For example after 5 unsuccessful attempts.
> >
> >
> > There is always the danger that an attacker could use this to  
> > lockout  all accounts on the system - which is also an effective DoS.
> Yes! An automatic reactivation of the account is necessary after a  
> prudential time.
>
>
> Regards,
> Vicente Aguilera Díaz
> OPST, OPSA, ITIL
> vaguilera () isecauditors com