Penetration Test Report (VoidSec): VoidSec Ghost

22/01/15 VoidSec Advisory 2015 security@voidsec.com
Ghost Blogging Platform
Web Application Penetration Test
Code Review
Matteo Beccaro ( aka bughardy - bughardy@cryptolab.net )
Performers: Paolo Stagno ( aka voidsec - voidsec@voidsec.com )
Abdel Adim Oisif ( aka smaury - info@shielder.it )
Ghost WAPT & CR VoidSec Advisory 2015 Pag. !1
https://voidsec.com
https://voidsec.com/disclosure-policy
22/01/15 VoidSec Advisory 2015 security@voidsec.com
Index
1. Introduction 3
1.1 Full Disclosure Policy 3
2. Key Findings 4
2.1 XSS 4
2.2 Denial of Service 4
2.3 Privilege Issues 4
2.4 Various 5
3. Vulnerability Details 6
3.1 XSS 6
3.1.1 XSS in blog/user’s images 6
3.1.2 XSS in Tab Manager 7
3.2 Denial of Service 11
3.2.1 Uncontrolled Resources Consumption 11
3.3 Privilege Issues 13
3.3.1 Privilege Reduction 13
3.3.2 Privilege Bypass 15
3.3.3 Privilege Escalation 17
3.4 Various 19
3.4.1 Unsafe token storage 19
3.5 Related 20
4. Appendix 21
4.1 Tools 21
4.2 About the team 22
Ghost WAPT & CR VoidSec Advisory 2015 Pag. !2
https://voidsec.com
https://voidsec.com/disclosure-policy
22/01/15 VoidSec Advisory 2015 security@voidsec.com
1. Introduction
Ghost is becoming a widespread platform for blogging. We saw an increasing number of
users leaving Wordpress and embrace more minimal blogging platforms, which focus on
writing and reading. In this, Ghost is one of the most used software and since it is getting a
lot of attention we started worrying about the security of its users; moreover, I myself
( Matteo Beccaro ) started using Ghost as software for my blog.
The test we made has been performed by the team harming no one.
For the Code Review part we used a local copy of the source code of the application
downloaded from GitHub1.
For the Web Application Penetration Test we used a server of myself in which I installed a
clean version of Ghost at its latest release at the time of writing2.
In the following chapters you will find a description of vulnerabilities found during the test
and for each:
• A table with the estimated severity of the specific vulnerability
• A description of how it can be exploited
• [Optional] The piece of source code faulty for the vulnerability
• Screenshots or Proof of Concept
• Credits to who found the vulnerability
1.1 Full Disclosure Policy
Our full disclosure policy gives the vendor 30 days before the vulnerabilities can be
disclosed publicly or as soon as the vulnerabilities have been fixed.
If the vendor doesn’t reply within a week from our initial attempt of contact we can disclose
the advisory publicly.
The corresponding CVEs of each vulnerability will be request by us, the team, before
sending the advisory to the vendor.
All the information included in this advisory are strictly confidential; sharing it, in any form,
before the 30 days has passed or before the vendor’s releasing the fixes are not allowed.
For the complete policy visit: https://voidsec.com/disclosure-policy/
1 https://github.com/TryGhost/Ghost
2 0.5.8
Ghost WAPT & CR VoidSec Advisory 2015 Pag. !3
https://voidsec.com
https://voidsec.com/disclosure-policy
22/01/15 VoidSec Advisory 2015 security@voidsec.com
2. Key Findings
In this chapter I’ll list all the vulnerabilities found during the test by the team, later I’ll
discuss one by one in details.
2.1 XSS
An XSS allows an attacker to inject code client-side which will be then executed on the
victim machine.
There are two different types of XSS, stored and reflected.
The first type is the most dangerous since the inject code ( ex. Javascript ) is stored on the
web page and will be triggered by all the users.
The second type instead requires the code to be injected by the victim itself, and it is not
stored on the webpage. After the user leave the page the code will be removed.
In Ghost we found three stored XSS which can lead, for example, to session hijacking.
• XSS in blog’s Logo and Cover
• XSS in user’s Avatar and Cover
• XSS in the Tag Manager
2.2 Denial of Service
A DoS vulnerability allows an attacker to create a malfunction in the target server. The
most common problem is when an attacker with more bandwidth than the server try to
overload its network capacity, denying the access to the real users.
In our case instead the vulnerability is within the application, and it can lead to a server
crash.
• DoS, Uncontrolled Resource Consumption in Filesystem.
2.3 Privilege Issues
A privilege issue can lead to several problems, for example a Privilege Escalation is used
to increase the privileges of an user, for example making it an administrator.
In Ghost we found a Privilege Reduction which can lead to a denial of service, and several
Privilege Bypass which I’ll discuss later.
• Privilege Reduction which can lead to a privilege escalation
• Privilege Bypass in reading stored drafts
• Privilege Escalation in publishing posts
Ghost WAPT & CR VoidSec Advisory 2015 Pag. !4
https://voidsec.com
https://voidsec.com/disclosure-policy
22/01/15 VoidSec Advisory 2015 security@voidsec.com
2.4 Various
I’ll list here vulnerabilities which are not included in the previous categories.
We have found that the token used by the software to keep the user authenticated is not
stored safety, which can lead to session hijacking if jointly with a XSS vulnerability.
• Unsafe token storage
Ghost WAPT & CR VoidSec Advisory 2015 Pag. !5
https://voidsec.com
https://voidsec.com/disclosure-policy
22/01/15 VoidSec Advisory 2015 security@voidsec.com
3. Vulnerability Details
3.1 XSS
3.1.1 XSS in blog/user’s images
A stored XSS has been found in blog’s image, in blog’s cover and in user’s avatar and
user’s cover.
This can lead to arbitrary execution of code client-side, like javascript.
To notice that only old browser version are vulnerable. Moreover to exploit it in blog’s
image and blog’s cover the user must be authenticated as administrator or owner, instead
for user’s avatar and cover it could be just an author.
The following tables summarize the severity of the vulnerabilities.
Technical Business
Likelihood LOW LOW LOW
Impact Impact
Base Score Temporal Modificator
Access Remediation
Access Vector Authentication Impact Exploitability Awareness
Complexity Level
6 5 3 4 3 NdA NdA
Envirovment Modificator Overall Score
Collateral
Target Distribution Requirement Final Score
Damage
NdA NdA NdA 4.0
Stored XSS in blog’s images
Technical Business
Likelihood LOW LOW LOW
Impact Impact
Base Score Temporal Modificator
Access Access Remediation
Authentication Impact Exploitability Awareness
Vector Complexity Level
6 5 4 4 4 NdA NdA
Envirovment Modificator Overall Score
Collateral
Target Distribution Requirement Final Score
Damage
NdA NdA NdA 4.5
Stored XSS in users’ images
Ghost WAPT & CR VoidSec Advisory 2015 Pag. !6
https://voidsec.com
https://voidsec.com/disclosure-policy
22/01/15 VoidSec Advisory 2015 security@voidsec.com
The following piece of code shows what can cause the vulnerability(ies) of above.
updateConfigTheme = function () {
config.set({
theme: {
title: (settingsCache.title && settingsCache.title.value) || '',
description: (settingsCache.description && settingsCache.description.value) || '',
logo: (settingsCache.logo && settingsCache.logo.value) || '',
cover: (settingsCache.cover && settingsCache.cover.value) || ''
}
});
};
Credits: Abdel Adim Oisif
3.1.2 XSS in Tab Manager
An other stored XSS has been found in Tag Manager; any users ( author, editor,
administrator or owner ) can create a new post and put, for example, javascript code as
tag for the post. When someone, like the administrator, notices that and proceeds to delete
it, the javascript code is triggered and, for example, the administrator token is stolen and
his session hijacked.
The following table summarize the severity of the vulnerabilitie.
Technical Business
Likelihood LOW MEDIO LOW
Impact Impact
Base Score Temporal Modificator
Access Remediation
Access Vector Authentication Impact Exploitability Awareness
Complexity Level
6 5 4 6 7 NdA NdA
Envirovment Modificator Overall Score
Collater