Instructions

This is a cross between a scavenger hunt and a CTF event. Each USB key will contain a puzzle which has to be solved, giving the location of the next USB key. These puzzles aren’t security specific, so anyone technically minded should be able to take part. If you’d like to participate, come along to the Portcullis Village and we’ll point you towards the first location.

Please note: These USB keys are not guaranteed to be safe! The team before you may have left all sorts of nasties on there. Please use sensible precautions, as you would when plugging any unknown device into your computer.

Rules

• Please don’t remove the USB keys from their locations, or move them from where you found them. This will ruin the fun for others!
• Once you find a USB key, copy the contents off before you start working on the challenge.
• Please don’t alter the contents of the USB keys.
• Have Fun!

Problems?

If you have any issues, think something is wrong, or just need some help, please come and find us at the village!

The post EMF Camp 2014 USB scavenger hunt appeared first on Portcullis Labs.

In case you’ve been out of the loop, here’s a brief summary of the vulnerability:

What is it?

Heartbleed (AKA CVE-2014-0160) is an implementation flaw in TLS heartbeats for OpenSSL versions 1.0.1 through to 1.0.1f. It exposes an unpredictably addressed 64KB chunk of server process memory for each malformed heartbeat received. By performing multiple heartbeats, you can recover almost all of the server process’ memory. Basically, the heartbeat acts as an echo request, with the payload size and payload contents determined by the requester. Typically these are filled with a few bytes of data. However by putting in a payload of say, 1KB with a payload size of up to 64KB, the server will return 63KB of its own memory due to a lack of bounds checking.

What does it expose?

Heartbleed can expose anything stored in the server process’ memory, which may contain but is not limited to:

• Session tokens
• Form submissions
• Email addresses
• Usernames
• Passwords
• Private keys

Once the server’s private key is exposed, then all future traffic encrypted by this key can be intercepted and manipulated by anyone holding the key.

Who/What is affected?

Any application using OpenSSL/libssl version 1.0.1 through to version 1.0.1.f. This means both server and client are susceptible to this attack. The scope of this extends beyond just HTTPS- any service using TLS can be affected. This bug has existed in OpenSSL’s code for two years, and at this time there is evidence to suggest that this weakness has been exploited as far back as November 2013.

What should we do?

The remediation for this vulnerability is fairly straightforward, as shown below:

• Update OpenSSL to version 1.0.1g, or recompile with

  -DOPENSSL_NO_HEARTBEATS

• Revoke the certificates for any services which have ever been vulnerable. This is important, otherwise the potentially compromised certificates and keys will continue to work
• Get new certificates

If you have reason to suspect that your service may have been attacked then it would be prudent to suggest that all users change their passwords, as they may have been compromised.

The post Heartbleed appeared first on Portcullis Labs.

It also offers advice on how to protect and correctly configure, with the goal of helping ensure that SSL services have a minimised attack surface.

SSLGPG-1.4.pdf
September 23, 2015
Version: 1.4

578.6 KiB
MD5 hash: f1d0976053e839a85dd19259ba26b0c0
Details

Date:

September 23, 2015

SSLGPG-1.2.pdf
April 10, 2014
Version: 1.2

584.5 KiB
MD5 hash: 1c660fa51cb46805ee76a515aa330005
Details

Date:

April 10, 2014

SSLGPG-1.1.pdf
April 1, 2014
Version: 1.1

578.0 KiB
MD5 hash: 47029e16f8d2ccf5f041d368722c40b7
Details

Date:

April 1, 2014

SSLGPG.pdf
September 20, 2013

576.1 KiB
MD5 hash: eb0599b73eb8f3ef5110d30e14acb32e
Details

Date:

September 20, 2013

The post SSL Good Practice Guide appeared first on Portcullis Labs.

The Team will continue to update the guide going forwards, and will highlight major changes on the blog. Whilst you’re checking out our updated recommendations, why not take a few extra minutes and look at our SSL Certificate Good Practise Guide?

The post New SSL recommendations appeared first on Portcullis Labs.

In fact, this recommendation has drawn some criticism from within the Labs Team itself. Some feel that given that BEAST is mitigated in most web browsers, it is better to eliminate RC4 altogether, and rely on the browsers’ protections to prevent BEAST. However, the counter claim to this notes that the Internet is larger than just the web, as well as the fact that BEAST is easier to exploit than the bias attack. Of course, neither of these solutions are viable in the long term.

Slowly, things are changing. This week, the latest version of the last of the major browsers gained default support for TLS v1.2 (see here). These aren’t the current release versions, but it does mean that support for the majority of users is on the horizon. With this in mind, The Team will start the countdown clock on its current SSL recommendations.

After 01/04/2014 (no joke), the Team’s SSL recommendations will no longer juggle flaky ciphers and suggest iffy workarounds, but instead will recommend TLS versions 1.2 and 1.1 and with them the glut of new ciphers offered. Hopefully these new recommendations (and their implementation by our customers) will result in fewer issues identified on tests, as well as settling yet another internal debate!

To see our current SSL Recommendations, as well as more information about SSL security in general, please see our SSL Good Practice Guide.

The post SSL: Light at the end of the tunnel appeared first on Portcullis Labs.

Key features

This natty python 2 script scrapes a series of web applications (including bing and yougetsignal’s database) and looks at Subject Alternative Names in the SSL certificate to find as many web applications which resolve to an IP address as possible. No guarantees are made as to the completeness or accuracy of the data, but it’s the best we can do. It can give an insight into the attack surface associated with a given IP address, allowing testers to advise client in situations where the risk is out of their control.

Usage and example

$ python2 allthevhosts.py 213.165.238.226
[+] bing search complete
[+] myipneighbours Search Complete
[E]ipneighbour search error.
[+] yougetsignal Search Complete
[+] SAN enumeration complete.
[+] resolved original addresss...
[+] verifying that 8 found URLs resolve to the same address
[+] all URLs resolved

www.portcullis-security.com
labs.portcullis.co.uk
www.portcullis.co.uk
ctads.net
portcullis-forensics.com
portcullis-security.com
portcullis.co.uk

allthevhosts.tar.gz
November 4, 2013

1.7 KiB
MD5 hash: be3c25a78d89f9b5234689250824fbed
Details

Date:

November 4, 2013

The post Finding all the vhosts appeared first on Portcullis Labs.

Key features

This handy little python 2 script does whois lookups on the IP addresses given in a file (one per line), and will give you the range and owner of each of the addresses (with duplicates removed) so you can spot anything that looks fishy before you start testing*.

Usage and example

IP address file:

8.8.8.8
8.8.8.9
4.4.2.2

And to run:

$ python2 whoislikeaboss.py ips
8.0.0.0 - 8.255.255.255 Level 3 Communications, Inc.
4.0.0.0 - 4.255.255.255 Level 3 Communications, Inc.

Simples!

*- Common sense not included.

whoislikeaboss.tar.gz
November 4, 2013

901.0 B
MD5 hash: c628b46d07ee1c65668687e6d11a09c9
Details

Date:

November 4, 2013

The post Whois… Like A Boss! appeared first on Portcullis Labs.

In their presentation, the Mailpile developers stated the concerns with cloud email to be:

• The centralisation of email storage, making mass surveillance trivial
• Poor spam filtering
• Lack of innovation with regards to F/OSS solutions
• Mass encryption is a “distant dream”
• Proprietary lock-in
• Risk of EEE tactics (Embrace, Extend, and Extinguish)
• Spam filters being used for censorship
• Incompatibility with encryption

I happen to agree with each of these issues (perhaps excepting spam). However, in the wake of PRISM, maybe we should even expand this problem space. Metadata is a big deal: It reveals (in a best case scenario) who you’ve been talking to and when, how long your messages are, and if you include attachments. Why can’t we protect this data too? Granted, this would require a somewhat more radical solution,  but I don’t see why this is a problem that couldn’t be solved. Still, it’s not fair to judge Mailpile on the basis of problems it doesn’t aim to solve, so I’ll discount this for the rest of my post.

What Mailpile propose is yet another mail user agent. Mailpile’s killer feature in the presentation appeared to be the search functionality, returning genuinely impressive search results in mere milliseconds. Beyond this, the interface was vaguely reminiscent of GMail, though obviously still in a very early stage of development. So, a nice interface, but it still doesn’t seem to address what I believe is the key issue surrounding web mail: Centralisation. From a pragmatic standpoint, no matter how simple it is to employ GPG, the standard user will not opt for it. Therefore, in my mind, the easiest way to raise the barrier to mass surveillance (the hot button topic right now) is to decentralise the storage of email, something which Mailpile fails to address.

Let’s take each of the problem bullet points, and see if Mailpile offers a solution. Mailpile at least partly addresses the following:

• Lack of innovation with regards to FOSS solutions – Does Mailpile count as innovation? That’s a matter of opinion
• Proprietary lock-in – Mailpile somewhat addresses this. If one interface supports multiple back-ends, users will find it easier to move between them
• Risk of EEE tactics (Embrace, Extend, and Extinguish) – Mailpile partly addresses this, much for the same reasons as above
• Incompatibility with encryption – Mailpile solves this problem! A locally hosted client is ideal as a solution for this problem

So, out of 8 issues identified with cloud email, Mailpile fully solves 1, and partly addresses 3. What of the other 4?

• The centralisation of email storage, making mass surveillance trivial
• Poor spam filtering
• Mass encryption is a “distant dream”
• Spam filters being used for censorship

All of these, excepting mass encryption, are really server side problems. Mailpile couldn’t hope to solve these. So, what would? Spam filtering seems to be already solved – numerous crowd-sourcing solutions exist, and in my mind this is the right way to go about solving this problem. The decentralisation of email storage just relies on more people running mail servers, and not relying on one of the big cloud providers.

The relative complexity of installing, configuring and maintaining an email server puts many off – this is what web mail really offers the average user. In my mind, the solution lies in a mail server that’s simple to deploy and maintain. Decentralising the infrastructure is what will negate the majority of the evils of web mail, not another web mail client, no matter how timely the marketing is.

On Mailpile’s own web page, they have quotes from articles on their product. These come from Wired, TechCrunch, Boing Boing, and Crowdfund Insider. These large publications should have done their homework before praising Mailpile’s security, as it does not appear to address the problems it aims to solve. It is my belief that the majority of Mailpile’s funding has come off of the back of such positive press, some of which is completely unwarranted.  It’s nice to see a positive reaction to a product with the aim of improving security and privacy for end users, but next time can we actually make sure it delivers on these goals first?

The post Mailpile: Well, they’re half right appeared first on Portcullis Labs.