summersec/shiroattack2

ShiroAttack2 A quick exploitation tool targeting the Shiro-550 vulnerability

Language Switching / Language:Chinese | English

Complete instructions: docs/USAGE.md

---

Why Shiro-550 is still usable

The hole from 2016 is still usable today. It’s not that the vulnerability itself is superficial, but rather three very practical reasons stacked together.

**First, default Key. ** Shiro 1.2.4 and earlier versions forcibly wrote an AES Key in CookieRememberMeManager: kPH+bIxk5D2deZiIxcaaaA==. For over a decade, tutorials and scaffolding code have been copying this value.

**Second, the key cannot be replaced. ** rememberMe requires both client and server to use the same Key. Once the Key is written into the configuration file, Docker image, or source repository, replacing it requires all nodes to change together.

**Third, the cost of utilization is low enough. ** You can get the shell with just a few GUI clicks, and the CLI can be directly embedded into scripts.

Attack Process

CLI Mode

After version 5.0, a CLI mode was added. The core attack logic AttackService (1000+ lines) remains unchanged—by inheriting TextArea intercepting log output, using the ControllersFactory registry to inject fake MainController], with the GUI and CLI sharing the same set of attack code. The CLI does not require a JavaFX window; at startup, a JFXPanel initializes the JavaFX thread.

In --json mode, output is divided into two channels: those starting with { are structured logs, AI or scripts can be used as JSON.parse lines; those not starting with { are original command outputs, and tail -1 can get the result.

AES mode: --cbc(Shiro ≤1.2.4), --gcm(Shiro ≥1.2.5).

Gadget automatically detects first attempts on the String/AttrCompare/ObjectToStringComparator variant (no commons-collections needed), then reverts to the CB variant that depends on ComparableComparator.