Imagine hearing about an unpatched, eight-year-old vulnerability in a popular, open-source web application framework originally developed by Google. Most offensive security professionals would likely assume it was an unfounded rumor. At a bare minimum, the developers must have updated documentation like “getting started” tutorials to indicate the inherent danger of using vulnerable features rather than highlighting the application’s functionality. Alternatively, the vulnerable framework features could have been marked as deprecated or the framework documentation could offer suggestions for replacing vulnerable code with updated alternatives.

It may seem hard to believe, but this is not just a rumor. Despite being openly discussed in 2015 and 2023 amongst the security community, the vulnerability in GWT (originally “Google Web Toolkit or sometimes referred to as “GWT Web Toolkit”) exists and could expose application owners to server-side code execution by unauthenticated attackers.

Session Summary

The session provides a methodical approach to identifying vulnerable GWT applications, beginning with reconnaissance techniques to detect GWT-specific traffic patterns in web requests. Lincoln demonstrates how to identify the telltale signs of vulnerable binary serialization through HTTP header analysis and by filtering for specific base64-encoded Java serialization headers. He then walks through the exploitation process using a custom-modified version of the ysoserial tool developed by Bishop Fox specifically for GWT's unique serialization implementation. The demonstration shows how attackers can progress from initial vulnerability confirmation using DNS callbacks to full command execution on vulnerable servers. Throughout the presentation, Lincoln emphasizes that while GWT's developers have issued updates to disable the vulnerable feature by default, existing applications remain at risk since disabling the feature would break functionality. He concludes by noting that true remediation requires modifying applications to eliminate the use of binary serialization entirely, rather than attempting to filter malicious requests.

Key Takeaways

1. Widespread unpatched vulnerability - This deserialization flaw has existed since at least 2015, but many applications built during that period remain vulnerable as patching would break functionality.
2. Easy identification techniques - Vulnerable applications can be detected by filtering web traffic for GWT-specific headers and base64-encoded Java serialization patterns (|r0).
3. Modified exploitation tools required - Standard deserialization exploitation tools don't work against GWT due to its unique implementation; Bishop Fox's custom ysoserial version addresses these differences.
4. Multiple exploitation vectors - The vulnerability can lead to remote command execution through various gadget chains, with Python-based payloads proving particularly effective in testing.
5. Filtering ineffective for mitigation - Web application firewalls and other filtering approaches struggle to distinguish malicious from legitimate GWT traffic, making application modification the only reliable remediation.
6. Beyond credential requirements - While attackers may initially need credentials to find vulnerable GWT RPC methods, once identified, these vulnerabilities can typically be exploited without authentication.