[Owasp-london] London WAF event and HacmeBank

Dinis Cruz dinis at ddplus.net
Sun Apr 23 21:08:02 EDT 2006

Since you might be interested, I am forwarding the email sent to the WAF
vendors that will participate on the next Owasp-London chapter event.

Note 1: The server mentioned ( is a server that I
just got from Rackspace and is currently dedicated for HacmeBank and
SiteGenerator tests. For obvious reasons, most of the server's pages are
password protected (except the install folder which is available to
anonymous users). If  you want to have access to this server (for
example to test HacmeBank V2 or SiteGenerator),  drop me an email with a
promise that you will not blow up the server (using HacmeBank's or
SiteGenerator's vulnerabilities) and I will send you an account to use.

Note 2: At the end, I've included a 'quick & dirty' list of HacmeBank
vulnerabilities and exploits (organized using the Owasp Top 10)

Best regards

Dinis Cruz
Owasp .Net Project

-------- Original Message --------

Subject: 	London WAF event - Operational notes
Date: 	Mon, 24 Apr 2006 01:28:18 +0100
From: 	Dinis Cruz <dinis at ddplus.net>

Dear F5, Imperva, NetContinuum, Fortify and Breach

Here are a couple operational notes for this Tuesday's Owasp-London WAF

    * The objective of this event is to create an environment where you
      (WAF vendor) are able to show your product in a scenario where
      WAFs add real value and business benefits. Please use it wisely
      since the audience is made of your potential clients.
    * For practical reasons (and due to a bug in SiteGenerator which is
      causing it to misbehave in some installation environments) we will
      use the latest version of Foundstone's HacmeBank (also Open Source
      and also developed by me)
    * I want you to focus your 15m/20m slot on how your product is able
      to mitigate against vulnerabilities that exist in HacmeBank.
    * At the end of this email I am including the specific HacmeBank
      vulnerabilities that I want to you to focus on (i.e. mitigate).
    * Ideally you should do a live demo since you (if participating)
      will have the products at InfoSec. This will help to maximize the
      impact of your presentation,
          o If that is not possible , then you can show pre-recorded
            videos (using for example Snag It). These videos can also be
            used as a backup in case there are some technical issues on
            the day
          o Please don't bring PowerPoints about your product. That said
            I don't see a problem with you making available to the
            audience marketing material about your product (i.e.
            brochures, CDs, etc...)
    * The version of HacmeBank that will be used is v2.00 which you can
      download from
          o Web Services installer:
          o Website Installer:
          o HacmeBank User and Solution guide (pdf):
    * In order to facilitate your tests I have set-up a server which you
      can use. This server contains a fully operational version of
      HacmeBank and you can access it here using
      the user name and password which I will send you in my next email.
    * Two changes on the event's schedule and presentations:
          o Fortify will not present the Asp.Net version of their WAF
            solution (still under development). Fortify will present how
            their J2EE solution is able to mitigate Owasp's Web Goat
          o Breach Security will be also participate

I known that you (WAF vendor) is having limited amount of time to
prepare for this event, but (on the positive side)  it does accurately
simulate a scenario where:

    * "...  critical vulnerabilities have been identified on a very
      important website ..."
    * ".... no code changes can be made ..."
    * ".... vulnerabilities MUST be mitigated as soon as possible ..."

Deployment is another area which I (and the event's audience) will be
very interested in, namely:

    - WAF installation and setup -  how long does it take to get the
appliance installed and working
    - 'Patch' rules deployment - how long does it take the to install
and active the relevant rules

I understand why some of you are having some reservations in bringing
the WAF appliance to the pub and setting it up there. All I will say
that if you do it (and it all goes smoothly) you will score a lot of
points with your potential clients. After all, if you are not able to
install and deploy your product in such environment, what changes will
your clients have when faced with a similar situation (having to deploy
ASAP a WAF on a site under attack ).

For me the the best WAF solution will be the one that :
    - is installed with minimum changes to the current environment,
    - is quick to install and activate
    - allows a quick and flexible upload/update of rules (i.e. patches
for known vulnerabilities)
    - has NO impact on the pages that have no rules assigned to

This last point is very important. When deploying a WAF on an existing
website, there is no margin for error on pages/forms that are not
affected by the vulnerabilities targeted by the WAF (i.e. the WAF cannot
have any negative side-effects).

The final objective is to resolve 100% of the known vulnerabilities 
with no negative impact on the website's functionality.

Please see at the end of this email the list of the HacmeBank
vulnerabilities that I want you to focus your presentation on.

Best regards

Dinis Cruz
Owasp .Net Project

HacmeBank v2.0 vulnerabilities (organized using the Owasp Top 10)

A1 Unvalidated Input

    Vulnerability: Account Transfer validation for negative values is
only performed at the client:
    Exploit: Use a proxy (or a browser tamper plugin) to inject a
negative number in the Form (this will
transfer an amount TO the source account FROM the target account (i.e.
the opposite of expected behavior)

    Vulnerability: Maximum number of login attempts is controlled by
client-side cookie
    Exploit: Use a proxy (or a browser tamper plugin) to change the
value of the CookieLoginAttempts (for example to 5000)

A2 Broken Access Control:
    Vulnerability: Admin pages available to anonymous users:
    Exploit after login, a normal user is able to access the following
admin pages:\Fetch_Web_Page\Manage_Accounts\Manage_Messages\Manage_Users\Sql_Query\Web_Services
        Note: these pages must be available to valid administrators

A3 Broken Authentication
    Vulnerability: Session Hijacking via ASP.NET_Session cookie
    Exploit: discover a valid ASP.NET_Session cookie, and hijack that
account by changing the cookie on the browser or injecting it via a proxy

    Vulnerability: Admin site protected with weak cookie
    Exploit: Access to the admin site is controlled by a client side
cookie called 'admin' (On login, this value is false, and set to true
after successful Response to the Challenge posted here To access
the admin area, login as a normal user and change the value of the
'admin' cookie from false to true

    Vulnerability: WebServices are accessible by anonymous users:
    Exploit: Access the WebServices directly
A4 Cross site Scripting (XSS):

    Vulnerability: Cross site Scripting (XSS)
    Exploit: Insert XSS payload in:
        - Account Transfer 'Comment': field
        - Request a Loan' 'Comment' field:
        - Post Message 'Subject' or 'Text' fields:

A6 Injection Flaws

    Vulnerability: SQL Injection
    Exploit: Insert SQL payload in:
        - Login Page 'Username' or 'Password' fields:
        - Transaction Details account_no GET field:
        - Account Transfer 'Comment': field
        - Request a Loan' 'Comment' field:
        - Post Message 'Subject' or 'Text' fields:

A7 Improper Error Handling
    Vulnerability: Detailed error messages sent to client:
    Exploit: Force SQL errors on:
        - Login Page 'Username' or 'Password' fields:   
        - Account Transfer 'Comment': field
        - Request a Loan' 'Comment' field:

A8 Insecure Storage:
    Vulnerability: SessionState contains Challenge's Response
    Exploit: 1) Decode the ViewState from the Admin Section login page
(, 2)
discover the Challenge's Response value in the decoded ViewState, and 3)
use that value to login to the admin area (the Challenge's Response
value is stored in a Asp.net control which is marked with
'visible=false' (but still stored in the ViewState))

    Vulnerability: Challenge's Response weak encryption
    Exploit: Brute force the Challenge's Response since it is calculated
by XORing the Challenge against a simple number

A10 Insecure Configuration Management

    Vulnerability: Directory Listing Enabled
    Exploit: Open the page   

More information about the Owasp-london mailing list