Skip to content
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

Difference in store_loot db behavior when connected remotely #17396

Closed
adfoster-r7 opened this issue Dec 16, 2022 · 2 comments
Closed

Difference in store_loot db behavior when connected remotely #17396

adfoster-r7 opened this issue Dec 16, 2022 · 2 comments
Labels
attic Older submissions that we still want to work on again bug confirmed Issues confirmed by a committer database

Comments

@adfoster-r7
Copy link
Contributor

Steps to reproduce

Noticed when testing #17374

When loot is stored, it persists locally:

ws = (db ? myworkspace.name[0,16] : 'default')
name =
Time.now.strftime("%Y%m%d%H%M%S") + "_" + ws + "_" +
(host || 'unknown') + '_' + ltype[0,16] + '_' +
Rex::Text.rand_text_numeric(6) + '.' + ext
name.gsub!(/[^a-z0-9\.\_]+/i, '')
path = File.join(Msf::Config.loot_directory, name)
full_path = ::File.expand_path(path)
File.open(full_path, "wb") do |fd|
fd.write(data)
end

But when the ccache content and file name is sent to the remote DB, it creates an new path to stop naming conflicts:

def self.report_loot
lambda {
warden.authenticate!
job = lambda { |opts|
if opts[:data]
filename = File.basename(opts[:path])
local_path = File.join(Msf::Config.loot_directory, "#{SecureRandom.hex(10)}-#{filename}")

So the return result of store_loot is the locally chosen name:

/Users/user/metasploit-framework/spec/dummy/framework/config/loot/20221218123340_default_192.0.2.2_mit.kerberos.cca_549283.bin"

Whilst querying for loot shows the path as having a different prefix:

/Users/user/metasploit-framework/spec/dummy/framework/config/loot/c90fd2477aff93d8769f-20221218123340_default_192.0.2.2_mit.kerberos.cca_549283.bin

Expected behavior

I believe store_loot should generate a local file name - and send it to the remote db webservice.
We shuold then persist the loot contents locally using the chosen webservice file name.

Current behavior

What happens instead?

the result of store_loot differs to future loot queries

Metasploit version

msf6 auxiliary(scanner/winrm/winrm_login) > version
Framework: 6.2.31-dev-6f9ebe4068
Console  : 6.2.31-dev-6f9ebe4068
@adfoster-r7 adfoster-r7 mentioned this issue Dec 16, 2022
2 tasks
@github-actions
Copy link

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

@github-actions github-actions bot added the Stale Marks an issue as stale, to be closed if no action is taken label Jan 16, 2023
@github-actions github-actions bot removed the Stale Marks an issue as stale, to be closed if no action is taken label Jan 17, 2023
@gwillcox-r7 gwillcox-r7 added the confirmed Issues confirmed by a committer label Jan 19, 2023
@adfoster-r7 adfoster-r7 added the attic Older submissions that we still want to work on again label Apr 26, 2023
@github-actions
Copy link

Thanks for your contribution to Metasploit Framework! We've looked at this issue, and unfortunately we do not currently have the bandwidth to prioritize this issue.

We've labeled this as attic and closed it for now. If you believe this issue has been closed in error, or that it should be prioritized, please comment with additional information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
attic Older submissions that we still want to work on again bug confirmed Issues confirmed by a committer database
Projects
Archived in project
Development

No branches or pull requests

2 participants