32C3 Recap – Part1

Every year a group of us are happy to use the holidays to travel to Hamburg to meet other people and learn something new at the 32C3.

In this small series we’ll present you recaps of some talks we found most interesting, but you also should make sure to watch the recording of them. 😉

Beyond your cable modem – How to not do DOCSIS networks

by Alexander Graf
Video

Alexander Graf presents (insecurity) insights on how cable modems work and connect to the ISP.

It started when Alexander moved to a new apartment and had to use a cable modem from that time on. As his modem just had an analogous output for his digital phone, he wanted to take a closer look if he would be able to connect his phone digitally instead of buying an A/D converter. Alexander then found four services, which run on a cable modem following the DOCSIS standard and are broken security-wise.

So when one plugs in his cable modem the first time, it will provision itself with the provider, by downloading a configuration file, named after the devices MAC-address. This is transfered over an unencrypted, unauthenticated TFTP connection. It happens, that you can download any provisioning file for any device (namely customer), when you know it’s MAC-address. The problem is that this provisioning file also holds the passwords for all the other services, which were partially identical for all devices.
One can also talk to the modem via SNMP (authenticated with the password from the provisioning file). When asking for all information the modem has, besides his own MAC-address and model, it also presents the MAC-address and internal IP-address of any connected device.
It seems that SNMP is not powerful enough (at least according to the standard), so there should be a administrative shell on the modem, which in 2015 is of course run with telnet, where you get a root-shell after logging in. Did I mention, that the credentials are in the configuration file and that they were the same for everyone?
Coming to the protocol Alexander was after at the beginning: SIP, which is used for VoIP. Here the modem has to authenticate itself with the server for phone calls, where again the credentials are in the configuration file. This time, though, each customer has it’s own. But still, as an attacker would easily be able to download any provisioning file, it would be easy-game to perform a man-in-the-middle-attack or at least tap on the phone calls.

After reaching out to his provider Kabel Deutschland, via heise security, they mitigated some of the issues, though they still have to follow the standard, as Alexander stated. Eventually telnet was replaced with SSH and an additional authentication is used for the TFTP connection, to ensure devices can only download their own configuration files. Also both the SNMP and SSH connections are now firewalled, so that modems cannot talk to each other with this protocols. Of course the passwords were changed. While this surely helps, I think the question remains, whether this is sufficient or not. Also Alexander assumes, that other ISPs (in other countries) have a similar bad protection.

Altogether the talk is really enjoyable and I would recommend to watch it. (It’s just ~30 mins + ~20 mins Q&A)

– Benjamin

The Perl Jam 2 – The Camel Strikes Back

by Netanel Rubin
Video

After Netanel Rubin’s quite polarizing talk “The Perl Jam: Exploiting a 20 Year-old Vulnerability” showed various serious web application vulnerabilities resulting from Perl’s CGI and DBI modules unconventional behaviour at 2014’s 31C3, the reaction from the Perl community was rather agitated. This was reason enough for Netanel to return to the CCC with a second edition of the Perl Jam with the fitting subtitle “The Camel Strikes Back”.
He starts his talk with a simple example for Perl’s peculiarities. It is the fact that function declarations cannot specify argument data types, thus it is not possible to restrict arguments to one type, such as strings. It is expected to write two different blocks of code in every function to handle scalar as well as non-scalar data types, even if the function should basically only receive one specific data type. This in itself is no problem at first, but combined with the distinction between non-secure and secure (hashes and arrays) data types, of which latter supposedly cannot be created by user input and are used unescaped (even in taint mode), exploitable functions can arise. Just as last time, Bugzilla is again used to demonstrate the vulnerable Perl code. The whole security concept is based on the assumption that users cannot generate hashes or arrays, as only CGI input is expected, and so these “secure” data types are used without additional security checks to access a database. But Bugzilla also features XMLRPC and JSONRPC, of which both are supporting input of non-scalar data types, which are treated as secure and thus allowing the exploitation of the vulnerable code resulting in an SQL injection!
In this scenario RPC was used to create the hashes, but what about regular user input to create non-scalar data types? In the further course of the presentation Netanel shows how different user input behaves in combination with different Perl CGI modules. The results range from multi-value scalar inputs creating an array of scalars to multi-file uploads generating a list of hashes, thus undermining the basic security concept that user input cannot create secure data types. Such or similar behaviour is true for CGI.pm, but also for basically any other CGI module, including (but not limited to) Mojolicious, Catalyst and PSGI, and thus affecting almost every Perl-based CGI application.
The highlight of the presentation is a simple code example to get a file and print it, or in other words a user uploads a file and the server is returning its content. These five lines can be exploited to perform a remote code execution on the target system by “exploiting” language-specific behaviour of Perl, and to complete this farce Netanel reveals that the code is an official example from the Perl CGI.pm documentation.
While Netanel’s final conclusion appears quite harsh (“Perl is Dead” and “Stop Using Perl”) at first, he further elaborates on his points during the Q&A. Perl and its modules make it very hard for any developer to write secure web application code, due to several quirks and undocumented behaviour. In addition, various (better) alternatives exist, which allow for better and more secure web applications with substantially less effort. Nevertheless, it should be kept in mind that this is the status quo and may very well change with the newly released Perl 6

– Heinrich

Key-Logger, Video, Mouse

by Yaniv Balmas
Video

This talk was held by Yaniv Balmas (@ynvb) on the first day at the 32c3. He spoke about KVMs (Keyboard-Video-Mouse) and the (in-)security of current used ones.

KVMs are used to provide a single human-machine interface (screen, keyboard and mouse) to multiple systems. After he presented the development of KVMs (beginning with dump ones, which just redirect the electric signals, to the current ones with hundreds of ports and management interfaces), he told that he decided to buy a modern, multiport KVM to look into. As this newer devices have their own logic for the management interfaces, he and Lior Oppenheim (@oppenheim1) decided to look into one system to see what (from a security point of view) could be done with it. As they had got a CD with an actual firmware image with their system, they started to analyze the image to look for vulnerabilities.
One third of his talk was therefore about the process to get some opcodes to look at (trying to get the raw binary used by the processor). He described pretty good how they decoded the firmware image (and the steps needed to were able to), how they detected the used architecture and how they failed in some of the tries. After they understood how to make their own firmware image, they developed a malicious image to show what an attacker could do if he had small amount of time with direct access to the device. Yaniv showed that the device could easily log the keystrokes entered (as it have to repeat it on the target device). As this is obvious and to show what could be even worse, he presented a demo how a malicious KVM could be used to infect air gapped networks, if it is connected with another, infected network. This could be done by simulating (a previous learned) password to login into a workstation to automatically download a malicious program. This program could send itself to the KVM by emulating keystrokes to type itself into the KVM. The KVM could then enter commands in the air gapped network to replicate the virus and execute it. This channel could then also be used to communicate with the internet. In my opinion this represents an interesting approach, as no one would really think of viruses injected by a (virtual) keyboard. The problem with this infection approach is, that a user will give all the credentials the virus need at some time and even if you replace the machines to remove the virus, it will be reinfected until you remove the KVM. The talk was presented in a very amusing manner and is a good example what steps are needed until you could analyze a firmware, even if it is provided by the vendor.

The research which was presented is only based on replacing the original firmware of one device with a malicious one. But I think that many of the KVMs could also be infected by emulating keystrokes to the device (if possible) as most of them are written in C/C++ and try to parse human entered keystrokes.

– Timo

Shopshifting

by Karsten Nohl, Fabian Bräunlein & Philip Maier
Video

This year Karsten Nohl and his colleges Fabian Bräunlein and Philip Maier from SRLabs did some research on Payment terminals and the payment protocols they are using.
They started with a quick explanation of the two payment protocols that are involved and continued with the first hack to get to the information of the card inserted and in a second step to get to the PIN as well. For that they used just functionalities of the protocol and the fact that there is no authentication between the cashier’s terminal and the payment terminal.
To get the magstripe and chip details of a card they used an already given functionality of the protocol between the cashier desk and the terminal. The same workes for the PIN with the difference that they used a functionality to send some text that will be displayed on the terminal and waits for input. The trick is that the message could be for example “please enter PIN”, although the message needs to be signed with a Message Authentication Code (MAC) before the terminal accepts it. In this case Fabian Bräunlein showed how they got the MAC through a timing side channel attack out of the hardware security module (HSM). Then Fabian Bräunlein demonstrated the hack live on stage with a payment terminal they got from eBay.
Another demonstrated attack was to hijacking a victims terminal. In this case an attacker could set his own terminal ID and force the terminal to reconfigure. This means that the victims terminal now react as a terminal of the attack and the transaction go to the attacks account. Then he should needs to swap banner and merchant info back to the victim ones so the customer and merchant don’t see any different on the receipt. But for that purpose an attacker needs its own merchant account.
The last demonstration was an attack which exploited (a problem of) the authentication with the backend and even works from remote. For that the attacker only needs a payment terminal from the same payment processor as his victim. Fabian Bräunlein explained how it works. The terminal sends an initialization request with his Terminal ID to the backend and gets its configuration encrypted send back. But the system uses a symmetric encryption and the key is stored in the HSM of the terminal and of all other terminals of that payment processor. This means that all terminals from the same payment processor use the same key for encryption. This leaves the Terminal ID (or you could also say username) as the only authentication factor, which is public since it is printed on any receipt.
For the hack itself the attacker needs only three parameters:

• The service management password which is the same on all terminals of one payment processor as well and could be found on the internet.
• The Terminal ID which can be found on a receipt or just by guessing.
• The correct TCP port of the backend which can be found via a brutforce attack.

With that one can impersonate a payment terminal with the Terminal ID of the victim and an attacker can do all the payment functionality the original terminal could do as well. As an example they demonstrated the prepaid functionality and printed a prepaid top up for O2. Not only that, but they demonstrated a feature called refund, which essentially is a simple transaction but with a negative value and can initiated to any bank account the attacker wants.
In the last part Philip Maier explained how they even defeated the supposedly-secure HSM which contains the password. After that Karsten Nohl closes with suggestion on improving the security and especially that using one shared secret in many terminals is not a good idea.
For more details look at the slides or even better watch the recording of the talk to see all of the live demonstration.

– Rafael

Lifting the Fog on Red Star OS

by Florian Grunow & Niklaus Schiess
Video

Though you sure already saw the blogpost and the talk, I’d like to mention it here for completeness. Also we are a bit proud that ‘Der Spiegel’ published an article about Florian’s and Niklaus’ talk. 🙂

Getting back to the post’s intro – learning something new is also possible at TROOPERS.

Stay tuned for the next part!