Pre Note : The following blogpost is about netflix vulnerability which was closed as won’t Fix and disclosing it under standard terms.I decided to disclose it since the team decided as wont fix.
Note : Title might be misleading.For better explanation i kept the title.
Cookie injection,Reuse of cookie will lead to privilege escalation and bypass of Basic Netflix plans.
What is cookie & what is cookie injection?
Cookies are small files which are stored on a user’s computer. They are designed to hold a modest amount of data specific to a particular client and website, and can be accessed either by the web server or the client computer. This allows the server to deliver a page tailored to a particular user, or the page itself can contain some script which is aware of the data in the cookie and so is able to carry information from one visit to the website (or related site) to the next.
Cookie Injection :
The majority of web applications are based on an authentication mechanism that enables to define user privileges. This mechanism is based on sessions. It defines cookies which validity period depends on the parameters. If the controls are only based on these cookies, the application is likely to be vulnerable, since cookies are saved on local machines. Hence, it is easy to modify their values or manually create new cookies.
The basic rule of security would be handling up secure cookies and cookies should expire whenever session is closed out .
Cookie Security Some basic rules :
- Cookies should not be reused.
- Cookies should be randomized.
- Cookies should expire on post logout.
- Cookies should have proper server side validations.
- Cookies should have proper attributes like no cache,no store,etc.
- Send The Cookie To Only Your Application
- Don’t Share Cookie With Sub Domains
- Require a Secure Connection
- Protect Against XSS Exploits
Bug Bounty rules & out of scope :
Most of the bug bounty programs leave/skip cookie injection since its basically client side attack ,i.e it’s carried based on user interaction.
For instance netflix bug bounty exceptions clearly states that it as out of scope .
Whats the bug :
Steps to replicate/reproduce-Noob Way :
- You might need any cookie editor of your favorite browser
- Go to your friends account export his/her cookie ,save it as json
- Now come to your computer import the json.
Steps to reproduce PT way[If request does not use HTTP ONLY,There are few areas where httponly is not implemented] :
- Send a xss hook of a vulnerable website[e.g beef]
- Capture the victims cookie.
- Import & enjoy the free netflix.
Alternatively it might be weird ask your paid friend to send cookies for u and capture http cookies in any proxy tool[like Burp] repeat the request.
How Cookies Work
When the server wants to set a cookie it passes back a header named “Set-Cookie” with the key-value pair and some options.
On subsequent requests the client will send along its own header to let the server know the name and value of its stored cookies. The server will not continue to send back the cookies, it will only send them if there is a change.
You can see all the headers for yourself using the LiveHeaders plugin for Firefox.
This data is completely in control of the client- it is trivial to change the values of a cookie. That means that, just like post and get data, all cookie data must be validated in some way. At the same time you’ll want to avoid storing sensitive information, such as passwords, as cookies are stored in cleartext and anyone with access to the computer later can easily pick those up (I know of at least one security forum that was hacked in this way). It is also important to note that HTTP does not encrypt the headers in any way. If the connection isn’t over SSL then it will not be protected from snooping eyes.
Session cookies are no different than any other cookie- their value is just a simple ID. Those IDs are susceptible to all of the same limitations as other cookies. The real power behind sessions happens server side, where the ID is used to pull out data stored on the server. This has many benefits over storing data directly into the cookie itself- data can’t be manipulated by the user, large amount of data can be stored without having to send it back and forth with each request, and you can store data you otherwise wouldn’t want the client to have access to.
How To Bypass HTTPONLY[Source Nateixm] :
Set-Cookie: <name>=<value>[; <max -Age>=<age>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]
</some_path></domain_name></date></age></max></value></name>set-Cookie: wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29; Expires=Wed, 09 Jun 2021 10:18:14 GMT; domain=www.test.org; path=/; Secure
Set-Cookie: wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29; Expires=Wed, 09 Jun 2021 10:18:14 GMT; domain=www.test.org; path=/; Secure; HttpOnly
Some Notes & References why httponly wont address the issue :
Why HttpOnly Won't Protect You
Before going in depth criticizing the HttpOnly session protection mechanism I better explain what it is and why it is…
POC how to steal httponly session cookies with XSS using apache cookie overflow (CVE-2012-0053)
The basis of this attack is a known Apache vulnerability ( CVE-2012-0053) which leaks all cookies (including HttpOnly…
SecurityFocus is designed to facilitate discussion on computer security related topics, create computer security…
Cookie Stealing script : https://pastebin.com/17M79Mu3 if its Apache.
Few Updates After Feedback from my friends :
- There is HTTP ONLY attribute to secure up the session ,why i need to bother it about :
- A cookie flagged
Secureis only sent to the server if the connection is secure (i.e. HTTPS). That is, a man-in-the-middle attacker can't capture them by intercepting a plain HTTP connection to your site.
- A cookie flagged
HttpOnlyis not accessible to scripts. That is, an XSS vulnerability on your site wouldn't allow an attacker to directly exfiltrate a
- Additional to it If a website is enabled with TRACE httponly it can be beated.
- HttpOnly restricts all access to
document.cookiein IE7, Firefox 3, and Opera 9.5 (unsure about Safari)
- HttpOnly removes cookie information from the response headers in
XMLHttpObject.getAllResponseHeaders()in IE7. It should do the same thing in Firefox, but it doesn't, because there's a bug.
XMLHttpObjectsmay only be submitted to the domain they originated from, so there is no cross-domain posting of the cookies.
- Some additional references :
c)Grease monkey script : https://greasyfork.org/en/scripts/17580-netflix-import-cookie/code
2.If you were sending up xss hook via beef you cannot steal up whole user session :
- Once you own the browser ,we can do anything :)
Attack chain & Its impacts :
Alice sends vulnerable request to catch bob’s cookies and reuses it forever.Since cookies does not expire at browser side it can be used forever.
- Privilege escalation
- Bypass of limited users plan
- You can buy netflix as one user and share it to as many users u can.
Why it cannot be controlled :
- Users can be tracked via login sessions whereas we cannot track users based on cookies
How you can secure yourself :
- Dont fall for false popups.
- Always check on your concurrent login.
- More importantly Never reuse your passwords & Never keep weak passwords.
Proof Of Concept :
Sample Cookies which you can test :
Disclosure Timeline :
- 9th November 2018 : Issue reported to Netflix through bug crowd.
- 13th November 2018 : Closed as out of scope.
- 13th November 2018 : Explained attack chain with proof video.
- 14th November 2018 : Contacted Bug crowd support
- 15th november 2018 : Wont fix confirmed by bug crowd team
- 19th November 2018 : Public Disclosure through medium blog