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

2/24/2010
04:13 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Fight Malware With Software Restriction Policies

Good news for Department of Defense folks. They can now start using USB flash drives again -- provided there's absolutely no other way to transfer the data from point A to point B. OK, so maybe it isn't time to rejoice just yet.

Good news for Department of Defense folks. They can now start using USB flash drives again -- provided there's absolutely no other way to transfer the data from point A to point B. OK, so maybe it isn't time to rejoice just yet.Strict rules are still in place limiting removable media use to mission-essential operations after meeting stringent compliance requirements. According to an article from Federal Computer Week, "randomly selected users and drives will be subject to periodic auditing under the new policy." The article went on to state that the Army plans to continue the ban for now.

I know I wrote before how I thought this was a knee-jerk reaction similar to the quick ban on social networking sites by Marines. Unfortunately, I don't have an inside look at what really went down, but I'm curious about what steps they took to triage the situation. Did they just cut it off because they didn't have the manpower to deal with the issue? I'm guessing it's the latter because, as one of my readers pointed out, doing so is the easiest and nips it in the bud quickly.

I was doing research a few months ago because I knew of several organizations having a problem with USB flash drive-based malware infections. The solution I came up with used nothing but built-in functionality in Windows that was then configured throughout their networks by pushing out policies via Group Policy. At first, it seemed too brain-dead simple to be a workable solution, but sure enough, Software Restriction Policies (SRPs) worked like a charm.

SRPs are essentially a built-in whitelisting capability included in Windows since XP. The configuration options aren't as powerful and easy to manage as some of the commercial offerings, but it does a good job of keeping malware that spreads via removable devices. It also does a good job of preventing drive-by downloads from running from a user's temporary Internet files folder.

The way the policies work is they prevent executables from running unless they match a cryptographic hash (MD5, SHA1, or SHA-256 depending on the version of Windows), are signed with a specific certificate, are located in a particular path, or are downloaded from a certain network zone.

Microsoft's documentation on SRPs is OK, but I ended up finding an excellent resource that walked through how to configure the policies specifically with the idea of using it to combat malware.

So SRPs keep malware and other executables from running from that don't fit the policy, but they won't keep malicious executables from being copied to approved paths. While that may be a gotcha, some antivirus products, like McAfee VirusScan Enterprise, have Access Protection rules that prevent executables from being copied into commonly SRP-exempted areas, like "C:\Program Files" and "C:\Windows\."

Adding those to things together result in an extremely limited attack surface. Of course, I don't know what the actual DoD environment is like and how easy it would have been to enact SRP quickly, but I would have liked to have been there and given it a shot ... instead of seeing them shoot themselves in the foot.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
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
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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-16219
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. An out-of-bounds read may be exploited by processing specially crafted project files. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16221
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. A stack-based buffer overflow may be exploited by processing a specially crafted project file. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16223
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. A heap-based buffer overflow may be exploited by processing a specially crafted project file. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16225
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. A write-what-where condition may be exploited by processing a specially crafted project file. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16227
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. An improper input validation may be exploited by processing a specially crafted project file not validated when the data is entered by a user. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute a...