Skip to content
Jul 18 14

GNU Radio – CC1111 packets encoder/decoder blocks

by foip

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:

hackrf_sender_grc

read more…

Apr 27 14

Exploit: McAfee ePolicy 0wner (ePowner) v0.1 – Release

by foip

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…).

yeswecan

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 ..

read more…

Apr 26 14

Symantec Endpoint Protection Manager – CVE-2013-1612 – Remote Buffer Overflow – PoC

by foip

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:

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.

memcpy altered destination address

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.
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...Loading...
Dec 11 13

Turning your Antivirus into my botnet – OWASP Benelux 2013 – Slides

by foip

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 :-)

AV_OWASP_2013_cover

References:

Enjoy!

1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...Loading...

Oct 27 13

WatchGuard – CVE-2013-6021 – Stack Based Buffer Overflow Exploit

by foip

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.

1.1 References

read more…

Sep 23 13

Cracking WatchGuard passwords

by foip

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.

Sample hash

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>

read more…

Jun 14 13

Exploit: McAfee ePolicy 0wner (ePowner) – Preview

by foip

If you heard about the following vulnerabilities in McAfee ePolicy Orchestrator version 4.6.5 and earlier:

and your environments haven’t been updated yet, then you should consider watching this video…

Main Features:

  • 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.

More information:

1 Star2 Stars3 Stars4 Stars5 Stars (19 votes, average: 4.53 out of 5)
Loading...Loading...
Oct 13 12

Metasploit stager: reverse_https with basic authentication against proxy

by foip

1. Introduction

If reverse_https does an amazing job by supporting proxy server and NTLM authentication, it exists some situations where the proxy server only manage basic authentication, and where you hold a valid pair of username and password.

Unlike NTLM, the username and password used during a basic authentication remains in the scope of the process (example: in your browser, after a successful authentication against the proxy server). This is the reason why reverse_http(s) doesn’t know anything about this password. Instead, reverse_http(s) stager use WinInet API to let Windows manages how to reach the Internet.

Back to our basic authentication mechanism, this customized version of reverse_https will let you embed a valid username and password inside the payload, to allow proper basic authentication against the proxy server. The proxy settings (IP, port, proxy.pac, …) are automatically managed by WinInet.

read more…

© 2010-2014 Fun Over IP All Rights Reserved -- Copyright notice by Blog Copyright