29/01/2015
Blog technique
A tale of 31C3 – Part 2
Dimitri Kirchner, Frédéric Guihéry, Georges Bossert, Kelly Resche, Marion Vogt
This is the second part of a serie of two articles about the 31C3 conference. This part summers up talks about bugs’ mining, code pointer integrity, ICS pwning, or Perl / SS7 / XRayScanner vulnerabilities.
Software analysis and hardening
Mining for Bugs with Graph Database Queries
Five years after its last presentation, Fabian Yamaguchi (Fabs) of the University of Göttingen was back on stage of the second day of this CCC edition. His talk entitled « Mining for bugs with Graph Database Queries » is a presentation of its new tool called Joern which mixes static program analysis and graph databases approach for a less painful bug hunting process.
To illustrate his work, Fabs explained that Stephen Esser found his bug in libssl2 using a simple regex expression ALLOC['A-Z0-9_]*s*([^,]*,[^;]*[*+-][^>][^;]*)s*;. This regex matches memory allocations that embeds any arithmetic operation. Such pattern is often a hint for bugs. Based on this observation, Fabs explained that if correctly used, even primitive tools like grep are powerful and that high false positive rates are often tolerated in practice.
Based on this, he proposed a search engine for source code that can be used to find bugs. Overall, his tool takes source code that is analyzed with a robust parsed and then indexed into a database. The analyst is then able to query the database to find interesting patterns.
His parser creates three different representations of the source code:
- Abstract Syntax Tree (AST) that gives a decomposition of the code into all of its language elements
- Control Flow Graph (CFG) that shows the various valid paths that are accepted between the program statements
- Program Dependence Graph (PDG) that models the dataflow and so the impact of each variables on each statement
However, his contribution is to mix these different representations under a unique graph called a Code Property Graph. This graph is then indexed into a noSQL graph database (Neo4J). He can latter search for vulnerabilities by means of search queries that can be submitted to the database. To achieve this, he proposed a query language that relies on the Gremlin Query Language.
Fabs then illustrated the use of its framework on the VLC (version 2.1.5) source code. Applied to it, his parser generates Code Property Graph made of about 2 million nodes and 4 million edges that takes 705Mb on its laptop. Given this database, the expert can then search for some language patterns. For example, to retrieve the name of all the functions declared in demux files, the following query can be used:
queryNodeIndex("type:File AND filepath:*demux*").out().filter {
it.type == "Function"
}.name
Such query can also be used to find potential vulnerabilities in sources. For example, a query can be used to get all the calls to malloc where the first argument contains an additive expression which is different to the additive expression declared in the third parameter of a memcpy function that applies latter on the same buffer.
getCallsTo("malloc").ithArgument("0").sideEffect{
cnt == it.code
}.match {
it.type == "AdditiveExpression"
}.statements().out("REACHES").match {
it.type == "CallExpression" && it.code.startswith("memcpy")
}.ithArguments("2").filter{
it.code != cnt
}
Applied to the source code of VLC, this query returned 4 hits and one of it allowed him to identify an Integer Overflow leading to a Heap-based overflow in the VLC Automatic Updater process. He then demonstrated how he can exploit this vulnerability to remotely control the EIP of its target.
He then provided another example query that can be use to identify buffer overflows in write handlers. He successfully applied his technique to identify various vulnerabilities in the Linux kernel source code. Those vulnerabilities are diverse:
- buffer overflows
- zero-byte allocation
- memory mapping bugs
- memory disclosure A total of 18 vulnerabilities was acknowledged/fixed by the Linux Kernel developers.
Code Pointer Integrity
In this talk, Mathias Payer presented two techniques called Code Pointer Integrity and Code Pointer Separation whose goal is to enforce memory safety of a program. Memory safety can be assured by calculating lower and upper bounds of every assignment in a program code, in order to identify potential bugs such as buffer overflow and dangling pointers. Implementing memory safety leads however to a huge overhead on performance. This is why researchers decided to apply memory safety regarding code pointers only. All non-code-pointer data are therefore left untouched in the memory layout, and a different safe memory layout is created to contain code pointers where memory safety proprieties are applied. In order to distinguish between normal and safe memory, instructions are identified using a type-based static analysis. Memory separation is then enforced using hardware instruction-level isolation.
Results of CPI and CPS implementations are quiet promising: CPS guarantees a strong security protection with an overhead of only 0.5-1.9 percents, and CPI guarantees a precise (strong++) security protection with an overhead of 8.4-10.5 percents. In order to use CPI and CPS, researchers are distributing specific versions of Clang, LLVM and Compiler-RT. They have this way recompiled an entire FreeBSD distribution and hundreds of applications such as Python, OpenSSL, or Apache. Researchers claimed that they prevent all types of attacks from RIPE (a scientific way of testing the coverage of a defense mechanism against buffer overflow). The prototype implementation called SafeStack is available online. Video of the talk can be accessed here.
Industrial Control Systems
Several talks have been presented in the field of Industrial Control Systems at the 31C3.
In a first presentation, Sergey Gordeychik and Aleksandr Timorin, two members of SCADA Strangelove, talked about Industrial Control Systems (ICS) related to Green Energy. SCADA Strangelove is an independent group of information security researchers founded in 2012 and focused on security assessment of commercial Industrial control systems.
They showed that a lot of ICS are connected to the internet and prone to many vulnerabilities and 0-days.
Then in another talk, Eireann Leverett presented his work on compromising industrial Ethernet switches. He focused his presentation on attacks towards management plane as a vector to compromise the switch and especially the data it carries. His point of view is that it is the Industrial Control Systems process which needs to be protected, not accounts or data confidentiality. Three types of switches have been compromised this way: Siemens Scalance X Family Version 4.3, GE Multilin ML Family Version 4.2 and Garrettcom Magnum Family 6K.
Concerning Siemens switches, he showed that it’s possible to bypass the authentication to download log files and even to upload a new firmware (he released a script to exploit this). Vendor has finally patched these vulnerabilities.
Concerning GE Multilin switches, he founded several reflected XSS, a DoS vulnerability and hard-coded keys in the firmware. The same hard-coded keys can be found in Garettcom switches, since they are the same OEM (Original Equipment Manufacturer) as GE Multilin switches. These vulnerabilities aren’t patched by the vendors because the products are not supported anymore.
As a conclusion, Eireann showed that remote attacker can:
- modify switch configuration to ex-filtrate process data;
- run DoS attacks;
- disrupt, alter, or drop process traffic when being in a MITM position;
Finally, he concluded that compromising a switch gives a better overall view of the process.
Miscellaneous
The Perl Jam: Exploiting a 20 Year-old Vulnerability
This talk presented by Netanel Rubin started with a « Fuck Perl » introduction that roughly stated:
- Perl coding style sucks,
- Perl OOP sucks,
- Perl data types sucks.
To illustrate these statements, he reminded the audience on Perl’s datatype (scalars, arrays, hashes…) before focusing on lists (not a datatype in Perl, solely an expression). Indeed, conversely to more common languages, Netanel illustrated some differences between an hypothetical expected behavior and reality, when dealing with some simple usages of lists. For instance, casting an array into a scalar returns the array length while storing an array into a scalar returns its last element:
@list = (1, 2, 'a', 'b', 'c');
print scalar @list
5
$sclr = (1, 2, 'a', 'b', 'c');
print $clr
c
He also reminded that Perl transform an array into a hash even if there is an even number of element in the dictionary:
%hash = (1, 2, 'a', 'b', 'c');
$hash{'a'}
b
The author then described the CGI module which is since 15 years a key element in web applications. He applied his « discovery » on Perl’s list and showed an example to illustrate multiple values provided in an URL which trigger the CGI module to return a list instead of the value of the first parameter. Example:
if the requested URL is index.cgi?foo=1&bar=a, $cgi->param('foo') returns 1 whereas if the URL is 1=index.cgi?foo=1&foo=2, it returns ('1, 2').
He then showed that the OWASP expected behavior declared for PERL CGI is to return the first occurrence only which is wrong in such case. He relied on this observation to perform some HTTP parameter pollution attacks. To achieve this, he stored a list as a value of a hash. And because Perl automatically expands a list into a hash, storing a list into the value of a dictionary creates new keys in it (known since 2006). For Example:
@list = ('f', 'lol', 'wat')
$hash = {'a' => 'b',
'c' => 'd',
'e' => @list};
print $hash
{'a' => 'b',
'c' => 'd',
'e' => 'f',
'lol' => 'wat'}
He then applied this Perl’s feature to find vulnerabilities in several Perl modules such as BugZilla. In this tool, the creation of a user is made with the following snipper:
my $otheruser = Bugzilla::User->create({ login_name => $login_name,
realname => $cgi->param('realname'),
cryptpassword => $password});
This snippet can be exploited by sending multiple real name in the HTTP POST request such as:
1=a=confirm_new_account&t=[TOKEN]&passwd1=Password1!&passwd2=Password1!&realname=Lolzor&realname=login_name&realname=admin@bugzilla.org
the previous snippet can be seen as:
my $otheruser = Bugzilla::User->create({ login_name => $login_name,
realname => 'Lolzor',
login_name => 'admin@buzilla.com'
cryptpassword => $password});
which finally leads to a user verification bypass since some privileges are based on the email address.
Another example of Perl misleading behavior was also illustrated. In this case, Netanel showed how Perl automatically expands a list when provided as a function argument. For example,
sub test {
($a, $b, $c) = @_;
print ($a, $b, $c);
}
@list = ('b','c')
test('a', @list)}}
returns {{Verb|'a', 'b', 'c'}} instead {{Verb|['b', 'c']
More confusing, when forced with a third argument such as in the case
@list = ('b', 'c')
test('a', @list, 'd')
Perl still expands the list and overwrites the specified third argument to return 'a', 'b', 'c' instead of 'a', ['b', 'c'], 'd'.
He then exploited this Perl feature to find vulnerabilities in the DBI module. This core module is the most common way to communicate with databases in Perl. This modules exposes a function ‘quote’ that can be used to filter/escape against SQL injections. For Example:
print 'select * from users where username = '.$dbh->quote($cgi->param('user'));
with the following URL: 1=index.cgi?user=user' it generated the following SQL statement: 1="select * from users where username = user'"
Thus, if we send the following request: 1=index.cgi?user=user'&user=2, it generates the following vulnerable SQL statement: 1=select * from users where username = user'.
It happens, because the quote function accepts a third argument to specify a type parameter constant. So by sending a third argument which value is 2, it means that the previous argument should be considered as an Integer.
He concluded his talk by listing several vulnerabilities he found such as Remote Code Execution or Arbitrary File Upload in various Perl projects using his findings.
SS7 vulnerabilities
SS7 is a protocol suite which was designed in the 1980s, and which is widely used by network operators to exchange information about customers. In total, three different talks about SS7 security were presented at 31C3 congress. These talks however, didn’t make any breakthrough regarding SS7 security. Indeed, research from August 2014 presented quite the same results. It is however, interesting to widely spread the information that an attacker can track your every movement and can intercept your calls and SMS thanks to SS7 vulnerabilities. All the attacker needs to have is your phone number and an access to the operator SS7 network.
Tobias Engel explained that getting access to an SS7 network can be obtained in different ways. The easiest one is to bought it for hundreds of euros a month. But an attacker who doesn’t want to pay can also gain access to the network with some time, since some network operators leave apparently their equipment unsecured and accessible from the Internet. Finally, other ways to access the network can be through FemToCells, LTE or WiMAX networks. Speakers however didn’t give any details on these specific techniques. Still, people talking about SS7 security don’t seem to think getting access is a big issue…
So, what’s wrong with SS7? Well, the deal is that SS7 networks lack any kind of security verifications. Two main components are therefore abused in SS7 attacks. These are the HLR (for Home Location Register) which is a central database containing information on subscribers (phone number, authorization to call, authorization to send SMS, etc.); and the MSC (for Mobile service Switching Center) which are temporary databases containing a copy of HLR data. Both communicates with each other in order to exchange information about users, but neither is authenticating the other hand. Therefore, it is possible to send special requests to abuse them. In order to illustrate these results, Tobias demonstrated how he was able to track a friend geolocation for almost 2 weeks. Details of the different attacks can be watch in his talk.
In a different presentation, Karsten Nohl of SR Labs explained how users can defend themselves against such attacks. The suggested solution is a brand new Android application, named SnoopSnitch. Its principle is to use users’ phones to understand if the network is actually abused. The goal of the application is to complete a GSM Security Map publicly accessible here, which let users compare protection capabilities of their mobile networks.
In conclusion, SS7 researchers explained that network operators have begun to understand the need to secure SS7 architecture. It is however a difficult task since the SS7 design principles have not been thinking with security in mind. For that reason, we may hear of SS7 vulnerabilities for some time…
Security Analysis of a Full-Body X-Ray Scanner
This talk presented by Eric Wustrow and Hovav Shacham discussed about security of a full-body x-ray scanner. They were able to do this research when they managed to buy such a scanner (the one adopted by airports) on eBay for about 50,000$… The goal of this research was to make an independent evaluation of this type of body scanners by:
- validating if their radiations can have implications on people’s health,
- understanding if privacy of the constructed naked images can become an issue.
From a disclosure point of view, researchers insisted on the fact that the model of scanners they evaluated is no longer deployed in US airports.
First type of attacks they presented concerned the quality of scanner’s images. They showed as an example, that this type of scanners cannot detect firearms or knives which are held by the side of a person. More precisely, if someone is standing in front of the scanner, and is holding a weapon on his side (for example attach to its leg), the weapon will mixed up with the background, so that it will be hide in the reconstructed image. With a similar approach, they also dissimulated a small charge of plastic explosive on their belly, using the detonator to reproduce the belly button. The results of these attacks are surprisingly good: you cannot differentiate between a man hiding a weapon or plastic from a ordinary guy…
Other types of attacks they presented consisted on privacy and people’s health issues. Concerning the privacy issues, they showed that it is possible to reconstruct an image of the scanned body by standing outside of the scanner, using a small image sensor. However, the reconstructed image is in that case very blur, far away from the quality of the XRay scanner.
Finally, their results concerning implications on people’s health were surprisingly positive: researchers neither found any issue concerning abnormal radiation doses nor found a way to send more radiations than expected.
Video of the talk can be accessed here. Original paper and images can be observed here.
Forging the USB armory
Andrea Barisani presented a project developed by his company (Inverse Path): the USB Armory which is basically a computer squeezed into a USB stick. It’s open source (Github repository can be accessed here) and designed for personal security applications. It includes:
- mass storage device with advanced features such as automatic encryption, virus scanning, host authentication and data self-destruct;
- OpenSSH client and agent for untrusted hosts (kiosk);
- router for end-to-end VPN tunneling, Tor;
- password manager with integrated web server;
- electronic wallet (e.g. pocket Bitcoin wallet);
- authentication token;
- portable penetration testing platform;
- low level USB security testing.
In order to support these applications, the design goals were to have a compact USB powered device with fast CPU and generous RAM, secure boot, standard connectivity over USB, familiar developing/execution environment and open design.
The final device software and hardware features are:
- Freescale i.MX53 ARM® Cortex™-A8 800Mhz, 512MB DDR3 RAM;
- USB host powered (<500 mA) device with compact form factor (65 x 19 x 6 mm);
- ARM® TrustZone®, secure boot + storage + RAM;
- microSD card slot;
- 5-pin breakout header with GPIOs and UART;
- customizable LED, including secure mode detection;
- excellent native support (Android, Debian, Ubuntu, FreeBSD);
- USB device emulation (CDC Ethernet, mass storage, HID, etc.);
- Open Hardware & Software.
It can work in device mode (as a USB stick) or in stand-alone mode to independently use a keyboard, USB display, USB mass storage devices, USB WiFi dongle and more.
