想象一下,我们在 Windows 应用程序中有以下伪代码:
ShellExecuteA(0, "open", &File, &Parameters, &Directory, 1);
并且,想象一下你可以控制Parameters论点。这是否意味着它可以被利用?
我知道这ShellExecute()很容易受到命令注入的影响。但是,在这种情况下,它是否也以同样的方式脆弱?
想象一下,我们在 Windows 应用程序中有以下伪代码:
ShellExecuteA(0, "open", &File, &Parameters, &Directory, 1);
并且,想象一下你可以控制Parameters论点。这是否意味着它可以被利用?
我知道这ShellExecute()很容易受到命令注入的影响。但是,在这种情况下,它是否也以同样的方式脆弱?
这取决于lpFile论点。如果lpFile是命令行解释器(例如cmd.exe或powershell.exe)或可以接受代码作为命令行参数的程序(例如perl.exe或ruby.exe),那么是的,您可以为命令注入攻击提供任意命令。
但是,如果lpFile程序不执行命令行参数(例如notepad.exe,pbrush.exe、 等),则不存在命令注入漏洞。请注意,即使在这些情况下,如果lpFile程序尝试打开命令行中提供的文件路径,这仍可能被视为安全问题。
正如杰森已经提到的,一切都取决于文件。但我还想多说几句。
你说:
并且,想象一下您可以控制 Parameters 参数。这是否意味着它可以被利用?
以同样的方式控制其他ShellExecute参数可能会获得...你可能明白我为什么说可能,而不是可以。
您没有包含相关信息,但我认为您的意思parameters是获得了编辑可执行文件的控制权。如果是这样的话。
想象一下文件是cmd.exe,你可以控制参数,但是在app参数中C:\file.txt它有11个字符,所以你可以把它改成其他的最多11个字符的参数(如果它小于11,你需要加NULLs)。
然而,在实际情况下,ShellExecute参数是部分硬编码的,并且是在程序流程中动态构建的。因此,回答您的问题ShellExecute很容易受到命令注入的影响,但是,并非每个使用的应用程序ShellExecute都可以作为目标,实际注入可能不是那么容易的任务。