Exploit Lab Red Team

Another validated security disclosure from our research. While testing the ERPnext application's authorization controls, we looked at what a user with no special permissions could access through functionality that handles Contract Templates. We created a zero-role account and found that it was possible to retrieve the contents of a Contract Template that the account should not have been able to access. The interesting part wasn't simply that the data was exposed. It was that the application's normal permission model said one thing, while the affected functionality effectively allowed us to work around it. That's the kind of gap we look for during application security testing: places where individual endpoints, functions, or workflows don't enforce the same access controls as the rest of the application. We reported the issue to Frappe security team, and it has since been fixed. The vulnerability is now publicly documented as https://lnkd.in/e9QgEDN6

What is Server-Side Request Forgery (SSRF)? Server-Side Request Forgery (SSRF) is a vulnerability that allows an attacker to make HTTP requests to destinations the attacker normally couldn't reach directly. The request comes from the server, which means it may have access to resources that aren't exposed to the attacker. For example, an application might fetch an image from a URL provided by the user. If that URL isn't properly validated, an attacker could manipulate it so the server makes a request to an internal resource instead of the intended external destination. That can expose services such as: → Internal applications   → Internal APIs   → Local services   → Private network resources   → Cloud metadata services This is why SSRF is worth investigating during a penetration test. Finding the vulnerable request is only part of the assessment. The impact depends on what the server can reach and what information or functionality is exposed through it. To reduce SSRF risk, applications that make requests to user-controlled URLs should validate and restrict destinations, prevent access to internal and private network ranges, restrict cloud metadata access, and apply appropriate outbound network controls. With SSRF, the vulnerable endpoint is only the entry point. The surrounding environment determines what that access actually exposes. #CyberSecurity #WebSecurity #SSRF #PenetrationTesting #RedTeam #ApplicationSecurity #ExploitLab

When a full crew of attackers comes together, and your cybersecurity is just one tiny lock trying to hold everything back. 😂 Cyberattacks don’t always come one at a time. Multiple attack vectors, persistence, exploitation and lateral movement can turn a single weakness into a much bigger problem. Security needs to be ready for the whole crew.

We disclosed a high-severity authorization vulnerability in ERPNext that allowed an authenticated user to access Communication data they were not authorized to see. In practical terms: a user with limited permissions could retrieve sensitive Communication content belonging to documents they should not have access to. The issue was reported to the Frappe security team and has now been addressed in: • ERPNext 15.120.0 • ERPNext 16.33.0 The vulnerability is tracked publicly as GHSA-cgxw-2996-9vj3, with: Severity: High CVSS: 7.7 CWE: CWE-862 — Missing Authorization The issue involved insufficient authorization checks in the "get_last_interaction" endpoint. An authenticated user, including a zero-role user, could create a Contact containing a Dynamic Link to an existing document and use the endpoint to retrieve Communication content associated with that document, despite not having permission to read the underlying Communication. During testing, directly requesting the same Communication through the REST API returned 403 Forbidden, while the vulnerable endpoint returned the Communication content. That distinction confirmed the authorization gap was in the helper itself rather than the user's normal document permissions. Frappe has published the security advisory and credited Exploit Lab as a reporter. Security Advisory: https://lnkd.in/eiyvhQr8 Affected users should upgrade to ERPNext 15.120.0 or 16.33.0. Research and disclosure by Exploit Lab Red Team