11/01/2016
Blog technique
A recap of 32C3
Dimitri Kirchner, Frédéric Guihéry, Kelly Resche
AMOSSYS attended the 32nd edition of the Chaos Communication Congress (CCC), which took place from December 27th to 30th in Hambourg. CCC is now one of the biggest hacker event in the world, amongst security conventions such as Defcon and Black Hat USA. The theme of this year’s edition was [Gated Communities](https://events.ccc.de/2015/11/04/32c3-gated-communities/). The idea behind this topic was to emphasis a global trend in which people are less and less part of the decision. Indeed, in many areas of our life, should it be related to politics, socio-economic or cultural domains, people face ideas, products and technologies that are imposed by these Gated Communities. In order to tackle this unfortunate tendency, the CCC [invited people](https://media.ccc.de/v/32c3-7550-opening_event#video) to hack and build new solutions by themselves. For four days, the congress was asked to be a dedicated Gated Community where anyone can discuss, think and decide freely. In this blog article, we decided to briefly recap some insightful talks we have attended during these four days.
The exhaust emissions scandal ("Dieselgate")
During this talk, Daniel Lange (who previously worked at BMW) first gave a brief overview of what automative industry motivations are today, along with several numbers related to the VW scandal (11 millions of cars affected, etc.). He then presented the NEDC (for New European Driving Cycle) which is currently used to assess the emission levels of car engines.
Daniel also explained that car manufacturers have settled several tricks to obtain better results during these tests. For example:
- they overinflate tires to reduce the rolling resistance,
- they remove mirror on the passenger side and tape all openings of the vehicle to reduce the air resistance,
- etc.
The only goal of these tricks is to have the best results possible. And this is not only for Volkswagen, this concerns every car manufacturers.
In the second part of this talk, Felix Domke explained the work he’s done on reversing the firmware of the Engine Control Unit (ECU) which basically controls everything in your car.
The speaker explained how selective catalytic reduction works: by dosing a liquid called AdBlue, the Selective Catalytic Reduction (SCR) is able to reduce the NOx emission.
When reversing the ECU firmware, Felix found that calculation of the right AdBlue dosage is represented by a model. What he also found is another model’s existence: an alternative model is present in the firmware which deactivates efficiency checks and which calculates a specific AdBlue dosage that produces much smaller exhaust emissions than the normal model… This alternative model is chosen by the ECU when the car is warm enough (20°C) and is following (guess what?) the driving cycles of the NEDC…
As a conclusion, Felix has done an enormous job since september (when the scandal became public) for this talk by reversing and giving concrete proofs of the Volkswagen emissions’ scandal.
The Perl Jam 2
After his 31C3 presentation, Netanel Rubin was back this year to show us more camels and « WAT? » abuses. To begin his presentation, Netanel started with responses and controversies he triggered last year when he showed us serious vulnerabilies in Perl’s CGI and DBI modules.
This year, he started to speak how PERL deals with hashes, and how they are often considered by some developpers as « secure », mainly because theses can’t apparently be created by user input. This means that hashes keys are often passed to dangerous functions without any validation. To illustrate this, he showed how anyone can create a controlled hash using XMLRPC or JSONRPC, trigerring an SQL injection in the project bugzilla as an example.
Netanel then took 3 popular Perl modules/frameworks (CGI.PM, Catalyst, and Mojolicious) and showed that they have different behaviors when dealing with specific inputs. This means that an attacker could also use specific inputs to exploit lazy codes which don’t sanitize user inputs and which uses one of these 3 modules.
To finish his presentation, Netanel finally took an example of the documentation of the CGI.PM module (afterwards, it seems that the example is a bit outdated…). At first sight, the Perl example is just waiting a file from the user and is printing its content.
However… in reality:
- the
upload()function of the CGI module checks if one of the « file » values is an uploaded file. That means that assigning a file and a scalar will return true and enter theif()statement. - the
param()function of the CGI module returns only the first element of the list. This means that the$fileparameter could now be a controlled string instead of a file in a normal case. - the operator
<>does not work with strings, unless the string is « ARGV »… In that case, the<>loops through the argument values in the URL and inserts each one in anopen()call. That means an attacker can now display any file on the server. But to complete his demonstration, Netanel had to execute code on the server… For this, he explained that theopen()method opens a file descriptor to a given file path… unless a|character is added to the end of the string. In that case, open will now execute the file. Combining all these Perl and CGI « features », it is finally possible to execute code on the server.
To conclude his talk, Netanel explained his point of view (which is a bit narrow-minded): « Perl is the problem ». However from his examples, it’s more the CGI module from Perl that has a poor level of security, and this is apparently known by the Perl community. As usual, this 32C3 presentation has made a lot of noise… You can check this page to dig into each controversies.
Shopshifting - The potential for payment system abuse
Karsten Nohl, Fabian Bräunlein and Philipp Maier (aka dexter), from Security Research Labs, presented several security flaws affecting the two main payment protocols in Germany:
- ZVT, used between the cashier station and the payment terminal. The ZVT protocol is spreadly used in Germany (about 80% of payment terminals use it),
- Poseidon, used between the payment terminal and the merchant’s bank. The Poseidon protocol implements the ISO 8583 standard.
The lack of authentication in those protocols allows an attacker to perform Man-in-the-Middle attacks through wireless or Ethernet connections. The researchers identified many others vulnerabilities:
- ZVT supports a feature that enable arbitrary text to be written to the payment terminal’s screen. Received commands are validated thanks to a MAC. However, a timing attack affects the MAC verification. Indeed, the MAC is checked byte per byte so the verification is a little bit longer when the MAC is correct than for a bad MAC.
- Poseidon protocol allows to configure a payment terminal (as another), knowing a terminal ID, a port number and a service password. The identifier is printed on every receipt generated by a terminal. The management service password is, as found by the speakers, a fixed value available online. The port number can just be brute-forced.
Throughout the talk, the speakers demonstrated, in real time using a real bank, a set of attacks exploiting the previous elements to:
- steal customer credentials (card details, PIN),
- hijack local terminal,
- compromise merchant account,
- issue refund transactions.
The speakers informed Germans banks of their results. Contrary to what banks think, the attacks are not just theoretical. Although there is no evidence of exploit by criminals, attacks have been implemented successfully by the researchers.
Neither Snow Nor Rain Nor MITM... The State of Email Security in 2015
Zakir Durumeric presented a talk about the SMTP protocol, its security extensions and how theses can be either useless or rarely adopted. This talk is based on his work in collaboration with many other researchers from the University of Michigan and Google and was presented at the ACM Internet Measurement Conference in October 2015.
SMTP (Simple Mail Transfer Protocol) is the protocol responsible for relaying messages between mail servers. It did not originally authenticate senders or encrypt mail in transit. Instead, servers support these features through SMTP extensions. These features are optional so mail servers still accept unprotected communications if they can’t negotiate a secure connection.
To protect communications through an SSL/TLS tunnel, a server can use the STARTTLS extension by sending a specific message. If the client supports encryption (TLS), it will understand the STARTTLS message and will initiate a TLS exchange before sending the email to ensure it is encrypted. If the client doesn’t know TLS or if the TLS message is incorrect, it will simply ignore the STARTTLS and send the email in clear.
From these considerations, STARTTLS is vulnerable to downgrade attack. An active attacker can strip out the server’s advertisement of STARTTLS support, and a vulnerable client would fall back to using the protocol without TLS.
Durumeric and al. identified that, in seven countries, more than 20% of inbound Gmail messages are downgraded to cleartext by network-based attacks. In the most severe case, 96% of messages sent from Tunisia to Gmail are downgraded to cleartext.
The second class of attacks mentioned by the speaker is DNS MX record hijacking attacks. Malicious DNS servers falsify MX records to reroute messages to servers controlled by attackers. The researchers found that 14.6K publicly accessible DNS servers in 69 countries provide invalid IP addresses or MX records for Gmail’s SMTP server.
After SMTP encryption, Durumeric focused on email authentication. Three ways to authenticate email are:
- DKIM (DomainKeys Identified Mail) where the sender uses public key cryptography to sign the content of emails,
- SPF (Sender Policy Framework) where the sender specifies which IPs are allowed to send emails,
- DMARC (Domain Message Authentication, Reporting and Conformance) where the sender publishes policy in DNS that specifies what to do if DKIM or SPF validation fails (reject, spam folder, etc.).
Such security features are rarely deployed by large providers. Whereas over 90% of Gmail emails are authenticated using either SPF, DKIM or a combination of both, less than 50% of the top million domains have SPF enabled and only 1% have DMARC policy. Reasons explaining why very few people actually use these features are for example, difficulties to handle email signatures for mailing list.
To conclude his talk, Durumeric introduced two recent IETF proposals for helping secure email transport. First, there is SMTP Strict Transport Security, which is equivalent to HTTPS HSTS (mail service providers can declare that they only accept secure connections). Then there is Authenticated Received Chain (ARC), which is the DKIM replacement that handles mailing lists.
Towards (reasonably) trustworthy x86 laptops
Joanna Rutkowska, from Invisible Things Lab, exposed a concept to mitigate some malware behaviours related to sensitive information leakage (such as secret key exfiltration or localization identification).
She addressed these issues firstly by preventing malwares from being able to gain persistant storage access on a laptop. To this extent, she introduced the concept of stateless laptop (i.e. laptops that lacks any persistent storage). With such laptops, a malware could not store any credentials used by the owner and retrieved through a key-logger for instance. Besides, this security mechanism would be resistant against OS-reinstallation or disk changes.
The main idea is that the state of a laptop (the OS, the firmwares, etc.) would be kept on an external trusted device (such as a USB stick or an SD card). In her work, Joanna went through each component of a standard laptop and explained which ones may contain persistant data storage (such as the SPI flash, any embedded controller flash or even the hard drives). She also depicted how to transform or avoid those components in order to comply with the stateless requirement. For instance, regarding the embedded controller flash issue, she suggested to externalize the firmware in a trusted storage. As an example, she refered to the Purism Laptop which implements this approach.
Joanna also addressed issues related to information exfiltration through wireless connections, and to privacy threats that can happen when external environments can characterize the physical location of a user (such as the wireless SSID value). For the former issue, she suggested to implement a physical kill switch (aiming at cutting off the power of any wireless devices), or to rely on a networking proxy implemented on an external and trusted device. For the latter issue (mitigating localization identification), she explained how to reduce the amount of sensitive information that can be retrieved from the physical environment.
This work is only at the state of concept at this time. She explained in more details in a recent paper the design of such a stateless laptop and the different issues that have to be addressed in order to make a proper implementation.
CloudABI: Pure capability-based security for UNIX
Ed Shouten, from the company Nuxi, described a new UNIX security mechanism called CloudABI. The speaker described at first the limitations of current capability-based solutions (the lack of compatibility with legacy libraries and difficulty to scale), as well as Mandatory Access Control (MAC) approaches (complex configuration and maintenance), which are the two usual responses to mitigate vulnerability exploitations.
In CloudABI, access to global resources is controlled by a set of tokens (think of tokens as file descriptors for instance). Those tokens are established at launch time based on a configuration file. Thus, it is possible to tell which pre-defined resources the process is granted access to (such as a listening socket or a file system directory). All other global resources are therefore not accessible.
Thus, if a software running on top of CloudABI happens to have a security flaw, malicious exploitation of it will not permit to access other system resources. Whereas with traditional security measures, an attacker would have access to files and other resources depending on the user permissions.
As its name suggests, CloudABI is a mechanism that provides a dedicated ABI. This ABI aims at being more secure and less complex (currently, only 58 system calls) than the usual Linux Standard Base (LSB) ABI.
Finally, CloudABI intends to be cross-platform friendly. Indeed, thanks to its small ABI, binary compiled for CloudABI should easily run on various compatible systems without recompiling efforts. Current supported systems are FreeBSD/x86_64 and FreeBSD/arm, with beta support of Linux/x86_64 and NetBSD/x86_64.
Figure 6: Graph with potential Use-After-Free
In all cases when a dangling pointer is detected, the last phase of the analysis has to characterize the UAF vulnerability by extracting the subgraph which leads to it. This subgraph has to contain all the elements needed to let a human person manually check in order to avoid true positives.
