More Related Content Similar to Account entrapment (20) Account entrapment2. © Copyright 2014 Denim Group - All Rights Reserved
Outline
• What is Account Entrapment
• What can an attacker do with Account Entrapment?
• Cookie-based
• How the attack works
• Defenses
• Login Cross Site Request Forgery
• How the attack works
• Defenses
3. What is Account Entrapment?
• We aren’t talking about an attacker gaining access
to a victim’s account. This is the opposite.
• We are talking about logging the victim into the
attacker’s account.
• Why?!
• To get the victim to store their information in the
attacker’s account (paypal, tax site)
• To get the victim to do work as the attacker (contests)
• To frame the victim for hacking!
© Copyright 2014 Denim Group - All Rights Reserved
4. But Why?! (tell me your secrets)
• Paypal or Amazon.com allows a user to store credit
card information and use it in the future.
• If the victim stored their credit card information on
the attacker’s account, the attacker could use it.
• Youtube got hit with this. The victim would get
logged in to the attacker’s account and browse
around. Later, the attacker could view the history.
• Imagine a tax preparation site or a password
storage site or any site where secrets are stored.
• Dropbox.
© Copyright 2014 Denim Group - All Rights Reserved
5. But Why?! (do my homework)
• If homework answers are submitted online, log in
the smartest person under your account.
• For any kind of contest you could try to get
everyone logged in under your account(s). Then
you’d be guaranteed to win!
• fiverr.com is a site where people do tasks for five
dollars. Suppose they were doing tasks under your
account. Cha-ching!
• Log in the best online poker player to your online
poker account.
• Online Bill Pay!
© Copyright 2014 Denim Group - All Rights Reserved
6. But Why?! (I was framed!)
• It would be easy to frame someone for hacking into
your account this way.
• For sites that are obvious when you’re not in your
own account (social media), this would work well
for entrapment. Once you log them into your
account, it’s hard not to look around.
• While this might not lead to criminal action, it
could be used to get a boss or co-worker fired, or
manipulate people in other ways.
• Repudiation! “There were so many people logging
into my account, I can’t be held responsible.”
© Copyright 2014 Denim Group - All Rights Reserved
7. But Wouldn’t Someone Notice?!
• Facebook? Amazon? City utilities bill pay site?
• An attacker can usually craft an account that looks
identical to what the victim would expect.
• Cookie Based Account Entrapment can swap a
victim into an attacker’s account for a single page.
© Copyright 2014 Denim Group - All Rights Reserved
8. Two Main Variants
• Cookie Based Account Entrapment
• Due to looser Same-Origin Policy restrictions on cookies,
the attack can:
• originate from a sister domain (marketing.bank.com can affect
myaccount.bank.com)
• and target a single action invisibly.
• State domians have special considerations: state.tx.us
• Login Cross Site Request Forgery
• Force the victim to make a login request using the
attacker’s credentials. That system will set up a valid
session for the victim under the attacker’s account.
© Copyright 2014 Denim Group - All Rights Reserved
9. A Little Background
• The internet is nothing more than plain text
requests and responses.
• The browser makes a request to the server.
• The server processes the request and returns a
response (usually containing the HTML of the
page).
• The browser interprets that response and usually
shows a page.
• The user interacts with the page and makes a new
request …
© Copyright 2014 Denim Group - All Rights Reserved
10. Response (to previous request)
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: name1=value1; expires=Wed, 10-Aug-2016
21:28:26 GMT; domain=denimgroup.com; path=/;
secure; httponly
Set-Cookie: name2=value2
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head> …
© Copyright 2014 Denim Group - All Rights Reserved
11. © Copyright 2014 Denim Group - All Rights Reserved
Request
GET /application-security-training.html HTTP/1.1
Host: www.denimgroup.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/36.0.1985.125 Safari/537.36
Referer: http://www.denimgroup.com/
Cookie: name1=value1; name2=value2
12. How Cookies Work
GROOT
.us .gov .com
usa.gov google.com
irs.gov
.ny.us .co.us .tx.us
.state.ny.us .state.co.us .state.tx.us
.sos.state.co.us .cpw.state.co.us .doc.state.co.us
smokey.cpw.state.co.us admin.doc.state.co.us
© Copyright 2014 Denim Group - All Rights Reserved
yahoo.com
mail.google.com
beta1.google.com
13. How Cookies Work (examples)
• http://a.b.c.com can set cookies with:
• domain=b.c.com or domain=c.com, cookies set with
domain=c.com will get sent by the browser to d.c.com
• path isn’t validated at all
• names don’t have to be unique: overwriting/overloading
• Secure flag can be set from HTTP and cookies with
Secure flag can be overwritten, overloaded, or expired.
• http://a.b.c.com can’t set cookies with:
• domain=.com or domain=.tx.us (browser specific lists)
• domain=d.c.com, but cookies set to c.com will be sent
© Copyright 2014 Denim Group - All Rights Reserved
14. Common Domain Setup (private)
.app1.good.com .marketing.good.com
.secure.app1.good.com .insecure.marketing.good.com
Traditional Security Scope
.good.com
© Copyright 2014 Denim Group - All Rights Reserved
15. Common Domain Setup (state)
cookie domain can be set up to .state.co.us
© Copyright 2014 Denim Group - All Rights Reserved
Traditional Security Scope
.state.co.us
.cpw.state.co.us .doc.state.co.us
smokey.cpw.state.co.us admin.doc.state.co.us
16. Cookie-based Account Entrapment
• The attacker uses a sister domain with an XSS or
header injection vulnerability.
• They trick the victim to go there, which stores a
logged-in session cookie on the victim’s browser.
• When the victim uses the actual site, they’re using
it in the attacker’s account.
• But wouldn’t they notice?!
• On Facebook they would, but what about amazon.com?
• If the path is set to a specific area, the victim could log
into their own account and not notice the transition.
• The attacker could make the accounts appear similar.
© Copyright 2014 Denim Group - All Rights Reserved
17. Defenses
• Remove XSS and header injection everywhere.
• Get browsers to treat .state.**.us as a top-level
domain. This is non-trivial as http://state.**.us is
sometimes an actual site.
• Use different domains, not just subdomains.
• Referer checking and a URL token on every page.
• Referer checking on every page enforces going to the
login page first and stops the attacker from forwarding
the victim to a logged in page. It also breaks things.
• URL tokens stop session switching, where the victim is
logged into their own account and also into the
attacker’s account (but only for a specific path).
© Copyright 2014 Denim Group - All Rights Reserved
18. Defenses (cont.)
• Protect special actions by requiring the user to
submit their password along with the request.
• This request under the attacker’s account would fail.
• The attacker could still force the victim into their
account for other portions of the site.
• Make blatant the account that the user is logged in
to and put everything under one path/url and track
navigation through the query string.
• Lots of bad ideas. So maybe just fix the XSS issues.
© Copyright 2014 Denim Group - All Rights Reserved
19. How Login Should Work
Browser Server
© Copyright 2014 Denim Group - All Rights Reserved
good.com
1. Get Login Page
Browser Server
good.com
2. Submit Credentials
Browser Server
good.com
3. Get Redirected Past Login
20. How CSRF Login Works
Browser Server
© Copyright 2014 Denim Group - All Rights Reserved
evil.com
1. Go To Attacker’s URL
Browser Server
good.com 2. Submit Attacker’s Credentials
Browser Server
good.com
3. Get Redirected Past Login
21. Login CSRF Defenses
• Standard CSRF protection is not sufficient. An
attacker could get an anti-csrf token and force the
victim to send it with the attacker’s credentials.
• A pre-login cookie tied to the anti-csrf token would
stop this.
• If the attacker can set the pre-login cookie on the
victim’s browser, then it would still work.
• Referer header checking is usually not
recommended for CSRF protection. It could work
here where common cookie/token methods don’t.
• The Referer has to match the domain exactly.
© Copyright 2014 Denim Group - All Rights Reserved
22. Conclusions
• But why?!
• Tell me your secrets (dropbox, tax prep)
• Do my homework (fiverr.com, online poker)
• I was framed! (HR scandals, repudiation)
© Copyright 2014 Denim Group - All Rights Reserved
• How?
• Cookie based (can be path specific)
• Login Cross Site Request Forgery (whole site)
• I would notice!
• Cookie based can target a single POST page where the
user sees nothing.
• What do I do?
• Protect your entire domain from XSS
• Specifically stop Login CSRF
Editor's Notes Before we start I’d like to get a show of hands. Raise your hand if you think you’d notice if you were logged into someone else’s account. Okay, you can put ‘em down. Now raise your hand if a victim gaining unauthorized access to an attacker’s account sounds like someone got the definition of hacking backwards. Those are the primary assumptions that I hope to break with this presentation. The main response when these attacks are brought up is “who cares?!” We’re going to spend some time answering that. After all that, I’ll ask again. Can I get a show of hands for who thinks this is not hacking? A primary functionality of a site like Facebook is to individualize your account. That’s not the case for most sites. The URL token should not be the session token for logging and referer leakage reasons. It’s only to protect against potential extra session tokens.