Epic Holiday Cookie Baking

One aspect of being a penetration tester that is always rewarding is the process of rabbit-holing into an area of interest and letting the data guide me to my destination. Recently, while updating and testing new code on a custom cookie fuzzing tool (Anomalous Cookie – https://github.com/Coalfire-Research/AnomalousCookie.git/), I discovered a XSS (cross-site scripting) vulnerability on EpicGames.com. While it appeared possible to write a good payload (stealing cookies and injecting malicious JavaScript/BeEF hooking), I had no good way to deliver it. Traditional cookie-stuffing (https://en.wikipedia.org/wiki/Cookie_stuffing) might work to drop the rogue cookie onto a target’s machine; but could there be other ways? If not, this would most certainly be classified as 'Self-XSS.'

Self-XSS is often not viewed as a valid attack vector. Without solid Proof-of-Concept (POC) tools and examples, Self-XSS findings are generally regarded as LOW in severity (and level of excitement) and are rarely able to be weaponized. With this as my inspiration, I set out on a mission to use my findings around this anomalous cookie to create a usable attack vector and kill chain.

Currently we rely on security flags (‘Secure’ & ‘HTTP-Only’) to ensure the integrity of cookie data used by our browsers and web services. What if an attacker modifies our stored cookies locally? Will the browser detect malicious payloads and anomalous behaviors in efforts to thwart attackers? It turns out the answer is, probably not. Let's take Google Chrome for example. While Chrome has the ability to check requests for cross site scripting (with its XSS Auditor), it currently does not (nor plans to, according to them) check any cookie values for malicious content (thereby leaving a possible unsanitized input vector). Without having the knowledge on how to create a new cookie and add it to Chrome’s local cookie jar, I'm off down another rabbit hole.

Chrome cookies are stored within an SQLite database (‘LOCAL\APPDATA\Google\Chrome\User Data\Default\Cookies’) and can be accessed easily without any authentication needed (using DB Browser for SQLite or PSSQLite PowerShell Module for example). The only data encrypted in the database are the cookie values (named 'encrypted_value'), which can easily be decrypted using the local Windows DPAPI. In our case, we don't want to read the cookies, we want to write the cookies, and it turns out we don't even have to encrypt them!

DB Browser for SQLite showing the baked “_epicSID” cookie.

Also, if the cookie we want to write exists already, we can just delete it first and then inject ours into the cookie jar. With no flags currently used to identify disk tampering, no XSS Auditor to flag malicious code, and no way for the server to check against a client-side attack, the user is almost defenseless if an unauthorized user gains access to their system and bakes their cookies (there we go . . . let's call our new technique “Cookie Baking!”).

Let's create a quick 'Proof-of-concept' PowerShell script called 'CookieBaker.ps1'. In addition to inserting data into the SQLite database file, we will need to install supporting code to make 'Cookie Baking' possible. Here's the script . . .

taskkill /im chrome.exe* /f

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force

Install-Module PSSQLite -Force

set-executionpolicy remotesigned

Import-Module PSSQLite

$Database = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cookies"

$query = "INSERT INTO cookies

(creation_utc,host_key,name,value,path,expires_utc,is_secure,is_httponly,last_access_utc,
has_expires,is_persistent,priority,encrypted_value,firstpartyonly) VALUES ('13186874114525467','.epicgames.com','_epicSID','kpjak%3c%2fscript%3e%3cScRiPt

%3ealert(1)%3c%2fScRiPt%3efbu5ubf6b6ce405264df19ea1394b58aba4d0','/','0','0','1',
'13386874114525467','0','1','0',NULL,'0')"

Invoke-SqliteQuery -DataSource $Database -Query $query

CookieBaker.ps1 script being run on target’s system.

That's it! The script can be injected via local physical access, Rubber Ducky attack, AMT MiTM, WHID Injector, Metasploit (exec_powershell), and more. Here's a walk-through of the attack path:

1. Obtain access to target system (Windows)
2. Run 'powershell Start-Process cmd -Verb runAs'
3. Run 'CookieBaker.ps1' script (only 8 lines of code)
4. Upon opening any page within the EpicGames.com domain, the user will unknowingly load malicious client-side java-script. With the use of the correct payload the user may potentially lose all domain cookies/tokens and be vulnerable to 'Man-in-the-Browser' attacks (BeEF Hook).

Taking a look at Chrome's Developer Tools under 'Application,' we can view all cookies for the current domain (epicgames.com) including our baked XSS cookie.

Google doesn’t currently consider ‘local’ Chrome attacks as security issues and doesn’t have any plans to fix their current weak implementation of cookie protection and handling. To be fair, this isn’t just an issue with Google Chrome. It’s interesting that we are concerned about cookie tampering in transit (with the current protection flags used) but not while they are at rest on disk. Good pentesters (and black hat hackers) are used to having unauthorized access to several machines at any given time. Obtaining shell access is not necessarily hard to do when you are motivated and skilled, and public computers are at risk because users of the system do not usually have their own protected sandbox environment to do their computing. Allowing users (including unauthorized ones) to modify the browsers cookie jar is dangerous and should be reconsidered. Users can never trust the validity and integrity of their locally stored cookies due to weaknesses in how cookies are currently stored, processed, and handled.

While stealing my daughter’s Fortnite account (for fun and education of course) was certainly possible, I also realized there was potential for real financial losses through Affiliate Fraud (via mass Cookie Baking/Stuffing). Time to come out of the rabbit hole and see what we have.

1. I learned that ‘Self-XSS’ definitely appears to be a valid attack vector
2. Cookie Baking bypasses XSS Auditor (and no plans from Google to fix)
3. Local Cookie Tampering is allowed and easy to do (needs authentication/encryption)
4. No requirement for encrypted cookies when creating new ones locally
5. There are currently no flags regarding 'DISK,' similar to ‘SECURE’ and ‘HTTP-ONLY’

Next steps will be to use ‘Anomalous Cookie’ to identify additional vulnerable cookies, create a ‘Cookie Baker’ Metasploit module for post exploitation (for POC purposes), and help re-mediate ‘Self-XSS’ findings everywhere! More to come.