What if one could do more than just bypass a sandbox (easy), but actually exploit the sandbox to gain access to custom signatures, client lists, and other customers’ files? It may be easier than you think. Here’s details showing how we exploited some of the leading sandboxes in the industry.

Proofpoint TAP – Background

Nearly three years ago, while researching and creating various sandbox bypass techniques for Proofpoint’s TAP (Targeted Attack Protection) in preparation for a Red Team operation, I did some additional poking around. As I do with most any 3rd party tool/service that I (or my employer) use, I try to validate customer data is reasonably safe. If I can lightly poke around and get sensitive data out, I know an advanced adversary will have no trouble.

I discovered there were few restrictions preventing malware from enumerating the sandbox: exfil’ing local VM files and files from a persistent share mapped to each VM.

An example of the code I used can be found here:
https://gitlab.com/J35u5633k/sandboxExploits_public/blob/master/EnumSandbox_macroVBA.vbs

Proofpoint TAP – My Notification

On 25 May 2015, I sent the following information to Proofpoint via security@proofpoint.com:

Here are a few examples of files I was able to discover by walking the directory structure (and mapped drives) and exfil’ing to my testing server.

Example #1 – Some of your closed-source software and configurations used to scan attachments…

Example #2 – Persistent files containing data from all customer’s attachments, which I was able to download to my server…

Example #3 – Credentials for your infrastructure…

Example #4 – URLs giving me access to every attachment from all of your customers…

Example #5 – grep’d out all of the unique customers from the processMonitor log file. There were 400 customer names I identified with attachments analyzed in the latest processMonitor.log file.

This is by no means an exhaustive list, but we want to be sure you guys were aware of what appears to be a pretty significant data leakage vuln in your Attachment Defense environment. If you need additional detail, please let me know.

Proofpoint TAP – Their Response

Within a few minutes of my email to Proofpoint, they responded, thanking me and said they’d immediately look into it. By the end of the day, my team had a lengthy conference call with our Proofpoint TAM as well as Proofpoint engineers. They informed us they were recalling people from conferences and trainings to work the issue. In less than 48 hours, my team and I had engaged with all levels of their company, which included phone calls with their lead developer in Taiwan. Within 72-hrs they were pushing partial mitigating controls and code. In just under 3 weeks, Proofpoint completely mitigated all discovered and reported vulnerabilities in their TAP product.

Proofpoint TAP – My Assessment

[THIS IS NOT A VENDOR ENDORSEMENT AND IN NO WAY SHOULD BE VIEWED AS ONE]

Any reader of my blog or follower on twitter (@redeemedHacker) knows I have a general distrust of security vendors to do the right thing. In my experience with these types of discoveries and working with vendors, more times than not, vendors seem to only be concerned with their profit margins and not necessarily doing things that actually make us more secure. Proofpoint has, without question, earned my respect and proved they care about their customers just as much, if not more, than their bottom line. They are not perfect, as is no one, but I’m confident this is a vendor you should at least consider for any bake-off you’re planning. I can say, having interacted with multiple vendors and their sandbox solutions, Proofpoint’s sandbox and the team behind it impresses me the most.

Undisclosed Vendor #1 and Vendor #2 (Profit > Customer’s Security)

After the successful exploitation of Proofpoint’s Sandbox, a fellow Red Teamer, David, and I began a hack-all-the-sandboxes effort against all vendor provided sandboxes we had access to. To our shock, all other solutions we tested, had very similar vulnerabilities.

As we did with Proofpoint, our team immediately contacted the other vendors. It took weeks to even get a conference call setup with the other two. One of the two never followed up with us again after the initial conference call. The other vendor followed up a few times, but nothing to the degree Proofpoint had. In both vendor’s cases, they refused to even acknowledge the majority of what we were disclosing as being an issue because, “we don’t see any active threats targeting this.”

To this day, 2.5 years later, these vendors are still vulnerable to most of our findings. They have failed to protect their customers and continue to prove my claims that vendors, as a general rule, care more about profits than customers.

Conclusion

Question everything. Test everything. Don’t ever take a vendor’s word as truth – ever. The mature vendors will appreciate your skepticism, work with you to prove their claims, and, most importantly, will be honest with you about their gaps.

Vulnerability and Exploitation Analysts

• Robert Neel – @redeemedHacker
• David Thompson – @dirty_tizzle

Disclosure Timeline

• 25 May 2015 – Original disclosure to Proofpoint, protected under NDA
• May/Jun 2015 – Conference calls with PP about details
• 16 Jan 2018 – Contacted Proofpoint to see if they would agree to a full disclosure. They tentatively agreed, same day.
• 31 Jan 2018 – Sent draft disclosure to PP for review.
• 02 Feb 2018 – PP approves the disclosure as written
• 02 Feb 2018 – Sent article through prepub process at my employer
• 15 Feb 2018 – My employer approves release