Recently I downloaded the new Windows server 2019 and upgraded my Win10 box to 1809.

Obviously, the first thing I did was to test the juicy/rotten exploit and surprisingly it did not work on both OS (tried aslo with other CLSID’s)

Remember what MS said about this “vulnerability”? Fear the Rotten/Juicy potato attack?

So I’m not sure if they patched it or some strange unintended behavior?

Probably something related to the OXID resolver, it seems like some checks in place before calling the resolver:

 

By omittimg the port in the RPC bindings string (“host” instead of “host[port]”)  in the IstorageTrigger::MarshalInterface method – where port is our local listener port specified with -l switch – connection does not get dropped and normal flow continues.

But DCOM won’t talk to our local listener, so no MITM and no exploit.

Note:   if you put the default port in the RPC bindings “host[135]” connection gets dropped  again. You cannot  specify ports, only hosts (local ore remote…)

Probably MS changed something in the rpcss.dll, version and size differs from previous builds.

 

That’s all for now, I will update this posts with as soon as I have news!

Update 2:

So MS “fixed” , maybe in an unintened way,  this exploit by checking the port specified in the RPC binding strings.

Ok, so why not sending the packets to a host under our control,  listening on port 135, and then forward the data to our local COM listener? Because we can specify a host different than localhost in the RPC bindings string, we only cannot specify the port…

This is what I tried but no luck, “LOGON DENIED”. Why? because in this case the client will not  negotiate a Local Authentication, which is fundamental for the NLTM reflection attack, given that host is remote.

A packet capture with rawcap.exe  on loopback interface confirmed my assumptions.

In order to negotiate a Local Authentication  the client has to provide these information in the NTLM type 1 message:

• Negotiate Domain flag
• Negotiate Workstation flag
• Supply Workstation Name
• Supply Workgroup Name

 

And these characteristics were obviously missing.

So i tried something very dirty by modifying the NTLM type 1 message before sending it to the RPC listener.

I set the flags, added the the computer/workgroup name and modified the message lengths and offsets of the NTLM and DCOM packet according to my manipulations.

But no luck again because it is the client which will decide the local authentication during the first call to InitializeSecurityContext()  using  his own handle which is not under our control.

Nothing to do!