RTF url issue

[MSisfuckedupmanimaginepayingtogetRCEd]

Hey, so I was playing around with this POC and I was trying to get a .rtf to pull the .html from a VM that wasnt the one executing the maldoc. So I tried using the -u option but I noticed that it was still contacting http://localhost:80/exploit.html, even when the local server didnt even start. To solve the issue I tried to mess with the rtf template and I noticed that there were 2 http://localhost:80/exploit.html instances, one generated by the {payload_url} in the py code and one hardcoded (to find it: ctrl + f > http://lo). The weird thing is that even by changing both urls to the ip I was trying to contact the .rtf still performed GET requests to localhost. Am I missing something obvious here?

Steps to reprodude the issue: 1) python .\follina.py -t rtf -m command -c "Start-Process cmd.exe" -u https://google.com 2) python .\follina.py -t docx -m command -c "Start-Process cmd.exe" 3) open the .rtf A GET request will be logged and cmd.exe will start even tho I doubt that google is hosting exploit.html lol

[chvancooten]

Hey @MSisfuckedupmanimaginepayingtogetRCEd! Nice username :)

Thanks for your great issue. I was able to replicate this issue, and track it to the fact that the payload location is also saved as a hexadecimal object within the RTF file itself (both in UTF-8 and UTF-16-LE, and with and without port). To find these objects, look for 6c6f63616c68 and 6c006f00630061006c0068006f0073007400 respectively.

Unfortunately, I tried using the same method to replace these objects in the template file, but failed miserably. It unfortunately looks like there is some kind of checksum in the OLE object that prevents it from being changed easily.

I ran out of time for tonight so will leave this issue open for now. @DanusMinimus, it would be great if you could take a look at this and see if you can get it to work! If we can't figure it out, I would propose to limit RTF generation to the default URL only for testing purposes (even though that's a bit lame...).

[ghost]

rtf option is not working the command is not replicated on the exploit.html. the default command is still there.

[honeyfairy]

Hey @MSisfuckedupmanimaginepayingtogetRCEd! Nice username :)

Thanks for your great issue. I was able to replicate this issue, and track it to the fact that the payload location is also saved as a hexadecimal object within the RTF file itself (both in UTF-8 and UTF-16-LE, and with and without port). To find these objects, look for 6c6f63616c68 and 6c006f00630061006c0068006f0073007400 respectively.

Unfortunately, I tried using the same method to replace these objects in the template file, but failed miserably. It unfortunately looks like there is some kind of checksum in the OLE object that prevents it from being changed easily.

I ran out of time for tonight so will leave this issue open for now. @DanusMinimus, it would be great if you could take a look at this and see if you can get it to work! If we can't figure it out, I would propose to limit RTF generation to the default URL only for testing purposes (even though that's a bit lame...).

A workaround is to generate the docx file with the custom url and open in Word and save as RTF. Tested and working.

[DanusMinimus]

Hello, I will check the issue as soon as I get home

[DanusMinimus]

When I generate an RTF file with a custom URL (using the version within this repository) I dont see a server starting on local host or a hardcoded value within the RTF.

Generation message -

New URI within the template

No hardcoded "local" string found

Also I see no outbound connection being made to the localhost

I am unable to re-create the issue @MSisfuckedupmanimaginepayingtogetRCEd

[chvancooten]

Hey @DanusMinimus, that appears to be incorrect. When I use the exact same command to generate the RTF I get the following hex data showing (twice) in the objdata field:

As @honeyfairy noted it does encode correctly when "Saving As" from the Word format.

[chvancooten]

Hey @MSisfuckedupmanimaginepayingtogetRCEd - this issue is addressed in the latest PR by @DanusMinimus. Could you do some testing with that?

[chvancooten]

Fixed in #26