Category: Palo Alto Networks

Large-scale network architectures, including private cloud and service provider networks, rely on a complex mix of routing protocols, virtualization, SDN, and Orchestration/Programmability  priorities to function properly. Palo Alto Networks virtual firewalls fit into many of these large-scale network architectures, supporting multiple hypervisors, private and public cloud vendors, multiple routing protocols, and orchestration integration via our open APIs. 

In this interview by Ivan Pepelnjak, we talk about some of these networking priorities and how Palo Alto Networks virtual firewalls can be deployed into these architectures, without adding unnecessary complexity. Networking teams are focused largely on scale, routing support, and orchestration, and Ivan’s interviews have a wide reach into this community and what these teams care about.

Please listen to hear a broad overview of how Palo Alto Networks integrates into these large-scale network environments.

[Palo Alto Networks Blog]

Many retailers, large and small, brick-and-mortar and online, had their brands tarnished by cyberattacks in 2014. While news stories focused on Point-of-Sales (POS) breaches, often the initial intrusion took place in the back-office and through a business partner. Bottom line, to protect their reputation and the trust of their customers, retailers must reevaluate the level of security currently in place not only in their POS environments but also throughout their value chain and across their business partners and customer touch points.

As a crucial starting point, all applications and servers in the datacenter that generate traffic with a POS should be segmented in one if not several network zones to allow for better scrutiny. Palo Alto Networks next-generation firewall can effectively manage, control, and inspect all traffic coming in and out of the POS datacenter zone(s) and apply security policies that eliminate unnecessary applications, ensure least-privileged access by users (including contractors), and inspect all traffic for malicious payloads to identify and block known and unknown malware.

This segmentation step is critical to prevent cyberattacks, which penetrate the enterprise network through a weak point, and then move laterally into zones that communicate with POS terminals and handle sensitive information such as customer data or credit card information.

Additionally, we recommend additional security for the edge of the network and endpoints. Palo Alto Networks offers two products that are natively part of our Enterprise Security Platform and strengthen security at the POS:

• Our advanced endpoint protection product, Traps, can be deployed on POS endpoints to prevent malware infection. Taking an innovative approach that is completely different from traditional AV products, Traps detects and blocks malware before it installs on the endpoint. Traps can be updated with the latest from the threat intelligence available through Wildfire, our threat detection service.
• Our remote access solution, GlobalProtect, can be deployed on mobile devices and remote computers to enable a security team to enforce enterprise policies at the POS and ensure consistency of policies and security from the core to the edge of your network. GlobalProtect can also be used to enforce a secure VPN connection from the device it is installed on to your core infrastructure.

Finally, to complete the security of the POS environment and the communication between individual stores and the retailer’s datacenter, we support the following options depending on the chosen architecture for distributed stores:

• For stores linked back to a central datacenter via MPLS, our Enterprise Security Platform should be deployed at the core to manage and secure all traffic going back and forth to stores. For this traditional and most common case, the security is centralized on one of our high-end next-generation firewalls.
• For retailers that want to offer richer customer experiences directly at the POS with WiFi access and other advanced services or need to allow store employees to connect directly to the internet, they can deploy one of our smaller appliances like the PA-200, at the store level and benefit from more advanced security features.

Retailers often maintain a hybrid approach to support a broad range of small to large stores in a cost effective manner. They can easily combine any of the above scenarios to support a mixed environment with minimal to no integration as all offered alternatives:

• Are based on the same underlying technology
• Can be centrally managed with our administration console Panorama
• Can easily exchange traffic logs
• Use consistent security policies regardless of the appliance deployed
• Seamlessly share threat intelligence

This deployment flexibility with minimal integration overhead is one key advantage of relying on the Palo Alto Networks Enterprise Security Platform.

Watch for upcoming blogs and webinars to learn how Palo Alto Networks can best secure retail operations and the highly target payment process.

For more on Palo Alto Networks and Retail

• Retail Industry Resources
• Retail Industry Blog Posts

[Palo Alto Networks Blog]

Ransomware

In recent years, the cybersecurity world has observed various changing trends in the malware landscape. From plain viruses and worms through DDoS botnets and banking Trojans, criminal organizations and malware authors are always trying to ramp up their attack abilities to adapt to the advancing security market and stay ahead of detection and prevention technology.

One of the most recent evolutions of this cat and mouse game is encrypting ransomware, which has lately become very popular with cyber criminals. The figure below shows the number of encrypting ransomware variants that have been spotted in attacks around the world, according to the date they were spotted on:

An encrypting ransomware is a malicious piece of software that infects a computer and encrypts all of its valuable files. The ransomware reaches the computer by way of exploiting a vulnerability (typically in a browser or a document reader), or via a downloaded executable run by an unsuspecting user. The malicious payload then encrypts valuable files on the machine (e.g. documents, images, certificates, etc.), requesting payment for their decryption within a certain time-frame.

The key needed for decryption is uploaded to a remote C&C server and is not stored on the local machine, making remediation very difficult. Removing the malware is not enough, since the bulk of the user’s files are encrypted and cannot be recovered without the key. Thus, if the victim chooses not to oblige within the given time-frame, the files remain encrypted with very little hope of recovery.

The effectiveness of this threat has contributed to its popularity among cyber criminals, which use it to infect individuals and organizations alike.

Looking at Things Differently

Most of the publications on encrypting ransomware focus on the infection methods, the encryption algorithm, or the C&C server communication. In this post, we look at ransomware from another angle, by analyzing the file operations they perform on the files they encrypt. A high-level overview using simple methods can provide significant insight into malware behaviors — insight that might otherwise go unnoticed when delving into the little details.

We can divide encrypting ransomware into three categories, based on the way they access and modify files:

1. Write-in-place
2. Rename-and-encrypt
3. Create-encrypt-and-delete

As part of our ongoing research into battling these pieces of ransomware, we analyzed many samples and variants, coming from different origins. We present a summarized study of some of the samples we analyzed, one for each of the aforementioned techniques.

Write-in-place

The ransomware in this category operate in the following manner:

1. Create a temporary file
2. Read the original file
3. Encrypt the data and write it to the temporary file
4. Read the encrypted data from the temporary file
5. Write the data back to the original file
6. Delete the temporary file

Ransomware of this type includes CryptoLocker, CryptoWall, CryptoDefence and DirCrypt.

Note that process memory can be used as the temporary storage area instead of a temporary file, and the malware still belongs to this category.

As an example, let us analyze a sample of the DirCrypt ransomware (md5:0e5e8f6edd2c1496614bb6a71ba3f256), which uses the process’s memory as its temporary workspace, as depicted below:

1. Open the file using CreateFile
2. Get the file size and data length using GetFileInformationByHandle
3. Read the file’s data (piece by piece), encrypt the data in memory, and write it back to the same file
4. Finally, close the file, as shown below

Upon opening the encrypted file, the user is faced with this message:

Rename-and-encrypt

Ransomware belonging to this category operate as follows:

1. Rename the original file.
2. Read the renamed file.
3. Encrypt the data and write it back to the renamed file.
4. Rename the file again to the original name (+ some extension).

Ransomware such as Onion/CBT/Critroni exhibit this method of operation.

This type of sequence is more complex than the first technique presented, since the file is renamed before the encryption. The defender might therefore need to keep track of all the different names a file may have.

An analysis of an Onion ransomware sample (md5: 10a472ec4a6687f1c432c639effbae00) shows the following actions being performed on the files to be encrypted:

1. Open the file using CreateFile
2. Rename the file using SetFileInformationByHandle to a file in a Temp directory, named 0.tmp
3. Get the file size, and data length using GetFileInformationByHandle
4. Read the renamed temp file, encrypt the read data, and write it back to the same file
5. Set a new file size with SetFileInformationByHandle
6. Rename the file again, this time to the original name, in the original path, with “.ctb2″ extension with SetFileInformationByHandle

Note that the malware uses GetFileInformationByHandle and SetFileInformationByHandle to preserve the original timing attributes of the file.

After all files of interest had been encrypted, the following message appears:

Create-encrypt-and-delete

The operations performed by malware in this category are:

1. Create a new file
2. Write the encrypted data to the new file
3. Delete the original file

Ransomware such as ZeroLocker and TorrentLocker use this method when encrypting files.

This technique is the hardest to identify as a malicious activity, since the API calls by themselves can’t associate the events of creation, writing and deletion together and show that they correspond to the same files. Furthermore, legitimate operations, such as moving files between different hard drives, might produce similar logs.

Analysis of a sample of the ZeroLocker ransomware variant (md5:3772a3deeb781803a907ed36ee10681d) shows that for each of the files in a set of predetermined directories, the following actions are performed:

1. Open the file using CreateFile
2. Create a new file in the same location, with the same name and an additional “.encrypt” extension
3. Get the file size and data length using GetFileInformationByHandle
4. Read the original file, encrypt it, and write it to the newly created file
5. Delete the original file using SetFileInformationByHandle

At the end of this procedure, the ransomware creates a directory named “ZeroLocker” with two files. One of the files contains the following message:

Conclusions

In this post we examined the methods of operation for several common ransomware samples. The first method, write-in-place, is the most simplistic method in terms of file operations. The second method, rename-and-encrypt, is very similar to the first method, but adds the complexity of tracking all the different names a file may possess.

The last method, create-encrypt-and-delete, is the file operation method, used by ransomware, that is the most challenging to identify. This stems from the fact that the file operations involved can be seen in everyday use-cases, and it is hard to relate them to malicious activity that aims to encrypt files on the machine.

Palo Alto Networks has been researching a solution in Advanced Endpoint Protection that, based on our lab tests, would have blocked the ransomware families mentioned above and prevented malicious activity. We hope to share more details of this solution in the coming months.

[Palo Alto Networks Blog]

Our Enterprise Security Platform brings network, cloud and endpoint security into a common architecture, with complete visibility and control, ensuring your organization can detect and prevent attacks while safely enabling an increasingly complex and rapidly growing number of applications.

Head here to see a document highlighting survey results from Forrester Research that illustrate the total economic impact of the platform and its fundamental advantages over a collection of point products.

[Palo Alto Networks Blog]

In this post we discuss CVE-2014-7911 and the various techniques that can be used to achieve privilege escalation. We also examine how some of these techniques can be blocked using several security mechanisms.

The Vulnerability

CVE-2014-7911 was presented here along with a very descriptive POC that was written by Jann Horn. Described briefly, the ObjectInputStream doesn’t validate that the serialized object’s class type, as described in the serialized object, is actually serializable. It creates an instance of the wanted class anyway with the deserialized values of the object. Therefore, one can create object of any class, and control its private variables, by serializing objects from another class, that would be deserialized as data members of the wanted class.

Let’s look at the example below:

The following snippet (copied from the original POC) shows a spoofed BinderProxy instance:

In the POC code that was provided above, an attacker serializes a class named AAdroid.os.BinderProxy and changes its name to android.os.BinderProxy after marshalling it, and before sending it to the system server.

android.os.BinderProxy class isn’t serializable, and it involves native code that handles mObject and mOrgue as pointers. 

If it was serializable, then the pointers valued wouldn’t be deserialized, but their dereferenced values would.

The deserialization code in ObjectInputStream deserializes the sent object as an android.os.BinderProxy instance, leading to type confusion.

As mentioned earlier, this type confusion results in the native code reading pointer values from the attacker’s spoofed android.os.BinderProxy, supposedly private fields, which the attacker modified.

Specifically, the field of interest is mOrgue.

The android.os.BinderProxy contains a finalize method that will result in native code invocation. This native code uses mOrgue as a pointer.

This is the finalize method:

And this is the declaration of destroy:

The native destroy function:

Eventually, the native code invokes decStrong

(i.e., in drl->decStrong((void*)javaObjectForIBinder);)

Note that at this point, drl is controlled by an attacker, as evident by the line

So decStrong is going to be called with us controlling ‘this’ pointer.

Let’s take a look on decStrong code from RefBase class source:

Note the line refs->mBase->onLastStrongRef(id); These lines will eventually lead to arbitrary code execution.

In the following screenshot of RefBase::decStrong assembly, the attacker controls r0(‘this pointer’)

Exploitation

The first use of the controlled register r0, which contains the ‘this’ pointer (drl) is in these lines:

These lines are translated to the following assembly:

First, r4 is loaded with the mRefs variable.

Note that r0 is the ‘this’ pointer of the drl, and mRefs is the first private variable following the virtual function table, hence it is 4 bytes after ‘this’ pointer.

Then, android_atomic_dec is being called with &refs->mStrong

This is translated to:

r0 now contains &refs->mStrong.

Note that the mStrong variable is the first data member of refs (in the class weakref_impl), and that this class contains no virtual functions, hence it does not contain a vtable, so the mStrong variable is at offset 0 of r4.

As one can tell –  the line refs->removeStrongRef(id); is not present in the assembly  simply because the compiler optimized and omitted it, since it has an empty implementation, as one can see from the following code:

Following the call to android_atomic_dec are these lines of code:

These are translated to the following assembly lines:

Note that android_atomic_dec returns the value of the specified memory address before the decrement took place. So in order to invoke refs->mBase->onLastStrongRef(id) (blx r2), we must get refs->mStrong to get the value of 1.

As we can see up to now, an attacker has several constraints that he must adhere to if he wishes to gain code execution:

1. drl (our first controlled pointer, i.e. r0 when entering decStrong) must point to a readable memory location.
2. refs->mStrong must have the value of 1
3. The dereference chain at the line refs->mBase->onLastStrongRef(id) must succeed and eventually point to an executable address.

In addition, an attacker must overcome the usual obstacles of exploitation – ASLR and DEP.

One can employ basic techniques to fulfill these requirements and overcome the mentioned security mechanisms, including heap spraying, stack pivoting and ROP. Let’s look at these in detail.

Heap spray

An attacker’s first step will be to get a reliable readable address with arbitrary data – most commonly achieved by a heap spray.

The system server provides several core functionalities for the android device, many of which are exposed to applications via various service interfaces.

A common paradigm to invoke a service in the context of the system server is like the following:

The acquired manager allows us to invoke functionality in the system server on behalf of us, via IPC.

Several services can be used by us for a heap spray, but for the purpose of this blog, we decided to use a heap spray that requires special app permissions, to prevent normal applications from utilizing this technique.

The location manager allows us to register test providers via the function addTestProvider – allowing us to pass an arbitrary name that contains arbitrary data. As we mentioned, one should enable developer options and enable the mock locations option in order to utilize this.

Note that this heap spray does have its limitations – the data is sprayed using the name field, which is Unicode. This imposes a limitation – we are limited to byte sequences which correspond to valid Unicode code points.

Spray addresses manipulation

After spraying the system server process memory address space, we encountered another issue – our chosen static address indeed pointed to readable data on each run, but not to the exact same offset in the spray chunk each time.

We decided to solve this problem by crafting a special spray that contains decreasing pointer values.

Here is an illustration of the sprayed buffer, followed by an explanation of its structure:

STATIC_ADDRESS is the arbitrarily chosen static pointer in mOrgue.
GADGET_BUFFER_OFFSET is the offset of GADGET_BUFFER from the beginning of the spray.

In each run of system server process, the static address we chose points to our controlled data, but with different offsets.

r0 (which always hold the same chosen STATIC_ADDRESS) can fall to any offset in the “Relative Address Chunk”, therefore point to any of the STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N addresses, on each time.

Note the following equation:

GADGET_BUFFER = Beginning_of_spray + GADGET_BUFFER_OFFSET

In the case that r0 (=STATIC_ADDRESS) points to the beginning of the spray : STATIC_ADDRESS = Beginning_of_spray.

Hence: GADGET_BUFFER = STATIC_ADDRESS + GADGET_BUFFER_OFFSET

On any other case – r0(=STATIC_ADDRESS) points to an offset inside the spray (the offset is dword aligned):

STATIC_ADDRESS = Beginning_of_spray + 4N

Beginning_of_spray = STATIC_ADDRESS – 4N.

Hence: GADGET_BUFFER = STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N

The higher offset in the chunk that r0(=STATIC_ADDRESS) points to, the more we have to subtract to make the expression:

STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N points to GADGET_BUFFER.

No matter to which offset in the chunk r0 points to, dereference it would give us the current address of GADGET_BUFFER.                         

But where do we get if we dereference the other addresses in the chunk?

As farther as we go above r0, the farther the dereference would bring us belowGADGET_BUFFER.

Now that we have a valid working spray, let’s go back to analyzing the assembly.

So to overcome the second constraint – in which refs->mStrong must contain 1

[r4] should contain 1, hence [GADGET_BUFFER – 4] should contains 1.

Now, after atomic_dec return value is indeed 1, we should overcome the other dereferences to get to the blx opcode.

Note in order to succeed with this dereference, [GADGET_BUFFER + 4] should contain a KNOWN valid address.

We arbitrarily chose the known address – STATIC_ADDRESS.

So now we can build the GADGET_BUFFER as following:

ROP CHAIN

We chose to run the “system” function with a predefined command line.

In order to control the r0 register, and make it point to the command line string, we should use some gadgets that would manipulate the registers.

We got only one function call, so to take control on the execution flow with our gadgets, we should use a stack pivot gadget.

Therefore, the first function pointer is the preparations for the stack pivot gadget:

Where r5 equals to the original r0 (STATIC_ADDRESS) as one can see at the beginning of decStrong.

Call to the next gadget – which should be 21(=0x54 / 4) dwords from the beginning of GADGET_BUFFER

This gadget does the Stack Pivoting.

SP register points to r7 – therefore the stack is under our control and points toGADGET_BUFFER.

Ret to the next gadget that should be kept 8 dwords from the beginning of GADGET_BUFFER

(Note the pop     {r4–r11,pc} instruction, which pops 8 registers off the stack before popping pc).

Now r0 points to 56 (0x38) bytes before GADGET_BUFFER, so we have 52 command line chars, excluding the “1” for atomic_dec.

Ret to the next gadget that should be kept 10 dwords from the beginning of GADGET_BUFFER (2 dwords after the current gadget – pop     {r3,pc})

That is the last gadget where we call system!

Here is an updated layout of the memory for this to happen:

Android and ARM

There are two important issues we should keep in mind when choosing the gadgets addresses.

• There is an ASLR mechanism on Android, and the addresses wouldn’t be the same on each and every time. In order to know the correct address, we use the fact that both system server process, and our app are forked from the same process – ZYGOTE, meaning we share the same modules. So we get the address of the necessary modules in system server process, by parsing the maps file of our process. ‘maps’ is a file in /proc/<pid>/maps which contains the memory layout and the loaded modules addresses.
• On ARM CPU, there are two modes of opcode parsing: ARM (4 bytes per opcode) and THUMB (variable bytes per opcode – 2 or 4). Meaning that the same address pointed by PC, could be parsed differently by the cpu when running in different modes. Parts of the gadgets we use are in the THUMB mode. In order to make the processor change its mode when parsing those gadgets, we change the pointer address from the actual address, to (address & 1) – turning on the LSB, which make the cpu jmp to the correct address with THUMB mode.

PAYLOAD

As described before, we use the “system” function to run our command line. The length of the command line is limited, and actually a command line can’t be used for every purpose. So we decided to use a pre compiled elf, that being written to the file system, as an asset of our app. This elf can do anything with uid 1000 (the uid of system server). The command line we send as an argument to system is simply –

“sh -c ” + file_path

CONCLUSION

Android has some common security mechanisms such as ASLR and DEP which should make an exploitation of vulnerability harder to achieve.

Moreover, every application runs in its own process, so the IPC communication could be validated, and making guesses on memory layout shouldn’t be intuitive. On the other hand, the fact that every process is forked from the same process makes ASLR irrelevant for vulnerabilities within zygote’s sons and the binder connection from every process to system server could lead to heap spray as seen on this post. Those issues appear to be inherent in the Android OS design.

Palo Alto Networks has been researching an Android security solution that based on our lab testing would have blocked this exploit (as well as other exploits) with multiple exploit mitigation modules. We hope to share more details in the coming months.

[Palo Alto Networks Blog]