22

I read this question: Is it common to allow local admin access for developers in organizations?

This question makes me wonder. I can see how local admin access is a danger to the machine. But can a computer with a user account with local admin access actually be a bigger danger to a properly set-up network than a computer that does not have local admin access? If yes, how?

Jens Bannmann
  • 143
  • 8
Belle
  • 325
  • 2
  • 7
  • It depends on what rights that user or machine has on the network.\ – schroeder Jul 23 '18 at 13:50
  • 1
    @schroeder assume no different than a non-admin user, since we are comparing those. – Belle Jul 23 '18 at 13:51
  • 1
    If you haven't seen developers run rogue DHCP servers (as often as not, just by mistake -- for example, meaning to do so only for a VM, but bridging it to the main network in error), you're either lucky, or haven't worked somewhere developers were running subnets with test hardware or otherwise doing adequately interesting things. :) – Charles Duffy Jul 23 '18 at 19:48
  • I've also had developers create non-STP-enabled loops via bad VPN or bridge configuration. – Charles Duffy Jul 23 '18 at 19:50
  • 1
    Your question is a bit mixed up. What do you mean by `be a danger to the a properly set-up network over a computer that does not have local admin access?`. Did you mean: Is there a risk for another computer that the user has no admin access to over a well-setup network? – Tom K. Jul 23 '18 at 19:51
  • 2
    @TomK. Yes, basically to anyone or anything on the network that is not the computer in question. – Belle Jul 23 '18 at 20:11
  • I recall reading about a security incident in which medical records were leaked because one of the office personnel installed file-sharing software on their computer. I think the company went bankrupt as a result. [If I can find a reference to this incident, I'll post it as an answer.] – Harry Johnston Jul 23 '18 at 21:38
  • @HarryJohnston And if he installed this software with user-rights only? The software could still have done everything it did – Falco Jul 26 '18 at 07:07
  • 1
    @Falco, this was some years ago, so probably not. Good point though, nowadays more and more software is designed to install in user space, so denying admin access to the end user is only a start, not all you need to do by any means. – Harry Johnston Jul 26 '18 at 08:19

8 Answers8

27

Local Admin access means that it is easier for the attacker to establish persistent control of the host, to install software and modify system settings, and to take actions like sniffing the network that may allow it to move laterally onto other systems.

So, yes, it is a danger to the network, in that it provides the attacker with more stable access to a more capable platform for lateral movement.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 2
    I have local admin access, as well as persistent control and the ability to install software and modify system settings on my own machine, and yet I do not pose a particular threat to the internet (at least, not the hosts that are properly set up). Could you elaborate on why a LAN would be different in this respect? – Ray Jul 23 '18 at 20:27
  • 6
    @Ray on the Internet, you've got non-local (non-broadcast) connections to a lot of machines with some level of their shields up. On a LAN, the shields are down, peers are trusted, and depending on the network config there may be very juicy bits of data in the broadcast traffic. A 'wolf' in the LAN full of sheep is far more dangerous than on the Internet. – gowenfawr Jul 23 '18 at 20:29
  • 9
    Note that not every LAN is trusted; it is entirely possible to have a [trustless network](https://cloud.google.com/beyondcorp/). That doesn't mean you can just stop worrying about local admin escalations, of course, but it does make them moderately less scary. – Kevin Jul 24 '18 at 00:46
  • 1
    The attacker can already install a lot of software without admin access, modify many user-scoped system settings. Add itself as a background startup programm for the user. Of course local admin gives more local access - but on the other hand a user with local admin has an easier time to wipe his machine. – Falco Jul 26 '18 at 07:14
  • I would not be sure to agree to "more capable" from a network perspective. The attacker can "dig in" on local admin, after he successfully mounted an attack. – Falco Jul 26 '18 at 07:16
  • @Falco the attacker can - but if they don't come in to Admin privileges, the attacker's first step will be to attempt privilege escalation, to get them. So as I said above, "makes it easier" because we're giving away something the attacker would otherwise have to work for. – gowenfawr Jul 26 '18 at 11:29
11

Danger is a bit of a strong word. I would say that local admin access presents additional network risks over non-admin access.

Admin access allows the user to run a packet sniffer in promiscuous mode. That can present additional risks if the network in question is vulnerable to MiTM attacks, or other unencrypted, sensitive information goes across the network.

You have to understand this risk in the context of users normally having physical access to the network. A malicious insider with physical access to the network cable could just simply plug their own device into the network which they have root/admin access too, and sniff packets on and perform the same attacks without root access on their own machine.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • You are assuming local intrusion/attack. Non insider attacks with non-admin level would have to work (scalate privileges) to be able to get promiscous mode network, so imho it is a danger. BTW, I like the carefull with the network cable advice. – bradbury9 Jul 23 '18 at 19:14
7

It is far more danger than most people guess. When we debated how much someone could do from Local Admin (local account, not domain account) on one domain-joined machine, I said "Would you like to find out?" Nobody did. Turned out they wanted to debate the theory but not put it to the test.

I argued on the other question what are you defending against. Well here's the thing. The next time anybody else connects to the machine in question, the local admin can impersonate that user. If it was a network share access, the impersonation can be only used for a few minutes. But a few seconds of domain admin is plenty to create a service on a network share on the domain controller.

In the old days it was stupid worse. The machine can MITM-attack anybody on the network not specifically defended against arp-spoofing. Until recently, this was the end game, but MS finally got their act together and closed SMB against MITM by fixing the auth package and actually making a backwards-incompatible change so that it stays fixed.

But not permitting the developer's VLAN access to the internet is dumb. Perhaps the best thing to do is let them have admin on their machines or VMs but simply not join them to the domain.

Yet this almost never comes up. The threat of being fired and prosecuted keeps the developers from going all-out like this, and for some reason internet-bourne malware doesn't use this stuff. So again, what are you really defending against? The developers probably can take over anyway. You've got to install version updates on production sooner or later.

Joshua
  • 1,090
  • 7
  • 11
  • 1
    Basically, "if the machine is shared it suddenly gets a whole lot worse". – Riking Jul 24 '18 at 18:22
  • Can it be at least partially mitigated by isolating the clients on the switches? So that every PC can exchange traffic only with an uplink port? Of course it still exposes whatever is available (like local servers) to the malicious machine, but at least limits broadcast, ARP and direct (PC-PC) traffic. – filo Jul 25 '18 at 08:57
  • @filo: only if you key your Mac addresses into your switches. But that still doesn't block token stealing. – Joshua Jul 25 '18 at 13:17
  • I think you are mixing up domain admin and local admin. I can impersonate a user with local access to his account already? Local admin does not change anything from an outside perspective – Falco Jul 26 '18 at 07:10
  • 1
    @Falco: I am not. Never underestimate the power of a kernel debugger. Once the domain admin connects at all the thread running as him can be changed to do something else. – Joshua Jul 26 '18 at 13:28
4

Yes, it's dangerous.

In 2014 I had a case which went like this:

  1. Developer with local admin rights takes ownership of utilman.exe, which is an ease-of-access application
  2. Replace utilman.exe by cmd.exe (which is also signed by Microsoft, so a signature check does not reveal it)
  3. Restart the PC and click the accessibility icon

Voilà, you have a console with NT Authority/System rights. You can now spy credentials from critical processes such as LSASS (e.g. using Mimikatz). If you can trick your admin (social engineering) to remotely logon at your PC, you have his credentials.

If you can't, just install a service that runs with System rights as well. You can then undo the hack and simply let the service wait for a longer time to collect credentials for you.

It seems this has not ben fixed in Windows 10.

Thomas Weller
  • 3,246
  • 3
  • 21
  • 39
  • 4
    Note, however, that unless you were using full disk encryption, the attacker didn't need admin rights. They could simply have booted to removable media and replaced `utilman.exe` with `cmd.exe` that way. (Although what really puzzles me about that story is why someone who already had admin took such a round-about route to get to SYSTEM in the first place. There are easier ways!) – Harry Johnston Jul 24 '18 at 23:37
  • @HarryJohnston: ok, which easier ways? – Thomas Weller Jul 25 '18 at 06:59
  • 7
    You can download `psexec` from the Microsoft web site, it has an option for running an arbitrary command in system context. If you want to do it yourself you can install a service. [Another option is the Task Scheduler](https://superuser.com/a/604099/96662). None of these are security vulnerabilities, if you have administrator privilege you're entitled to run code as local system. – Harry Johnston Jul 25 '18 at 07:52
  • Developers are less likely to be familiar with administration and/or security tools like psexec, so it makes sense they'd resort to something like replacing executables. – Angelo Schilling Dec 27 '18 at 00:25
3

Admin access means you can run certain privilege-requiring tools. Packet sniffers are one mentioned by other. Another example is an ARP-spoofer/poisoner for MitM attacks, or an mDNS/NBT-NS impersonator(e.g. Responder). Generally any tool which requires low-level network access, or the ability to open certain protected ports is more likely to require admin access.

Also, being a local admin vs a non-admin means you are going to be able to access certain things on that machine which could allow you to pivot to others, e.g. using mimikatz to dump stored AD passwords, access the full registry on Windows, install keyloggers cross-account(i.e. as a daemon/service), etc.

It's honestly night-and-day having admin access to not; it's the reason things like OSCP focus so heavily on learning privilege escalation, and not just gaining an initial foothold.

Angelo Schilling
  • 681
  • 3
  • 11
0

The answer to your question is "yes." The attacker can very easily convert the machine into a zombie and perform malicious tasks (with full admin rights) on your network.

One of the most difficult attacks to mitigate is the "Insider Attack." In your case, you are allowing an attacker to perform attacks from your internal network with full rights on a zombie (compromised machine).

Michael
  • 2,391
  • 2
  • 19
  • 36
Sayan
  • 2,033
  • 1
  • 11
  • 21
0

Well just an example. Suppose you have a reasonably secure network with a firewall that allow full outgoing http/https access from user desktops, and no other incoming or outgoing access from those machines, and some other protocols for internal servers (DNS, mail, etc.)

A local admin can set up an https proxy from his/her desktop to an external relay and use it to completely bypass the firewall rules. It can even be done for good reasons because it allows to continue to work or test from home. But it just defeats the goal of the corporate firewall...

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
0

It depends what you mean by "properly set up network".

If you configure your network to treat every host on it as potentially evil, most likely compromised, and a possible source of attack, then local admin access is not a danger (that you are not already expecting).

In the real world, any internal network and most data center networks are set up with an assumption of some level of trust, meaning that they are at least more trustworthy than the outside / the Internet.

Local admin challenges that assumption. Note that I said "challenges", not "breaks".

You need to ask yourself how trustworthy your local admins are, both on the scale of intentional action and on the scale of errors and mistakes. That is now your level of trust on the network.

Tom
  • 10,124
  • 18
  • 51