11.

1 SESSION  Hijacking Basics

 Hijacking Web Sessions
HIJACKING  Token Examples

CONCEPTS  Why Hijacking is Successful

 Hijacking vs Spoofing
 The act of “taking over” someone else’s session after they have established it
 Usually aimed at web browsers
 Can sometimes be done at the network level
 The server does not realize that someone else is masquerading as the client
 The victim (user) also may not realize their session has been hijacked
 The attacker and victim might be running parallel sessions
 The server would see this as two sessions by the same client
1. After a web client authenticates, the web server sends a session
identification token (key) to the client
2. The attacker steals the token or successfully guesses its value
3. The attacker then takes over the connection while the session is in
progress
4. The attacker does not need to authenticate again
 Authentication usually happens only at the beginning of the session
 The attacker only needs to present the token to the server to show they
already authenticated
 A Session Hijacking attack compromises the client’s session token
 Steal or predict a valid session token
 Gain unauthorized access to the Web Server

 HTTP communication uses many different TCP connections, the web server needs a
method to recognize every user’s connections.
 The most useful method depends on a token that the Web Server sends to the client
browser after a successful client authentication.
 A session token is normally composed of a string of variable width and it could be
used in different ways
 For example:
 In a URL, the token is a cookie included in the the header or body of an HTTP request
 It could also be a JSON Web Token (JWT)
 URLs with embedded Cookie
http://www.example.com/PHPSESSID=298zf09hf012fh2
http://www.example.com/userid=sup3r4n0m-us3r-1d3nt1f13r

 JSON Web Token

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
.
eyJzdWIiOiJ1c2Vycy9Uek1Vb2NNRjRwIiwibmFtZSI6IlJvYmVydCBUb2tlbiBNYW4iLCJz
Y29wZSI6InNlbGYgZ3JvdXBzL2FkbWlucyIsImV4cCI6IjEzMDA4MTkzODAifQ
.
1pVOLQduFWW3muii1LExVBt2TK1-MdRI4QjhKryaDwc
 Lack of account lockout for invalid session IDs
 Session expiration time is indefinite
 Session IDs are small or the ID generation algorithm is weak
 Vulnerability of most TCP/IP computers
 Session IDs handled insecurely
 Majority of countermeasures require encryption to work
 Hijacking
 Process of taking over active session
 Needs legitimate user to make/authenticate connection

 Spoofing
 Process of initiating new session using stolen credentials
 Attacker pretends to be a user/machine to gain access
 11.2
COMPROMISING A
 Cookie-based Authentication
 Token-based Authentication

SESSION TOKEN  JWT

 Stealing a Token
 The traditional, stateful web authentication mechanism
 Provides “proof” to the website that the user has already been
authenticated
 The website can “trust” a browser that presents the cookie
 Lifetime of a cookie:
1. User enters their login credentials
2. Server verifies the credentials are correct and creates a session which is then
stored in a database
3. A cookie (text file) with the session ID is placed in the user’s browser
4. On subsequent requests, the session ID is verified against the database and if
valid the request processed
5. Once a user logs out of the app, the session is destroyed both client-side and
server-side
 A token is (usually) a JSON Web Token (JWT)
 Digitally signed JSON object (key/value pair)
 Can be Base-64 encoded

 Token-based authentication is stateless

 The server does not keep a record of which users are logged in
 Does not keep track of which JWTs have been issued
 Every request to the server is accompanied by the token which the server uses to verify
the authenticity of the request
 Token-based authentication has gained prevalence over the last few years due to
the rise of:
 single page applications
 web APIs
 Internet of Things (IoT)
 JWT Format uses key-value pairs

HEADER.PAYLOAD.SIGNATURE

{ { { 7WK5T79u5mIzjIXXi2oI9
"alg": "HS256", "sub": "123456789", Fglmgivv7RAJ7izyj9tUyQ
"typ": "JWT" "name": "Moo", }
} "admin": true
}

Whole thing is then serialized (put in one line) and typically Base64 encoded:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyAKCSJzdWIiOiAiMTIzNDU2Nzg5IiwgCgkibmFtZSI6ICJNb28iLCAKCSJhZG1pbiI6IHRydWUgCn0=.
7WK5T79u5mIzjIXXi2oI9Fglmgivv7RAJ7izyj9tUyQ
1. User enters their login credentials.
2. Server verifies the credentials are correct and returns a signed token.
3. This token is stored client-side:
 most commonly in local storage.
 but can be stored in session storage or a cookie as well.

4. Subsequent requests to the server include this token as an additional

Authorization header
 or through one of the other methods mentioned above.

5. The server decodes the JWT and if the token is valid processes the request.
6. Once a user logs out:
 the token is destroyed client-side.
 no interaction with the server is necessary.
 Because HTTP communication uses many different TCP connections, the web
server needs a method to recognize every user’s connections
 The most useful method depends on a token that the Web Server sends to the client
browser after a successful client authentication
 The token is used in different ways:
 In the URL
 In the header of the http requisition as a cookie
 In other parts of the header of the http request
 In the body of the http requisition.

 A Session Hijacking attack compromises the session token

 By stealing or predicting a valid session token
 This gains unauthorized access to the Web Server
 Stealing
 Attacker steals session IDs using various techniques
 Sniffing
 XSS
 Malicious site

 Guessing
 Attacker looks at variable parts of session IDs to try to guess what they are

 Brute Force
 Attacker keeps trying different session IDs until the right one is found
 Command Injection
 Attacker injects malicious code into the target server

 Session ID Prediction
 Attacker takes over the session

 Session Desynchronization
 Attacker breaks the connection with target machine

 Monitoring
 Attacker watches the TCP segment flow and predicts the TCP sequence number

 Sniffing
 Attacker intercepts a token

 Attacker gains access to a machine that still has an active session

 User has stepped away
 Access is via RAT
 Session has no logout or expiration time
 AKA side-jacking
 Use a sniffer (Wireshark, Kismet) to capture a valid session token (Session ID)
 Reuse the token to gain unauthorized access
 AKA predictable session token
 Attacker analyzes the website’s session ID generation process
 Attacker then predicts a valid session ID value and gets access
 Looking at the example, “user02” would be a good prediction
  Stored XSS
11.3 XSS  Reflected XSS
 DOM XSS
 A popular and effective attack type
 Takes advantage of a client’s trust in a server
 Malicious code (typically JavaScript) is inserted into a web page
 While the victim views the page, their browser executes the
malicious code in the background
 Made possible when the web app does not validate user input
 Requires some level of social engineering
 Can compromise a session by stealing its cookie
 JavaScript is a programming language which runs on web pages inside your
browser
 It is included in the HTML that forms the web page you see
 It adds functionality and interactivity to the web page
 It’s used extensively on all major applications and CMS platforms.

 Unlike server-side languages such as PHP, JavaScript code inside your browser
cannot impact the website for other visitors
 It only performs actions within the user’s browser

 While JavaScript is client-side and does not run on the server, it can be used to
interact with the server by performing background requests
 The web page does not display the script to the user
 It is executed silently in the background
 An attacker exploits a vulnerability on the website’s software
 They inject their own script which is executed by the victim’s browser
 The script can steal the session cookie/token, entice the user with phishing, or
perform unwanted actions in the user’s name
 Stored XSS
 Reflected XSS
 DOM XSS

Note: You will learn more about compromising web apps in the
CEH Module “Hacking Web Applications”
 AKA Persistent XSS
 Malicious code is stored permanently in a website database
 Victims later unknowingly run that code
 An attacker injects a malicious script onto the site that others will read
 The attacker posts to a forum, product review, or some other feedback page
 The “legitimate” posting contains a hidden malicious script (easy to do in HTML)
 As visitors read the posting, their browser is also running the malicious script in the
background
 JavaScript document.cookie property in the script is a common way to capture a cookie

Requires some social engineering to entice victims to read the attacker’s post
 A vulnerable web app allows visitors to post a comment:

POST /post/comment HTTP/1.1

Host: vulnerable-website.com
Content-Length: 100
postId=3&comment=Love+this+product!&name=Moo+Dharma&email=moo%40example.com

 Visiting users will see the following post:

Love this product!

 An attacker posts this comment:
<p>Yeah it’s great<script>some bad command here</script></p>

 Visiting users will see the following post:

Yeah it’s great
 At the same time the bad command is running in the background
 AKA Non-persistent XSS
 An attack in which a web app receives data in an HTTP request
 Includes that data within the immediate response in an unsafe way

 Malicious code is run in the victim’s browser in the context of their current session
with the website
 If you want to steal the user’s cookie, you need them to first obtain a cookie
 While they still have that session going, you need the same browser (in the same session)
to execute the malicious code
 If you simply send them a malicious link, it will open another instance of the browser,
which will be in a different session
 The injected script is reflected off the webserver as part of:
 An error message
 A search result
 Any other server response

 The attacker must search the web app for any place where user input directly
triggers a response
 A search field is a very common choice

 Once a vulnerable insertion point is found, the attacker can craft a link containing it
(and the malicious script) and send it to the victim

Requires some social engineering to entice the victim to click a pre-created malicious link
1. Some vulnerable web app has a search function
 Users enter a word (search term) in a form
 The form creates a URL containing the search term. For example:

https://www.example.com/search?term=chocolate
2. When the user presses enter, the web app searches for the term AND echoes the
user-supplied search term back :
<p>You searched for: chocolate</p>
3. The attacker creates a URL with malicious code in place of a normal search term:
https://www.example.com/search?term=<script>some+malicious+code</script>
4. The attacker puts this malicious URL in a phishing email, SMS, etc. and sends it to
the user
5. The user just has to click the link, thinking it will lead to something else
6. The vulnerable site will reflect the malicious code back to the victim’s browser
7. The browser executes the code (which could include stealing the user’s session
token)
 AKA DOM-based Cross-Site Scripting
 Abuses the Document Object Model
 A standard way to represent HTML objects in a hierarchical manner

 In a DOM XSS attack, the malicious JavaScript code is inserted directly into the
victim’s browser
 Unlike the other XSS attacks which upload (or reflect) malicious code off the server

 There are several HMTL objects that are particularly suited for DOM XSS:
 window.location
 document.url
 document.location
 document.referrer
 DOM is a programming interface for HTML
and XML documents
 DOM treats an HTML/XML document as a tree
structure,
 Each node in the tree is an “object”
representing part of the document
 The document itself is also considered an object

 Objects have “methods” that can be used

programmatically to change the content of the
document
  A “malicious” link with JavaScript is clicked by an unsuspecting victim

http://testhtml5.vulnweb.com/#/redir?url=javascript:alert(%22Hacked%20by%20Moo%22)

 The JavaScript is processed on the client browser

 Wireshark capture confirms the JavaScript was not sent to the server
 No sign of the script in any of the packets
 Include input validation/sanitization in the web app
 Use a tool such as Burp Suite to scan your website or web application regularly
 Restrict user input to a specific allow list
 Provide a drop-down menu that a user must choose from

 Avoid/restrict HTML in inputs

 Require all input be text only
 Sanitize all input to remove any possible code

 Sanitize all inputted values

 Escape all unsafe characters so that they don’t result in HTML

 Use HTTPOnly Flags on Cookies

 This prevents JavaScript from reading the content of the cookie

 Use a Web Application Firewall to help pre-screen all input

11.4 CSRF  Cross-site Request Forgery
 CSRF Considerations
 Exploits a server’s trust in the client
 Takes advantage of a saved authentication to access sensitive data
 The attacker tricks an authenticated victim into unwittingly executing an
undesirable action
 The victim authenticates/is already authenticated to the web site
 The attacker sends a malicious link to the victim
 The link instructs the victim’s browser to perform an unwanted action in the background
 A CSRF attack can force the unwitting victim to:
 Transfer funds
 Make unauthorized purchases
 Change their email address or contact details
 etc.
 If the victim has an administrative account, the attacker can expand the attack to
other areas in the web site
1. Visit your bank's site, log in.
2. Then visit the attacker's site (e.g. sponsored ad from an untrusted organization).
3. Attacker's page includes hidden form with same fields as the bank's "Transfer
Funds" form.
4. Form fields are pre-filled to transfer money from your account to attacker's
account.
5. Attacker's page includes JavaScript that submits form to your bank.
6. When form gets submitted, browser includes your cookies for the bank site,
including the session token.
7. Bank transfers money to attacker's account.
8. The form can be in an iframe that is invisible, so you never know the attack
occurred.
 Typical GET request for a $5,000 bank transfer to my friend Moo:
GET https://mybank.com/transfer.do?account=Moo&amount=$5000 HTTP/1.1
 Attacker would change the recipient to their account instead:
GET https://mybank.com/transfer.do?account=TheAttacker&amount=$5000 HTTP/1.1
 Attacker embeds the request into a harmless-looking hyperlink:
<a href="https://mybank.com/transfer.do?account=TheAttacker&amount=$5000">Click
for more information</a>
 The attacker now needs to send out a phishing email to as many bank customers as
possible, enticing them to click the link
 If the bank’s website only uses POST requests, it’s not possible to frame malicious
requests using an <a> href tag
 However, the attack can be delivered in a <form> tag
 It can even be a self submitting form
<body onload="document.forms[0].submit()>
<form id=”csrf” action="https://mybank.com/transfer.do" method="POST">
<input type="hidden" name="account" value=“TheAttacker"/>
<input type="hidden" name="amount" value="$5000"/>
</form>
</body>

 The above form above does not have a submit button

 It will be triggered without a user’s knowledge and consent
 Instead, the button is replaced by a line of JavaScript:

document.getElementById('csrf').submit();
 The power of CSRF is that it's difficult to detect
 The attack is carried out by the user’s browser as if user requested it
 The user could enter same URL manually and get same result
 It’s nearly impossible for the browser to distinguish CSRF from normal
activity
 CSRF can be difficult for an attacker to execute
 Requires finding a form that can permit malicious instructions
 Requires knowing the right values that aren't obscured
 Sites that check the referrer header will disallow requests from different
origins
 Implement CSRF tokens
 A unique, unpredictable secret value generated by the web app
 The client must present the token for every request

 Do not use GET requests for state-changing operations

 Use the OWASP CSRF Cheat Sheet for guidance when developing the web app
11.5 OTHER  Session Replay

WEB  Session Fixation

 MITB
HIJACKING  MITM

ATTACKS
 Attacker listens in on conversation between user and server
 Attacker obtains user’s authentication token
 Attacker replays request to server using obtained token and gains unauthorized
server access
 AKA Session Donation Attack
 Permits an attacker to hijack a valid user session
 Exploits a limitation in the way a vulnerable web app manages the session ID
 An attacker obtains legitimate web app session ID
 Tricks the victim’s browser into using it

 Session fixation execution techniques include:

 Session token in URL argument
 Session token in hidden form field
 Session ID hidden in cookie
1. The attacker visits the web application login page
 Receives a legitimate session ID generated by the web application
 The attacker does not log in, but saves the session ID

2. The attacker tricks a victim into using the session ID

 Injection, man-in-the-middle attack, social engineering, etc.
 The victim goes to the website with the attacker’s session ID and logs in

3. The web app now thinks anyone with the session ID is legitimate
4. The attacker uses the session ID to access the web application
 Takes over the user session
 Impersonates the victim
 AKA Monkey-in-the-Middle
 A general term for an attacker inserting themselves into an existing session to
intercept messages
 Uses various techniques to split TCP connection into two sessions:
 Victim-to-attacker
 Attacker-to-server

 Once inserted, the attacker can read/modify/insert fraudulent data into the
communication
 You can capture a session cookie by reading the HTTP header
 You can also change the amount of a money transaction inside the application
context
 ARP spoofing
 DNS poisoning
 Modify records on the authoritative DNS server
 Modify the cache of the local DNS server
 Inject fake cached lookups into the victim machine
 Modify the victim machine’s HOSTS file with fake name to IP mappings

 Rogue wireless access point

 Malicious links
 Similar to MITM
 Attacker uses a Trojan to intercept calls between the browser and its libraries/security
mechanisms
 Primary objective is to manipulate Internet banking transactions
 Customer makes the payment, but malware changes the destination and amount

ONLINE BANKING
ONLINE BANKING

Payee Name Gas Bill

Payee Name Fraudster
Payee Account 123456
Payee Account 99999 What the
What the #
Amount $50 #
user sees Amount $5000 bank
sees
 Compression Ratio Info-leak Made Easy (CRIME):
 A client-side attack that exploit vulnerabilities present in the data compression feature of
protocols such as SSL/TLS, SPDY*, and HTTPS
 BREACH:
 An exploit against HTTPS when using HTTP compression (SSL/TLS compression)
 Based on the CRIME security exploit

 Forbidden Attack
 A type of MITM
 Exploits the reuse of a cryptographic nonce during the TLS handshake

*SPDY is a Google protocol that manipulates HTTP traffic. It attempts to reduce page load
latency, thus speeding up web traffic
 11.6  TCP Session Hijacking

NETWORK-  Source Routed Packets

 RST Hijacking
LEVEL  Blind Hijacking

SESSION  ICMP/ARP Spoofing

 UDP Hijacking
HIJACKING
 Take a user's or client's place after it has established a TCP connection with a
server
 Enables a connection without providing credentials
 Conditions:
 Cleartext protocol used
 Attacker needs to observe and correctly predict TCP sequencing numbers
 Packets can’t be digitally signed
 Process:
 Watch the client/server TCP sequence numbers
 Send spoofed TCP FIN packets to the client
 Spoof your IP or MAC to the server
 When the client disconnects, continue communicating with the server via the spoofed
address
 A common way to deauthenticate a client
 Attacker sends spoofed TCP segments to the client with the RST flag raised
 Victim (typically client) thinks the other side (typically server) has closed the
connection
 Attacker takes the client’s place
 Two common techniques to redirect traffic to the attacker
 Both require that the client and the attacker be on the same network segment
 ICMP Redirect
 Attacker sends spoofed ICMP redirect messages to the client
 Tells the client that it should no longer use its current default gateway
 Instead, the attacker is the client’s “new” default gateway

 ARP Spoofing
 Attacker sends fake ARP replies re-mapping the server/router IP address to the attacker’s
MAC address
 The client will put the attacker’s MAC in the destination field of the Ethernet or Wi-Fi
frame
This is your
.254
router
speaking.
Next time
send traffic .1
to 254
instead of
me.
 UDP Hijacking can happen in one of two ways:
 Attacker sends a forged server reply to the victim before the legitimate server can reply
 Attacker intercepts server’s reply using man-in-the-middle attack

Connection Request

Forges a reply before

the server responds

MITM
 A type of MITM
 The attacker does NOT create two sessions
 Instead, the attacker poisons the DNS lookup so the client sends traffic destined
for the server to the attacker
 The attacker also manipulates the source routing option in the IP headers of the
client’s traffic
 Specifies that the traffic return path from the server passes back through the attacker
 Performed if source routing is not possible
 Attacker can only send data/commands – cannot see server’s response
 OK if they can see the results of a command
 11.7
SESSION  Hijacking Tools

HIJACKING  Mobile Tools

TOOLS
  Ettercap, bettercap
 ARP poisoning and MITM tools

 T-Sight, Juggernaut, Hunt, Shijack

 TCP interactive session hijackers

 sslstrip
 force SSL downgrade to HTTP
 Used in HTTPS MITM attacks

 Hamster
 cookie sidejacking tool - replaces your cookie with someone else’s

 Ferret
 the cookie sniffer used by Hamster

Note: You can use Ettercap, hamster, and ferret together to MITM, sniff, and sidejack cookies
 Burp Suite, OWASP ZAP, Paros
 localhost proxies for intercepting and manipulating web app traffic

 Firesheep
 Mozilla Firefox extension
 Packet sniffer that hijacks browser sessions on unencrypted public Wi-Fi
 Steals cookies from the user’s favorite sites such as Facebook, Twitter, etc.

 CookieCadger
 A Java app that automatically sidejacks and replays insecure HTTP GET requests
 DroidSheep
 Android app that listens for HTTP packets on wireless networks
 Sidejacks the session and extracts the session ID

 DroidSniff
 Sniffer, MITM, automatic password capture of popular social media sites

 dSploit
 Pentesting suite that runs on Android
 Wi-Fi scanning, network mapping, port scanning session hijacking, MITM

 zANTI
 ARP poisoning MITM
 Sniff cookies
DroidSheep DroidSniff
 zANTI
dSploit
11.8 SESSION
HIJACKING
 Countermeasures
COUNTER-
MEASURES
 Protect Session IDs:
 Use unpredictable (randomized) Session IDs
 Never use URLs with Sessions IDs
 Don't Re-use Session IDs

 Use HTTP-Only on Cookies to help prevent XSS (Cross-Site Scripting)

 Regenerate the session key after authentication
 Limit incoming connections
 Minimize remote access
 Set absolute and inactive time limits on sessions
 Use Multi-Factor Authentication
 Use HTTPS or an IPSEC-based VPN to encrypt your connection
 Use OWASP cheat sheets for web app developer best practices.
11.9 SESSION
HIJACKING  Review

REVIEW
 INTRO TO
 In session hijacking, the attacker attempts to take over the client’s session AFTER the user
has authenticated
 ETHICAL
Cookies and Java Web Tokens (JWTs) are the most common type of session token
Session Sniffing (sidejacking) is where you passively sniff and capture the user’s token
HACKING

 Session Prediction is where you can guess what the next token value would be

REVIEW Stored (persistent) XSS stores the malicious code on a page that
 Cross-Site Scripting (XSS) is where the client trusts the server
 The attacker injects malicious code which the client’s browser executes in the background


others will see
 Reflected XSS uses a web app’s search or error functionality to
send the malicious command, along with a session token, back to
the user
 DOM XSS injects the malicious script into the victim’s browser
directly, superimposing it on top of a downloaded page
 INTRO TO
 Cross-Site Request Forgery (CSRF) is where the server trusts the client (authenticated user)
ETHICAL
 As the user does something else, the CSRF tricks the browser into sending unauthorized commands to
the website, which the website will accept and execute

HACKING
 Session Replay is where the attacker passively sniffs the client’s session token and then uses it

REVIEW
 Session Fixation is where the attacker obtains a legitimate session token and then tricks the
client into using it while authenticating
 CRIME and BREACH take advantage of protocol vulnerabilities
 MITM can be accomplished through ARP spoofing, ICMP redirect, DNS poisoning, and
malicious links
 Source-routed hijacking uses the source routing field in an IP header to instruct
routers to send traffic through a different path (the attacker)
 Blind hijacking is used when source routing is not possible
 The attacker can relay requests to the server, but cannot see the responses

 TCP session hijacking requires the attacker to predict the next TCP sequence number,
deauthenticate the client, and take the client’s place
 UDP hijacking intercepts a server’s UDP response to a client, sending a fake response
in its stead