Pages

Tuesday, June 28, 2016

How to Compromise the Enterprise Endpoint

Posted by Tavis Ormandy.


Symantec is a popular vendor in the enterprise security market, their flagship product is  Symantec Endpoint Protection. They sell various products using the same core engine in several markets, including a consumer version under the Norton brand.

Today we’re publishing details of multiple critical vulnerabilities that we discovered, including many wormable remote code execution flaws.

These vulnerabilities are as bad as it gets. They don’t require any user interaction, they affect the default configuration, and the software runs at the highest privilege levels possible. In certain cases on Windows, vulnerable code is even loaded into the kernel, resulting in remote kernel memory corruption.


As Symantec use the same core engine across their entire product line, all Symantec and Norton branded antivirus products are affected by these vulnerabilities, including:


  • Norton Security, Norton 360, and other legacy Norton products (All Platforms)
  • Symantec Endpoint Protection (All Versions, All Platforms)
  • Symantec Email Security (All Platforms)
  • Symantec Protection Engine (All Platforms)
  • Symantec Protection for SharePoint Servers
  • And so on.


Some of these products cannot be automatically updated, and administrators must take immediate action to protect their networks. Symantec has published advisories for customers, available here.


Let’s take a look at a sample of the vulnerabilities we found.


Unpackers in the Kernel: Maybe not the best idea?


Many developers will be familiar with executable packers like UPX, they’re tools intended to reduce the size of executables by compressing them. This causes a problem for antivirus products because it changes how executables look.


Antivirus vendors solve this problem with two solutions. First, they write dedicated unpackers to reverse the operation of the most common packers, and then use emulation to handle less common and custom packers.


The problem with both of these solutions is that they’re hugely complicated and prone to vulnerabilities; it’s extremely challenging to make code like this safe. We recommend sandboxing and a Security Development Lifecycle, but vendors will often cut corners here. Because of this, unpackers and emulators continue to be a huge source of vulnerabilities, we’ve written about examples in Comodo, ESET, Kaspersky, Fireeye and many more.


Let’s look at an example from Symantec and Norton Antivirus. This vulnerability has an unusual characteristic: Symantec runs their unpackers in the Kernel!

CVE-2016-2208: Vulnerability Details



ASPack is commercial packing software that’s been around for a long time, and Symantec has dedicated unpackers for a few older versions. Reviewing Symantec’s unpacker, we noticed a trivial buffer overflow when a section’s SizeOfRawData field is greater than SizeOfImage. When this happens, Symantec will allocate SizeOfImage bytes and then memcpy all available data into the buffer.


Effectively, we can get Symantec to execute a sequence like this:

   char *buf = malloc(SizeOfImage);

   memcpy(&buf[DataSection->VirtualAddress],
          DataSection->PointerToRawData,
          SectionSizeOnDisk);


All of these values are attacker controlled, resulting in a very clean heap or pool overflow. To build a test case, I researched how to identify ASPack on OpenRCE’s packer database:


.aspack:00412001                 public start
.aspack:00412001 start           proc near
.aspack:00412001                 pusha
.aspack:00412002                 call    skipBytes
.aspack:00412002
...
.aspack:00412014                 pop     ebp
.aspack:00412015                 mov     ebx, 0FFFFFFEDh
.aspack:0041201A                 add     ebx, ebp
.aspack:0041201C                 sub     ebx, 12000h
.aspack:00412022                 cmp     dword ptr [ebp+422h], 0
.aspack:00412029                 mov     [ebp+422h], ebx
.aspack:0041202F                 jnz     END_OF_PACKER
...
Abbreviated sample ASPack sample code from http://www.openrce.org/reference_library/packer_database_view/17


This was enough for me to make a testcase in NASM that reliably triggered Symantec’s ASPack unpacker. Once I verified this work with a debugger, building a PE header that mismatched SizeOfImage and SizeOfRawData would reliably trigger the vulnerability.


VirtualAddress      equ 0x10000-0x08    ; VirtualAddress of section data, offset where copy starts.
SizeOfImage         equ 0x12000-0x0C    ; Size you want to allocate.
SectionPadding      equ 0x2000          ; SizeOfImage-VirtualAddress

   ; Section Headers
   db ".data", 0, 0, 0                 ; Name
   dd 0                                ; VirtualSize
   dd VirtualAddress                   ; VirtualAddress
   dd 0xffffffff                       ; SizeOfRawData
   dd __data                           ; PointerToRawData
   dd 0                                ; PointerToRelocations
   dd 0                                ; PointerToLinenumbers
   dw 0                                ; NumberOfRelocations
   dw 0                                ; NumberOfLinenumbers
   dd 0                                ; Characteristics
Configuring PE section headers to trigger ASPack overflow.


The full source code is available in the issue tracker.


On Linux, Mac and other UNIX platforms, this results in a clean heap overflow as root in the Symantec or Norton process. On Windows, this results in kernel memory corruption.


Because Symantec uses a filter driver to intercept all system I/O, just emailing a file to a victim or sending them a link to an exploit is enough to trigger it - the victim does not need to open the file or interact with it in anyway. Because no interaction is necessary to exploit it, this is a wormable vulnerability with potentially devastating consequences to Norton and Symantec customers.


An attacker could easily compromise an entire enterprise fleet using a vulnerability like this. Network administrators should keep scenarios like this in mind when deciding to deploy Antivirus, it’s a significant tradeoff in terms of increasing attack surface.


PowerPoint Stream Stack Buffer Overflow



Parsing PowerPoint and other Microsoft Office files is no simple feat. The data itself is stored in a series of contiguous records documented in [MS-PPT], but just extracting those records requires parsing a series of streams stored in a filesystem-like container called the Compound File Binary format documented in [MS-CFB].


Symantec has implemented an I/O abstraction layer that exposes the PowerPoint streams stored in a Compound File via a stdio-like interface. This framework is part of Symantec’s “decomposer” library, and is used for things like extracting document metadata and embedded macros.


As with stdio, I/O to and from the underlying storage is buffered for performance, so reads can sometimes be satisfied directly from the cache. I noticed that It is possible to force the cache into a misaligned state with combinations of odd-sized records. When this happens, a bug can cause reads to be incorrectly rounded-up, resulting in a buffer overflow.


By forcing the cache into a misaligned state, we can force a request like this:
When this happens, a bug causes the size to be rounded up like this:
This bug can result in a buffer overflow. I found an invocation that looked exploitable, but there’s a significant problem: This routine is only called when using what Symantec calls “Bloodhound Heuristics”.


BloodHound Heuristics



Symantec exposes a setting to administrators called “Bloodhound Heuristics”, this is called “Advanced Heuristic Protection” on Norton Antivirus, but is effectively the same thing.


Symantec has a whitepaper on their heuristics here. There are three options available to administrators: Low, Automatic and Aggressive. The default setting is Automatic, which increases the number of tests run dynamically.


I wrote a simple test case that triggers the vulnerability, and it crashes reliably with the “Aggressive” mode, but didn’t work in the default configuration. Requiring a non-default setting would reduce the severity of this vulnerability significantly, so I looked into what would trigger “Aggressive” heuristics automatically.


I downloaded an archive of powerpoint files from VirusTotal Intelligence to see if any of them triggered the aggressive heuristics by putting a few breakpoints on tests I was interested in. I got lucky, a few of the files did cause aggressive heuristics mode.


Examining the files and their structure, one stream stood out as unusual, containing an ExOleObjStgCompressedAtom. Rather than create my own, I simply extracted the compressed object and %incbin’d it into a stream in my testcase.

Exploitation



All PROT_EXEC mappings on Norton Antivirus use ASLR on Windows, but the decomposer library is part of a 32-bit process. As the scan service automatically respawns, brute force should be entirely possible.


However, with careful manipulation of the cache, we can partially overwrite the return address, meaning we don’t have to leak any module address to reliably predict the location of code relative to the return address.
The first stage is to see what we have available, to test this let’s search for an int3 instruction within range.


0:069> s (@eip & 0xffff0000) Lffff cc 1
6cbc9ba3  cc 01 00 00 80 bb 68 46-00 00 00 0f 84 82 00 00  ......hF........


That will do, let’s see if it works….
Perfect! It works every time. The next stage would be to find a sequence of gadgets that extends the range available, and then turn it into a standard ROP exploitation problem.


The source code for this exploit is available on the issue tracker.


It’s a 100% reliable remote exploit, effective against the default configuration in Norton Antivirus and Symantec Endpoint, exploitable just from email or the web. As the bug is in the core scan engine’s decomposer library, all Symantec and Norton branded products are affected. This includes but is not limited to:


  • Norton Antivirus (Mac, Windows)
  • Symantec Endpoint (Mac, Windows, Linux, UNIX)
  • Symantec Scan Engine (All Platforms)
  • Symantec Cloud/NAS Protection Engine (All Platforms)
  • Symantec Email Security (All Platforms)
  • Symantec Protection for SharePoint/Exchange/Notes/etc (All Platforms)
  • All other  Symantec/Norton Carrier, Enterprise, SMB, Home, etc antivirus products.
  • And so on..


On Windows, this results in remote code execution as SYSTEM, and root on all other platforms.


Vulnerability Management


As with all software developers, antivirus vendors have to do vulnerability management. This means monitoring for new releases of third party software used, watching published vulnerability announcements, and distributing updates.


Nobody enjoys doing this, but it’s an integral part of secure software development.


Symantec dropped the ball here. A quick look at the decomposer library shipped by Symantec showed that they were using code derived from open source libraries like libmspack and unrarsrc, but hadn’t updated them in at least 7 years.


Dozens of public vulnerabilities in these libraries affected Symantec, some with public exploits. We sent Symantec some examples, and they verified they had fallen behind on releases.


Conclusion



As well as the vulnerabilities we described in detail here, we also found a collection of other stack buffer overflows, memory corruption and more.

Thanks to Symantec Security Team for their help resolving these bugs quickly.

29 comments:

  1. Thank you for the interesting article.

    ReplyDelete
  2. Great write up Tavis.

    As a matter of interest, how much notice was Symantec given to patch before your research was published?

    ReplyDelete
    Replies
    1. Exactly! Surely this could have been released after allowing sufficient time for Symantec to advise customers? It might not be in the wild yet but how long now it's known? Customers aren't all running the latest versions of s/w (hello XP?!) so those with an estate of '000s are now put at risk which the author tries to qualify by saying thanks Symantec for fixing in your latest version?!

      Not saying I'm not grateful for knowing but sheesh!

      Delete
    2. I was wondering about this, so I read their introductory post that describes their process: http://googleprojectzero.blogspot.com/2014/07/announcing-project-zero.html

      In this case, it looks like it was reported to Semantic on 28th of April. You can see more details here: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q=&sort=-id&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary
      and
      https://bugs.chromium.org/p/project-zero/issues/detail?id=810&can=1&q=&sort=-id

      Delete
    3. Those users were already at risk anyway. Tavis didn't *create* the vulnerabilities, Symantec did. The whole idea that vulnerabilities are not used until they are publicly exposed by a security researcher, is just complete and utter nonsense.

      Seriously, go blame Symantec for introducing these issues in the first place or customers for not updating their systems, not Tavis for exposing the issues that *already existed*.

      Delete
  3. Kudos! Good - and very much needed - work. Should have been done by Symantec but hopefully they heard the wakeup call ...

    ReplyDelete
  4. How about outlining the security software with the least vulnerabilities?

    ReplyDelete
  5. Hosting vendors have an awesome opportunity to help out here, and maybe sell some more servers too.

    Many (most?) small/medium business customers use their web server as their corporate email solution as well. It's really common.

    This makes the case for quarantining the corporate "enterprise endpoint"

    https://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&suid=20160628_00

    If you look carefully at the column "solution", there's a subtle change of wording, from "updated to xxx" (automatically) to "update to yyy" (meaning, to me, go do it)

    That means customers will be clamoring for the hosting techs to apply hotfixes and such: https://support.symantec.com/en_US/article.INFO3791.html

    If there's anything other than antivirus scanning going on on the customer's email server, now's a good time to revisit their solution, to quarantine the email server as best as possible.

    It shouldn't "share the same host" as their database server, or their web server, or any other corporate function - not even their "jumpbox" (especially not that).

    Maybe give it its own separate network too. Minimize what an attacker could achive via the server, except properly sending and receiving email.

    That's step one - getting email off onto its own shiny new quarantined server. Then, sure, apply all of the recommended hotfixes.

    ReplyDelete
    Replies
    1. People still host their own mail servers?

      Delete
  6. This was published two years ago at blackhat

    ReplyDelete
    Replies
    1. Care to share a reference/url/citation to that work?

      Delete
    2. It seems it was this: https://www.offensive-security.com/vulndev/symantec-endpoint-protection-0day/

      Delete
  7. Difficult to see this as anything other than assholery by Google. Windows is banned within Google unless you have approval, so there's no business need to go hunting vulnerabilities on the platform. Really this is just a smear campaign that's quite ironic given Android's own glaring security problems.

    ReplyDelete
    Replies
    1. You really haven't followed Project Zero then. You have outlined Android vulnerabilities in the past. Lately they have been on a "security software" kick and I applaud them. For people who have to maintain or secure environments, projects like this help everyone.

      Delete
    2. Given a massive proportion of their customers & user run Windows and security depends on endpoint security, I think it's excellent that Google are providing this to the community.

      When other vendors do dumb stuff like this, it's good that they're called out on it.

      p.s. Read above: "On Linux, Mac and other UNIX platforms, this results in a clean heap overflow as root in the Symantec or Norton process. On Windows, this results in kernel memory corruption." etc. idiot.

      Delete
    3. Really, a project team looking for and exploring zero day exploits not allowed to look for zero day exploits.... lol

      Delete
    4. They aren't searching for the security flaws on Windows, but on Symantec's Norton line of products...

      Delete
    5. These vulnerabilities apply to more than just Windows though; they are present in several products for Mac and Linux as well and have equally devastating consequences.

      Delete
  8. Symantec, as Tavis clearly stated, dropped the ball on this. With the previous Thawte certificate misdemeanours Symantec now has repeat form. However the forced disclosure and remediatation by the vendor has made the product stonger. One now has to ask what other hidden and preventable nasties are still there waiting for the unscrupulous to leverage. Symantex has taken a hit to their corporate image as a responsible security player and it remains how this will affect their bottom line with many customers perhaps now choosing alternative providers. However, as the article alludes they are not the only vendors at fault - it could be the case of jumping out of the frying pan into the fire. As suggested, a multi-level approach to security is required - don't put all your eggs in one basket...

    ReplyDelete
  9. How irresponsible. As part of the security community I'd expect a little more discretion.

    So much easier to spend all your time researching, compared to those in the trenches tasked w/ operations and security of an enterprise. Arrogant and irresponsible behavior from Google. At least they didn't post source code....oh wait they did

    ReplyDelete
    Replies
    1. These issues were submitted to Symantec some time ago and patches are available.

      https://bugs.chromium.org/p/project-zero/issues/list

      Delete
    2. Irresponsible? You put yourself as "part of the security community", yet you obviously don't get it. At all.

      First of all, if you for one second think that "security by obscurity" is a viable strategy, as you imply by your comment, then you are in the wrong line of business, being the arrogant one.

      Secondly, what if Google (and others) hadn't discovered these (and other) flaws? How many years have they been laying dormant? How many malicious entities, state or organized crime sponsored even, have already exploited these flaws, without sending the manufacturer a helpful hint that there's a hole in your product suite large enough to drive a battleship through? There are plenty of examples of 0-day exploits being sold clandestinely on the black market to the highest bidder.

      Thirdly, the irresponsible party here is not Google and their engineer and Project Zero, or anyone who finds, reports and then releases information on vulnerabilities but a) people in the industry like you, with the oblivious mindset you and too many others so blatantly and ignorantly display, and b) Symantec in this case, who have a product that is fundamentally flawed in its design.

      They have no business putting this kind of code - or almost ANY kind of code for that matter - in operating system kernels and root privileged processes in the first place! What happened to mitigation techniques? Compartmentalization? Stack protection? Sandboxing? Privilege dropping? Etc, etc. Where have Symantec been the last decades? They decide they can take the liberty to relieve the operating system of the duty and responsibility of safeguarding the system by installing a few extra wide gates in the walls, without telling anybody about them. Then they don't bother to put any border police in place to keep an eye on their handiwork. Or even gates, come to think of it. They just cover up the holes in the walls with tarp and hope that no one notices...

      This deserves to be a far bigger scandal than it is, due to the reckless and incompetent ways they have designed their products. I doubt this is the last we hear about this kind of exploint against Symantec, and I doubt other "Security" software vendors are much better.

      Delete
    3. You know absolutely nothing about security and have I would wager you have no qualifications or experience in the subject. In fact, you sound like a bitter Microsoft fanboy.

      Delete
  10. How much time did the research uncovered in this article take?

    ReplyDelete
  11. For those attacking Google here, note that the mentioned CVE was assigned back in Febuary, and Semantic issued a LiveUpdate to their systems to fix the issue back in May, so waiting 'till July to publish would seem to me to be plenty of time.

    ReplyDelete
  12. They did work together with symantec to fix those vulns. And now all a sysadmin needs to do is deploy an update.

    ReplyDelete
  13. Except the update that is advised to go to, 22.7+, is not available to all users. Instead, they are still releasing on a "phased rollout" and a system I tested today cannot update to the latest version. In fact, even after removal and reinstall the version offered after updates is 22.5.4.25 (in theory, vulnerable)

    ReplyDelete