Session Fixation Vulnerability on a Leading Bank's website

Session fixation vulnerabilities occur when:

    A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
    An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.

In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.

Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.


Summary :-

When an application does not renew its session cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).


Anatomy of a Session Fixation Attack :-

Step I :- Here is the request to the banking application

Step II :- The response from the application sets a cookie in the browser

Step III :- Modify the Session Id value in the Set-Cookie function. This will cause all of the subsequent requests from the browser to contain the modified Session Id.

Step IV :- Now when the same modified Session Id is sent in the request when the user tries to log into the application.

Step V :- Login successful with user supplied Session Id

The vulnerability has been reported to the bank, hope their response is quick.

Murder... Death... Kill... Whatever...

MDK3 is a WiFi tool that can be used for DOS Attack on APs or Beacon Flood among many other things. Now, MDK3 is available in BackTrack5. Here's the link to ASPj's website for MDK3.

MDK3 Features as listed on ASPj's Website :-
    Bruteforce MAC Filters
    Bruteforce hidden SSIDs (some small SSID wordlists included)
    Probe networks to check if they can hear you
    intelligent Authentication-DoS to freeze APs (with success checks)
    FakeAP - Beacon Flooding with channel hopping (can crash NetStumbler and some buggy drivers)
    Disconnect everything (aka AMOK-MODE) with Deauthentication and Disassociation packets
    WPA TKIP Denial-of-Service
    WDS Confusion - Shuts down large scale multi-AP installations

# mdk3 

BEACON FLOOD (FAKE AP)

First lets see the how the Beacon Flood (Fake AP) works.

There are 3 types of packets in 802.11 :-
 - Management
 - Control
 - Data

Beacon Frame is a subtype of Management Frames --> Subtype 8
Beacon Frames are broadcast frames which are sent out periodically by APs to broadcast their presence.

Everything is in plaintext inside a Beacon Frame. So, if we spoof a Beacon Frames, WiFi devices  in the vicinity will report a new AP.

# mdk3 --help b

The Beacon Flood will create a Fake Access Point in the sense that it starts broadcasting Beacon frames using your WiFi card. So, all of the clients in the vicinity will detect a new AP.

The reason for doing a Beacon Flood could be several. It can be used for the MITM attack, or also a DOS,
since creating a fake AP with an SSID that already exists in range, cause the crash of wifi driver and its
scanner in the victim.

List of APs in range :-

# airodump-ng mon0 -c 6                      ->  To find list of APs in range

# mdk3 mon0 b -n mogambo -a -c 6                    ->  Start Beacon Flood on Channel 6 on interface mon0 with SSID mogambo

The Fake AP appears in the list of APs in range :-

Simple Case of URL Redirect Vulnerability

Description :-

URL Redirection is done when a website redirects a user to another trusted site.

URL redirection is sometimes used as a part of phishing attacks that confuse visitors about which web site
they are visiting.


Examples for URL Redirect Vulnerability:-

http://www.vulnerable.com?redirect=http://www.attacker.com

The phishing use can be more complex, using complex encoding:

Real redirect: http://www.vulnerable.com/redirect.asp?=http://www.links.com

Faked link: http://www.vulnerable.com/security/advisory/23423487829/../../../redirect.asp%3F%3Dhttp%3A//www.facked.com/advisory/system_failure/password_recovery_system

Impact :-

A remote attacker can redirect users from your website to a specified URL. This problem may assist an attacker to conduct phishing attacks, trojan distribution, spammers.


Solution :-

To avoid the open redirect vulnerability, parameters of the application script/program must be validated before sending 302 HTTP code (redirect) to the client browser. The server must have a relation of the authorized redirections (i.e. in a database).

POC :-

Here is a case of URL Redirection where the website does not validate the URL before redirecting the client.

A simple change in the redirect address can redirect the client to the attacker's site.