I generally feel lost these days :) Thanks for your continued patience! I absolutely don't want to make this more complicated than it needs to be. I >think< what I'm proposing might actually be simpler, more what ASSP admins would expect, and much better for security.
I see your point about having a match of a hash of a digital signature be enough to allow a file through. I don't know what to do about that, but it's not an issue for me as we'd be looking for hashes of executable content vs signatures. I'm not ignoring its significance though. Let me answer your question from my perspective: >*Why should assp look at any "rest" if one bad content is found (Its an exception)? and reverse - Why should assp look at any "rest" if one known good content is found (Its an exception)? * If bad content is found, I agree, there is no need to scan more, just block it and be done. *But one known good thing found shouldn't allow everything else in that file though. *If you were given a cupcake made with delicious chocolate and poison, just because you see the known to be delicious chocolate doesn't mean you should blindly eat the cupcake. Check for poison even though there's chocolate. --if you're one of the crazy people out there who thinks chocolate is also bad, there is no reasoning with you :) I've thought long and hard, and then as you suggested, even harder about this. With the current functionality, I think there's a real risk of having bad compressed file passed because a matching hash of a file within the compressed file. A known good hash of an Excel file's vbaproject.bin shouldn't pass the whole MS Office compressed file. I think the option to determine how many levels this file can be nested in a zip is a good start. We can allow Excel files with hash matching vbaproject.bin files within the excel file, but not an excel file in a zip, by specifying zip level 1. But to your point, what if *"there is an object included in the office file (it's an OLE which can contain anything - also executables)"* ? I'd want to block OLE!! Just because a vba project matches a good hash, why would we then want to allow unknown OLE in that same office compressed file through? I'm just not seeing the advantage to letting it through, but certainly see the risk. Summary: I want to consider the hash list as a way of ignoring a file type/content rule that would ordinarily block the file. If that match is on part of a file (either a file within a compressed file or part of a PDF), I still want ASSP to consider the other parts of that file against the rules. It's mostly compressed files that I'm worried about, because I've already seen multiple good quotes and a similarly named exe in a zip in the real world. What if a definition like 08d5518ef129ba1a992f5eb5c25e497cf886556710ffebe7cfb6aedf9d5727c9 *2* # VBA Macro signature of vbaProject.bin in Excel file or that .bin in an excel file in a zip would: 1) Ignore that VBA was found in a directly attached Excel file excel (not in a second compressed file) if vbaproject.bin matches a known hash (ignore the vba vs specifically allowing the whole file), but continue checking for other blocked content in that excel file like OLE's we don't know about. If something else is found in that Excel file, block it, even though we also found a good hash in it. 2) Do the same thing for an Excel file (say quote.xlsm), is in a zip file (outer.zip). If an office macro is found in quote.xlsm with a matching hash, just ignore that part of the xlsm. Check the rest of the xlsm file for other prohibited content. If nothing matches, scan the other files in outer.zip for prohibited content, traversing into them if they're also compressed files. And if for some reason there was an excepted hash 3 levels down, ignore that it is excepted, because the hash definition above limits to 2 levels. This would stop: A) Outer.zip sent from a compromised vendor that includes Quote1.xlsm, Qutoe2.xlsm, and Quote3.EXE - quote1 and 2 has a good hash, quote3.exe is the bad file B) Quote1.xlsm sent from a compromised vendor that is a copy of their standard quote with allowed VBA but now includes malicious OLE. Before the hash allowing feature, for an office macro to be allowed through, we had to allow >>all<< MSOM from a given address, which was far from optimal. But at least with that, OLE would sill be blocked. Now, we can only allow known MSOM (vba), but in doing so OLE will get though in that same file which scares me. On Tue, Jan 22, 2019 at 2:08 AM Thomas Eckardt <thomas.ecka...@thockar.com> wrote: > I'm lost. (: > > using the following rule > > zip:*@domain => block => exe-bin|xml > > having an exception SHA-hash for the included vba file > > what would happen - think about .... > > even harder - in addition there is an object included in the office file > (it's an OLE which can contain anything - also executables) > > what would happen - think about .... > > >If you looked at the rest of the content > > Why should assp look at any "rest" if one bad content is found (Its an > exception)? and reverse - Why should assp look at any "rest" if one known > good content is found (Its an exception)? > > What should be done, if a signature or certificate is hashed , but not the > executable itself? What is the relation beween the cert and the executable > or bad file or good files or not bad files? > > It makes no sense to further scan an attachment, if a known good file is > found - because there is no rule for "what to do" , if "what" is found. > > Your suggestion will lead in to a very very complex attachment definition. > You would have to specify (exactly) for each SHA-hash, which other content > is allowed or forbidden at which zip-level (possibly at which folder level) > > Thomas > > > > > Von: "K Post" <nntp.p...@gmail.com> > An: "ASSP development mailing list" < > assp-test@lists.sourceforge.net> > Datum: 21.01.2019 19:07 > Betreff: Re: [Assp-test] fixed in assp 2.6.4 *SPAM-Evaporator* > build 19015 > ------------------------------ > > > > We can tell vendors not to send zip files, but we don't have a choice for > some of the bigger ones that our charity works with. They won't change, > not ever. > > I understand about AFC just treating office files as zip files (and that's > fine). For those vendors who insist on sending zip files with office macro > enabled files, if we enable the hash of good vbaproject.bin files at level > 2, then that zip will be set as good regardless of the rest of the > content. What I'm asking is why you wouldn't want to mark that file in the > zip as good, but still check the other files in the zip? If you looked at > the rest of the content, that would cause the zip to get rejected if an exe > is slipped in or non-approved vba is in another file. Wouldn't this be > preferable functionality for all? > > > > > > > On Mon, Jan 21, 2019 at 4:26 AM Thomas Eckardt < > *thomas.ecka...@thockar.com* <thomas.ecka...@thockar.com>> wrote: > >Would you consider changing this functionality to consider the other > files in a compressed file, or at least giving us the option between: > > > This is not possible, because ASSP_AFC does not know anything about office > files. Office files are ZIP files and processed like them. > So a part of an Office file will match at zip-level 1. If the Office file > is in a ZIP the match will be at zip-level 2. > > >but the remaining files in the compressed file (or the other parts of > the PDF) will be analyzed and can separately trigger stripping of the > containing zip (or the PDF). > > All other files in an Office file (ZIP) are remaining fles. If you use the > hash of a signature file to detect the 'good' exception, the (or any) > project file would be a remaining file (and possibly blocked). > > > ASSP_AFC handles both cases - "found a bad file" and "found a well known > good file" - as an exception. In the first case it stops processing the > attachment and blocks, in the second case it stops processing and delivers. > Both without analysing any other (still not processed) part of this > attachment > The check for "a well known good file" is done first for all files in a > complete uncompressed tree, before (for example) the executable detection > is done for any part of the ZIP. > > There is only one way to be sure a "a well known good file" definition > can't be (easy) frauded. Restrict the zip-level for parts of office files > to 1 and for PDF to 0 - and tell the vendors to not zip attachments. > > If you fear, a verdors PC can possibly be hijacked and abused to infect > attachments without lossing an agreed signature - don't use this feature. > > Thomas > > > DISCLAIMER: > ******************************************************* > This email and any files transmitted with it may be confidential, legally > privileged and protected in law and are intended solely for the use of the > individual to whom it is addressed. > This email was multiple times scanned for viruses. There should be no > known virus in this email! > ******************************************************* > > _______________________________________________ > Assp-test mailing list > *Assp-test@lists.sourceforge.net* <Assp-test@lists.sourceforge.net> > *https://lists.sourceforge.net/lists/listinfo/assp-test* > <https://lists.sourceforge.net/lists/listinfo/assp-test> > _______________________________________________ > Assp-test mailing list > Assp-test@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/assp-test > > > > > DISCLAIMER: > ******************************************************* > This email and any files transmitted with it may be confidential, legally > privileged and protected in law and are intended solely for the use of the > individual to whom it is addressed. > This email was multiple times scanned for viruses. There should be no > known virus in this email! > ******************************************************* > > _______________________________________________ > Assp-test mailing list > Assp-test@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/assp-test >
_______________________________________________ Assp-test mailing list Assp-test@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/assp-test
