1. Log on as non-admin on a box with steam 2. Do not start steam or any game 3. cat %system32%\calc.exe > %programfiles%\steam\bin\steamservice.exe 4. Reboot 5. Log on, start steam 6. BAM! Now you have calc.exe (attempted to) run as System with highest local priveleges
This requires elevation.
I didn't modify anything so I assume Steam set it that way.
Headdesk
However, I'll point out that one hardly needs administrator access to, say, encrypt your documents and install a crypto miner. The whole idea that gaining administrator privileges through local escalation on a personal desktop is A Big Deal(TM) is silly.
So even if someone gets exec on your user files, you'd still prefer them to be limited to your user and not running at higher priv levels. Even if 90% of the damage is done with access to your personal files, it still adds more damage with higher privs.
Plus this means user-level countermeasures like "run steam as a separate user" are useful; with escalation, that's not an effective defense. Also, if you've got multiple users on the computer, an attack that can't escalate privileges might ruin your day, but an attack that can escalate privileges might ruin your day and your spouse's day and anyone else in your family's day, so even in terms of "personal files" on a modern Windows system you can still be looking at more damage from an escalating attack.
> So even if someone gets exec on your user files, you'd still prefer them to be limited to your user and not running at higher priv levels. Even if 90% of the damage is done with access to your personal files, it still adds more damage with higher privs.
This is debatable, since whatever other damage they could do is something I'm not likely to care very much about compared to all my work, the whole reason I have a computer in the first place, being held for ransom or otherwise lost to me.
> Plus this means user-level countermeasures like "run steam as a separate user" are useful; with escalation, that's not an effective defense.
I suppose this is true, however I don't think any competent authority will tell you that simply running a program you don't trust as another user should ever be relied upon as a sandboxing mechanism anyway.
> Also, if you've got multiple users on the computer, an attack that can't escalate privileges might ruin your day, but an attack that can escalate privileges might ruin your day and your spouse's day and anyone else in your family's day, so even in terms of "personal files" on a modern Windows system you can still be looking at more damage from an escalating attack.
That's a fair point.
You're right that merely using "runas" does not provide any additional security (at least none that can't be circumvented). However if you run an application in a separate desktop session under a separate user account that does not have admin access at all (e.g. the account type is "standard user") then it should be sandboxed from other users (in technical terms, it's a security boundary).
The most practical way to do this on a consumer desktop would be to have a separate "Steam user" account that you log in to for the sole purpose of running Steam. While most people wouldn't want to do this (as it's inconvenient), it should at least be an option for those that do want it. To put it another way, there's no good reason to undermine the enhanced security provided by separate user sessions.
I’ve seen steam on work computers. This isn’t limited to home desktop users by any stretch. People install steam because they don’t know it puts their work computers at risk.
You could argue that they shouldn’t have games on a work PC (some companies are a bit more lax and even play together) and an easy way to convince them to not do that is if you point out that Steam makes your system less secure by design.
Steam also sells design tools and complete sdks. Idk if it is a common way to install them though.
Security is still important for those companies
Edit: downvoters, I would really like to know why this post deserved downvotes
Tell me, what precisely does having administrator privileges on a workstation provide that having the user account's privileges does not? With the user account you still have access to the user's files (and they are almost certainly the only user of that workstation) and all network resources they have access to.
If the machine is on a Windows domain, usually anybody on that domain can log on to it. Which means I can walk up to your machine while you grab a coffee and use this attack to gain full control over everything on your machine. If you do anything personal on that machine, eg email, I just got access to it.
The parent is describing an attack which does not require the administrative user to do anything except install Steam. Any other user who can logon to that machine could use this privilege escalation exploit to access the administrative user's files
However, this is not necessarily the case, so I yield the point.
As a particular problematic scenario, consider a school: Steam cannot be used in educational settings because of this issue.
But no let’s just forget all of the reasons we use group policy and principles of least privileges.
Imagine if your initial foothold is user with Steam installed. You just got SYSTEM for free.
What good is the computer account for this when you already have the user account?
> But no let’s just forget all of the reasons we use group policy and principles of least privileges.
By that rationale, computer accounts should have far fewer privileges than the actual user account anyway, so again having local admin isn't worth much.
> run code that wouldn’t otherwise be possible
Namely?
> Imagine if your initial foothold is user with Steam installed. You just got SYSTEM for free.
And I'm struggling to see how that adds much to my problem of someone having a foothold on a user workstation already.
And that's ignoring the circumstances of Steam being installed on the workstation in the first place AND the user having installed some untrustworthy game with it in the window since the game's appearance on Steam and its detection and removal.
Which is also not to mention that this means the user has the ability to install software and is therefore infinitely more likely to just download some malicious installer from the nefarious portions of the internet that they can access with a web browser.
Powershell, friend. Changing execution policy requires privileges. Guess what SYSTEM gives you? Plus you can disable windows defender and install any nasty things you want! Pretty sure you’d need system to snoop/inject traffic too.
If you have other services or applications installed (like IT setting up your workstation), those things can now be read/changed where they otherwise wouldn’t be with just user access. This can lead to other information leakage about other parts of the network or services.
>And I'm struggling to see how that adds much to my problem of someone having a foothold on a user workstation already.
No fucking shit, but you don’t let them walk into system just because they got user.
You’re taking the stance that any compromise means death and that’s directly opposite of defense in depth, so you clearly don’t believe in that. That’s just being lazy mate. Why not just chmod 777 everything and call it a day?
>Which is also not to mention that this means the user has the ability to install software and is therefore infinitely more likely to just download some malicious installer from the nefarious portions of the internet that they can access with a web browser.
Because they don’t know Steam is insecure by design! They trust Steam! That’s the problem! This isn’t common knowledge and since Steam won’t fix it, it needs to become common knowledge.
PowerShell execution policy is stupid easy to bypass. You simply pass the '–ExecutionPolicy Bypass' parameter when launching the script. Of course, since you already have complete control of the user account, being able to run PowerShell isn't nearly as big a deal as the fact that you can run anything at all.
> Plus you can disable windows defender and install any nasty things you want!
Windows defender, like pretty much all AV software, is crap anyways and won't detect most of the things you'd be interested in doing. It's a low-effort screen for well known malware. Case in point: it didn't catch your malicious installer when Steam downloaded and ran it in this scenario did it?
> Pretty sure you’d need system to snoop/inject traffic too.
That may well be true, but considering I pretty much already have full control of the user account and can therefore do everything it can do on the network without injecting anything, I'm not sure what is gained.
> No fucking shit, but you don’t let them walk into system just because they got user.
Eh, it isn't really worth my effort to try and prevent it when all they'll have to do is fire a UAC prompt the user will almost certainly just click through anyway. Especially considering what little (basically nothing) it gets the attacker.
> Because they don’t know Steam is insecure by design! They trust Steam! That’s the problem! This isn’t common knowledge and since Steam won’t fix it, it needs to become common knowledge.
So here's the scenario you're talking about: A user has installed Steam on their work computer. They use Steam to download an installer that is actually malicious and this fact has not been caught by Valve yet. Steam, who's entire purpose is to install games, runs the installer. Consequently, the user account is now owned by an attacker.
...And even if this vulnerability were patched ALL OF THE ABOVE WOULD STILL BE TRUE!
GPO prevents this but if you have local system you can override that locally and then change execution policy.
I’m sorry, I don’t say this often but you don’t know what you’re doing so I’m not going to take the time for the rest of your post. I’d encourage you to research this more if you like it.
You strike me as a very typical infosec person, always endeavoring to make mountains out of molehills and add unnecessary friction to everyone else's job in order to add minor benefits in highly improbable scenarios.
All things considered, thanks for discussing this with me despite my harsh language and tone. It’s a bad habit of mine
Makes sense, because Windows is also used for servers. The Steam client is not.
> If Steam is installed on a corporate network PC (game development, QA services, esports teams, etc?), regular users being able to elevate to machine admin is a big deal.
No it isn't. This is effectively the same as being installed on some home PC. Being local admin on the workstation doesn't really give you any more ability to do damage than just a regular user account. A non-administrative process still has access to all the user's stuff, and all the network resources that user account has access to. Local admin doesn't really give you anything new.
That's dangerously untrue. On all the Windows systems at home, everybody else is a non-privileged user and I set sane file permissions so they can get to shared movies, etc, but not read my bank details and tax records. Privilege escalation means that they could trivially change those permissions. The same is true of a corporate environment -- just because you can't also make changes to AD doesn't mean the threat of accessing local files under other users' accounts is trivial.
ETA: I just read a bunch of this user's other posts in this thread and I'm beginning to suspect they're trolling, so I'll disengage.
Ok, in that scenario it is true, but multi-user desktops in the age of smartphones and tablets are a vanishingly small niche. My experience in corporate environments suggests they are also almost entirely 1:1 as well.
the issue is this file has W permission for all users
you can't write there without elevating. at which point you can just register stuff to run as you wish.