So in my quest to quench my thirst for tinkering with things I stumbled on LimeSurvey and decided to take a look at it and see what could be done. To explain what LimeSurvey is the below text has been taken from their page.
LimeSurvey is the tool to use for your online surveys.
Whether you are conducting simple questionnaires with just a couple of questions or advanced assessments with conditionals and quota management, LimeSurvey has got you covered.
LimeSurvey is 100% open source and will always be transparently developed.
We can help you reach your goals.
I registered for a trial account and set everything up on my server that I use for my reviews. The first thing that I found was that there was brute force protection in place but that it could be bypassed by manipulating the Client-IP or X-Forwarded-For headers. This was discovered in version 3.21.1+191210 but is likely to be present in earlier versions as well. It was patched in version 4.1.0+200128 in this commit. It has been assigned CVE-2019–19804. Now of course this can still become a problem depending on how LimeSurvey is setup. Since the code now uses $_SERVER[‘REMOTE_ADDR’] to fetch the IP of the client, it could spell trouble if the application is behind a load balancer or reverse proxy that will not correctly report the client IP. So there’s some room for configuration that should be considered here. …
So previously I wrote about a few vulnerabilities that I found in YetiShare ( https://medium.com/@jra8908/yetishare-3-5-2-4-5-3-multiple-vulnerabilities-2d01d0cd7459) and during the process of testing the fixes that were made, I found a few more. These have been cleared to write about now, so here they are 😊.
The previous patch missed a few spots, which have been mitigated in the version 4.5.5 of YetiShare. …
This disclosure has been waiting to be let out for some time now. Some of these I first stumbled on many years ago but didn’t have the time or energy to give it any more thought. Well now I have both time, energy, and motivation to report and write about all the stuff I’ve found (including new findings since I’m currently on a “review roll”).
An admin user can instruct the updater script to downgrade to another version instead of upgrade, reintroducing previous flaws. …
I had an older version of YetiShare laying around, and decided to see if I could find anything fun to play with. Since I made quite a few findings, I decided to write about most of them here instead of making separate articles about each of them. It was hard at first to figure out a way to confirm the findings in the newer versions since I didn’t have a license. But with the help of others; including YetiShare themselves, I was able to fully confirm everything. I will probably be writing a separate article later about other findings that were made, since I made new findings in the patched release they made. They gave me a license to the latest version for me to review, and then more was found and reported. I would like to thank the support at MFScripts (The makers of YetiShare) for being so patient with me and my continuous rambling and spamming about new discoveries; but when I get into the flow … there’s just no stopping it. I will try to keep this article light and just describe shortly about each finding, then you can find the technical details in the respective Github repository. I also want to mention that I did not have access to any versions below v3.5.2, …
This is basically the exact same thing again as with CVE-2019–19576. I took another look after the patch was released and realized that there are other PHP extensions out there, in this case on Debian/Ubuntu with PHP5 that this library does not blacklist. So I installed PHP5 on Ubuntu and tested it, and the same thing went through. Both Verot and K2/JoomlaWorks have released patches and agreed to release this new CVE.
So this is a bit of a shorter text, but there are a bunch of more coming up (That are currently within the 90 days responsible disclosure timeline, plus some Vendors that have asked for extended time).
PoC github: https://github.com/jra89/CVE-2019-19576
This is a filter bypass exploit that results in arbitrary file upload and remote code execution. The class.upload.php script filters “dangerous files and content” and renames them to the txt file extension. It also does different type of transformation on the uploaded image, which would normally destroy any injected payload, even if the file extension filter could be bypassed.
The file extension filter is a blacklist, so any time a new extension is introduced (in this case phar), or any has been missed, a PHP file can be uploaded. The content must still be a valid image however and will still go through the imagecreatefromjpeg and similar functions. For this purpose I wrote the inject.php script which will essentially bruteforce its way through different images until it finds one where the payload will not be destroyed by the process done in class.upload.php. This effectively gives us an arbitrary file upload and a very stealthy code execution since it’s still a valid image and will be displayed like one on pages where uploaded. …