NETGEAR ProSAFE NMS MFileUploadController Vulnerability
Netgear ProSAFE Network Management System NMS300 is a centralized and comprehensive management application for network administrators that enables them to discover, monitor, configure, and report on SNMP based enterprise-class network devices. The Netgear Network Management System NMS300 delivers insights into the network, including third-party devices and its web-based user interface makes it easier to monitor and administer an entire network.
This vulnerability allows remote attackers to execute arbitrary code on affected installations of NETGEAR ProSAFE Network Management System 126.96.36.199. Authentication is not required to exploit this vulnerability. The specific flaw exists within the MFileUploadController class. The issue results from the lack of proper validation of a user-supplied path, prior to use in file operations. An attacker can leverage this vulnerability to execute code in the context of SYSTEM.
This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-27274.
Common Vulnerability Scoring System (CVSS):
The overall CVSS score is 8.6 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C).
Base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), based on the following metrics:
• Attack vector is network.
• Attack complexity is low.
• Privileges required is low.
• Privileges required is low.
• User interaction is none.
• Scope is changed.
• Impact of this vulnerability on data confidentiality is high.
• Impact of this vulnerability on data integrity is high.
• Impact of this vulnerability on data availability is high.
Temporal score is 8.6 (E:U/RL:O/RC:C), based on the following metrics:
• The exploit code maturity level of this vulnerability is unproven.
• The remediation level of this vulnerability is official fix.
• The report confidence level of this vulnerability is confirmed.
Attack Packet Overview:
The Content-Type header line contains the following:
- “multipart/form-data” – Data is in multiple parts. Defining separated parts by the boundary keyword.
” – Separating keyword or sequence of characters.
The Content-Disposition header line contains the following:
” – name of form element being returned.
- “filename=” – Suggested file name to be used if detached and stored in a separate file.
A user with the “observer” privilege can manage the MIB config files via the “mib browser” page in the NMS300 web interface to upload a MIB config file. A request to the Request-URI “/lib-1.0/external/flash/MfileUpload.do” will be sent to the server to upload a MIB config file.
The MIB file content is transferred in a multipart/form-data part within the HTTP message body, and the filename parameter within the Content-Disposition header specifies the name of the file. The uploaded file will be saved into the following directory:
Where the “Install_Dir” is where the NMS300 is installed, and the “filename” is the filename parameter within the Content-Disposition header in the multipart/form-data part. The “type_dir” and “sub_dir” are derived from mapping the value of the type and sub request parameters to various sub-directory names. This mapping is specified in the file “resource.properties” which has the following contents:
For example, if the type parameter value is “mib”, the “type_dir” is “WEB-INF/mibs/Customized/”; if the sub parameter value is “4”, the “sub-dir” is “Switch/”. Therefore, the nms300_mibpath for the uploaded MIB file in the above example is:
If type and sub parameters are omitted or contain empty value, the “type_dir” is assigned as the string “null” and the “sub_dir” is assigned as the empty string “” in the application. Therefore, the nms300_mibpath for the uploaded MIB file will be a string as below:
An unrestricted file upload vulnerability exists in the NETGEAR Management System NMS300. The vulnerability is due to a failure to validate the file type of the uploaded file. When the server receives the HTTP POST request with Request-URI containing “/lib-1.0/external/flash/MfileUpload.do”, the method uploadFile() in MFileUploadController class is executed. This method retrieves the values from the type, sub, and filename parameters in the request and then uses them to build the nms300_mibpath for the uploaded MIB file. Then, the uploadFile() method writes the uploaded file content into the nms300_mibpath. Then, the uploadFile() will call the parseNewMIB() method of the MibLoader class to parse the uploaded MIB file. If the uploaded file is not in the format of a MIB config file, the
parseNewMIB() will throw exceptions and cause uploadFile() to delete this uploaded MIB file
However, the uploadFile() does not sanitize the filename parameter for dangerous file extension type. Also, it does not validate the type and sub parameter. If type and sub parameters are omitted or contain empty value, an attacker can upload a malicious JSP file with the filename parameter like “poc.jsp” and then the file will be saved in a nms300_mibpath as below:
Because uploadFile() will delete the uploaded file if it is not a MIB config file, the attacker must try to pass this checking. The attacker can achieve it by embedding the malicious JSP code inside the comment lines of a normal MIB config file, as shown in the example below:
Where the comment line starts with “–” and the JSP codes follows. This makes the uploaded JSP file kept on the server without being deleted. Later, due to the files under the directory “/Install_Dir/apache-tomcat-6.0.33/webapps/ROOT/” can be remotely accessed without any restriction via HTTP requests, the attacker can submit a subsequent request with an URL as below:
and get the uploaded JSP file executed on the target server, which can cause arbitrary code execution.
Note that, beginning from NMS300 version 188.8.131.52, authentication has already been required to access the URI “/lib-1.0/external/flash/MfileUpload.do”. Therefore, in general, an attacker must authenticate to the server to exploit this vulnerability. Unauthenticated attack can only be applied to servers older than version 184.108.40.206.
A remote attacker could exploit the vulnerability by sending crafted HTTP requests to the target server. Successful exploitation would result in the code execution under the security context of SYSTEM.
Triggering the Problem:
• The target system must have the vulnerable product installed and running.
• The attacker must have network connectivity to the affected ports.
• The attacker must authenticate to the target system.
The attacker authenticates and then sends an HTTP request containing crafted parameters to upload a malicious file to the target server. The vulnerability is triggered when the server processes the request.
The following application protocols can be used to deliver an attack that exploits this vulnerability:
• HTTP, over port 8080/TCP
SonicWall’s, (IPS) Intrusion Prevention System, provides protection against this threat:
• IPS 15572: NETGEAR ProSAFE MFileUploadController Arbitrary File Creation
The risks posed by this vulnerability can be mitigated or eliminated by:
• Blocking the affected ports from external network access if they are not required.
• Upgrading the product to a non-vulnerable version.
The vendor has released the following advisory regarding this vulnerability: