*Overview*
Google Analytics by Yoast is a WordPress plug-in for monitoring website
traffic. With approximately seven million downloads it’s one of the most
popular WordPress plug-ins.
A security vulnerability in the plug-in allows an unauthenticated attacker
to store arbitrary HTML, including JavaScript, in the WordPress
administrator’s Dashboard on the target system. The JavaScript will be
triggered when an administrator views the plug-in’s settings panel. No
further user interaction is required.
Typically this can be used for arbitrary server-side code execution via the
plugin or theme editors. Alternatively the attacker could change the
administrator’s password, create new administrator accounts, or do whatever
else the currently logged-in administrator can do on the target site.
*Details*
The impact is a combination of two underlying problems. Firstly, missing
access control allows an unauthenticated user to modify some of the
settings associated with the plug-in. It’s possible overwrite the existing
OAuth2 credentials which the plug-in uses for retrieving data from Google
Analytics, and thereby connect the plug-in with the attacker’s own Google
Analytics account.
Secondly, the plug-in renders an HTML dropdown menu based on the data
downloaded from Google Analytics. This data is not sanitized or
HTML-escaped. If the said attacker enters HTML code such as <script> tags
in the properties in their Google Analytics account settings, it will
appear in the WordPress administrative Dashboard of the targeted system and
get executed whenever someone views the settings.
*Proof of Concept*
The following HTML snippet could be used to hijack the Google Analytics
account of a website running a vulnerable version of the plug-in:
<a href="http://YOUR.BLOG/wp-
<br><br>
<form method=POST action="http://YOUR.BLOG/wp-
<input type=text size=100 name="google_auth_code">
<input type=submit>
</form>
First, the attacker would click the reauth link. The action doesn't require
any kind of authentication. It will reset some of the plugin settings and
redirect the attacker to a google.com OAuth dialog, where they'd get an
authentication code.
Next the attacker would copy-paste the code in the above form and submit.
This would update the code in the plugin settings - again without requiring
authentication. The plugin would now retrieve its data from the attacker's
Google Analytics account.
The actual payload script would be entered at the attacker's own Google
Analytics account settings at
https://www.google.com/
An example of a property name:
test"><script>alert('stored XSS')</script>
This would fire an alert box whenever an administrator views the Analytics
settings page in the Dashboard of the target WordPress site.
A real-world attack would probably use a src attribute to load a more
sophisticated script from an external site. It could make chained ajax
calls to load and submit administrative forms, including those of the
plugin editor to write server-side PHP code, and finally execute it.
*Solution*
Yoast was notified on March 18, 2015. A new version of the plug-in (5.3.3)
was released the next day.
*Credits*
The vulnerability was found by Jouko Pynnönen of Klikki Oy, Finland.
An up-to-date version of this document is available at
http://klikki.fi/adv/yoast_
Google Analytics by Yoast is a WordPress plug-in for monitoring website
traffic. With approximately seven million downloads it’s one of the most
popular WordPress plug-ins.
A security vulnerability in the plug-in allows an unauthenticated attacker
to store arbitrary HTML, including JavaScript, in the WordPress
administrator’s Dashboard on the target system. The JavaScript will be
triggered when an administrator views the plug-in’s settings panel. No
further user interaction is required.
Typically this can be used for arbitrary server-side code execution via the
plugin or theme editors. Alternatively the attacker could change the
administrator’s password, create new administrator accounts, or do whatever
else the currently logged-in administrator can do on the target site.
*Details*
The impact is a combination of two underlying problems. Firstly, missing
access control allows an unauthenticated user to modify some of the
settings associated with the plug-in. It’s possible overwrite the existing
OAuth2 credentials which the plug-in uses for retrieving data from Google
Analytics, and thereby connect the plug-in with the attacker’s own Google
Analytics account.
Secondly, the plug-in renders an HTML dropdown menu based on the data
downloaded from Google Analytics. This data is not sanitized or
HTML-escaped. If the said attacker enters HTML code such as <script> tags
in the properties in their Google Analytics account settings, it will
appear in the WordPress administrative Dashboard of the targeted system and
get executed whenever someone views the settings.
*Proof of Concept*
The following HTML snippet could be used to hijack the Google Analytics
account of a website running a vulnerable version of the plug-in:
<a href="http://YOUR.BLOG/wp-
<br><br>
<form method=POST action="http://YOUR.BLOG/wp-
<input type=text size=100 name="google_auth_code">
<input type=submit>
</form>
First, the attacker would click the reauth link. The action doesn't require
any kind of authentication. It will reset some of the plugin settings and
redirect the attacker to a google.com OAuth dialog, where they'd get an
authentication code.
Next the attacker would copy-paste the code in the above form and submit.
This would update the code in the plugin settings - again without requiring
authentication. The plugin would now retrieve its data from the attacker's
Google Analytics account.
The actual payload script would be entered at the attacker's own Google
Analytics account settings at
https://www.google.com/
An example of a property name:
test"><script>alert('stored XSS')</script>
This would fire an alert box whenever an administrator views the Analytics
settings page in the Dashboard of the target WordPress site.
A real-world attack would probably use a src attribute to load a more
sophisticated script from an external site. It could make chained ajax
calls to load and submit administrative forms, including those of the
plugin editor to write server-side PHP code, and finally execute it.
*Solution*
Yoast was notified on March 18, 2015. A new version of the plug-in (5.3.3)
was released the next day.
*Credits*
The vulnerability was found by Jouko Pynnönen of Klikki Oy, Finland.
An up-to-date version of this document is available at
http://klikki.fi/adv/yoast_