Commenting out tls.sendall(bytes(magic, "utf-8")), gives same 'result'

[brizzbane]

of printing the supposed socket that shows 'success' ....

[0xh4di]

use python3

[brizzbane]

I am. The point I am making removing the supposed sending of the shellcode, you will get the same result as with it.

[terrafying]

read the source...

[brizzbane]

I did.

It looks to me like what he is printing out in the readme:

[ + ] <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('192.168.137.1', 64251), raddr=('192.168.137.201', 3389)>

is the socket that is initially created for starting the exploit (i.e. line 297). Which has nothing to do with a payload actually being sent.

This can be confirmed by commenting out any lines that have anything to do with sending payload/shellcode.

@terrafying, or the author, I'd love to see a screen cap of an actual connect back (using this code)--if by "read the source..." you mean you have it working.

[terrafying]

Oh i interpreted what you said wrong, then. That's exactly what it does; the print is kinda meaningless. Anyway, all I can do is BsOD it by sending tons of garbage in that last packet.

[terrafying]

Also I don't get what the author even means by using the unicorn framework, which gives you powershell output that would be used to inject shellcode into memory, which is what we're already doing.

[algo7]

Also I don't get what the author even means by using the unicorn framework, which gives you powershell output that would be used to inject shellcode into memory, which is what we're already doing.

This vulnerability could execute arbitrary code on the target system, I was using the unicorn framework to do the job. That's all, nothing special.

[algo7]

Research Needed

[terrafying]

So you're saying kernel pool/heap spraying isn't a thing?

[algo7]

It is.

[je6k]

Have you successfully executed any code?

[algo7]

I have tried to supply the code through both plaintext and various encoded versions. No luck so far.

[GossiTheDog]

It won't ever work as you need to spray etc, you can't just paste in shellcode.

[algo7]

So far, I probably don't posses the skill of doing so. However, I'll do some research on this topic. Thanks for your guidance.

[brizzbane]

I messed w/it for several days...and yea, from what I read--you aren't going to get anywhere pasting shellcode. Regardless if its encoded correctly etc. I think the shellcode has to be specifically crafted for THIS vulnerability ...so that it 'hits' (I'm super newb), the right process/dll/whatever that the exploit has granted it access to.

I think just sending the shellcode puts it in memory (maybe), but doesn't really do anything with it. I took n1xbyte/CVE-2019-0708, update, and looked at his code....looked at the differences between x32 bit and 64 bit, took what was the 'same', and then added the shellcode on to that--hoping maybe he had some idea what he was doing, and the beginning of that code was hitting what it needed to...

but anyways, I guess my point is, ...theres a good chance you probably need to know what you are doing (beyond programming skills), to be able to take advantage of the exploit and get a shell.

[edit]

also, you do:

tls.sendall(bytes(allpacl2, "latin-1"))

and then info(results) (line 411), which is still defined as the socket that was created to start executing the original code, line 302: results = socket_connection(tpkt.getData(), ip, receive_size=1024)

(Which really doesn't tell you anything).

In the original POC, it suggests doing something like, results = tls.sendall(bytes(allpacl2, "latin-1")), and then printing out THAT 'results', so you can get the actual response of what you just sent...

but to avoid confusion, imho, I'd do something like:

my_test = tls.sendall(bytes(allpacl2, "latin-1"))

or whatever. Use another name other than results. You have line 412 commented out, but if you would do results = tls.sendall, ...then when it trys to close the socket (line 412), it's no longer referencing the socket, and you'll get an error saying something about a string.

[algo7]

I messed w/it for several days...and yea, from what I read--you aren't going to get anywhere pasting shellcode. Regardless if its encoded correctly etc. I think the shellcode has to be specifically crafted for THIS vulnerability ...so that it 'hits' (I'm super newb), the right process/dll/whatever that the exploit has granted it access to.

I think just sending the shellcode puts it in memory (maybe), but doesn't really do anything with it. I took n1xbyte/CVE-2019-0708, update, and looked at his code....looked at the differences between x32 bit and 64 bit, took what was the 'same', and then added the shellcode on to that--hoping maybe he had some idea what he was doing, and the beginning of that code was hitting what it needed to...

but anyways, I guess my point is, ...theres a good chance you probably need to know what you are doing (beyond programming skills), to be able to take advantage of the exploit and get a shell.

[edit]

also, you do:

tls.sendall(bytes(allpacl2, "latin-1"))

and then info(results) (line 411), which is still defined as the socket that was created to start executing the original code, line 302: results = socket_connection(tpkt.getData(), ip, receive_size=1024)

(Which really doesn't tell you anything).

In the original POC, it suggests doing something like, results = tls.sendall(bytes(allpacl2, "latin-1")), and then printing out THAT 'results', so you can get the actual response of what you just sent...

but to avoid confusion, imho, I'd do something like:

my_test = tls.sendall(bytes(allpacl2, "latin-1"))

or whatever. Use another name other than results. You have line 412 commented out, but if you would do results = tls.sendall, ...then when it trys to close the socket (line 412), it's no longer referencing the socket, and you'll get an error saying something about a string.

Thanks for your information. It is not an easy task. I am working on several different version of this PoC, and it's easy to confuse between each of them. I will refine my code and see what the actual response is. Much appreciated.

[Dimanp00]

Some additional techinacl details about this CVE https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html

[0x0kasaku]

I have used the unicorn to generate my own shellcode, and use the msf to listen the port. The poc is running successfully, but i don't get the reverse shell !!! Can you help me ?

[brizzbane]

@0x0kasaku, the POC is not running successfully. Even though it informs you that it is 'infected', indeed, it is not.

[algo7]

@0x0kasaku, the POC is not running successfully. Even though it informs you that it is 'infected', indeed, it is not.

info(infected) is executed through the execution of the program. However, at this stage, it does not indicate the success of the exploit. I would comment it out to avoid confusion.

[algo7]

I have used the unicorn to generate my own shellcode, and use the msf to listen the port. The poc is running successfully, but i don't get the reverse shell !!! Can you help me ?

This is not some simple exploit templates where you can just pop in your payload and expect it to work. We are still researching the correct method of delivery, and please (x10) do some research yourself before posting comments like "It doesn't work". Script kiddies looking for easy exploit is not welcomed.

[rwhitcroft]

People are confused because you're contradicting yourself.

The README literally says "working shell code", but that's wrong. Then you said you have to generate your own payloads with unicorn, which is also wrong. Then when you run the code, you get the "infected" message, which is meaningless because there's no check for success.

[algo7]

People are confused because you're contradicting yourself.

The README literally says "working shell code", but that's wrong. Then you said you have to generate your own payloads with unicorn, which is also wrong. Then when you run the code, you get the "infected" message, which is meaningless because there's no check for success.

Apology for causing confusions. the README has been updated and the "info(infected!)" which was used as a programming trace was also removed.