For some reason the existing kernel payload doesn't work with the
exploit as it currently stands, which is very odd given that everything
else seems to be in order.
Hoping to get some help from the rest of the MSF folks as right now
I don't think I can trust the tools that I'm using.
This code is at the point where we SHOULD see a crash (given that the
payloads in use for kernel/user are both just As and Bs (deliberate at
this point).
Unforunately the exploit does not result in a crash. Things just keep
on going! I've looked at the difference in the traffic across the two
different exploits (py and rb) and what's clear is that the mixin is
doing a lot more work at the start.
Also, the mixin generates packets of smaller size in the way that it
encodes data (ie. it doesn't always use 2 bytes for a short value, it'll
use 1 instead if only 1 is required).
Pretty sure that the size issues aren't the problem, I think there's
something else in play. I'm at the point where diving into the RDP stuff
even more isn't inspiring so I'm hoping that opening this up to collab
will help us move forward.
From zerosum0x0:
Exploitation and Caveats:
1. You register with channel MS_T120 (and others such as RDPDR/RDPSND) nominally.
2. Full RDP handshake, I like to wait for RDPDR handshake too (code in the .py)
3. You free MS_T120 with the DisconnectProviderIndication message to MS_T120.
4. RDP has chunked messages, so we use this to groom.
a. Chunked messaging ONLY works properly when sent to RDPSND/MS_T120.
b. However, on 7+, MS_T120 will not work and you have to use RDPSND.
i. RDPSND only works when HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\Winstations\RDP-Tcp\fDisableCam = 0
ii. This registry key is not a default setting for server 2008 R2. SHITTY ISSUE
5. Use chunked grooming to fit new data in the freed channel, account for the allocation header size (like 0x38 I think?). At offset 0x100? is where the "call [rax]" gadget will get its pointer from.
a. The NonPagedPool (NPP) starts at a fixed address on XP-7
i. Hot-swap memory is another SHITTY ISSUE. With certain VMWare and Hyper-V setups, the OS allocates a buncha PTE stuff before the NPP start. This can be anywhere from 100 mb to gigabytes of offset before the NPP start.
b. Set offset 0x100 to NPPStart+SizeOfGroomInMB
c. Groom chunk the shellcode, at *(NPPStart+SizeOfGroomInMB) you need [NPPStart+SizeOfGroomInMB+8...payload]... because "call [rax]" is an indirect call
d. We are limited to 0x400 payloads by channel chunk max size. My current shellcode is a twin shellcode with eggfinders. I spam the kernel payload and user payload, and if user payload is called first it will egghunt for the kernel payload.
6. After channel hole is filled and the NPP is spammed up with shellcode, trigger the free by closing the socket.
TODO:
* You can use the scanner methodology to detect x86/x64, but I'm still not sure how to detect OS, other than XP nominally will not use SSL and 7 will.
* The whole thing needs to be swapped to the Ruby version. Tom Sellers client is nicer and works for XP whereas this python client will not (when I wrote this module it was still in progress)
* Write the XP/2003 portions grooming MS_T120.
* Can we detect if RDPSND grooming is working or not?
* Any channels besides RDPSND/MS_T120 work for the grooming? (I've gone through about 10 books on NT RDP and reversed enough to doubt it)
https://github.com/0xeb-bp/bluekeep .. this repo has code for grooming MS_T120 on XP... should be same process as the RDPSND
The `needs_cleanup` flag needs to be set per-module when an exploit
needs an interactive session to clean up. Some `FileDropper` exploits
need additional cleanup to what the mixin provides, but since all
`FileDropper`s already mark themselves as needing cleanup those are not
covered here. A few of these could potentially be refactored to use the
original exploitation method to clean up or to compile the list of
files/commands to clean up ahead of time, but that is out of the scope
of this fix.
OJ