blocking .wmf at the perimeter
Written by jlgaddis on December 29, 2005 – 10:00 pm -Due to a new 0-day exploit affecting Microsoft Windows (see CERT advisory), we recently implemented the blocking of .WMF files at our network perimeter. (“Our”, in this case, represents the campus of the educational institution for which I work.)
We did this in two different ways, to address two possible vectors of attack. These two ways are not the only possible vectors of attack, but the two that I deemed most likely to facilitate an infection. We are currently blocking WMF files coming in via e-mail, and also via the web.
On our campus Exchange 2003 Server, we run McAfee GroupShield to scan all e-mail, inbound and outbound. GroupShield has the ability to block files with certain extensions, so we added “.wmf” to the list of filtered extensions.
To block WMF files from the web, I implemented custom access control lists (ACLs) in Squid. Squid is a caching proxy server that we use to cache frequently visited sites, both to decrease the amount of time it takes for a page to load, and also to reduce bandwidth across our WAN links.
Squid has a very flexible mechanism for blocking just about anything you’d like, from file extensions to IP address to domain names (you can even use regular expressions!).
The ACLs that I added to squid.conf were as follows:
acl blockedtypereq reqmimetype -i ^application/x-msmetafile$ acl blockedtypereq reqmimetype -i application/x-msmetafile acl blockedtyperep repmimetype -i ^application/x-msmetafile$ acl blockedtyperep repmimetype -i application/x-msmetafileThen, later on in squid.conf, we must actually tell Squid what to do with these ACLs. We place them above all others in the ACL chain:acl denyext urlregex -i .mp3$ .asx$ .wma$ .wmv$ .avi$ .mpeg$ .mpg$ .qt$ .ram$ .rm$ .iso$ .wav$ .wmf$
httpaccess deny blockedtypereq all httpaccess deny blockedtyperep all httpaccess deny denyextFirst, this tells Squid to deny any traffic which matches the “blockedtypereq” ACL. This ACL (see definition, above) matches any HTTP requests with a MIME type of “application/x-msmetafile”. The second does the same thing, except for HTTP responses from a remote server. The last line denies URLs which match a list of file extensions previously defined.
Once these directives are in place, it’s just a matter of reloading Squid’s configuration file so that it notices the changes. In our case, it’s a Red Hat Enterprise Linux server, so we just use
# service squid reloadWith this, we’ve reloaded Squid’s configuration file and can now test the ACLs. Simply browsing to any URL ending in “.wmf” should trigger the ACL and result in an “Access Denied” error page from Squid.
Tags: internet, linux, microsoft, networking, open-source, security | No Comments »
January 2nd, 2006 at 11:15 am
[...] I wrote an article a few days ago called Blocking .WMF at the Perimeter. In this article, I mentioned how we were blocking .WMF files through the Squid proxy server and McAfee GroupShield on our Microsoft Exchange servers. [...]
January 2nd, 2006 at 1:55 pm
[...] Note that the .dll and .js extensions aren’t blocked for HTTP. That’s because the lovely IIS uses the .dll suffix for its extensions, and you can’t block JavaScript for HTTP either unless you want to break 90% of the Internet for all your local clients. I firmly belive that blocking them for FTP is just fine, tough. Update 20060102 125530: Jeremy Gaddis shares a squid recipe. [...]
January 3rd, 2006 at 10:53 am
Hi,
I have two issues with this:
1) To me, it looks like you need to add the following to block by reply:
reply-access means to check what the server sends back!
httpreplyaccess deny blockedtyperep httpreplyaccess allow all
2) It looks like only your urlregex recipe works. URLs ending with .wmf are blocked fine, whereas the following link (safe demo!) opens up the wmf file: http://www.heise.de/security/dienste/browsercheck/demos/ie/wmfexp2.php Seems like there is a problem with the repmime_type acls.
Any ideas?
Thanks, Sven
January 3rd, 2006 at 6:21 pm
Hi Sven,
Thanks for the feedback, first off.
I tried adding your code from 1) above, but it had the same effect. I was still able to access the URL you listed in 2).
It appears that Squid is actually working as designed in this case, however, because the content-type returned by the server in this case is “binary/octet-stream” (which I can’t really filter out).
Here’s the plain-text dump of the headers from a tcpdump capture:
GET /security/dienste/browsercheck/demos/ie/wmfexp2.php HTTP/1.1 Host: http://www.heise.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Accept: text/xml,application/xml,application/xhtml+xml,
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 200 OK Date: Tue, 03 Jan 2006 23:18:27 GMT Server: Apache/1.3.34 Vary: Accept-Encoding Content-Disposition: inline; filename=”browsercheck.wmf” Content-Length: 15734 Connection: close Content-Type: binary/octet-stream
At this point, I’m not really sure, to be honest, as my Squid-fu isn’t that great. I’m interesting in hearing of any ideas, however.
Thanks!
January 4th, 2006 at 12:52 am
acl blockedcontdisp repheader Content-Disposition -i .wmf httpreplyaccess deny blockedcontdisp httpreply_access allow all
January 4th, 2006 at 3:19 am
Hi Jeremy,
thanks for the reply. Yes, indeed it seems to be the problem that the content header is octect-stream which – yes – we cannot filter out as well as it will block way too much other stuff.
Unless anybody else has some additional ideas how to deal with this, I’m afraid we have no means to block this properly (but my squid-fu is next to nil so to speak
).
Thanks anyway, Sven
January 4th, 2006 at 11:06 am
@Federico – thanks! Unfortunately, my proxies are all 2.5stable5 – looks like I need to upgrade…
Cheers, Sven
January 4th, 2006 at 11:10 am
Similar… I’m at 2.5stable6 and Squid errors out when I add those lines and try to reload its configuration. Unfortunately, that’s the newest version available on my RHEL4 boxes.
Know offhand what version this was introduced in?
Thanks!
January 4th, 2006 at 5:56 pm
Hi there,
For sure 2.5stable10 have it nice.
Alternative may be to use a redirector like squidGuard which did a good job for me.
Cheers Eric
January 5th, 2006 at 3:19 am
Hi All,
@Eric – unfortunately, AFAIK squidGuard also only allows to block what you request (a URL with .wmf in it or so), but not what gets sent back. You can use the link in my first post to check if your squidGuard rule works. If yes, please let me know how you did it.
Cheers, Sven
January 5th, 2006 at 11:08 am
Good basic filtering, but it’s possible to rename a .WMF file with a more innocuous and common extension like .JPG, which this filter probably wouldn’t catch.
Do you know of any easy-to-implement squid filter that lets you perform magic strings checking and blocking?
January 5th, 2006 at 10:29 pm
[...] This just occurred to me while reading A sober New Years update at the Internet Storm Center, since I just recently posting an article about Blocking .WMF at the Perimeter. This is somewhat similar. [...]
February 1st, 2006 at 12:15 am
[...] I’ve no idea what the actual bandwidth usage was, but once a month when I received an invoice/statement from them, each one listed my bandwidth usage as 0%. My “limit” was 200GB, so it must’ve been less than 2GB/mo. January was probably actually different, as I seen a huge increase in traffic over the last month, primarily due to my posts about Blocking WMF at the Perimeter, the Windows WMF Vulnerability, and Monitoring for Sober.Y with Squid and swatch. The final count for January is just over 70,000 hits, I think. [...]