[IE9/IE10] Malware Domains Tracking Protection List

It seems there's a Malware Domains TPL for IE. This is the same list that exists for ABP.

There doesn't seem to exist a link from the official -http://malwaredomains.com URL, so in order to use it, you should create an html file with a text editor, such as Notepad.

This is the code you should copy and paste:

Code:

<a href="javascript:window.external.msAddTrackingProtectionList('http://easylist-msie.adblockplus.org/malwaredomains_full.tpl', 'Malware Domains Tracking Protection List')">Add Malware Domains Tracking Protection List</a>

Save it as MalwareDomainsTPL.html, for example. Then you should copy the file location to Internet Explorer address bar. To do it, just press SHIFT + mouse right-click > Copy as path. Remove any quotation marks and press enter. You should then be able to add this TPL to IE9/10.

I hope this is useful to someone.

 

Considering IE's SmartScreen, I wonder how useful this really is.

 

I doubt SmartScreen is able to spot everything. Maybe it spots everything that's on Malware Domains list. Maybe it doesn't.

Anything that can help keep average jane and joe safer is always welcome.

Anyway, and this is not recent info, but I recall creating a thread a while back where I mentioned an article by Zscaler where they tested web browsers built-in URL protection such as SmartScreen and Google Safebrowsing against known URL/domain blacklists, such as this one, and I was surprised to see that while there was some overlap, these lists also protected against more URLs/domains.

 

AFAIK, TPLs are privacy friendly in the sense that one can use them without having the URLs they visit, filter hit statistics, etc phoned home to anyone. Whereas SmartScreen does, at least according to Microsoft, phone home URL information, usage information, etc. Making it, I think it fair to say, privacy UNfriendly.

I do have a concern about this Malware Domains TPL approach, which boils down to questions about how the TPL rules are applied. I think one would want a "Malware Domain" to be blocked under all circumstances including but not limited to:

1) Any type of content from the malware domain is included as third-party content on some other site
2) Someone clicks on a link, or manually enters the URL, to something at the malware domain
3) Any request, for anything, gets redirected to the malware domain

Is TPL domain blocking utterly thorough?

 

The way TPLs work is that they will block third-party communications. Obviously, this means that if the user manually enters the URL, then the list can't do anything and hopefully this is where SmartScreen comes in, if it's able to stop access to it.

The entries don't make a distinction of the content types (if that's what you meant?), it simply has -d domainname. The domain and subdomains are blocked, as long as we're dealing with a third-party connection to domainname.

So, if, let's say, we access www.wilderssecurity.com and there's a connection for baddomain, and the TPL has the entry in it for baddomain, then the connection is blocked, because that would be a third-party connection.

I hope I still recall how TPLs work...

 

That's what I figured, and I think such a TPL would also fail to protect you if you click on a link to that URL. For example, the EasyPrivacy TPL has this rule:

-d hit-counts.com

and an arbitrary search for a site that uses that counter turned up -http://www.hudsonsribsandfish.com/

If I load the later with IE10, the hit counter image is blocked, but there remains a link to -www.hit-counts.com and if I click on that link IE10 will load the page.

Were we talking about the Malware Domains TPL and a site that is on that list, we'd surely want requests to be blocked even if they were triggered by the user clicking on a link or manually entering one. We'd especially want any/all URLs to exes, etc to be blocked.

So in practice, IE TPLs appear to have a flaw similar to ABP subscriptions. Namely, given how the rules are defined/applied you can't actually block all requests to a domain. Although that doesn't render them useless, it does reduce their usefulness and create situations that a user must be aware of. Frankly, they both should be fixed to allow for more thorough domain blocking.

Are there any IE addons that do domain blocking well? If so and one can get the Malware Domains list into such an addon, more complete protection could be had.

 

I just thought of something else. We know SmartScreen checks the URLs that people explicitly navigate to (top level). Do we know what SmartScreen does WRT sub requests and especially third-party URLs? Since there are many secondary requests for one top-level document, the volume of URLs that could be checked increases dramatically. So I'm inclined to assume it doesn't perform full URL checks on all secondary requests. Does it perform a hostname level check on all third-party secondary requests? The TPL approach effectively would.

 

I'm afraid that's a limitation of TPLs. But, it's also great to have this kind of TPL (protecting against malicious domains) in case of an ad that is whitelisted in another TPL, otherwise the website won't work properly. This way, if the ad network is hijacked, then if the TPL is able to block that connection, then the drive-by download won't happen.

While not perfect, better than nothing.

The only addons I'm aware that should block, or at least not allow damage, would be Spybot and SpywareBlaster? I'm not familiar with any other.

A better solution would be to use a hosts file/another method that allows wildcards, such as Acrylic DNS/other. There's no hosts file version of Malware Domains list, though. And, converting the current list to hosts format wouldn't block subdomains, so better to have it in TPL format. Or, convert to *.domainame and have something like Acrylic DNS, of course. But, such TPL(s) suit better the average Joe and Jane.

Anyway, I did a small test of my own, which is not an accurate test ( far from it), because I don't understand much of how html/etc code works (the coding itself), but I saved -http://www.softpedia.com HTML code with Internet Explorer Developer Tools, and then I edited the HTML file and modified an AD link to point to an *.EXE file, and then I blocked the EXE file domain name in the TPL file. Then, I monitored network connections with the Developer Tools and I noticed that the connection was Pending... usually it should show Aborted. I have IE10 set not to allow file downloads, and I got no prompts saying the file download was denied. But, as soon as I remove the entry from the TPL, and restart the process, I do get a warning from IE that a file download failed.

So, there's some benefit. (Again, this was most likely a flawed test, but I just wanted to see what could happen.)

 

Your little experiment there is interesting to me because it sounds as though you saw a TPL rule affect the loading of external content from a local html file. I actually tried to test something recently using a local html file like:

Code:

<!DOCTYPE html>
<!-- saved from url=(0014)about:internet -->
<html>
  <head>
    <meta charset="utf-8">
    <title>EasyPrivacy TPL Test</title>
  </head>
  <body>
    <p>Below here is an img loaded from http://www.hit-counts.com/images/wwwimage.jpg<p>
    <img src="http://www.hit-counts.com/images/wwwimage.jpg" alt="An image" />
  </body>
</html>

There is a "-d hit-counts.com" rule in the EasyPrivacy TPL so that image shouldn't load. However, when I loaded it using IE10 (EasyPrivacy TPL is installed) on a Win7/64 machine the image *was* loaded. I then uploaded the same html page to a webserver and loaded it from there. The image wasn't loaded. IOW, on my system it appears TPL rules aren't being (properly) applied when the html page is local.

Furthermore, at some point I tried using IE10's File->SaveAs feature to save the remote page to a local file (type Webpage, complete). I noticed that the image file was retrieved and saved despite it normally being blocked by the TPL rule. IOW, on my system it appears that the TPL is bypassed if/when you preform this type of saving.

Do you have the EasyPrivacy TPL installed? If so, I'd be interested to know if your IE10 (desktop version if on Win8 ) behaves the same way when you attempt to load the above as a local html file. If you are interested in testing the save as behavior you can try saving -http://www.hudsonsribsandfish.com/ and see if counter.gif shows up as a local file.

Perhaps IE10 on Win7/64 has some unique quirks?

Edit: Since directing someone to specific sites could be an attempt at mischief... feel free to make some URL substitutions if you are willing to check this out but don't want to go where I mentioned. As long as the same thing is tested that would help zero in on whether there is some issue here that isn't specific to my system.

 

I didn't use those links, because I also use a hosts file to block ads/trackers and I didn't want either to disable or remove the entry, so I tried with another img source.

The result I got is that the image is allowed to load. But, as you mentioned, I believe this has to do with the fact that's a local html file (C:\etc\etc\test.html as shown in the address bar). Maybe the best way to test it would either to temporarily run a local web server, so that the page is displayed as -http://localhost/etc, or maybe set up some page at Dropbox, as it does allow to host a smallish website I think?

 

Thanks for the test/feedback m00nbl00d. I previously put the same html page up on a remote Internet server and IE10 did block the image when the page was loaded from there. I'm assuming that duplicated your Dropbox idea.

I liked your "try a local webserver" idea and gave it a go. IE10 did block the TPL'd image when the page was retrieved via:

-http://localhost:7777/test.html
-http://127.0.0.1:7777/test.html
-http://ComputerName:7777/test.html
-http://10.x.x.x:7777/test.html

For fun I tried changing the MOTW in that page to:

<!-- saved from url=(0024)http://example.iana.org/ -->

and tried reloading the page as a local file. Thinking that IE10 might make use of the hostname from the MOTW for third-party comparison purposes. That idea didn't work; IE10 did NOT block the image. After this I tried loading it via local webserver once more and noticed that the image appeared. IOW, that TPL rule didn't prevent the image from being displayed when the image had been previously requested and locally cached.

I also took a quick look at redirects, where the img src URL was to the same non-TPL'd host as the html page was loaded from, but said host redirected the request for that image to a TPL'd host. My IE10 blocked the image load.

So based on my limited testing, the TPL rule bypass scenarios appear to be/include:

1) Explicit navigation (clicking on a link or entering URL via address bar)
2) Third-party content loaded via a local filesystem webpage (file://)
3) Third-party content in a webpage saved via File->Save As
4) Third-party content having been previously requested and cached

Those with more knowledge of IE and TPL application would be a more definitive source of info. Someone should have a full test suite up and have tested things far more thoroughly.

 

Nice test.

-edit-

By the way, do you still happen to have the local web server installed? If you do, I was wondering if you could test whether or not it would be possible to have local TPL files loaded into IE? I was going to test it out, after picking some local web server software, but now that you already have it...

It would be a great way of having other lists converted to the TPL format, without having to host them online, due to legal issues and all that stuff. If used privately, I don't think there would be any issue, as it would be for personal use.

 

Basic testing of installing, updating, and using a TPL file @ [noparse]http://localhost:7777/MyTPL.tpl[/noparse] passed with IE10/Win7-64. Since the HTTP server need only serve basic content (install page and tpl), a very simple portable app type HTTP server that is auto started would suffice.

FWIW, I did also try the no server approach... loading the install page via local file URL and calling window.external.msAddTrackingProtectionList with several variants of local file URLs. My brief attempts to get that approach working weren't successful. Conceptually there might be a way to create, or modify, related TPL registry items and TPL store file and effectively eliminate the need for a local server. I'll leave such investigations to others.