*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=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://ift.tt/1EqZn9H .
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment