Fix for arbitrary file write via spider_plus module

[Marshall-Hallenbeck]

Description

The module spider_plus improperly creates the output file and folder path when saving files from SMB shares.

It does not take into account that it is possible for Linux SMB shares to have path traversal characters such as ../ in them. An attacker can craft a filename in an SMB share that includes these characters, which when spider_plus crawls and downloads, can write or overwrite arbitrary files.

This PR resolves #1120

(sidenote: ruff is throwing errors about the line-length: 65000, and I think we already ignore that rule...)

Type of change

Insert an "x" inside the brackets for relevant items (do not delete options)

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Deprecation of feature or functionality
• This change requires a documentation update
• This requires a third party update (such as Impacket, Dploot, lsassy, etc)
• This PR was created with the assistance of AI (list what type of assistance, tool(s)/model(s) in the description)

Setup guide for the review

Requires an SMB share with at least one file to be shared in it.

The PoC for the arbitrary write was shared with me privately; I can provide that to other maintainers for them to test if needed, but the reporter of this vulnerability has nicely not shared the PoC publicly yet.

Screenshots (if appropriate):

Before fix:


After fix:

Checklist:

Insert an "x" inside the brackets for completed and relevant items (do not delete options)

• I have ran Ruff against my changes (poetry: poetry run ruff check ., use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary (new modules or features are required to be added to the e2e tests)
• If reliant on changes of third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects
• I have linked relevant sources that describes the added technique (blog posts, documentation, etc)
• I have performed a self-review of my own code (not an AI review)
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[Marshall-Hallenbeck]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

[NeffIsBack]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

We don't need a new version, I'm just gonna tell them to apply the patches manually.

[Marshall-Hallenbeck]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

We don't need a new version, I'm just gonna tell them to apply the patches manually.

This will probably be CVE'd and we'll need a proper way to differentiate it rather than just a commit hash.

[NeffIsBack]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

We don't need a new version, I'm just gonna tell them to apply the patches manually.

This will probably be CVE'd and we'll need a proper way to differentiate it rather than just a commit hash.

Why should we. This is not a web server where this matters, there is practically no realistic attack scenario. You could likely inject all kind of things into NetExec and with that the OS. This is a security tool doing all kinds of insecure stuff.

[Marshall-Hallenbeck]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

We don't need a new version, I'm just gonna tell them to apply the patches manually.

This will probably be CVE'd and we'll need a proper way to differentiate it rather than just a commit hash.

Why should we. This is not a web server where this matters, there is practically no realistic attack scenario. You could likely inject all kind of things into NetExec and with that the OS. This is a security tool doing all kinds of insecure stuff.

I disagree, the PoC works to overwrite arbitrary files and all you have to do is run the module with download against it. This puts nxc users at risk of having their systems completely nuked.

[NeffIsBack]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

We don't need a new version, I'm just gonna tell them to apply the patches manually.

This will probably be CVE'd and we'll need a proper way to differentiate it rather than just a commit hash.

Why should we. This is not a web server where this matters, there is practically no realistic attack scenario. You could likely inject all kind of things into NetExec and with that the OS. This is a security tool doing all kinds of insecure stuff.

I disagree, the PoC works to overwrite arbitrary files and all you have to do is run the module with download against it. This puts nxc users at risk of having their systems completely nuked.

Yeah but so what. Someone would need to setup a specific kind of file structure and hope that some pentester (or who would you target with that?) run exactly that module against your smb server (who is btw in your internal network lol). Of course there is a risk and it is good that we patch that but the actual risk is diminishing. NetExec is not a service running all the time.

[NeffIsBack]

At that point just hack the internal network on your own, much higher probability on being successful lol.

[Marshall-Hallenbeck]

@NeffIsBack we should probably push a 1.5.1 release and get it on Kali ASAP too

We don't need a new version, I'm just gonna tell them to apply the patches manually.

This will probably be CVE'd and we'll need a proper way to differentiate it rather than just a commit hash.

Why should we. This is not a web server where this matters, there is practically no realistic attack scenario. You could likely inject all kind of things into NetExec and with that the OS. This is a security tool doing all kinds of insecure stuff.

I disagree, the PoC works to overwrite arbitrary files and all you have to do is run the module with download against it. This puts nxc users at risk of having their systems completely nuked.

Yeah but so what. Someone would need to setup a specific kind of file structure and hope that some pentester (or who would you target with that?) run exactly that module against your smb server (who is btw in your internal network lol). Of course there is a risk and it is good that we patch that but the actual risk is diminishing. NetExec is not a service running all the time.

The likelihood is definitely low, but the impact is high and still exists.

[shaaati]

As @NeffIsBack asked me privately for my opinion:

I fully agree with the way that @Marshall-Hallenbeck wants to handle this.

Disregarding any theorizing about attack models and risk awareness when running attack tools, this seems to be a valid security report that should be handled like one.

Users will want to identify whether or not their version is affected and the easiest way to see this is by publishing a bug fix release.

It is perfectly valid to write a release note that also talks about the inherent risk of running security tooling in your environment. However, imho you shouldn't neglect the validity of this report.

[NeffIsBack]

Sure okay.

Then @Marshall-Hallenbeck please:

• Validate that file downloads in various other places have proper checks (could very well be that --get-file is vulnerable to that as well for example)
• Do a bug fix release
• Get in touch with the kali team so the new release is uploaded

[NeffIsBack]

Since we have decided to do a bug fix release for it we should probably communicate it to the public as well once the patch rolled out to kali.