Login  |  Register  |  Contact


Saturday, February 22, 2014

Apple Bug Bad. Patch Now. Here Are Good Writeups

By Rich

Yesterday Apple released iOS 7.06, an important security update you have probably seen blasted across many other sites. A couple points:

  • Apple normally doesn’t issue single-bug out-of-cycle security patches for non-public vulnerabilities. They especially don’t release a patch when the same vulnerability may be present on OS X but there isn’t an OS X patch yet. I hate speculating, especially where Apple is concerned, but Apple has some reason for handling this bug this way. Active exploitation is one possibility, and expectations of a public full disclosure is another.
  • The bug makes SSL worthless if an attacker is on the same network as you.
  • OS X appears vulnerable (10.9 for sure). There is no public patch yet. This will very likely be remediated very quickly.
  • A lot of bad things can be done with this, but it isn’t a remotely exploitable malware kind of bug (yes, you might be able to use it locally to mess with updates – researchers will probably check that before the weekend is out). It is bad for Man in the Middle (MitM) attacks, but it isn’t like someone can push a button and get malware on all our iOS devices.
  • It will be interesting to see whether news outlets understand this.

The best security pro article is over at ThreatPost.

The best technical post is at ImperialViolet. They also have a test page.

If you are in an enterprise, either push the update with MDM as soon as possible, or email employees with instructions to update all their devices.


Monday, November 16, 2009

Why You Should Take the Adobe Flash Origin Issues Seriously

By Rich

I was talking with security researcher Mike Bailey over the weekend, and there’s a lot of confusion around his disclosure last week of a combination of issues with Adobe Flash that lead to some worrisome exploit possibilities. Mike posted his original information and an FAQ. Adobe responded, and Mike followed up with more details.

The reason this is a bit confusing is that there are 4 related but independent issues that contribute to the problem.

  1. A Flash file uploaded to a site always runs in the context of that site. This one isn’t any big surprise: any time you allow someone to upload executable code to your site, it’s probably game over from a security perspective. This is why major sites restrict the kinds of content users can upload, and many file types won’t run in the browser anyway. For example, even if you can upload a JavaScript file to a server, you can’t execute that file and have it run in the context of that server. Some other file types will execute in major browsers, but not many, and we control them using content headers and file extensions. (Technically file extensions shouldn’t matter, but a lot of sites rely on them anyway… especially for images).
  2. Flash ignores file extensions and content headers. The Flash player built into all of our browsers will execute any file that has Flash file headers. This means it ignores HTTP content headers. Some sites assume that content can’t execute because they don’t label it as runnable in the HTML or through the HTTP headers. If they don’t specifically filter the content type, though, and allow a Flash object anywhere in the page, it will run – in their context. Running in context of the containing page/site is expected, but execution despite content labeling is often unexpected and can be dangerous. Now most sites filter or otherwise mark images and some other major uploadable content types, but if they have a field for a .zip file or a document, unless they filter it (and many sites do) the content will run.
  3. Flash files can impersonate other file types. A bad guy can take a Flash program, append a .zip file, and give it a .zip file extension. To any ZIP parser, that’s a valid zip file, and not a Flash file. This also applies to other file types, such as the .docx/pptx/xlsx zipped XML formats preferred by current versions of MS Office. As I mentioned in the second point, many servers screen potentially-unsafe file types such as zip. Such hybrid files are totally valid zip archives, but simultaneously executable Flash files. If the site serves up such a file, (as many bulletin boards and code-sample sites do), the Flash plugin will manage to recognize and execute the Flash component, even though it looks more like a zip file to humans and file scanners.
  4. Flash does not respect the same origin policy. When I first started programming web applications, when Lynx and Mosaic were the only browsers, we worried quite a bit that if you set a cookie for one site, any other site could read it. That’s where the same origin policy for browsers started: a browser would only allow sites to read their own stored cookies, and prevent them from seeing cookies from other sites. As we added JavaScript, this became even more important – since JavaScript is executable code, any scripts should only a) run for and b) have access to the site that sent them to the browser, even if the code originated someplace else. If this didn’t work, JavaScript code on one site could manipulate and read data from any other site. Or I could host a JavaScript file on my site and use it to steal information from any other site that linked back to my code (referencing JavaScripts on remote servers is a common programming practice). With Flash I can host a file on one site and present it on another, and it runs with the rights to access both sites. Mike shows an example of this where a file on mail.google.com communicates with JavaScript on skeptical.org (his site). Since Flash has hooks into JavaScript, it allows one site to manipulate the JavaScript on another site… which shouldn’t ever happen.

Thus we have four problems – three of which Adobe can fix – that create new exploit scenarios for attackers. Attackers can sneak Flash files into places where they shouldn’t run, and can design these malicious applications to allow them to manipulate the hosting site in ways that shouldn’t be possible. This works on some common platforms if they enable file uploads (Joomla, Drupal), as well as some of the sites Mike references in his posts.

This isn’t an end-of-the-world kind of problem, but is serious enough that Adobe should address it. They should force Flash to respect HTTP headers, and could easily filter out “disguised” Flash files. Flash should also respect the same origin policy, and not allow the hosting site to affect the presenting site.

If you are a web site administrator, there are a few things you can do. One of the easiest is to run all user-generated content from a separate server, which means Flash code should never be able to access your main server (and its JavaScript) since it runs in the context of the subdomain, not your main domain. You can also use the content-disposition header for user generated content, which will force the user to download included files, rather than running them in place (Flash does respect this header).

This issue is definitely more serious than Adobe is saying, and hopefully they’ll change their position and fix the parts of it that are under their control.


Monday, July 13, 2009

Second Unpatched Microsoft Flaw Being Exploited

By Rich

Microsoft released an advisory today that an unpatched vulnerability in the Office Web Components ActiveX control allows an attacker to run arbitrary code as the logged-in user. Worse yet, this is being actively exploited in the wild. Fortunately it is easy to protect against.

For the technical details, please see the SANS Internet Storm Center post, and the official Microsoft advisory.

Here’s the short version and how to protect yourself:

  1. This is a flaw in the spreadsheet ActiveX control that comes with Office. It only works if you visit a malicious link with Internet Explorer, and have a vulnerable version of Office installed (if you have Office, it’s safest to assume you are vulnerable).
  2. This does not affect Outlook, unless you click on an email link that opens Internet Explorer.
  3. It is actively being exploited by bad guys on the Internet, and Microsoft is working on a patch.
  4. If you switch to another browser, you are safe.
  5. If you still need to use IE, you can click on this link for a tool that will help disable the control. Don’t try this if you are on a work computer without talking to IT.

And that’s it – no reason to panic, with plenty of ways to protect yourself. You can now safely ignore all the scary emails you’ll be getting any moment from various security vendors…

(This is unrelated to the other ActiveX 0day that popped up last week and is also being actively exploited).


Tuesday, December 30, 2008

What Regular Users Need To Know About The SSL/Root Certificate Authority Exploit

By Rich

Update: Verisign already closed the hole.

This morning (in the US- afternoon in Europe), a team of security researchers revealed that they are in possession of a forged Certificate Authority digital certificate that pretty much breaks the whole idea of a trusted website. It allows them to create a fake SSL certificate that your browser will accept for any website.

The short summary is that this isn’t something you need to worry about as an individual, there isn’t anything you can do about it, and the odds are extremely high that the hole will be closed before any bad guys can take advantage of it.

Now for some details and analysis, based on the information they’ve published. Before digging in, if you know what an MD5 hash collision is you really don’t need to be reading this post and should go look at the original research yourself. Seriously, we’re not half as smart as the guys who figured this out. Hell, we probably aren’t smart enough to scrape poop off their shoes (okay, maybe Adrian is, since he has an engineering degree, but all I have is a history one with a smidgen of molecular bio).

This seriously impressive research was released today at the Chaos Computer Congress conference. The team, consisting of Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Anne Osvik, and Berne de Weger took advantages of known flaws in the MD5 hash algorithm and combined it with new research (and an array of 200 Sony Playstation 3s) to create a forged certificate all web browsers would trust. Here are the important things you need to know (and seriously, read their paper):

  • All digital certificates use a cryptographic technique known as a hash function as part of the signature to validate the certificate. Most certificates just ‘prove’ a website is who they say they are. Some special certificates are used to sign those regular certificates and prove they are valid (known as a Certificate Authority, or CA). There is a small group of CAs which are trusted by web browsers, and any certificate they issue is in turn trusted. That’s why when you go to your bank, the little lock icon appears in your browser and you don’t get any alerts. Other CAs can issue certificates (heck, we do it), but they aren’t “trusted”, and your browser will alert you that something fishy might be going on.
  • One of the algorithms used for this hash function is called MD5, and it’s been broken since 2004. The role of a hash function is to take a block of information, then produce a shorter string characters (bits) that identifies the original block. We use this to prove that the original wasn’t modified- if we have the text, and we have the MD5 results, we can recalculate the MD5 from the original and it should produce exactly the same result, which must match the hash we got. If someone changes even a single character in the original, the hash we calculate will be completely different from the one we got to check against. Without going into detail, we rely on these hash functions in digital certificates to prove that the text we read in them (particularly the website address and company name) hasn’t been changed and can be trusted. That way a bad guy can’t take a good certificate and just change a few fields to say whatever they want.
  • But MD5 has some problems that we’ve known about for a while, and it’s possible to create “collisions”. A collision is when two sources have the exact same MD5 hash. All hash algorithms can have collisions (if they were really 1:1, they would be as long as the original and have no purpose), but it’s the job of cryptographers to make collisions very rare, and ideally make it effectively impossible to force a collision. If a bad guy could force an MD5 hash collision between a real cert and their a fake, we would have no way to tell the real from the forgery. Research from 2004 and then in 2007 showed this is possible with MD5, and everyone was advised to stop using MD5 as a result.
  • Even with that research, forging an MD5-based digital certificate for a CA hadn’t ever been done, and was considered very complex, if not impossible. Until now. The research team developed new techniques and actually forged a certificate for RapidSSL, which is owned by Verisign. They took advantage of a series of mistakes by RapidSSL/Verisign and can now fake a trusted certificate for any website on the planet, by signing it with their rogue CA certificate (which carries an assurance of trustworthiness from RapidSSL, and thus indirectly from Verisign).
  • RapidSSL is one of 6 root CAs that the research team identified as still using MD5. RapidSSL also uses an automatic system with predictable serial numbers and timing, two fields the researchers needed to control for their method to work. Without these three elements (MD5, serial number, and timing) they wouldn’t be able to create their certificate.
  • They managed to purchase a legitimate certificate from RapidSSL/Verisign with exactly the information they needed to use the contents to create their own, fake, trusted Certificate Authority certificate they can then use to create forged certificates for any website. They used some serious math, new techniques, and a special array of 200 Sony PS3s to create their rogue certificate.
  • Since browsers will trust any certificate signed by a trusted CA, this means the researchers can create fake certificates for any site, no matter who originally issued the certificate for that site.
  • But don’t worry- the researchers took a series of safety precautions, one being that they set their certificate to expire in 2004- meaning that unless you set the clock back on your computer, you’ll still get a security alert for any certificate they sign (and they are keeping it secret in the first place).
  • All the Certificate Authorities and web browser companies are now aware of the problem. All they need to do is stop using MD5 (which only a few still were in the first place). RapidSSL only needs to change to using random serial numbers to stop this specific technique.

Thus at this point, your risk is essentially 0, unless Verisign (and the other CAs using MD5) are really stupid and don’t switch over to a different hash algorithm quickly. We are at greater risk of someone like Comodo issuing a bad certificate without all the pesky math.

Nothing to worry about, and hopefully the CAs will avoid SHA1- another hash algorithm that cryptographers believe is prone to collisions.

And I really have to close this out with one final fact:

Chuck Norris collides hash values with his steely stare and power of will.

Update: Yes, if the researchers turn bad or lose control of their rogue cert, we could all be in serious trouble. Or if bad guys replicate this before the CAs fix the hole. I’m qualitatively rating the risk of either event as low, but either is within the realm of possibility.


Friday, December 12, 2008

Stop Using Internet Explorer 7 (For Now), Or Deploy Workarounds

By Rich

There is an unpatched vulnerability for Internet Explorer 7 being actively exploited in the wild. The details are public, so any bad guy can take advantage of this. It’s a heap overflow in the XML parser, for you geeks out there. It affects all current versions of Windows.

Microsoft issued an advisory with workarounds that prevent exploitation:

  1. Set Internet and Local intranet security zone settings to “High” to prompt before running ActiveX Controls and Active Scripting in these zones.
  2. Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.
  3. Enable DEP for Internet Explorer 7.
  4. Use ACL to disable OLEDB32.DLL.
  5. Unregister OLEDB32.DLL.
  6. Disable Data Binding support in Internet Explorer 8.


Thursday, October 23, 2008

Microsoft Critical Update Today- **Updated- Details Released**

By Rich

If you don’t already know, Microsoft is releasing an out of band critical update today. Rumor is it is not related to the TCP DoS issue, and may involve an 0day with remote code execution.

Here’s the link to the webcast where they will detail what’s going on.

We don’t normally jump on a bandwagon like this, but it sounds like a big one you’ll want to fix ASAP.

UPDATE: Woops- literally 2 minutes after I posted this, Ryan Naraine posted details and a link to the official advisory.

It’s a nasty vulnerability in the Server service that allows remote code execution without authentication. You should already be blocking TCP ports 139 and 445 at the perimeter, so nothing unusual to change on the firewall.

But this is totally wormable, requires no authentication, and allows arbitrary code execution. It’s the evil trinity of vulnerabilities.

You should pay extra attention to your mobile users and friends and family- have them update ASAP since the odds are they aren’t blocking those ports. Don’t get too cocky if you have a firewall- like Slammer it will only take one infected sales dude to plug back in at the office and ruin your day. These are the kinds of vulns NAC is made for.

Also, don’t forget about those virtual versions of Windows running on your Mac.

It looks so easy to exploit, that by the time you read this it’s probably too late :)


Wednesday, October 01, 2008

Massive TCP Flaw Looming

By Rich

Yesterday, following up after recording the podcast on clickjacking, I was talking with Robert Hansen about the TCP flaw some contacts of his found over in Sweden. He wrote it up in his column on Dark Reading, and Dennis Fisher over at TechTarget also has some information up.

Basically, it’s massive unpatched denial of service attack that can take down nearly anything that uses TCP, in some cases forcing remote systems to reboot or potentially causing local damage. Codified in a tool called “Sockstress”, Robert E. Lee and Jack C. Louis seem to be having trouble getting the infrastructure vendors to pay attention. I can’t but help think it’s because they are with a smaller company in Sweden; had this fallen into the hands of one of the major US vendors/labs methinks the alarm bells would be ringing a tad louder.

From what Robert told me, supported by the articles, this tool allows an attacker to basically take down anything they want from nearly anywhere (like a home connection).

Robert and Jack are trying to report and disclose responsibly, and I sure as heck hope the vendors are listening. Now might be the time for you big end users to start asking them questions about this. It’s hard to block an attack when it takes down your firewall, IPS, and the routers connecting everything.

One interesting tidbit- since this is in TCP, it also affects IPv6.


Tuesday, July 22, 2008

Pure Genius

By Rich

There is nothing else to say.

(Hoff claims he wrote it in 8 minutes).


Wednesday, July 09, 2008

More On The DNS Vulnerability

By Rich

Okay- it’s been a crazy 36 hours since Dan Kaminsky released his information on the massive multivendor patch and DNS issue. I want to give a little background on how I’ve been involved (for full disclosure) as well as some additional aspects of this. If you hate long stories, the short version is he just walked me through the details, this is a very big deal, and you need to patch immediately.

Dan contacted me about a week or so ago to help get the word out to the CIO-level audience. As an analyst, that’s a group I have more access to. I was involved with the initial press conference and analyst briefings, and helped write the executive overview to put the issue in non-geek terms.

At the time he just gave me the information that was later made public. I’ve known Dan for a few years now and trust him, so I didn’t push as deeply as I would with someone I don’t have that relationship with. Thus, as the comments and other blogs dropped into a maelstrom of discontent, I didn’t have anything significant to add.

Dan realized he underestimated the response of the security community and decided to let me, Ptacek, Dino, and someone else I won’t mention into the fold.

Here’s the deal- Dan has the goods. More goods than I expected. Dino and Ptacek agree. Tom just issued a public retraction/apology. This is absolutely one of the most exceptional research projects I’ve seen. Dan’s reputation will emerge more than intact, although he will still have some black eyes for not disclosing until Black Hat.

Here’s what you need to know:

  1. You must patch your name servers as soon as possible. This is real, it’s probably not what you’re thinking. It’s a really good exploit (which is bad news for us).
  2. Ignore the “Important” rating from Microsoft, and other non-critical ratings. You have to keep in mind that for many of those organizations nothing short of remote code execution without authentication will result in a critical rating. That’s how the systems are built.
  3. Dan screwed up some of his handling of this, and I’m part of that screwup since I set my cynical analyst hat aside and ran totally on trust and reputation. Now that I know more, I stand behind my reaction and statements, but that’s a bad habit for me to get into.
  4. This still isn’t the end of the world, but it’s serious enough you should break your patch cycle (if you have one) on name servers to get them fixed. Then start rolling out to the rest of your infrastructure.
  5. CERT is updating their advisory on an ongoing basis. It’s located here.

Next time something like this happens I’ll push for full details sooner, but Dan is justified in limiting exposure of this. His Black Hat talk will absolutely rock this year.


Tuesday, July 08, 2008

Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released

By Rich

Today, CERT is issuing an advisory for a massive multivendor patch to resolve a major issue in DNS that could allow attackers to easily compromise any name server (it also affects clients). Dan Kaminsky discovered the flaw early this year and has been working with a large group of vendors on a coordinated patch.

The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not immediately reveal the vulnerability and reverse engineering isn’t directly possible.

Dan asked for some assistance in getting the word out and was kind enough to sit down with me for an interview. We discuss the importance of DNS, why this issue is such a problem, how he discovered it, and how such a large group of vendors was able to come together, decide on a fix, keep it secret, and all issue on the same day.

Dan, and the vendors, did an amazing job with this one. We’ve also attached the official CERT release and an Executive Overview document discussing the issue.

Executive Overview (pdf)

CERT Advisory (link)

Update: Dan just released a “DNS Checker” on his site Doxpara.com to see if you are vulnerable to the issue. Network Security Podcast, Episode 111, July 8, 2008

And here’s the text of the Executive Overview:

Fixes Released for Massive Internet Security Issue

On July 8th, technology vendors from across the industry will simultaneously release patches for their products to close a major vulnerability in the underpinnings of the Internet. While most home users will be automatically updated, it’s important for all businesses to immediately update their networks. This is the largest synchronized security update in the history of the Internet, and is the result of hard work and dedication across dozens of organizations.

Earlier this year, professional security research Dan Kaminsky discovered a major issue in how Internet addresses are managed (Domain Name System, or DNS). This issue was in the design of DNS and not limited to any single product. DNS is used by every computer on the Internet to know where to find other computers. Using this issue, an attacker could easily take over portions of the Internet and redirect users to arbitrary, and malicious, locations. For example, an attacker could target an Internet Service Provider (ISP), replacing the entire web – all search engines, social networks, banks, and other sites – with their own malicious content. Against corporate environments, an attacker could disrupt or monitor operations by rerouting network traffic traffic, capturing emails and other sensitive business data. Mr. Kaminsky immediately reported the issue to major authorities, including the United States Computer Emergency Response Team (part of the Department of Homeland Security), and began working on a coordinated fix. Engineers from major technology vendors around the world converged on the Microsoft campus in March to coordinate their response. All of the vendors began repairing their products and agreed that a synchronized release, on a single day, would minimize the risk that malicious individuals could figure out the vulnerability before all vendors were able to offer secure versions of their products. The vulnerability is a complex issue, and there is no evidence to suggest that anyone with malicious intent knows how it works.

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses. Unfortunately, due to the scope of this update it’s highly likely that the vulnerability will become public within weeks of the coordinated release. As such, all individuals and organizations should apply the patches offered by their vendors as rapidly as possible.

Since not every system can be patched automatically, and to provide security vendors and other organizations with the knowledge they need to detect and prevent attacks on systems that haven’t been updated, Mr. Kaminsky will publish the details of the vulnerability at a security conference on August 6th. It is expected by this point the details of the vulnerability will be independently discovered, potentially by malicious individuals, and it’s important to make the specific details public for our collective defense. We hope that by delaying full disclosure, organizations will have time to protect their most important systems, including testing and change management for the updates. Mr. Kaminsky has also developed a tool to help people determine if they are at risk from “upstream” name servers, such as their Internet Service Provider, and will be making this publicly available.

Home users with their systems set to automatically update will be protected without any additional action. Vendor patches for software implementing DNS are being issued from major software manufacturers, but some extremely out of date systems may need to updated to current versions before the patches are applied. Executives need to work with their information technology teams to ensure the problem is promptly addressed.

There is absolutely no reason to panic; there is no evidence of current malicious activity using this flaw, but it is important everyone follow their vendor’s guidelines to protect themselves and their organizations.