Create CVE-2021-36748.yaml

[pajoda]

Template / PR Information

Blog for PrestaShop by PrestaHome up until version 1.7.7 is vulnerable to SQL injections.
Vulnerable path: /module/ph_simpleblog/list?sb_category=

It doesn't seem like data can be reflected with a UNION SELECT and due to a special way the plugin or shop system seems to react to an empty result caused by a AND false injection in the WHERE clause, I figured this might be faster than a time-based detection.

From by observation while creating the template with example pages, requesting the normal site by showing all categories via OR true-- - returns a 200 with some content or an information that there are no posts and not returning any data by using AND false results in an entirely empty 404 response. Combining all these aspects into the need of an 200 vs. a 404 and a existent body vs. an empty body should be a solid detection. We could go time-based though. It takes 4 times the SLEEP value, so 5 takes about 20 seconds, 3 takes about 12 seconds.

If I may ask a question while someone with more in-depth knowledge about Nuclei is reading this:
Is there a way to dump DSL aspects? Like if my DSL doesn't match for some reason, it would be nice to have some kind of a debug mode that tells me about status_code_1, status_code_2 and the other values. In the best case it even detects the parts that don't match. Maybe not just for DSL matchers but for any matcher so I know what exactly has been done and returned to debug why things don't work, -v only gives the request path. This is also how I found out why I seemingly need to use raw requests for this simple task. There was a double // if the input target has a trailing /, which caused the application to respond differently, it seems to be important to have the exact path and using trimright doesn't work in normal requests to remove a possible trailing slash if I'm not mistaken. (Just as documentation and information for people that might read this in the future: This is BS. I was using an older Nuclei version, the behaviour was changed over time.)

Please feel free to correct me if I am wrong about any of my information, I'm also open to a time-based detection as explained above.

Template Validation

I've validated this template locally?

• YES
• NO

Additional Details (leave it blank if not applicable)

You can easily find vulnerable pages by searching for "modules/ph_simpleblog/" in website source code search engines. Basically all of them are vulnerable. I literally can't find a secure one which is bad for a double verification. Even the demo shop from the vendor is still vulnerable.

Additional References:

• CVE-2021-36748
• Writeup by pentester

[ehsandeep]

@pajoda

If I may ask a question while someone with more in-depth knowledge about Nuclei is reading this:
Is there a way to dump DSL aspects? Like if my DSL doesn't match for some reason, it would be nice to have some kind of a debug mode that tells me about status_code_1, status_code_2 and the other values. In the best case it even detects the parts that don't match. Maybe not just for DSL matchers but for any matcher so I know what exactly has been done and returned to debug why things don't work, -v only gives the request path.

You can use debug flag to dump request and response, or debug-req or debug-resp for dumping specific parts.

[ehsandeep]

@pajoda thank you for adding all the details around this template, it's working very well, also the matchers you wrote were technically right, I just updated them per line to make it more readable and easy to understand for others.

Also only looking for length and status code will work for the vulnerable host, as well as some random hosts having similar responses, so it's always a good idea to include some page-specific unique string to ensure our matchers doesn't get a match against an unrelated target, so I've also included PrestaShop specific string in the matchers.

I've also noticed that len(body_2) == 0 works perfectly when a server returns the content-length header in the response, and unfortunately not all the servers return that header, in that case, this matcher will miss the valid target, so I think this part can be improved as well.

[pajoda]

No problem, I hope detailed information helps to speed up your review and understand my thought process and find possible issues in it.

Great addition again, I should have spotted the redirect header too actually. Thank you!

I see, comprehensive review again! Does the following matcher section fix this?

          - "status_code_1 == 200"
          - 'contains(tolower(body_1), "prestashop")'
          - "len(body_1) > 0"
          - "status_code_2 == 404"
          - 'trimspace(body_2) == ""'
          - "contains(tolower(all_headers_2), 'index.php?controller=404')"

I also added a tolower to the prestashop string lookup. I guess you were looking for var prestashop which seems to be a very common thing, I saw some CSS classes on several pages that were Pascal Case, additionally a PrestaShop generator meta tag seems to be a thing so I figured this might make it a bit more flexible.