I recently worked with RF transmissions between CC1111-based devices (the chips that are supported by RFCat) and I was in the need to easily encode and decode my payloads using GNU Radio. GNU Radio already contains several packets encoder/decoder blocks, but none of them (if I’m right, and I hope that I am) deal with the same header length, whitening algorithm and/or checksum used by the CC1111 chips. In the CC1111 world, the header is one byte length, the checksum is CRC16 and the data whitening is performed using the following algorithm http://www.ti.com/lit/an/swra322/swra322.pdf.
Here is a simple GRC flow-graph demonstrating how to encode and transmit CC1111 packets using your favorite SDR device:
UPDATE: Version 0.2 released on 29th of June 2014. Check out https://github.com/funoverip/epowner.
I received so many requests for this exploit code. Usually my response was something similar to: “Because the exploit can p0wn a whole network environment within 2 minutes (only by talking with the McAfee ePO server), and that vulnerable ePO servers are currently exposed on the Internet, I have to wait a little bit before releasing it” (problem of consciousness the doctor said…).
McAfee released a security patch on March 2013. So one year ago. Guess what, Internet servers are still vulnerable (come on.. really ?) I think that I did my job and waited long enough. I can’t save the planet every day.. Some companies will be magisterially owned but after the OpenSSL Heartbleed story, I don’t really care anymore. I consider these companies already compromised since a while ..
Do want to help me to turn this PoC into reliable exploit code ? Here is the short story about CVE-2013-1612, a remote buffer overflow that I’ve reported to Symantec in June 2013. The vulnerability impacts Symantec Endpoint Protection Manager (SEPM, a.k.a. the central SEP server) versions 12.1.0 to 12.1.2. Here are some references about the bug:
The PoC code (provided below), simply overwrite EIP by using a SEH-based technique. Unfortunately, due to memory protection mechanisms, I wasn’t able to create a stable exploit using this technique since all modules are compiled using the /SafeSEH flag and workarounds (that I knew) were found useless.
Pointer overwriting approach
I finally tried a second approach which only requires to bypass DEP and stack canary protections (/GS). Btw, Symantec DLL aren’t compiled with ASLR. So, instead of triggering a memory access violation by filling the stack (as for a usual SEH-based overflow), I’ve observed the process behavior when only a few bytes are overwritten and realized that an interesting pointer is overwritten. This pointer is a “destination address” argument passed to a memcpy() call, a few instructions after the the overflow. On top of that, the “source address” given to memcpy() points to our shellcode! So, I have the pleasant capability to copy “anything” “anywhere”, as illustrated by the following screenshot. The source pointer contains to the shellcode address and destination pointer is currently set to 0xAAAACCCC.
Using this memcpy(), my goal was to overwrite the “saved return address” value of the memcpy() frame, with the first instruction of my ROP chain. Therefore, as soon as memcpy() returns, it starts executing my payload. By doing this, no Stack-Guard cookies are broken :-) (do you get the big picture?).
Using this approach, /GS protections is bypassed and a classical ROP can be used to circumvent DEP. So far so good excepted that I need to know the address of the memcpy() frame, and here comes the problem. By default, SEPM runs 330 threads, and each of them use its own stack based-address. Therefore, the address of the memcpy() frame is different for each thread. So, I need to know which thread is dealing with my HTTP request :-/
Can I use a brute-force approach ? Yes. The service restarts automatically upon crash (example: if I write at the wrong address). However, it will take a while and the service remains unavailable during the attack (constantly restarting).
There is however something interesting to know here. I have observed that right after the service restart, the first HTTP request sent to the server is “most of the time” handled by a predictable thread ID and therefore, a predictable stack-based address ! When you find it, only a few attempts are needed to write at the correct memcpy() frame address. Unfortunately, this knowledge was still found useless to me because the thread ID that serves the first request seems to be hardware-dependent. Actually, I have no idea how Windows allocates new threads and this is where I stuck in this approach… My exploit works in my labs, but won’t work in yours. I’ve observed totally different thread ID on other platforms :-/
If you have any brilliant idea or find another approach, please give it a try ! (and please keep me informed :-) ). The PoC code and a vulnerable version of the software is provided below.
- PoC code: Download the SEH-based PoC code here. There is an encryption key (KCS) to provide to the obfuscation function. The PoC will let you know where to find your environment key. (Exploit-db mirror)
- Vulnerable SEPM version: A copy of the vulnerable software can be found here. You will find two httpd processes running, one of them has 330 threads. Attach your debugger to that one.
Below are the slides that I’ve presented at the OWASP Benelux day 2013 (Amsterdam). It covers partial results of my research about Managed Antivirus software, especially how I’ve chained multiple McAfee ePolicy Orchestrator bugs and weaknesses in order to compromise both the ePO server(s) and the managed stations. This is how ePolicy 0wner tool was born.
Thanks to the audience and the staff ! It was a very pleasant moment :-)
This blog entry aims to provide the reader with technical details about the stack-based buffer overflow that we’ve discovered in the web administration console of the WatchGuard XTM appliance (CVE-2013-6021), as well as our journey into the exploit development. While the bug was quite easy to discover, writing a reliable exploit was more challenging due to several limitations, including an impressive hardening of the device.
It is worth to mention that by default, the web console of the XTM appliance is not reachable from the Untrusted interface as long as the firewall policy hasn’t been modified to allow external access. However, the XTMv version (virtual appliance) allows external access to the web console by default.
Watchguard Firewall appliances offer the ability to manage policies per user. Several mechanisms can be used to authenticate users (Active Directory, LDAP, Radius, ..) including a local database called “Firebox database” (Firebox-DB). Based on the XML configuration file of the appliance (which includes the Firebox-DB accounts), I recently needed to evaluate the passwords strength defined by a customer. Unfortunately, the firebox passwords appeared to be encrypted or hashed and I couldn’t find any information about the algorithm used.
Hereunder is an excerpt of the XML configuration file, showing the definition of the user “john“. The password was set to “readwrite“, a deliberately simple choice for testing purposes.
<account> <id>john</id> <password>628427e87df42adc7e75d2dd5c14b170</password> <description/> <idle-timeout>1800</idle-timeout> <session-timeout>28800</session-timeout> [...SNIP...] </account>
If you heard about the following vulnerabilities in McAfee ePolicy Orchestrator version 4.6.5 and earlier:
- CVE-2013-0140 – Pre-authenticated SQL injection
- CVE-2013-0141 – Pre-authenticated directory path traversal
and your environments haven’t been updated yet, then you should consider watching this video…
- Remote command execution on the ePo server.
- Remote command execution on the Managed stations (one ring to rule them all).
- File upload on the ePo server.
- Active Directory credentials stealing.