SUDO | IT Security Matters

23 May 2015

Restarting a complex application is a tough task, in particular when many interconnected services have to be restarted in the correct order. A restart becomes a great challenge in a mixed Linux/Windows server environment with dozens of databases, applications and web services.

Some application administrators developed a smart tool to simplify restart jobs. A graphical representation of the application system, with services represented as blocks and dependencies as connections between the blocks, allows the controlled restart of single services as well as the entire application system. Even a restart simulation is possible.

For every service a restart procedure is implemented. If the service receives a restart command, the restart procedure on the respective server is executed. Works perfect, even in a mixed Linux/Windows environment.

I first came across this smart tool during a security assessment of a complex application. On a Windows server I found an SSH service which ran in the context of a globally defined service account. This globally defined service account was member of the local administrator group. For security reasons the local login with this service account was disabled. Really clever!

Unfortunately, each globally defined service account increases the attack surface of your IT system. Once an attacker compromises such an account he gets privileged access to every system where the account is used for administrative tasks. In the worst case, without segmentation in trusted zones, an attacker could get access to all your Windows servers.

How to mitigate this vulnerability? The fast way is to ‘Deny login from the network‘ for this service account in addition to ‘deny login locally’. This will hamper an attacker from exploring your network with a compromised account. If an administrator must configure a service he must sign in with his personal administration account. To change the service he has to enter the service account’s password.

In addition I recommend to question the use of globally defined service accounts in general. As mentioned above such accounts increase the attack surface of your IT system.

With this I recommend: Before you use a globally defined service account for an administrative tasks, ask yourself the question: Can I imagine to do this with a locally defined service account?

If your answer is Yes, and the extra effort is low, you should implement the service with a local account. Make this approach mandatory for all IT staff to keep the attack surface of your IT system sustainably small.

Wishing all a Happy Memorial Day weekend!

19 July 2014

Last week I discussed IT security related topics with the computational biology systems group. It’s hard to believe, but most of the scientist work with Linux, most of the time with a bare bash (Bourne-again shell).

What surprised me was that no scientist works with permanent super user rights. Everyone works with a standard user account, but has the option to switch context with SUDO if necessary. Very impressive!

‘Way of working’ is an essential part of every security strategy. Sometimes large security gains could be achieved with small changes to the way of working, at a fraction of the cost of technology based measures.

With Windows users I have endless discussions about the pros and cons of working with permanent administrative rights. There are good reasons for working this way, but as a result, we create a security hole from the size of a barn door that may compromise all other security measures.

On 26 April 2014 Microsoft informed in ‘Microsoft Security Advisory 2963983’ about a critical vulnerability in Internet explorer. In ‘Security Bulletin MS14-021 – Critical’, published on 1 May 2014, we find some details about the vulnerability and the best reason to end this discussion once and for all:

‘An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.’

Bingo!

Waiving permanent administrative rights must not have serious disadvantages for user productivity. Microsoft implemented a technology similar to SUOD with Windows Vista.

Windows User Account Control (UAC) allows standard users to execute functions where administrative rights are required. If this is the case, UAC prompts for administrative privileges before executing the command.

The solution in just 3 steps:

Communicate the new policy and new way of working to users with local admin rights
Create a local account Useridloc and add account Useridloc to local administrators group
Remove account Userid from the local administrators Group

When UAC requests administrative privileges the user inputs the credentials of Useridloc.

Please note: Since users can re-assign themselves to the local administrators group please audit compliance with the policy.

By the way, if Useridloc is used with runas (the windows command for SUDO), commands could be executed directly with administrative rights.

Welcome back to the comfort zone!

IT Security Matters

Klaus Jochem

Tag Archives: SUDO

The neverending local administrative rights story

Share this:

Like this:

Share this:

Like this: