Re: idea

["Tomas L. Byrnes" <tomb () byrneit net>]

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
>
>
>
>
> -----Original Message-----
> From: funsec-bounces () linuxbox org [mailto:funsec-bounces () linuxbox org]
> On Behalf Of Ben Li
> Sent: Friday, January 02, 2009 12:29 AM
> To: funsec () linuxbox org
> Cc: RandallM
> Subject: Re: [funsec] idea
>
> Hello Randall,
>
> As a lurker, a part time system administrator, and an ex-developer, I
> offer the following (slightly vague for public consumption).
>
> I read from your original post the following assumptions about a
> worst-case scenario of an infected machine:
> 1) DNS is locally compromised and unreliable.
> 2) All of the web browsers on the infected machine are compromised and
> unreliable with respect to the types of content they will access and
> store, and specifically will not download executable binaries which are
> assumed to contain anti-maware capabilities.
>
> Your identified problem seems to be that you want to easily locate and
> retrieve remote resources using an infected machine, under the above
> conditions. The general form of the solution, then, is to functionally
> relocate DNS-like functionality, and content transfer functionality up
> the network stack into layers not typically patrolled by the malware.
>
> Those conditions leave at least the following unblockable vector for
> delivering an executable payload:
> 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.
> 2) As established, Akami is difficult and expensive to play with. The
> umpteen other unblockable sites which host user-generated content are
> neither difficult, nor expensive to play with.
>
> By now, you've probably realized that any solution pattern for this
> problem, given assumptions 1 and 2, will have the consequence of being
> difficult to detect or stop via legitimate network security tools, and
> of consequence, such solution patterns may also be employed by the
> malware authors to deploy very resilient C+C networks, hence, my
> reluctance to even mention that this idea is possible.
>
> I've been mostly inactive in this part of computer security for several
> years, so I don't know if this abuse of non-blockable user-generated
> content injection is a new idea. (I know that link spammers are
insanely
> effective at content injection already, albeit for different purposes.)
> I've not seen it described in the Di(e|t)trich papers from this fall.
If
> you know of any references, or if you find some flaw in the above
> reasoning about the potential threat, a quick note would would be
> appreciated. If, on the other hand, this is a new type of legitimate
> threat, I look forward to working with you to ensure that the right
> people are at least made aware that it exists.
>
> Happy new year,
> -Ben Li
> MA Candidate, University of Calgary
>
> RandallM wrote:
> > ok, I am drinking, after all it is the NYE celebration. But, I had
> > this idea pop in. Remember, it is a "first thought idea". That means
I
> > am in need of input to brainstorm with me on it. Here is the initial
> > thought:
> >
> > When fixing infected computers I find that:
> > 1. most people don't have programs installed for preventive much less
> > combative 2. depending on the infection one cannot download programs
> > or go to "helpful" sites to use.
> >
> > malware sites often rotate IP or DNS in order to "hide".
> >
> > Thought:
> > Why can't we using the same type of process provide access to
programs
> > and or sites in the same manor so that the malware infections cannot
> > "block" because the sites are not permanant?
> >
> > Symantec is and always will be "www.symantec.com
> > <http://www.symantec.com>", as with other sites. they are blocked by
> > malware infections (in various ways that I would love to understand
> > more). If there were "server" around the globe open with online
> > scanners and tools that rotated with DNS and or IP addressing the
> > malware could not block it.
> >
> > Can this be done with a revolving network of servers from volunteers?
> >
> > Make sense or have I already drank too much?
> >
> > --
> > been great, thanks
> > Big R
----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > 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.

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