“String substitution” refers to when text characters are substituted with those of another type. It occurs when an application anticipates inputs from users, but instead receives malicious payloads, which causes the application to behave unexpectedly. As a result of this, string substitution defects are referred to as string substitution flaws or string substitution vulnerabilities.
Major String Substitution Vulnerabilities
There are a couple of vulnerabilities that can be exploited as a result of the string substitution aspect. Let’s have a look at a couple of these.
Log4j
Log4j is a zero-day software vulnerability in Apache Log4j 2, a widely used Java library used for logging requests. Log4j allows an attacker to gain control of a server that is running a certain version of the Log4j library. To exploit this vulnerability, the attacker may use the payload in name, email address, password, or anything else that is being logged. As soon as the strings are logged, it gets interpreted by the Java library, executing the payload or commands. This aids the attacker in gaining remote access to the computer system.
Data logging is governed by the Log4j 2 library. An attacker can exploit this issue to take control of a string and deceive the server into requesting and executing malicious code, which might compromise the whole server or the infrastructure. Remote control of any internet-connected service that supports specific versions of the Log4j library is made possible as a result of this vulnerability.
Remote Code Execution (RCE)
RCE occurs when unsanitized user inputs are immediately transmitted to system commands without being processed before. Most of the time, this occurs when the application makes use of some of the system functions, such as the sys function in PHP. The user can manipulate user inputs and substitute them with malicious commands that then get executed on the server side.
Attackers can cause a great deal of damage with the RCE, including downloading a webshell, building a backlink to a machine, and compromising the entire server as well as the organization’s infrastructure.
There are several possibilities for an attacker to gain access. They might look for vulnerabilities in the framework used by the application or use an already well-known exploit to achieve RCE on the system. As a result, system command functions should only be utilized in a sandboxing environment, or input validation should be performed to all user inputs in the majority of cases.
Local File Inclusion (LFI)
LFI is a vulnerability that allows an attacker to include files on a server by using a web browser to do so. An attacker can modify the input path traversal characters such as ../(dot dot slash) sequences, which includes other files from the web server. In LFI, the attacker aims to access files and folders that are outside the web-root folder. By exploiting an LFI vulnerability, an attacker can gain access to arbitrary files and directories on the file system, including the application source code or configuration.
It is possible for an attacker to pass malicious inputs as defined above (../) to access sensitive files on the server when the application is accepting user inputs to access files on the server. This is because the user inputs are controlled directly by the user and there is no sanitation of the inputs. This vulnerability can be abused in a variety of ways, including utilizing php wrappers and encoding the file path. Hence, it is always recommended that user inputs be sanitized before being processed by the application.
Conclusion
String substitution vulnerabilities are a threat to an organization, and they have the potential to do unanticipatable harm to the business due to the high severity of these vulnerabilities. Thus, it is usually recommended to sanitize user inputs before processing them and to perform whitelisting to user inputs or to files that can be accessed by a user.
