Re: Script Based Attacks & Form Hacks

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

Hi Chris,

On 22 Jul 2005, at 03:15, Christopher J Varenhorst wrote:

> <snip>

> As far as automated attacks go, HTTP is too slow for bruteforce  
> password attacks
> to be effective.

The objective of many brute force password attacks is not to gain  
access to one specific user's account, but rather to gain access to  
_any_ user's account.  Instead of targeting the few users who have  
strong passwords, attackers could target the users with weak  
passwords by trying, for example, 20 commonly used passwords against  
the known usernames.
The speed of an HTTP brute force attack is limited only by the server  
response time and the available bandwidth.  IMO even a regular DSL  
line provides sufficient bandwidth to launch a brute force attack.

>   Automated form posting will fill server databases with
> garbage, but I think its unlikely to bring the server to a  
> standstill. (maybe
> I'm wrong?)

I'd agree that in most web apps, having thousands of bogus user  
accounts won't be too much of a strain on the database, but what  
about attacks that are launched using those accounts?  Let's assume  
an attacker has managed to create a number of fake accounts on a web  
app and can therefore perform transactions with those accounts.  He  
could:
- Submit fake transactions that consume backend resources, such as  
complex searches.
- Submit fake transactions that target manual processes behind the  
service.  For example, a transaction that ends up in the hands of a  
human operator who needs to evaluate has a high processing cost.  If  
this transaction (and thousands like it) are fake, then the service  
could effectively be DoS'd.
- Submit fake transaction that incur a financial cost to the site  
owner.  E.g. each check by a third party on a credit card number  
incurs a small processing fee - whether that credit card number is  
valid or not.  Thousands of fake requests could result in a large  
processing fee and perhaps an effective DoS.


> A straight out DOS attack would be more effective at that.

And I think that's the reason we haven't seen many of these attacks  
in the wild.  It's simply much easier to use a DDoS system to bring  
an app to it's knees, than it is to create a sophisticated  
application DoS attack.  But app level DoS attacks have the advantage  
that they don't require as much bandwidth, so don't need all those  
zombies - proxies work just fine.

> Some
> http servers will even automatically block automated attacks like  
> this.

Only if they're coming from the same IP, and (as I mentioned in  
another reply) there are plenty of open proxies out there.

Regards,
Stephen

> Quoting Chad Maniccia <wopazar () gmail com>:
>
>
> > Hi List,
> >
> > One thing I have not heard any one discuss is the use of automated
> > scripts and form hacking. I could easily write a Java program to
> > attack any ASP,JSP,PHP etc.. simply by viewing the page source to  
> > find
> > the parameters the form processor will be looking for. You could use
> > this to fill up some ones database with garbage bring the server to a
> > standstill or worse yet bypass all the fancy javascript you had on  
> > the
> > calling page. Some web applications actually use javascript to
> > calcualte currency transactions.
> >
> > What ideas do you guys have to protect yourself from these?
> >
> >
> > Thanks,
> > Chad