Cisco 7920 Wireless IP Phone
Alex Tilley had an interesting observation about the 7920 phone after reading this diary entry. If anyone else is observing this same thing or has an explanation, please let us know:
"If I hold my mobile (cell phone) (a motorola v525) up to the screen while the mobile has a connected call, the cisco voip phone reboots.
This happens with any mobile phone and a few other cisco 7940's we have around here, but I tried it on the same model cisco at another office and it didn't reboot"
Fellow handler Donald Smith passed along the following information on two new vulnerabilities. Thanks Don!!
http://www.cisco.com/warp/public/707/cisco-sa-20051116-7920.shtml
There are two vulnerabilities relating to the Cisco 7920 Wireless IP
Phone:
- The first vulnerability is an SNMP service with fixed community
strings that allow remote users to read, write, and erase the
configuration of an affected device
- The second vulnerability is an open VxWorks Remote Debugger on UDP
port 17185 that may allow an unauthenticated remote user to access
debugging information or cause a denial of service
IP phones that have default passwords and unauthenticated managment
ports. KEWL:)
"If I hold my mobile (cell phone) (a motorola v525) up to the screen while the mobile has a connected call, the cisco voip phone reboots.
This happens with any mobile phone and a few other cisco 7940's we have around here, but I tried it on the same model cisco at another office and it didn't reboot"
Fellow handler Donald Smith passed along the following information on two new vulnerabilities. Thanks Don!!
http://www.cisco.com/warp/public/707/cisco-sa-20051116-7920.shtml
There are two vulnerabilities relating to the Cisco 7920 Wireless IP
Phone:
- The first vulnerability is an SNMP service with fixed community
strings that allow remote users to read, write, and erase the
configuration of an affected device
- The second vulnerability is an open VxWorks Remote Debugger on UDP
port 17185 that may allow an unauthenticated remote user to access
debugging information or cause a denial of service
IP phones that have default passwords and unauthenticated managment
ports. KEWL:)
Keywords:
0 comment(s)
Mail Call Time: More Sony Info and Snort Signatures
Sony is in the still spotlight with their latest endevours. Here is some more info and some Snort rules to try.
Here is an interesting tidbit from Juha-Matti Laurio:
It seems that SecurityFocus database has assigned Sony BMG's DRM uninstallation utility from First 4 as software vulnerability at their new BID 15430:
http://www.securityfocus.com
"The CodeSupport package can be told to download, and then execute arbitrary content from remote Web sites. As it fails to verify that the source of the remote content is from a trusted source, attackers may utilize it to download and execute malicious code from arbitrary sources, facilitating the remote compromise of targeted computers."
Two interesting articles (another is blog entry of BID's reporter) at
http://www.securityfocus.com
and
http://www.freedom-to-tinker
(including demonstration too) available too.
Matt Jonkman let us know that Bleeding Snort had the following signatures available. Thanks everyone for your hard work at Bleeding Snort!
Here is an interesting tidbit from Juha-Matti Laurio:
It seems that SecurityFocus database has assigned Sony BMG's DRM uninstallation utility from First 4 as software vulnerability at their new BID 15430:
http://www.securityfocus.com
"The CodeSupport package can be told to download, and then execute arbitrary content from remote Web sites. As it fails to verify that the source of the remote content is from a trusted source, attackers may utilize it to download and execute malicious code from arbitrary sources, facilitating the remote compromise of targeted computers."
Two interesting articles (another is blog entry of BID's reporter) at
http://www.securityfocus.com
and
http://www.freedom-to-tinker
(including demonstration too) available too.
Matt Jonkman let us know that Bleeding Snort had the following signatures available. Thanks everyone for your hard work at Bleeding Snort!
#By Michael Ligh
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
(msg: "BLEEDING-EDGE MALWARE Sony DRM Reporting 1";
flow: to_server,established; uricontent:"/toc/Connect?type=redirect"; nocase;
uricontent:"&uId="; nocase; classtype:trojan-activity;
reference:url,www.sysinternals.com/blog/2005/11/more-on-sony-dangerous-decloaking.html;
sid:2002675; rev:3;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
(msg: "BLEEDING-EDGE MALWARE Sony DRM Reporting 2";
flow: to_server,established; content:"sonymusic.com"; nocase;
pcre:"User-Agent:[^
]+SecureNet[^
]+Xtra/i"; classtype:trojan-activity;
reference:url,www.sysinternals.com/blog/2005/11/more-on-sony-dangerous-decloaking.html;
sid:2002674; rev:2;)
#by Blake Hartstein
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
(msg:"BLEEDING-EDGE Malware Sony DRM Related --
CodeSupport ActiveX Attempt"; flow:from_server,established; content:"CLSID"; nocase;
content:"4EA7C4C5-C5C0-4F5C-A008-8293505F71CC"; nocase; distance:0;
reference:url,www.frsirt.com/english/advisories/2005/2454;
reference:url,www.hack.fi/~muzzy/sony-drm/; classtype:web-application-attack;
sid:2002679; rev:3;)
Link to rules on "Bleeding Snort"
Keywords:
0 comment(s)
Strange phishing/spam e-mails
Here is the latest update on the following Scenerio. Thanks to fellow handler Bojan for your great analysis and work on this one!
At the moment I am pretty sure that spammers
were using this "trick" to make users solve CAPTCHA graphics for them. In
this case, I believe they were trying to open new accounts on free webmail
www.pochta.ru (that's a legitimate Russian webmail). When you try to open a
new account on that site (http://www.pochta.ru/regform
presented with a CAPTCHA picture and it's link will be exactly
http://www12.pochta.ru/rnd_img
example).
Now, pochta.ru uses sid parameter to identify which CAPTCHA image will be
presented. The image itself will be changed (colors and number positions),
but the string that the user has to enter will remain the same. To test this
just enter the URL above in your browser and refresh couple of times - you
will see how it changes.
Therefore, spammers can build a big table of corresponding SID strings
(probably just hashes) and correct answers which enables them to
automatically open new accounts. This maybe even works on other sites if
they use same programs to generate CAPTCHA images.
END UPDATE
We received couple of reports of very strange phishing/spam e-mails.
They all share obfuscated text which is shown properly when rendered as a HTML. In the body of the e-mail the text is always similar to:
"Dear <domain> Member,
We must check that your <domain> ID was registered by real people. So, to help <domain> prevent automated, registrations, please click on this link and complete code verification process."
The link is, of course, hidden in the HTML and the displayed one is different from where the user will go when they click the link.
All of these e-mails use Google redirector techniques in order to defeat SURBL (Spam URI Realtime Blocklists). Some of the e-mails we saw also use multiple redirectors in order to defeat Google's anti-redirector script.
They are also frequently malformed and don't work at all, for example, one of the reports we received pointed to this URL (with spaces added by us to prevent clicking on it):
ht tp://www.go ogle.to/url?q=http://STaNdar TzA.Com/cgi -bin/p och/redir.cgi?s=<domain>
All e-mails always had recipients domain as the argument to the redir.cgi script. Also, most of the URLs are malformed and won't work (notice characters).
Some of the first e-mails that were submitted pointed to a different domain - standza.net. This URL was accessible for couple of hours and it didn't seem to do anything - it was probably used to collect IP addresses, or the author is/was still setting things up.
The domain which is used now, standartza.com is not resolvable, but is registered.
Thanks to Laurent D, Dan W, Guy R!
UPDATE
We received some very nice submissions about this.
First, in order to obfuscate their text, spammers use special Unicode formatting characters. The trick is to use "Right-To-Left Override" (RLO), so any text between two delimiters will be displayed backwards.
From the document at http://www.unicode.org/charts/PDF/U2000.pdf, and received phishing e-mails, we can see that those delimiters are ‮ and ‬. The reason for this is simple. Bayesian spam filters which don't render this properly will end up with weird tokens in their databases and the spammer can change tokens frequently (by grouping them).
The second trick (with tab characters in the URL) will work with Google redirectors.
Spammers also used various DNS tricks (round robin DNS entries, if one of their sites goes down they can redirect users to a different site).
The most interesting thing is why? It seems that spammers are trying to open new accounts on free webmail systems. Most of these systems today use CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart - http://www.captcha.net) to prevent bots from automatically opening accounts. Spammers use their spam targets to provide them with the data they need.
Thanks to Micha P, Danne, Andew H!
At the moment I am pretty sure that spammers
were using this "trick" to make users solve CAPTCHA graphics for them. In
this case, I believe they were trying to open new accounts on free webmail
www.pochta.ru (that's a legitimate Russian webmail). When you try to open a
new account on that site (http://www.pochta.ru/regform
presented with a CAPTCHA picture and it's link will be exactly
http://www12.pochta.ru/rnd_img
example).
Now, pochta.ru uses sid parameter to identify which CAPTCHA image will be
presented. The image itself will be changed (colors and number positions),
but the string that the user has to enter will remain the same. To test this
just enter the URL above in your browser and refresh couple of times - you
will see how it changes.
Therefore, spammers can build a big table of corresponding SID strings
(probably just hashes) and correct answers which enables them to
automatically open new accounts. This maybe even works on other sites if
they use same programs to generate CAPTCHA images.
END UPDATE
We received couple of reports of very strange phishing/spam e-mails.
They all share obfuscated text which is shown properly when rendered as a HTML. In the body of the e-mail the text is always similar to:
"Dear <domain> Member,
We must check that your <domain> ID was registered by real people. So, to help <domain> prevent automated, registrations, please click on this link and complete code verification process."
The link is, of course, hidden in the HTML and the displayed one is different from where the user will go when they click the link.
All of these e-mails use Google redirector techniques in order to defeat SURBL (Spam URI Realtime Blocklists). Some of the e-mails we saw also use multiple redirectors in order to defeat Google's anti-redirector script.
They are also frequently malformed and don't work at all, for example, one of the reports we received pointed to this URL (with spaces added by us to prevent clicking on it):
ht tp://www.go ogle.to/url?q=http://STaNdar TzA.Com/cgi -bin/p och/redir.cgi?s=<domain>
All e-mails always had recipients domain as the argument to the redir.cgi script. Also, most of the URLs are malformed and won't work (notice characters).
Some of the first e-mails that were submitted pointed to a different domain - standza.net. This URL was accessible for couple of hours and it didn't seem to do anything - it was probably used to collect IP addresses, or the author is/was still setting things up.
The domain which is used now, standartza.com is not resolvable, but is registered.
Thanks to Laurent D, Dan W, Guy R!
UPDATE
We received some very nice submissions about this.
First, in order to obfuscate their text, spammers use special Unicode formatting characters. The trick is to use "Right-To-Left Override" (RLO), so any text between two delimiters will be displayed backwards.
From the document at http://www.unicode.org/charts/PDF/U2000.pdf, and received phishing e-mails, we can see that those delimiters are ‮ and ‬. The reason for this is simple. Bayesian spam filters which don't render this properly will end up with weird tokens in their databases and the spammer can change tokens frequently (by grouping them).
The second trick (with tab characters in the URL) will work with Google redirectors.
Spammers also used various DNS tricks (round robin DNS entries, if one of their sites goes down they can redirect users to a different site).
The most interesting thing is why? It seems that spammers are trying to open new accounts on free webmail systems. Most of these systems today use CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart - http://www.captcha.net) to prevent bots from automatically opening accounts. Spammers use their spam targets to provide them with the data they need.
Thanks to Micha P, Danne, Andew H!
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments