Changing Pre-Auth stored XSS to RCE for fun and no profit (CVE-NaN)
Hi all, it has been months since I didn’t publish anything on Medium. In January 2021, I found preauthentication stored XSS and command injection bug in TastyIgniter v2.1.1. TastyIgniter open-source food ordering and restaurant management system and it is written with laravel PHP framework. I decided to hunt vulnerabilies in this system because the system seems to be used by lots of restaurants, it has 1.2k stars and 599 forks in Github.
0x01- Hunting for Preauth bugs (i.e stored XSS)
After installing the TastyIgniter, I start focuing on user and guest area because if such area have some nasty bugs, that will be a huge profits for me. Even if I found SQLi or file upload misconfiguration to RCE in admin area, I cannot exploit the system if we have no admin credentail.
I stared reading the source code, looking some features and I realised that there are lots of stored XSS vulnerabilities in user’s address book.
However, these are self stored XSS because, in admin’s portal, XSS is not trigger as shown below.
I need to find another XSS to make something impactful.
After finding a bit, I found another stored XSS vulnerability that don’t need to login to trigger the vulnerability. The software has a booking features. After guest or user do some reservations, the web page showed reservation is succeed and first name, last name fields are vulnerable to XSS.
Firstly I thought, why XSS can trigger because laravel is using Blade technology and Blade itself automatically prevent such kinds of attack. After reading the source code, I found that below source code make vulnerable.
In laravel, between {{ something }} statements are automatically sent through PHP’s htmlspecialchars function to prevent XSS attacks but if you add !! in your blade template, javascript codes will not escapsed. What!!!!.
I tried to copied the above reservation link, pasted in another browser saw that XSS can trigger.
If admin views vulnerable link, we can steal admin’s session. Lol, I’m just kidding, nowadays session cookies are all protected with samesite, secure, httponly and so, if you can only think about stealing cookies, stop finding bugs and try learn some.
0x02- RCE discovery
Well, this one is so much easier than I think. In admin/settings/edit/mail url, admin can configure mail setting as shown below and “Sendmail Path” field is vulnerable to command injection vulnerability.
I can managed to run some commands by adding extra commands such as ;whoami; and command’s result is displayed in error as shown.
So, I have preauth stored XSS and command injection bug in admin side. If I can chain these two bugs, I can get one click RCE.
0x03- Combining the bugs
Below script and video shows how I can able to exploit preauth stored XSS and command injection vulnerablity to gain RCE.
PoC Video
Exploit code
0x04- Fixing the Bugs like Developer
Well, if I can find bugs why can’t I fixed them.
For stored XSS, replacing {!! with {{ in extensions/igniter/reservation/components/booking/success.blade.php will fix the issue.
For command injection bug, the developer is directly passed the user input in line 104
and then send an email with swiftmailer.
In swiftmailer documentation, we can declare sendmail binary using Swift_SendmailTransport function as shown below.
As a result, command injection occurs and so, adding passing user input to escapseshellcmd() before sending to SendmailTransport in vendor/laravel/framework/src/Illuminate/Mail/TransportManager.php will fix the issue.
Conclusion
I am so boring to submit for CVEs and so let it be and I called them as CVE-NaN.
