Was the LizardStresser stressful?

After taking down the Xbox Live and the Playstation Network gaming services, the Lizard Squad group came again in the spotlight after the leak of a database of their LizardStresser not-so-new booter (a service providing Distributed Denial of Service or DDoS against payment). The breach occurred mid-January and resulted in the release of a 19 MB sql file containing the database content, consisting of about 150000 lines. We analyzed the data, focusing on targets and on attacks. After a bit of scripting, behold!

First, here’s a summary of the quantities of attacks and of attackers, showing that only 1.95% of the registered users actually used the service and launched at least one attack:


Continue reading

Volatility plugin for Dyre

Dyre is a banking malware discovered in middle of 2014. It can intercept HTTPS traffic, using techniques documented in this Introduction to Dyreza.

In the context of our review of malware faced by customers, we need to rapidly respond and assess the risk. Dyre is malware found in such context, and we are releasing a Volatility plugin that we are using internally to dump configuration in memory for Dyre (Dyreza) samples.


Continue reading

Auditing the security of a linux system

The purpose of this post is to detail what type reviews will be performed on a linux computer to determine if it meets the security requirements of the PCI DSS standard. To do this, whenever possible, I will detail the commands to use in each case.


However, although the main purpose is to audit compliance with PCI DSS, the proposed revisions can be used as a starting point for any security audit of a linux computer you want to perform.

All the commands in this post have been tested on Ubuntu 12.04 computer, so it is possible that some of them need to be modified to work properly on other Linux distributions. We can use the lsb_release-a command for the exact version of the system we are reviewing, or obtain it from the /etc/os-release. Continue reading

31c3 – A New Dawn

Co-authored by meatwad and adr13n

We attended the 31c3 — a New Dawn conference which took place in Hamburg, Germany from the 27th of December 2014 to the 30th of December 2014.

The conference is still as underground as you expect it to be. A lot of hackerspaces, many 3d printers and an underground geeky atmosphere. Don’t expect bigwigs and other corporations trying to sell you their products, CCC is not about selling and marketing. It’s all about the community, the sharing and above all security in general.

So after some “Club Mate”, we headed to the talks. The following list gives you an overview of the different talks we attended. For a complete list of the talks as well as the schedule, the reader can refer to the links list at the end of this post.

Continue reading

안녕하세요 FDTC 및 CHES 2014

I recently attended two of the largest workshops about hardware security: FDTC and CHES in Busan, South Korea. As usual, lots of new results were presented there.
During the Fault Diagnosis and Tolerance in Cryptography workshop (FDTC), three presentations, including the invited speaker, were about different ways to attack Pairing Cryptography algorithms with fault and side-channel attacks. This indicates that focus has moved to this cryptographic primitive and the security of its hardware implementations. Two papers presented fault attacks against the Miller algorithm which is used to compute pairings. One of these paper showed that combining an initial fault in the Miller algorithm with a second fault to bypass the final exponentiation of a pairing was possible on their target device, a AVR XMEGA-A1 microcontroller.
Two different glitch attacks were presented against microcontrollers. One of them showed that heating the microcontroller helped to induce further effects when clock glitching. In the second paper, a combination of clock glitching and underpowering were applied on both ARM Cortex-M0 and a Atmel ATxmega 256 microcontrollers. The faults obtained were skipped or duplicate instruction executions as well as wrong calculations.
New fault attacks were presented against GOST, SIMON, SPECK, Feistel and Substitution-Permutation networks. Aside from attacks, a new countermeasure was presented to protect RSA implementations against multiple fault injections. The authors made a large effort to formalize fault injections as well as showing equivalence of some fault models. They then showed how to build provable secure countermeasure against high-order fault attacks (multiple faults) with a generic fault model. This may provide a good tool for hardware designers.

P1040192 During the Workshop on Cryptographic Hardware and Embedded Systems (CHES), the best paper award was given to a team from Tohoku and Kobe. They showed that it is possible to build a detector inside a circuit with standard cells that detects if an electromagnetic (EM) probe is near the die. Usually, we use EM probes to either perform leakage acquisitions for side channel analysis or to inject localized faults using local electromagnetic radiations. If a chipset is equipped with such detector it may hinder such attacks. Their detector was implemented and tested within an AES processor. A video of their experiment was shown during the rump session.
Another team showed that a hardware Trojan construction presented last year which consists in modifying the dopant level of a gate into a circuit, can be detected when the circuit is analyzed with a FIB or a SEM.

A presentation leading to a nice demo (picture on the right) was given by people from Tel-Aviv University and Technion. Their idea was to extract the secret key used during GnuPG encryption only by touching the chassis of a laptop. They successfully demonstrated proof of their attack on stage.
New fault attacks were also presented. A team demonstrated that the countermeasure for AES which was defeated last year has other weaknesses and they proposed a different countermeasure. Another team combined fault attacks with side channel information to attack the AES key scheduler. Meanwhile, they solved an interesting previous open question about the Hamming weight of the key scheduler. They showed that two different keys can have the same key expansion Hamming weight. They provided an algorithm to construct such keys. A side channel analysis of prime number generation was presented by ANSSI. They attacked the prime sieving algorithm before the Miller-Rabin’s tests during the prime number generation. They applied their attack on a smartcard implementation.
An interesting presentation was made about Photonic Emission Analysis (PEA). A team from Berlin performed an analysis of an arbiter-based Physically Unclonable Function (PUF), which is a common construction of timing-based PUFs. The photonic emission principle is simple. Each CMOS transistor can emit photons during a switch of its state. These photons can be observed from the backside of the chips and thus give information about the physical location of the active part of the die. This team implemented its PUF on an Altera MAX V board. For the photonic emission analysis they used a Si-CCD camera and an InGaAs avalanche diode to provide both spatial and timing resolution. With their setup they obtained the timing of some reference challenges and then these timings were used to predict further PUF outputs of given challenges and finally clone the PUF.
To sum up, more and more complex and combined attacks are being realized and the theory behind them is becoming more fully understood. This progression is resulting in hardware attacks which are practical and sometimes devastating to the security of certain products. Links are are being made between previously separate domains to achieve practical attacks. I saw lot of amazing presentations and I had really nice discussions there. I hope to see you next year in Saint-Malo.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Forum EPFL 2014 Crypto Challenge

For the Forum EPFL 2014 job fair, we created a crypto challenge—in the spirit of CTF hacking contests—and offered to award a quadcopter drone to the first student to solve it and Bus Pirate devices to the next 2nd to 10th.

After about 10 days, no one solved it, although the difficulty was well below that of a competitive crypto challenge at (say) DEFCON qualifications.

Given the password-protected ZIP archive https://www.kudelskisecurity.com/kschallenge.zip, a first step was to recover the password: 1234. OK, next step:

The ZIP archive contained:

  • a text file named ciphertext and containing the string “407747220c5f2754c6fd192502c8f597814bc95ce897eb6a3c45ba4a7150fe86d054d1607e94bf0fc90790ddba8925b50c8c6159b091651442779e86febfc6b1bd736d77d28d89d96ebee2d4038f26cb77a1b843afdb1c7bf3c01518a77b6f87d25b8071cafbfc30ee3f569f72342dcc” (224 characters, thus 112 bytes); one was supposed to deduce that this was the hexadecimal representation of a ciphertext (encrypted message).
  • a command-line Python script named challenge.py, taking as parameter a file name and encrypting the file with CBC-AES-128 (from Python’s Crypto.Cipher module) using a key generated by a custom PRNG. The script is copied below:

#!/usr/bin/env python

# Copyright (c) 2014 Nagravision SA, all rights reserved

import os
import sys
import hashlib
from Crypto.Cipher import AES

ZEROBLOCK = '\x00'*16

def encrypt(key, iv, plaintext):
    assert len(key) == 16, 'key isnt 16-byte'
    assert len(iv) == 16, 'iv isnt 16-byte'
    assert len(plaintext) % 16 == 0, 'plaintext length isnt multiple of 16'
    cipher = AES.new(key, AES.MODE_CBC, iv)
    return cipher.encrypt(plaintext)

def xor(xs, ys):
    return ''.join(chr(ord(x) ^ ord(y)) for x, y in zip(xs, ys))

class PRNG(object):

    def __init__(self):
        self.state_bytes = 64
        self.key = ZEROBLOCK
        self.iv = ZEROBLOCK
        # get low-entropy string from the environment
        entropy = ''.join(os.listdir('/proc'))
        # hash to make a higher-entropy string
        seed = int(hashlib.sha256(entropy).hexdigest(), 16)
        # ensure distinct processes have distinct seeds
        pid = os.getpid()
        new_seed = self.__diversify(pid) * seed
        # hash again to get a 32-byte string
        final_seed = hashlib.sha256(str(new_seed)).digest()
        # initialize state
        self.state = final_seed + '\x00'*(self.state_bytes - len(final_seed))
        # fill state with pseudorandom bytes
        # + proof-of-work, against bruteforce
        for i in range(10000):

    def __print_state(self):
        print self.state.encode('hex')

    def __diversify(self, x):
        return pow(3, x, 65537) & 0xffff

    def __update(self):
        mask = encrypt(self.key, self.iv, self.state)
        self.state = xor(mask, self.state)

    def get_bytes(self, nbbytes):
        randbytes = self.state[-nbbytes:]
        return randbytes

def main():
    prng = PRNG()
    plaintext = open(sys.argv[1]).read()
    key = prng.get_bytes(16)
    iv = ZEROBLOCK
    ciphertext = encrypt(key, iv, plaintext)
    print ciphertext.encode('hex')

if __name__ == '__main__':

The PRNG is seeded with

  • a snapshot of the content of /proc, which is highly unpredictable on a typical Linux system.
  • the “diversified” PID, which on a Linux system ranges from 1 (init) up to 32768 (see /proc/sys/kernel/pid_max)

These two elements are then multiplied together on the line new_seed = self.__diversify(pid) * seed. Reminder: for all x, we have x×0=0.

In the above PRNG, one can observe a function __diversify(), which doesn’t seem to add entropy, let alone to “diversify” the PID, but rather to deterministically map a PID x to the value (3x mod 65537) mod 65536, since the AND mask 0xffff is equivalent to a reduction modulo 1+0xffff. Now, observe that pow(3, 32768, 65537) equals 65536, which is equivalent to 0 modulo 65536.

Bottom line: there is a PID, namely 32768, for which the key does not depend on the highly unpredictable content of /proc. With this PID, one obtained the key “622c4f56d20f0825e22751e0f29b38f5″. One could then decrypt the ciphertext, and notice that it looked like a gzip’d file stripped of its first bytes (1f 8b 08 08). The rest is left as an exercise :-)

How DNS kills the Internet

There is a huge amount of Internet traffic just for Domain Name System DNS, as the amount of domain names grows it also becomes more complex. Due to the architecture of DNS, more complex means also increased time upon name resolution. This article tries to show why it happens and to give suggestions to improve it. Most of the points have been previously exposed (e.g. Notes on the Domain Name System, RFCs, …). We try to give a clear view of the whole state of DNS and show some statistics of our measurements.

How DNS works

To simplify, this article focuses mainly on domain name to IPv4 address resolution (A records). DNS provides resolution in a hierarchical distributed way. The following image illustrates the domain name resolve mechanism (credits to wikimedia.org).


Basically there are 13 root name servers (there are 13 IP addresses but there are hundreds of root servers distributed all over the world using Anycast addressing). Root servers serve the “.” domain; all domain names end with “.”, and if it is omitted a suffix is added. If it is a public Internet domain name, the suffix will usually be “.”. Root servers don’t have the A record for the requested domain name, except for the TLDs name servers themselves, but they delegate to the Top Level Domain (TLD) name server. Basically they respond I don’t know, but these servers may know (illustrated above by Try The mechanism is the same for the TLD name servers until it reaches the name server that has the answer (completed in 3 queries in the picture).

Continue reading