>I think there's a real risk of having bad compressed file passed because a matching hash of a file within the compressed file.
Yes - a really small one - but there is a risk! To elimnate the risk, the hash validity must be resticted to a single zip-level, which does not allow to bypass at any lower zip level.. >I still want ASSP to consider the other parts of that file against the rules. What you want to do will only work if the hash is calculated over all forbidden parts (eg. executables). It will not work, if the hash is calculated over a signature or certificate or only one executable part. It is the same like anywhere in assp. If a defined or agreed level of trust is reached by a mail (sender, recipient, SPF, DKIM, DMARC .....) , the mail may be delivered regardless of its content. A good example is a PDF which includes many JavaScripts. In your scenario, you would have to calculate and to register the hash for each JS part - and the PDF will only pass, if not a single one of them is changed (has not a hash match). The goal of this feature is, that you don't need to do this, if the PDF is signed. If the signature hash is found,all other 'bad' parts (JS) are accepted. Another good reason to keep the exceptional behavior (stop at a found good) are for example .jar or .war files. Such file can contain hundreds or thousands of java classes (all are executabes). It would take ages to process them all using this feature without the exceptional behavior. This I meant, when I said "think about it". Think about it from a general point of view in IT - not as an admin who battles with some office files. This feature is mainly build, to make attachment conversation easy. For example, any of your departments sends out sheets or PDF's, that have to be filled out by anyone else. The IT department (you) creates the required templates and signs the documents (PDF, macro, OLE, JS ...). As long as nobody touches or changes the signed parts, the signatures will not change and are keeped valid. If the documents are sent back at a agreed level of compression, they can be validated and delivered without any risk. If your company is the recipient of such documents, find and define the trust level together with the sending partner. Using this feature without an agreed and trusted security level of conversation, may lead in to a more or less higher security risk. What you want to do is to define or to find a 100% trust level without an agreement with any conversation partner - IMHO this is not possible, because the partners can change.their behavior at any time - anyway. Thomas Von: "K Post" <nntp.p...@gmail.com> An: "ASSP development mailing list" <assp-test@lists.sourceforge.net> Datum: 22.01.2019 21:44 Betreff: Re: [Assp-test] fixed in assp 2.6.4 *SPAM-Evaporator* build 19015 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 > 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 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 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
