Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

[Fwd: London WAF event - Addidional vulnerabilities]

Subject: [Fwd: London WAF event - Addidional vulnerabilities]
Date: Mon, 24 Apr 2006 23:10:34 +0100
Here are a couple more interesting vulnerabilities from HacmeBank (Note:
most are not mentioned in the Foundstone HacmeBank 2.0 User Guide pdf)

Dinis

-------- Original Message --------
Subject:        London WAF event - Addidional vulnerabilities


Dear F5, Imperva, NetContinuum, Fortify and Breach

Following the positive response (from some of you) regarding the
successful mitigation of most of the vulnerabilities included on my last
email, here are 6 additional vulnerabilities (harder to mitigate):

    Vulnerability: Users are able to access account details belonging to
other users:
    Exploit: log-in as user jv and open the page
http://209.97.215.160/aspx/Main.aspx?function=TransactionDetails&account_no=5204320422040001
    replace the 'account_no' GET value with 5204320422040003 (i.e.
http://209.97.215.160/aspx/Main.aspx?function=TransactionDetails&account_no=5204320422040003)
and note that you are now accessing account details belonging to another
user (in this case the user jm)

    Vulnerability: Old Password requirement is not enforced in 'Change
Password' page    
    Exploit: Hijack user session (using for example a valid user's
Session Cookie), open the page
http://209.97.215.160/aspx/main.aspx?function=PasswordChange and change
that user's password (without knowledge of that user's current password)

    Vulnerability: ViewState replay vulnerability
    Exploit: The source account on the Transfer Funds page
(http://209.97.215.160/aspx/main.aspx?function=AccountTransfer) is
controlled by ViewState. This means that the attacker cannot change this
value by POST form injection, but means that if the attacker is able to
grab a valid ViewState from another user (via Xss, cached copy of that
page on a Hard Disk or by sniffing the traffic), it can replay that
ViewState and make transfers from that account (to an external account).

    Vulnerability: Web Services Session ID is not enforced
    Exploit: Invoke the web services directly without needing a valid
SessionID.
    Solution: the correct resolution of this vulnerability is one where
the Web Services are still publicly available but control to the exposed
Web Services functionality is managed via the SessionID

    Vulnerability: 'WAF redirect on attack detection' information leak
    Exploit: The normal WAF functionality of redirecting attacks
detected to a custom error pages, provides information to attackers that
such type of defense (WAF) is in use, and creates very dangerous 'False
Positive' situations where valid user's input could be wrongly flagged -
something that would severely affect the user experience and business
value (imagine a user filling a 4 page web form being redirected to the
error page on the last page).
    Solution: Dynamically 'normalize' potentially malicious input. For
example, on a Form field vulnerable to SQL Injection, rewrite that field
with only the allowed chars (for example letters and numbers) and flag
an attack

    Vulnerability: "How do we know we are being attacked?"
    Exploit: Attack the website via 1) the vulnerabilities that are not
'patched' or 2) pages not protected by WAF (i.e. with no rules applied)
    Solution: Alert WAF operational staff when such attacks are occurring

Finally here is one last question and demo request: "If your WAF has a
Web Interface, are you able to protect it using your WAF?"

After all presentations are done, there will be Panel Discussion (with a
representative from each WAF vendor) where we will discuss ideas and
solutions for the mitigation of the most complex vulnerabilities.

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net  




-------------------------------------------------------------------------
Sponsored by: Watchfire

Watchfire's AppScan is the industry's first and leading web application 
security testing suite, and the only solution to provide comprehensive 
remediation tasks at every level of the application. Change the way you 
think about application security testing - See for yourself. 
Download a Free Trial of AppScan 6.0 today!

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000007kaF
--------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>
  • [Fwd: London WAF event - Addidional vulnerabilities], Dinis Cruz <=