However, a large range of versions of tomcat are affected. There have to be libraries on the classpath which are vulnerable to be exploited by a Java deserialization attack (e.g.The attacker has to find a separate file upload vulnerability to place the malicious serialized file on the server.This is likely to happen only on websites with high traffic loads (but not too high, as it will be more likely that a JDBC Store is used instead of a File Store) PersistentManager needs to be enabled manually by the tomcat administrator.This attack can have high impact (RCE), but the conditions that need to be met make the likelihood of exploitation low. There is however a very quick and convenient PoC written by masahiro311, see this GitHub page. It doesn’t make much sense to create an exploit as it’s just one HTTP request. If you are unfamiliar with exploiting Java deserialization vulnerabilities, we have an online course available that teaches you all the details. generated by ysoserial) at location /tmp/ssion. Of course, all that is left to exploit the vulnerability is for the attacker to put a malicious serialized object (i.e.
The malicious code has already been executed at that point. The error is thrown after deserialization succeeded but when it tried to interpret the object as a session (which it is not). The blue line then shows that it tries to deserialize the object. The web application will return HTTP 500 error upon exploitation, because it encounters a malicious serialized object instead of one that contains session information as it expects.įrom the line in the stacktrace of the above image marked in red we see that the PersistentManager tries to load the session from the FileStore. If the file exists, it will deserialize it and parse the session information from it.It will check at location directory + sessionid + ".session", which evaluates to “.But the currently running Manager is a PersistentManager, so it will also check if it has the session on disk. It will first check if it has that session in memory.Tomcat requests the Manager to check if a session with session ID “.Because the attacker can control the value of JSESSIONID sent in the request, what would happen if he put something like “ JSESSIONID=././././././tmp/12345“? When Tomcat receives a HTTP request with a JSESSIONID cookie, it will ask the Manager to check if this session already exists. When there is no Manager tag written in context.xml, the StandardManager will be used. A few days ago, a new remote code execution vulnerability was disclosed for Apache Tomcat.