![]() It suggests that there may be a deserialization exploit in play, and that ModSec could be a key factor related to the use of cookies. Upon investigating potential vulnerabilities related to cookies and Express, I came across an informative article at exploiting-node-js-deserialization-bug-for-remote-code-execution. The article explains how the use of a second equals sign within the cookie parameter may result in a DoS condition with Mod Security.įrom the website’s architecture, it appears to be built on the Express framework. READ MORE HERE : modsecurity-vulnerability-cve-2019-19886 Further investigation into Mod Security’s cookie-related exploits unearthed several informative articles, including this one: ModSec appears to be the WAF employed to safeguard this webpage, which seems peculiar. I encountered an error while attempting to fuzz the login page using SQL Injection payloads. It appeared as a JWT token, but it was not actually a profile cookie: Furthermore, the website utilized Express as its backend framework, which could assist in identifying potential vulnerabilities related to these cookies Bypassing ModSec (RCE) As I proxied the traffic, I stumbled upon an intriguing cookie. Therefore, I decided to use Burp Suite to inspect the background activity. I didn’t find anything interesting on this page. Luckly,I attempted to login with admin:admin, and it worked! Website : Ī login page greets us at the new domain: Let’s add that to the /etc/hosts file and enumerate there. Ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u -H "Host: /" -fw 3
0 Comments
Leave a Reply. |