[R4] Apache Wicket DiskFileItem Java Deserialization Remote File Manipulation

Apache Wicket is "an open source, component oriented, server-side, Java web application framework." Currently, main development of Wicket is done on the 8.x branch. However, Wicket’s website indicates the current release is listed as 7.3.0 and they continue to offer 6.23.0 as well as 1.5.14.

The Issue

Wicket 6.x contains an implementation of a Java Class called “DiskFileItem” that is nearly identical to the Commons Upload previously disclosed in TRA-2016-12. The only real difference being that the Commons Upload version has been updated to address issues such as CVE-2013-2186 where the Wicket version has not. Fortunately, most (if not all) JVM will catch this attack so it no longer needs to be explicitly checked for as done in Commons Fileupload. Interestingly, DiskFileItem was purged from the 7.x branch back in 2014 as a result of the WICKET-5503 ticket as seen in commit 99fcd91. The developers correctly identified that tracking security updates in Commons FileUpload was too difficult (since they already missed the update to DiskFileItem).

Can This Be Used In Deserialization Attacks?

Of course! As a quick proof of concept, Tenable created a new payload in ysoserial and it is almost an exact copy/paste job of the FileUpload1 payload but uses wicket-util. This allows an attacker to add, move, and delete files that Apache DiskFileItem can. Additionally, if an older Java VM is running, the attacker can control the filename as well, since the NULL byte check doesn't exist. In that case, the ability to name and place a custom file can lead to remote code execution.

Note that the CVSSv2 score downplays the severity of this issue due to the academic nature of the scoring system. Worst case scenario, this can be leveraged to achieve remote code execution in some cases through several actions.

On 2016-11-25, the Wicket team contacted us again and mentioned that they missed an important point in our original report to them: "Protect against null byte attacks". Pedro Santos from the Wicket team dug into this even further and committed additional fixes and write-up. His analysis concludes this is specific to Wicket and had CVE-2016-6793 assigned for it. More details will be published via Wicket's page on this issue in the near future.