Practicing Version Recognition Technology in Critical Devices

This article was first published on our team’s. Click here to read the Chinese version. https://mp.weixin.qq.com/s/k74R7FcWcjIBqLJa0eTwRg

Introduction

Those who pay attention to security consulting may have noticed that when a certain device has a vulnerability, we often see reports such as “a certain device has been hacked” or “a certain vulnerability affects a large number of devices” and so on.

However, we know that the scope of the vulnerability is actually closely related to the version of the device. So how do these reports quickly determine the scope of the vulnerability? Especially for those devices that do not clearly show version information, how to quickly determine its version has become a key issue.

Based on this background, this paper will delve into the key technical issue of version identification. By drawing on and summarizing the practical experience of industry experts, we will focus on the version identification technology of a number of mainstream devices, including Citrix, CiscoRV and Flytower. In this paper, we focus on analyzing those key devices that do not have explicit version information, and explore how to accurately determine their running versions through indirect methods, so as to provide an important reference for the assessment of the scope of vulnerability impact.

Technical Practice Analysis

In this paper, the following three technical approaches are mainly used in device version identification:

• Based on HTTP response header analysis: analyze the Last-Modified header information returned by the device and compare it with the release time of the known version to determine the version.
• Configuration file parsing: accessing and analyzing key configuration files of the device to directly obtain version information.
• Static Resource Characterization: Collect and compare the static resource hash value and path characteristics of the device to determine the version.

Each of these methods has its own advantages and disadvantages: the timestamp-based method may be biased due to file modifications, and configuration file parsing, although highly accurate, requires higher access rights. Therefore, it is usually necessary to combine multiple methods to improve the accuracy of version identification in practical applications.

Device Example Study

Citrix Device Version Identification

Citrix ADC and Citrix Gateway are important networking products from Citrix that are widely used for internal and external application access in organizations. In the current Internet environment, external attackers have become a common security threat by exploiting vulnerabilities in targeted systems and products.

Since Citrix ADC and Citrix Gateway products do not display clear version identification externally, this poses a challenge for testers to perform version fingerprinting. However, we can obtain the version information of these two products through the following technical means:

First, the last modification timestamp in the system file attributes can be utilized for version determination. Since there are intervals between the release of different versions of Citrix products, the file modification time can reflect the approximate version range of the products.

Second, a version feature library can be built by collecting the static file hash values of each known version of Citrix products. When testing, we only need to obtain the file hash value of the target system and compare it with the feature library to deduce the specific version number.

Finally, in Citrix Gateway products, certain configuration files will write their own version information into them, and we can determine the version information by parsing certain key configuration files. For example, by accessing a specific configuration page or API interface, the version identification can be extracted from the response. This method requires higher privileges, but can get the most accurate version information.

We first set up the Citrix environment locally by entering the system and executing the command grep -R “13.0.47.24” /var/netscaler/ -name “*.xml”. With this command, we found the current product version information in the /vpn/pluginlist.xml file.

/vpn/pluginlist.xml is an XML-formatted configuration file in the Citrix Gateway product that contains information about the list of plugins enabled by Gateway.

When Citrix Gateway is deployed as a VPN gateway, it needs to load various plug-in modules to handle functions such as VPN connectivity, authentication, and policy control. Configuration information such as the enabled status and load paths of these plug-ins are stored in the pluginlist.xml file, so we can access this file to obtain version information.

When analyzing the HTTP responses of Citrix ADC and Gateway, we found that in addition to the above interfaces, when requesting the specific URI “/vpn/index.html”, the HTML response body contains a string value similar to an MD5 hash, which is appended to the URL of the page resource in the form of the parameter “?v=”.

To explore the significance of this version hash, we collected and extracted a large number of scan data reports from Citrix products, and found that there are nearly a hundred unique version hashes. In order to verify that these hashes can be mapped to specific product versions, we built our own test environment for Citrix ADC. After simulated access and analysis of the page response, we found that the version hash is a randomly generated identifier rather than a preset static token.

Based on this, we can extract the version hash information from a specific interface, and accurately locate the specific version of the product by parsing the hash value of each historical version.

When Citrix releases products such as ADC and Gateway, it records the last modification time of the file in the file attributes. System components such as executables, configuration files, static resources, etc. will contain Last Modified timestamps. When a user accesses these system files via an HTTP/HTTPS request, the server returns the Last-Modified field in the response header, and the value of this field is the last modification time in the file attribute.

For example, if you access the Citrix ADC administration interface/logon/LogonPoint/pluginFiles.json page, the response headers will contain: Last-Modified: Tue, 05 Apr 2022 10:11:21 GMT This timestamp reflects the last modification time of the pluginFiles.json file. This timestamp reflects the last modification time of the pluginFiles.json file. Similarly, we can request other system files to get their modification times.

By writing a script to batch fetch the Last-Modified times of key system files, we can get a set of time datasets. By comparing this data with the release times of each historical Citrix version, we can match the closest version number.

Although there are limitations in this method - multiple modifications of files may lead to deviations in the time information - it still provides an important reference for Citrix product version identification as a passive way of collecting fingerprint information.

CiscoRV Device Version Identification

The Cisco RV34X series routers are high-performance, secure network devices designed for small businesses. For version identification, we first examined the device’s Web interface code, but were unable to find an obvious version identifier.

Last-Modified is a key field in the HTTP response header that identifies when a resource was last modified. By analyzing the RV34X series firmware, we found that the last-modified time of the three CGI files exactly matches the release time of the firmware. So, can we determine the specific version of the target device by directly accessing these CGI files and obtaining the Last-Modified value?

In order to verify the correlation between Last-Modified headers and firmware versions, we tested the Last-Modified headers on the /cgi-bin/blockpage.cgi files of multiple devices and checked them against known firmware versions. The test results confirm that the headers partially reflect the device’s firmware version. Based on this finding, we created a version mapping table that corresponds Last-Modified dates to specific firmware versions, as shown below:

CISCO_RV34X_VERSION_MAP = {
  "2022-10-17": "1.0.03.29",
  "2022-06-14": "1.0.03.28",
  "2022-03-08": "1.0.03.27",
  "2022-01-06": "1.0.03.26",
  // 省略
  }
 

Using this mapping relationship, we are able to quickly determine the corresponding firmware version from the Last-Modified header information returned by a remote device, thus realizing remote version identification.

Fortinet Version Recognition

The Fetta (Fortinet) Firewall is a high-performance, multi-functional network security product from Fortinet that uses a unified threat management (UTM) solution accelerated by a dedicated security processing chip.

We have collected as much of Fita’s firmware as possible to build a complete repository.

In newer versions of the Feta Firewall, the page’s static resource loading path exhibits unique characteristics. Specifically, the path contains a random hash value. The existence of this hash value makes the static resource loading path of the page with high uniqueness. By analyzing the code of the page, locating the loading path of the static resources, and then extracting the hash value, it can be used as an important basis for judging the newer versions.

For older versions of Feta Firewall, the paths for loading static resources on the page are significantly different from the newer versions. The paths of these earlier versions do not contain random hash values, but rather a simple string of numbers. Although this string of numbers is less complex to characterize than the hash value, it can still be used as a reliable version identifier. By comparing the path characteristics on the page with known version information, we can accurately determine if the firewall is an earlier version.

Earlier versions of the Feta Firewall are unique in their page characteristics. Its static resource links do not contain obvious path features, but instead use a string of numbers as parameters. This type of parameter passing is more common in earlier versions (3.x). By analyzing the numeric parameters of the static resource links in the page, we can determine whether the firewall belongs to one of these earlier versions.

Through these studies we found that there are significant differences in page characteristics, static resource loading methods, and parameter passing between different versions of the Feta Firewall. These differences not only provide us with reliable version identification markers, but also reflect the technological evolution of Feta products at different stages of development. Combining these features, we can build a relatively complete version identification methodology, which provides important support for device security assessment.

Summarization

In this paper, we explored the version identification technology practices of three mainstream devices (Citrix, CiscoRV and Fetta). By analyzing information from multiple dimensions such as HTTP response headers, static resource features, page hash values, etc., we successfully constructed a set of reliable version identification methods. These methods not only provide important support for vulnerability impact scope assessment, but also provide valuable technical references for the research field of device security.

References

• https://cybernews.com/security/fortinet-hackers-maintaining-access-despite-patches/
• https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-activity