Ben, If you carry your own resolver libs with you AV application you might be able to mitigate this -- or at least detect when the HOSTS file has one of your entries in it.
-rick Ben Li wrote: > As far as I can tell, Windows 7 will be the first version of that > operating system to support DNSSEC, and I look forward to seeing AV > vendors and many others embrace it. Even with DNSSEC, however, I suspect > that malware will still be able to make specific DNSSEC-enabed domains > _inaccessible_ through the local hosts file, and rogue DNS/DHCP servers > and the like. The idea we're exploring is to remove any dependency on > DNS for the specific purpose of delivering AV programs to the gazillions > of existing XP and older Windows desktops which are already infected, > and cannot get to an AV vendor site to obtain AV software. > > -Ben > > > Rick Wesson wrote: >> Why not use a private root and use DNSSEC to do the validation of the >> FQDN. AV >> vendors could even use their own roots and test that looking up their >> addresses >> were correct. At least the AV software would be able to tell that the >> DNS was >> messed up. >> >> There are DNSSEC enabled TLDs -- you could start there. >> >> -rick >> >> >> Ben Li wrote: >> >>> I think this is a discussion about two related parts of a single >>> problem. CouldAV addresses the area of detecting and preventing >>> infections through a great new way to analyse and track binary >>> executables and processes, while Randall's concern seems to be about >>> getting AV tools on to known infected machines that actively resist >>> efforts to install/use AV tools. >>> >>> The present solution concept proposes to break one form of resistance >>> which prevents the infected machine from locating and/or installing >>> AV tools from the Internet, by moving a pointer resolution function >>> (AVpublisher.tld -> IP address) normally provided by DNS (and >>> corrupted by installed malware) into a different layer and space >>> which is not blockable at all by a malware. So far, our preliminary >>> proof-of-concept work indicates that it would be possible to bypass >>> untrustable host name resolution functions to deliver AV tools (such >>> as CloudAV or anything else) to infected machines. >>> >>> -Ben >>> >>> >>> Tomas L. Byrnes wrote: >>> >>>> The concept of distributed/cloudAV has been worked on by the University >>>> of Michigan crew that did the fundamental work that led to Arbor >>>> Networks: >>>> >>>> http://www.eecs.umich.edu/fjgroup/cloudav/ >>>> >>>> It's similar in detection concept to Sunbelt's new product in that it >>>> uses multiple engines, and to the current discussion in that it is a >>>> distributed system. >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] >>>>> On Behalf Of Alex Eckelberry >>>>> Sent: Friday, January 02, 2009 8:26 AM >>>>> To: Ben Li; [email protected] >>>>> Cc: RandallM >>>>> Subject: Re: [funsec] idea >>>>> >>>>> >>>>>> 1) The previous suggestion of housing the payload in a widely >>>>>> available and widely distributed system (Akami) is wise. Google, >>>>>> Wikipedia, twitter, facebook, blogs, hotmail and at least several >>>>>> other popular websites must remain accessible on the infected machine >>>>>> in order for the user not to reformat it, thereby killing the >>>>>> infection. >>>>>> >>>>> It's worth noting that virtually all of the antimalware vendors use a >>>>> CDN -- Symantec uses Akamai, we use Edgecast, etc. Most antimalware >>>>> vendors use a different cname for their downloads (like >>>>> download.sunbeltsoftware.com or live.symantec.com). Maybe there's >>>>> something fruitful there in terms of changing DNS, but like Ben, I >>>>> also >>>>> share a concern that this can backfire. >>>>> >>>>> And, as Ben infers, any solution will have to take into account that >>>>> blocks occur through a wide range of methods, not the least of which >>>>> >>>> are >>>> >>>>> host file modifications, router DNS hacks, local DNS hacks, etc. In >>>>> the >>>>> end, though, I'm still not quite sure about how one would implement >>>>> any >>>>> one of these ideas. >>>>> >>>>> It's an interesting discussion nonetheless. >>>>> >>>>> Alex >>>>> >>>>> >>>>> >>> _______________________________________________ >>> Fun and Misc security discussion for OT posts. >>> https://linuxbox.org/cgi-bin/mailman/listinfo/funsec >>> Note: funsec is a public and open mailing list. >>> >> >> > _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
