Dienstag, 13. Juni 2017

New printers vulnerable to old languages

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:

Montag, 30. Januar 2017

Printer Security


Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.

From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.


TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET
Full results are available in the master thesis of Jens Müller and our paper.
Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The highlights of the entire survey will be presented by Jens Müller for the first time at RuhrSec in Bochum.

Mittwoch, 25. Januar 2017

PKCE: What can(not) be protected


This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.
At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation“ attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.
In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.

Donnerstag, 29. September 2016

Hacking PayPal's Express Checkout



Do you know what is happening in the background when you buy something in an online shop using PayPal?

In this post we will tackle the following problems:
  • How can PayPal's API be tested?
  • How does PayPal's Express Checkout work? You can find the detailed report here.
  • How can we debit more money than authorized?

Freitag, 22. Juli 2016

How to Break Microsoft Rights Management Services

In this post, we provide a security analysis of Microsoft Rights Management Services (RMS) and present two working attacks: 
  1. We completely remove the RMS protection of a Word document on which we only have a view-only permission, without having the right to edit it. This shows that in contrast to claims made by Microsoft, Microsoft RMS can only be used to enforce all-or-nothing access. 
  2. We extend this attack to be stealthy in the following sense: We show how to modify the content of an RMS write-protected Word document issued by our victim. The resulting document still claims to be write protected, and that the modified content was generated by the victim
This work is going to be presented at WOOT'16.

Dienstag, 3. Mai 2016

Curious Padding oracle in OpenSSL (CVE-2016-2107)

Today, a new OpenSSL security advisory came out and it patched my recent finding, Padding oracle in AES-NI CBC MAC check (CVE-2016-2107).

In this post, I will give some background on this attack and how I found it. Before reading the whole post, note that this vulnerability is very hard to exploit (even if it is given the high severity score). Also note that it is not a new general padding oracle attack with a new logo. It is just an oracle coming from an invalid check of decrypted message content, specifically introduced in OpenSSL (ok, if you really want to have a name for it, call it UnluckyHMAC ...because our HMAC is sad not to be able to validate bytes :) ).

Mittwoch, 16. März 2016

XML Parser Evaluation


XML Parser Evaluation

For some time now, we've been researching in excruciating detail the prevalence of DTD attacks on different XML parsers.

For a quick recap which attacks are possible, see our DTD Cheat Sheet post.


In this post, we present you the results in a nutshell.
The information presented here is based on this masterthesis which covers the respective results in greater detail.

Test Methodology


We identified 16 test vectors, each testing a specific attack vector (e.g. XXE, various kinds of DoS, XXE parameter entity,...). We ran these tests against the default parser configuration and call these therefore core tests.

Additional tests are based on the same test vectors, however, we executed them against custom (modified) parser configurations, indicating the effect of specific features of a parser.

The complete test set is available on github.

Results

We analyzed the following parsers and summarized the test results in Table 1. In addition, we show which attacks cannot be mitigated indicated by an asterisk.