Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

3/13/2013
11:33 AM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Defending Local Admin Against Physical Attacks

Physical access usually spells game over, but protections can be put in place to help defend against local boot attacks

In my previous blog entry, I wrote about some of the issues with having a shared password for the local administrator account on Windows desktops. This is a common problem that we encounter during penetration tests, and one that often leads to easy lateral movement throughout the organization and privilege escalation up to a domain administrator account.

Specifically, I discussed two protection measures to help protect local administrator accounts while a workstation is booted. First, do not allow users to be administrators on their desktops. Second, create unique passwords for each local administrator account. It's not hard to understand the benefits of the first recommendation, but how does having unique local administrator passwords hold up to physical attacks against a local machine?

It's an interesting question because, as we all know, if you have physical access to a computer, then you own it. However, in this situation, you would still only own that one workstation because that local administrator password is not used anywhere else. It prevents quick movement to other hosts, however, that one foothold may be all that's needed to pivot, attack, and escalate.

Without Autorun disabled and a non-admin logged in, a patient attacker would need to reboot the workstation, install malware, and wait for a privileged domain account to log in so he could impersonate the account and move to other systems. Or, as we did in a penetration test last week, he could leverage the unprivileged account to scour the network file shares to find passwords that eventually lead to root access of all Linux servers ... but that's for another post.

So how do we protect those systems from physical attacks? The usual approach is to disable the ability for the computer to boot from alternative media, such as a CD/DVD drive or USB flash drive. Traditionally, a password for the BIOS will prevent an attacker from being able to change the boot sequence from the hard drive to an alternate device, like a USB flash drive or optical media. While this approach generally still holds true, it is not foolproof since a lot of today's desktops and laptops support PXE network booting prior to booting the hard drive.

PXE boot support? Who cares, right? You should. Instead of walking over to a target machine, sticking in a DVD or USB flash drive, rebooting it, and stealing the local password hashes or planting a Trojan, PXE boot attacks allow an attacker to do essentially the same thing without ever physically touching the target workstation. Support for PXE boot attacks were added to Metasploit a couple of years ago with pxesploit. For more details about pxesploit, check out this blog entry I wrote when it was first released at DefCon in 2011.

If you aren't using PXE booting for rapidly deploying systems, then disable it on all of your systems in addition to locking down the BIOS. Or enable it only during the time you're doing the deployment, and then immediately disable it.

The last protection I want to mention is full disk encryption. Even with BIOS protections, a determined attacker could remove the drive, plant malware or steal password hashes, and put the drive back in. Full disk encryption would prevent this and provides protection against data loss and exposure if the system were lost or stolen. A silver bullet? No, of course not, but it's another layer in a layered approach to protecting endpoints.

There are also physical security protections, but that's beyond today's scope. No need for unnecessary scope-creep, right?

That's it for now. On Friday, I will be posting the final blog entry about this topic and will be covering tools to help with keeping all those local Windows administrator accounts unique. For any questions or comment, please leave a comment below or send me a message via email or Twitter.

John Sawyer is a Senior Security Analyst with InGuardians, Inc. The views and opinions expressed in this blog are his own and do not represent those of his employer. He can be reached at [email protected] and found on Twitter @johnhsawyer.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MROBINSON000
50%
50%
MROBINSON000,
User Rank: Apprentice
3/19/2013 | 11:18:09 AM
re: Defending Local Admin Against Physical Attacks
The Executive Order recently signed by President Obama was aimed to improve the security of America's critical infrastructure, defined as physical or virtual assets and systems the destruction of which would have a debilitating impact on security, national economic security, public health or safety. To read about protecting against physical attacks I recommend reading the following article: http://blog.securityinnovation...
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24213
PUBLISHED: 2020-09-23
An integer overflow was discovered in YGOPro ygocore v13.51. Attackers can use it to leak the game server thread's memory.
CVE-2020-2279
PUBLISHED: 2020-09-23
A sandbox bypass vulnerability in Jenkins Script Security Plugin 1.74 and earlier allows attackers with permission to define sandboxed scripts to provide crafted return values or script binding content that can result in arbitrary code execution on the Jenkins controller JVM.
CVE-2020-2280
PUBLISHED: 2020-09-23
A cross-site request forgery (CSRF) vulnerability in Jenkins Warnings Plugin 5.0.1 and earlier allows attackers to execute arbitrary code.
CVE-2020-2281
PUBLISHED: 2020-09-23
A cross-site request forgery (CSRF) vulnerability in Jenkins Lockable Resources Plugin 2.8 and earlier allows attackers to reserve, unreserve, unlock, and reset resources.
CVE-2020-2282
PUBLISHED: 2020-09-23
Jenkins Implied Labels Plugin 0.6 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to configure the plugin.