Signature Blocks (Part 2)
It seems I am not alone in this pet peeve. I received enough email to do an "Email etiquette" diary. I'll save that for later.
Here's the general consensus:
1. 4 lines
<name>
<Title>
<company>
<phone number or web address>
2. Quote are okay as long as:
a) It's kept to a minimum
b) it's kept to PERSONAL email only
c) It's does not have a racial or religious theme. (duh?)
d) plain text
3. Plain text
4. Plaxo and LinkedIn are bad.
5. jpg's/gif's/png's are bad. (no HTML!)
6. Apparently in some parts of the .eu, you HAVE to put stuff in your Sig block like, company name, web site, email, for disclaimer purposes.
http://www.out-law.com/page-431
7. CERTS are okay, but as one reader pointed out, "Why tell people what you don't have?"
8. Addresses are to be kept out, if I want your address, I'll ask you for it. Email addresses should also be kept out, since it's going to be in your Reply-To:
9. The only thing worse than big long Sig blocks is OOOR. (Out of Office Replies)
10. Last but DEFINITELY not least. The Disclaimers that say stuff like:
"IF YOU ARE NOT THE INTENDED RECIPIENT OF THIS MESSAGE YOU MUST DELETE AND NOTIFY THE SENDER BLAH BLAH BLAH BLAH BLAH, OR YOU CAN BE FINED 500 BUCKS BLAH BLAH BLAH, INSERT 20 MORE LINES OF STUFF HERE BLAH BLAH BLAH BLAH".
Has anyone ever seen one of these enforced? Do you have a link to case law? I'd like to make fun of it.
Bottom line from the group?
Keep it short, plain text, and simple. HTML, logos, quotes, disclaimers, etc.. are not necessary and do nothing but keep short email replies long.
Oh, and for those email clients that don't recognize that "--" is the start of the Sig block (Outlook, Lotus), please, fix your stuff. (from a reader).
Oh, and if you are replying to a reply.. trim your Sig.
Thank you all for writing in, hopefully I've influenced enough of you to take a look at your sig lines and trim them up. They are getting out of control.
--
Joel Esler
http://handlers.sans.org/jesler
Here's the general consensus:
1. 4 lines
<name>
<Title>
<company>
<phone number or web address>
2. Quote are okay as long as:
a) It's kept to a minimum
b) it's kept to PERSONAL email only
c) It's does not have a racial or religious theme. (duh?)
d) plain text
3. Plain text
4. Plaxo and LinkedIn are bad.
5. jpg's/gif's/png's are bad. (no HTML!)
6. Apparently in some parts of the .eu, you HAVE to put stuff in your Sig block like, company name, web site, email, for disclaimer purposes.
http://www.out-law.com/page-431
7. CERTS are okay, but as one reader pointed out, "Why tell people what you don't have?"
8. Addresses are to be kept out, if I want your address, I'll ask you for it. Email addresses should also be kept out, since it's going to be in your Reply-To:
9. The only thing worse than big long Sig blocks is OOOR. (Out of Office Replies)
10. Last but DEFINITELY not least. The Disclaimers that say stuff like:
"IF YOU ARE NOT THE INTENDED RECIPIENT OF THIS MESSAGE YOU MUST DELETE AND NOTIFY THE SENDER BLAH BLAH BLAH BLAH BLAH, OR YOU CAN BE FINED 500 BUCKS BLAH BLAH BLAH, INSERT 20 MORE LINES OF STUFF HERE BLAH BLAH BLAH BLAH".
Has anyone ever seen one of these enforced? Do you have a link to case law? I'd like to make fun of it.
Bottom line from the group?
Keep it short, plain text, and simple. HTML, logos, quotes, disclaimers, etc.. are not necessary and do nothing but keep short email replies long.
Oh, and for those email clients that don't recognize that "--" is the start of the Sig block (Outlook, Lotus), please, fix your stuff. (from a reader).
Oh, and if you are replying to a reply.. trim your Sig.
Thank you all for writing in, hopefully I've influenced enough of you to take a look at your sig lines and trim them up. They are getting out of control.
--
Joel Esler
http://handlers.sans.org/jesler
Keywords:
0 comment(s)
Google Counter ... isn't
Those of you who have seen the "google-analytics" URL in your logs before might be tempted to assume (as I was) that google-counter[dot]com is just another incarnation of the same. I even at first discounted that my anti-virus complained about "obfuscated javascript", thinking that Google must have cooked up some really complicated Ajax mess again that misled my AV to a false positive.
But no. On a second look, the site tries to download an ANI cursor exploit. And wait - there is lots more IFRAMES. Ouch! This definitely ain't Google!
z-014-1.php contains an obfuscated exploit for MS06-014
z-014-3.php contains another exploit for MS06-014
z-create-o.php contains the IE CreateObject exploit (as seen on Metasploit TV)
z-cs-an.php is an obfuscated exploit for MS07-017
z-java1.php is an oldie, Java-ByteVerify exploit
All of these try to download and run a file "down.exe" off the same site, which in turn downloads and runs a Browser Helper Object (BHO) off someplace else. The BHO is a key logger / banking trojan. We have decoded the configuration file that tells the trojan what to do - you can look at the file under http://handlers.sans.org/dwesemann/decoded-bho-helper.txt . Yes, lots of banks... Thanks to fellow handlers Lorna and Pedro for help with the analysis.
Caution: The google-counter site is still live at the time of writing. Sink yourself at your own risk.
But no. On a second look, the site tries to download an ANI cursor exploit. And wait - there is lots more IFRAMES. Ouch! This definitely ain't Google!
z-014-1.php contains an obfuscated exploit for MS06-014
z-014-3.php contains another exploit for MS06-014
z-create-o.php contains the IE CreateObject exploit (as seen on Metasploit TV)
z-cs-an.php is an obfuscated exploit for MS07-017
z-java1.php is an oldie, Java-ByteVerify exploit
All of these try to download and run a file "down.exe" off the same site, which in turn downloads and runs a Browser Helper Object (BHO) off someplace else. The BHO is a key logger / banking trojan. We have decoded the configuration file that tells the trojan what to do - you can look at the file under http://handlers.sans.org/dwesemann/decoded-bho-helper.txt . Yes, lots of banks... Thanks to fellow handlers Lorna and Pedro for help with the analysis.
Caution: The google-counter site is still live at the time of writing. Sink yourself at your own risk.
Keywords:
0 comment(s)
BBB goes IRS
Just a quick heads-up - the Better Business Bureau (BBB) malware we've reported on earlier seems to have mutated into one that claims to come form the Internal Revenue Service (IRS). Still using RTF attachments with embedded malware as vector, though.
Keywords:
0 comment(s)
Virus detection - vector vs. payload
In a previous diary, we've written about the surprising prevalence of those exploit "iframes" which in the end download a file called "funny.php" off a server in Russia, Panama or Ukraine, etc. "funny.php" is an EXE sailing in disguise, and usually a
password stealing spyware of the "Bancos" family. The file changes frequently and cleverly enough to keep the majority of anti virus products perpetually in the dark. The only two things that tend to "save the day" if a user happens across one
of these IFRAMEs is that firstly, the vulnerabilities exploited are pretty old (and patched). Secondly, the anti-virus detection for the exploit iframe (the infection "vector") is significantly better than detection for the spyware (the "payload").
Some anti virus products apparently trigger on the "obfuscation" of the exploit, (it is encoded Javascript), risking a higher false positive rate by doing so, but also making it less likely that a tiny change in the exploit code renders the signature useless. Others apparently trigger on the exploit itself. The obfuscation and exploits used have been pretty much the same for the past three months, so one would reasonably expect anti virus coverage to be well in place.
When today a user of mine "found" another one of these funny.phps, I decided to pass both the vector and payload files through Virustotal to see who was up to snuff:
Virustotal results for the obfuscated exploit file ("forum.php")
Virustotal results for the payload ("funny.php")
The results speak for themselves, with quite a few prominent vendors competing for the coveted "Sees No Virus" award :). I'm constantly amazed at how anti-virus ever could grow into a multi-billion dollar industry.
password stealing spyware of the "Bancos" family. The file changes frequently and cleverly enough to keep the majority of anti virus products perpetually in the dark. The only two things that tend to "save the day" if a user happens across one
of these IFRAMEs is that firstly, the vulnerabilities exploited are pretty old (and patched). Secondly, the anti-virus detection for the exploit iframe (the infection "vector") is significantly better than detection for the spyware (the "payload").
Some anti virus products apparently trigger on the "obfuscation" of the exploit, (it is encoded Javascript), risking a higher false positive rate by doing so, but also making it less likely that a tiny change in the exploit code renders the signature useless. Others apparently trigger on the exploit itself. The obfuscation and exploits used have been pretty much the same for the past three months, so one would reasonably expect anti virus coverage to be well in place.
When today a user of mine "found" another one of these funny.phps, I decided to pass both the vector and payload files through Virustotal to see who was up to snuff:
Virustotal results for the obfuscated exploit file ("forum.php")
Virustotal results for the payload ("funny.php")
The results speak for themselves, with quite a few prominent vendors competing for the coveted "Sees No Virus" award :). I'm constantly amazed at how anti-virus ever could grow into a multi-billion dollar industry.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments