From basic User to full right Admin access on the server (via XSS, LFI, WebShell)
Imagine that you have a business in partnership with someone. At some point, you have an internal conflict. What will you do as a main business owner? Changing all passwords in important places? Are you sure that this is a sufficient measure of protection against attacks from an offended partner?
Something like this happened with one company and they decided to make a security check for important parts. Approximate profile of the attacker was compiled. And I started to explore system more and more. The system was built hierarchically. There was Auth jwt token service. Further on the issued jwt tokens, user could do something on different subdomains.
Testing scope was pretty small — only one subdomain. But the most important according to customers. We decide to decrease scope for first testing iteration. As a result of testing, absolutely all resources and projects could be compromised. I will not tell in detail about all issues which i found. It was a lot. I will only describe those that seemed curious to me and strange in 2019 year.
- UserName Information Disclosure
Users search GET request allowed receiving a set of information of the following nature — userID, Name, Login, avatar …
Without any problems, it was possible to collect data of all users with real LoginNames. I think everyone understands what can be done with such information further?! Brute force attack or perform point phishing attack for example… Up to this point, customer did not understand that redundant information could be a problem.
2. Blind XSS in support request
It was simple support request with special form. With inserted XSS inside. I have some feelings that this problem exists in 80% of the systems I encounter. No one understand how risky this can be. In this case, I was informed that the attack was working suddenly after receiving a notification from XSS Hunter. But the customer was not sure that I could takeover control of admin panel through this attack vector.
Since XSS Hunter does not support getting local storage information, i used another XSS Logger. The following article was very helpful.
As a result of the repeated attack, it was possible to make sure that the system administrator’s JWT Token could easily be leaked with blind XSS attack.
3. Stored XSS in E-mail template
I discovered functionality which allows to make prepared email invitations for registration in the system.
The name of the person could be inserted into the form of the letter. To have email template more personal. In order to crank up such a successful attack through such a letter — you need to know the victim’s email client and you need to know the zero day xss for this client. In general, the success results from such type of attack, by definition, will be unreal. Until the moment when I found a curious button in the received email.
It was possible to open email in browser mode. And here I found a surprise XSS message. At the same time, the web version of the email was opened on the administrator’s subdomain.
Double surprise so to speak.
4. Available access.log file (Local file inclusion)
During my testing session, I found an interesting place in the system. The responses from the server was 404. But it was different 404 errors. Sometimes there was an additional header. Sometimes not. I decided to check this place a little bit with fuzzing technique.
As a result, I was very surprised by the server response with 200 status code with pretty heavy size of the transmitted data.
It turned out that I discovered the readable access.log file. All activity on the server was recorded in that file. User Agents, jwt tokens and many other things. That can lead to takeover control of all active users.
5. Full Web Shell Access
In principle, all the problems described above could be quite often. But certain types of vulnerabilities are already quite difficult to find. I am talking about shell access to the server through neatly loaded code in the shell.php file.
First things first. It was possible to make posts and articles in the system. At the same time it was possible to upload a picture as a wallpaper for your article. The picture was saved on the same domain. But the filename is forced to changed. Ie you upload — mypicture.jpg. But as a result, you will have 123456.jpg. I decided to check what will happen if I will try to upload xml file. And to my surprise I received in response 123456.xml. And then I realized that there is a 99% chance of success with the php web shell file. For this attack, I used the b374k shell (https://github.com/b374k/b374k). With a direct access to the file, I got what I wanted — full access to the server through the loaded shell file.
But it was not the saddest thing. The saddest thing was that through this vulnerability it was possible to compromise more than 10 projects that were in the root directory on this server !!!
My friend said that it was possible to hack many projects from one shell upload in the 2010 year. Alas, in the courtyard of 2019. And a similar problem exists to this day.
As a result of testing, the customer was very surprised with my findings from the report. And I was very glad that my work was very helpful.
PS: Click 👏 “Clapping Hands” icon if you like this article 😉
If you need to auditing and testing some projects, please get in touch with me: http://t.me/valyaroller. I like to be helpful and have valuable findings.
