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!