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 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25159
PUBLISHED: 2020-11-24
499ES EtherNet/IP (ENIP) Adaptor Source Code is vulnerable to a stack-based buffer overflow, which may allow an attacker to send a specially crafted packet that may result in a denial-of-service condition or code execution.
CVE-2020-25654
PUBLISHED: 2020-11-24
An ACL bypass flaw was found in pacemaker before 1.1.24-rc1 and 2.0.5-rc2. An attacker having a local account on the cluster and in the haclient group could use IPC communication with various daemons directly to perform certain tasks that they would be prevented by ACLs from doing if they went throu...
CVE-2020-28329
PUBLISHED: 2020-11-24
Barco wePresent WiPG-1600W firmware includes a hardcoded API account and password that is discoverable by inspecting the firmware image. A malicious actor could use this password to access authenticated, administrative functions in the API. Affected Version(s): 2.5.1.8, 2.5.0.25, 2.5.0.24, 2.4.1.19.
CVE-2020-29053
PUBLISHED: 2020-11-24
HRSALE 2.0.0 allows XSS via the admin/project/projects_calendar set_date parameter.
CVE-2020-25640
PUBLISHED: 2020-11-24
A flaw was discovered in WildFly before 21.0.0.Final where, Resource adapter logs plain text JMS password at warning level on connection error, inserting sensitive information in the log file.