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 > > > > >-----Original Message----- >From: [email protected] [mailto:[email protected]] >On Behalf Of Ben Li >Sent: Friday, January 02, 2009 12:29 AM >To: [email protected] >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.
