This document provides an overview of securing session management and discusses vulnerabilities in session tokens. It describes how session tokens can be attacked by predicting, modifying, or stealing them. It also discusses weaknesses related to how tokens are generated, transmitted, handled by applications, and terminated. The document recommends generating strong, unpredictable tokens and protecting them throughout their lifecycle to help secure session management.
2. Session Management
• Enables application to identify a given user over
a number of different request
s
• Ex: login, then later request
s
• Fundamental security componen
t
• A prime target for attackers
3. Session Management
• Potential consequences of session
management attack
s
• A user can masquerade as another use
r
• Privilege escalation to administrator, owning
the entire applicatio
n
• Can be as simple as incrementing the value of a
token
4. Wall of Sheep
• My Gmail was
hacked at
Defco
n
• By stealing
and replaying
my session
cooki
e
• Using Hamster
and Ferret
7. Logging In
• Allow user to register and log i
n
• Require a session to maintain the "state" of
being authenticate
d
• Otherwise user would have to log in to each
page
9. Session Token
• Server's
fi
rst response contains a Set-Cookie:
heade
r
• Each subsequent request from the client
contains the Cookie: header
10. Vulnerabilities
• Two categorie
s
• Weakness in generation of session token
s
• Weakness in handling session tokens
throughout their life cycle
11. Finding the Real Session
Token
• Sometimes a platform like ASP.NET generates a
token but the app doesn't really use i
t
• To
fi
nd a token, establish a session and then
replay a reques
t
• Systematically remove each item you suspect
of being the real toke
n
• Wait till response is no longer customized for
your sessio
n
• Burp Repeater is good for this
18. HTTP Authentication
• Basic, Digest, NTL
M
• Pass credentials with every request in HTTP
header
s
• Not via application-speci
fi
c cod
e
• Rarely used on Internet-based applications
19. Sessionless State
Mechanisms
• Application doesn't issue session tokens or
manage the state
• Transmit all data required to manage the state
via the client in a cookie or hidden form
fi
el
d
• Ex: ASP.NET ViewStat
e
• Link Ch 7a
20.
21.
22. Securing View State
• Data must be protected, usually as a binary blob
that is encrypted or signe
d
• To prevent re-use on another machin
e
• ASP.NET View State uses Base64 and a hash
made from a Machine Authentication Cod
e
• Includes the machine's MAC addres
s
• Expiration time enforces session timeouts
23. Indicators of Sessionless
State Mechanisms
• Token-like data items >=100 bytes lon
g
• New token-like item in response to every
reques
t
• Data is encrypted (structureless) or signed
(structured accompanied by a few random
bytes
)
• Application rejects attempts to submit the same
item with more than one request
26. Token Use Cases
• Password recovery tokens sent to user's
email addres
s
• Tokens in hidden form
fi
elds to prevent
cross-site forgery attack
s
• Tokens used to grant one-time access to
protected resource
s
• Persistent tokens used to "remember me
"
• Tokens used to allow customers of shopping
application to see the status of an order
32. Hack Steps
• Obtain a single toke
n
• Modify it in systematic way
s
• Change it one byte at a time, or one bit at a tim
e
• Resubmit it to see if it's still accepte
d
• Some
fi
elds may be ignore
d
• Burp Intruder's "char frobber" function
33. Hack Steps
• Log in as several users at different time
s
• Record the token
s
• If you can, register similar usernames like A,
AA, AAA, AAAB, etc
.
• Try similar series for other data, such as email
addresses
34. Hack Steps
• Analyze the tokens for correlation
s
• Look for encoding or obfuscatio
n
• A series of repeating letters like AAA will
produce repeating encoded characters like zzz if
XOR is use
d
• Base64 often ends in = or ==
35. Hack Steps
• Use the patterns you've found to try guessing
tokens of other user
s
• Find a page that is session-dependen
t
• Use Burp Intruder to send many requests using
guessed token
s
• Monitor results to see if any pages load
correctly
38. Patterns
• From a sample of tokens, it may be
possible to predict valid token
s
• Commercial implementations such as
web servers or application platforms may
be more vulnerabl
e
• Because it's easier to gather a large
sample of tokens, from your own test
system
40. Three Sources of
Predictable Session Tokens
• Concealed sequence
s
• Time dependenc
y
• Weak random number generation
41. Concealed Sequences
• This sequence
appears to be
Base64-encode
d
• Decodes to the
gibberish on the
right
42. Hexadecimal Form
• Render the tokens as
hexadecimal
number
s
• Calculate difference
between sequential
token
s
• For negative
differences, add
0x10000000000 so it
starts with FF
45. Time Dependency
• Left number simply
increments by 1
each tim
e
• Right number
moves up by a
varying value, as
shown on the right
46. Another Sample
• Ten minutes late
r
• First number has jumped
by
6
• Second number has
jumped by 53957
8
• Ten minutes = 600 sec =
600,000 milliseconds
47. Attack Steps
• Poll the server frequently to gather session
token
s
• When
fi
rst number increases by more than 1,
there's another user in betwee
n
• We know the second number will be between
the two numbers we hav
e
• Simply brute-force the value
48. Weak Random Number
Generation
• Jetty is a Java-based Web serve
r
• Calculates pseudorandom session tokens
with a "linear congruential generator
"
• Multiplies previous number by a constant,
adds another constant, truncates to 48 bit
s
• Given one value, all others can be predicted
49. PHP 5.3.2 and Earlier
• Session token generated fro
m
• Client's IP addres
s
• Epoch time at token creatio
n
• Microseconds at token creatio
n
• Linear congruential generator
50. phpwn
• The vulnerability was
found in 200
1
• But no one wrote a
practical attack tool until
Samy Kamkar in 201
0
• Link Ch 7b
56. Design Goal
• Token built from meaningful content,
such as usernam
e
• Encrypted with a secret key not known to
the attacke
r
• Sounds good, but sometimes the
attacker can tamper with token's
meaningful values without decrypting
them
57. ECB Ciphers
• Electronic Code Boo
k
• Input broken up into blocks, often 8 bytes lon
g
• Symmetric encryption, no randomnes
s
• Each input block encodes to a single output
bloc
k
• This preserves patterns in input
67. Modify a Single Byte of
Ciphertext
• That block will decrypt to jun
k
• But the next block will remain meaningful, only
slightly altered by the XO
R
• Some of the altered blocks will have valid uid
values
73. Information Leakage
• Application may re-use the encryption code
elsewher
e
• It may allow user to submit arbitrary input and
see the ciphertex
t
• Such as to create a download link for an
uploaded
fi
l
e
• Submit desired plaintext as a
fi
lename, such a
s
• uid=1
76. Common Myths
• "SSL protects tokens in transmission
"
• Some attacks still work, such as XS
S
• "Our platform uses mature, sound
cryptography so the token is not
vulnerable
"
• But cookie may be stolen in transit
77. Disclosure on the Network
• Tokens transmitted without encryptio
n
• Can be sniffed from many location
s
• User's local networ
k
• Within IS
P
• Within IT department of server hosting the
application
78. Credential Theft v.
Token Theft
• Stealing a user's password may not wor
k
• Two-factor authentication, requiring a
PIN in addition to the passwor
d
• Login performed over HTTP
S
• Stealing a session token and hijacking
an authenticated session may still wor
k
• And the user won't be noti
fi
ed of a
extra successful login
79. Not Always HTTPS
• An app may use HTTPS during logi
n
• But use HTTP after login to see authorized
conten
t
• Gmail did this until 201
2
• Eavesdropper cannot steal password, but can
steal session token
80. Upgradeable Token
• App may use HTTP for preauthenticated page
s
• Such as the site's front pag
e
• And use HTTPS for login and all subsequent
page
s
• But continue to use the same token; upgrade
to an authenticated sessio
n
• Attacker can steal the token before login
81. Back Button
• App uses HTTPS for login and all subsequent
page
s
• With a new toke
n
• But user navigates back to an HTTP page with
the Back butto
n
• Exposing the token
82. sslstrip
• "Log In" link goes to an HTTPS pag
e
• Attacker in the middle alters the page to use
HTTP instea
d
• And forwards requests to the server via HTTP
S
• User won't see any obvious difference in the
page
83. Mixed Content
• HTTPS page with some HTTP conten
t
• Such as images, style sheets, etc
.
• This can send the session token over HTT
P
• Browsers now block some mixed-content by
default
84. Social Engineering
• App uses HTTPS for every pag
e
• Send user an HTTP link via email or IM, or
added to some page the user view
s
• To http://target.com or http://target.com:44
3
• Clicking that link may send a session token over
HTTP
85. Hack Steps
• Walk through the app, from start page, through
login, and all its functionalit
y
• Record every URL and note every session token
you receiv
e
• Note transitions between HTTP and HTTPS
87. Secure Cookies
• If secure
fl
ag is set on a cookie, browser will
only send it via HTTP
S
• If the connection is only HTTP, that cookie won't
be sent
105. Referer Attack
• A web mail application transmits session tokens
in the UR
L
• Send email to targets containing a URL on the
attacker's Web serve
r
• The Referer headers from people who click will
appear in the server logs
106. Vulnerable Mapping of
Tokens to Sessions
• Allowing users to have two sessions open at the
same tim
e
• Using static tokens (same token is sent to the
user each time they log in
)
• Misunderstanding of what a session is
107. Flawed Logic
• Token valu
e
• But app accepts the same "r1" with a different
"user"
108. Vulnerable Session
Termination
• A session may remain valid for days after the
last request is receive
d
• Ineffective logout functionalit
y
• Logout merely deletes cookie but does not
invalidate i
t
• Logout merely runs a client-side script, server
doesn't know a logout has occurred
109.
110. Token Hijacking
• Cookie thef
t
• Session
fi
xation: attacker feeds a token to the
user, then user logs in, then attacker hijacks the
sessio
n
• Cross-Site Request Forgery (CSRF
)
• Tricks user into submitting a request
containing a cookie that goes to an attacker's
server
111. Liberal Cookie Scope
• When a cookie is set, the server can set the
domain and url (path) the cookie is used fo
r
• By default, all subdomains are include
d
• Cookie set by games.samsclass.info
• Will be sent to foo.games.samsclass.inf
o
• But NOT to samsclass.info
112. Specifying the Domain
• App at foo.wahh-app.com sets this cookie
:
• A domain can only set a cookie for the same
domain or a parent domai
n
• And not a top-level domain like .com
113. Example
• blogs.com sets a cookie for each use
r
• Each user can create blog
s
• joe.blogs.co
m
• sally.blogs.co
m
• A blog with JavaScript can steal tokens of other
users who read the attacker's blog
114. Fix
• There is no way to prevent cookies for an
application from being sent to subdomain
s
• Solution: use a different domain name for main
app, and scope the domain to this fully quali
fi
ed
nam
e
• www.blogs.co
m
• Cookie won't be sent to joe.blogs.com
115. Path
• Application returns this HTTP header
:
• Much stricter than same-origin polic
y
• Easily defeated by getting a handle to a
JavaScript window (Link Ch 7f)
119. Strong Tokens
• Tokens should contain no meaning or structur
e
• All data about the session's owner and status
should be stored on the server in a session
objec
t
• Some random functions, like java.util.Random,
are predictable from a single value
120. Sources of Entropy
(Randomness)
• Good method
:
• Add a secret known only to the server, then
hash it al
l
• Change the secret on each reboot
121. Protecting Tokens
Throughout Their Life Cycle
• Only transmit over HTTP
S
• secure, httponl
y
• Use HTTPS for every page in applicatio
n
• Don't put session tokens in the UR
L
• Implement a logout function that invalidates
session token on the server
122. Protecting Tokens
Throughout Their Life Cycle
• Session should expire after a brief period of
inactivity, such as 10 minute
s
• Don't allow concurrent login
s
• If a user starts a new session, a new token
should be generated, and the old one
invalidate
d
• Protect diagnostic or administrative functions
that save token
s
• Or don't save tokens in them
123. Protecting Tokens
Throughout Their Life Cycle
• Restrict domain and path for session cookie
s
• Audit codebase and remove XSS vulnerabilitie
s
• Don't accept tokens submitted by unrecognized
user
s
• Cancel tokens after such a request
124. Protecting Tokens
Throughout Their Life Cycle
• Use two-factor authenticatio
n
• Makes cross-site request forgery and other
session-hijacking methods more dif
fi
cul
t
• Use hidden
fi
elds rather than session cookie
s
• More dif
fi
cult to steal because they aren't sent in
every request
125. Protecting Tokens
Throughout Their Life Cycle
• Create a fresh session after every authenticatio
n
• To prevent session
fi
xation attacks
126. Per-Page Tokens
• A new page token is created every time the user
requests an application pag
e
• Page token veri
fi
ed on every reques
t
• If it doesn't match, the session is terminate
d
• Prevents pages being used out of orde
r
• And blocks an attacker from using a page at the
same time as a real user
127.
128. Log, Monitor, and Alert
• Requests with invalid tokens should raise IDS
alert
s
• Alert users of incidents relating to their
sessions
129. Reactive Session
Termination
• Terminate session if a request ha
s
• Modi
fi
ed hidden form
fi
eld or URL query
string paramete
r
• Strings associated with SQL injection or XS
S
• Input that violates validation checks, such as
length restrictions