Skip to content

Latest commit

 

History

History
113 lines (71 loc) · 3.82 KB

CVE-2023-35078.md

File metadata and controls

113 lines (71 loc) · 3.82 KB

Notes on CVE-2023-35078

Summary

Warning

Work in progress, not well tested, may hit on false positives or false negatives, may break functionality if used for blocking, use at your own risk.

Theory 1 '/mifs/aad/*'

Based on the Ivanti RPM[2] for older, possibly unsupported versions of EPMM, it appears that the vulnerability (or at least a significant part of it) is due to all URL paths under /mifs/aad being permitted without authentication. Some sub-paths may have required authentication, some may legitimately not requrie authentication, but some (e.g., /mifs/aad/*/api/v2/*) allowed attackers to bypass authentication and perform sensitive operations (like accessing other users' information, creating EPMM administrative accounts).

/mifs/aad/api/v2/* seems to be the right detection, versus /mifs/aad/*/api/v2/*.

+ https://epmm.example.com/mifs/aad                  # allowed with no auth
+ https://epmm.example.com/mifs/aad/intune_response  # allowed with no auth

- https://epmm.example.com/mifs/aad/**               # now requires auth, was previously vulnerable

The Ivanti RPM[2] uses postinstall scripts to modify Apache Tomcat and httpd configuration files.

- <sec:http pattern="/aad/**" security="none" create-session="stateless"/>

+ <sec:http pattern="/aad" security="none" create-session="stateless"/>
+ <sec:http pattern="/aad/intune_response" security="none" create-session="stateless"/>

+ # Whitelist specific aad URI paths
+     RewriteCond         %{REQUEST_URI} ^/mifs/aad/
+     RewriteRule         !(/mifs/aad|/mifs/aad/intune_response)$ - [F]

nuclei

TBD

YARA

TBD

Basic regex

These paths could be vulnerable, should (all? mostly?) require authentication:

`.*(\/+mifs\/+aad\/+api\/+v2\/.*)`i

Allowed with no authentication:

`.*(\/+mifs\/+aad$)`i
`.*(\/+mifs\/+aad\/+intune_response$)`i

Theory 2 '/mifs' + '/api/v2/'

Warning

Based on the Ivanti RPMs this theory seems to be at least partially incorrect.

Not vulnerable, authentication is checked:

https://epmm.example.com/api/v2/

Vulnerable, authenticaiton is bypassed:

https://epmm.example.com/mifs/*/api/v2/

Is /mifs/ required?

Is any specific URL path required?

https://epmm.example.com/mifs/*/api/v2/
                         ^^^^^^^
                      what goes here?

nuclei

TBD, if this theory is even valid

YARA

rule CVE-2023-35078
{
strings:
$Regex_URL = /https?:\/\/+([\w\.-]+)(\/+mifs(?:\/+\w+)*\/+api\/+v2\/\w*)(\?*.*)/ nocase

condition:
all of them 
}

Basic regex

/https?:\/\/+([\w\.-]+)(\/+mifs(?:\/+\w+)*\/+api\/+v2\/\w*)(\?*.*)/i

References

[1] https://forums.ivanti.com/s/article/KB-Remote-unauthenticated-API-access-vulnerability-CVE-2023-35078

[2] https://support.mobileiron.com/ivanti-updates/ivanti-security-update-1.0.0-1.noarch.rpm

[3] https://doublepulsar.com/mobileirony-backdoor-allows-complete-takeover-of-mobile-security-product-and-endpoints-559733d612e1

[4] https://www.mnemonic.io/resources/blog/ivanti-endpoint-manager-mobile-epmm-authentication-bypass-vulnerability/

[5] https://github.com/projectdiscovery/nuclei-templates/blob/730c5c355814a585a9146b7c356373752d7e8b36/http/cves/2023/CVE-2023-35078.yaml