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
Solve #5092: Add module to exploit dangerous group policy startup scripts #5125
Conversation
looks like i can kill that gentoo ebuild :-) for fake gem badsamba |
* So bind payloads also work
This pull request, now also adds @hmoore-r7's feedback. Introduces the
|
Just curious, any reason to use a VBS versus EXE for this? |
Looks like the SMB filename parameter is being misparsed in the mixin: |
Should switch on the extension and provide an exe/vbs/ps1 payload depending on the request? |
def setup | ||
super | ||
self.file_name = datastore['FILE_NAME'] || "#{Rex::Text.rand_text_alpha(4 + rand(3))}.vbs" | ||
exe = payload.encoded_exe |
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.
This will never get used because of the regenerate_payload
. If it did, it would be wrong, because client-side modules should always call regenerate_payload
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.
on every on_client_connect
the payload is regenerated for the client, it is just an initialization. I used this initialization because indeed the encoded payload should be good enough when reverse payloads are used, shouldn't be?
So yup, just initializing things. But I can avoid initialization if you think it is more correct.
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.
Probably no reason to initialize it at all, since it will not be used.
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.
Right, it's getting generated here and then never used; wasted cycles. I would remove this line and the next.
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.
snif :-( I like to initialize things. But that's okey. I can delete initialization. I won't fight all of you =) proceeding!
Test after last commit:
|
@hmoore-r7 asked:
Because GPO supports VBS and PS initialization scripts. Used VBS to port the BadSamba technique. From the GPO options I would say it shouldn't support an EXE directly as initialization script. but Windows can be an "obscure" system and I didn't try really.
Yeah, the parsing isn't super good (or good at all) (see |
After doing 100 tests with @wchen-r7 (thanks a lot for helping with testing it!) we're having problems to make it work on a Fresh Windows 7 SP1 install after just adding the startup script to the group policy. Maybe some configuration missing, but I'm unable to solve it, so marking as delayed until I can answer exactly what's going on. |
I recovered testing this night. Several minutes after logging in the fresh windows 7 SP1 I got it:
I'm going to share / ask pcap's with @wchen-r7 see if I can figure out what's going on and finally fix. |
Did a couple of changes to the SMB handling, including a better parsing of the PATH in NT_CREATE_ANDX requests, as pointed by @hmoore-r7 Anyway I think the problems we are finding aren't related to the smb communication but to the execution of GPO policies on the windows side. So. First thing. On windows 7 SP1 I've noticed Windows defender goes into action. So my first recommendation is to disable the Windows Defender service to be sure it isn't killing the payload. After disabling Windows Defender I've noticed "System Startup scripts" aren't executed most of the times (I don't get SMB traffic neither :?). In order to mitigate testing with "Logon scripts" looks more reliable. Logon scripts are executed once the user logs in in his session, and are executed with user privileges (instead of system privileges). So in order to test:
With "Logon startup" scripts, which are more reliable on my case, after login, it's what I get in the console:
|
One more note, parsing and execution of startup scripts can be started manually with In this way should be easier to monitor with sysinternals and get network pcap's if everything else fails still. So hopefully I can debug what's going on and make fixes if it's a msf code fault. So if with the verification steps above there aren't sessions with Startup, neither logon scripts, we can use this method for verification / debug. When forcing startup scripts to run manually I'm getting sessions every time. See if everything helps to see what is going on! :) |
I will try again. |
Provides module to fix #5092.
Instead of BadSamba uses
Msf::Exploit::Remote::SMB::Server::Share
to make it easy :)Verification