Re-evaluating Local Administrative User Rights
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
You are focused on a single kind of threat, not security in general.
My concern is all of it but I don't have time to give an example for every single security issue. If you have more and better ones, please list them. I'm looking for as much as possible here.
-
@scottalanmiller again, my focus is not ransom ware, I used that as a single example for some point i don't remember now.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
If it's about users doing something to work around company device management and security software, well then at that point it becomes a matter of company policy, management, and not an IT issue.
An ounce of prevention is better than a pound of cure.
Policies are only good if they followed, HR & management are only good if they have the balls to do something.
Chances are that a rogue actor won't care about policies or HR.More importantly, normal end users are not trained to understand what they are doing in most cases. Ignore malicious actors, we are talking about good, well meaning people that HR has vetted. They still don't understand what "installing" means, they can't identify safe sources, they don't have the diligence to do package maintenance, they don't know overarching IT strategies, they don't control licensing or often even have awareness of it.
I think this is key here. These things are the difference between them and us.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
credential stealing/online trickery aren't what local admin right (or rather lack there of) are there to protect.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
credential stealing/online trickery aren't what local admin right (or rather lack there of) are there to protect.
Right. I wasn't implying that it was in that statement.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
Ransomware does not REQUIRE admin rights to work, it just becomes more powerful when it gets them. By getting admin rights it can move from "trivial to stop" to "extremely hard to stop", it moves from "easy to identify" to "medium to identify". It changes from "encrypts one user's stuff on the machine" to "encrypts every user's stuff on the machine plus the machine itself." And with admin rights it can hide itself, make itself start without a user, and control its priority. It's like your car doesn't require tires to drive, but it sure works better when it has them.
Devices in this scenario are strictly single user devices. Not MS AD domain joined.
Software in Win10 doesn't just get admin rights, that requires a very specific set of events or oversights that don't exist in this case. If a random program wants to execute from downloads folder or somewhere similar, it will do so as standard user. So it can't just get admin rights and hide itself.
Sure, but you just said this is basically in a home user situation - what home user won't just click allow when they see those prompts? Nearly zero will actually consider what is being asked... instead most will just click OK to get rid of the damned box with no comprehension on what was asked or what is happening.
By not having local admin rights, and requiring an actual password be entered for a different account, these home users will be forced to think .1% more than they did before - and some might actually stop before getting themselves infected.
But that's still not the norm for Windows - Windows still builds the first, and generally only, account with local admin rights, so they aren't getting that benefit anyway.
So what situation are you envisioning where this would ever be a real problem for non domain joined machines (domain being either AAD or AD?)
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
It is possible. I uncovered a few people doing it here at work. It came from some of the Office 365 installs where they were installing various apps on their own like Teams and such. In any other case they are not allowed to install anything on their own and no one except myself and 1 other has local admin rights to anything. So now I worry about some hacker who realizes this about Office365 and tries to phish our users using links that look like O365.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
Sure, but you just said this is basically in a home user situation
Entirely enterprise, not home use-like at all.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
Sure, but you just said this is basically in a home user situation
Entirely enterprise, not home use-like at all.
You said not MS AD joined at all - so what are they joined to? What's forcing them to have a local admin account? nevermind - that's not really part of this conversation - you're simply stating as a starting point, machines either have or don't have a local admin account, and the user either does or doesn't have local admin access themselves.
got it. -
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
Having removed admin rights, you have defeated something that the A/V vendor doesn't yet have a signature for.
Not necessarily, with UAC, programs ran as users in the local Administrators group still runs as a standard user and requires elevation.
This is partially true, but only sometimes. There are ways around it. Lots of applications get installed with admin rights and once there, UAC is disabled. Look at any IT management toolsets, for example.
This example requires admin rights or UAC in the first place. That's not the issue.
Yes, but only once. And that's all that it takes. Once it gets the rights, it can do unlimited things, for forever. Including installing other things, like ransomware.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
No, AV is designed for viruses. Trojans bypass AV by their nature.
My point is that trickery IS what not having local admin rights is all about.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@nadnerB said in Re-evaluating Local Administrative User Rights:
I'd say that most malware wants to write something to the local PC.
Right, but there are a lot of places on the PC you can write to that does not require local administrative privileges.
True, but those spaces aren't ones that will automatically execute.
what? there is a an auto start area for the local user space.
Yes, and it doesn't auto-start with the computer. Nor does it start as an admin. It's just "the end user starting it when they log in". Not the same at all.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
Ransomware does not REQUIRE admin rights to work, it just becomes more powerful when it gets them. By getting admin rights it can move from "trivial to stop" to "extremely hard to stop", it moves from "easy to identify" to "medium to identify". It changes from "encrypts one user's stuff on the machine" to "encrypts every user's stuff on the machine plus the machine itself." And with admin rights it can hide itself, make itself start without a user, and control its priority. It's like your car doesn't require tires to drive, but it sure works better when it has them.
Devices in this scenario are strictly single user devices. Not MS AD domain joined.
That's a new limitation. AD isn't a factor, but only a single user is. But only a small one.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Software in Win10 doesn't just get admin rights, that requires a very specific set of events or oversights that don't exist in this case. If a random program wants to execute from downloads folder or somewhere similar, it will do so as standard user. So it can't just get admin rights and hide itself.
That "very specific set of events" is just... "the end user clicked the thing that they click constantly because that's what they are trained to do". There is an effective "ok" button and once you are in the mode of clicking that, the "specific set of events" doesn't exist. So once you make end users local admins, it disables that protection in the brains of essentially all end users (and IT pros.)
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
Yes, but it's "run in the user space". Everything works that way. Office suites, you name it. Chrome is just a "portable app".
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
You are focused on a single kind of threat, not security in general.
My concern is all of it but I don't have time to give an example for every single security issue. If you have more and better ones, please list them. I'm looking for as much as possible here.
Just... all except the one that you keep mentioning. Ransomware is unique in that it is a specific threat that is pretty egregious without admin rights. Essentially nothing else is really like that.
So all traditional threats is what the rest of us are discussion. All virus, trojans, root kits, remote execution tools, etc. All of the things we talked about as an industry before getting distracted by ransomware. All of the things that stuff like antivirus and no-local admin rights are designed to protect against.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
No, AV is designed for viruses. Trojans bypass AV by their nature.
My point is that trickery IS what not having local admin rights is all about.
I see, and good point. AV in my experience has prevented soo much Trojans though. So I am not sure what you mean that AV doesn't stop Trojan infected software, because I've seen a lot of live logs where it does.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
Yes, but it's "run in the user space". Everything works that way. Office suites, you name it. Chrome is just a "portable app".
Yeah, I just don't like the idea of portable apps - as an admin, I'd like to prevent them. Because there is no reason in most businesses that a user would need to run a portable app. If you prevent execution from any user rightable space, you can kill so much of this malware.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Software in Win10 doesn't just get admin rights, that requires a very specific set of events or oversights that don't exist in this case. If a random program wants to execute from downloads folder or somewhere similar, it will do so as standard user. So it can't just get admin rights and hide itself.
That "very specific set of events" is just... "the end user clicked the thing that they click constantly because that's what they are trained to do". There is an effective "ok" button and once you are in the mode of clicking that, the "specific set of events" doesn't exist. So once you make end users local admins, it disables that protection in the brains of essentially all end users (and IT pros.)
Yeah I totally get this and is HUGE. I have this noted.
