Archive | April, 2011

Huge Sony PSN Data Breach; What Should I Do?

On Tuesday, Sony officially disclosed a humongous data breach against the Playstation Network or PSN (recently renamed to Qriocity), which allowed external attackers to get their hands on the Personally Identifiable Information (PII) of around 77 million gamers. Worse yet, they may have even stolen their credit card information, too.

If you read security news, or follow me (@SecAdept) on Twitter, you’ll know this incident has been brewing for around a week now. It first started last Wednesday, when PSN went down for all Playstation 3 users. At the time, I’d imagine that most customers assumed the outage was some sort of routine maintenance. However, with Sony recently coming out of a DDoS battle with “Anonymous” over the Geohot Playstation hacking lawsuit, paranoid security professionals like me suspected this outage might be related to more “Anonymous” hijinks. Unfortunately, we have since learned that that wasn’t the case (I wish it was).

Over the next few days, the story continued to slowly unfold, mostly on security and gaming sites. Sony blog posts (some which were later removed) eventually admitted that the issue may be related to an “external intrusion.” However, Sony was not quick to confirm the details, or share what the attackers got. If you are interested in how the story slowly unfolded, PCWorld has a great timeline of the incident. In any case,  Sony finally sent an email to all its PSN subscribers Tuesday night, sharing exactly what the bad guys stole — and unfortunately the cretins hit pay dirt.

If you’d like to read Sony’s email in full, check out this forum post, but I’ll quickly highlight what it claims the attackers stole from all PSN subscribers:

  • Your name,
  •  address (city, state, zip),
  • country,
  • email address,
  •  birthdate,
  • PSN password and login
  • PSN online ID and handle
  • purchase history,
  • billing address (may be different than normal one),
  • security answers,
  • and possibly even your credit card information (excluding security code)

Unfortunately, this is a huge repository of valuable information for identity thieves and attackers wishing to target your other online accounts. On the surface, the biggest concern is whether or not attackers gained access to credit card (CC) numbers.  Sony is not very clear on this count. They claim they have no evidence to suggest so. However, they immediately backpedal, saying they cannot rule out the possibility. A more recent Sony Blog update has at least shared that the CC date was encrypted, and that they didn’t store any security code info for CCs. Well, at least that’s semi-good news.

So what’s a PSN subscriber to do?

Being one myself, I immediately asked myself that very question. Here’s what I’ve come up with:

  1. Do you follow best password handling practices? If not, change your passwords. One well known, but often ignored, password security practice is that you should NOT use the same password everywhere. Unfortunately, many people, including security professionals, don’t follow this practice. If you are one of those people, the first thing you need to do is go to all the important sites you visit and change your password. If someone has your email address and a password, that will get them into many popular sites you may frequent.
  2. Cancel/change your credit card. This one really sucks. It can be a pain to get new credit cards, mostly when you don’t know for sure whether it is entirely necessary. Unfortunately, I have to lean towards being safe and not sorry. If you shared your CC with PSN (it’s possible you may not have), you should probably get new cards. Granted, Sony does say the CC data was encrypted. So ultimately, it is up to you if you want to take the chance.
  3. Watch your credit information. There’s really nothing you can do about that fact that a lot of your PII data is out there. This is the same data bad guys use to setup fraudulent accounts in your name. Luckily, attackers didn’t get one crucial (at least in the US) piece of data; your social security number. Without this, they probably can’t setup financial accounts in your name. Nonetheless, you should still monitor your credit via your country’s credit agencies. You may even considering submitting a fraud alert or credit freeze, which will make it harder for attackers to create new accounts in your name.
  4. Remain vigilant for follow-up attacks. Since the attackers didn’t get Social Security numbers, they don’t have all they need to totally steal your identity. However, they often follow up these sorts of attacks with other attacks (email phishing), trying to gather any additional info they need. Furthermore, they can often leverage the information they’ve already stolen to help trick you into trusting them. So remain vigilant against phishing and social engineering attacks, asking you for private info.

The last question that I’m sure is one everyone’s mind, is how did Sony actually get hacked. The short answer is, we don’t know yet. Sony’s not sharing. There has been a number of rumors, though:

  • Geohot did it. This is the guy that hacked the Playstation 3’s DRM and copy protection. Sony sued him for it, and he settled the case (saying he’d leave Sony stuff alone). This guy’s smart enough to breach networks, but I’m pretty sure he didn’t go after PSN, mostly after settling with Sony. So I doubt this is the case.
  • “Anonymous” did it. Anonymous is that random group of hackers that went after HBGary. They also sided with Geohot during the PS3 hacking case, and likely launched DDoS attacks against Sony in early April. However, they claim they had nothing to do with this breach. I tend to believe it as Anonymous tends to stick more with headline grabbing stunts, than these highly illegal, malicious breaches. That said, some solo-Anonymous hackers may have acted alone.
  • The attack is the result of a custom PS3 firmware (called Rebirth). When Geohot hacked the PS3 DRM, he made it possible for homebrew coders (and pirates) to load their own modified firmware onto the PS3. These modification could allow playstation users to do all sorts of cool things that Sony didn’t originally intend the PS3 to do. However, some of the latest custom firmwares coming out of the PS3 “scene” included modifications that would allow hacked PS3 to regain access to PSN, or worse, the PSN developer network. One of those firmwares was called Rebirth. Due to the timing of Rebirth’s release, and some of it’s features, some people suspect it has something to do with how the PSN attackers were able to breach Sony’s PSN  network. In fact, it seems very likely that the modified firmware was at least used to fraudulently download PSN games without valid CCs. Of the rumors presented, this one seems most possible to me. That said, the creators of Rebirth have claimed they weren’t responsible either. However, they admit users have found interesting ways to use their firmware.

Besides those rumors, other experts have shared their own guesses about how this breach might have happened. For instance, one mentioned that it could have been a spear-phishing email, that got malware on an administrator’s computer. That guess is as good as any. After all, that’s basically how the Aurora attackers got into Google — it’s certainly possible.  Yet, it’s still just a guess. Until Sony, or someone else, shares the real story, all we can do is wonder.

Not  knowing exactly how the breach happened makes it harder to give you a specific defense that can help prevent this from happening to you, but that’s where good ‘ole “Best Practices” come in (something we also learned during the HBGary incident). Two things come to mind for me:

  1. Defense-in-Depth. Security guys hear this so often that it stops feeling relevant. It still is. It’s simple math. The more defensive layers you build up — things like Firewalls, IPS, AV, application control, cloud reputation, etc. — the better statistical chance you have of detecting and blocking an attack. That is why WatchGuard created our XTM appliance. We want to make it as easy as possible to incorporate as many defenses as possible, in one easy to manage appliance, and to have a platform that allows you to evolve your defenses in the future. That said, when most people think “Defense-in-Depth,” they only think about the hard, preventive technology measures, such as the ones I’ve mentioned above. They don’t think as much about the softer security measures, such as visibility tools that may also help you recognize unusual incidents, like security breaches. When you are building your layers of defense, don’t forget to include products that offer visibility tools as well (we have great visibility tools, and plan to make them even better).
  2. Focus your perimeter on your data center! One of my predictions for this year was that your perimeter will not go away. It will just shrink, harden, and focus on your data center. The huge increase in mobile workforce and technologies, has caused the security industry to largely focus on mobile security technologies — for good reason. However, just because you need mobile defenses, doesn’t mean you can tear down the walls around your castle. Instead, the huge increase in big data breaches, like this PSN incident, has shown that we need strong, evolving perimeter defenses around our data centers, today more than ever. Your perimeter shouldn’t only protect your data center from the world, but also from your own workforce. Based on what Sony’s doing to improve their PSN security, it sounds like they now agree with my prediction.

This PSN data breach will surely have resounding affects on network security for years to come. I wouldn’t be surprised to see it cause PCI changes, trigger politicians to suggest new laws, and result in new business regulations. I will continue to follow the story and post any interesting new details I find. —  Corey Nachreiner, CISSP. (@SecAdept)

Adobe Partially Corrects Flash Zero Day in Reader and Acrobat

Severity: High

22 April, 2011


  • These vulnerabilities affects: Recent versions of Adobe Reader, and Acrobat
  • How an attacker exploits it: In various ways, but most commonly by enticing your users into opening a Word or Excel document containing malicious Flash
  • Impact: In the worst case, an attacker can execute code on your computer, potentially gaining control of it
  • What to do: If you use these popular Adobe products, you should download and install their various updates as soon as possible.


Typically, Adobe’s quarterly Patch Day falls on the same Tuesday as Microsoft Patch Day (the second Tuesday of the month). However, a recent zero day Flash exploit circulating in the wild has encouraged Adobe to release an out-of-cycle patch early.

Yesterday, Adobe released updates for Reader and Acrobat to fix an unpatched Flash vulnerability, which attackers are exploiting in the wild. Since the flaw lies within a Flash component that ships with many Adobe products, it affects Reader and Acrobat as well. I mentioned this flaw already in a post a week or so ago.

As usual, Adobe doesn’t describe this flaw in any technical detail. However, they do mention that the flaw lies within the authplay.dll Flash component, which has already been subject to a very similar  previous vulnerability. By enticing you into opening specially crafted, Word, Excel, or maybe even PDF documents, attackers can leverage this unspecified flaw to execute code on your computer, with your resources. As usual, if you are an administrator, it’s game over.

See Adobe’s APSB11-08 bulletin for more details about this update.

Solution Path:

Adobe has released updates for Reader and Acrobat to fix this flaw in some of their products. They fully patch Acrobat, however, they have not released a fix for Reader X for Windows. Adobe argues that Reader X’s default security settings should protect you from these attacks, so they do not plan to release the Reader X update for Windows till their normal patch day, next June.

If you use any of the software below, we recommend you download and deploy the corresponding updates as soon as possible, or let Adobe’s automatic updater do it for you. 

For All WatchGuard Users:

Some of WatchGuard’s Firebox models allow you to prevent your users from downloading certain types of files via the web (HTTP) or email (SMTP, POP3). If you like, you can temporarily mitigate the risk of some of these vulnerabilities by blocking various Adobe and MS Office related files using your Firebox’s proxy services. Such files include, .DOC, .XLS,  .PDF, .SWF, .DIR, .DCR, and .FLV. That said, many websites rely on these files to display interactive content. Blocking them could prevent some sites from working properly. Furthermore, many businesses rely on these file types to share documents. Blocking them would affect legitimate files as well. For that reason, we recommend the updates above instead.

Nonetheless, if you choose to block some Adobe  and Office files, follow the links below for video instructions on using your Firebox proxy’s content blocking features to block files by their file extensions:


Adobe has released updates to fix these vulnerabilities.


This alert was researched and written by Corey Nachreiner, CISSP. (@SecAdept)

Apple Releases OS X, Safari, and iOS Security Updates

Yesterday, Apple released a handful of security advisories for various products, including:

The Snow Leopard update only fixes one security issue. If you read my “Fraudulent Certificate” post from a few weeks ago, you know that attackers were able to get their grubby hands on some fraudulently-issued, but technically legitimate digital certificates for some pretty well known domains. At the time, Microsoft had released a fix for Windows to ensure that it would not consider these certificates legitimate. This small OS X updates does the same thing for Snow Leopard.

The Safari update, which is probably the most critical of them all, fixes two flaws in the popular browser’s WebKit component. By enticing you to a web page containing malicious code, an attacker could leverage this flaw to execute code on your computer, with your privileges. Attackers commonly exploit these type of flaws in drive-by download attacks.

The two iOS updates also fix various code execution vulnerabilities that could occur on iPhones, iPods, and iPads. The worst is similar to the Safari vulnerabilities above. If an attacker can lure you to a special site with your iPhone, he could exploit this vulnerability to execute code. Since certain applications run on iPhones as root, this could give attackers full control of the device. In the real-world, these sorts of iOS flaws are more commonly leveraged by jailbreakers; to gain control of their phones. However, nothing is stopping malicious attackers from leveraging the same techniques to spread mobile malware.

If you have any of these products, you should download and install the updates recommended in each advisory, or just let Apple’s automatic update software do it for you. — Corey Nachreiner, CISSP. (@SecAdept)

What is the TCP Split-Handshake Attack and Does It Affect Me?

If you’ve followed security news over the past few days, you’ve probably seen a lot of hoopla about a TCP split-handshake vulnerability that can affect firewalls and other networking and security devices. Many of the Media’s articles characterize this complicated TCP connection attack as, “a hacker exploit that lets an attacker trick a firewall and get into an internal network as a trusted IP connection” or as a “hole” in firewalls. I’m not sure that these descriptions properly characterize this vulnerability, and I suspect many administrators may not really understand how this attack works (let alone what it does and doesn’t allow an attacker to accomplish). I hope to try and rectify that in this post.

Before I jump into a description of this attack, WatchGuard XTM owners probably want to know if they are vulnerable to this attack. The answers is, No. Our XTM appliances do not allow TCP split-handshake connections. Furthermore, we also enable a feature called TCP SYN checking by default on our devices, which further protects against TCP state-based attacks. Later in this post, I’ll go into more detail on how we tested this, but for now, know that our appliances are not susceptible to this attack. With that out of the way, let’s look at this attack.

What is the TCP Split-Handshake Attack?

To understand the TCP split-handshake attack you need to understand how network devices build TCP connections. I’m going to assume you are familiar with the TCP three-way handshake. If not, this guide will walk you through it. Most network administrator understand this three-way handshake technique quite well, and many gateway security devices (like stateful firewalls) are designed to enforce it. However, less people know about another legitimate way to build TCP connections, called the simultaneous-open handshake. With a simultaneous open connection, both a client and server send a SYN packet to each other at about the same time. Then both sides also send ACK packets to each other in response. This slightly different variant of the TCP handshake doesn’t happen much in the real world, however, it’s a perfectly legitimate way to start a TCP connection (according to RFC 793).

This brings us to the TCP split-handshake (also sometimes called a Sneak ACK attack). As the name suggests, the split-handshake combines aspects of the normal three-way handshake with the simultaneous-open handshake. Essentially, a client sends a SYN packet to a server, intending to complete a normal three-way handshake. However, rather than completing the client’s three-way handshake, a malicious server starts by replying as though it were doing a simultaneous-open connection, and then starts its own three-way handshake in the other direction — from server to client. So in essence, even though the client started the connection to the server, the logical direction of this connection gets reversed.

This is a fairly quick and high-level description of this attack. If you are a technically oriented person that wants to know the nitty-gritty details, I highly recommend you read, The TCP Split Handshake: Practical Effects on Modern Network Equipment. It is the defacto document describing this attack. If you just want the highlights, I also recommend this article. It characterizes the attack well, without diving too deep into the technical detail.

So What Can an Attacker Accomplish with this Attack?

OK. At a high-level, you now know that the TCP split-handshake attack is a sneaky way that a malicious server can reverse the logical direction of a connection that a client initiates. But what exactly does that mean? What can an attacker do with that, and how bad is it?

First, you should know that this attack cannot punch holes in your firewall, willy-nilly, without user interaction. A key mitigating factor to the attack is that a client within your network must first make a connection to a malicious server on the internet, before this attack can even start. Some of the descriptions of the attack, which claim an external attacker can trick a firewall into giving them access as a trusted IP, seem to leave this fact out. So if you were worried that external attackers can just hop through your firewall on their own, don’t be.

Furthermore, when this attack succeeds, the attacker isn’t even getting free reign on the victim computer or your network either, instead the attacker has only reversed the logical direction of your client’s initial connection. This could be bad, as I will explain in a second, but it is not immediate full access to the victim computer or your network.

What this attack really comes down to is an IPS (or other security content-filtering) evasion attack. The key issue is this attack logically reverses the direction of a perfectly legitimate connection your client initiated. This doesn’t really mean the attacker can do anything new on the victim computer, but it may confuse gateway security scanning services that protect your client. Many security systems, like IPS, antivirus (AV), and other content-filtering systems rely on the direction of traffic to decide how to scan it, or even if they will scan it. If an attacker can confuse the gateway devices as to the direction of traffic, it may be able to evade security scanning or IPS policies.

Let’s look at a real world example. Say an unpatched client in your network connects to a malicious drive-by download web server that is not leveraging the split-handshake attack. The malicious web site tries to get your client to execute some javascript that forces your client to download malware. If you have gateway IPS and AV, your IPS may detect the malicious javascript, or your AV may catch the malware. In either case, your security scanning would block the attack.

However, if the malicious web server adds the TCP split-handshake connection to the same attack, your IPS and AV systems may be confused by the direction of the traffic, and not scan the web server’s content. Now the malicious drive-by download would succeed, despite your gateway security protection.

So to summarize, the TCP split-handshake attack may help malicious servers to bypass security scanning services on your gateway security devices. However, it will not allow external attackers to bypass your firewall policies, and it requires an internal client start the connection in the first place.

Is My X-brand Network Device at Risk?

Now you know the true impact of TCP split-handshake attacks. They don’t allow attackers to totally bypass firewalls without user interaction, but they could help attackers evade your security services, assuming your clients connect to them. The next question is, are my network devices vulnerable?

To help you answer that question, I’m going to share how I tested WatchGuard’s XTM appliances.

The authors of the paper I mentioned earlier (The TCP Split Handshake: Practical Effects on Modern Network Equipment) included a special Ruby script in their paper called fakestack.rb. This script sets up a server on port 8080, that listens for incoming connections, and replies to those connection using the TCP split-handshake connection method. If this malicious connection succeeds, the script reports, “The handshake’s a LIE!” You can use this script to test your network equipment, and see whether or not it allows TCP split-handshake connections to complete.

I recommend you use fakestack.rb with a Linux computer. I used my Backtrack 4 installation. Fakestack.rb requires another ruby script called PacketFu, which in turn requires something called PcapRub. The whitepaper above explains these dependencies. Once your have all this installed, you simply have to disable your computer’s local host firewall (on 8080 at least), and run fakestack.rb (sudo fakestack.rb eth0 8080).

Once you have fakestack running, I recommend you first get a client to connect to it directly, without any firewall or gateway device in the mix. This way you can see what happens when the split-handshake connection succeeds. Open a web browser (IE or Firefox) on a Windows computer that is on the same network, and try to connect to the IP of the computer running fakestack, on port 8080 (http://x.x.x.x:8080). You will not see anything in the web browser. However, if you look at fakestack’s output, you will see it generating packets, sending certain replies, and if the attack works, it returns that “handshake’s a lie” message.

Once you have fakestack working, testing your own network gear is simple. Simply put the fakestack computer on the external side of your firewall, IPS, or security appliance, and get an internal client to try to connect to fakestack. If fakestack returns the handshake is a lie message, then you know your security gear may be vulnerable to this attack. However, if you don’t get the handshake is a lie message, fakestack wasn’t able to complete the split-handshake connection, and your device must be doing something to prevent it.

This is the test I did with our XTM appliances. When a client behind an XTM appliance tries to connect to fakestack, the connection never completes. Meanwhile, the XTM logs report:

2011-04-15 19:18:37 Deny 63316/tcp 8080 63316 0-External Firebox tcp syn checking failed 40 31 (Internal Policy) proc_id=”firewall” rc=”101″ tcp_info=”offset 5 A 1845100933 win 64″
2011-04-15 19:18:37 Deny 63316/tcp 8080 63316 0-External Firebox Denied 44 31 (Unhandled External Packet-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 6 S 794513233 win 64″

Our packet handling engine does not recognize split-handshake connections as legitimate connections. Furthermore, split-handshakes trigger our TCP syn checking feature too, which is enabled by default.

This test shows that WatchGuard devices don’t allow split-handshake connections. You can use the same test to figure out whether or not your other network security devices handle TCP split-handshake connections properly.


So in summary:

  • The TCP split handshake attack is not an attack that allows attackers to punch holes in firewalls without user interaction. However, it is a significant vulnerability that could allow attackers to evade security services like IPS, assuming the attacker can entice the victim to a malicious server.
  • WatchGuard XTM appliances are not vulnerable to the TCP split-handshake attack, since we do not allow split-handshake connections. We tested this using a script designed by the discovers of the attack, called fakestack.rb.
  • If you want to know how your other network gear responds to TCP split-handshake connections, use fakestack.rb to test.

I hope this post helped clear up some potential misinterpretations about this complex vulnerability, and has shown you its true severity and impact. Feel free to share your thoughts and ideas about this flaw in the comments section. I find it quite interesting and would love to discuss it. — Corey Nachreiner, CISSP. (@SecAdept)

Privacy Bill of Rights – Right to Accountability, part 2

Title I of the Commercial Privacy Bill of Rights Act of 2011 is comprised of two rights – the Right to Security and the Right to Accountability. This posting focuses on the second part, the Right to Accountability.

Similar to the Right to Security, this section is short. In essence it says that each “covered entity” (see the previous post for what that entails), shall:

1. Have reasonable accountability for the adoption and implementation of policies consistent with this Act;

2. Develop a process for responding to non-frivolous individual complaints about how their personally identifiable information (PII) is collected, used and managed;

3. And lastly, document and communicate how it complies with this Act upon request from an authorized party, such as the FTC.

What this section really says can be narrowed down to one word: POLICY

Legislation aside, if your businesses or organization manages sensitive data, you should already have a formal, written policy as to how information is safeguarded, managed and accounted. So for many, this requirement is nothing new to what they should already have in place.

That being said, there are many SMB organizations that would be affected by this Act and do not have a security policy in place. It follows then, that for this reason, requiring businesses to have a security policy in place may be extremely beneficial for businesses and consumers.

And the easiest way to make a policy? Borrow from the Deming Wheel.

The Deming Wheel

Here is a brief outline to writing any business process or policy:

* PLAN – put your plan in writing, assign an owner, and define how your business will comply with this Act;

* DO – put your plan in place, test it, train others on it and make it known in the organization;

* CHECK – make a checklist, regularly audit the process, verify and document results;

* ACT – improve on the process where possible.

In summary, the whole issue of accountability boils down to putting data security policies in place that are “proportional to the size and structure” of your business or organization. Even if this Act does not become law, creating a formal security policy is certainly the prudent thing to do for any business.

The next post will be on Title II, the Right to Notice and Individual Participation.

Another Month, Another Zero Day Flash Vulnerability

According to an Adobe security advisory, Flash Player suffers from a zero day vulnerability, which attackers are currently leveraging in the wild to execute malicious code on victim computers.

It seems like just last month I described this exact same zero day Adobe Flash vulnerability…. oh, wait. That’s because I did!

Ok, fine. They aren’t technically exactly the same, but on a functional level they might as well be. Though Adobe never gives much technical detail in their advisories, both the old and new vulnerability lie within Flash’s Authplay.dll component. In both cases, attackers embed malicious SWF files within Office documents. Last month, they used Excel documents, this month, they go for Word documents. Finally, in both cases, if you open said malicious Office document on a computer with Flash installed, the specially crafted SWF file can execute code with your privileges, and allow an attacker to install pretty much any malware he wants on your computer.

As with last month’s Flash zero day, Adobe just recently learned of this flaw from reports of attackers exploiting it in the wild, and haven’t had time to patch it yet. They plan to release Adobe Flash Player and Acrobat X updates that will fix this issue as soon as they can (they say they are still scheduling it). However, they do not intend to release a Reader X update till June, since Reader X’s default sandbox setting should prevent this exploit from working.

Like before, I recommend you warn your users about opening Word documents attached to strange emails. If you like, you could use the proxies on our XTM appliances to block all Word attachments. However, most organizations need to allow them for business. I will let you know when Adobes updates their products in Security Alerts posted here. Corey Nachreiner, CISSP



Privacy Bill of Rights – Right to Security and Accountability, part I

In the latest Draft of the “Commercial Privacy Bill of Rights Act of 2011,” the first Title, “Right to Security and Accountability” is actually quite short – in fact, the Right to Security section contains just 53 words. The key provision reads, “…to require each covered entity to impose reasonable security measures to protect covered information it collects and maintains.”

First, what is a “covered entity?” The Act defines a covered entity to be: any person that collects, uses, transfers or maintains covered information concerning more than 5,000 individuals during any consecutive 12-month period. Keep in mind; a “person” can also be a corporation, non-profit organization, or any other entity that the Federal Trade Commission has authority over.

What this says is that the Act will affect just about every size and type of organization that collects records on more than 5,000 people a year. That is huge in terms of scope!

Next, what is “reasonable security?” This is fairly easy to define, although it may seem vague. In law, the “reasonable standard” is often deemed to be a standard for what is fair and appropriate under usual and ordinary circumstances.

Here, the industry (both hackers and security vendors) will play a significant role in helping to define what is “reasonable security.” Certainly having a firewall is a start. But, is a firewall from 2003 “reasonable” by today’s standards? Possibly not. Given that hackers are more sophisticated than ever and utilize extremely nefarious techniques that constantly evolve, the traditional firewall from even a few years ago may not be sufficiently capable to meet today’s reasonable security needs.

Next we answer what is “covered information.” Covered information means personally identifiable information (PII), unique identifier information (UII) and any information that is collected, used or maintained in connection with PII or UII that may be used to identify an individual.

Some industry regulations, such as PCI DSS, have similar requirements, so for many businesses this is nothing unusual. The Act specifies that home addresses, email addresses, telephone numbers, cookies, user IDs, as well as the usual suspects of social security numbers or other government issued identifiers are all “covered information.”

Bottom line: Personal privacy is worthy of protection, which is exactly what this Act aims to achieve. The scope of this Act will certainly mean that nearly every business will have to, at a minimum, reexamine their security posture to ensure that they are reasonably secure. In the wake of the Epsilon breach, the “Right to Security” seems unquestionable. What remains, then, are the questions of the other provisions in this Act, and what they mean to consumers and businesses.

More to come on part two, where we examine the second half of Title I, “Right to Security and Accountability.” There we analyze the impact of “accountability.”

Thirteen Windows Bulletins Patch 18 Security Holes

Critical SMB, DNS, and ActiveX Flaws Corrected

Severity: High

12 April, 2011


  • These vulnerabilities affect: All current versions of Windows and components that ship with it
  • How an attacker exploits them: Multiple vectors of attack, including sending specially crafted network traffic or enticing your users to view malicious images
  • Impact: Various results; in the worst case, an attacker can gain complete control of your Windows computer
  • What to do: Install the appropriate Microsoft patches immediately, or let Windows Automatic Update do it for you.


Today, Microsoft released thirteen security bulletins describing 18 vulnerabilities that affect Windows and components that ship with it. Each vulnerability affects different versions of Windows to varying degrees. However, a remote attacker could exploit the worst of these flaws to gain complete control of your Windows PC. The summary below lists the vulnerabilities, in order from highest to lowest severity.

  • MS11-019: SMB Client Remote Code Execution Vulnerability

Microsoft Server Message Block (SMB) is the protocol Windows uses for file and print sharing. According to Microsoft, the Windows SMB client suffers from two security vulnerabilities which attackers could leverage to execute malicious code. By enticing one of your users to connect to a malicious SMB server, or by sending a specially crafted SMB message, an attacker can exploit of either the flaws to gain complete control of a vulnerable Windows computer. However, firewalls like WatchGuard’s XTM appliances typically block SMB traffic from the Internet, making these vulnerabilities primarily an internal risk. That said, many types of malware leverage SMB vulnerabilities to self-propagate within networks, once they infect their first victim.
Microsoft rating: Critical

  • MS11-020: SMB Server Remote Code Execution Vulnerability

The Windows SMB Server also suffers from a code execution vulnerability. By sending a specially crafted SMB packet, an attacker can exploit this flaw to gain complete control of a vulnerable Windows computer. Again, this vulnerability primarily poses an internal risk since firewalls block SMB.
Microsoft rating: Critical

  • MS11-027: Cumulative ActiveX Kill Bit Update

Microsoft and external researchers have identified several Microsoft and third party ActiveX controls that suffer various security vulnerabilities. By enticing one of your users to a malicious website, an attacker could exploit any of these ActiveX controls to execute code on your user’s computer, with that user’s privileges. Like most Windows vulnerabilities, if your user has administrative privileges, the attacker would gain complete control of the user’s PC. This update sets the Kill Bit for all the vulnerable ActiveX controls, thereby disabling them in Windows. For more details about which ActiveX controls are disabled, see the Vulnerability Information section of Microsoft’s bulletin.
Microsoft rating: Critical.

  • MS11-028: .NET Framework Stack Corruption Vulnerability

The .NET Framework is software framework used by developers to create new Windows and web applications. Unfortunately, the x86 JIT compiler within the .NET Framework suffers from a complex vulnerability having to do with it incorrectly compiling certain types of function calls. The scope and impact of this vulnerability differs greatly depending on the Web or Windows .NET application you’ve designed. In the worst case, an attacker could exploit this flaw to gain complete control of a Windows computer. However, you are only vulnerable if you are hosting a custom web application creating in a certain way, allow others to upload custom .NET web applications, or created a special .NET Windows application. If you do create .NET application, see the Vulnerability Information section of Microsoft’s alert for more details about this issue. In any case, if you’ve installed .NET Framework, you should install this update even if you don’t create your own .NET applications.
Microsoft rating: Critical.

  • MS11-029: GDI+ Integer Overflow Vulnerability

The Graphics Device Interface (GDI+) is one of the Windows components that handles images, specifically 2D vector graphics. GDI+ suffers from an integer overflow vulnerability involving its inability to properly handle specially malformed EMF images. By luring one of your users into viewing a malicious image, perhaps hosted on a web site, an attacker could leverage this flaw to execute code on that user’s computer, with that user’s privileges. If your users have local administrative privileges, the attacker gains full control of their computer.
Microsoft rating: Critical

  • MS11-030: Windows DNS Client Code Execution Vulnerability

The Windows DNS client suffers from an unspecified vulnerability having to do with its inability to handle specially crafted Link-local Multicast Name Resolution (LLMNR) DNS queries. There are two way an attacker could exploit this flaw, which depend on what version of Windows he targets. Against Windows XP and Server 2003 computers, an attacker needs to log in to your computer locally with valid credentials, and then run a special program which would exploit this flaw to elevate his privileges. Since this scenario requires the attacker have local access to your computers and valid credentials, it poses less risk. However, the flaws poses much greater risk to Windows Vista, 7, and Server 2008 computers. Against these versions of Windows, an attacker only has to send a specially crafted LLMNR broadcast message to leverage this flaw to execute code with the NetworkService accounts privileges, which would give him significant control of your computer.
Microsoft rating: Critical.

VBScript and JScript are both scripting languages created by Microsoft, and used by Windows and its applications. According to two Microsoft Bulletins, these scripting engines suffer from two code execution vulnerabilities. The lesser risk flaw is a recap of MS10-022, which we described in a previous alert. This is a code execution issue that only crops up when you press F1 in a very particular situation. However, the second vulnerability is an integer overflow flaw an attacker can easily trigger with a specially crafted script. By enticing you to a specially crafted web page, an attacker could leverage this flaw execute code on your computer with your privileges. If you have admin rights, then it’s game over for your PC.
Microsoft rating: Critical and Important.

  • MS11-032: OpenType Font CFF Driver Code Execution Vulnerability

Windows ships with many fonts, including the OpenType Compact Font Format (CFF) font. Unfortunately, the driver that helps Windows display the OpenType CFF font doesn’t properly validate certain parameter values. Attackers can exploit this flaw in one of two ways, depending on whether they are targeting newer or older versions of Windows. Against older versions of Windows (XP and 2003) an attacker would need to run a specially crafted program on one of your Windows computers in order to gain complete control of that system, regardless of the attacker’s original user privileges. The attacker needs to have local access to one of your computers in order to run his malicious program. However, newer versions of Windows (Vista, 2008, 7) have an auto preview feature that will automatically preview fonts in a directory. By luring one of your users into opening a file share that contains a maliciously crafted OpenType font, an attacker could leverage this flaw to gain complete control of newer Windows computers. As an aside, this flaw is almost identical in nature to MS11-007.
Microsoft rating: Critical

  • MS11-024: Fax Cover Page Editor Memory Corruption Vulnerability

The Windows Fax Cover Page Editor (fxscover.exe) is just what it sounds — a program that helps you create a cover page for faxes. It suffers from an unspecified memory corruption vulnerability due to its inability to handle specially crafted fax cover pages (.cov). By enticing one of your users to open a specially crafted .cov, an attacker could exploit this flaw to execute code on that user’s computer, with their privileges. As usual, if your users have administrative privileges, the attacker inherits them.
Microsoft rating: Important.

  • MS11-026: MHTML Information Disclosure Vulnerability

In our February advanced notification post, we mentioned a zero day MHTML vulnerability that was similar to a Cross-site Scripting (XSS) vulnerability.The flaw involves the Windows MHTML or MIME HTML component, which is used to handle special web pages that include both HTML and MIME (typically pictures, audio, or video) content contained in one file. If an attacker can entice you to visit a specially crafted web-page, or click a malicious link, he could exploit this flaw in much the same way he might exploit a Cross-Site Scripting (XSS) vulnerability; to steal your cookies, redirect your browser to malicious sites, or essentially take any action you could on a web site. This update finally fixes that February zero day flaw.
Microsoft rating: Important.

  • MS11-033 : WordPad Code Execution Vulnerability

WordPad is the free text editor that comes with Windows. It suffers from an unspecified vulnerability involving its text converters inability to parse specific fields in a specially crafted Word document. By enticing one of your users to open such a document, an attacker could exploit this flaw to execute code on that users computer. If the user is a local administrator, the attacker gains full control. This flaw only affects Windows XP and Server 2003.
Microsoft rating: Important

  • MS11-034 Windows Kernel-Mode Drivers Elevation of Privilege Vulnerabilities

The kernel is the core component of any computer operating system. Windows also ships with a kernel-mode device driver (win32k.sys) which handles many kernel-level devices. This kernel-mode driver suffers from two elevation of privilege vulnerabilities. Though these flaws differ technically, they share the same scope and impact. By running a specially crafted program, a local attacker could leverage these flaws to gain complete control of your Windows computers. However, the attacker would first need to gain local access to your Windows computers using valid credentials. This factor significantly reduces the risk of these flaws.
Microsoft rating: Important

Solution Path:

Microsoft has released patches for Windows which correct all of these vulnerabilities. You should download, test, and deploy the appropriate patches throughout your network immediately. If you choose, you can also let Windows Update automatically download and install these for you.




* Note: Server Core installations not affected.


Due to the complicated, version-dependent nature of .NET Framework updates, we recommend you see the Affected & Non-Affected Software section of Microsoft’s Bulletin for patch details.


* Note: Server Core installations not affected.


MS11-031 & MS11–022

Due to the complicated, version-dependent nature of VBScript and JScript updates, we recommend you see the Affected & Non-Affected Software sections of Microsoft’s Bulletins for patch details:



This Fax Cover Editor update requires multiple patches. Please see the Affected & Non-Affected Software section of Microsoft’s Bulletin for more details.




For All WatchGuard Users:

Attackers can exploit these flaws using diverse exploitation methods. A properly configured firewall could help mitigate the risk of some of these issues. That said, the Firebox cannot protect you from local attacks, nor can it prevent attacks that leverage normal HTTP traffic. Therefore, installing Microsoft’s updates is your most secure course of action.


Microsoft has released patches correcting these issues.


This alert was researched and written by Corey Nachreiner, CISSP.

What did you think of this alert? Let us know at
More alerts and articles: Log into the LiveSecurity Archive.

Malicious Office Documents Could Open Doors into Your Network

Severity: High

12 April, 2011


  • These vulnerabilities affect: Most current versions of Microsoft Office, and the components that ship with it
  • How an attacker exploits it: Typically by enticing one of your users to open a malicious Office document
  • Impact: In the worst case, an attacker executes code on your user’s computer, gaining complete control of it
  • What to do: Install Microsoft Office updates as soon as possible, or let Microsoft’s automatic update do it for you


As part of today’s Patch Day, Microsoft released two security bulletins describing eleven vulnerabilities found in Excel and other components that ship with most current versions of Microsoft Office for Windows and Mac.

Though the eleven vulnerabilities differ technically, and affect different Office components, they result in the same problem. If an attacker can entice one of your users into downloading and opening a maliciously crafted Office document, he can exploit any of these vulnerabilities to execute code on a victim’s computer, usually inheriting that user’s level of privileges and permissions. If your user has local administrative privileges, the attacker gains full control of the user’s machine.

According to Microsoft’s bulletins, an attacker can exploit these flaws using many different types of Office documents. In one bulletin, Microsoft specifically states Excel documents are vulnerable. However, they also mention any “Office files” in their other alert. Therefore, we recommend you beware of all unexpected Office documents.

If you’d like to learn more about each individual flaw, drill into the “Vulnerability Details” section of the security bulletins listed below:

  • MS11-021: Nine Excel Code Execution Vulnerabilities, rated Important
  • MS11-023: Two Office Code Execution Vulnerabilities, rated Important

Solution Path

Microsoft has released patches for Office to correct all of these vulnerabilities. You should download, test, and deploy the appropriate patches throughout your network immediately, or let the Microsoft Automatic Update feature do it for you.


Excel update for:


For All WatchGuard Users:

While you can configure certain WatchGuard Firebox models to block Microsoft Office documents, some organizations need to allow them in order to conduct business. Therefore, these patches are your best recourse.

If you want to block Office documents, follow the links below for video instructions on using your Firebox proxy’s content blocking features by file extensions. Some of the file extensions you’d want to block include, .DOC, .XLS, .PPT, and many more (including the newer Office extensions that end with “X”). Keep in mind, blocking files by extension blocks both malicious and legitimate documents.


Microsoft has released Office updates to fix these vulnerabilities.


This alert was researched and written by Corey Nachreiner, CISSP.

IE Update Corrects Code Execution and Information Disclosure Flaws

Severity: High

12 April, 2011


  • This vulnerability affects: All current versions of Internet Explorer, running on all current versions of Windows
  • How an attacker exploits it: Typically, by enticing one of your users to visit a malicious web page
  • Impact: In the worst case an attacker can execute code on your user’s computer, gaining complete control of it
  • What to do: Deploy the appropriate Internet Explorer patches immediately, or let Windows Automatic Update do it for you


In a security bulletin released today as part of Patch Day, Microsoft describes five new vulnerabilities in Internet Explorer (IE) 8.0 and earlier versions, running on all current versions of Windows. Researchers reported four of the new vulnerabilities privately to Microsoft, while the other one was disclosed publicly. They rate the aggregate severity of these new flaws as Critical.

The five vulnerabilities differ technically, but three of the worst flaws share the same general scope and impact. This trio of flaws all involve memory corruption issues having to do with how IE handles various HTML elements, including MSHTML objects and page layouts. If an attacker can lure one of your users to a web page containing malicious web code, he could exploit any one of these three vulnerabilities to execute code on that user’s computer, inheriting that user’s privileges. Typically, Windows users have local administrative privileges, in which case the attacker gains complete control of the victim’s computer. Attackers often leverage these type of code execution vulnerabilities to launch Drive-by Download attacks.

The remaining two issues are less severe  information disclosure and click-jacking vulnerabilities.

Keep in mind, today’s attackers commonly hijack legitimate web pages and booby-trap them with malicious code. Typically, they do this via hosted web ads or through SQL injection and XSS attacks. Even recognizable and authentic websites could pose a risk to your users if hijacked in this way.

If you’d like to know more about the technical differences between these flaws, see the “Vulnerability Information” section of Microsoft’s bulletin. Technical differences aside, the memory corruption flaws in IE pose significant risk. You should download and install the IE cumulative patch immediately.

Solution Path:

These patches fix serious issues. You should download, test, and deploy the appropriate IE patches immediately, or let Windows Automatic Update do it for you.

Internet Explorer 6.0

Internet Explorer 7.0

Internet Explorer 8.0

    * Note: These flaws do not affect Windows Server 2008 administrators who installed using the Server Core installation option.

For All WatchGuard Users:

These type of attacks typically look like normal-looking HTTP traffic, which you must allow if your network users need to access the World Wide Web. Therefore, the patches above are your best solution.


Microsoft has released patches to fix these vulnerabilities.


This alert was researched and written by Corey Nachreiner, CISSP.

What did you think of this alert? Let us know at

More alerts and articles: Log into the LiveSecurity Archive.

%d bloggers like this: