Re: Ideas sought for blocking new variant of cryptolocker
On 7/8/2014 10:41 PM, David F. Skoll wrote:
On Tue, 08 Jul 2014 21:03:35 -0400
Kevin A. McGrail kmcgr...@pccc.com wrote:
So this sounds like you are searching the entire email for this
string which just sounds inefficient especially if they use some big
attachments.
It's not too bad because the regex is simple.
I just think it could hit on non-attachments quite easily without any
mime handling . I saw another email that tried to anchor it to base64
or something similar.
if (uc($header) eq MZ) {
You don't want the uc(); that could lead to false-positives, but yes,
the idea is correct.
Good point.
The reason I did it with a SpamAssassin rule is that we have ways to
push out SpamAssassin rules easily to our customers, but not so much
code changes. :)
Make sense.
The rule hits on surprisingly few messages (only two out of a couple of
million so far), but it's not terribly accurate: One false-positive caused
by a stupid base-64 encoder that leaves extra newlines between lines,
and one sort-of-false-positive that was a DLL renamed to .DAT to sneak
past filename extension blocks, but wasn't otherwise malicious.
Having had some people I've helped hit by CryptoLocker, I think the FPs
may be outweighed by the gains.
Regards,
KAM
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Wed, 9 Jul 2014 17:44:26 -0700 (PDT) John Hardin jhar...@impsec.org wrote: I'm not excusing their approach, but I'm saying there are a lot of sources of real-world friction that lead to suboptimal solutions like this. I expect the desire to avoid requiring installation (and maintenance!) of PGP/GPG by their (assumed non-technical) customers is the primary reason they are doing it this way. Yes. Symantec is the real culprit here. It is actively encouraging the compromising of computers with the workflow of its product. The proper approach would have been to make freely available a Symantec Encrypted Archive viewer, similar to how Adobe makes PDF readers freely available. Symantec of all companies should know better. Regards, David.
Smtp auth and trusted_networks
Hi In the following example our mx received message with ESMTPSA from 1.1.1.1 and that ip detected as trusted. Our trusted_networks list do not have this ip configured. I need to run rbl check against 1.1.1.1. Is there any settings to not add authenticated host to trusted hosts ? We use SpamAssassin version 3.3.1. Jul 10 14:27:34.275 [9780] dbg: received-header: parsed as [ ip=1.1.1.1 rdns=sender1.domain.com helo=mail.domain.com by=mx.domain.com ident= envfrom= intl=0 id= auth=ESMTPSA msa=0 ] Jul 10 14:27:34.275 [9780] dbg: received-header: relay 1.1.1.1 trusted? yes internal? yes msa? no Jul 10 14:27:34.277 [9780] dbg: received-header: parsed as [ ip=2.2.2.2 rdns= helo= by=mail.domain.com ident= envfrom= intl=0 id= auth= msa=0 ] Jul 10 14:27:34.277 [9780] dbg: received-header: relay 2.2.2.2 trusted? no internal? no msa? no Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-Trusted: [ ip=1.1.1.1 rdns=sender1.domain.com helo=mail.domain.com by=mx.domain.com ident= envfrom= intl=1 id= auth=ESMTPSA msa=0 ] Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=2.2.2.2 rdns= helo= by=mail.domain.com ident= envfrom= intl=0 id= auth= msa=0 ] Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-Internal: [ ip=1.1.1.1 rdns=sender1.domain.com helo=mail.domain.com by=mx.domain.com ident= envfrom= intl=1 id= auth=ESMTPSA msa=0 ] Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-External: [ ip=2.2.2.2 rdns= helo= by=mail.domain.com ident= envfrom= intl=0 id= auth= msa=0 ] Thanks.
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
soapbox I believe strongly that ALL IT admins would be well guided by reading the SAGE ethics guide http://www.pccc.com/base.cgim?template=sage_code_of_ethics Can't recommend it highly enough and I think it would guide well in this gray areas on how to handle things. I didn't like that a poster with good intentions was attacked because he couldn't discuss specifics. To me, that's when I look at the credibility of the speaker to gauge the credibility of the story. Further, I can't think of a single tenant of the ethics guidelines that DFS didn't maintain in his posting AND his credibility in the anti-spam community is as excellent (as long as you ignore his commercials: https://www.youtube.com/watch?v=ccIzZS_wD6U). Anyway, there are a lot of bad actors out there that we need to focus on stopping. Attacking good actors just because we don't like their acting (and DFS' acting is horrible) just helps the bastard spammers. Please keep this in mind in the future. /soapbox Regards, KAM
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On 7/9/2014 5:18 PM, David F. Skoll wrote: On Wed, 09 Jul 2014 14:44:27 -0700 Ted Mittelstaedtt...@ipinc.net wrote: David DID NOT say that. He said that he was shocked to discover Why are you assuming he is under NDA or he is an employee of this company? Let me clarify the situation: 1) I'm the owner of Roaring Penguin, so my boss is unlikely to fire me for breaching company policy. 2) We operate hosted anti-spam service for a large number of customers. 3) Many of our customers are quite sensitive about their privacy. 4) Although I could probably reveal details of this incident without consequences, I choose not to out of respect for our customers. It would not look good if I revealed the companies with whom our customers correspond to the entire Internet, at least not without asking first. [...] Now, in MY opinion there are only TWO ways to handle organizations like large data processing company It turns out that the company is using this product: http://www.symantec.com/business/support/index?page=contentid=TECH149840 to send sensitive information to its customers. I'm not about to shame the large data processing company since the product is probably being used by some low-level and harried clerk who was told by IT that it was the approved way to send sensitive information. I am *quite* happy to call out Symantec and say: Symantec, you BONEHEADS! You're an anti-virus company and you think it's a good idea to distribute sensitive information as a WINDOWS EXECUTABLE??? Symantec, you ought to be ashamed of yourselves! Is that sufficient naming and shaming? :) Perfect!! That is what I was looking for. Although from the pro-gunners out there now we will hear the software doesn't kill people, users kill people arguments claiming it's not Symantec's fault for creating a piece of software that large Data Company is abusing, but as a gun owner myself I'm pretty immune from that bankrupt line of reasoning Ted Regards, David. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
You didn't read your own code of ethics. It states if you have a bias, you disclose it. David HAD a bias in his original post and DID NOT disclose it. He DID subsequently disclose that bias AFTER I had called him on it and I commend him for it. This is the problem with codes of ethics - it's exceedingly difficult to write a code of ethnics that makes it possible to beat someone over the head who is being ethical - but is being ethical in a way that is insulting. Now, if you would like to discuss the ACTUAL ethical issue instead of trying to use your code to beat me over the head because you didn't like the tone of my response - great! Otherwise, seems to me that I'm not the only one on a high horse this morning Ted On 7/10/2014 8:56 AM, Kevin A. McGrail wrote: soapbox I believe strongly that ALL IT admins would be well guided by reading the SAGE ethics guide http://www.pccc.com/base.cgim?template=sage_code_of_ethics Can't recommend it highly enough and I think it would guide well in this gray areas on how to handle things. I didn't like that a poster with good intentions was attacked because he couldn't discuss specifics. To me, that's when I look at the credibility of the speaker to gauge the credibility of the story. Further, I can't think of a single tenant of the ethics guidelines that DFS didn't maintain in his posting AND his credibility in the anti-spam community is as excellent (as long as you ignore his commercials: https://www.youtube.com/watch?v=ccIzZS_wD6U). Anyway, there are a lot of bad actors out there that we need to focus on stopping. Attacking good actors just because we don't like their acting (and DFS' acting is horrible) just helps the bastard spammers. Please keep this in mind in the future. /soapbox Regards, KAM --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On 7/10/2014 12:31 PM, Ted Mittelstaedt wrote: You didn't read your own code of ethics. It states if you have a bias, you disclose it. David HAD a bias in his original post and DID NOT disclose it. He DID subsequently disclose that bias AFTER I had called him on it and I commend him for it. This is the problem with codes of ethics - it's exceedingly difficult to write a code of ethnics that makes it possible to beat someone over the head who is being ethical - but is being ethical in a way that is insulting. Now, if you would like to discuss the ACTUAL ethical issue instead of trying to use your code to beat me over the head because you didn't like the tone of my response - great! Otherwise, seems to me that I'm not the only one on a high horse this morning Your continued attacks on upstanding members of the anti-spam community serve little purpose. Let's focus on stopping spammers.
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Thu, 10 Jul 2014, Ted Mittelstaedt wrote: Although from the pro-gunners out there now we will hear the software doesn't kill people, users kill people arguments claiming it's not Symantec's fault Please do not go there. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The fetters imposed on liberty at home have ever been forged out of the weapons provided for defense against real, pretended, or imaginary dangers from abroad. -- James Madison, 1799 --- 10 days until the 45th anniversary of Apollo 11 landing on the Moon
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On 7/10/2014 8:26 AM, David F. Skoll wrote: On Wed, 9 Jul 2014 17:44:26 -0700 (PDT) John Hardinjhar...@impsec.org wrote: I'm not excusing their approach, but I'm saying there are a lot of sources of real-world friction that lead to suboptimal solutions like this. I expect the desire to avoid requiring installation (and maintenance!) of PGP/GPG by their (assumed non-technical) customers is the primary reason they are doing it this way. Yes. Symantec is the real culprit here. It is actively encouraging the compromising of computers with the workflow of its product. The proper approach would have been to make freely available a Symantec Encrypted Archive viewer, similar to how Adobe makes PDF readers freely available. Hold on there a second let's not throw the baby out with the bathwater. By using PGP they are using an open source encryption algorithm. If they supply their own encrypted viewer then almost certainly it would be closed source and there's no way to know if the NSA or some other malevolent agency inserted a back door - like was done with RSA. SO I think that using PGP was the right course of action here. Fundamentally the problem as i see it is lack of verification. You pointed that out yourself. A phisher can send an encrypted payload - maybe even encrypted with PGP with high encryption - that would be unbreakable without the password. Then they include the password in the phishing email. As you properly pointed out - this is a lack of verification problem, NOT a lack of encryption problem. If Symantec replaces PGP with their own custom thing now your not only introducing the lack of verification your also introducing unreliability of encryption, too. Use of PGP is actually the proper thing to do. Wouldn't the BEST proper approach would be to send out a link to a SSL webserver where the end user can download the PGP encrypted self-extractor? Now yes I know your all gonna say that a phisher can send out the same emails to their OWN SSL webserver. But, the moment law enforcement detects this is happening then the phisher's SSL certificate gets revoked, eh? After all, that's why we pay Verisign $10,000 a year for their special commerce SSL certificates, eh? And when victim of the phish clicks on the SSL link then the browser sends out alarm bells that the SSL certificate is compromised and not to go there, eh? respond carefully - any negative response and your impinging the honor of our trusted SSL system!!! ;-) Ted Symantec of all companies should know better. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Thu, 10 Jul 2014 11:43:21 -0700 Ted Mittelstaedt t...@ipinc.net wrote: SO I think that using PGP was the right course of action here. Yes, of course. But they should supply the PGP *software* using a separate delivery mechanism from the PGP-encrypted *payload*. Encouraging people to rename and run executable files they receive via email is not good. Regards, David.
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On 7/10/14, 1:43 PM, Ted Mittelstaedt t...@ipinc.net wrote: And when victim of the phish clicks on the SSL link then the browser sends out alarm bells that the SSL certificate is compromised and not to go there, eh? If we could rely on users to not click right through that SSL warning, we would be living in a much nicer world than the one we currently inhabit. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com ...Life is not a journey to the grave with the intention of arriving safely in one pretty and well-preserved piece, but to slide across the finish line broadside, thoroughly used up, worn out, leaking oil, and shouting GERONIMO!!! -- Bill McKenna
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Thu, 10 Jul 2014, Ted Mittelstaedt wrote: On 7/10/2014 8:26 AM, David F. Skoll wrote: On Wed, 9 Jul 2014 17:44:26 -0700 (PDT) John Hardinjhar...@impsec.org wrote: I'm not excusing their approach, but I'm saying there are a lot of sources of real-world friction that lead to suboptimal solutions like this. I expect the desire to avoid requiring installation (and maintenance!) of PGP/GPG by their (assumed non-technical) customers is the primary reason they are doing it this way. Yes. Symantec is the real culprit here. It is actively encouraging the compromising of computers with the workflow of its product. The proper approach would have been to make freely available a Symantec Encrypted Archive viewer, similar to how Adobe makes PDF readers freely available. By using PGP they are using an open source encryption algorithm. If they supply their own encrypted viewer then almost certainly it would be closed source and there's no way to know if the NSA or some other malevolent agency inserted a back door - like was done with RSA. Agreed. It would be better if there was an open-source PGP/GPG archive viewer application. However... SO I think that using PGP was the right course of action here. PGP is a red herring here. Fundamentally the problem as i see it is lack of verification. You pointed that out yourself. Um, no, the problem is that this Symantec tool is training people to rename and run executable email attachments. The misnamed-executable practice is to bypass security policies that dictate email messages shall not have executable attachments in order to avoid malware. As you properly pointed out - this is a lack of verification problem, NOT a lack of encryption problem. That too, but when you've trained users to not view rename and run this file with immediate suspicion, you've drastically lowered the bar for malware. If Symantec replaces PGP with their own custom thing now your not only introducing the lack of verification your also introducing unreliability of encryption, too. Use of PGP is actually the proper thing to do. Again, PGP is a red herring here. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- There is no better measure of the unthinking contempt of the environmentalist movement for civilization than their call to turn off the lights and sit in the dark.-- Sultan Knish --- 10 days until the 45th anniversary of Apollo 11 landing on the Moon
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On 7/10/2014 12:12 PM, John Hardin wrote: On Thu, 10 Jul 2014, Ted Mittelstaedt wrote: On 7/10/2014 8:26 AM, David F. Skoll wrote: On Wed, 9 Jul 2014 17:44:26 -0700 (PDT) John Hardinjhar...@impsec.org wrote: I'm not excusing their approach, but I'm saying there are a lot of sources of real-world friction that lead to suboptimal solutions like this. I expect the desire to avoid requiring installation (and maintenance!) of PGP/GPG by their (assumed non-technical) customers is the primary reason they are doing it this way. Yes. Symantec is the real culprit here. It is actively encouraging the compromising of computers with the workflow of its product. The proper approach would have been to make freely available a Symantec Encrypted Archive viewer, similar to how Adobe makes PDF readers freely available. By using PGP they are using an open source encryption algorithm. If they supply their own encrypted viewer then almost certainly it would be closed source and there's no way to know if the NSA or some other malevolent agency inserted a back door - like was done with RSA. Agreed. It would be better if there was an open-source PGP/GPG archive viewer application. However... SO I think that using PGP was the right course of action here. PGP is a red herring here. Fundamentally the problem as i see it is lack of verification. You pointed that out yourself. Um, no, the problem is that this Symantec tool is training people to rename and run executable email attachments. The misnamed-executable practice is to bypass security policies that dictate email messages shall not have executable attachments in order to avoid malware. As you properly pointed out - this is a lack of verification problem, NOT a lack of encryption problem. That too, but when you've trained users to not view rename and run this file with immediate suspicion, you've drastically lowered the bar for malware. Oh we are already so far down the path to evil under Windows that's nothing. Under Windows, users don't think of it as rename and run they thing of it as rename and open Microsoft has conflated the notion of running an executable with the notion of opening a file to edit or view or read. Hiding the extensions by default is like the icing on the cake - it's like Microsoft built Windows to be hacked. If your going to tell users don't open an attachment if you have to rename it then you are IMPLYING that if they DON'T have to rename the attachment then the attachment is safe, just save it and open it. The bar has already been drastically lowered by the Windows paradigm as Microsoft has defined it. And if that wasn't bad enough they introduced another paradigm in Windows 8 of applets and such, giving the evildoers even more hidey-holes in the OS to run malware. Fundamentally I think the problem is with attachments. An email attachment should be regarded as an anachronism. Users should not be emailing each other attachments they should be emailing each other links to attachments that exist on servers, and the SSL paradigm should be re-architected to do more than just let users click though a simple warning message. 30 years ago when a lot of email was carried by UUCP then an attachment made sense. But today in a connected Internet - absolutely not. Ted If Symantec replaces PGP with their own custom thing now your not only introducing the lack of verification your also introducing unreliability of encryption, too. Use of PGP is actually the proper thing to do. Again, PGP is a red herring here. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Thu, 10 Jul 2014 12:25:50 -0700 Ted Mittelstaedt t...@ipinc.net wrote: Fundamentally I think the problem is with attachments. No, the problem is not with attachments. An attachment actually included in an email is no more dangerous than an attachment downloaded via a link. Email attachments are far too convenient; no-one's going to give them up. The problem is that Windows encodes metadata such as this is executable in the filename, making it trivial for attackers to get their payloads to run. The simple act of renaming a file in Windows can be the equivalent of chmod a+x in UNIX. A Windows user probably does not realize that renaming a file can have dire consequences, whereas even a casual UNIX user might pause if asked to chmod a file after saving it. (Note well this article: http://lwn.net/Articles/178409/ which points out that some UNIX desktop environments are repeating the mistake made by Windows.) Regards, David.
Re: Smtp auth and trusted_networks
Il 2014-07-10 17:36 Nick I ha scritto: Hi In the following example our mx received message with ESMTPSA from 1.1.1.1 and that ip detected as trusted. Our trusted_networks list do not have this ip configured. I need to run rbl check against 1.1.1.1. Is there any settings to not add authenticated host to trusted hosts ? We use SpamAssassin version 3.3.1. You case is exactly what the patch in bug#6430 (https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430) attempts to cover. Unfortunately, that patch never went into any SA version, so you have to apply it by yourself if you really need to let your MX act as an MSA in case of authenticated submissions. If you use amavis, there is another option: move mail submission to another instance of your smtp daemon and configure it to submit received (and authenticated) message to an amavis channel you prepared for outgoing mail. Regards, Giampaolo Jul 10 14:27:34.275 [9780] dbg: received-header: parsed as [ ip=1.1.1.1 rdns=sender1.domain.com [1] helo=mail.domain.com [2] by=mx.domain.com [3] ident= envfrom= intl=0 id= auth=ESMTPSA msa=0 ] Jul 10 14:27:34.275 [9780] dbg: received-header: relay 1.1.1.1 trusted? yes internal? yes msa? no Jul 10 14:27:34.277 [9780] dbg: received-header: parsed as [ ip=2.2.2.2 rdns= helo= by=mail.domain.com [2] ident= envfrom= intl=0 id= auth= msa=0 ] Jul 10 14:27:34.277 [9780] dbg: received-header: relay 2.2.2.2 trusted? no internal? no msa? no Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-Trusted: [ ip=1.1.1.1 rdns=sender1.domain.com [1] helo=mail.domain.com [2] by=mx.domain.com [3] ident= envfrom= intl=1 id= auth=ESMTPSA msa=0 ] Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=2.2.2.2 rdns= helo= by=mail.domain.com [2] ident= envfrom= intl=0 id= auth= msa=0 ] Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-Internal: [ ip=1.1.1.1 rdns=sender1.domain.com [1] helo=mail.domain.com [2] by=mx.domain.com [3] ident= envfrom= intl=1 id= auth=ESMTPSA msa=0 ] Jul 10 14:27:34.277 [9780] dbg: metadata: X-Spam-Relays-External: [ ip=2.2.2.2 rdns= helo= by=mail.domain.com [2] ident= envfrom= intl=0 id= auth= msa=0 ] Thanks. Links: -- [1] http://sender1.domain.com [2] http://mail.domain.com [3] http://mx.domain.com
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On 7/10/2014 at 3:35 PM, David F. Skoll d...@roaringpenguin.com wrote: On Thu, 10 Jul 2014 12:25:50 -0700 Ted Mittelstaedt t...@ipinc.net wrote: Fundamentally I think the problem is with attachments. No, the problem is not with attachments. An attachment actually included in an email is no more dangerous than an attachment downloaded via a link. Email attachments are far too convenient; no-one's going to give them up. The problem is that Windows encodes metadata such as this is executable in the filename, making it trivial for attackers to get their payloads to run. The simple act of renaming a file in Windows can be the equivalent of chmod a+x in UNIX. A Windows user probably does not realize that renaming a file can have dire consequences, whereas even a casual UNIX user might pause if asked to chmod a file after saving it. (Note well this article: http://lwn.net/Articles/178409/ which points out that some UNIX desktop environments are repeating the mistake made by Windows.) Regards, David. Actually, that goes back to the days of XX-DOS, CP . . err, umm . . . Lordy, now I do feel old. joe a.
