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.

 

Recommended Reading:

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 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
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
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15820
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
CVE-2020-15821
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
CVE-2020-15823
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
CVE-2020-15824
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
CVE-2020-15825
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.