-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Exploits MS13-005 - Low Integrity to Medium Integrity Local Priv Esc #2162
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
Conversation
Processing! |
First test has not been successful
The process is indeed low integrity: Was a "blind test", now digging into the code, etc, etc. |
|
||
register_advanced_options( | ||
[ | ||
OptBool.new('EEGG', [false, 'Anderson command technique',]) |
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.
Don;t think its neede for the exploit, is it?
Main issues with running this test is: You can disable SPAWN_PROMPT and create a cmd prompt yourself to see if the broadcast messages are being captured. If they aren't your machine isn't vulnerable! I guess I could do an md5 check on the appropriate dll or version and implement check |
And it's what happens when running the integrity check from an IE low integrity process (notice the Low subdir):
Indeed:
When the intended test is:
So this test doesn't look useful for IE, working on it.... |
Doh... WE could just expandpath and look if the tempdir ends in Low, hmmm doesn't work. |
Hi @Meatballs1, I've tried to address the thing on Meatballs1#6 Mainly:
Test for the FILESYSTEM option:
The new 1104 process is indeed MI: Feel free to review, test discuss anything. Once it's handled I guess we'll be ready to land this one! :) thanks! |
Thanks @Meatballs1 , landing! |
not still :P giving time to @Meatballs1, work on progress on his side! :) |
I tried mutli railgun call but currently Meterpreter crashes - I cant find any examples anywhere at the moment of this in use?. Theres also a bug in that the multi handler doesn't handle 'CONSTANTS'. I've added 3 technique options: Currently the powershell command line did not work in my environment - I need to check on this... [Edit] Just retried it and it worked fine... Importing the Powershell library it is obvious that some of the datastore options are ambiguous (e.g. PERSIST) so I have added PSH:: infront in a similar fashion to EXE:: to give them some provenance |
@@ -8,9 +8,9 @@ def initialize(info = {}) | |||
super | |||
register_options( | |||
[ | |||
OptBool.new('PERSIST', [true, 'Run the payload in a loop', false]), |
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.
Is anyone (module/mixin) using this option. Can you just rename it without other code modifications :?
If it's the case I ask myself if this datastore option is really needed, just asking :)
(Same happens with PUSH_OLD_METHOD and RUN_WOW64).
On the other hand, if further code modifications are needed to change it, please don't change it in this pull request. Try to not modify mixins and/or libs when doing a pull request for add a module. It's easier to handle modules out of mixins/libs/core changes.
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.
As far as I'm aware the only module using it at the moment is smb/psexec_psh:
grep "Exploit::Powershell" agrees!
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.
And the same mixin doesn't use the datastore options :?
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.
The Exploit::Powershell mixin I mean
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'm not sure I understand the question?
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'm sorry, trying to explain better. The Exploit::Powershell mixin is accessing datastore['PERSIST'], datastore['PSH_OLD_METHOD'] and datastore['RUN_WOW64']. My question is, are the old options names compatible with the new PSH::PERSIST, PSH::OLD_METHOD and PSH::RUN_WOW64? If not, I guess the code from the Exploit::Powershell mixin should be modified to use the new options names.
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.
Doh, yes I'm being daft
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.
Okey, I can land this change in this pull request. But please, in the future, when changing libs/core code use a different pull request than the one adding a module. It's a perfect example, where a core mixin is being modified, and this modification can be handled independently of the mode addition. Just to have into account in the future, please :)
#2075 addresses the powershell stuff... we're currently running into the mismatch from using an old codebase for all of this. I keep running into this whenever i want to write something for framework trunk using PSH since that PR contains a slew of methods for working with it. |
Processing, the TYPE attack vector is taking a really long time, more than I expected. Will update in a while, giving the chance.... |
After all.... the TYPE method didn't work here:
On the CMD:
BTW: In case could be related, it took really a long time to broadcast the full command! |
OptBool.new('PERSIST', [true, 'Run the payload in a loop', false]), | ||
OptBool.new('PSH_OLD_METHOD', [true, 'Use powershell 1.0', false]), | ||
OptBool.new('RUN_WOW64', [ | ||
OptBool.new('PSH::PERSIST', [true, 'Run the payload in a loop', false]), |
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've been reviewing other mixins using these type of names for datastore options. As far as I've checked there isn't an strict naming style for these type of options. I find:
- UPPERCASE::CamelCase
- UPPERCASE::snake_case
But never UPPERCASE::UPPERCASE. I'll be switching them to UPPERCASE::snake_case if anyone stops me, since snake_case is preferred for naming variables on ruby.
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.
Its probably best if I revert these changes from this module, and these comments should apply to #2075 ?
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.
Agree, it's probably better if you could revert these changes from this pull request. Indeed they aren't needed for the module to work.
About the TYPE method, getting the command line, stopping the exploit, starting a handler and typing the command line on a Windows CMD manually, works:
So, maybe, is the exploit handler / task finishing before the payload "can be delivered" by using the TYPE technique. Is it working on your tests @Meatballs1 ? Thanks! juan |
Ah last thing I tried was windows/exec CMD=calc.exe as it would be quicker than Meterpreter. I guess this issue should be resolved the same route that is decided for #2156 |
@Meatballs1 agree with your last comment, trying with windows/exec CMD=calc.exe |
Bah that reverted more than I wanted to! I've got myself into a gitloopofdoom(tm) |
Ok cleaned out my PSH changes. Is there an executive design decision on how to handle 'indefinite' waits? I would like to see about speeding this up with railgun multicall but it seems completely unfunctional at the moment. The alternative would be to hardcode a meterpreter method that takes a string and HWND_BROADCASTS it all for you :) |
Is there an executive design decision on how to handle 'indefinite' waits?
I'm still trying the windows/exec payload .... taking the live again to deliver the CMD. I really don't thing the TYPE option with powershell encoded payload is very useful atm, but still likes the custom command option, so testing. If calc.exe spawns it's okey for me to land. I just will add a warning message to show when people use the TYPE exploitation method. It takes longer time than I thought indeed. |
Okey, fisnished and works, testing "old" methods, adding a warning message when using the TYPE technique with a payload, and proceeding with landing if all work as expected :) |
FILE Method tested successfully, now giving a chance to the WEB one:
|
Also the WEB one:
Thanks @Meatballs1 , landing! |
Landed, just small cleanup here: 3a05993 warning message about long wait times for the user, and make msftidy compliang, thanks @Meatballs1 for an awesome exploit! |
For completeness the easter egg I wanted: http://www.youtube.com/watch?v=yYmg7YX-YY0 :) Cheers for putting up with all my dithering @jvazquez-r7 |
Tested on IE8-Win7 VM from: http://www.modern.ie/en-US/virtualization-tools#downloads
Its pretty fun to watch: http://www.youtube.com/watch?v=Vw8ylvTOlBQ
Also tested on the Vista but that doesn't support the spawning of a shell as no shortcut so the only attack vector there is if the victim spawns a cmd prompt (or powershell) for you.
To test:
ProcExp can tell you if a process is medium or low integrity for success.
Possible Improvements:
The low integrity check could possibly be refactored into Post::Accounts? But that's pending in another PR. It would also benefit from being railgunned.
Would the typing go faster if we did a multi railgun call?
Could add an option to just write the whole payload command rather than web download - but you'd definitely want to time this for the small hours of the morning. I expect that'd be better in a separate module? If we're getting in as a low integrity process we probably exploiting IE anyway so have web access...