-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add module metasploit_static_secret_key_base #7341
add module metasploit_static_secret_key_base #7341
Conversation
Badass. |
[ | ||
['Metasploit 4.12.0-2016061501 to 4.12.0-2016083001', | ||
{ | ||
'RAILSVERSION' => 4, # The target Rails Version (use 3 for Rails3 and 2, 4 for Rails4) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we probably don't need this configurability unless we're going to add more targets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're probably right. I tried to avoid changing the plumbing from rails_secret_deserialization to maintain parity (e.g. Leaving in the rails3 stuff as dead code) and wanted to avoid having magic values (e.g. The salt) inlined in the code. Should the dead code should be removed at the cost of parity? If the magic values don't belong in the target, should they be inlined in the code, or defined somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if you want parity, it follows that it should just extend the original module with this as a selectable target, rather than being introduced as a separate module. If this is going to be a separate module, ideally the common code moves to lib or a mixin.
Barring that, for a one-off, I'd optimize out the dead code. It's unlikely someone's going to update a working version-specific exploit just because a more generic exploit added a feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if you want parity, it follows that it should just extend the original module with this as a selectable target, rather than being introduced as a separate module
I thought of that, but decided it'd inhibit discoverability
If this is going to be a separate module, ideally the common code moves to lib or a mixin.
Probably the way to go, especially if we keep cranking static secret_key_base
modules out. OTOH these should die out with the Rails session cookie deserializer now defaulting to JSON.
I'd optimize out the dead code
Sounds good to me, I'll get on it
* Inline magic values * Optimise out dead Rails3-specific code
4a83fa3
to
dcfbb9e
Compare
Verified with a Pro install which was upgraded to 4.12.0-2016081201:
Nice work, @justinsteven! I'll land this PR shortly... |
Release NotesThis module allows the user to exploit certain upgraded versions of Metasploit Community, Express, and Pro by forging a session cookie, allowing remote code execution. Upgrade versions of Metasploit Community, Express, and Pro 4.12.0-2016061501 through 4.12.0-2016083001 are vulnerable (full installs of these versions are not vulnerable, only the upgrades). Authentication is not required to exploit this vulnerability. See this blog post for more details: https://community.rapid7.com/community/metasploit/blog/2016/09/19/important-security-fixes-in-metasploit-4120-2016091401 |
Thanks @pbarry-r7 ! |
this is cool man |
Exploits the issues detailed in:
Heavily based on
exploits/multi/http/rails_secret_deserialization
.Verification
secret_key_base
baked in (see the list in Targets)msfconsole
use exploit/multi/http/metasploit_static_secret_key_base
exploit
Sample