August 25, 2016

GHR 109 – Session Hijacking

Objectives:

A session ID (a.k.a. token) ties the user credentials to the user’s HTTP requests and responses and the appropriate authorization to access resources is enforced by the web application.  As a hacker you want to capture, predict, or brute force the token in order to hijack the session between the user and the web server.

  • RULE : There are 2 types of session hijacking attacks, targeted or generic.
  • RULE : There 2 layers in the OSI model to attack.  The Transport layer (4) and Application layer (7).
  • RULE : Transport layer hijacking tasks:
    • Identify an active session
    • Predict the sequence number
    • Take the victim offline while you continue the connection to the server
    • Use the session
  • RULE : Transport layer hijacking is most effective when the victim and attacker are on the same LAN, because active sniffing of ACK and SEQ numbers is required.
    • BLUE TEAM : If the attacker isn’t on the same LAN, they will have to blindly send several packets to get a sample of the SEQ.  Block this activity at the firewall.
  • RULE : Application layer hijacking via session sniffing.
    • RED TEAM : Use Burp Suite to grab the sessionID (token) from the Target > Site map > Request > Params > Cookie.
  • RULE : Application layer hijacking via Man-in-the-browser relies on malware to be present on the victim’s machine.  If you compromise the end point, it doesn’t matter how much encryption is the path to the server.
  • RULE : Targeted session hijacking refers to the attacker impersonating a specific user in the web application.
  • RULE : Generic session hijacking refers to the attacker impersonating any valid or legitimate user in the web application.
  • RULE : The session ID is a “name=value” pair.
  • RULE : Tokens (session ID) have the following interesting properties:
    • Session ID Name
    • Session ID length
    • Session ID Entropy
    • Session ID Value
  • RULE : Fingerprint the web application by checking session ID Name.  For example you will see names like ASP.NET_SessionId (ASP .NET), CFID (ColdFusion), PHPSESSID (PHP), JSESSIONID (J2EE), etc.
  • RULE : Check the length of the session ID, if is too short, brute forcing comes into play.
  • RULE : If the session ID uses a weak source of entropy, prediction comes into play.  Prediction gets difficult if a Pseudo Random Number Generator is used.
  • RULE : As a good coding practice the value of the session ID must not reveal details of the user, the session, or the inner workings of the web application.  When developers don’t follow good coding practices, you can grab this low hanging fruit pretty easily.
  • RULE : To maintain session state the developer has options such as:
    • Cookies.
    • Proprietary Headers.
    • URL path variables on GET requests.
    • JSON body in POST requests.
    • Hidden HTML form fields.
  • RULE : Cookies should be the preferred method chosen by the developer.  Because cookies can use optional properties, such as the token expiration timestamp and usage constraints.
  • RULE : Lazy developers will use path variables which are easily modified in attempts to gain access to other accounts.
  • RULE : If the web developer uses cookies as the default way to maintain session state, it might still accept the other ways also. The attacker can simply find some other location where a path variable or JSON is used to get a variable name or find some way of predicting what to pass in then return to a higher value part of the web application and pass a variable into it there.
  • RULE : Under certain conditions some web applications switch from cookies to URL path variables (automatic URL rewriting), such as when privacy conscious clients block the use of cookies.