Drones – A hacker’s playground

Unmanned Aerial Vehicles (UAVs) offer new perspectives, both from a civilian and a military standpoint; yet, they present vulnerabilities having the potential to lead to disastrous consequences regarding public safety if exploited successfully, as evidenced by recent hacks. These repercussions can be prevented by implementing best practices, continuously assessing the technologies used and most importantly by remaining aware of the environment, of the weaknesses that may be exploited and of the threats that may emerge. The purpose of this article is not to provide countermeasures or solutions, but to outline flaws and vulnerabilities to better understand and address potential threats and threat actors.

timeline

Figure 1 UAVs hacks disclosure timeline

As shown by recent hacks, several professional Unmanned Aerial Vehicles (UAV) used byarmed forces, governments, police departments and the private sector are vulnerable to critical attacks which exploit both technical vulnerabilities and design flaws. This can lead to UAVs being spied on, made inoperable or controlled by the attacker unbeknownst to the UAV’s owner. Continue reading

DEFCON qualifiers write-up: Baby-re

In this simple challenge, we’re given the binary of a remote service:


$ file baby-re
baby-re: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped

This asks for 13 inputs, and then returns `Wrong`, unless we give it
the right input.


$ ./baby-re
Var[0]: 1
Var[1]: 2
Var[2]: 3
Var[3]: 4
Var[4]: 5
Var[5]: 6
Var[6]: 7
Var[7]: 8
Var[8]: 9
Var[9]: 10
Var[10]: 11
Var[11]: 12
Var[12]: 13
Wrong

Continue reading

TROOPERS 2016

I recently attended the TROOPERS conference, held in Heidelberg, Germany. A lot of interesting research was presented, in this blog post I’m going to summarize selected talks that I particularly enjoyed.

The first presentation was by Philippe Teuwen, where he demonstrated his latest attack on white-box cryptography. The idea is to apply existing hardware attacks such as side-channel or fault attacks in order to break white-box cryptography implementations. For example, a simple DPA can be applied to software execution traces to reveal the key with only 16 traces. This approach is really efficient since all publicly available challenges can be broken and this could expose, for example, the incoming Host Card Emulation systems (HCE). In addition, Philippe released all his tools as open source on his GitHub account, allowing everyone to experiment with these attacks. He also posted the instructions on how to use the software on the Insinuator blog. Continue reading

Insomni’hack 2016: microwave writeup

This is a write-up for the microwave pwn of Insomni’hack CTF (first published on deadc0de.re).

Following binaries were given:

  • microwave_61f50dba931bb10ab3089215b2e188f4
  • libc.so.6

Those are both available here

The program

The program simulates a microwave able to connect to twitter and tweets your favorite food.

There are 4 options:

    1. Connect to Twitter account: asks for username and password to connect to twitter
    1. Edit your tweet: edit content of the tweet(s) to be sent
    1. Grill & Tweet your food
    1. Exit

Connect to twitter:

:::
 --------------------------------------------------------
 |     Welcome to the next generation of MicroWaves!    |
 |                         ***                          |
 | This stylish Microwave with Grill function, includes |
 |      a function that tweets your favourite food!     |
 |                         ***                          |
 --------------------------------------------------------
           ----------------------------------
           |  1. Connect to Twitter account |
           |  2. Edit your tweet            |
           |  3. Grill & Tweet your food    |
           |  q. Exit                       |
           ----------------------------------

           [MicroWave]: 1

           Log in on Twitter:
           username: test
           password: test

Checking test
Twitter account
...

Edit your tweet:

:::
           ----------------------------------
           |  1. Connect to Twitter account |
           |  2. Edit your tweet            |
           |  3. Grill & Tweet your food    |
           |  q. Exit                       |
           ----------------------------------

           [MicroWave]: 2

           #> some blabla

           Done.

Grill and tweet:

:::
           ----------------------------------
           |  1. Connect to Twitter account |
           |  2. Edit your tweet            |
           |  3. Grill & Tweet your food    |
           |  q. Exit                       |
           ----------------------------------

           [MicroWave]: 3



  Okay! Let's do this!
...

Here are the protections of the binary

:::bash
$ checksec microwave_61f50dba931bb10ab3089215b2e188f4
[*] '/tmp/microwave_61f50dba931bb10ab3089215b2e188f4'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
    FORTIFY:  Enabled

Continue reading

Insomni’hack 2016: Pcapbleeding writeup

The Insomni’hack conference and CTF happened last Friday in Geneva, as usual it was a lot of fun. And as usual, Dragon Sector won the CTF, beating a few other world-class teams that made the trip for this on-site jeopardy CTF. About 80 teams registered, and the final ranking looks as follows for the first 25 teams:

ranking

There was only one challenge in the crypto category, “pcapbleeding”. With such a name, the vulnerability was obvious: Heartbleed. We were given three files

  • attack_log.pcap, a capture of a partial TLS session
  • hb_scrt_ch.crt, the certificate of the server
  • pcap_flag.pcapng, this one is self-explanatory

I worked on this challenge with my teammate Brecht Wyseur from the duks team. Here’s how we solved it:

Continue reading

A perspective on the state of the SSLiverse as of early 2016

tl;dr; Most studies about SSL tend to use SSL information retrieved by DNS domain names. This article provides an overview of the SSLiverse when SSL information is retrieved from each SSL enabled host in the IPv4 range on port 443.

With today’s state of the art scanning tools and proper infrastructure, it is now possible to crunch interesting data from Internet hosts on the IPv4 address space. The focus of this article is on SSL enabled hosts information. While most studies found on the web tend to consider SSL information retrieved via domain names, the numbers presented in this article propose a different perspective.

However, before I expose these interesting numbers, make sure to take note of the following:

  • The scan from which this data comes from was performed in February 2016 (scans are conducted on a regular basis).
  • Information was collected on a per IPv4 host basis. This means that only one (the default) certificate was retrieved for every host that was scanned.
  • Only port 443 was considered. Scanning other ports for SSL information (such as 465, 993 or others) would probably expose slightly different data and be more accurate about the state of the SSLiverse.

Now that this is clear, let’s dig into the data, shall we?

Continue reading

The NORX Bug Bounty Program

This post is on behalf of the team that designed the cipher NORX, namely Philipp Jovanovic (EPFL), Samuel Neves (Uni Coimbra), and JP Aumasson (Kudelski Security).

Are you a cryptanalysis-ninja with differentials, boomerangs, and bicliques being your weapons of choice? Do you know what IND-CPA, IND-CCA{1,2}, and INT-{P,C}TXT actually mean and that querying random oracles has nothing to do with randomly visiting astrologers? Or do your hacker-friends celebrate you as the personified american fuzzy lop?

Well, if you answered yes to any of these questions and are up for a challenge, then head over to https://norx.io and find some bugs in one (or all) of the following categories:

  • Bugs in the NORX algorithm (a.k.a. cryptanalysis)
  • Bugs in the NORX security proofs (evidence of a wrong proof and/or a wrong result)
  • Bugs in the NORX source code (software bugs or inconsistencies with the specs)

If you answered no but are nevertheless up for a challenge, then head over to the NORX website too and give it a try, as in each category you can win a bounty of $250! In order to get a reward, your submission has to be the winning entry in one of the above categories.

The deadline for submissions is May 31, 2016 at 23:59 (UTC+01:00). Send your findings to contact@norx.io and we will tell you if your results are eligible. The winners of the bug bounty program will be announced in the first week of June, 2016.

Happy hunting!

The NORX team

Acknowledgements: The NORX bug bounty program would not have been possible without our generous sponsors. We thank Bryan Ford, head of EPFL’s Decentralized and Distributed Systems Lab, and Kudelski Security, for providing financial support.