Last year we wrote an open letter to Valve regarding their security practices. This letter outlined several problems we, as a community of developers and gamers, had with Valve’s security practises. Chief of which were the lack of an incentive (“bug bounty”) program for reporting vulnerabilities, including the inconsistency in which Valve reward some reports; the lack of clear avenues for reporting vulnerabilities and for the receipt of a report to be acknowledged; and Valve inadequately communicating vulnerabilities to partners that may be affected.
In response to our letter last year, Valve evaluated their security procedures, explained their stance on security & their associated behaviours, and since then we have seen continuous improvements from Valve with regards to their security policies and facilities.
Now, just over a year on, we want to revisit the concerns we originally raised in the open letter, acknowledge the changes Valve have made to their processes over the last year, point out what we’re very happy with, and what we’re still not quite satisfied with.
Our purpose with this post is twofold: We want to provide a coordinated piece of feedback to Valve specifically with regards to security. We also want to provide the wider developer, partner, & gamer communities with information about Valve’s advancements and present shortcomings, so those parties can take the available and appropriate steps necessary to protect themselves and their products.
Reviewing last year's concerns
Incentives program
Valve’s response to our letter last year stated:
[...] Each team at Valve has slightly different requirements and goals when working on security reports [...] We don’t plan on establishing any formal bug bounty programs for any of our products at this time.
We haven’t seen any evidence of Valve’s stance having changed over the past year. Our opinion on this hasn’t changed either: we think the lack of a coherent reward program is ultimately detrimental toward Valve’s products.
We are aware of a few vulnerabilities found in Valve’s products over the past year that were exploited in-the-wild, and were actually rather simple to execute (the recent [password-reset vulnerability](http://www.theregister.co.uk/2015/07/27/gamers_steaming_over_dumb_valve_password_vuln/) being one such example). In our opinion, many of these vulnerabilities likely would have been caught, before being exploited in-the-wild, if Valve had a program in place to incentivise researchers to continuously probe their products.
We think the core problem here is Valve having no unified stance on incentives, and, within that lack of unification, the inconsistency in which researchers are sometimes rewarded: The rewards Valve offer – economy items – are distributed rarely, seemingly arbitrarily, and in some cases disproportionately to the value of a vulnerability[1], causing them to have no real value as an incentive for researchers.
Last year we stated the idea of rewarding researchers with economy items was “insulting”, and suggested monetary rewards are the best solution. We still think that is the case, but we think that even a coherent economy item incentive program would be a lot better than having no incentive program at all – Valve have proven that rare economy items do hold a lot of value to some customers, after all. The primary problem with economy item rewards, however, is that they alienate researchers who do not play the game for which the economy item rewards are offered – as far as we are aware, current economy item rewards are all unusual hats in Team Fortress 2; not very enticing for users who do not play Team Fortress 2.
We urge Valve to re-evaluate their stance on an incentive program and put together a coherent policy offering incentives, whatever form those incentives take (monetary, economy-item, or something else).
Ed note: As we were finishing up this blog post, Valve shipped the Finder's Fee hat in Team Fortress 2, pictured top-right. The Finder's Fee looks to be intended as a reward for reporting high-value vulnerabilities, so it appears Valve are already working on the problem of incentives already.
[1] Of course value is subjective, but this leads to some researchers becoming frustrated when they go unrewarded for a vulnerability they feel is of a higher value to other vulnerabilities that have been rewarded. e.g. http://redd.it/2nffw2
Difficulty reporting vulnerabilities
One problem we identified last year is that it was very difficult to discreetly report vulnerabilities if you were not already well-networked with Valve. Valve tackled this straight away by setting up a new page on their website, Security Issues, noting how to directly and securely contact Valve to report vulnerabilities.
Our experience reporting vulnerabilities as instructed on this page have been positive: Reports have been acknowledged quickly, fixed in an acceptable timeframe, and confirmation of the fix communicated back to the reporter as soon as the fix is deployed.
There is one outstanding issue that we have identified, as a result of reviewing the security page for this post, which is the page is still a little hard to find: It doesn’t show up on the first page of search results for the terms “Valve/Steam report bug/exploit”. A little SEO sprinkling, just adding the words “bug” and “exploit”, would probably go a long way towards solving that.
Overall, we are very happy with this page and Valve’s responsiveness to reports made via the methods noted on the page.
Communicating security vulnerabilities to partners
We are only aware of a single example, from this year, where we feel Valve has inadequately communicated a vulnerability to their partners, and – perhaps more frighteningly – to other product teams internally.
Given we are only aware of one example, we don’t have enough data to objectively evaluate whether there has been an overall improvement or not on the topic of Valve’s communication.
With regards to that single example: we won’t go into detail for this post, but we will state that were some concerning vulnerabilities in the Source 1 engine identified by one of our own community members, Nathaniel Theis, which were not communicated by Valve to Source 1 licensees, and which were also not communicated to all of the product teams within Valve – requiring one of the product teams to have to contact Nathaniel via Reddit in order to obtain details on the vulnerabilities.
We would like to commend Nathaniel for his efforts surrounding these vulnerabilities, as he went beyond expectations and worked, and is continuing to work, directly with various Source 1 licensees to fix the vulnerabilities identified in their respective products. If you are a Source 1 licensee and haven’t heard anything about these vulnerabilities, please contact Nathaniel directly for details (nttheis@gmail.com).
Security advancements over the past year
Mobile two factor authentication
The Steam Mobile app, for Android and iOS, now has the facility to generate Steam Guard codes, instead of having the codes delivered via e-mail. Being able to generate codes, versus having them e-mailed, is a net benefit for customers in terms of both convenience (e-mails can be slow and sometimes cumbersome to access) and security – being able to generate the code cuts out any middlemen in the process of the code being delivered, thus minimising opportunities for the code to be intercepted (e.g. by malicious software, or malicious actors in the network stack - if your mail is travelling unencrypted).
We’re not sure on the details of Valve’s two-factor implementation, but we would like it if Valve adopted the industry-standard time-based one time password (TOTP) implementation (if they do not already) and provide customers with the TOTP secret – so customers can use their own apps to manage these authentication codes, which is doubly useful for platforms for which there is no support for the the Steam Mobile app.
Add your phone number to your Steam account
Valve recently rolled out an update to the ‘My account’ section of Steam, and included the facility to associate your phone number with your Steam account. The page stated associating your phone number “will help you recover your account if you've lost your password or your Steam Guard authenticator.”
This facility was rolled out recently so we haven’t seen exactly what and how it’s used (just the description quoted above), but it appears to be another method of two-factor authentication for high-value account actions.
It’s good to see Valve protecting more and more account-related actions with a verification stage, but it’s a little concerning to see fragmentation already evolving in these verification methods. It would be a lot better to have these various actions use a single unified verification method, and give customers the choice of what that verification method should be (e-mail verification, Steam Mobile codes, SMS verification).
Trade confirmation e-mails
Steam now sends trade-confirmation e-mails when trade requests involving your account are made. This is optional, of course, but defaults to being enabled. Valve have also stated they will not offer support relating to stolen account items for accounts which have disabled this security feature, which is an understandable position to hold: Valve aren’t going to support you if you don’t utilise the available facilities to maintain the security of your account.
This is a good step towards keeping an account’s economy items safe. It will no doubt cut down on the amount of economy items lost through compromised accounts, or potentially through XSS exploits or malicious software on the end user’s machine.
This is another opportunity where Valve could replace the use of an e-mail confirmation with the use of two-factor authentication, for the same reasons we praised two-factor auth in the section above.
Reduction of automated phishing accounts
Valve have implemented a number of improvements over the past year that have greatly reduced the amount of automated phishing bots on Steam. We understand these improvements have been primarily related to the base restrictions applied to newly registered accounts, and there has been a noticeable drop in nuisance bots on Steam as a result. There’s nothing else to say on this point, but we did want to acknowledge it – we’re thankful for the drop in nuisance bots!
To conclude
Valve have made a great number of improvements with regards to the security of their products and customers over the last year, both in response to the points raised in our open letter and of their own volition. We still think Valve need to review their stance on incentives for reporting vulnerabilities, and we’re not quite sure how things stand with regards to Valve’s internal communication and communication with partners – the one example we have above, where we believe Valve failed to adequately communicate a security vulnerability, doesn’t give us enough data to make an objective observation on this point. Beyond those two points, we are happy with the work Valve has put in to security over the past year, and are excited to see what will happen in the coming year.
Sincerely,
Rob Jackson (Official Team Fortress Wiki)
Martin Benjamins (SteamDB)
Pavel Djundik (SteamDB)
Nathaniel Theis (Concerned Citizen)
John Drinkwater (Concerned Citizen)
Jesús Higueras (Galactic Cafe)
Tomáš Duda (Concerned Citizen)
Daniel Evans (Concerned Citizen)