0

I know this has been asked here before, but I am not satisfied with the answers and don't know if it's ok to revive and hijack an older question.

We have workstations that authenticate users on an LDAP server. However, the local root user can su into any LDAP user without needing a password. From my perspective this sounds like a huge security problem that I would hope could be avoided at the server level.

I can imagine the following scenario where a user can impersonate another and don't know how to prevent it:

  1. UserA has limited permissions, but can log into a company workstation using their LDAP password. They can cat /etc/ldap.conf and figure out the LDAP server's address and can ifconfig to check out their own IP address. (This is just an example of how to get the LDAP address, I don't think that is usually a secret and obscurity is not hard to overcome)
  2. UserA takes out their own personal laptop, configures authentication and network interfaces to match the company workstation and plugs in the network cable from the workstation to their laptop, boots and logs in as local root (it's his laptop, so he has local root)
  3. As root, they su into any other user on LDAP that may or may not have more permissions (without needing a password!), but at the very least, they can impersonate that user without any problem.

The other answers on here say that this is normal UNIX behavior, but it sounds really insecure.

Can the impersonated user act as that user on an NFS mount for example? (the laptop even has the same IP address). I know they won't be able to act as root on a remote machine, but they can still be any other user they want!

There must be a way to prevent this on the LDAP server level right? Or maybe at the NFS server level? Is there some part of the process that I'm missing that actually prevents this?

Thanks!!

  • 1
    This is what Kerberos is for. Authenticating users directly against an LDAP server in, say, an Active Directory environment is a bad idea. – Michael Hampton Mar 01 '14 at 03:45
  • 1
    The situation you suggest, where a host is replaced by a rogue host, is not an OS level issue, but a network layer issue. This is best resolved by your network engineer establishing what would be considered ~normal~ port security provisions that absolutely prevent the host from being replaced by a different host. While there are ways to overcome that, Kerberos is there for the rest of it. – George Spiceland Mar 01 '14 at 05:27
  • Thanks!. I read that Kerberos is useful for authenticating over an insecure network, but using a trusted host, which is not my case. Using network layer security to make sure only authorized hosts can join the network seems like the best solution, I think we will use 802.1X and a RADIUS server using client certificates (EAP-TLS) to make sure only authorized systems can actually go through the network switches. Our managed switches seem able to handle this. Knowing there are only authorized devices on the network, we can assume that our root user on each is trusted and the problem is avoided. – Daniel Gollás Mar 04 '14 at 00:28
  • At least until someone gets root on one of the machines who isn't supposed to have it. Then you're screwed, port security or no. – Michael Hampton Aug 20 '14 at 01:55

1 Answers1

2

I don't think your scenario is valid.

Say an attacker will follow your 1,2,3 points and will become a different UID (user) on their own machine they have brought.

And then what exactly? They have already had access to their own machine as root and using anonymous LDAP as user backend on their own system to su into a user is just as good as:

useradd differentUser
su - differentUser

... without using the LDAP at all.

Because LDAP will only replace a local user storage (eg. /etc/passwd) - see nsswitch.conf and it's manual.

If they want to login to any other machine on your network they will still need to supply valid credentials for a different user.

How is that insecure?

The NFS mount

No. For them to be able to act as that user on a NFS mount they would first have to be able to mount a NFS share from somewhere.

If /etc/exports on a NFS server would freely allow them to mount the NFS share they wouldn't need LDAP, they could just mount it and browse it anyway.

lukash
  • 121
  • 4