Ryan Olson, Intelligence Director, Palo Alto Networks
As I look back over the cyberthreat landscape in 2014, I’m amazed by the volume of activity handled by our community this year. From Heartbleed toWireLurker, we certainly had our hands full.
Sophisticated, targeted attacks will be the new normal in 2015 and I expect to see at least one new report each week. Here are some other trends from 2014 and predictions for the coming year that I think are significant.
Longstanding vulnerabilities revealed In 2014 we learned about multiple major vulnerabilities in code, which in some cases had been in place for more than a decade. Heartbleed, ShellShock,POODLE and SChannel all existed in source code for years, but weren’t publicly disclosed until 2014. It’s possible that these vulnerabilities had been independently discovered by attackers who exploited them unnoticed for years.
The discovery of these vulnerabilities started reviews of major open source repositories the community had assumed were rock solid. Those reviews are likely to bear fruit in 2015, resulting in the disclosure of more long-standing vulnerabilities.
Continued success of ransomware Ransomware, a class of malware that extorts users into paying an attacker, has existed in various forms for years, but 2014 was when the “Locker” malware really took off. Lockers work by infecting a system, quickly finding important files on the hard drive, encrypting them and telling the user they can recover the files if they pay a ransom, normally a few hundred dollars. Lockers are distributed through many mechanisms (spam email, for example) and are often installed by other botnets as secondary payloads.
The best-known locker variant, “CryptoLocker,” was detected in late 2013. One of the reasons for this malware’s success was that its operators actually decrypted files once the ransom was paid. If word got out that victims who paid the ransom never recovered their files, nobody would pay up. But infected users trusted CryptoLocker and were willing to pay the ransom to retrieve their stolen files. Other variants of lockers discovered in 2014 included CryptoWall and CryptoDefense.
The massive success of these in 2014 impacted companies large and small and the revenue streams generated by ransom payments are unlikely to be disrupted any time soon.
Ongoing PoS attacks Starting at the end of 2013, organizations began reporting a series of attacks on retail point-of-sale (POS) systems, which impacted tens of millions of users. These attacks used malware that infected Windows systems attached to credit card readers, and searched those systems’ memory for credit card data.
In August, the U.S. Secret Service released an advisory about one of those malware tools, known asBackOff. The advisory estimated that more than one thousand businesses were affected by BackOff. While many organizations reported PoS breaches this year, the total of publicly announced breaches was well under a thousand, indicating that many breaches may have gone unreported.
The U.S. credit card payment system is moving away from legacy magnetic stripe technologies toward chip-and- PIN systems, which are less vulnerable to these attacks. Apple released its own payment system (ApplePay) in October, which uses near field communication (NFC) for contactless payments, in part to help make in-store payments more secure.
POS attacks and new malware are likely to extend well into 2015 and beyond – depending on how quickly new security measures are adopted.
Mobile is a valuable target In 2014 we saw multiple new attacks on Android and iOS devices, most significantly WireLurker, which attacked non-jailbroken iOS devices. As more data moves onto these devices they are becoming a valuable target for all types of attackers.
Mobile devices are ripe for attack for many reasons: They often hold user credentials for applications and websites, they’re used for out-of-band authentication, they are almost constantly connected to the internet and they have audio and video recording capabilities
For high-profile targets, these devices are a treasure-trove of information. Mobile platforms often do not receive the same level of monitoring (anti-virus, IPS, etc.) that desktop systems do. An infected phone could go unnoticed for months or longer while monitoring the user and stealing their data.
In 2015 I expect to see the discovery of significant targeted attacks against mobile devices designed to steal data.
If you’ve been thinking about looking into COBIT, but haven’t because you are not quite sure what it can do for your enterprise, now is the time to get started. As an IT professional who has used COBIT for several years, I can say without hesitation that it has more to offer than you might imagine. COBIT can help you look at your organization from the governance and management standpoints, and expands the view beyond just processes through the use of enablers. This framework is not an academic reference that grew out of the audit, risk and security areas. It is a flexible, useable tool that has completely won me over, and here are five reasons I’m a big fan:
COBIT is relevant—the goal is to deliver value.
The enterprise exists to create value for its stakeholders. This is simple in theory, but tough in real life. COBIT was created from the top down, meaning that the entire model focuses on the primary facets of providing value by realizing benefits while optimizing risks and resources. From the goals cascade to the enablers, COBIT helps you focus on value.
COBIT still focuses on information.
If an enterprise does not manage its information, it will no longer exist. COBIT focuses on the information first, and that is the right way to look at it. Without information, there is no need for the technology.
COBIT is not just for the big companies.
COBIT has escaped the “for big companies only” misconception. Whether you have a small IT organization or several hundred resources, COBIT fits any size; you just need to identify your business goals, objectives and mission to operate as a going concern. I have seen an organization with two IT staff members leverage COBIT.
COBIT is a framework that looks beyond just processes.
COBIT’s seven enablers are designed to help you get beyond just looking at processes. These enablers include 1) Principles, Polices and Frameworks, 2) Processes, 3) Organizational Structures, 4) Culture, Ethics and Behavior, 5) Information, 6) Services, Infrastructure and Applications, and 7) People, Skills and Competencies. These provide a more holistic approach to governance where changes in one enabler must be adequately assessed across all enablers.
COBIT is a great reference for process owners.
All processes should have owners. I will even take that a step further and say that all processes should have assigned roles. Within COBIT 5 there is a wealth of information regarding processes. There are 37 processes organized into five domains (one governance domain and four management domains). Within this process reference model, the biggest hitters for me include: process description and purpose, practices and activities, inputs and outputs, RACI charts, goals, and related industry standards and frameworks.
And the benefits don’t end there. See five additional reasons here.
Whether you are a board member, executive, auditor or IT operator, do yourself a favor and learn more about COBIT. Admittedly, many people find it difficult to simply thumb through the various publications and experience the “ah, I get it now” feeling. My advice to anyone who wants to learn more about it is to go to the ISACA site and download some of the key publications, or visit COBIT online. And consider joining me at the first-ever COBIT Conference, taking place in March 2015 in Orlando, Florida, USA.
Adopting a framework does not guarantee your governance success, but it sure does offer a great starting point. COBIT offers a common language that can be shared across the enterprise, but real adoption requires executive support, a desire to improve and a strong desire to achieve the governance of enterprise IT.
Mark Thomas, CGEIT, CRISC, ITIL, MOF
President of Escoute
Did you know that you can find use cases for our products on our Technical Documentation portal? Our use case examples provide realistic scenarios and/or topologies that display a complete start to finish configuration. Besides showcasing the primary capabilities of the product, they highlight features that may be overlooked or that complement each other.
In this post, we share 3 use cases for Panorama.
1. Use Case: Configure Firewalls Using Panorama
This use case is based on a scenario where you want to use Panorama in a high availability configuration to manage a dozen firewalls on your network: you have six firewalls deployed across six branch offices, a pair of firewalls in a high availability configuration at each of two datacenters, and a firewall in each of the two regional head offices.
This example takes you through the process of assessing the efficiency of your current policies and determining where you need to adjust them to fortify the acceptable use policies for your network. The use case provides information on how to analyze traffic data from applications and also provides suggestions on what changes to make to your policy configuration.
3. Use Case: Respond to an Incident Using Panorama
This use case traces a specific incident and shows how the visibility tools such as incident notifications, threat logs, WildFire logs, and data filtering logs on Panorama can help you respond to the report. The use case also provides suggestions on updating the security policy following the analysis of an incident.
In this write-up, we will present several techniques used in exploiting a vulnerability in Google Chrome, and the various difficulties presented by its security mechanisms and considerations. We also offer some reflections regarding how some of the techniques used were made irrelevant by mitigations introduced since.
The exploit was developed to exploit a bug in Chrome 33, a winning submission to Pwn2Own 2014 by geohot, which later also awarded him the Best Client-Side Bug pwnie award.
The Bug
The vulnerability existed in Chrome’s implementation of ArrayBuffers, and is described in some detail in this issue page in the Chromium repository, along with an impressively concise exploit implemented by geohot himself.
This information was unavailable when we were researching the submission, so we had to make do with the code diff.
To keep things short, let’s just take a look at the relevant fix. Surprisingly, the vulnerability and the fix were in the internal JavaScript code used by the V8 engine, and not in a native component:
What we’re seeing here is the code that would be invoked whenever a Typed Array of any sort (Uint32/16/8 etc) is constructed on top of an existing ArrayBuffer instance.
On the left, we see that before the fix, the bufferByteLength is determined by reading the byteLength field of the underlying instance.
On the right, we see that the length is now retrieved via a call to %ArrayBufferGetByteLength, which denotes a native function call.
This Byte Length is later used to calculate the element length of the new Typed Array (byteLength/sizeof(element).
The issue then lies with the user’s ability to somehow control the byte length field of an ArrayBuffer. Amusingly, this is accomplished by simply overriding the byteLength getter for an ArrayBuffer instance.
An ArrayBuffer 0x20 bytes in size is instantiated. Its byteLength getter is then overridden using the __defineGetter__ method.
If you refer to the fixed code above, the issue becomes clear- you can trick the browser into creating a Typed Array of arbitrary size, based on an ArrayBuffer instance of particularly small size.
This is a remarkably elegant bug that takes you directly to relative full memory control.
Exploitation
So, we have an Array object which spans the entire 32bit memory space, enabling us read/write access.
In order to leverage this into code execution we’ll need to accomplish two objectives:
Discover the location of our Array object in memory, in order to upgrade our relative r/w into full blown absolute memory r/w.
Control EIP: Find a function pointer to corrupt, preferably a vtable of an object we can control.
These two steps are somewhat trivial in other browsers, but Chrome follows several security oriented design principles which make exploitation much more difficult.
PartitionAlloc
PartitionAlloc is a feature of Chromium’s WebKit fork – Blink.
It serves the purpose of creating memory sterility by partitioning heap allocations according to their purpose and nature – it avoids juxtaposing metadata or control data with buffer and user-input data, which is rightfully perceived to be more vulnerable.
There are 4 partitions:
Object Model Partition (Element objects etc)
Renderer Partition
Buffer Partition (Where an ArrayBuffer or a string would be allocated)
General Partition
PartitionAlloc maintains several allocation “entities”, from small to large – buckets, superpages and extents.
Super-pages are the building blocks of a partition, and are 0x200000 bytes in size each; an extent describes a sequence of super-pages.
A partition is composed of one or more extents.
Each super-page is transparently divided into buckets which are selected according to the size of a requested allocation by “order” and size.
On top of that, each super page has “guard” areas, which prevent an attacker from sequentially reading/writing/overflowing memory:
Specifically, a super-page comprises a metadata page, an actual data area (0x1f8000 bytes in length) and several guard areas (reserved, inaccessible pages).
What this means for us is that even though we have full relative read, we can’t just go around reading memory freely, since our faulty ArrayBuffer will be located inside one of these 0x1f80000 byte areas surrounded by reserved pages.
Worse than that, since PartitionAlloc is well implemented and enforced throughout the project – we are unable to allocate any object with a vtable in our proximity.
Basing our buffer
So, we know we have an array object located somewhere in memory, from which we can read the entire memory space relative to our buffer, but since we don’t know its base, we can’t convert this into absolute r/w.
The solution we came up within order to overcome this, given PartitionAlloc’s obstacles, was to create an object in near vicinity to our faulty buffer, and then spray a significant amount of items which point back to this object.
Both the single object and the sprayed pointers to it would have to be allocated in the buffer partition, same as our faulty array.
This is done by creating a simple string with similar size to our faulty ArrayBuffer, thus placing it in the same or adjacent bucket, and then spraying a moderate amount of attribute objects, with different names but the same value – our string.
The purpose of this is to get Chrome to allocate a few more super-pages, directly following the super-page we’re in, and read a pointer to the string adjacent to us from there.
Crudely depicted as follows:
By blindly reading 0x200000 bytes ahead (super-page size), we can read the attribute pairs created and heuristically infer the absolute address of the attribute we created.
Then, by scanning the memory near us, we can attempt to infer the relative offset of the attribute string from our array buffer. Combining the absolute address of the attribute string with its distance relative to us allows us to calculate our address in memory, completing objective #1.
This is the code that achieves the condition described and resolves the location of the corrupted buffer, allowing us to set up absolute r/w abstracts.
Our next objective is to gain execution by overriding a vtable for some object.
We actually broke this objective into two subtasks – leaking a pointer and overriding a vtable.
We’ve already established that we’ll have difficulty finding a pointer in our partition.
Ironically, the metadata page of the partition itself solves this issue.
Since we know how partitions are formed in Chrome 33, we can apply some more heuristic logic to bring us to the metadata page of our partition (exactly 1 page up from the super-page base), which happens to contain a few bucket pointers:
Since we don’t know exactly where we are relative to the super-pages base (not exactly accurate since we already know our absolute location), we resort to scanning backwards at 0x10000 intervals, plus a constant 0x1028 offset.
We know when we’ve found a bucket pointer once we find a value which repeats itself 0x20 ahead several times.
At this point we’ve accomplished half of our second objective, but this doesn’t really help us gain code execution.
The approach we took from here on was to simply spray a large amount (400MBs or so) HTMLDivElement objects, which we then tried to overwrite by accessing a constant address.
This sort of makes the previous leak redundant, but we decided to show it anyway since it opens up a few interesting options for exploitation. We’ll discuss those in a moment.
Naturally this has a lot of disadvantages, chief among which is the fact that these Divs would be allocated in the DOM partition, and partition bases are randomized, reducing our chances of success somewhat.
Maneuvering around the Chrome memory space
A more sophisticated approach exists, but unfortunately it relies on changes that were only introduced after this bug was fixed.
We tested this method by artificially creating the same corrupt ArrayBuffer condition in a newer version of Chrome (36 was the most recent at the time) using a debugger.
It involves reliance on an interesting detail of the PartitionAlloc structures, namely the invertedSelf member which exists in the PartitionRootBase struct:
Being a static struct, the PartitionRootBase for each partition would be located in chrome_child’s data section.
Since we have arbitrary r/w access and a pointer to chrome_child’s base, we can definitely find these structures by once again applying a simple heuristic.
The invertedSelf field is located at offset 0x68, so any value which corresponds to ~value == &value – 0x68 will highly likely be a PartitionRootBase struct.
Indeed, this function returns exactly 4 matches, one per PartitionRootBase.
Finding the Object Model Partition can then be accomplished by creating a moderate amount of Divs, enough to fill one super-page of its partition with HTMLDivElement objects, and scanning each partitions’ currentExtent looking for the pattern created by these 0x34 byte size objects.
Once we find the HTMLDivElement, it’s a simple matter of overriding a vtable and iterating over all the Divs we allocated and calling a specific method.
Using this method it’s possible to achieve fairly high reliability with a very small memory footprint.
Conclusion
All in all, exploitation in Chrome is very challenging. Even once all of this has been accomplished, you still need to employ a sandbox bypass in order to achieve full exploitation.
In addition, some of the methods described here are no longer relevant. Specifically, it seems that the Chromium developers have added an additional layer of protection by fragmenting super-pages into writable and reserved pages even within the 0x1f8000 byte area, making resolving our buffers address even harder.
Google Chrome incorporates security considerations in the design of the browser, and significantly so, to a very impressive degree.
Unfortunately, not all software vendors align themselves to the Chromium project’s standards. Palo Alto Networks Traps acts to prevent several types of attacks, even those that may circumvent or overcome mechanisms such as in Chrome, fortifying existing defenses while adding significant additional mitigation mechanisms. Learn more about Advanced Endpoint Protection here.
This week Unit 42 released its first Threat Landscape Review, looking at how malware trends affect key industries, from healthcare to high tech, around the world, and the particular persistence of the Kuluoz, or Asprox, campaign.
This infographic represents some of the key data from the full report, which you can download from the Unit 42 page. Does anything shown here surprise you?
