funsec mailing list archives

Re: idea


From: RandallM <randallm () fidmail com>
Date: Sat, 3 Jan 2009 20:28:30 -0600

This seems to be what everyone is missing:

 "GETTING TO A HELPLESS PERSON WHO'S COMPUTER IS UNABLE TO REACH ANY SITE OR
DOWNLOAD ANY PROGRAM TO AID THEM".

Thus, we have thought on "obfuscation" of the links to such sites and or
tools. Any "www.malware-help.com" DNS common sites are "blocked".

"AV-CLOUDS", "DNSSEC" do not provide for "after" the infection of those that
have not received "clients" or "resolvers" prior to infections. They are
real problems NOW!

How does Grandma get help? She takes to "such and such" for $200 dollar who
for get to say "oh, take your family pics off", wipe her drive and reload
the pc. She tryed to go to AV and other scan sites but instead the browser
took her to "wifes lonely and horny".

Understand now?

On Sat, Jan 3, 2009 at 5:27 PM, Ben Li <banjili () gmail com> wrote:

Hi Rick,

It would be great to have that as a problem, since that means the AV app is
running on the infected machine. If I can get my resolver on to the infected
machine, I can also get an AV app on to the machine. The limitation we're
trying to solve is how to get the AV app on to the machine, when the malware
is actively preventing (through breaking DNS) known AV apps from being
obtained from the regular sources. You're right in that AV apps would
benefit if they carried their own resolvers (and doing so would make some of
the apps we've tested somewhat more robust), but the basic limitation we're
addressing occurs before that point.

-Ben



Rick Wesson wrote:

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: 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.











-- 
been great, thanks
Big R a.k.a System
_______________________________________________
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.

Current thread: