Welcome back to our monthly review of some of the most interesting security research publications.
Antonakakis et al. Understanding the Mirai botnet, USENIX Security [paper]
Basically, this paper explains everything you need to know in terms of the evolution of the Mirai botnet: the various attack campaigns (nothing new, but it is well explained), geographical spread, infected devices, bandwidth, etc.
Actually, many findings in this paper are not "new." Indeed, we already published lots of content on Mirai months ago (see below). The value I see in this paper personally is (1) it summarizes the situation quite well and clearly, (2) the study of the botnet's size and bandwidth is very detailed, and (3) the authors explain the tools they used, such as a network telescope, honeypots, DDoS, and DNS logs.To fingerprint infected devices, we use a different technique - from our FortiGuard Labs Telemetry - but fortunately our results concur ;)
The paper highlights some interesting points:
Mirai infected 600,000 devices at its peak.
Compared to other worms like CodeRed, the initial spread was not very high. Side note: like diseases, it is not necessarily the most contagious infections which spread the most.
The infection started in Brazil, Columbia, and Vietnam, whereas CodeRed initially targeted the US.
Our Mirai-related blog posts:
Research: Disassembling Linux/Mirai.B!worm, Dec 8, 2016
IoT-based Linux/Mirai: Frequently Asked Questions, Oct 31 2016
IoT malware are coming. Will you listen to me now?, Oct 24 2016
P. Hulin et al. AutoCTF:Creating Diverse Pwnables via Automated Bug Injection, WOOT, [paper]
In this paper, the authors present an automated system to create challenges for a Capture The Flag session. The motivation is that creating CTF competitions is very time consuming because each challenge is specifically created, researched, implemented, and tested.
The authors use a bug injection system called LAVA to insert vulnerabilities into code, such as integer overflow, stack pointer corruption, etc. To create a CTF challenge, LAVA is provided with a C source program, and then various challenges can be automatically generated based on this source.
Why I think this is more suitable to lab sessions than CTFs
The idea is interesting, but I don't think this is good for CTFs. Several reasons for that, IMHO:
Generated challenges are repetitive. They said they tested this over the course of a week, and had conflicting responses as to whether this repetition was annoying or not. However, they also stated that their participants were not very used to CTFs. As a regular CTF player, I can definetely answer this: for me, this is a strong issue. You may have 2 or 3 similar challenges, but an entire CTF? No way. This would be boring.
This is limited to challenges where the source code is available in C.
This is also inherently limited to challenges where the participants need to exploit vulnerabilities. There are many other types of challenges that need to be included that this tool cannot help, such as steganography.
I would rather apply this idea to the creation of exercises in workshops / lab sessions. In fact, I believe it would be quite valuable in that case.
Smart devices CTF sponsored by Fortinet
This is excellent timing to let you know that we are organizing a smart-devices CTF, Ph0wn, on Nov 29 2017 on the French riviera. As an organizer, I will certainly admit that preparing a CTF is time consuming :( but we also learn a lot doing so. And if you are wondering, none of our challenges will be automatically generated. ;) Even if we had wanted to, I am not sure LAVA/AutoCTF would have easily adapted to the context of IoT, etc.
You are all welcome to attend! Come and challenge yourselves on a variety of smart devices.
S. Kleber et al. Automated PCB reverse engineering, WOOT [paper]
The goal of PCB (Printed Circuit Board) reverse engineering consists in understanding its hardware implementation without having any insider information. It typically involves expensive tools such as microscopes, lasers or other specific equipments such as sand blasting machines or chemicals.
This paper proposes a cheaper and simpler solution, which works based on high resolution pictures taken by a camera of good quality, but that is still affordable. Once those are available, they have implemented a prototype which works on those pictures. For instance, it recognizes characters on the PCB to get the model of a given chip or other information. The pictures are also analyzed to follow the paths between components. Finally, a web search is automatically conducted to find documentation for detected components. Even better, the documentation is automatically parsed to find specific points of interest such as a pin-signal tables map.
Sadly, the implementation is not currently publicly available. The only issue I see to this method is that, to my understanding, it is not able to extract information from multiple layers of a PCB, only from the top and bottom layers, as the other layers are not visible to the camera...
-- the Crypto Girl