DOJ claims CryptoLocker 100% ineffective now - was Re: Ideas sought for blocking new variant of cryptolocker
FYI http://www.crn.com/news/security/300073406/doj-cryptolocker-trojan-is-now-out-of-commission.htm?cid=nl_sec#
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Jul 10, 2014, at 5:17 PM, Joe Acquisto-j4 j...@j4computers.com wrote: 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. Long live Multics and ITS! -Philip
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.
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: 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.
Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Wed, 09 Jul 2014 05:44:34 +0200 Karsten Bräckelmann guent...@rudersport.de wrote: If you deliberately try to sneak past sensible security measures, you should not be surprised to be blocked. The attempt by an honest user to disguise any $file (he did it on purpose, so he knows there's issues with that) is in no way better than a dis-honest user disguising a file. Since implementing this rule, I have been *shocked* to discover that a large data processing company (name hidden to protect the guilty) sends out information about credit-card processing in the form of obfuscated Microsoft Windows executable files!!! (They're renamed to end in .ex instead of .exe) I tried running one of these files inside Wine. It's a PGP Self Decrypting Archive that asks for a passphrase. The mind boggles! *THIS* is the state of Windows security best practices? Regards, David.
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
First of all why do people insist on hiding names of companies that do stuff like this? It just makes it look like your manufacturing an event that doesn't exist, it destroys your credibility. Secondly, if you think that this is an example of badness on Windows security best practices you simply have not seen Windows deployed in 90% of production networks out there. This is NOTHING compared to S.O.P. on most Windows setups. Imagine MS-DOS/LanManager network security model of 30 years ago. Now imagine Windows networks today in the vast majority of production installs. NO EFFING DIFFERENCE! Ted PS: Naturally there will be some Windows-kool-aid drinker who is going to angrily reply to this post claiming Windows is secure if people just followed Microsoft's directions. On 7/9/2014 11:06 AM, David F. Skoll wrote: On Wed, 09 Jul 2014 05:44:34 +0200 Karsten Bräckelmannguent...@rudersport.de wrote: If you deliberately try to sneak past sensible security measures, you should not be surprised to be blocked. The attempt by an honest user to disguise any $file (he did it on purpose, so he knows there's issues with that) is in no way better than a dis-honest user disguising a file. Since implementing this rule, I have been *shocked* to discover that a large data processing company (name hidden to protect the guilty) sends out information about credit-card processing in the form of obfuscated Microsoft Windows executable files!!! (They're renamed to end in .ex instead of .exe) I tried running one of these files inside Wine. It's a PGP Self Decrypting Archive that asks for a passphrase. The mind boggles! *THIS* is the state of Windows security best practices? 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)
On Wed, Jul 9, 2014 at 2:23 PM, Ted Mittelstaedt t...@ipinc.net wrote: First of all why do people insist on hiding names of companies that do stuff like this? It just makes it look like your manufacturing an event that doesn't exist, it destroys your credibility. You mean besides NDAs and policies that at the very least might cause those people to be fired by their employers? If you ever went to a defcon open presentation, they do their best not to divulge the names of involved parties. Secondly, if you think that this is an example of badness on Windows security best practices you simply have not seen Windows deployed in 90% of production networks out there. This is NOTHING compared to S.O.P. on most Windows setups. Imagine MS-DOS/LanManager network security model of 30 years ago. Now imagine Windows networks today in the vast majority of production installs. NO EFFING DIFFERENCE! Ted PS: Naturally there will be some Windows-kool-aid drinker who is going to angrily reply to this post claiming Windows is secure if people just followed Microsoft's directions. On 7/9/2014 11:06 AM, David F. Skoll wrote: On Wed, 09 Jul 2014 05:44:34 +0200 Karsten Bräckelmannguent...@rudersport.de wrote: If you deliberately try to sneak past sensible security measures, you should not be surprised to be blocked. The attempt by an honest user to disguise any $file (he did it on purpose, so he knows there's issues with that) is in no way better than a dis-honest user disguising a file. Since implementing this rule, I have been *shocked* to discover that a large data processing company (name hidden to protect the guilty) sends out information about credit-card processing in the form of obfuscated Microsoft Windows executable files!!! (They're renamed to end in .ex instead of .exe) I tried running one of these files inside Wine. It's a PGP Self Decrypting Archive that asks for a passphrase. The mind boggles! *THIS* is the state of Windows security best practices? 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)
On 7/9/2014 11:37 AM, Mauricio Tavares wrote: On Wed, Jul 9, 2014 at 2:23 PM, Ted Mittelstaedtt...@ipinc.net wrote: First of all why do people insist on hiding names of companies that do stuff like this? It just makes it look like your manufacturing an event that doesn't exist, it destroys your credibility. You mean besides NDAs and policies that at the very least might cause those people to be fired by their employers? If you ever went to a defcon open presentation, they do their best not to divulge the names of involved parties. Correct, but THEY ARE SAYING that they are under NDA and can't talk about it. They readily admit they are profiting off the evildoing of their customers or whatever, and quite often they have worked relentlessly within their organizations to change the SOP, and are known a gadflys, and their employer is well aware of their views. They speak at DEFCON because they hope that if enough people are educated to bad security practices that sooner or later an outside force will either convince their employer they were right all along, or if there's enough agreement they are correct by 3rd parties, their employer may be convinced. 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? He did not say this large DP company was his meal ticket. Are YOU saying that this is his meal ticket? But there is a larger issue here that I will address - this insistence of cowardly hiding behind NDA to protect rule breakers. David DID not say he did that - YOU are saying he did - and YOU appear TO BE ARGUING IN FAVOR OF DOING IT. What it boils down to is who are your sympathies for? The people breaking the rules or the thousands of other people who are going to find out after signing up with the rule breakers that they use questionable and unsafe business practices? Now, in MY opinion there are only TWO ways to handle organizations like large data processing company The first is to work within the system - if for example Large DP Company _is_ a customer of David's he goes to them, explains the danger, recommends they correct it. Then when he posts here he says I was shocked to discover and my customer and I are working to correct it or some such. I have plenty of respect for that, and posting that encourages other IT people to do the same. The second way is to work outside of the system. You start by sending an anonymous letter to the large DP company outlining the security issue and giving them 3 months to correct it or you will go to the press. If they haven't corrected it in 3 months you anonymously post details of what they are doing to every security blog and mailing list you can find. In that case, you NEVER, EVER breath a word of the security problem to anyone. No one in the company, no one outside of the company. You make absolutely sure there's no possible way it can be traced back to you because trust me they are gonna try like hell to find whoever ratted them out. I presume David IS NOT doing that or we wouldn't be having this discussion. If you cannot do either of those options THEN GET THE HELL OUT OF HIGH TECH WE DON'T NEED YOU. You are an administrator. YOU ARE PAID BY CLUELESS USERS TO PROTECT THEM AND THEIR DATA, DAMMIT. They trust you. When you walk on by something like this business David posted about, and DO NOTHING, you are breaking their trust. THIS is my beef with David's post. Merely posting hey this is what someone is doing is just walking on by, kicking the can down the road, doing nothing. THIS is what destroys your credibility. Users don't understand the dynamics of it. They aren't qualified to advise you no matter what they tell you and what you think - if they were, they wouldn't be paying you to do the job. Defending the people like Large DP Company is morally wrong and bankrupt. Mauricio, you need to seriously think about what your saying. Would you want the doctor of your child to say nothing when you tell him your a 2 pack a day smoker in your home? Well probably you would - but the doctor's responsibility is to the helpless child, not to you. The IT admin's responsibility is to the helpless users not to a rule-breaking large data processing company. Ted Secondly, if you think that this is an example of badness on Windows security best practices you simply have not seen Windows deployed in 90% of production networks out there. This is NOTHING compared to S.O.P. on most Windows setups. Imagine MS-DOS/LanManager network security model of 30 years ago. Now imagine Windows networks today in the vast majority of production installs. NO EFFING DIFFERENCE! Ted PS: Naturally there will be some Windows-kool-aid drinker who is going to angrily reply to this post claiming Windows is secure if people just followed Microsoft's directions. On 7/9/2014 11:06 AM, David F. Skoll wrote:
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Wed, 09 Jul 2014 14:44:27 -0700 Ted Mittelstaedt t...@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? :) Regards, David.
Re: Obfuscated Windows excecutables (was Re: Ideas sought for blocking new variant of cryptolocker)
On Wed, 9 Jul 2014, Ted Mittelstaedt wrote: You are an administrator. YOU ARE PAID BY CLUELESS USERS TO PROTECT THEM AND THEIR DATA, DAMMIT. recovered_monk ...unless it involves some actual, you know, effort on their part. /recovered_monk And in this instance, Large DP Company *is* doing something proactive to protect the data they are providing to their customers - they are putting it in a strongly-encrypted wrapper. That in doing so they are training their customers to behave in a manner that makes them vulnerable to malware delivered by social engineering *may* not be something they would worry enough about to actually spend money and time on fixing, especially if fixing it involves them forcing their costomers to install PGP or GPG in order to access a non-self-extracting encrypted archive. That won't be as visible a security feature as the PGP archive itself is, and it's not, strictly speaking, a hole in *their* security practices. 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. -- 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 --- Drugs will always be around. Politicians are therefore making an active decision to distribute them through violent gangs. --Twitter --- 11 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 Wed, Jul 9, 2014 at 5:44 PM, Ted Mittelstaedt t...@ipinc.net wrote: On 7/9/2014 11:37 AM, Mauricio Tavares wrote: On Wed, Jul 9, 2014 at 2:23 PM, Ted Mittelstaedtt...@ipinc.net wrote: First of all why do people insist on hiding names of companies that do stuff like this? It just makes it look like your manufacturing an event that doesn't exist, it destroys your credibility. You mean besides NDAs and policies that at the very least might cause those people to be fired by their employers? If you ever went to a defcon open presentation, they do their best not to divulge the names of involved parties. Correct, but THEY ARE SAYING that they are under NDA and can't talk about it. They readily admit they are profiting off the evildoing of their customers or whatever, and quite often they have worked relentlessly within their organizations to change the SOP, and are known a gadflys, and their employer is well aware of their views. They speak at DEFCON because they hope that if enough people are educated to bad security practices that sooner or later an outside force will either convince their employer they were right all along, or if there's enough agreement they are correct by 3rd parties, their employer may be convinced. 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? He did not say this large DP company was his meal ticket. Are YOU saying that this is his meal ticket? But there is a larger issue here that I will address - this insistence of cowardly hiding behind NDA to protect rule breakers. David DID not say he did that - YOU are saying he did - and YOU appear TO BE ARGUING IN FAVOR OF DOING IT. What it boils down to is who are your sympathies for? The people breaking the rules or the thousands of other people who are going to find out after signing up with the rule breakers that they use questionable and unsafe business practices? Now, in MY opinion there are only TWO ways to handle organizations like large data processing company The first is to work within the system - if for example Large DP Company _is_ a customer of David's he goes to them, explains the danger, recommends they correct it. Then when he posts here he says I was shocked to discover and my customer and I are working to correct it or some such. I have plenty of respect for that, and posting that encourages other IT people to do the same. The second way is to work outside of the system. You start by sending an anonymous letter to the large DP company outlining the security issue and giving them 3 months to correct it or you will go to the press. If they haven't corrected it in 3 months you anonymously post details of what they are doing to every security blog and mailing list you can find. In that case, you NEVER, EVER breath a word of the security problem to anyone. No one in the company, no one outside of the company. You make absolutely sure there's no possible way it can be traced back to you because trust me they are gonna try like hell to find whoever ratted them out. I presume David IS NOT doing that or we wouldn't be having this discussion. If you cannot do either of those options THEN GET THE HELL OUT OF HIGH TECH WE DON'T NEED YOU. You are an administrator. YOU ARE PAID BY CLUELESS USERS TO PROTECT THEM AND THEIR DATA, DAMMIT. They trust you. When you walk on by something like this business David posted about, and DO NOTHING, you are breaking their trust. THIS is my beef with David's post. Merely posting hey this is what someone is doing is just walking on by, kicking the can down the road, doing nothing. THIS is what destroys your credibility. Users don't understand the dynamics of it. They aren't qualified to advise you no matter what they tell you and what you think - if they were, they wouldn't be paying you to do the job. Defending the people like Large DP Company is morally wrong and bankrupt. Mauricio, you need to seriously think about what your saying. Would you want the doctor of your child to say nothing when you tell him your a 2 pack a day smoker in your home? Well probably you would - but the doctor's responsibility is to the helpless child, not to you. The IT admin's responsibility is to the helpless users not to a rule-breaking large data processing company. You are putting words in my mouth. Since you assumed to know what I am thinking and spent a lot of time writing those brilliant paragraphs to expand on that, I think it would be unfair of me to say anything else. And besides, I do not like horses, be them high or low. Never did. Ted Secondly, if you think that this is an example of badness on Windows security best practices you simply have not seen Windows deployed in 90% of production networks out there. This is NOTHING compared to S.O.P. on most Windows setups. Imagine
Re: Ideas sought for blocking new variant of cryptolocker
On 7/7/2014 5:34 PM, David F. Skoll wrote:
Replying to myself...
full MSDOGEXE /\n\nTV[opqr]/
Seems to work. :)
So this sounds like you are searching the entire email for this string
which just sounds inefficient especially if they use some big attachments.
Since I'm guessing you are using MD, wouldn't something like this be
better? Untested, but based on some code for looking for rar files
masquerading as zip files:
sub filter_bad_filename {
# Check for hidden executables
unless (re_match($entity, '\.exe$') ) {
my $bh = $entity-bodyhandle();
if (defined($bh)) {
my $path = $bh-path();
if (defined($path)) {
if(check_for_exe_signature($path,
$entity-head-recommended_filename())) {
action_add_header(X-Suspected-Hidden-EXE-Attachment,True);
}
}
}
}
...
}
sub check_for_exe_signature {
my ($path, $recommended_filename) = @_;
my ($filehandle, $header);
#OPEN THE FILE, GRAB THE HEADER AND TEST
$filehandle = new IO::File( $path);
if (defined $filehandle) {
read($filehandle,$header,2);
close ($filehandle);
if (uc($header) eq MZ) {
return 1;
}
return 0;
}
NOTE: I would actually use an action_add_header_immediately routine that
modifies the message that's passed to SA
But then add rules like this that use the header and other items to make
a poison pill score possible
body__KAM_CRYPTO1 /open the attached document/i
body__KAM_CRYPTO2 /add an extension/i
header __KAM_CRYPTO3 X-Suspected-Hidden-EXE-Attachment =~ /True/
meta KAM_CRYPTO (__KAM_CRYPTO1 + __KAM_CRYPTO2 + __KAM_CRYPTO3 = 3)
describe KAM_CRYPTO Likely CryptoLocker Spam with Hidden EXE Malware
score KAM_CRYPTO 8.0
regards,
KAM
Re: Ideas sought for blocking new variant of cryptolocker
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.
Since I'm guessing you are using MD, wouldn't something like this be
better? Untested, but based on some code for looking for rar files
masquerading as zip files:
Yes, looking at file signatures (à la file(1)) would be more robust.
if (uc($header) eq MZ) {
You don't want the uc(); that could lead to false-positives, but yes,
the idea is correct.
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. :)
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.
Regards,
David.
Re: Ideas sought for blocking new variant of cryptolocker
On Tue, 2014-07-08 at 22:41 -0400, David F. Skoll wrote:
On Tue, 08 Jul 2014 21:03:35 -0400, Kevin A. McGrail 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.
The regex is dead simple, indeed. Even as full rule, it should perform
better than most complex body rules, since it is a very short pattern
with no backtracking.
For the benefit of easier discussion, the regex /\n\nTV[opqr]/ can be
translated to an empty line, that hopefully matches the gap at the
beginning of a MIME attachment, with some certain base64 encoded bytes.
That last part should better be referred to as a base64 encoded DOS MZ
executable -- or simply .exe file. A base64 encoded /^TV[opqr]/ is
identical to /^MZ/ decoded.
Which of course means, that applies to more than just a new variant of
some malware. Though generally targeting any MS executable dropped as a
mail attachment is not a bad idea...
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. :)
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,
That should be solvable by adding stricter border to be beginning of the
regex. Since I don't know what your samples use in particular, here is a
quick first idea.
/(: base64|)\n\nTV[opqr]/
The idea is to base the regex at a char not part of the base64 set,
focusing on the Content-Transfer-Encoding and Content-Disposition MIME
headers. Whatever is the last one used.
and one sort-of-false-positive that was a DLL renamed to .DAT to sneak
past filename extension blocks, but wasn't otherwise malicious.
If you deliberately try to sneak past sensible security measures, you
should not be surprised to be blocked. The attempt by an honest user to
disguise any $file (he did it on purpose, so he knows there's issues
with that) is in no way better than a dis-honest user disguising a file.
--
char *t=\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Ideas sought for blocking new variant of cryptolocker
So, the inevitable had to happen. The cryptolocker folks are getting around extension blocking with this: == PLEASE NOTE! In case you are not able to open the attached document, please save it to your computer and manually add an extension SCR (characters after dot). See the sample name: Ivoice640.SCR Then try again to read the file! == And, naturally, some *#$*% users fall for it. A base64-encoded MS-DOS executable always matches this regex: ^TV[opqr] but we only want to match that at the very beginning of the B64-encoded body. Any ideas how to do this with a full rule? Would: full MSDOGEXE /\n\nTV[opqr]/ do the trick? Regards, David.
Re: Ideas sought for blocking new variant of cryptolocker
Replying to myself... full MSDOGEXE /\n\nTV[opqr]/ Seems to work. :) Regards, David.
