BeyondTrust

Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

The Law Of Unintended Consequences

Posted December 21, 2011    Peter McCalister

It’s been a long while since I’ve logged into a UNIX box at the console or via telnet. But back when I was first learning my way around UNIX in the late 80’s and early 90’s, I vividly remember the nearly universal greeting when logging in as root:

————————————–
login: root
password:

Don’t login as root, use su.
#
—————————————

That short bit of advice whenever I logged in as root stuck with me. I didn’t always obey it, and usually I ignored it at my own peril. I remember many times when I really wish I hadn’t been root when installing random software or just going about my business, and the law of unintended consequences reared its ugly head.

When I began using Windows NT in earnest, and then Windows 95, I noticed immediately that this simple principle simply seemed to be missing. It was always assumed that if it was your machine or server, that you would naturally have administrative rights at all times. Chaos ensued, and I often found myself rebuilding machines from scratch to recover from a relatively simple mistake committed with admin rights. I rapidly recalled those earlier admonishments to use ‘su’ rather than the root account, and always remembered to create standard user accounts for day to day use. This was really hard in the “old days” of Windows, and some might say it’s still a pain in the butt today, though it’s become much, much easier with the advent of things like User Account Control in Vista and Windows 7.

In those days (and, honestly, still today) I also suffered from a problem that many in the IT world will recognize: that I was the personal IT support department of my family, particularly my dad. Sure, I tried to get him to log in as a standard user early on, in the interest of saving myself some headaches, but of course it didn’t stick. I can remember on numerous occasions being summoned to deal with a virus or some other kind of malware that had embedded itself so deeply in the system that even specialized tools were unable to remove it. Oh, if he had only been a standard user it never would have required the multiple reformat and rebuilds that it did. Yeah, you remember.

And so we arrive at today.. Microsoft has finally caught up with the decades-old UNIX capability of ‘sudo’ that is essentially what UAC provides. So life is better, right? Now actions performed as administrator can be logged and patrolled to some degree, but of course some issues have remained. With ‘su’ you could grant very specific capabilities, such as the ability to run a single application or command as root, without handing over the keys to the castle. UAC still makes this tricky, since unlike ‘sudo’ it doesn’t ask for your user credentials to elevate an application or command, but instead asks for admin credentials. So now we’re almost back to square one–where ‘su’ allows you to empower regular users to do specific things, UAC is virtually an all-or-nothing proposition. This may work fairly well in the home market, but it certainly flops big time in a corporate setting.

The bottom line here should be obvious, we here at BeyondTrust make really cool software that allows you to control admin privileges via network policy at a very granular level, and we can solve a huge swath of these problems in a corporate setting. But being new here (this is my third week), I thought I’d kick off the blogging by talking a little bit about my personal history with avoiding root and admin privileges for my day to day work, and why it has always been important advice, both in how I’ve worked and in the advice I’ve given to others. Thanks for reading!

Leave a Reply

Additional articles

How To Implement The Australian Signals Directorate’s Top 4 Strategies

Posted October 20, 2014    Morey Haber

The Australian Signals Directorate (ASD), also known as the Defence Signals Directorate, has developed a list of strategies to mitigate targeted cyber intrusions. The recommended strategies were developed through ASD’s extensive experience in operational cyber security, including responding to serious security intrusions and performing vulnerability assessments and penetration testing for Australian government agencies. These recommendations…

Tags:
, , , ,
asp-mvc

Exploiting MS14-059 because sometimes XSS is fun, sometimes…

Posted October 17, 2014    BeyondTrust Research Team

This October, Microsoft has provided a security update for System.Web.Mvc.dll which addresses a ‘Security Feature Bypass’. The vulnerability itself is in ASP.NET MVC technology and given its wide adoption we thought we would take a closer look. Referring to the bulletin we can glean a few useful pieces of information: “A cross-site scripting (XSS) vulnerability exists…

Tags:
4bestpracticesaudits-blog

Four Best Practices for Passing Privileged Account Audits

Posted October 16, 2014    Chris Burd

Like most IT organizations, your team may periodically face the “dreaded” task of being audited. Your process for delegating privileged access to desktops, servers, and infrastructure devices is a massive target for the auditor’s microscope. An audit’s findings can have significant implications on technology and business strategy, so it’s critical to make sure you’re prepared…

Tags:
, , , ,