Feed aggregator
Vulnerability Assessment Testing Automation Part I, (Tue, Jun 29th)
In my SANSFire presentation I described how and why to automate parts of the security testing process. The slides are posted here (handlers.dshield.org/adebeaupre/deBeaupre-SANSFire2010v011.pdf). Part of the process involves taking tool outputs, parsing them, and then importing the results to a database. In the example I am giving here we are taking nmap XML output, parsing it using a perl script and the nmap::parser (code.google.com/p/nmap-parser/) module, and then importing it to a MySQL database. The script I'm using is based on work by Paul Haas found here (www.redspin.com/blog/2009/10/27/nmap-database-output-xml-to-sql/). The table schema he uses is one of the better ones I have seen for nmap data storage. One of the major things the script lacks is the ability to parse nmap NSE output, still a work in progress. In any case the script is found here (handlers.dshield.org/adebeaupre/nmap_xml2mysql-v011.pl). The structure of the script is straight forward:
Main - reads command line arguments and calls the other functions
Usage - prints out a usage message if no command line arguments are provided
CreateTables - creats the database tables
Nmap_info - reads in the xml file and populates the tables
Db_output - outputs a success message
Unfortunately it needs some more work, but does the trick. I am more than open to suggestions, or better ways of doing things. Part II will be a script to import v2 .nessus files into a MySQL database, also in perl. Let us know if you use this script, something like it, or some other technique to manage security test data. Contact us or use the comment fields below.
Cheers,
Adrien de Beaupr
EWA-Canada.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Main - reads command line arguments and calls the other functions
Usage - prints out a usage message if no command line arguments are provided
CreateTables - creats the database tables
Nmap_info - reads in the xml file and populates the tables
Db_output - outputs a success message
Unfortunately it needs some more work, but does the trick. I am more than open to suggestions, or better ways of doing things. Part II will be a script to import v2 .nessus files into a MySQL database, also in perl. Let us know if you use this script, something like it, or some other technique to manage security test data. Contact us or use the comment fields below.
Cheers,
Adrien de Beaupr
EWA-Canada.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Snort.org will be temporarily closed for site enhancements Monday, June 28 2010 between 2-4 PM EST. Intermittent outages will occur., (Mon, Jun 28th)
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Down the RogueAV and Blackhat SEO rabbit hole, (Mon, Jun 28th)
Couple of days ago, a fellow handler Joel sent an obfuscated PHP script he acquired. Having a PHP script that is 100KB+ and pretty heavily obfuscated definitely sounds like something I'm interested in, so with couple of extra days I decided to give it some time. At that point in time I did not know that I'm looking at the master PHP script (albeit an old version) that is being used by the RogueAV guys.
I managed to acquire the very latest version of the script that is being used at the moment which provided me with some unique insight into how their operations work. So, I will publish a series of diaries analyzing various parts in the script in next couple of days/weeks (depending on feedback/free time etc). Let's get to work.
First step: poison search engines
If you have been following campaigns by the RogueAV guys you probably noticed that they very quickly poison search engines with the latest events/keywords. The poisoning part is, of course, completely automated and partially done by the script I will talk about.
The scripts that are used are almost exclusively set on compromised web sites. They are mainly interested in web sites running Apache with PHP, of course. It looks like in many cases they are abusing incorrect installations or known vulnerabilities such as open TinyMCE editors. In any case, their goal is to install couple of PHP scripts on those compromised servers. The scripts will allow them to setup poisoning campaigns, offer redirections to other sites serving RogueAV, but at the same time to also conceal their activities as much as possible since they don't want the real owner to find out that his site has been compromised.
This means that the attackers modify the web site, but in such a way that the web site continues to operate normally, unless special parameters/keywords are used! So there are probably thousands of such compromised web sites which the attackers are not using at the moment. Since the scripts allow automatic updates they can use them at any time and configure for a specific campaign in a matter of seconds.
The following figure shows how the SEO part works, with steps described below. While I was researching this I was in contact with some colleagues in CA who posted an article about this back in January (great work by them!) with analysis similar to mine, but the script I analyzed is the latest version used at the moment. You can read CA's article here.
This is what is happening:
In first step, the master CC server(s) use Google Trends to collect keywords that are currently hot (interesting).
The master CC server(s) now use various methods to spam links to compromised sites containing specially crafted parameters with such keywords.
Now search engine crawlers either find spammed links or just crawl the compromised web sites again (in which case they get a bit different response I will cover that in the next diary).
When the crawler accesses a compromised web site, the master script immediately contacts the CC server and asks what to return to the crawler. The CC server creates a web page in real time containing a lot of references to the asked keyword, as well as links to other compromised web sites!
The custom web page is returned to the crawler and cached locally.
In step 2, besides spammed links, search engine crawlers will also visit compromised web sites. Now an interesting thing happens that helps poison the results: when the script detects a visit from a search engine crawler, but without the required poisoned parameters, the PHP script by the attackers will return the original requested web page, but with concatenated links to other compromised web sites that it has in the local database. This local database can be updated automatically through an interface on the PHP script so the attackers can update the database constantly as well.
Here we can see such a web page requested first time normally (normal user agent, main index.html requested) and second time pretending to be a search engine crawler. Notice the difference in size of the returned file:
$ ls -l index.html*
-rw-rw-r-- 1 nobody nobody 38383 Jun 26 12:53 index.html-normal
-rw-rw-r-- 1 nobody nobody 95703 Jun 26 14:47 index.html-crawler
And this is what gets appended in raw HTML:
(compromised sites deliberately removed as they are still live).
By doing this they are getting all compromised sites linked to each other, hopefully increasing their rating with various search engines. See the style setup as display:none? This makes sure that if someone renders this web page through a browser that the inserted links will be invisible. They are not invisible to a crawler, of course.
Redirecting to RogueAV
Now, after all this poisoning, if a normal user (plain user agent) accesses the web site directly, he will just get the same cached web page that the crawler got. However, if the web site is accessed by clicking the link that appeared as a search result in any search engine (Google, Yahoo, Bing ...), such a request will have a corresponding referrer set and the script will redirect the user to another web site that will serve (you guessed it) RogueAV, as shown in the figure below:
This time they are trying to get the user to install it by displaying an ActiveX error.
With this I will end with the first diary. In the next diary I'll go deeper into analyzing interesting details found in the script (will be posted on Thursday).
If you would like me to go into more details with anything let us know through our contact form.
--
Bojan
INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
I managed to acquire the very latest version of the script that is being used at the moment which provided me with some unique insight into how their operations work. So, I will publish a series of diaries analyzing various parts in the script in next couple of days/weeks (depending on feedback/free time etc). Let's get to work.
First step: poison search engines
If you have been following campaigns by the RogueAV guys you probably noticed that they very quickly poison search engines with the latest events/keywords. The poisoning part is, of course, completely automated and partially done by the script I will talk about.
The scripts that are used are almost exclusively set on compromised web sites. They are mainly interested in web sites running Apache with PHP, of course. It looks like in many cases they are abusing incorrect installations or known vulnerabilities such as open TinyMCE editors. In any case, their goal is to install couple of PHP scripts on those compromised servers. The scripts will allow them to setup poisoning campaigns, offer redirections to other sites serving RogueAV, but at the same time to also conceal their activities as much as possible since they don't want the real owner to find out that his site has been compromised.
This means that the attackers modify the web site, but in such a way that the web site continues to operate normally, unless special parameters/keywords are used! So there are probably thousands of such compromised web sites which the attackers are not using at the moment. Since the scripts allow automatic updates they can use them at any time and configure for a specific campaign in a matter of seconds.
The following figure shows how the SEO part works, with steps described below. While I was researching this I was in contact with some colleagues in CA who posted an article about this back in January (great work by them!) with analysis similar to mine, but the script I analyzed is the latest version used at the moment. You can read CA's article here.
This is what is happening:
In first step, the master CC server(s) use Google Trends to collect keywords that are currently hot (interesting).
The master CC server(s) now use various methods to spam links to compromised sites containing specially crafted parameters with such keywords.
Now search engine crawlers either find spammed links or just crawl the compromised web sites again (in which case they get a bit different response I will cover that in the next diary).
When the crawler accesses a compromised web site, the master script immediately contacts the CC server and asks what to return to the crawler. The CC server creates a web page in real time containing a lot of references to the asked keyword, as well as links to other compromised web sites!
The custom web page is returned to the crawler and cached locally.
In step 2, besides spammed links, search engine crawlers will also visit compromised web sites. Now an interesting thing happens that helps poison the results: when the script detects a visit from a search engine crawler, but without the required poisoned parameters, the PHP script by the attackers will return the original requested web page, but with concatenated links to other compromised web sites that it has in the local database. This local database can be updated automatically through an interface on the PHP script so the attackers can update the database constantly as well.
Here we can see such a web page requested first time normally (normal user agent, main index.html requested) and second time pretending to be a search engine crawler. Notice the difference in size of the returned file:
$ ls -l index.html*
-rw-rw-r-- 1 nobody nobody 38383 Jun 26 12:53 index.html-normal
-rw-rw-r-- 1 nobody nobody 95703 Jun 26 14:47 index.html-crawler
And this is what gets appended in raw HTML:
(compromised sites deliberately removed as they are still live).
By doing this they are getting all compromised sites linked to each other, hopefully increasing their rating with various search engines. See the style setup as display:none? This makes sure that if someone renders this web page through a browser that the inserted links will be invisible. They are not invisible to a crawler, of course.
Redirecting to RogueAV
Now, after all this poisoning, if a normal user (plain user agent) accesses the web site directly, he will just get the same cached web page that the crawler got. However, if the web site is accessed by clicking the link that appeared as a search result in any search engine (Google, Yahoo, Bing ...), such a request will have a corresponding referrer set and the script will redirect the user to another web site that will serve (you guessed it) RogueAV, as shown in the figure below:
This time they are trying to get the user to install it by displaying an ActiveX error.
With this I will end with the first diary. In the next diary I'll go deeper into analyzing interesting details found in the script (will be posted on Thursday).
If you would like me to go into more details with anything let us know through our contact form.
--
Bojan
INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Study of clickjacking vulerabilities on popular sites, (Sun, Jun 27th)
If you are looking for some activity on this sunday afternoon (2:37 PM GMT-5 here in Medelln, Colombia), I strongly suggest you to review the excellent paper published by Gustav Rydstedt, Elie Bursztein, Dan Boneh from Stanford University about clickjacking attacks and how to put in place proper defense against them.
Download the paper here: http://seclab.stanford.edu/websec/framebusting/framebust.pdf
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Download the paper here: http://seclab.stanford.edu/websec/framebusting/framebust.pdf
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Firefox 3.6.6 out - fixes issues with "crash protection", (Sun, Jun 27th)
---------------
Jim Clausing, jclausing --at-- isc [dot] sans (dot) org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Jim Clausing, jclausing --at-- isc [dot] sans (dot) org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
socat to Simulate a Website, (Sat, Jun 26th)
Last week I published a diary on DNS Sinkhole. If you are looking at tracking the clients that are redirected into your sinkhole address, the method I have been successfully using is with a multipurpose relay tool, called socat (SOcket CAT) .
In order to capture the host information (true website name) the client is attempting to access, I have been using socat to simulate various web server ports (80, 443, 7070, 8080, etc) and you can capture that information with your favorite IDS or using a simple Snort signature. It is much easier then to figure out what site the client was attempting to connect to and figure out if the client is already infected. A direct client outbound connection might indicate the client is attempting to contact a CC and already compromised while a web site redirect is potentially malicious but blocked by the sinkhole.
Socat as a Web Site Simulator
socat TCP-LISTEN:80,bind=192.168.25.5,fork,reuseaddr,crlf SYSTEM:
This first socat example is used to simulate a web server listener on TCP port 80. The same line can be copied several times with different ports using the same address to simulate your web port list.
socat openssl-listen:443,bind=192.168.25.5,fork,reuseaddr,verify=1,cert=/home/certs/sinkhole32.pem PIPE=echo Media Center PC 6.0)
Accept-Encoding: gzip, deflate
Host: 00g00.ru
Connection: Keep-Alive
The socat binary is included in the DNS Sinkhole ISO and these two example are in the rc.local script. More information is available about socat's other features here.
-----------
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
In order to capture the host information (true website name) the client is attempting to access, I have been using socat to simulate various web server ports (80, 443, 7070, 8080, etc) and you can capture that information with your favorite IDS or using a simple Snort signature. It is much easier then to figure out what site the client was attempting to connect to and figure out if the client is already infected. A direct client outbound connection might indicate the client is attempting to contact a CC and already compromised while a web site redirect is potentially malicious but blocked by the sinkhole.
Socat as a Web Site Simulator
socat TCP-LISTEN:80,bind=192.168.25.5,fork,reuseaddr,crlf SYSTEM:
This first socat example is used to simulate a web server listener on TCP port 80. The same line can be copied several times with different ports using the same address to simulate your web port list.
socat openssl-listen:443,bind=192.168.25.5,fork,reuseaddr,verify=1,cert=/home/certs/sinkhole32.pem PIPE=echo Media Center PC 6.0)
Accept-Encoding: gzip, deflate
Host: 00g00.ru
Connection: Keep-Alive
The socat binary is included in the DNS Sinkhole ISO and these two example are in the rc.local script. More information is available about socat's other features here.
-----------
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Live CD for Remote Incident Handling, (Fri, Jun 25th)
This paper was written by Bert Hayes. Bert Hayes is a security professional at the University of Texas. When Bert originally wrote this paper, he submitted it to me for the SANS Gold process, and I helped push the paper in the right direction, however, while it was an excellent paper and well written, it didn't really meet the criteria we were looking for.
However, I thought Wow, what a great idea, what a great paper. I am sure a lot of organizations will benefit from this.
Of course Bert nor the Internet Storm Center can be held liable for any damage you to do a computer while using this, (just to get that disclaimer out of the way), and it's recommended that if you are going to use the contents of the computer you are doing the investigation on for a prosecution, don't use this. (Changing the state of the data on the drive during a forensic investigation is generally frowned upon.)
But, as I said, this is a great paper and you should definitely download it and give it a read.
http://security.utexas.edu/consensus/How_To_UTIRD2.pdf
Enjoy
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
However, I thought Wow, what a great idea, what a great paper. I am sure a lot of organizations will benefit from this.
Of course Bert nor the Internet Storm Center can be held liable for any damage you to do a computer while using this, (just to get that disclaimer out of the way), and it's recommended that if you are going to use the contents of the computer you are doing the investigation on for a prosecution, don't use this. (Changing the state of the data on the drive during a forensic investigation is generally frowned upon.)
But, as I said, this is a great paper and you should definitely download it and give it a read.
http://security.utexas.edu/consensus/How_To_UTIRD2.pdf
Enjoy
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Thunderbird 3.1 available for download!, (Fri, Jun 25th)
According to Mozilla, the following updates are in Thunderbird 3.1:
New Quick Filter toolbar
New Migration Assistant
Saved Files Manager
Several fixes to improve upgrading from Thunderbird 2
Several design improvements and corrections to the interface
Stability, memory, and password handling improvements
So if you use Thunderbird, start your upgrade engine now. Available here. Or if you wan the local language version for our Non-English speaking customers: here.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
New Quick Filter toolbar
New Migration Assistant
Saved Files Manager
Several fixes to improve upgrading from Thunderbird 2
Several design improvements and corrections to the interface
Stability, memory, and password handling improvements
So if you use Thunderbird, start your upgrade engine now. Available here. Or if you wan the local language version for our Non-English speaking customers: here.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
The Great "Flash Stock Crash" of May 2010, (Fri, Jun 25th)
Otto sent this article into us, and while it's not generally security related, I do feel as if it's interesting to the readers and it does relate to computers and automation in general.
Remember when the stock market (DJIA) took a dip on May 6th, 2010? Lost about 600 points? Here is a very interesting write up of the crash with charts:
http://www.nanex.net/20100506/FlashCrashAnalysis_Intro.html
There is also a Complete Text link on the page where you can read the full write up. Interesting stuff.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Remember when the stock market (DJIA) took a dip on May 6th, 2010? Lost about 600 points? Here is a very interesting write up of the crash with charts:
http://www.nanex.net/20100506/FlashCrashAnalysis_Intro.html
There is also a Complete Text link on the page where you can read the full write up. Interesting stuff.
-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Help your competitor - Advise them of vulnerability, (Thu, Jun 24th)
Tom Bicer wrote in to tell us about some interesting development amongst the SSLcertificate providers. Comodo made a press release announcing that they found some vulnerabilities related to Verisign's certificate and had advised Verisign on the vulnerabilities. The vulnerability at least led to potential security issues at one of Verisign's customer (a bank). The vulnerability was discovered using publicly available information. Comodo definitely was careful in the wording of this press release, no details of the vulnerability was released. They also stated that they followed CCSS's (Common Computing Security Standards Forum) guideline in releasing the vulnerability information.
While it seems that Comodo is doing everything right, it still brings the question - Should you test your competitor's products/ stuff? And - How do you handle the announcement so it doesn't look like you are doing leveraging your competitor's security weakness in marketing? There are no good answers to those questions, it's all dependent on the situation. It's all a very fine line. It's hard to balance the bragging rights by the finder of a vulnerability before the announcement of actual vulnerability by the vendor. In some cases, vulnerabilities are never released by the vendor. Bottom line, credit to the finder of vulnerability should be given. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
While it seems that Comodo is doing everything right, it still brings the question - Should you test your competitor's products/ stuff? And - How do you handle the announcement so it doesn't look like you are doing leveraging your competitor's security weakness in marketing? There are no good answers to those questions, it's all dependent on the situation. It's all a very fine line. It's hard to balance the bragging rights by the finder of a vulnerability before the announcement of actual vulnerability by the vendor. In some cases, vulnerabilities are never released by the vendor. Bottom line, credit to the finder of vulnerability should be given. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Microsoft Non-Security Updates, (Wed, Jun 23rd)
As a number of readers have reported, Microsoft released a few non-security updates on Tuesday via Windows Update/Automatic Updates. Most of our readers will recognize that the 4th Tuesday of the month is when Microsoft usually releases non-security updates. From the results of a couple of computers here in my office, the updates involve the .NET Framework versions 3.x and 2.x. As with all updates, please remember to test the update in your respective environment prior to wholesale deployment. More information on the .NET Framework update available at KB982524.
Scott Fendley ISC Handler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Scott Fendley ISC Handler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
IPv6 Support in iOS 4 , (Wed, Jun 23rd)
On monday, Apple released iOS 4 to the masses. Among numerous security fixes, one other feature that caught my interest was the availability of IPv6. The iPhone was one of a few holdouts in the mobile phone world that did not yet support IPv6. In some ways, the iPhone and similar devices is just why people feel we may need IPv6. Features like VoIP calling (e.g. Apple's new Facetime protocol) can work with NAT, but may possibly work better if the device has a globally routable IP address which may not be available in IPv4.
Screenshot of iOS 4 beta versions showed a new configuration setting for IPv6, allowing users to turn IPv6 support on and off. The final version as delivered to customers on Monday, no longer has this switch. Instead, IPv6 support is always turned on. In order to be functional, it does need to be connected to an IPv6 capable network.
In my tests, Iconnected the iPhone's WiFi network to my home network, which supports IPv6 and uses a router that advertises itself via IPv6 router advertisements. The iPhone did pick up an IPv6 address. The IPv6 address selected by the iPhone was derived from the MAC address (EUI-64). Ipersonally would have preferred a privacy enhanced address.
iOS 4 does not appear to support any tunneling protocols. It will only use IPv6 in a dual stack configuration. I am going to update this diary as I get to experiment more with it.
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Screenshot of iOS 4 beta versions showed a new configuration setting for IPv6, allowing users to turn IPv6 support on and off. The final version as delivered to customers on Monday, no longer has this switch. Instead, IPv6 support is always turned on. In order to be functional, it does need to be connected to an IPv6 capable network.
In my tests, Iconnected the iPhone's WiFi network to my home network, which supports IPv6 and uses a router that advertises itself via IPv6 router advertisements. The iPhone did pick up an IPv6 address. The IPv6 address selected by the iPhone was derived from the MAC address (EUI-64). Ipersonally would have preferred a privacy enhanced address.
iOS 4 does not appear to support any tunneling protocols. It will only use IPv6 in a dual stack configuration. I am going to update this diary as I get to experiment more with it.
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Opera Browser Update, (Wed, Jun 23rd)
In other news, Opera Software released version 10.54 of their web browser on June 21st. One of the vulnerabilities corrected in this release involves the font handling flaw discussed in the advisory at http://www.opera.com/support/kb/view/954/. In addition, Opera corrected several other critical vulnerabilities which will be disclosed in the future. If you prefer to use the Opera web browser to the other mainstream alternates, it is recommended that you apply the update in the near future. More information is available in the release notes.
Thanks to Frank who noted the update a short while ago.
Scott Fendley --ISC Handler on Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Thanks to Frank who noted the update a short while ago.
Scott Fendley --ISC Handler on Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Mozilla Firefox Updates, (Wed, Jun 23rd)
Earlier today, Mozilla released the newest version of Firefox.
Firefox 3.6.4corrects 7 vulnerabilities which range from critical issues such as denial of service or arbitrary code execution bugs along with a few lower level issues. The full list of vulnerabilities corrected is located in the release notes. In addition, this release of Firefox provides much better handling of plugin crashes. Should a plugin crash or freeze while viewing a website, Firefox now allows the plugin to crash without taking down the entire browser. This is a very useful feature for those of us who keep many many tabs or windows open during the course of the day and get very irritated when you open that one website that has some odd flash or quicktime media that causes the plugin to abnormally end. YAY!
Firefox 3.5.10 also was released and corrects for 9 vulnerabilities of which 6 are rated as critical. The 3.5.x tree of Firefox will continue to receive security updates for 2 more months, so it is time to prepare to jump to 3.6.x very soon. More details on the security issues are listed in the release notes.
Thanks to all of our readers who were on top of these releases tonight and alerted us of them.
Scott Fendley --ISC Handler on Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Firefox 3.6.4corrects 7 vulnerabilities which range from critical issues such as denial of service or arbitrary code execution bugs along with a few lower level issues. The full list of vulnerabilities corrected is located in the release notes. In addition, this release of Firefox provides much better handling of plugin crashes. Should a plugin crash or freeze while viewing a website, Firefox now allows the plugin to crash without taking down the entire browser. This is a very useful feature for those of us who keep many many tabs or windows open during the course of the day and get very irritated when you open that one website that has some odd flash or quicktime media that causes the plugin to abnormally end. YAY!
Firefox 3.5.10 also was released and corrects for 9 vulnerabilities of which 6 are rated as critical. The 3.5.x tree of Firefox will continue to receive security updates for 2 more months, so it is time to prepare to jump to 3.6.x very soon. More details on the security issues are listed in the release notes.
Thanks to all of our readers who were on top of these releases tonight and alerted us of them.
Scott Fendley --ISC Handler on Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Problems With Lenovo Support, (Tue, Jun 22nd)
If you visited the Lenovo support site over the last few days, you may want to check out this link that Jim sent in. Lenovo Support Website Loads Malicious IFrame, Infects Visitors With Trojan
Christopher Carboni - Handler On Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Christopher Carboni - Handler On Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Thoughts on Malware for Mobile Devices, (Tue, Jun 22nd)
One of the reasons that I love going to conferences is that it really makes me think. Being around some of the best minds in information security. talking to people, listening to thier views and re-evaluating my own opinions based on any new information is a big takeaway for me.
For those who were not at SANSFire this year and didn't otherwise follow the Handler's annual State of the Internet Panel, one of the questions asked of the panel was (and I'm paraphrasing because I can't remember the exact word for word question) Every year we hear a prediction that this will be the year that mobile malware becomes wide spread. Do you think that will happen this year?
I remember giving some answer along the lines of Well, we've already had a few examples and one of the other Handlers cited the malware infested apps that became available (breifly) from the iTunes Store. The panel concluded and we all went about our business but something was nagging me. Something just didn't feel right.
I started talking to a few friends discussing mobile security and then looked at my own devices.
How would I really know if there was malware on my smart phone?
Malware authors have become increasingly good at hiding the presence of malware on infected systems and I didn't have anti virus on my phone, a problem which has since been corrected. But given the problems with signature based AV protection, do I really have confidence that I'm protected?
How do we really know that mobile malware is not widespread right now?
Please take a moment and answer the poll that I've posted and if you have some creative ways you're protecting your mobile devices, send them in and I'll post them.
While 130 people is not a statistically large sample we do have some interesting preliminary results.
Of 130 people, only 15 are scanning for malware.
Of those 15, 3 (20%) have detected malware.
If you extrapolate that percentage out to the entire sample, 23 people who responded who do not scan would be infected with malware.
For now, I'm filing that under Things that make you go Hmmmmm.
Christopher Carboni - Handler On Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
For those who were not at SANSFire this year and didn't otherwise follow the Handler's annual State of the Internet Panel, one of the questions asked of the panel was (and I'm paraphrasing because I can't remember the exact word for word question) Every year we hear a prediction that this will be the year that mobile malware becomes wide spread. Do you think that will happen this year?
I remember giving some answer along the lines of Well, we've already had a few examples and one of the other Handlers cited the malware infested apps that became available (breifly) from the iTunes Store. The panel concluded and we all went about our business but something was nagging me. Something just didn't feel right.
I started talking to a few friends discussing mobile security and then looked at my own devices.
How would I really know if there was malware on my smart phone?
Malware authors have become increasingly good at hiding the presence of malware on infected systems and I didn't have anti virus on my phone, a problem which has since been corrected. But given the problems with signature based AV protection, do I really have confidence that I'm protected?
How do we really know that mobile malware is not widespread right now?
Please take a moment and answer the poll that I've posted and if you have some creative ways you're protecting your mobile devices, send them in and I'll post them.
While 130 people is not a statistically large sample we do have some interesting preliminary results.
Of 130 people, only 15 are scanning for malware.
Of those 15, 3 (20%) have detected malware.
If you extrapolate that percentage out to the entire sample, 23 people who responded who do not scan would be infected with malware.
For now, I'm filing that under Things that make you go Hmmmmm.
Christopher Carboni - Handler On Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
GoDaddy Scam/Phish/Spam, (Mon, Jun 21st)
A number of readers (and myself included) have received an email claiming to be from GoDaddy. The email is grammatically correct, and appears quite genuine. The subject is GoDaddy.com Order Confirmation and interestingly the images within the HTML are pulled from imagesak.godaddy.com, excepting one which came from hxxp://img.securepaynet.net/bbimage.aspx?pl=somecodeandmyemailaddress. The links in the emails I have seen point to hxxp://dextersss-com-ua.1gb.ua/zzx.htm among others. The phishing site and IP address and domain registration are in the Ukraine.
Thanks to Christopher and Dwight!
Cheers,
Adrien de Beaupr
EWA-Canada.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Thanks to Christopher and Dwight!
Cheers,
Adrien de Beaupr
EWA-Canada.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Father's Day Tips, (Sun, Jun 20th)
Happy Father's Day to all of the dads out there!
Here's something you can give dear old dad on his special day - sit down with him and walk him through some pointers on how to keep his computer and his personal information safe. If you are over at dad's today spending some time, be sure to give his computer a good tune up while you are there.
Below are some ideas for things to pass along. You might have to do a few of these things for him or perhaps teach him the steps if he's interested, If you've got other tips that would be useful for your dad, please use the comment feature at the bottom to add to the list.
Dad's Computer
1. Keep it updated, which means the operating system, any programs he has installed, and most importantly his antivirus software. Turn on the auto-update feature and let his computer take care of updating itself automatically. Be sure to reboot if it asks you to.
2. Uninstall any software that dad does not use. Old programs often have security problems, and if dad's not going to use an application anymore, why not free up the space on his hard drive while at the same time making his computer more secure?
3. Make sure that his screen-saver requires a password to reactivate. Too often (particularly in shared environments with family members or office mates) a creative friend might send embarrassing emails from dad's computer or might accidentally download malicious software.
4. If dad has a laptop, be sure that the built-in disk encryption feature is running. This will protect him should his laptop be stolen. Also, invest in a cable lock so that his laptop can be physically secured while he's temporarily away from the computer. Laptops can be stolen in just a few seconds.
Dad's Websites
5. Warn dad to be careful with what he puts on social networking sites about himself, his friends, and his co-workers. Remember once on the Internet, always on the Internet, especially photographs.
6. Show him how to use website passwords that are complex but easy for him to remember. Tell him that if possible, use a passphrase rather than a password something like Thisismybankpassw0rd is much harder to crack or guess than 75yt*$AS (20 characters versus 8 characters.)
7. Remind dad to pay close attention to where he is online. Many phishing sites appear to be legitimate but if he looks closely at the address bar he may see that he are not really at his bank or site that he thought he was going to. Think twice before entering any personal information at a new web site does this company really need to know the things it is asking for?
Dad's Personal Information
8. Be very careful with peer-to-peer (P2P) or file-sharing programs. They should never be used on office computers, and if dad has them at home pay close attention to which parts of his hard drives are shared to others by these programs. Under no circumstances should he put office information on his personal computer, especially if he uses P2P software at home to share files with his friends.
9. If dad uses reply to all in emails, remind him to check each of the email addresses to make sure he know where his email is going. Also, tell him to BE VERY CAREFUL if he replies to a posting from a listserver or online group his reply may go to the entire group rather than just the person he thought he was writing back to.
10. Dad should know who to call or contact if he thinks he has become a victim of online crime. Events happen fast online and he often will not have much time to call for help before it is too late. In addition, show him how to keep a backup copy of all of his personal information (passwords, credit card numbers, bank account information, emergency phone numbers, etc.) on a physical piece of paper that is locked in a fireproof container.
Marcus H. Sachs
Director, SANSInternet Storm Center (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Here's something you can give dear old dad on his special day - sit down with him and walk him through some pointers on how to keep his computer and his personal information safe. If you are over at dad's today spending some time, be sure to give his computer a good tune up while you are there.
Below are some ideas for things to pass along. You might have to do a few of these things for him or perhaps teach him the steps if he's interested, If you've got other tips that would be useful for your dad, please use the comment feature at the bottom to add to the list.
Dad's Computer
1. Keep it updated, which means the operating system, any programs he has installed, and most importantly his antivirus software. Turn on the auto-update feature and let his computer take care of updating itself automatically. Be sure to reboot if it asks you to.
2. Uninstall any software that dad does not use. Old programs often have security problems, and if dad's not going to use an application anymore, why not free up the space on his hard drive while at the same time making his computer more secure?
3. Make sure that his screen-saver requires a password to reactivate. Too often (particularly in shared environments with family members or office mates) a creative friend might send embarrassing emails from dad's computer or might accidentally download malicious software.
4. If dad has a laptop, be sure that the built-in disk encryption feature is running. This will protect him should his laptop be stolen. Also, invest in a cable lock so that his laptop can be physically secured while he's temporarily away from the computer. Laptops can be stolen in just a few seconds.
Dad's Websites
5. Warn dad to be careful with what he puts on social networking sites about himself, his friends, and his co-workers. Remember once on the Internet, always on the Internet, especially photographs.
6. Show him how to use website passwords that are complex but easy for him to remember. Tell him that if possible, use a passphrase rather than a password something like Thisismybankpassw0rd is much harder to crack or guess than 75yt*$AS (20 characters versus 8 characters.)
7. Remind dad to pay close attention to where he is online. Many phishing sites appear to be legitimate but if he looks closely at the address bar he may see that he are not really at his bank or site that he thought he was going to. Think twice before entering any personal information at a new web site does this company really need to know the things it is asking for?
Dad's Personal Information
8. Be very careful with peer-to-peer (P2P) or file-sharing programs. They should never be used on office computers, and if dad has them at home pay close attention to which parts of his hard drives are shared to others by these programs. Under no circumstances should he put office information on his personal computer, especially if he uses P2P software at home to share files with his friends.
9. If dad uses reply to all in emails, remind him to check each of the email addresses to make sure he know where his email is going. Also, tell him to BE VERY CAREFUL if he replies to a posting from a listserver or online group his reply may go to the entire group rather than just the person he thought he was writing back to.
10. Dad should know who to call or contact if he thinks he has become a victim of online crime. Events happen fast online and he often will not have much time to call for help before it is too late. In addition, show him how to keep a backup copy of all of his personal information (passwords, credit card numbers, bank account information, emergency phone numbers, etc.) on a physical piece of paper that is locked in a fireproof container.
Marcus H. Sachs
Director, SANSInternet Storm Center (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
DNS Sinkhole ISO Available for Download, (Sat, Jun 19th)
In January, I posted a diary on how to configure a basic DNS Sinkhole using BIND. Last week, during the SANSFire conference, I did a talk on DNS Sinkhole and made an ISO available for download. It is a ready to install DNS Sinkhole server for those who would like to test and/or deploy one in their network as an internal forwarder. I also indicated that inserting a DNS sinkhole in a network is like putting a NIDS/NIPS inline with potentially several thousand signatures (DNS domains). After you loaded your DNS sinkhole list, it hijacks the clients DNS requests to known malicious sites responding with an IP address you control instead of its true address. It could also be used to enforce corporate policies (hacking, adults, gaming, social, etc) with the creation of separate sinkhole lists.
However, for maximum efficiency, it is important to only allow the DNS Sinkhole server to forward outbound requests (block all other outbound DNS request form internal servers/clients) otherwise, there are known cases where malware has been coded with its own DNS server/changer to evaded detection. Handler Bojan Zdrnja posted a diary here regarding this type of evasion.
The installation document is located in the rel_note directory of the CD and is available online here. This document provides all the information needed to install and configure the server. There are two ISO available for download:
- a 32-bit version can be downloaded here
- a 64-bit version can be downloaded here
The script to load the sinkhole list is located in the /root/scripts directory and is called sinkhole_parser.sh. This script contains a menu to download from 3 lists (Malware Domain Blocklist, ZeuS tracker and Malware Threat Center SRI). Any of these lists can be commented out in the script. They are merged, parsed and duplicates are removed to create a single list of 20,000+ sites. The sites are saved in a file in /var/named/site_specific_sinkhole.conf which can be loaded via the script in the DNS Sinkhole (server support either Bind or PowerDNS, see the release notes for configuration). I may add to the script other lists later.
Warning: If you are using any of the above lists, there is always the possibility that a site that you do business with may have been added to the sinkhole list because it has been detected serving malware.
There are various ways to capture the sinkhole data such as setting up a web server, IDS alerts, netflow, etc to find which clients were redirected to the sinkhole for signs of system compromise.
-----------
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
However, for maximum efficiency, it is important to only allow the DNS Sinkhole server to forward outbound requests (block all other outbound DNS request form internal servers/clients) otherwise, there are known cases where malware has been coded with its own DNS server/changer to evaded detection. Handler Bojan Zdrnja posted a diary here regarding this type of evasion.
The installation document is located in the rel_note directory of the CD and is available online here. This document provides all the information needed to install and configure the server. There are two ISO available for download:
- a 32-bit version can be downloaded here
- a 64-bit version can be downloaded here
The script to load the sinkhole list is located in the /root/scripts directory and is called sinkhole_parser.sh. This script contains a menu to download from 3 lists (Malware Domain Blocklist, ZeuS tracker and Malware Threat Center SRI). Any of these lists can be commented out in the script. They are merged, parsed and duplicates are removed to create a single list of 20,000+ sites. The sites are saved in a file in /var/named/site_specific_sinkhole.conf which can be loaded via the script in the DNS Sinkhole (server support either Bind or PowerDNS, see the release notes for configuration). I may add to the script other lists later.
Warning: If you are using any of the above lists, there is always the possibility that a site that you do business with may have been added to the sinkhole list because it has been detected serving malware.
There are various ways to capture the sinkhole data such as setting up a web server, IDS alerts, netflow, etc to find which clients were redirected to the sinkhole for signs of system compromise.
-----------
Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
IMPORTANT INFORMATION: Distributed SSH Brute Force Attacks, (Fri, Jun 18th)
Based on an analysis of the logs for my SSH honeypot, it appears that this latest spate of SSH brute force attacks are using keyboard-interactive authentication, rather than the standard password authentication.
2010-05-21 19:29:11+0000 203.185.xxx.xxx trying auth password
2010-05-23 19:31:57+0000 200.175.xxx.xxx trying auth password
2010-05-25 01:02:57+0000 122.155.xxx.xxx trying auth password
2010-05-25 01:09:06+0000 75.156.xxx.xxx trying auth none
2010-05-25 01:09:07+0000 75.156.xxx.xxx trying auth password
2010-05-25 05:08:07+0000 68.40.xxx.xxx trying auth password
2010-05-29 14:39:51+0000 122.226.xxx.xxx trying auth password
2010-06-02 06:27:31+0000 217.25.xxx.xxx trying auth password
2010-06-03 11:32:22+0000 62.83.xxx.xxx trying auth none
2010-06-03 11:32:24+0000 62.83.xxx.xxx trying auth password
2010-06-11 08:44:52+0000 222.173.xxx.xxx trying auth password
2010-06-11 15:42:46+0000 220.163.xxx.xxx trying auth password
2010-06-13 22:14:15+0000 67.228.xxx.xxx trying auth password
2010-06-15 01:21:39+0000 211.254.xxx.xxx trying auth password
2010-06-15 02:09:01+0000 202.98.xxx.xxx trying auth password
2010-06-15 19:53:49+0000 89.128.xxx.xxx trying auth none
2010-06-15 19:53:51+0000 89.128.xxx.xxx trying auth password
2010-06-15 20:10:45+0000 89.133.xxx.xxx trying auth password
2010-06-16 18:20:54+0000 165.98.xxx.xxx trying auth keyboard-interactive
2010-06-16 18:33:35+0000 64.122.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:05:53+0000 59.124.xxx.xxx trying auth password
2010-06-16 19:06:47+0000 220.73.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:28:54+0000 219.159.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:47:52+0000 80.94.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:57:57+0000 203.15.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:18:00+0000 119.161.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:27:40+0000 82.91.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:47:02+0000 190.12.xxx.xxx trying auth keyboard-interactive
2010-06-16 21:27:00+0000 200.40.xxx.xxx trying auth keyboard-interactive
2010-06-17 16:59:36+0000 210.82.xxx.xxx trying auth password
Understand: If you have disabled password authentication in your ssh_config by uncommenting the line:
PasswordAuthentication no
that *WILL NOT* protect you against this latest round of attacks.
In order to disable keyboard-interactive logins, you must also uncomment the line:
ChallengeResponseAuthentication no
NOTE: DO NOT DO THIS unless you understand what you're doing and know that it will not break anything (I don't want a bunch of emails saying I got in trouble because I did what Liston said...)
To test if your server is configured correctly, log in using the command line version of ssh with the -v option. That will spit out a whole bunch of debugging information. The important line is this:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
If you see something like that, then you're not only vulnerable to standard password brute force attacks, but this newer keyboard-interactive attack as well.
Tom Liston
Handler - SANS Internet Storm Center
Senior Security Analyst - InGuardians, Inc. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
2010-05-21 19:29:11+0000 203.185.xxx.xxx trying auth password
2010-05-23 19:31:57+0000 200.175.xxx.xxx trying auth password
2010-05-25 01:02:57+0000 122.155.xxx.xxx trying auth password
2010-05-25 01:09:06+0000 75.156.xxx.xxx trying auth none
2010-05-25 01:09:07+0000 75.156.xxx.xxx trying auth password
2010-05-25 05:08:07+0000 68.40.xxx.xxx trying auth password
2010-05-29 14:39:51+0000 122.226.xxx.xxx trying auth password
2010-06-02 06:27:31+0000 217.25.xxx.xxx trying auth password
2010-06-03 11:32:22+0000 62.83.xxx.xxx trying auth none
2010-06-03 11:32:24+0000 62.83.xxx.xxx trying auth password
2010-06-11 08:44:52+0000 222.173.xxx.xxx trying auth password
2010-06-11 15:42:46+0000 220.163.xxx.xxx trying auth password
2010-06-13 22:14:15+0000 67.228.xxx.xxx trying auth password
2010-06-15 01:21:39+0000 211.254.xxx.xxx trying auth password
2010-06-15 02:09:01+0000 202.98.xxx.xxx trying auth password
2010-06-15 19:53:49+0000 89.128.xxx.xxx trying auth none
2010-06-15 19:53:51+0000 89.128.xxx.xxx trying auth password
2010-06-15 20:10:45+0000 89.133.xxx.xxx trying auth password
2010-06-16 18:20:54+0000 165.98.xxx.xxx trying auth keyboard-interactive
2010-06-16 18:33:35+0000 64.122.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:05:53+0000 59.124.xxx.xxx trying auth password
2010-06-16 19:06:47+0000 220.73.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:28:54+0000 219.159.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:47:52+0000 80.94.xxx.xxx trying auth keyboard-interactive
2010-06-16 19:57:57+0000 203.15.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:18:00+0000 119.161.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:27:40+0000 82.91.xxx.xxx trying auth keyboard-interactive
2010-06-16 20:47:02+0000 190.12.xxx.xxx trying auth keyboard-interactive
2010-06-16 21:27:00+0000 200.40.xxx.xxx trying auth keyboard-interactive
2010-06-17 16:59:36+0000 210.82.xxx.xxx trying auth password
Understand: If you have disabled password authentication in your ssh_config by uncommenting the line:
PasswordAuthentication no
that *WILL NOT* protect you against this latest round of attacks.
In order to disable keyboard-interactive logins, you must also uncomment the line:
ChallengeResponseAuthentication no
NOTE: DO NOT DO THIS unless you understand what you're doing and know that it will not break anything (I don't want a bunch of emails saying I got in trouble because I did what Liston said...)
To test if your server is configured correctly, log in using the command line version of ssh with the -v option. That will spit out a whole bunch of debugging information. The important line is this:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
If you see something like that, then you're not only vulnerable to standard password brute force attacks, but this newer keyboard-interactive attack as well.
Tom Liston
Handler - SANS Internet Storm Center
Senior Security Analyst - InGuardians, Inc. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
Copyright 2009 Lawman Technology and Consulting Group LLC
