bugtraq - Google Analytics by Yoast stored XSS #2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAOm4KJVg9jghm9qomv72w3LNiB_mgDv8rf=cUnSZLj-RkN+HGg@mail.gmail.com>
Date: Tue, 21 Apr 2015 15:59:11 +0300
From: Jouko Pynnonen <jouko@....fi>
To: bugtraq@...urityfocus.com
Subject: Google Analytics by Yoast stored XSS #2

OVERVIEW
==========

Google Analytics by Yoast is one of the most popular WordPress
plug-ins with over 7 million downloads and "1+ million" active
installs. Last month Yoast patched a stored XSS we reported in the
plug-in. Shortly after this we identified another bug of a similar
severity. The second stored XSS has now been corrected.

An unauthenticated attacker can store JavaScript in the WordPress
administrator’s Dashboard on the target system. The script will be
triggered when an administrator views the Analytics panel next time.
No other user interaction is required.

Under default configuration the injected script can execute arbitrary
code on the web server via the plugin or theme editors.

Alternatively the attacker could change the administrator’s password,
create new administrator accounts, and do whatever else the currently
logged-in administrator can do on the target system.

DETAILS
========

Exploiting the bug is easier to carry out and automate than in the
first case. The most simple exploit is to view a page on the target
system so many times that it ends up in the "Popular pages" section of
the Analytics panel. Any HTML tags appended in the page URL will be
embedded without escaping.

If the site is low-traffic or hasn't got much content, a single page
load may suffice. On heavy-traffic sites the attacker would have to
use a tool, script, or other method to generate a lot of page views.

It's possible to generate fake page views for Google Analytics. This
happens by communicating directly to the Analytics server; no genuine
page views or a real web browser would be required to plant the
malicious script.

While the previous vulnerability could be used to inject JavaScript in
the plugin's Settings panel (requiring two clicks from the WordPress
main Dashboard view), this one is triggered in the main Analytics
panel. Selecting the Analytics view in the Dashboard would suffice to
execute the attacker's code (one click from the WordPress main
Dashboard).

The plug-in doesn't aggregate Google Analytics data more frequently
than once per day so the attacker may have to wait some time for the
injected code to get triggered.

PROOF OF CONCEPT
==================

While not logged on, navigate to an URL like:

    http://YOUR.BLOG/?html=<script>alert('hello')</script>

Log on and view the Analytics panel in the Dashboard. If you already
had visited the Dashboard recently, you may have to wait for the next
data aggregation.

SOLUTION
=========

The vendor was notified on March 22, 2015. A new version of the
plug-in (5.4) was released on April 20. The update can be installed
via the WordPress Dashboard.

CREDITS
========

The vulnerability was discovered by Jouko Pynnönen of Klikki Oy while
investigating websites in the scope of Facebook’s bug bounty program.

A Facebook acquisition listed on their bug bounty info page was
affected by both of the stored XSS vulnerabilities in this plugin.
While Facebook agreed on the technical severity of the bugs (stored
XSS which "potentially allowed an attacker to achieve RCE"), no bounty
was issued.

In the three published remote code execution bug cases I could find
(which include indirect or "potential" RCE's) Facebook issued rewards
ranging from $15,000 to $33,500.

The rationale for denying bounties this time was that the
vulnerabilities affected WordPress instead of Facebook-specific
software and no "user data" or Facebook-owned infrastructure was
involved.

Facebook has previously qualified WordPress bugs (e.g. WPML) and bugs
that don't involve "user data" (e.g. aconnectedlife.info) nor
Facebook-owned infrastructure (Oculus, aconnectedlife.info, Onavo DNS
misconfiguration, etc).

It was therefore surprising that after taking appropriate steps to
secure their systems, Facebook decided that these bug reports weren't
worth any reward at all.

An up-to-date version (including a YouTube demo) of this document can
be found at http://klikki.fi/adv/yoast_analytics2.html .

-- 
Jouko Pynnönen <jouko@....fi>
Klikki Oy - http://klikki.fi - @klikkioy