Dienstag, 4. Juli 2017

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.

The issue: CORS misconfiguration

Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.
Misconfiguation Description
Developer backdoorInsecure developer/debug origins like JSFiddler CodePen are allowed to access the resource
Origin reflectionThe origin is simply echoed in ACAO header, any site is allowed to access the resource
Null misconfigurationAny site is allowed access by forcing the null origin via a sandboxed iframe
Pre-domain wildcardnotdomain.com is allowed access, which can simply be registered by the attacker
Post-domain wildcarddomain.com.evil.com is allowed access, can be simply be set up by the attacker
Subdomains allowedsub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain
Non-SSL sites allowedAn HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption
Invalid CORS headerWrong use of wildcard or multiple origins,not a security problem but should be fixed

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.