NIST has downloadable ISOs of hashes for whitelists: http://www.nsrl.nist.gov/
That ought to help a great deal... On Mon, Feb 7, 2011 at 18:01, Marc Maiffret <mmaiff...@eeye.com> wrote: > Apologies in advanced for the stream of conscious flow of this email as I am > pressed for time. > > > > The way systems are being compromised right now really comes from one of two > main ways: > > > > 1. The “fake av” problem – This is along the lines of what you > described below. A user is convinced to run code in a way that is completely > legitimate. I.E. The user runs an executable from their web browser without > the attacker leveraging a software based vulnerability. This is a common > problem especially as it relates to the various fake anti-virus software out > there. In this case whitelisting would help as the only thing going on here, > typically, is a malicious executable being launched via a web browser. > > 2. Software vulnerabilities – This is different and a much bigger > problem than the first. In this case, which I believe to be more common, > users do not have to do anything but simply view a website and once viewing > a website there is attack code which will leverage an unpatched/unknown > vulnerability within some software on that machine > (IE,FireFox,Reader,Java,Flash,Quicktime,etc…). A lot of these attacks are > being delivered through completely legitimate websites through malicious > advertisements or hackers using SEO methods to have their malicious website > show up in “legitimate” Google search results. > > > > We see the second case happening even more often because it is so simple and > reliable. In the second case since your leveraging a vulnerability in a > known good application it means your now executing code (in the case of a > buffer overflow) within that known good applications process space which > means your part of the good white list and can do what you please. So unlike > today where typically you would start executing code within Adobe Reader > just enough to download somemalware.exe and execute it. You would have an > intermediary step to either a) Have your malicious code that executes within > Adobe Reader kill what process control security software is running (i.e. > kill bit9) and then execute your malware just as normal b) Make yourself > persistent on the system in one of a number of ways that do not actually > require an executable. Think Operation Aurora and it using a services.dll > style to backdoor the system which means your now just a .dll running within > svchost.exe which is a process that has to be white listed. Or you’re a .dll > running within rundll32.exe which is also white listed. Now the good guys > become required to also white list control all .dll’s and if you thought > trying to manage what processes you should or should not be running was hard > with just executables it becomes a nightmare, i.e. an IT time sink, to do it > for every .dll. And then of course the .dll example I gave is just the > simple bypass, there are more sophisticated things that again raise the bar > to make whitelisting worthless pretty fast. > > > > So is whitelisting not worth it at all? I.E. Should you not look into a > whitelisting solution or an endpoint security solution that has whitelisting > as a component? No, I would not go that far, I think some level of process > control can be helpful but as a feature of a good endpoint solution rather > than an entire solution itself. For example in the endpoint security product > I help create we use process execution control but rather than trying to > figure out all that you should and should not be white listing we are > controlling known good behavior around the more commonly attacked > applications (web browser, office, adobe, etc…) Then we fill in the white > listing gaps by doing in process memory monitoring to more generically > prevent exploits that are actually leveraging the more common classes of > application vulnerabilities such as buffer overflow attacks etc so that when > an attacker goes to initially execute malicious code within Adobe we deny > that from happening in the first place which means we don’t have to worry > about the after fact of trying to control processes and other things that > become a losing battle. > > > > I forget if it is this week’s VEF or the next one that one of my researchers > is covering some data we dug up on most common locations for malware to > reside on a system etc… http://www.eeye.com/VEF > > > > -Marc > > > > From: Crawford, Scott [mailto:crawfo...@evangel.edu] > Sent: Monday, February 07, 2011 1:54 PM > To: NT System Admin Issues > Subject: RE: Intel developing security 'game-changer' > > > > Well stated. > > Do you have any opinion on the volume of malware we’d see in a strictly > white-list environment as opposed to a strictly black-list environment? > Right now, the “vulnerability” is predominately the user who can be > convinced to run code to see the dancing pigs. It seems that white-listing > effectively plugs that hole, but then we’d move on to vulnerabilities in > executables. So, I guess the question becomes “Does code written by God have > more vulnerabilities than code written by nerds?” > > > > From: Marc Maiffret [mailto:mmaiff...@eeye.com] > Sent: Monday, February 07, 2011 2:24 PM > To: NT System Admin Issues > Subject: RE: Intel developing security 'game-changer' > > > > “AV today never addresses the known app that has the vulnerability, but > rather the separate malware executable that it spawns” > > > > Never a more true statement than that. If people spent half the time they do > talking and worrying about threats as they did managing the root of the > problem, vulnerabilities, they would be far better off. > > > > Black/white listing is so easily bypassed it has a small half-life of being > effective. I.E. If everyone used such technology tomorrow then > exploits/malware would be very easily updated to bypass it. You can find a > great example of what the world would look like in the case of executable > control based on what happens with iPhones and the app store. That is a > great example of strict application code down to a code signing and related > level etc… Again the problem though is legitimate applications having > unpatched/unknown (zeroday) vulnerabilities. Case in point was one of the > more recent iPhone “jail break” techniques which was in reality an exploit > for a PDF vulnerability within iPhone that was leveraged for lower level > access and eventually the rooting of the device etc… Appstore/appcontrol/etc > all go out the window in these scenarios. > > > > Executable control is still in the threat prevention category and as such it > just requires an evolution of the threat to become as useless as AV is these > days. > > > > I am obviously biased in believing that vulnerabilities are one of the most > important things to focus on as that is the sort of security technology I > help make for a living. That being said though when I founded eEye over 13 > years ago I was coming directly from a place of having been a teenage hacker > with hands on experience in exactly how systems are compromised. It was as > clear to me then as it is still to me now that so long as your chasing the > next threat you will never see much success. > > > > And while on the topic I encourage you guys to join eEye’s free > Vulnerability Expert Forum which is a live webinar with myself and eEye > research discussing the new vulnerabilities from Patch Tuesday, outstanding > zeroday, and other generally interesting things happening in IT security and > research. http://www.eEye.com/VEF > > > > -Marc > > > > Signed, > > Marc Maiffret > > Founder/CTO > > eEye Digital Security > > http://www.eEye.com > > > > SC Magazine vulnerability management review: > http://www.scmagazineus.com/eeye-digital-security-retina-cs/review/3405/ > > > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > Sent: Sunday, February 06, 2011 6:51 AM > To: NT System Admin Issues > Subject: Re: Intel developing security 'game-changer' > > > >>>It sounds like we agree for the most part. > > > > It seems clear to me from your responses that we really don't. > > > > > >>>Again, my response was intended toward MBS’s comment and others like it. > > > > Like mine, since I actually agree with the statement that MBS made. > > > > > >>>As long as we agree that that we’ll still need blacklists in a whitelist >>> environment, I have no issue. > > > > We disagree, because if you only allow, say, 4 things to run, how does it > help you to have a separate list of, say, 50 things that you don't want to > have running? > > > > You keep arguing the point of the infiltration of a whitelisted app, without > properly addressing how this infiltration would look like operationally. > (AV today never addresses the known app that has the vulnerability, but > rather the separate malware executable that it spawns) > > > > -- If ACROBAT.EXE is suddenly a bad app, then how are you more protected by > a blacklist than a whitelist in a zero-day scenario? > > > > -- If Off The Shelf App has a vulnerability that allows an attacker to spawn > MyOwnBadApp.exe on a remote system, then how are you more protected by a > blacklist than a whitelist in a zero-day scenario? > > > > -- If NEWNAME.EXE is released into the wild, and copied to your network by a > VPN user, then how are you more protected by a blacklist than a whitelist in > a zero-day scenario? > > > > Whitelists are going to have to become THE preferred mechanism for much of > desktop security[1], or we will be forever behind the curve with malware, > getting hit by more and more zero-day executables, and subjecting ourselves > to an ever increasing number of self-inflicted denial of service attacks by > hastily QA'd malware definition signatures. As these points are detailed in > my previously linked blog post, I need not elaborate on them again here. > > > > It seems that we will simply have to agree to disagree. > > > > ASB (Find me online via About.Me) > Exploiting Technology for Business Advantage... > > > > [1] This is outside of anomaly behavior detection mechanisms -- we're simply > discussing whitelisting vs blacklisting here > > On Fri, Feb 4, 2011 at 8:04 PM, Crawford, Scott <crawfo...@evangel.edu> > wrote: > > Sorry, for the slow response, I missed your reply while replying to Kurt. > > > > It sounds like we agree for the most part. Again, my response was intended > toward MBS’s comment and others like it. As long as we agree that that we’ll > still need blacklists in a whitelist environment, I have no issue. > > > > Even if it takes the signature writers a mere 24 hours to: > > figure out all the combinations of "bad bits" > test and validate the fix > make the fix available to their distribution mechanisms > get your systems to pick them up > > That's still a long time for a zero-day infection to do its work. And, > having worked with a number of AV vendors on zero-day scenarios, 2-3 days is > not unreasonable for reverse engineering a good exploit. > > > > Where does that leave your systems which are only relying on a list of bad > things to block? > > > > In a very bad state indeed. But remember, I’m not suggesting that system > rely ONLY on a list of bad things to block. > > > > A friend recently suggested an analogy. > > > > Most people treat their homes as a whitelist environment. A relatively small > number of people on Earth are welcome – family, friends, and the occasional > supermodel J. But, after I let my brother in the front door, I’m still going > to kick him out if he starts tracking mud all over my carpet. He’s > white-listed, but the mud is blacklisted. > > > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > Sent: Monday, January 31, 2011 2:47 PM > To: NT System Admin Issues > Subject: Re: Intel developing security 'game-changer' > > > > Scott, > > > > Your response points out things that I already pointed out in my response. > Yes, there are specific scenarios where whitelisting does not prevent an > attack. Even then, it still affords additional opportunities to mitigate > exploitation of the vulnerability. Additionally, there are many other > scenarios where whitelisting addresses a weakness of blacklisting. > > > > So you still come out ahead. Please note my comments about vendor > facilitation of granular feature control to mitigate the types of problems > that you are focusing on. > > > > Now, let's look at how the vulnerabilities you mention are actually > exploited. > > http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability > http://isc.sans.edu/diary.html?storyid=992 > http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx > > > > By getting someone to open up a specially crafted data file (via web, email, > file share, etc), you can cause the primary application to spawn your > executable (which is hidden in the "data" file) -- typically with all the > rights of the spawning app. > > > > Now, depending on how such an application is initiated, it may not spawn as > a child process, but as its own process. If it spawns as a child process, > then whitelisting may or may not help. But, as its own process, it would > fail to be initiated -- even in a zero day scenario for which no signatures > exist. > > > > Even if this is only in 50% of the zero-day situations, you're still > protected to a much greater degree than via signatures alone. > > > > > > > >>>Antimalware signatures are generally produced much more rapidly than an >>> application patch. So, while a zero day flaw may take a week (optimistic) to >>> patch, the AV vendors could be blocking all .txt files containing the >>> offending string of bits. > > > > Which doesn't take into account all the effort that malware writers put into > their "work" to ensure that offending string of bits is obfuscated. > > > > Even if it takes the signature writers a mere 24 hours to: > > figure out all the combinations of "bad bits" > test and validate the fix > make the fix available to their distribution mechanisms > get your systems to pick them up > > That's still a long time for a zero-day infection to do its work. And, > having worked with a number of AV vendors on zero-day scenarios, 2-3 days is > not unreasonable for reverse engineering a good exploit. > > > > Where does that leave your systems which are only relying on a list of bad > things to block? > > > > > >>>Agreed for the time being. But, if we were to flip a magic switch and swap >>> to a predominantly white-list based environment, the most common >>> exploitation vectors would switch to exploiting white-listed .exes through >>> buffer overflows or other methods of tricking an .exe to doing more than >>> displaying data in a data file. > > > > I'm not sure where you have gotten this idea that buffer overflow and > "executable" data exploits involve making the parent application do new > tricks. All they do is get the parent application to run new code of the > attackers choice, and in many cases, that code is subject to running in its > own environment -- thus, blockable in a whitelisting scenario. > > > > I've experienced several examples of this during my testing of what later > became Cisco's CSA product, and eEye's Blink! > > > > Here's a good article to read: > http://www.intelligentwhitelisting.com/blog/problem-vulnerable-whitelisted-application-part-ii > > > > ASB (My Bio via About.Me) > > Exploiting Technology for Business Advantage... > > > > > > From: Crawford, Scott [mailto:crawfo...@evangel.edu] > Sent: Monday, January 31, 2011 6:12 PM > > To: NT System Admin Issues > Subject: RE: Intel developing security 'game-changer' > > > > Inline, but here’s some opening comments J > > > > White-listing .exes does nothing to stop attacks like .wmf and .jpg > vulnerabilities below. > > > > http://www.symantec.com/business/security_response/attacksignatures/detail.jsp?asid=21526 > > http://www.symantec.com/security_response/writeup.jsp?docid=2004-091516-5119-99&tabid=2 > > > > While these may be currently patched and/or low risk, I think they server to > illustrate my point. Note that AV signatures detect the badness in them > before Microsoft patched the offending executable. Also note that under all > but the most restrictive white-listing campaign, the code that processes > .wmf and .jpg would be allowed. > > > > Again, please don’t misunderstand me. I’m not saying white-listing is > without its advantages. I’m simply saying that it’s not a solution to stop > malware. Impair it? Yes. Stop some of it? Yes. But, the primary reason it > stops some and even most current malware is because it’s not very popular > yet. > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > Sent: Monday, January 31, 2011 2:47 PM > To: NT System Admin Issues > Subject: Re: Intel developing security 'game-changer' > > > >>>There are MORE good files that I want to use than bad that I want to >>> block. > > > > Except that most of those good files won't get executed if you stop a more > limited number of other executables from launching. > > > > My concern is infected data files that are associated with a white-listed > .exe. > > > > You don't necessarily have to track every version of every known DLL that > might ever get executed, if you can simply track the far more limited number > of executables that would spawn them. > > > > Understood > > > > It would appear that you're looking at whitelisting in a very different way > than is typically implemented. What is your understanding of how a > whitelisting solution would need to work? > > > > Yes, I am becoming aware that I’m looking at it very differently J. That is > basically my point. The way it’s typically implemented is to specify an > allowed list of executables using multiple ways of compiling that list – > publisher, path, hash, filename, etc. This is basically the only practical > way it can work. However, to be *truly* stop all malware from executing, it > would also have to include all documents/data files that a user would want > to use. > > > > > >>>If there’s a chance that said application will make a mistake, then we >>> also need something signature based to block the bad bits. > > > > Except that the scenario you're presenting is exactly what we call Zero Day > attacks. Vulnerability is discovered in an approved app (no matter how you > chose to identify "approved app") and it gets exploited. How is a signature > helping there when the attack is new? > > > > Antimalware signatures are generally produced much more rapidly than an > application patch. So, while a zero day flaw may take a week (optimistic) to > patch, the AV vendors could be blocking all .txt files containing the > offending string of bits. > > > > > > If the vulnerability is one that requires no new executables, then a > zero-day attack is equally damaging to a whitelist or blacklist approach. > > > > If the vulnerability is one that spawns a new executable, then a zero-day > attack is not effective in a whitelist scenario, but just as damaging as > always in a blacklist scenario. > > > > I address the need for vendors to allow features and functionality to be > enabled or disabled independently (in the very next paragraph) > > > > Right. The ability to turn off javascript/macros in Word, Reader, IE, etc. > is certainly a beneficial addition, but it doesn’t prevent other forms of > malware that may be present in a .doc or .pdf, just the malware that > exploits the built-in execution engine. > > > > , which would provide even more security. In the meantime, blacklisting at > the host level as the primary means of protection is a game of increasing > risk with diminishing returns... > > > > Agreed…for the time being. But, if we were to flip a magic switch and swap > to a predominantly white-list based environment, the most common > exploitation vectors would switch to exploiting white-listed .exes through > buffer overflows or other methods of tricking an .exe to doing more than > displaying data in a data file. > > ASB (My Bio via About.Me) > Exploiting Technology for Business Advantage... > > > > > > On Mon, Jan 31, 2011 at 2:36 PM, Crawford, Scott <crawfo...@evangel.edu> > wrote: > > “Application whitelisting is a good idea, because for every environment, > there are less items that fall into the “known good” category than bad code > that you don’t want to run.” > > > > This assumption simply isn’t true. Data = 1’s and 0’s = code. There are MORE > good files that I want to use than bad that I want to block. If there was > some magic bullet that ensured “data” files could never contain executable > bits, then I would agree whole heartedly. But, I don’t believe such bullet > will ever exist. Therefore data = 1’s and 0’s = code and its up to the > whitelisted .exe to interpret them correctly. If there’s a chance that said > application will make a mistake, then we also need something signature based > to block the bad bits. > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > Sent: Monday, January 31, 2011 12:25 PM > > To: NT System Admin Issues > Subject: Re: Intel developing security 'game-changer' > > > > Here are my full thoughts on the subject, as a security mechanism: > > > > http://home.asbzone.com/ASB/archive/2010/05/10/it-s-time-to-re-evaluate-host-based-security.aspx > > > > No, it is not a panacea, because no security mechanism ever is. Yes, there > are drawbacks, but focusing on these technologies will provide a bigger bang > for the buck and allow us to mitigate the weaknesses sooner. Either way, > your ROI is greater in most scenarios which use whitelisting vs > blacklisting. > > > > Also, check out the following: > http://www.schneier.com/blog/archives/2011/01/whitelisting_vs.html > > > > > > ASB (Find me online via About.Me) > Exploiting Technology for Business Advantage... > > > > > > On Mon, Jan 31, 2011 at 12:48 PM, Crawford, Scott <crawfo...@evangel.edu> > wrote: > > “No one here has suggested panacea” > > > > Perhaps not, but that’s not my perception. I see lots of statements like > “I’m still of the opinion that the only real solution is white-listing. - > MBS” Maybe I’m misreading that, but that hints at a panacea and I’m simply > saying that it’s not. > > > > All of your other points – I agree. > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > Sent: Wednesday, January 26, 2011 4:35 PM > > To: NT System Admin Issues > Subject: Re: Intel developing security 'game-changer' > > > > No one here has suggested panacea, but consider how effective it would be in > a white-listing environment to add most apps to the list in the event of a > zero-day to an EXISTING app. You wouldn't have to do anything for an app > that wasn't already allowed in your environment. > > > > It is akin to the change in firewall rule-set made in ages gone by from > Allowed-by-Default to Denied-by-Default. > > > > Likewise, look at all the environments that have moved towards some form of > locked down user desktop and see how much of a benefit has resulted. > > > > Reducing problems by 50-80% off the bat, with little overhead, is always > desirable. > > > > ASB (My Bio via About.Me) > Exploiting Technology for Business Advantage... > > > > > > On Wed, Jan 26, 2011 at 5:03 PM, Crawford, Scott <crawfo...@evangel.edu> > wrote: > > My point is that neither signatures, nor white-listing are a panacea. The > fact that we’ve been sig based for so long while malware continues to be > effective leads many to think that white-listing would solve all our woes. > I’m simply saying that many *current* vulnerabilities circumvent a > white-list so it can’t be a panacea…unless of course you white-list each > individual data file. > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > Sent: Wednesday, January 26, 2011 1:55 PM > > To: NT System Admin Issues > > Subject: Re: Intel developing security 'game-changer' > > > > Just as network anomaly detection devices don't eliminate the use of > signatures, whitelisting solutions can still make use of several mechanisms > for avoiding bad stuff. > > > > It is the complete RELIANCE on signatures that is troublesome. > > > > Oh, and btw, I try to avoid Adobe Acrobat altogether. There are plenty of > viable alternatives at the moment... > > > > ASB (My Bio via About.Me) > > Exploiting Technology for Business Advantage... > > > > > > On Wed, Jan 26, 2011 at 2:51 PM, Crawford, Scott <crawfo...@evangel.edu> > wrote: > > Unless you’re going to white-list every doc/jpg/pdf/mp3 you’re going to > open, that’s not a panacea either. Documents = 1’s and 0’s = code. The only > difference is what layer its executed at. Assume you white-list > AdobeReader.exe. The next time a flaw is found that is exploited through a > malformed PDF, it will march right through your white-list. > > > > From: Michael B. Smith [mailto:mich...@smithcons.com] > Sent: Wednesday, January 26, 2011 1:38 PM > > > > To: NT System Admin Issues > > Subject: RE: Intel developing security 'game-changer' > > > > I’m still of the opinion that the only real solution is white-listing. > > > > But that raises its own set of issues. > > > > Regards, > > > > Michael B. Smith > > Consultant and Exchange MVP > > http://TheEssentialExchange.com > > > > From: Andrew S. Baker [mailto:asbz...@gmail.com] > > Sent: Wednesday, January 26, 2011 2:35 PM > > To: NT System Admin Issues > > Subject: Re: Intel developing security 'game-changer' > > > > Since a whole lot of allegedly legitimate software acts just like malware, > they'd have their work cut out for them. > > > > Try installing a host-based IPS on your system in monitoring mode, and look > at what it would block -- and why. > > > > There are certain classes of zero-day that can be blocked by software or > hardware. There are others that cannot be, simply because of what passes > for functionality these days. > > > > Oh, and I agree with Ben and Jonathan... > > > > ASB (My Bio via About.Me) > Exploiting Technology for Business Advantage... > > > > > > On Wed, Jan 26, 2011 at 1:47 PM, Sean Martin <seanmarti...@gmail.com> wrote: > > Most important statement.... > > > > "If Intel has hardware technology that can reliably stop zero-day attacks, > that would be a huge win in the war against malware," Olds said. "The key is > that it's reliable. It has to have the ability to discern legit software > from malware. But if they can pull this off, it would give them quite a > competitive advantage vs. AMD." > > > > - Sean > > > > On Wed, Jan 26, 2011 at 9:37 AM, David Lum <david....@nwea.org> wrote: > > What say you, Alex, et all. > > > > http://www.computerworld.com/s/article/9206366/Intel_developing_security_game_changer_?taxonomyId=85 > > > > Hype? > > David Lum // SYSTEMS ENGINEER > NORTHWEST EVALUATION ASSOCIATION > (Desk) 503.548.5229 // (Cell) 503.267.9764 > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
