During pentest, I came across an interesting and unusual case where developers're trying to escape a single quote (') via a single quote (') in an script context. Further, I noticed that they were adding ' on the right hand side of the injected single quote. The developers're trying to have single quotes in pair but why? Are they trying to escape or something else? It sounds unfortunately funny and at the same time shows XSSing is not going anywhere in the near future.
The screen-shot given below shows the reflection of our interest. Please keep in mind that I had used the harmless XSS probe string i.e., "xxxxxxxx'yyyyy. The < sign is not part of probe string given site has enabled .NET's XSS protection. The site forcefully redirects me to an error page if I inject < character.
The screen-shot given below shows the reflection of our interest. Please keep in mind that I had used the harmless XSS probe string i.e., "xxxxxxxx'yyyyy. The < sign is not part of probe string given site has enabled .NET's XSS protection. The site forcefully redirects me to an error page if I inject < character.
It can be seen in the screen-shot above that site has added or appended an extra ' for escaping (the apparent reason I can think of) a single quote from the probe string. As you could aware of the fact that \ may be used as an escape character for ' and " quotes in an script context like \'and \" respectively. The site was adding/appending an extra ' as an escape character for the injected ' so payload(s) like '-confirm(1)-' and ');confirm(1);// do not work. Soon I realized during testing that \ is not escaped or controlled or filtered. The attack payload I used to XSS this case is: \');confirm(1);//. It starts with \'. The screen-shot is given below and later I will explain why the payload works.
The attack payload was \');confirm(1);//. It starts with \' in order to make single quote as an escape character. After that application has added/appended one single quote because application developers want to have or see single quotes in pair. So we have a situation like this: '\''. It is perfectly legit given in a pair of single quotes there is an escaped single quote. After that )character closes the function call prematurely followed by a semi-colon i.e., ; as a statement terminator. The next is a proof of concept JavaScript function call i.e., confirm(1); followed a single line comment i.e., // in order to avoid syntax error or neutralizes the effect of remaining parts of function call i.e., notyAlert. This XSS shows how one can leverage application's unusual functionality against it.
Sunday, February 28, 2016
Stored, Reflected and DOM XSS in Google for Work Connect (GWC)
Google for Work Connect (GWC) is "a community for system/application administrators and partners". GWC is in scope for Google bug bounty program though Google considers it a low priority application as far as reward amount is concerned. It is not about reward all the time. This blog (i.e., Respect XSS) is about XSS. Some time ago, I found Stored, Reflected and DOM XSS in GWC.
Stored XSS
In GWC community, application administrators can share their ideas and help each other. The application allows users to create a document/posting/thread/message and among other features (e.g., mark as question, tags and category etc), the posting has a title or name and messagebody. The title of posting is of our interest in this case. The site was doing good in encoding <character into < (if found in the title) (see screen-shot).
As you can see in the above screen-shot that < is encoded in an HTML context (i.e., <a> tag around reflection), so no need to waste time here. The site has another feature where one can do the same stuff but via Google Drive. The feature is labelled as "Add a file from Google Drive". In that case, at that time (now site has been updated and things may be bit different), the name of Google Drive file becomes the title of the post. The screen-shot shows the site's behavior when a file has been added from Google Drive. Please keep in mind that in Google Drive, I had first created a file named "xxxxxxxx'yyyyy</img>.PNG so that I can used that file here in GWC.
The screen-shot above shows reflection in GWC and and it can be seen that reflection was in script context in general and as a part of var declaration (i.e., object literal) in particular. The developers were using " for holding the title of file and at the same time, " and </ were not controlled or filtered or escaped. The XSS is now pretty straight forward, Please make sure that you have a file in Google Drive named </script><script>confirm(document.domain)</script>
This was an stored XSS because posting on GWC is available for all logged-in users. The root cause of this stored XSS was that GWC application forgot to control/encode/filter input from other application (i.e., Google Drive) though they were doing good on direct user-supplied input.
Reflected XSS
If somehow you're able to cause an error (e.g., file was not properly uploaded from Google Drive) in GWC then application throws an error message in a GET parameter named "googleDriveError". This GET parameter is vulnerable to a classical reflected XSS. Further if you're able to cause an authentication error, then application throws an error message as a part of GET parameter named "error". Both error related GET parameters were vulnerable and both were using the same code base. The screen-shot shows the reflection of our harmless probe string "xxxxxxxx'yyyyy</img as a part of "googleDriveError" GET parameter.
It can be seen in the screen-shot that < is not filtered in an HTML context. It is enough of information. The next screen-shot shows reflected XSS in "googleDriveError" GET parameter followed by a reflected XSS in "error" GET parameter.
DOM XSS
I also found a DOM XSS in GWC. The culprit for DOM XSS was window.location.hash.substring(1) but the problematic JavaScript code executes only if someone marked/clicked the reply of a posting "Mark as Helpful". The vulnerable dynamic JavaScript code was part of a JavaScript file at that time (site has been updated and you will see a not found message). The vulnerable JavaScript code looks like ...
... {if(window.location.hash){c.scrollTo("a[name='"+window.location.hash.substring(1)+"']")} ...
There are two screen-shots given below. One shows where posting has not been marked "Helpful" and one shows where posting has been marked "Helpful". The DOM XSS payload was part of both cases but executes only in the later case.
GWC received an update recently so there is a great chance that this update has introduced some bugs. Happy Hunting ...
The screen-shot above shows reflection in GWC and and it can be seen that reflection was in script context in general and as a part of var declaration (i.e., object literal) in particular. The developers were using " for holding the title of file and at the same time, " and </ were not controlled or filtered or escaped. The XSS is now pretty straight forward, Please make sure that you have a file in Google Drive named </script><script>confirm(document.domain)</script>
This was an stored XSS because posting on GWC is available for all logged-in users. The root cause of this stored XSS was that GWC application forgot to control/encode/filter input from other application (i.e., Google Drive) though they were doing good on direct user-supplied input.
Reflected XSS
If somehow you're able to cause an error (e.g., file was not properly uploaded from Google Drive) in GWC then application throws an error message in a GET parameter named "googleDriveError". This GET parameter is vulnerable to a classical reflected XSS. Further if you're able to cause an authentication error, then application throws an error message as a part of GET parameter named "error". Both error related GET parameters were vulnerable and both were using the same code base. The screen-shot shows the reflection of our harmless probe string "xxxxxxxx'yyyyy</img as a part of "googleDriveError" GET parameter.
It can be seen in the screen-shot that < is not filtered in an HTML context. It is enough of information. The next screen-shot shows reflected XSS in "googleDriveError" GET parameter followed by a reflected XSS in "error" GET parameter.
DOM XSS
I also found a DOM XSS in GWC. The culprit for DOM XSS was window.location.hash.substring(1) but the problematic JavaScript code executes only if someone marked/clicked the reply of a posting "Mark as Helpful". The vulnerable dynamic JavaScript code was part of a JavaScript file at that time (site has been updated and you will see a not found message). The vulnerable JavaScript code looks like ...
... {if(window.location.hash){c.scrollTo("a[name='"+window.location.hash.substring(1)+"']")} ...
There are two screen-shots given below. One shows where posting has not been marked "Helpful" and one shows where posting has been marked "Helpful". The DOM XSS payload was part of both cases but executes only in the later case.
GWC received an update recently so there is a great chance that this update has introduced some bugs. Happy Hunting ...
0 Comment:
Đăng nhận xét
Thank you for your comments!