You will never get anything out of me: introducing Nuke My LUKS

Recently I wrote and published Nuke My LUKS, a fairly simple network-based panic button designed to overwrite the LUKS header with random data and shutdown the computer in case of an emergency situation. This code was inspired in the idea of panicbcast by Niklas Femerstrand.

This tool can be useful for activists, human right workers and others that face an adversary, such as law enforcement, that can coerce the subject to disclose encryption passwords for the computer’s hard drives.

IMPORTANT: This will make impossible to recover any data stored in the disk even if the password is known. It is recommended to store your backups, as well as your original LUKS header, encrypted and in a safe location. Use this code with precaution.

How it works

Nuke My LUKS is divided in four different small pieces of code:


In a nutshell, it works by sending a UDP broadcast message to port 1337 with a tag appended to a user-defined password. In case the password matches, the script for destroying the LUKS header is executed.

NOTE: Configure your firewall rules to allow UDP broadcast messages from your trusted computer running the client of Nuke My LUKS.

PS: Notice that it is possible to repurpose this code to use any shell script and perform other actions, but the original design is to destroy the LUKS header of the computer.


PLEASE READ: As the script used to destroy the LUKS header with random data reads off /dev/urandom and writes its content into the beginning of a LUKS-capable device, such as /dev/sda1, there is no guarantee this action will work as intended in SSD drives, given the way these drives behave during write operations.

For more information about this topic see Data remanence on Wikipedia.

dm-crypt/LUKS version > 1.6.4 implements the option luksErase. However, in order to ensure it will also have a similar effect in older installations we’re using the old fashioned dd instead.


Generate a config file using

julio@trouble:~/programming/Python/security/nukemyluks$ ./ mysupersecretpassword
[+] Configuration file created successfully.

Copy the generated config.ini file, and the LUKS header destruction script to the computers you want to have this code running:

julio@trouble:~/programming/Python/security/nukemyluks$ cat config.ini
password_hash = $2a$13$fFEVaVHalvesYhVMUJTrUOjGPdUUvxzLIJUIqU8.jc3PJFbbQ.vSe

Make sure the script can run with root privileges. This is necessary to call dd on a device.

Now execute and leave it running on the background.

In case of panic, pass your password to

julio@trouble:~/programming/Python/security/nukemyluks$ ./ mysupersecretpassword
You will never get anything out of me: introducing Nuke My LUKS

Scanning the Internet for backdoored ScreenOS devices: some statistics and tales of evading honeypots

EDIT: January 6th 2016 – it looks like I used the wrong tag on Censys, leading to a much higher number of potential NetScreen devices. Will update the post as soon as I get everything right. Fixed.

On December 18th 2015, Juniper published an advisory stating that unauthorized code was discovered in its flagship product ScreenOS. This unauthorized code were in fact two different backdoors: one related to a weakened encryption algorithm that makes traffic prone to eavesdropping by a passive attacker and another one that affects the authentication mechanism, allowing an adversary to gain unfettered access to the device using a secret account.

The focus of this blog post is to gather statistics on the approximate number of Internet-facing Juniper ScreenOS affected by this publicly-disclosed authentication backdoor. This study leveraged results from passive search engines such as SHODAN and Censys.

Continue reading “Scanning the Internet for backdoored ScreenOS devices: some statistics and tales of evading honeypots”

Scanning the Internet for backdoored ScreenOS devices: some statistics and tales of evading honeypots

A survey of insecure Flash crossdomain policies – Alexa Top 10,000 case study

EDIT: October, 9th 2015 – added Appendix section.

Just like many other information security consultants, most of my billable time is spent performing web application penetration testing. Also just like every other professional pentester out there, I rely a lot on Burp Suite and its amazing scanner.

More often than not, Burp Scanner comes up with a finding that, under certain conditions, can have a rather high impact but is not commonly exploited: insecure crossdomain.xml file.

In a recent blog post, Matthew “mandatory” Bryant exploited this vulnerability against the popular music service rdio. This inspired me to conduct a survey against Alexa Top 10,000 most visited sites on the web (October 2015) in order to verify how widespread crossdomain vulnerability actually is, as well as hopefully raise awareness about the issue. It is worth mentioning there is some prior art on this exact same topic published in an academic paper from 2011 and a blog post by Zach Bloomquist, but I was not aware of any of them until I started to write the support code for this survey.

The rest of this blog post briefly discusses what crossdomain policy is and how it can affect the security of a website. It also describes all steps necessary to conduct the survey, including the relevant technical details and code, and presents its results.
Continue reading “A survey of insecure Flash crossdomain policies – Alexa Top 10,000 case study”

A survey of insecure Flash crossdomain policies – Alexa Top 10,000 case study

Brief analysis of a SQL injection in Cacti 0.8.8b

Back in September 2013 I wanted to practice some code auditing and picked the latest version of Cacti (v0.8.8b at the time). I spent a few hours looking into the code and also assessing a running instance of Cacti and this exercise resulted in a few vulnerabilities. I was motivated to finally put together this write-up since several SQL injections were fixed in Cacti in July 2015. As of this writing (September 2015), it seems like this vulnerability is still present in the latest version of Cacti.

For those who don’t know, Cacti is a quite popular network monitoring tool pretty similar to Zabbix and Nagios. A quick Google search for intitle:”Login to Cacti” comes up with more than 4,000 results. Finding high severity bugs in Cacti means that chances are very high an attacker will actually break into a box located in a privileged position in the network, as it needs to be positioned in a way to monitor traffic and events.

Cacti is a PHP application and I have to say, it’s miserable from a security point of view.
Continue reading “Brief analysis of a SQL injection in Cacti 0.8.8b”

Brief analysis of a SQL injection in Cacti 0.8.8b

CampCTF Spam100 – pwn

Few days ago I had the chance to attend to Chaos Communication Camp 2015.
I personally had a great time camping, swimming in the lake and catching up with friends I usually bump into conferences like this — including an old friend from high school I haven’t seen in ages.

This year CCC Aachen held a capture the flag competition at the event named CampCTF. The CTF was open for everyone interested and there was no requirement of physical presence at the camp to play.

I admit I barely touched my computer while at the camp — I was more keen to enjoy a good time with friends and have holidays — I had a go with some of the challenges of the CTF.

Without further ado, let’s proceed with the actual write-up of one of the challenges of the CTF: Spam100.
Continue reading “CampCTF Spam100 – pwn”

CampCTF Spam100 – pwn

On the security implications of window.opener.location.replace()

It’s no secret I am a big fan of many HackerOne bug reports and public penetration test reports authored by companies such as Cure53 and Least Authority.

In fact, pretty much every week I spend some of my free time reading bug reports. Regularly I stumble upon very interesting attack vectors and oftentimes learn tricks I had never seen before. This post is about one of the techniques I learned sometime ago whilst reading a report submited to HackerOne, authored by a bounty hunter named Daniel Tomescu.

After finished reading the particular report, I was a bit confused and not convinced this was a bug in the application at all. Then I had a discussion about it with my friend Shubham Shah and he clarified some of my doubts about it.

Digging in a bit more about the issue, I discovered this is indeed a design decision of all major browsers. However, it seems to me that the security ramifications of this design decision are not well understood and often ignored.

The objective of this post is to present the issue, discuss it in as many details as possible and make a case of why this issue has a greater security impact than many people may think. Continue reading “On the security implications of window.opener.location.replace()”

On the security implications of window.opener.location.replace()

Positive HackDays 2012 $natch write-up

Sometime ago while browsing old backups I stumbled upon a raw write-up I did for $natch, a vulnerable Internet banking application created for a CTF-style competition organized by the folks of Positive Technologies. They held this contest at PHDays 2012 in Moscow and at the 29th Chaos Communication Congress in Hamburg.

I participated in the contest at the 29C3 and scored second place (in fact I found more bugs than the winner and certainly would have won if my laptop’s network card hadn’t bailed out – I had to borrow one from the organizers so I could play).

This post will discuss in detail every vulnerability found within the application, along with the relevant vulnerable source code, and explain all steps necessary to successfully exploit them.

Continue reading “Positive HackDays 2012 $natch write-up”

Positive HackDays 2012 $natch write-up