*** Be Careful With Your Blocking Rules ***

An alert reader mentioned the importance of carefully constructing filters for evil sites. From a previous diary, he saw some evil IP addresses that he wanted to block access to for his users. He noticed that all of the evil IP addrs were in the same /16 range, so he just applied a filter for the entire range. Ooops! Turns out that a legitimate large auction site, which will remain nameless for the purposes of this discussion, was also in that range. His users complained when they couldn't access their auctions to sell pez dispensers and such. Moral of the story, "Sometimes good folks reside in bad neighborhoods." In other words, be careful what you filter.



*** Anti-Spyware Solutions based on Infrastructure ***

Today, we solicited ideas for tweaking infrastructure components to thwart the menace of spyware. I'm not talking about the latest anti-spyware products... darned near every vendor has released a specific behavior- or signature-based anti-spyware solution. Instead, we're interested in hearing other non-product-specific solutions. For example, we asked if you have tricked out your web proxy to detect or even stop spyware? How? Have you diddled with your Windows file system perms to stop spyware while still having a usable machine? Have you stumbled upon the ideal Active Directory settings to stop the spyware slaughter? Please don't send solutions like, "I just use this anti-spyware product, and boy am I thrilled." Also, don't send us an answer like, "I use Mac OS X... What's all this spyware fuss about?" or the Mike-Poor-like solution, "First, insert a FreeBSD CD into your drive..." We're interested in infrastructure-related solutions for Windows machines, where the spyware threat is the biggest.



I've summarized and lightly consolidated the responses we got below. We're pretty fully loaded on the issue, so no further input on it for now, please.




*** UPDATE ***



Man, I love Storm Center readers. Within the first hour, we got some really good ideas for spyware prevention and detection, infrastructure-style. Here's a summary of the best stuff so far:



1) James uses a squid proxy for all of his outbound surfers. Then, he runs an anti-virus tool with spyware sigs on the squid cache to catch a whole bunch of nasties on their way in, including a bunch of downloader trojans and redirection exploits. Now, he enforces the proxy settings in the browser using AD for all of his IE users.



2) Mike Larson goes further, trying to move all users to Firefox. He changed the default home page for IE to a warning of the dangers of using it, along with an icon to download Firefox. For those corporate apps that really require IE, he created a custom shortcut that opens IE. Also, to help make sure things stay this way, he config'ed IE to NOT check that it is the default browser.



3) Mike Larson goes still further by setting up his folks as "restricted users". To help make that happen, another reader (who wanted to be anonymous) offers some good ideas:

a) Make sure all users have all of the network printers in their vacinity already installed. Otherwise, they'll complain that they need local admin so they can print to some new-fangled printer in their cubicle.

b) Make sure Flash, ShockWave, and other common or popular required plug-ins are already installed.

c) Make sure the Help Desk has some type of remote desktop capability. This will surely help with the printer issue (a) above, which I've seen burn a bunch of orgs.

d) Don't take the easy way out for older apps by just giving people Power Users or local Admin privs. Instead, run cacls.exe and see what is really required. It's better to do this work proactively rather than reactively responding to a bunch of spyware.



4) Aaron Hanson cites the usefulness of a DNS blackhole for common spyware domain names. You can resolve requests for some of the worst offenders to a website of your own hosting a little 1x1 gif file, or some indication to your users about how much you love them (I added that twist, not Aaron). For more info on this stellar idea, check out http://www.bleedingsnort.com/forum/viewtopic.php?forum=11&showtopic=98 , where Aaron and a bunch of other folks dialogue about how to make this manageable.



**NEW: David Glosser sent a nice follow-up stressing how carefully the "Black Hole DNS Spyware Project" is to only include domains actually associated with spwyare and malware. They don't want to include ad servers in the list, since sometimes they aren't appropriate to block. What's more, updates to this blackhole list are at http://www.bleedingsnort.com/forum/viewtopic.php?forum=11&showtopic=774 . Thanks a lot, guys!



5) Steve McDougald mentioned his use of the open source tools like nmap, grep, and perl to locate systems on the network. Then, he uses pslist to see if any known spyware processes are running on the boxes. If so, he uses pskill to terminate them. He's even got a MySQL database to keep a list of discovered machines, and actions his scripts have taken on them.




*** UPDATE UPDATE ***



A couple of more interesting ideas have come up:



6) Matt Jonkman points out that much spyware has its own user-agent type for HTTP, or modifies the existing user-agent type of IE. That's a great point. He directed us to the bleeding-snort work in creating a list of user-agent types associated with spyware specimens, suitable for filtering at proxies or creating IDS sigs for. Check out http://www.bleedingsnort.com/article.php?story=20050303190103553 . I've heard of the user-agent concept before, but wasn't aware of the good work that's going on with it at bleeding snort by Chris Taylor and Matt Jonkman. Good stuff, gents!



7) Another anonymous reader mentioned his plan to have all of his users run Firefox as their default browser, configured to use one gateway going out. Then, if a user has a specific business need for IE (such as updating Windows or running a specific app), he directs all installed IE browsers to another, separate gateway. On this gateway, he severely limits outbound traffic to a known whitelist of sites with a defined business need. In essence, he's bifurcating his network, into a rather open Firefox arena, along with a carefully guarded IE fortress.




*** BUT WAIT, THERE'S MORE ***



A few other nifty ideas have come in.



8) An anonymous reader tells us of the success he's had with his commercial IPS tool in blocking spyware. It's got, according to him, "Filters for herds of spyware.. and so far ZERO blocks of legit traffic." Nice use of IPS technology.



9) Speaking of IPS (and IDS) stuff, Matt Jonkman also alerts us to the Bleeding Snort's Bleeding Malware ruleset, over at http://www.bleedingsnort.com/bleeding-malware.rules . So, in the end, the Bleeding Snort guys have a three-pronged approach: The DNS Blackhole (mentioned in point number 4 above), the User-Agent blocking (in point number 6), and the Bleeding Malware ruleset (mentioned here in point number 9).



10) A related approach to the DNS issue is to create a hosts file on each system that sends requests for spyware to some place else. Both Ramu and an anonymous reader have suggested this, a solid approach if you can push hosts files updates to your end systems. The anonymous gent points out the hosts list at www.someonewhocares.org/hosts , which is conveniently named, "how to make the internet not suck (as much)". What a great name that would be for a book! You should look at the list, which gets rid of all kinds of nasty items by redirecting name lookups to 127.0.0.1, including various malware, spyware, and other evil stuff.



**NEW: Paul Daniels mentioned that some spyware attacks the hosts file, fixing 127.0.0.1 settings so the spyware can resolve back to its owners. That's why this approach is best used in conjunction with a DNS blackhole and other items in this list.



11) Not all issues are technical ones, of course. Thus, Richard mentions the usefulness of having a good policy restricting personal Internet usage. Policy is a great place to start, but only when backed up by enforcement (see items 1-10 above) and education.



12) Which brings us to the next point, from Charles Hamby. He's got a user training program to tell them about spyware and how to avoid it.



13) Charles also uses a custom startup script to look for the most common spyware files and folders, as well as P2P apps. He runs it domain-wide.



14) Another approach mentioned by Richard (the gent from item number 11, in case you are keeping score) is about disk imaging. That is, tell all users to keep their personal files on a server, and reset all of their operating systems every night. I've seen this done in a few very very large organizations, with great results. Sure, users moan about losing their custom wall-paper with their children and favorite sports teams on them, but they get used to it pretty quickly. You could even give them a single folder to store their stuff locally, if you are being generous. But, set a backup tool to blow away everything else at the end of the day.


**NEW: An alert reader has pointed out the importance of using an image that is clean, with cleared caches, temporary files, and such. That's a great point. I've seen some people (whom I won't name) who have used images with some unfortunate left over stuff in it. Build specific images to be restored from; don't use some existing system that you think is "clean enough".



15) Another anonymous dude who has some very standardized systems has written a perl script that merely counts the number of reg keys defined under
HKLM/software/microsoft/windows/currentversion/explorer/browser help objects
HKCU/software/microsoft/windows/currentversion/run
and HKLM/software/microsoft/windows/currentversion/run.
If the number of keys under there exceeds a threshold he's defined, he investigates.

**NEW: Turns out the Bleeding Snort guys have a perl script that does similar scanning of a Windows domain for Browser Helper Objects, available at http://www.bleedingsnort.com/filemgmt/singlefile.php?lid=7 . I tell ya, is there nothing these Bleeding Snort guys don't do. They're into everything, and we're all grateful for it. But, according to David Glosser, who tipped me off to that perl script project, they are looking for beta testers for this concept. Stand up and volunteer!



*** A FINAL BATCH OF IDEAS FOR NOW ***



Here are a final couple of ideas... some really really good ones.



16) Instead of monitoring user-agents looking for specific changes to known bad stuff (a la item number 6 above), Mike Pomraning had a great plan. He records a list of user-agents and client IP addresses (he does this using a custom passive user-agent header recorder, written with pynids, a python wrapper around libnids on top of libpcap). In fact, Mike is the author of pynids! Then, check this out... you are paying attention, right?!? He then logs all unique pairings of user-agent and IP addresses when they are first seen. He can then spot strange new user-agents quite easily, getting a list of systems with probable spyware (or other weird stuff like unusual media players, new anti-virus updaters, etc.) on a regular basis. You could implement a similar strategy with a web proxy like squid, to create a highly useful variation to item number 6 above. Mike points out that he wrote pynids for this very reason.



17) An anonymous reader mentions that he has set a GPO to hide IE from all of his users, forcing them to run Firefox instead. Consider the irony of that, my friends. Consider this an interesting variation to number 2 above.



18) Many people have mentioned their use of GPO to insert known evil sites into the Restricted Sites zone of IE. That's what this zone is all about, and such a solution is very reasonable.



19) And last, but not least, another anonymous reader uses Active Directory's software restriction policy to define specific MD5 hashes and paths for various forms of malware. You can read about this AD option for WinXP and 2003 at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx .





Feel free to use these ideas from these awesome folks.




I want to thank everyone for their really solid input today on using infrastructure components to thwart spyware. I felt like I was in a brainstorming session with 20,000 of my closest friends. Your ideas and enthusiasm are certainly appreciated. The more we can spread this info among the good guys, the better off we'll all be. Thanks again to everyone who submitted input. I tried to respond to all of you, but missed a couple. I'll finish up those responses later tonight and tomorrow morning.




That's all for now...



--Ed Skoudis


Sr. Security Consultant and Co-Founder


Intelguardians


ed (at) intelguardians.com