Coolpad is the sixth largest manufacturer of smartphones in the world, and the third largest in China. We recently discovered that the software installed on many of Coolpad’s high-end Android phones includes a backdoor which was installed and operated by Coolpad itself. Today we released a new report detailing the backdoor, which we’ve named “CoolReaper.”
After reviewing Coolpad complaints on message boards about suspicious activities on Coolpad devices, we downloaded multiple copies of the stock ROMs used by Coolpad phones sold in China. We found the majority of the ROMs contained the CoolReaper backdoor.
CoolReaper can perform the following tasks:
Download, install, or activate any Android application without user consent or notification
Clear user data, uninstall existing applications, or disable system applications
Notify users of a fake over-the-air (OTA) update that doesn’t update the device, but installs unwanted applications
Send or insert arbitrary SMS or MMS messages into the phone.
Dial arbitrary phone numbers
Upload information about device, its location, application usage, calling and SMS history to a Coolpad server
We expect device manufacturers to install software on top of Android that provides additional functionality and customization, but CoolReaper does not fall into that category. Some mobile carriers install applications that gather usage statistics and other data on how their devices are performing. CoolReaper goes well beyond this type of data collection and acts as a true backdoor into Coolpad devices.
Coolpad customers in China have reported installation of unwanted applications and push-notification advertisements coming from the backdoor. Complaints about this behavior have been ignored by Coolpad or deleted.
Coolpad has also modified the Android OS contained in many of their ROMs. The modifications are specifically tailored to hide CoolReaper components from the user and from other applications operating on the device. These modifications make the backdoor much more difficult for antivirus programs to detect.
In November a white-hat security researcher identified a vulnerability in the back-end control system for CoolReaper, which allowed him to see how Coolpad controls the backdoor.
CoolReaper is the first malware we have seen that was built and operated by an Android manufacturer. The changes Coolpad made to the Android OS to hide the backdoor from users and antivirus programs are unique and should make people think twice about the integrity of their mobile devices.
If this wild 2014 taught us anything, it’s that cyber threats are becoming more pervasive and no one is immune to them. All organizations – regardless of vertical segment – need to apply a heightened sense of urgency and sophisticated security measures that:
Lean more towards strict security policies versus a predominantly open environment
Address attacks at every step in an attack lifecycle
Cover all aspects of an enterprise – from the data center and branch offices to endpoints
We invite you to learn more about the Palo Alto Networks Enterprise Security Platform, which offers a unique preventative approach with three essential components – Next-Generation Firewall, Advanced Endpoint Protection and Threat Intelligence Cloud – to secure computing environments, prevent known and unknown threats, and safely enable an increasingly complex and rapidly growing number of applications.
Below you’ll find all of our 2015 predictions by subject.
These topics are among many planned for Ignite 2015, where you will tackle your toughest security challenges, get your hands dirty in one of our workshops, and expand your threat IQ. Register now to join us March 30-April 1, 2015 in Las Vegas — the best security conference you’ll attend all year.
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?
