Heartbleed plugin for FOCA

Tuesday, April 29, 2014

By now, everyone knows about Heartbleed. Just like we did for FaasT, we have created a plugin for FOCA (final version) one of our most downloaded tools. This plugin allows the tool to detect vulnerable servers and audit them, among all the other cool features FOCA counts with.


Loading the plugin in FOCA
To take advantage of the plugin, just download FOCA and create a project over the domain to be audited. Load the plugin from "Plugins" tab in the upper menu, and press on "Load/Unload plugins". Browse for HeartBreatPlugin.dll and load it. Once loaded, it will be accessible from the plugins menu.

There are two options: automatic analysis or manual analysis and exploitation. Checking on "Check all hosts that FOCA detects automatically for the HeartBleed vulnerability" will make FOCA to check for the vulnerability in all domains found for this project.


Automatically checking domains

Domains will go from the "Pending" box to "Checked" or "Vulnerable", depending on the results. All domains found by the usual way FOCA works, will be checked. For a manual analysis, a domain and port has to be specified. There is an option to repeat the attack every 5 seconds and generate a memory dump, that will be stored in a local file.


Manually checking domains

Ricardo Martín
ricardo.martin@11paths.com








Eleven Path's first anniversary. Cakes and Labs

Thursday, April 24, 2014

Although our first post was created in May, Eleven Paths officially started a year ago, in April 2013. It has been a whole year of hard work, but with quite a lot of rewards. Much more than we expected. Anyhow, it is just a year. To be honest, that was "easy". We still have to grow old and create the innovation technology we want to.

Just a year ago, Latch was not even an idea. FaasT was a tiny little thing (right now, it's a monster), Metashield was basically a prototype... and much more (tools, conferences, white papers, patents...). But we still have new technology to show. And it's going to be great. We really think so.

For this special day, we took a break in London, Madrid and Málaga Labs. We stop typing for a while and share a moment with our coworkers. These are just a few pictures of the little party we all shared.

The tiny cake from London (we don't endorse Evian),



The big and customized cake for Málaga, with typos included, and hiding the workers identities (you are welcome)...


And from our headquarters in Madrid.


As far as we can tell, they were all delicious.

Heartbleed plugin, ready for FaasT

Thursday, April 10, 2014

There is a lot of good information about Hearbleed out there, there is little more to add. It is a extremely serious vulnerability, that has shaken the internet from the bottom up. Known as HeartbleedCVE-2014-0160, affects different versions of OpenSSL, from 1.0.1 to 1.0.1f and 1.0.2-beta1. It is fixed in 1.0.1g version.

Although media talked about 66% of affected sites, actually that is the figure corresponding to Apache and nginx market. Not all of them will use OpenSSL and, not all of them using it would be vulnerable. The problem has already been fixed in our Latch servers. By the way, we have renewed our certificates for the API connection. If you as a costumers were doing a certificate check on your side, you must update it with the new ones released yesterday

What can happen to me?

If a vulnerable version of OpenSSL is used, potentially, any user could be able to access an OpenSSL memory chunk. This means that, whatever is in memory in that moment, may be extracted by an attacker in a "clean", easy and remote way. In other words, if this extracted memory chunk contains users, passwords or session cookies or even the private key for that server (something that depends on probability and on "brute force")... this information would be exposed. Since an attacker may connect as many times as necessary, it seems serious indeed. So, the one attacked is not only the server, but its users, accounts, etc. Even depending on how SSL is configured, conversations between server and client could be retrospectively decrypted.

There are lots of scripts with proof of concepts that allow to, with just a click, attack vulnerable servers and, as a collateral effect, its users.

FaasT and Heartbleed

The Faast team has been getting with it during the last two days to adapt and create the code that checks if webs are indeed vulnerable. We already have this feature in our tool, as a plugin. FaasT tests the vulnerability with any OpenSSL used, even if its version claims to be safe.


HeartBleed real time detection, shown in FaasT vulnerabilities list

Faast features includes a way to show, as a picture, the evidence of a vulnerability exploited in a target. The evidence is shown both in the scanning report (in PDF) and the web interface.


Example of an evidence with FaasT

How to implement Oauth protocol in Powershell (an example with Latch)

Wednesday, April 9, 2014


Latch already counts with lots of SDKs and plugins, so you can implement it with different languages or use it with your favorite CMS. There is an "unofficial" bash implementation, even. But you may want to experiment with Latch and some Powershell scripting. Since Latch uses some kind of Oauth technique to authenticate, you may use this code to implement any other Oauth protocol with Powershell, with minor changes to this code.

Different SDKs and plugins developed so far

The best way to deal with this is to create a Powershell module that will export some functions. Creating a module is easy. Just use your editor of choice and write down the functions you need. You will need a Latch account, remember this is just as easy as:
  • Register for free here to get a Latch account in a couple of minutes. Register as a developer.
  • Create your account so you get your Secret and AppId.
  • Download the app for your smartphone: It is available for Android, iOS, Windows Phone and Firefox OS.
Coding

We will create some funcions so we can interact with the official API. First of all, the constants:

Set-Variable API_HOST -option Constant -value "https://latch.elevenpaths.com";
Set-Variable API_CHECK_STATUS_URL -option Constant -value "/api/0.6/status";
Set-Variable API_PAIR_URL -option Constant -value "/api/0.6/pair";
Set-Variable API_UNPAIR_URL -option Constant -value "/api/0.6/unpair";

This will be the code function for the other ones. It will get an URL, the AppId and the Secret. Will return the result (code is simplified):

function AuthenticationHeaders{
param(
[string] $url,
[string] $applicationId,
[string] $secretkey
)

$requestSignature="GET`n"

$date = Get-Date -format u
$date = $date.Substring(0,$date.Length-1)

$requestSignature+=$date+"`n`n"+$url
$sha = new-object System.Security.Cryptography.HMACSHA1
$sha.Key = [Text.Encoding]::ASCII.GetBytes($secretkey)
$seedBytes = [Text.Encoding]::ASCII.GetBytes($requestSignature)
$digest = $sha.ComputeHash($seedBytes)
$base64Encoded = [Convert]::Tobase64String($digest)
$wc = New-Object system.net.webclient
$wc.Headers.Add("Authorization","11PATHS " + "$($applicationId) $($base64Encoded)")
$wc.Headers.Add("X-11Paths-Date", $date)
Try
{
$result = $wc.DownloadString($API_HOST+$url)
}
Catch
{
$ErrorMessage = $_.Exception.Message
$FailedItem = $_.Exception.ItemName
Break
}
return $result
}


Now you have the basics, the functionality is easier to achieve. For example, pairing an account would be just this:

function Pair{
param(
$applicationId,
$secretkey,
$pairingCode
)

$url = "$($API_PAIR_URL)/$($pairingCode)"

$result = AuthenticationHeaders $url $applicationId $secretkey
return $result
}

That will just basically call AuthenticationHeaders with the right parameters.

To check the status of the account (one of the most important features) just use this, using again the main AuthenticationHeaders function.

function Status{
param(
$applicationId,
$secretkey,
$accountID
)

$url = "$($API_CHECK_STATUS_URL)/$($accountID)"

$result = AuthenticationHeaders $url $applicationId $secretkey
return $result
}

For unpairing:

function UnPair{

param(
$applicationId,
$secretkey,
$accountID
)

$url = "$($API_UNPAIR_URL)/$($accountID)"

$result = AuthenticationHeaders $url $applicationId $secretkey
return $result
}

How to use it

There is much more to do and functions to implement, that are left as an exercise to the reader. To use this code, insert a line in the module with the functions you want to export, like:

Export-ModuleMember -Function Pair,UnPair,Status

Now, you can install this module, (just copying it to %UserProfile%\Documents\WindowsPowerShell\Modules, for example) and use it like this,. If you named it Latch.ps1, it would be, for example:

$l = import-module Latch -ascustomobject
$applicationId="bqwRxYXXXXXXX"
$secretkey="6O6zi6PDPnLzfVZcXXXXXXXXXXXXXXX"
$accountID="543ac56903aee2bc7fa40c88ed274e1XXXXXXXXXXXXXXX"

$l.Pair($applicationId,$secretkey,$args[0])
$l.Status($applicationId,$secretkey,$accountID)
$l.UnPair($applicationId,$secretkey,$accountID)

This commands will return a JSON you can parse, just like the specifications in https://latch.elevenpaths.com suggest.

An example of using this scripts for pairing, getting the status and unparing
For another approach to this problem, the SDK for powershell may be used, that will be available soon.