Valve accused of ignoring existing RCE vulnerability in Source games for 2 years
twitter.com
twitter.com
This was 5-6 odd years ago and he no longer works there, so things might have changed, but based on this tweet it seems unlikely.
This seems to be a common theme with problems at Valve.
Our lead says that all work must come from the scrum master but in practice it is selectively enforced.
The typical problem at software companies is that developers are incentivized only to write code for new features that will land them promotions and look good on their resume--but bugfixes and security work is not part of that.
Management can counteract this with top-down initiatives. Programs like "fix-it week" or teams dedicated to security with different incentives in place. For example, Google suffers from the "promotion-oriented programming" about as badly as any other company, but they manage to take security seriously.
Valve has "flat hierarchy", which goes in quotes because the hierarchy isn't really flat, it's just hidden. Because the hierarchy is hidden, it's harder to address large-scale problems like institutional priorities... because there are fewer people to delegate large-scale problems to.
There is even reason for (say, for example) Rockstar to leave hackers alone in GTA : they act as artificial whales to lure real players into buying in-game currency in order to keep up/seek revenge.
There are a few games I can think of off the top of my head that have a symbiotic relationship with hackers.
The only way to prevent this is to remove elevated access from the player's computer. This has been done with varying levels of success on consoles, but even then it's only a matter of time.
But I also think a lot of the hackers in both GTA and CS are cheating in ways that no regular user input could trigger, they're compromising the software at a lower level than that.
The bigger problem is that even with input recognition, one of the biggest problems are wallhacks, meaning you can see other players through walls which is an advantage that's almost as large as aimbotting in tactical shooters like CS.
The lack of care regarding source engine netcode extends to every part of the source engine, including Valve Anti-cheat.
The anti-cheat is trivial to reverse (several PUBLIC bypasses have existed for years on github, with zero patch), the engine source has been leaked, reverse engineered, and fiddled with by thousands of 14 year old kids. It is pathetically easy to bypass, for example, by changing a single byte in memory you can see through walls, see enemy money, etc. See this video I found about how miserably broken it is: https://files.catbox.moe/8e3bxz.mp4
It is in my opinion the greatest loss to gaming that a classic, legendary game like Counter-strike got completely ruined by lack of care by a company that profits millions off of the case unboxings.
> It is in my opinion the greatest loss to gaming that a classic, legendary game like Counter-strike got completely ruined by lack of care by a company that profits millions off of the case unboxings.
have you played the game in recent years? this has not been the case for me or the people I play with at all.
when playing on high trust-factor accounts, cheating is basically eliminated.
the experience for newer players is pretty bad but once you convince the system you're trustworthy, the algorithm does an extremely good job of not matching you with cheaters.
what valve lacks in boring, sensible solutions they make up for with interesting often much more complex workarounds (see: the open-world csgo danger-zone map shoved into a game with a room-based engine)
I know he couldn't be an expert but the person on my team says he can he blatant every game and never get banned because we're on prime. I don't want to believe that but then he had a lot of items and didn't mind spinbotting at all.
This is all really just anecdotes, but here's my counter anecdote. I play csgo on and off with friends. None of us have ever cheated in csgo (or any other competitive online game for that matter). I'd say we get about 1 obvious cheater every 50 games, with 2-3 less obvious "maybe they're using wallhacks" as well. This is significantly improved from 3-4 years ago where we got a cheater once every 4-5 games.
The rest of us aren't cheaters. We have old steam accounts with lots of games, items, and play time. We have prime. We still got put into that lobby. I'm not good enough to look like a cheater on my playing alone either.
Yes, but this is not a technical fix. You just hope that accounts with more "value" cheat less. Which is true in most cases.
Trust does actually work a lot of the time. But you'd think account security would be easy for them to crack down upon.
People think you're kidding, but it's really that easy on Source! For a while, the most popular TF2 (a Valve Source game) hack was created by a 15 year old. He made at least a million dollars in profit too! (can't remember if this factoid was verified or not, but he can definitely pay for college now) I wasn't as nearly as talented but I made some hacks for fun when I was 15 or 16 years old.
Yeah....no not exactly fun.
Luckily you can now report accounts for this, and with enough reports they will be auto-muted now.
Strangely the only difference between one java cheat that was detected and one that has been undetected for four years, is that the original, old java one that got detected was licensed upder GPL, and the newer one is licensed under AGPL. Then there's a newer fork with a GUI that is undetected for ~2 years.
VAC seems to be... unable or unwilling to detect Java cheats. The original, old one got detected, though, and it was Java. so there is a tad of confusion.
I have sent countless messages to valve offering patches for several current exploits, like the current server lagger/crasher that allows teleportation. They literally just do NOT care. At all.
The premise of bug bounties is that the reward amount is at the discretion of the program host and that the time incurred by developing a fix will influence the moment of payout, but refusing to pay and even communicate (for years!) for clearly eligible submissions is well beyond a reasonable interpretation of the conditions, and to consistently keep facilitating this abuse is simply fraudulent.
Some game companies (riot games) even install their anti-cheat software so that is loads in the ring 0 space. Even with their best efforts, cheaters will still prosper.
Might even go a step further and firewall my gaming machine off from the rest of my network.
Maybe we should we run the entire OS in the games hypervisor?
Some of the MMO games I've played used this gold transfer "graph" analysis that worked pretty well with really low False Positive Rate.
One of the best tricks is to show them messages via a method outside of normal chat which a normal player would see on their screen, but which a bot would not receive as 'chat'.
As for not talking to anyone, a surprising amount of people play MMOs just like that, so it's not really atypical for a player to never communicate. Runescape even has an account choice, "Ironman Mode", where you have to play the game self-sufficiently, and can't trade with or rely on any other players. You can still chat with other players if you want, but you don't have to.
Or in some games, they can send messages in a way that a human would see, but not a bot who expects the messages to come over chat. For example, waving a sign in front of the character's face with a message or whatever. It helps that the admins can also hide from normal presence detection, even though they're visible on the bot's screen, visually.
I've literally watched admins ban a bot using these precise countermeasures. The trick is to always keep giving them new things they haven't thought of to adapt to.
With mobile games it's ridiculously easy. I actually made daily task farming bots for a couple mobile games I used to play. The hardest part was getting the bot to log into the game. Completely neutralized the habit-forming strategies of these game companies. Ironically the bot was statistically indistinguishable from any sufficiently-addicted player.
No need for a camera when you can just stream the screen.
All of the anti-cheat solutions I've seen that run in kernel mode are none of those things. They make it well known that they're installing, are made by vendors that actively care about the security of their products, and are trivially easy to remove once they're no longer needed.
The Genshin website previously allowed anyone to view the phone number you have linked to your account via the password reset mechanism. Due to common reports of accounts getting stolen (and unable to be recovered), two factor auth has been highly requested, but doesn't seem to be a priority. I'm skeptical that they strongly care about the security of their users.
Even if Genshins anti-cheat is completely secure, as kernel anti-cheat becomes more common it's inevitable that we will get an instance that is full of security holes. Unfortunately as long as the user can't play their favorite game without it, they will happily install it.
More importantly though, once you're in the kernel, its much easier to hide your presence to all manner of Windows sysadmin tools.
Mirror repo after the original author took the repo down, but still exploitable AFAIK.
https://github.com/Luohuayu/evil-mhyprot-cli
Not as bad as capcom.sys:
https://mobile.twitter.com/TheWack0lian/status/7793978407622...
The effect is the same though: ring 0 code execution.
I'm of the opinion that easy kernel access for all apps and games is ultimately not putting me in control of my computer.
But beyond that, I don't see how "more restriction" == "more control for the user"
Many vendors originally hid the fact until they started receiving community backlash about it. For example, Riot with Vanguard originally hid*[0] that it was running 24/7, and also hid the fact that it blocked drivers, until people noticed and complained about it. Many games, PUBG Lite and Genshin Impact in recent memory, also do not reveal this to the user.
[0]: https://gameriv.com/vanguard-adds-a-system-tray-icon-to-give... *: I'm aware there was a blog post about it, but blog post about it != clear, upfront warning on install about behavior
> ...made by vendors that actively care about the security of their products...
Here's some fun, all involving anti-cheats:
- Using xhunter1.sys (XIGNCODE3) for an LPE: https://x86.re/blog/xigncode3-xhunter1.sys-lpe/ (still used in some MMOs!)
- Using capcom.sys (rootkit shipped with Street Fighter V) to write a rootkit: https://www.fuzzysecurity.com/tutorials/28.html
- Using mhyprot2.sys (from Genshin Impact) to read/write umode memory / read kmode memory with kernel privileges: https://github.com/ScHaTTeNLiLiE/libmhyprot (still exploitable, AFAIK!)
- Using BEDaisy.sys (BattlEye - shipped in Rainbow Six: Siege, Fortnite, etc) for handle elevation: https://back.engineering/21/08/2020/
In addition, you still need to trust the vendor (duh!). Some of them are essentially RATs, like BattlEye - it loads shellcode from the server that runs in BEService as NT/SYSTEM, and they can target code pushes by IP/ingame ID/etc. Reverse engineering the anti-cheat itself is not enough to trust it; it can change its behavior as it sees fit. They can even choose to specifically target you and steal your files, and there's a very high chance you'll never find out about it.
> ...and are trivially easy to remove once they're no longer needed.
Depends on how you define "trivially easy" - for eg. with Riot Vanguard, it installs/uninstalls separately from Valorant so you need to remember that separately. Some other ones, like xhunter*.sys install silently and aren't easy to uninstall at all unless you go delete files in System32. Others like EasyAntiCheat/BattlEye (last I used it, been years since I've touched them) need special uninstaller .exes that are included with the game, but are not registered with Windows or don't run automatically when uninstalling the game.
Many games package in outright spyware that siphon all kinds of data off your machine including browsing history. Kerbal Space Program was infamous for this (they removed the spyware at some point but I haven't checked recently if it was ever added back in).
Please post details. Were they literally mining user data?
https://www.theregister.com/2016/09/23/capcom_street_fighter...
https://mobile.twitter.com/TheWack0lian/status/7793978407622...
Their software also takes screen shots, walks the file system, scans people's processes... Any similarities to malware may or may not be mere coincidences. They're also known for false positives: banning people for receiving special strings via text message, unknowingly installing mods with hacks bundled in or due to the presence of development tools such as debuggers or even virtual machines. Good luck trying to reverse such a ban, the entire gaming community has already been conditioned to accept any decision as final and to even defend this practice. When coupled with DRM, this essentially means your license to play the game has been revoked with no refunds.
Why are separate machines required, rather than dual-booting? (i.e. Windows for games, Linux for everything else)
The correct way to do so, is to have separate hard-drives for different OS. Then there is zero chance of them stepping on each other.
Most of the components have firmware that can itself be loaded with malware.
Is there _any_ way to bypass this, apart from separate machines? I didn't know this was possible.
This is one of the reasons I'm so enthusiastic about the T2 and M1: a hardware root of trust designed by a competent vendor. (Yes, there is a flaw in the T2, but it requires physical access to exploit.) In my opinion, those are the only trustworthy desktops or laptops on the market right now. You'll notice AWS (Nitro) and Google (Titan) also have their own proprietary hardware security chips for the same reason.
Depends on what the avenue of exploit you're worried about is. You can disable BIOS flashing from the OS in the BIOS, but that might still be theoretically vulnerable to, say, compromising the Intel ME environment and flashing from there; a rootkit loaded in SMM could hang around until the machine is cold power cycled (and theoretically compromise the bootloader(s) to load itself and then chainload the "real" bootloader every boot); if you want to get really invasive, you could theoretically start flashing various microcontrollers attached to the system (say, a USB flash drive, or your HDD/SSD controller) to do malicious things.
These get increasingly unlikely (and unreliable, without knowing and targeting the specific hardware you're using) as your attacker model includes less resources, but not impossible. Intel ME code execution, BIOS and SMM rootkits, malicious USB flash drive firmware and HDD firmware have all been demonstrated (I haven't seen malicious SSD firmware, but there's nothing theoretically stopping it other than the controller doing a lot more on them), and a couple have even been found in the wild.
It is currently unclear whether there is a publicly available PoC or any exploitation going on in the wild.
[1] https://twitter.com/AntiCheatPD/status/1380873722966503426
I'll second that.
I discovered and reported a vulnerability with the Steam client's Bluetooth pairing process via hackerone.
The issue was confirmed but decided "out of scope" as apparently "within bluetooth range" runs afoul of the bug bounty's "require physical access" exclusion.
8 months later (I haven't exactly kept on top of this) they're still demanding I keep it confidential. I'll follow it up...
I have been involved with other bounties on that site in that time, related to other companies & products.
I suspect if I had "broken their (Hackerone) policy" with this issue in that time, there would have been problems receiving a reward from the other bounty programs relating to different companies...
This isn't the only reason I haven't publicised the issue more widely, I've had other things on my plate, but it is a consideration.
There is this so-called "Steam web API key scam" which is ongoing for years at this point: Scammers create phishing Steam login pages to grab people's credentials. Just with these credentials, the damage an attacker can do is still limited because of 2FA. However, the biggest flaw is that it is possible to automatically create API keys for the phished accounts that allow 24/7 remote access of these Steam accounts without the user even noticing. With this access, scammers then automatically modify and alter trades at will and at any time in the future, milliseconds before people confirm them using their mobile device (2FA), e.g., by declining the original trade and setting up a new trade with a scammer's bot account that has changed its profile data to the one of the actually intended trading partner.
This attack is mostly based on phishing, spoofing and confusion, but it could at least be made much harder by preventing automated API key generation and therefore indefinite access to an account (e.g., by implementing email confirmations or captchas for API key generation).
Each day lots of children or laypeople are losing in-game items worth thousands of dollars. I'm admin on a popular CS:GO and gaming Discord server with ~30k members and we see such reports multiple times a week.
Valve has no incentive to fix this as long as it's not their money or regulators start applying pressure.
So, here's what makes me confused about your story:
1. I don't see any kind of activity hooks in IEconService, that would let the attackers know via a callback that. Are you saying that they're polling all the hijacked accounts at a high frequency to detect trades they could intercept? That seems like a highly divergent use case from normal uses of the API, and one that an abuse team would be motivated to prevent.
2. I thought the Steam trade confirmation dialog showed very specific information about just what was being traded for what. I.e. it's not just that you're approving "a trade with foo", it's "a trade with foo (whom you've had as a friend for 20 days), where you give a xyzzy and receive a quux". Are the users just blindly approving trades worth thousands without even verifying?
I don't like either of your solutions though. A captcha would be just be minor irritation for the attacker, and anyone who can be phished into logging in can be phished to approve the key generation. It seems that the bigger problem here is that the API keys are unscoped. Once you have that, it's easier to inform the user in the approval flow about just what they're approving, and viable to nag the users into revoking access for apps with dangerous permissions.
People do. Many years ago I started playing an MMOG and the old timers were all discussing some incredibly rare new item. So I said I had one, and someone said he'd give me 100 million credits for it. For comparison, I'd just spent several hours grinding out about 10 credits. So I sent him a formal offer - some random piece of junk for 100 million credits - and he was so excited he clicked OK without reading what he was getting. He was so angry! He spent weeks spewing venom on the forums.
Of course, this wasn't real money, but in terms of time spent earning it he suffered a significant loss.
True indeed.
> Are you saying that they're polling all the hijacked accounts at a high frequency to detect trades they could intercept?
Yes.
I have to admit, the "milliseconds before" part was just wrong because I failed when trying to oversimplify for attention.
> it's "a trade with foo (whom you've had as a friend for 20 days), where you give a xyzzy and receive a quux". Are the users just blindly approving trades worth thousands without even verifying?
Often, the attackers focus on swapping trade offers that are initiated from a 3rd party, e.g., a trusted middleman marketplace site that requests your item (with nothing in return) that you want to offer. 3rd party sites take a lot of blame for "stolen items" because people don't even understand how this scam works.
Here, the few seconds are between the 3rd party offering the trade and the compromised user accepting the trade, not between the user accepting the trade in the browser and on his phone. Since the phished user is not aware of the 3rd party site's account in the first place (it is not one of his friends), it is very easy to clone all the observed account details and transform a scam bot account into looking like it is the one from the 3rd party site. Actually, there are characteristics that cannot be spoofed, but an ordinary user, not even aware that he was phished and that someone has control over his account who can do such things, will not notice this.
Now, you could argue that preventing 3rd party sites from existing could also solve this issue. However, I see a valid use case in these 3rd party sites. The goal of my suggestion is to counter these attacks with minimal effort without disabling automated trading capabilities completely:
> A captcha would be just be minor irritation for the attacker, and anyone who can be phished into logging in can be phished to approve the key generation.
I agree that it would only make the attack harder, not impossible, but considering the usual workflow I still see this as an improvement - as a first step.
The phishing is usually done by setting up a "legit" website, e.g. for skin trading, skin gambling or even any other non-financial purpose that requires authentication via Steam. This "legit" website then spawns a malicious "Login with Steam" OpenID credentials popup, rendered inside (!) the web page. This means, the website itself draws (depending on your OS and browser) a perfectly fine looking Browser popup window inside the legit page. It basically spoofs the browser UI itself. Laypeople get fooled easily by this, they sometimes do not even question why the window cannot be dragged out of the page, if they even try. These web apps are built in top-tier quality because obviously, the profit potential is huge. There is probably even a framework sold to easily recreate such pages at this point.
What I'm trying to say is: Getting the user to login is easy because it's part of the legit workflow. The API key generation - not so much.
Basically, everything I'm asking for is to make it hard to automatically transform a normal user account into a bot account used to automate trade offers. I know that there is a valid use case for automated bot accounts and automated trade offers. But the automation of the action to enable such functionality for an account should be prevented at all cost, and it should be explicitly requested from the user, including a warning.
Probably you are saying something similar with that statement with which I agree:
> the bigger problem here is that the API keys are unscoped
TL;DR: I think that preventing automated Steam web API key generation is the best short-term solution considering effort to make the attack a lot harder for the scammers.
The one I am always sent just shows a W10 decorated window. I've reported this same exact fake steam login popup thing to Cloudflare many times, yet the attackers seem to be deploying almost the same exact site time after time. Thankfully, Cloudflare eventually gets around to taking them down, but they aren't doing anything proactive to stop it from happening again.
https://www.hackerone.com/disclosure-guidelines states that "After the Report has been closed, Public disclosure may be requested by either the Finder or the Security Team." - so if the report just doesn't get closed, you can't disclose through the platform, and https://www.hackerone.com/policies/code-of-conduct says "Disclosing report information without previous authorization is not permitted."
To me, that seems that you're not permitted to disclose the issue at all until the report has been closed and either 1) 30 days have passed and the security team hasn't requested an extension, or 2) "180 days have elapsed with the Security Team being unable or unwilling to provide a vulnerability disclosure timeline".
Due to this, I refuse to report through HackerOne.
[1]: https://twitter.com/floesen_/status/1337107178096881666
It depends on whether you think there's a reasonable chance that someone may be using that exploit by now. Carrot and stick approaches do not work without a reliable stick.
Edit: I suppose it also depends on how much you value going through the exact same process with valve for other bugs in the future. But in a situation like this it seems like little would be lost.
HackerOne is almost certainly smarter than doing that because this would immediately ruin their reputation as a bug reporting platform (and expose that they're complicit in suppressing disclosure). They're much more likely to just ban the H1 account or issue some limited penalty.
Valve could potentially try, but the risk here also seems minimal: They also have a reputation to uphold, are experienced enough to know that suing security researchers paints a really bad picture and would draw attention to their vulnerabilities, and especially if their software is full of holes, this would almost certainly cause many people to disclose information about those.
There's a small chance you might still get the bounty, because you reported it first. And if not, because it's already disclosed by another party, you can cry foul on social media.
Full disclosure or no disclosure.