SecureMecca HostsFile Change lists

[hhhobbit]

The change lists for the hosts file is here (also, the 2009-11 change list have bee moved to this folder):

http://www.SecureMecca.com/public/Changes4Hosts/
http://www.SecureMecca.com/public/Changes4Hosts/2009-12-05.7z
http://www.SecureMecca.com/public/Changes4Hosts/2009-12-05.7z.sig
http://www.SecureMecca.com/public/Changes4Hosts/2009-12-05.zip
http://www.SecureMecca.com/public/Changes4Hosts/2009-12-05.zip.sig

I am going to start adding MalwareDomainList's hosts back into the file for the following 3 reasons:

1. add.WinRisk has become add.Risk to reflect the growing threat to iPhone users.  It is also now included in the hosts.lnx file.  Perhaps a quote is in order to illustrate why this is being done:

"There is no magic fairy dust protecting Macs" - Dai Zovi, security researcher and co-author of The Mac Hacker's Handbook.

I should hastily add the same goes for Linux and other Unix or Unix-like systems.  But the main reason is that the iPhone worm that takes advantage of jail-broken iPhones is just the first salvo against not just iPhones but all Macintosh systems.  For those that don't know it, the iPhone OS is nothing more than a stripped down Mac OS-X operating system.  Once people learn how to work in a certain environment they are off and running.  I can conclude that it is just going expand.  After all, many Mac owners are these rich people with huge bank accounts and almost no knowledge of how to protect themselves.  What a tempting, tasty, juicy target.

All of MDL's hosts are going into this file where I can contain the volatility.  That doesn't mean that everything in add.Risk comes from MDL.  I have my own stuff going in there too.  The one thing that marks these hosts though is their volatility.  They come and go like mad.  But having them separate means I can search for patterns.

2.  I have added an add.Spam section as well.  These hosts have about the same volatility as the hosts in add.Risk.  They are usually gone within two months.  For now, I use only what I get in my own email box.

3. By having these separate from the more stable ad pushers and trackers I can more easily prune things but even more importantly search for patterns that will stop a bad host without me even knowing its name.  I have done a great deal of work here with the patterns provided by Dr Gary Warner at the University of Alabama, Birmingham campus:

http://garwarner.blogspot.com/

I will post agin in about a month.  I think the revmove list section I started should be deleted.

I am giving the reason most of the hosts that were considered for removal were retained in the Kept.txt file.  Mostly it is porn but for most of them I still don't like those obfuscated JavaScripts.  They may lead to nothing malevolent right now, but what is there to prevent that from happening in the future?

[hhhobbit]

Finally!  A way to prune off useless TK domain blocks.

I will have an new update tomorrow 2012-02-15 here:

http://securemecca.com/public/Changes4Hosts/2012-02-15.7z
http://securemecca.com/public/Changes4Hosts/2012-02-15.7z.sig

There is a file in it that shows how to test the bad TK domain host
URLs for whether they are still bad.  But I also put it here:

http://www.securemecca.com/Analysis/TK-Host-Test.txt

The Analysis folder is not open via the home page, but
everybody knows where the Analysis folder is at and what
is in it. There is nothing wrong with others knowing about it.

It really does answer how to test the TK domain hosts.  But
with all of the stuff in the way like the following in the way
with Windows:

1. ISP - (Comcast Anti-Bot service)
2. Browser protection (and did you really turn it all off?)
3. AV protection - Kaspersky blocked the URLs I tested).
4. Internal Microsoft protection?

There is no guarantee that a block some place is not
skewing the tests.  I think I have pretty well moved the
ISP out of the way (at least for these), and the others are
not even a problem on Linux.  Even so I also did tests on
Windows and proved to my satisfaction the TK domain
wasn't doing OS detection and routing Windows people
one way and everybody else another way.  We all go the
same way.

After all, the TK domain people don't want malware through
their redirection service either.  They just want some money
for URLs that look like a domain when in fact they go to
something rather long some place else.

So you really need to run the script on Linux / Unix.  No
C programs need to be written.  You will want some
folder like the following:

drwxrwxrwt 10 root     root      4096 2012-02-12 09:50 /home/tmp

I think it is all self explanatory.  That does not mean that the
URLs stuffed into the BadTKs.txt are all bad.  But we do have two
ways of finding the ones that are okay with just two simple grep
commands.  More may be added in the future.  Just remember,
I block searchdiscovered.com not because it has given malware,
but just because it is a tracker / park host.  It has never given me
malware.  In fact the tracking is so slight I may remove the block
of searchdiscovered.com.  Also, all of the hot URLs at the TK domain
have never gone through searchdiscovered.com.  The malware links
go many other places but not through there.

Finally!  A way to prune off useless TK domain blocks.

Good Enough?  If not email me and I will fill in the gaps.

[hhhobbit]

The change lists are gone.  Somebody said they had an installer (It was an exe file) and that ten people were using it.  I don't think so since the visits to the web-site almost completely match my hit count of the tracker that is given to me that I block.  Then somebody paid me a personal visit with a "we don't know who we are looking for" message.  I haven't had a visit from anybody either known or unknown for years.  I turned their binary over to the AV companies for analysis:

http://preview.tinyurl.com/88nr5sf
(VirusTotal Scan - it has the download site indicated in one of my too many remarks)
Size:        1564739
MD5:        da2295b32a81d312d967c535fb5ec903
SHA1:      82671309a56263d56443032b66bc8d6a9eee88ac
SHA256:  96ce1610954d9f65f3d503515490bacc191dbf89a926c1072ddf802a3435ded5

I wasn't happy with it since as a WIndowsRar self extractor it had no copyright string.  I have waited several weeks for them to clear their binary with the AV companies and they don't seem to be doing anything.  Nothing has changed on the detection of it.  Since I was able to get the one AV company that detected the wget.exe which is part of UnixUtils as bad to no longer detect it (McAfee still detects it as tool wget.exe) during that same time period, I assume they have enough time to do the same thing.  The detection of their binary has not changed at all.  Since an anti-spam company has been sued out of existence and MVPHosts has been repeatedly sued I made my hosts file and the change lists unavailable.  I assumed that is where they were headed on this.  So watch your step!

That does not mean I do not have a hosts file.  I do.  It is just that for now it is for personal use only.  Where do you think the PAC filter rules come from?  Out of the air?  But I have focused most of my attention on the trackers in the past year.  However I will from time to time make things available to MDL that I feel may be useful, most appreciably in removing hosts from the hosts list you have.  They will be in this folder:

http://www.securemecca.com/public/MalwareDomainList/

You have two files right now:

http://www.securemecca.com/public/MalwareDomainList/0-ChangesParks.txt
http://www.securemecca.com/public/MalwareDomainList/googlesyndication_PSEUDO.txt

I will make two files - list.txt and rmlist.txt that will list what is new and what was removed.  I just did a complete rebuild of my Host <---> IP DB which caused me remove one park IP and downgrading  others from Park to Pseudo-Park (False Park) status.  I assume you can write a script that will automate pulling down the files.

Sorry