Hut3 Cardiac Arrest – Disclaimer

April 16th, 2014 No comments

Update: I’ve received a clarification from the person who reported the issue that it does not crash the host, but renders HP iLO unresponsive. I have amended the disclaimer to reflect this.

I’ve had an unconfirmed report that the script I wrote to check for the Heartbleed bug, Cardiac Arrest, can crash certain servers render HP iLO unresponsive. Whilst these reports are currently unconfirmed by myself and CNS Hut3, I have added the following disclaimer to the script:

DISCLAIMER: There have been unconfirmed reports that this script can render HP iLO unresponsive. This script complies with the TLS specification, so responsitivity issues are likely the result of a bad implementation of TLS on the server side. CNS Hut3 and Adrian Hayter do not accept responsibility if this script crashes a server you test it against. USE IT AT YOUR OWN RISK. As always, the correct way to test for the vulnerability is to check the version of OpenSSL installed on the server in question. OpenSSL 1.0.1 through 1.0.1f are vulnerable.

Please note the last two sentences especially. Cardiac Arrest is a script that can be used to quickly check various servers that you suspect are vulnerable. It does not claim to be a perfect check, as there are multiple ways to initiate a TLS connection (whilst STARTTLS is supported for several protocols, not all are supported). If you want a fool proof way of securing your servers against Heartbleed, do the following:

  1. Log onto the server and check the version of OpenSSL installed.
  2. If the version of OpenSSL is between 1.0.1 and 1.01f, upgrade to the latest version of OpenSSL and restart all services which use OpenSSL. If you are unsure of which services these might be, restart the entire server.

Also, it should go without saying, but do not use this script against servers you do not have permission to test.

– Adrian Hayter

What’s Worse than Heartbleed? Bugs in Heartbleed Detection Scripts

April 14th, 2014 No comments

I’ve written a blog post for CNS Hut3 (my current employer) about bugs in various Heartbleed detection scripts and tools than I found whilst testing for the vulnerability. These bugs lead to false negative results when the script is pointed at certain SSL / TLS setups, leading to a false sense of security for anyone who uses them.

In addition to finding the bugs, I have also developed a python script which does not suffer from the same issues, and which should work well against most configurations of SSL / TLS. The script is called “Cardiac Arrest” (all the good Heartbleed related puns I could think of, like Heartbleeder and Heartattack, were taken), and it can be downloaded here:

In addition to fixing the aforementioned bugs, the script offers several advantages over similar tools:

  • Support for SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2 (SSLv3 is supported because some servers still respond to Heartbeat requests when using it).
  • Ability to scan multiple ports and hosts in a single scan.
  • Support for STARTTLS on SMTP, POP3, IMAP, and FTP.

By default, the script will check port 443 against any hosts it is given, checking each SSL / TLS protocol until it finds a vulnerability, at which point it will skip to the next port / host. The following screenshot shows the script being run against (CloudFlare’s Heartbleed challenge site):

Cardiac Arrest vs CloudFlare Challenge

Cardiac Arrest vs CloudFlare Challenge

As this script is based on other Heartbleed detection scripts, and these script authors disclaimed copyright to the code, I am following their example and disclaiming copyright over my code as well. Feel free to modify and re-share the code as often as you like.

Exposed Webcam Viewer Removal

May 28th, 2013 No comments

TL;DR: This is a large wall of text that explains why I removed the exposed webcam viewer from my site. The short version is: excessive workloads and shoddy journalism. The long version is below.

A little over a month ago, I removed the Exposed Webcam Viewer from this site. Not only that, but I removed all the articles I’d written about it, and effectively scrubbed the cache of it from Google. I did all this pretty much silently, apart from a comment I made from my reddit account in response to concern that I’d either been arrested or otherwise forced to take down the site.

However, it seems that I had far more fans of the Exposed Webcam Viewer that I originally thought, and I’m still getting emails from people asking why it was taken down. Hopefully this short post will put some closure on the whole thing.

There were a multitude of reasons why I took the viewer down. None of them were related to law enforcement or other government agencies forcing my hand (in fact, I haven’t had any contact from a single one). The main reason the site came down was because it was simply too much work to maintain effectively. I know a lot of people appreciated the easy to use interface (despite not being the most aesthetically pleasing), but what most people were unaware of is how much work had to go on behind the scenes.

Firstly, there was the finding of new content. Although at first I used automated scripts to try to find webcams online, these were less successful later on. As a result, a lot of the cameras that I added were found through quite a lot of manual effort.

Secondly, there was the matter of keeping content up to date. Quite often, cameras would go offline when owners either turned them off, or they were otherwise disconnected. Although there were around 9,000 cameras that were shown as online in the viewer, there were almost 40,000 URLs in the database that had to be checked on a regular basis. Again, this was achieved via automated scripts (initially via curl, and later with my own code), but it was still a pain to ensure that these had all run correctly. In addition, at times when the site was under heavy load, almost all the cameras would be knocked offline due to the sheer number of people trying to connect to them. When this happened, I had to wait until the site was less active in order to run the scripts (else a number of webcams that were only temporarily down would be marked as offline erroneously). As you might imagine, this scenario happened quite often as the site became more and more popular.

Thirdly, whilst a lot of people wanted new or improved features for the interface, development is a very slow process, given my standards for secure programming (on the plus side, the application was hardened against pretty much all web based attacks).

Finally, and possibly one of the most important reasons was the general level of abuse I saw. Granted, quite a lot of people were very good at emailing me when they found a camera pointed at a child, or in a bedroom somewhere, and they were of course removed as quickly as possible. However, a number of feeds seemingly slipped through, and the final straw was when a foreign news channel (who shall remain nameless) decided to do a story on the viewer, featuring a feed of someone’s bedroom and linking to the feed on their website. All this was done without any attempt to contact me (either for an interview, or to let me know about the feed). It was a pathetic attempt at journalism; missing the entire point of the viewer (which was to warn people about insecure cameras, not be some kind of tool for voyeurism), and broadcasting an innocent couple in bed. The webcam page was viewed over 75,000 times before I spotted it and took it down.

Suffice to say, after that incident I was left with a bad taste in my mouth, and I decided to shut down the viewer before someone else could do any more damage. No, there aren’t any immediate plans to bring it back up again. I’m quite enjoying all the free time I now have to work on other projects. I won’t say anything definite though; times change, maybe my mind will too. So, watch this space I guess.

Basic Port Scanning with Nmap

January 15th, 2013 No comments

As promised back in November, here is the first of my penetration testing tutorials. This tutorial will deal with the basics of Nmap, the popular port scanning security tool.

For this tutorial, you will need:

  • Nmap
  • A host (or hosts) that you own, or that you have permission to scan.

The host can be your computer (just use as the IP address), or your home WiFi router (you can usually find the IP address of this in your network settings).

Performing your First Scan

The first thing we will do is run a default Nmap scan against an IP address. Enter the following command at your command prompt, or if you are using Zenmap (the graphical front-end to Nmap), put the command in the “Command” box.


Of course, replace with the IP address you wish to scan ( is the address of my home router). Then press enter. Nmap will start scanning the IP address you gave it, and should produce something like the following output:

Nmap Default Scan

Nmap Default Scan

As you can see, Nmap has detected that the host is up, and that it has 6 ports open or filtered. The entire scan took 9.37 seconds. What did Nmap actually do though? To understand this better, re-run the scan but add the -vv flag to the command:

nmap -vv

A Change of Direction (Penetration Testing Tutorials)

November 30th, 2012 No comments

In case my readers haven’t noticed, I’ve changed the tagline of the blog from “A blog about Information Security, Cryptography, and Privacy” to “A blog about Information Security, Privacy, and Ethical Hacking”. If you don’t see it, try clearing your browser cache.

The reason for this small change in direction is threefold:

  1. When I started this blog a couple of years ago, cryptography was one of my main interests. These days, whilst I still like reading up on advances in cryptography, I don’t find it as interesting as other aspects of information security.
  2. Cryptography itself can be seen as a big part of “Information Security”, so it seemed pointless to effectively include it twice in the tagline.
  3. I’ve worked as a penetration tester for almost 6 months now, so ethical hacking is now something I am focusing on and wanting to write about more.

So I’m going to start a small series of simple but detailed tutorials on various skills required when penetration testing. They will range from basic usage of nmap/nessus/metasploit to the more advanced cracking of stolen hashes and attacking web applications. If people have suggestions for other tutorials, be sure to contact me and I’ll do my best to put one together.