SSTIC 2017 – Day Three
Links to reports from other days:
- SSTIC 2017 – Day 1
- SSTIC 2017 – Day 2
- SSTIC 2017 – Day 3
PacketWeaver
ANSSI agents Florian Maury and Sébastien Mainand, from the network and protocol security laboratory, presented their tool to us. PacketWeaver which addresses a recurring need in their network-level audit services. Indeed, they are often required, on the solutions they audit, to selectively capture traffic (via MITM) in order to observe and manipulate it before reinjecting it into the network.
This process is easily achievable with ARP spoofing and filtering rules. iptables then scripts Scapy (or other). However, setting up this environment is a repetitive, uninteresting, error-prone, and not very generic task (hard-coded addresses).
They therefore developed a tool that organizes and facilitates these steps and then allows for chaining the processes through blocks linked by pipes communication.
The tool is developed in Python and offers a console interface similar to Metasploit.
Among the features, we were able to observe the ability to launch a scan ping on a network, or to create a DNS server or proxy with the addresses we want. Blocks can have multiple inputs and outputs. For example, it's easy to implement a flow with a TLS server connected to a modification script of our choice and returned via a TLS client.
In the future, the authors plan to provide more scripts, use them for training exercises, and provide equipment test sets.
Video : https://www.sstic.org/2017/presentation/pw/
cpu_rec.py
Louis Granboulan, from Airbus, presented his tool to us. cpu_rec.py. During his work, particularly in auditing, he often has to disassemble programs, and understanding their architecture is essential to correctly interpret the bytes into opcodes and instructions. This isn't always straightforward when dealing with more complex files. ELF, COFF (PE) Or Mach-O, but from raw firmware extracts or memory captures. The tool is currently capable of recognizing 72 architectures, which obviously go beyond the classic Intel or ARM.
In summary, the tool works based on statistics, calculated beforehand on a corpus of programs of a known architecture, to then calculate the similarities with the binary code to be analyzed.
Louis then detailed the strategies that were tested (machine learning, Markov chains with sliding window, etc).
It should be noted that his tool can function independently or as a module for the program binwalk in order to easily apply it to a firmware or disk image.
Article and video: https://www.sstic.org/2017/presentation/cpu_rec/
Machine Learning confronted with the operational constraints of detection systems
Anaël Bonneton and Antoine Husson from ANSSI and INRIA presented the hot topic of Machine Learning applied to computer security and more specifically to intrusion detection.
They observed that current systems are based on expert-constructed signatures, designed to minimize false positives, but which, in turn, struggle to handle variations and are vulnerable to new attacks. The field is therefore searching for new solutions, including... Machine Learning, and more broadly Artificial Intelligence, are part of it. They noted that, in the current state, security experts are skeptical about the quality and ease of understanding of the results while marketing departments announce great promises.
The speakers presented the fundamentals of this area of supervised learning. We start with an input that we want to analyze (in their example, PDF files). First, it must be transformed into a numerical vector (a list of numbers) so that it can be interpreted by a classifier. The classifier will return a score (which we want to reflect the malicious nature of the PDF file), which we will compare to a threshold to make a binary decision (malicious or not). In a detection context, this score can be used to prioritize alerts and fine-tune the threshold between false positives and false negatives.
For the training phase, an expert will determine how to transform the input into a vector of numbers based on specific characteristics (several approaches have been suggested: the number of pages or images, the presence and value of the last modification date, etc.), choose the classifier algorithm, and then construct a labeled dataset (malicious or benign?). The classifier they selected, based on a linear model, can independently identify the discriminating characteristics that positively or negatively influence the final score and to what extent (weight).
To validate the model, the standard approach is to use 90 %s from the labeled dataset to train the algorithm, and to keep 10 %s to test and validate its effectiveness. They also discussed the problems that can arise when the model is overtrained on a specific dataset to the point of being ineffective on others.
Their tool SecuML is generic and allows you to see the coefficients discovered during training for each characteristic, the scores calculated for each on the test files and the false positive and detection scores obtained on the control subset as a function of the threshold retained.
Article and video: https://www.sstic.org/2017/presentation/le_machine_learning_confront_aux_contraintes_oprationnelles_des_systmes_de_dtection/
NIDS: In search of the lost villain
Eric Leblond, from Stamus Networks, gave a presentation about the’IDS Suricata network to which he contributes.
He participated in a cyber defense exercise organized by NATO within the yellow team, responsible for indicating to the red team (the attackers) the level of discretion of their attacks against the blue team (the defenders). He then had the idea of constructing a graph of the attackers' progress within the target information system based on the alerts raised by the IDS. For each alert, he therefore needed to know who the attacker and the target were.
It is naively assumed that the source IP address of an alert corresponds to the attacker, while the destination IP address corresponds to the victim. However, alerts can also originate from an outgoing stream: for example, when a web server returns many HTTP 403 errors, the source IP is that of the server, but the attacker's IP corresponds to the destination IP.
The speaker therefore proposed adding information to the rules to return the correct values for the alerts. Source and the Target allowing the construction of a directed graph of relationships representing the attacker's path from victim to victim.
The author has implemented the necessary modifications in Suricata and Prelude, but it now remains to convert and enrich the many existing detection rules.
Slides, article and video: https://www.sstic.org/2017/presentation/signature_ids_update/
Deploying TLS 1.3: the great, the good and the bad: Improving the encrypted web, one round-trip at a time
Filippo Valsorda from Cloudflare was invited to present the latest version of the encrypted communication protocol TLS 1.3.
He began his presentation by warning that despite the minor version number, TLS 1.3 brought major changes. (big jump) unlike its predecessors TLS 1.0, 1.1 and 1.2. The version number also gave rise to numerous discussions on the working group's mailing list.
The main topic was the number of RTTs (an acronym that has generated many jokes on Twitter) during TLS connection establishment. One RTT corresponds to one Round-Trip Time, This refers to the time it takes for a round trip between the client and the server (i.e., two packets). These round trips, essential for verifying and negotiating the encryption conditions, generate overhead and latency compared to a simple unencrypted connection, and it is therefore desirable to minimize them.
In comparison to TLS 1.2, which required two, the latest version 1.3 only requires one RTT to establish a TLS connection from scratch. Indeed, messages (Hello Client/Server And Finished) which were previously sent successively are now present in the same packets, saving several hundred milliseconds.
He then recalled that most TLS connection establishments are done more succinctly by reusing parameters negotiated in a previous exchange according to the mechanism of Resumption. Instead of 1 RTT, it is now possible to go down to 0 RTT by concatenating the useful content (e.g., HTTP request or response) to the TLS connection establishment messages.
Beyond the impacts on the Forward Secrecy Having taken these issues into account and addressed them, Filipo explained that an attacker would now be able to replay a captured encrypted message without needing to decrypt it, which can have serious consequences (imagine, for example, an HTTP request used to trigger a bank transfer). Client programs are best positioned to know which messages are dangerous in case of replay, that is, those that trigger actions. In HTTP, for example, a GET request is only supposed to retrieve content without modifying it (a so-called GET request). « idempotent« A browser could therefore use the 0-RTT mechanism for these requests; however, this convention is not followed by all applications, so there is a risk. He described Cloudflare's policy on this matter: accepting 0-RTT GET requests only when no parameters are passed (this is just a heuristic; imagine, for example, a GET request for /product/123/delete), this test being combined with detection of the framework used.
Filippo then described in TLS 1.3 what had been removed (RC4, 3DES, MD5, SHA1, AES-CBC, compression, renegotiation… thus negating the notorious attacks that exploited them), reduced (far fewer choices regarding cipher suites and elliptic curves) and added (signature of the entire connection establishment exchange and protection against downgrades malicious).
He then concluded on the current state of deployment, on the client and server side, mentioning the case of some proxies that did not support this protocol well and were blocking connections.
Blog post summarizing the presentation: https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
Video : https://www.sstic.org/2017/presentation/2017_invite_2/
Subscribers remote geolocation and tracking using 4G VoLTE enabled Android phone
Olivier Le Moal, Patrick Ventuzelo, and Thomas Coudray from P1 Security presented the security flaws of the new VoLTE communication protocol deployed by mobile phone operators. This protocol implements the Voice over LTE, Similar to VoIP but built on top of existing operator data protocols, this protocol offers improved sound quality, faster calls, and the ability to make calls via base stations. VoWiFi.
VoLTE reuses existing VoIP protocols: SIP for signage, SDP for negotiating codec parameters and RTP for audio streaming with suitable recent codecs (e.g.: AMR). Thanks to their test infrastructure, consisting of two Android phones rooted Connected to two different operators, they were able to observe (via standard network captures) the exchanged messages and, in particular, compare what was sent on one side and received on the other. Indeed, the operators had added dedicated equipment: SIP servers and proxies, audio gateways, etc.
The speakers notably discovered that in the messages SIP INVITE, It was easy to spoof the caller ID number (caller ID spoofing) without the operator preventing it. Beyond the obvious consequence for the person receiving the call, they raised the possibility of injecting spoofed calls into judicial interception and tracing systems. More anecdotally, the parties involved can exchange messages by injecting their data into SIP headers, without traceability or billing. According to the speakers, manufacturers are aware of this and are working on it.
They also observed that the message «"183 session progress"», returned by the phone called following the message GUEST, disclosed a lot of sensitive information including the IMEI (which indicates the exact version of the phone and therefore facilitates the precise exploitation of vulnerabilities if necessary, for example: Stagefright), as well as the identifier of the cell tower that allows the phone to be located. This information can be obtained free of charge, and silently for the victim, as the call can be interrupted at that moment, before the ringing sound.
Finally, they concluded by explaining that, unlike the classic telecom audits they are used to, exploiting VoLTE vulnerabilities is simplified by the absence of difficult-to-access prerequisites: here there is no need to be physically present in the operator's network or to have specific equipment at one's disposal.
DroneJack
Guillaume Fournier, a student at CentraleSupélec, presented the DroneJack project which he created with another student, aimed at protecting physical areas from drone overflights.
Their solution differs from existing methods (jamming, eagles, etc.) in its selectivity and effectiveness against swarms of drones. It works against Wi-Fi drones by deploying multiple Wi-Fi access points within the protected area to ensure comprehensive coverage and enable triangulation-based location tracking.
Regarding Wi-Fi drones, the developers of DroneJack reuse the tools (continued) Aircrack) and existing techniques on these networks. Drones using protected networks are subject to deauthentication attacks, and those whose network is open are joined by the tool to then carry out attacks on the piloting interface (API) or on the operating system.
The audience nevertheless raised several questions regarding the effectiveness of the device, the ease of evading detection by changing the drone's MAC address (some manufacturers have their own OUI prefixes, making them easily identifiable), and the risk of attacks against legitimate Wi-Fi networks. Finally, the legality of such an attack on drones was also raised but received no concrete answer.
Article and video: https://www.sstic.org/2017/presentation/dronejack/
Reverse engineering of a connected toothbrush
Axelle Apvrille, from Fortinet, investigated a connected toothbrush distributed by an American dental insurance company. Faced with the difficulty of obtaining multiple units, she ruled out a physical attack vector (dismantling her single unit) and instead focused on the iOS and Android applications as well as the connectivity. Bluetooth Low Energy used to communicate with the application on the user's smartphone.
She demonstrated that none of the security mechanisms offered by Bluetooth LE (authentication and encryption) were enabled, making it easy to communicate with the brush and discover which interfaces and services were exposed. By supplementing this information with mobile application analysis, she was able to create a script to query information from the brush (its color, motor rotation speed, etc.) and even interact with it (triggering the motor at the desired speed).
She also noticed that the brush was always using the same MAC address (instead of using the functionality Privacy), and that it emitted continuously even when switched off and could therefore be used to track a person who is moving with it (for example in their suitcase).
On the server side, it discovered several vulnerabilities allowing access to other users' profile pictures or changing their score in mini-games in order to potentially cheat to obtain discounts on the cost of insurance.
In general, she described the complicated exchanges she had with the manufacturer, which appears to be the insurance company, when notifying them of the vulnerabilities (closure of her support account and then her user account).
Article and video: https://www.sstic.org/2017/presentation/ingnierie_inverse_dune_brosse__dents_connecte/
Closing conference: Technical review of the TV5Monde incident
ANSSI intervened through two agents (who wished to remain anonymous) to describe in detail the attack carried out in 2015 against the television channel TV5 Monde.
This presentation was very interesting and packed with content, so we highly recommend watching the original video or reading it. the article written by Le Monde journalist, Martin Untersinger (which had occurred the previous day, See our summary on this topic.).
For a security auditor, the vulnerabilities exploited by the attacker are not surprising:
- filtering defects: at the network input from the Internet, via interconnections with providers and stream distributors, and internally («flat network»); ;
- trivial or default passwords; ;
- presence of passwords in an internal wiki.
Overall, the ANSSI auditors noted that the level of security was low, but within the average range of their experience.
It is interesting to note that TV5 Monde used several IT service providers: the attacker exploited the VPN access of one of them to gain access to the internal network, then used the credentials of another to become the administrator of the Windows domain. The speaker therefore highlighted the risks associated with outsourcing the administration of information systems, particularly regarding the loss of knowledge and the difficulty of responding to incidents. Indeed, once the incident response was initiated, it was, for example, difficult for them to obtain an accurate and up-to-date map of the network and systems.
After presenting the initial actions taken to stop the attack, the speakers described the remediation steps. These steps included several phases of comprehensive audits of the existing infrastructure (particularly the network architecture and the domain). Active Directory) then hot reconstruction of the domain (via scripts developed specifically to control replication, all interspersed with pauses to allow the production of television news broadcasts without risk).
In order to create an environment Active Directory targeted, they drew inspiration from the silo administration recommendations presented in first day (establishment of a delegation model with three zones with different levels of criticality):
- red for domain controllers, virtualization servers (ESX), accounts and administrative workstations, in order to build an impregnable, healthy core; ;
- yellow for business servers and service accounts; ;
- green for simple users, workstations, printers, etc.
Video : https://www.sstic.org/2017/presentation/2017_cloture/
— Clément Notin
