McAfee SiteList.xml password decryption
Recently, a very good friend of mine (@Sn0rkY) pointed me out the story of a pentester who recovered the encrypted passwords from a McAfee SiteList.xml file, using Responder (link). Simply clever.
Since I worked hard on McAfee products in the past (see ePolicy 0wner), he asked me if I knew how to decrypt these passwords, directly from the SiteList.xml file. The answer was no. But, another link from SySS GmbH pointed out that the encryption was based on 3DES and some XOR. What ?!? That sounds very similar to what I’ve found earlier in ePolicy Orchestrator !
So, back into IDA Pro and Immunity Debugger, I’ve found that – indeed – the algorithm reused the same hardcoded 3DES key in ECB mode, but that the XOR was a bit different. A short python implementation of the reversed algorithm provided me with the following result:
$ ./mcafee_sitelist_pwd_decrypt.py 'jWbTyS7BL1Hj7PkO5Di/QhhYmcGj5cOoZ2OkDTrFXsR/abAFPM9B3Q==' Crypted password : jWbTyS7BL1Hj7PkO5Di/QhhYmcGj5cOoZ2OkDTrFXsR/abAFPM9B3Q== Decrypted password : MyStrongPassword!
Yes ! :-)
It is time to share this knowledge with the penetration testing community. Isn’t ?
https://github.com/funoverip/mcafee-sitelist-pwd-decryption
Happy password recovering!
foip
(12 votes, average: 3.58 out of 5)
Loading...
1. Introduction
So we’re back, ready to run through an additional step into our Verisure Wireless alarm journey. This post is the second chapter of my Verisure story where we’ll learn how to extract and dig into firmwares. Getting firmware out of the memory will actually help us to grab various AES keys, a required step to decrypt both radio and ethernet communications, but also authenticating against the local console using USB connector (this will be described in part 3).
The reader can found the first part of this journey at the following location, where we briefly introduced the Verisure Wireless equipments and shown how to demodulate RF messages using GNU Radio framework and the HackRF One SDR platform.
Our initial investigations aimed to get a clear view on the alarm design and more especially, its security level. We learned from part 1 that radio communication is encrypted using a strong algorithm (AES-128). However, even the strongest cryptographic algorithm can be broken if weaknesses exist in the software and particularly in the keys management. We’ve been reassured to see that Verisure made a very good choice in their design. Additionally, keep in mind throughout this article that our work was performed inside a lab, and successfully achieved because we got physical access to the alarm. We were indeed able to read and/or modify firmware and memory which is not possible in a live environment, at least not without triggering multiple anti-sabotage sensors.
1. Introduction
Verisure is a supplier of wireless home alarms and connected services for the home. A Verisure setup can be composed of multiple devices, sensors and/or detectors such as Motion detectors with camera, Magnetic contacts for doors or Windows, Smoke detectors, Keypads, Sirens, etc. Each component of the setup communicates using wireless technology with the central gateway called “Vbox”, it-self monitored by Verisure agents through the Internet and/or 3G connection.
As a Verisure customer, I was curious to get a clear view of the design and security measures implemented by the manufacturer. I therefore decided to buy a testing Kit on eBay (120 Euros) to open it and starting an exciting journey inside the boxes.
This post is the first part of my Verisure story and aims to observe radio communications between the multiple devices of the alarm. In other words, we will translate the radio communication into binary messages. Please note that Verisure is the new name of Securitas-Direct. You may potentially find both names in my scripts and screenshots.
Introduction
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.
Packet encoder
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.
Hi,
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 ..
Hello,
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:
- http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&suid=20130618_00
- http://www.securityfocus.com/bid/60542/info
- https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1612
SEH-based approach
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 :-/
Please help
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.
Cheers,
foip
Downloads
- 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.
(5 votes, average: 3.40 out of 5)Loading...
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 :-)
References:
- https://kc.mcafee.com/corporate/index?page=content&id=sb10042
- http://www.kb.cert.org/vuls/id/209131
- http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0140
- http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0141
Enjoy!
(5 votes, average: 4.60 out of 5)Loading...
1. Introduction
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.