某CMS的代码审计(RCE)

今天审了一个开源CMS，sql、upload和xss这些作者做的还不错，至少我走了一遍流程后没发现什么大问题。
就发现了一个rce，还是由shiro升级后，在config中硬编码导致的。其实这个一开始就看到了，但是打的时候没删JSESSIONID，以为不行，后来找了一圈又看了一遍，才发现。
直接放一下我记录的原文，关键词我过滤了。英语不好，见谅

xxx is a set of rapid development framework, scaffolding, backend management system, permission system

After downloading its source code from github, it was discovered through an audit that the author uses Shiro for the identification of permissions, so shiro is essential. I found that in the source code, Shiro’s version was upgraded to 1.6.0 though, avoiding the deserialization risks associated with using AES-CBC below version 1.2.4.
However, the author sets a fixed key in the ShiroConfig file and uses this key to encrypt the rememberMe parameter in the cookie. This situation can cause a deserialization attack with very serious consequences.

Set up a local environment for attacks. When the attacker logs in and selects remember me, the cookie will have the rememberMe field

Blast the field and find that the encoded key is 2AvVhdsgUs0FSA3SDFAdag==, which is the same as the one set in the source code
After an audit, I found that the source code contains commons-beanutils-1.9.4.jar dependency, which is actually a dependency included in shiro.
Using this dependency, it is possible to generate a deserialized payload and then encrypt the payload using the key obtained by blasting.
Finally, write this payload after the rememberMe field and attack it. Successful RCE

Note that the JSESSIONID in the cookie field should be deleted, otherwise the system will make judgments directly based on the JSESSIONID.

I found that the author provided a test environment on the public web for this project
Enter this website, use the test account to log in, and then follow the above steps to attack. Successful RCE