Re: idea

[rackow () mcs anl gov]

I'm missing something in regards to DNSSEC and how it helps here.

If you "own" the machine, you can replace the DNS server info used by that
machine.  Note you can also replace the public keys, etc that go along
with these root zones or any subdomain.  Yes, a little more complex,
but not all that much considering what they corrently do to a system.

If you own that DNS server, you can have it feed any information you
want it to.  The client can do all the authentication it wants, the
pieces all line up, they are just wrong.

This would have a better chance of working if the network the infected
machine is on is behind a firewall that doens't allow outgoing port 53
except to a known trusted DNS server.  I don't think that many are.
With that kind of setup, you could trigger an alert from the firewall
that some machine is infected and attempting to get out anyway.

Granted if you have your own tools that you are using to obtain
various signatures, etc and cross check them internally,  you
can trust what is provided, but that's only as long as your tool
isn't infected too.

--Gene

Ben Li made the following keystrokes:
> 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: funsec-bounces () linuxbox org [mailto:funsec-bounces () linuxbox org]
> > > > > On Behalf Of Alex Eckelberry
> > > > > Sent: Friday, January 02, 2009 8:26 AM
> > > > > To: Ben Li; funsec () linuxbox org
> > > > > 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.
_______________________________________________
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.