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...
Where Businesses Waste Endpoint Security Budgets
Kelly Sheridan, Staff Editor, Dark Reading,  7/15/2019
US Mayors Commit to Just Saying No to Ransomware
Robert Lemos, Contributing Writer,  7/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Now this is the worst micromanagment I've seen.
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-17210
PUBLISHED: 2019-07-20
An issue was discovered in PrinterOn Central Print Services (CPS) through 4.1.4. The core components that create and launch a print job do not perform complete verification of the session cookie that is supplied to them. As a result, an attacker with guest/pseudo-guest level permissions can bypass t...
CVE-2019-12934
PUBLISHED: 2019-07-20
An issue was discovered in the wp-code-highlightjs plugin through 0.6.2 for WordPress. wp-admin/options-general.php?page=wp-code-highlight-js allows CSRF, as demonstrated by an XSS payload in the hljs_additional_css parameter.
CVE-2019-9229
PUBLISHED: 2019-07-20
An issue was discovered on AudioCodes Mediant 500L-MSBR, 500-MBSR, M800B-MSBR and 800C-MSBR devices with firmware versions F7.20A to F7.20A.251. An internal interface exposed to the link-local address 169.254.254.253 allows attackers in the local network to access multiple quagga VTYs. Attackers can...
CVE-2019-12815
PUBLISHED: 2019-07-19
An arbitrary file copy vulnerability in mod_copy in ProFTPD up to 1.3.5b allows for remote code execution and information disclosure without authentication, a related issue to CVE-2015-3306.
CVE-2019-13569
PUBLISHED: 2019-07-19
A SQL injection vulnerability exists in the Icegram Email Subscribers & Newsletters plugin through 4.1.7 for WordPress. Successful exploitation of this vulnerability would allow a remote attacker to execute arbitrary SQL commands on the affected system.