Story: Few months back I was reading a security news on one of the famous news site, and by mistake I typed some characters in the URL and then the site responded with an obvious 404 page. At that time my Burpsuite was open and all the traffic was passing through it. Now as security analysts we do have some habit to play with the URLs and parameters. So, due to this bad habit ;), I entered some special characters and luckily those got reflected in the 404 response page. After further investigation I came to know that the news site has actually implemented the Gtranslate and the vulnerability is present in the code of GTranslate wordpress plugin.
About GTranslate & its WordPress plugin
GTranslate is the product which can translate any HTML website and make it multilingual. It will help you to increase international traffic, reach a global audience and explore new markets. More Information about product.
And as per the description on WordPress site, GTranslate is a leading website translation services provider since 2008 and powers more than 500.000 multilingual websites worldwide.
Vulnerability
The vulnerability I found in GTranslate WordPress plugin is Reflected Cross Site Scripting and it was straight forward, and I did not spend much time on this to identify the bug. The vulnerability requires use of the hreflang tags feature within a sub-domain or sub-directory which is a paid option of WordPress plugin.
As we all know, there are a hell lot of blogs and articles available on XSS and I do not want to add one more into it. So instead of discussing what is XSS and what we can do with it, I would like to keep this blog as minimal as possible and will do an analysis where the vulnerability exists. And one more fact why I am writing this is because it’s my first CVE :D.
Plugin Setup & Analysis of code
Open the GTranslate page, select and download the vulnerable version of GTranslate WordPress plugin (gtranslate.2.8.38.zip).
Install the plugin in WordPress and make sure you select Add hreflang tags & sub-domain URL structure checkboxes before activating it.
Now, lets first quickly observe the vulnerability in code, for that extract the gtranslate.2.8.38.zip and Open gtranslate.php file in any editor.
Step-1: navigate to the line #1940 in gtranslate.php which checks for whether you add the hreflang tags and have you selected the enterprise version of plugin or not. Then, at line #1955 it obtained the value of current_url from the home_url().
Step-2: Observe what will home_url() will do from its official page.
So as per the description, we can say that the plugin will retrieve the URL which is displayed on page and set it into current_url variable.
Step-3: Observe that at line #1959, #1967, #1969, #1972 where, current_url variable is directly used without any kind of validation and decoding which lead to reflecting the same in page response and hence Reflected XSS.
Now Let’s open the browser and observe the same by visiting the page. We have already activated the plugin with required options set.
We can see from the below screenshot that the plugin is activated and ready to use on the page.
Enter any value in the URL (E.x: asdf) and observe the response which is an obvious 404 page.
Now Let’s observe the same but in Burp’s repeater.
From the above screenshot we can see that our invalid page value reflects as it is in response.
Without wasting much time, let’s add our payload in the URL, "><script>alert(location)</script> and observe the response.
But doing the same in the browser will not give us a xss alert so let’s compensate for the extra angular bracket with our payload.
So our final payload will be: "><script>alert(location)</script><img src=x.
And here is my First CVE :).
Sincere thanks to Mihir Doshi (@m1h1rd) for helping me in setting up the plugin.
Disclosure Timeline
- 10th February 2020 reported to the vendor
- 18th February 2020 Fixed by vendor
- 20th April 2020 CVE assigned
happy hacking and Cheers.
