SSTIC 2012 – Day Three
Source Address Validation Improvements (SAVI)
Speaker: Jean-Michel Combes (Orange)
The third and final day of SSTIC began with a rather technical presentation on possible countermeasures to attacks based on IP address spoofing. Not necessarily easy to digest the day after a social event, but it's always possible to consult the... resources once the headache has passed with a clear head.
The conference opens with a presentation of the most widespread attacks, such as poisoning (ARP, DNS…) or denial of service (TCP flood…). It then describes the various countermeasure proposals published by the IETF, as well as their limitations.
The body of the presentation focuses on the latest standard of this type (SAVI): its mode of operation, its current level of deployment and the limitations of the technique.
In short, the protocol acts as a buffer at the switch level. It determines the legitimate owner of an address based on several elements (MAC address, switch port, etc.) and can establish trusted zones for traffic.
It is notably deployed on a Chinese university network where it operates on one million devices.
It can be noted that the limitations of the protocol go beyond the technical: by allowing the location of IP addresses, it enters into privacy issues, for example.
Malicious use of connection tracking
Speaker: Eric Leblond (OISF)
The presentation starts with a brief reminder about the implementation of connection tracking with netfilter: the conntrack system, which works wonderfully to provide stateful filtering with "simple" protocols (those that pass all their data neatly between two ports; typically HTTP).
Next comes the turn of the less compliant protocols that tend to open connections somewhat arbitrarily (FTP, SIP, etc.). In these cases, netfilter relies on helpers : modules developed separately, which inspect the control channel of the protocols in question to manage the opening of flows.
The question is simple: if these helpers are poorly coded – meaning "if they don't validate the legitimacy of requests on the control channels" – doesn't the firewall become a giant open bar? (spoiler: yes, but it's not the end of the world either)
The problem stems from the methods of controlling the helpers. Beyond implementation flaws, we can find ourselves in situations where the very design of a protocol does not allow not to effectively validate the legitimacy of a request; such as, for example, the DCC of IRC.
It is therefore indeed possible to exploit the helpers to arbitrarily open data streams through a firewall. However, dreams of accessing a 3306 from the internet can be nipped in the bud. On the one hand, the helpers Dangerous ones are disabled by default. On the other hand, it is generally necessary to be on the local network to be able to use them when they are active.
In short, a very interesting topic, worth remembering. And testing it internally, since the speaker has published his tool and a script exists. nmap which allows testing the behavior of helpers FTP.
Influence of best practices on BGP incidents
Speakers: Sarah Nataf (Orange), François Contat (ANSSI), Guillaume Valadon (ANSSI)
As an appetizer, the speakers humorously announced that this year there is ANSSTIC, and… ANSSTIC by Orange:
The presentation begins with a brief introduction to BGP: the prerequisites for implementing it (AS number, IP prefixes, the large pipeline that carries everything between operators) and the operation of the protocol itself (session openings between routers, prefix announcements).
The following section describes potential exploits and best practices for protection. Examples illustrate the lack of default protection for prefix announcements—thus creating the possibility of spoofing them or advertising routing tables containing a virtually unlimited number of prefixes. The case of Pakistan is cited, where, in an attempt to block YouTube within the country, prefixes were advertised that redirected to a "black hole"—prefixes that were propagated to routers beyond its borders, temporarily redirecting global traffic intended for YouTube to Pakistan.
The final section presents the operator's perspective and the measures implemented to monitor networks and respond to incidents.
In conclusion, BGP is a robust protocol, but it relies on trust between operators; therefore, applying best practices is essential to ensure its proper functioning. Incidents are more often caused by unforeseen errors and side effects than by malicious acts.
The morning continues with a series of short presentations.
Netusse, by Clément Lecigne (Google)
The speaker presented a tool developed in his spare time: a socket fuzzer that works simply and effectively. Simple, because it only initializes sockets with valid operations to put them in a state conducive to fuzzing. Effective, because it finds exploitable bugs: the end of the presentation demonstrates the discovery of a bug in the FreeBSD kernel and its exploitation to achieve local privilege escalation… which was unpatched at the time of the conference.
The speaker has published several of his tools on github.
Code verification by static typing, by Etienne Million (EADS Innovation Works)
Description of a static analysis method. The idea is to identify user-controlled pointers accessing kernel memory to detect dangerous constructs.
Website showcasing the tool and related projects.
Blocking botnet C&C channels by intercepting DNS queries, by Ronan Mouchoux (TELECOM Bretagne)
The idea of intercepting DNS queries comes from the observation that antivirus and other usual protections are ineffective in combating the opening of C&C channels on an infected machine when malware uses pseudo-randomly generated domain names.
The project is still under development; the goal is to implement several algorithms for identifying suspicious domain names and to combine them in order to maximize the detection rate.
The morning ends with a conference in English: Successes (and limitations) of (static) binary analysis
Speaker: Halvar Flake (Zynamics)
The speaker begins by summarizing his point: over the past ten years, enormous progress has been made in automated binary analysis and the adoption of this approach has probably helped to correct millions of bugs… but (there is always a «but») there are a number of seemingly simple pieces of code that can contain bugs that are difficult to understand, correct, and are obviously undetectable by automated analysis tools.
The presentation shows the example of a very simple function (no multithreading, no heap allocation, etc.), but one that has too many possible execution paths to be properly analyzed. In a different vein, web browsers are mentioned. They already represent hundreds of thousands of lines of very complex C++ code to analyze… and incorporate a JavaScript interpreter, which allows control over the code's execution path within the browser. This section concludes with a word on manually analyzing binaries: identifying relevant code snippets during an analysis is not always straightforward; delving into a binary is a non-trivial and highly time-consuming task.
Ultimately, the best method remains – unsurprisingly – manual analysis aided by tools. It's also clear that in 2012, we should be able to produce clean, easily analyzeable code. But we're not. I'll leave it to Nicolas Ruff. to summarize the situation in his own way.
Miasm: Reverse engineering framework
Speaker: Fabrice Desclaux (CEA)
The afternoon started off strong, with forty slides presented in under thirty minutes and an average speaking rate of around six words per second. This conference was an experience that no report can truly capture. But we can still say what it was about.
Miasm's goal is to provide an abstraction layer alongside the assembler and offer a generic intermediate language. On the one hand, this avoids having to relearn a multitude of specific features when moving from one architecture to another. On the other hand, it allows algorithms (for example, vulnerability scanning) to be applied directly to this intermediate language.
The framework integrates several features that can further facilitate analysis processes: application of simplification rules to eliminate the first layers of obfuscation, reconstruction of the execution flow, search for code that validates constraints to find sections suitable for ROP, etc.
THE slides ; L'’article. And the’tool in question.
Reverse engineering and debugging a Qualcomm baseband
Speaker: Guillaume Delugre (Sogeti ESEC)
A little background to begin: basebands are the chips integrated into phones that manage communications (GPRS, among others). They are completely separate from the phone's "system" processor. This makes for a difficult environment for reverse engineering: the industry is closed, specifications run to millions of pages, microcode is proprietary… generally speaking, analysis requires knowledge of the environment, while documentation is lacking. However, finding and exploiting vulnerabilities is facilitated by the nature of embedded environments, which do not benefit from standard protection techniques like ASLR.
The exploitation techniques presented show that it is possible to send diagnostic commands to the baseband, which can generally benefit from arbitrary read/write access to the entire memory.
Ultimately, basebands are used to manage a large number of functionalities while security aspects are neglected. However, newer versions of embedded systems are beginning to integrate some anti-exploitation features (canaries, etc.).
Protecting and defending military cyberspace: the national approach
Speaker: Arnaud Coustillière (Army General Staff)
This tenth edition of SSTIC concludes with a presentation of the doctrine followed by the army in the context of defensive cyber warfare.
State-level security needs can be summarized by two key points: the Ministry of Defense employs 295,000 people, and attacks are increasingly targeting individuals before attacking IT infrastructure, as seen with RSA and the Ministry of Finance. Malicious activity originating from users—whether intentional or not—is becoming the primary focus.
The application of the doctrine is transversal to theaters of operations (land, sea, air, space) and concerns a multitude of environments: traditional infrastructures, on-board computing, SCADA systems of combat platforms, surveillance networks, etc.
The operations (surveillance, protection, incident response, etc.) are carried out in collaboration between the Ministry of Defence and the SGDSN.
The major challenge remains raising user awareness, because everyone is a source of risk but also a player in security.
THE slides.
