CVE2014-6287 Analysis Report
0x00 Preface
In wooyun zone, I saw the article HFS 2.3x remote command execution (the last day of hacker capture). Previously, I only analyzed binary vulnerabilities. This command injection vulnerability was the first analysis, the hfs 2.3.279 version is downloaded from the Internet. After running, run the POC and run the four calc instances.
Poc:
http://localhost:80/?search==%00{.exec|calc.}
PS: at the end of the analysis, google looked for the string "parserLib" in the executable module to know that this vulnerability is a CVE2014-6287 ...... A faint sorrow. But let's talk about the analysis process.
0x01 preparations
The first is some preparations before the analysis. You can use PEiD to view the file, add the asp Shell, and simply perform shell removal using the PEiD universal shelling tool.
After IDA loads the shell file, it can see some functions. According to the previous understanding of the string class implementation in c ++, it seems that static compilation is used, the library code for string processing is statically linked to the executable file.
PEid is used to identify the files after shelling by the compiler. It is recognized as Borland Delphi 6.0-7.0. IDA is used to load the corresponding signature library and sign the function, in this way, a large number of inline functions can be identified to facilitate analysis. With the signature, 5636 inline functions can be identified, which makes it much easier to analyze.
0x02 analysis process
View the File Import function through IDA, find the startup functions of WinExec, ShellExecuteA, and other processes, locate the function call points through cross-reference, set breakpoints through windbg, and observe the parameters, the calculator was indeed started by ShellExecuteA. View the call stack of the program.
The sub_531438 function can be found through the call stack. This function explains the exec | calc command and starts calc. After analyzing the function, we can see that this function is a function that explains and executes USER commands. The relevant code is as follows.
Continue to analyze the transfer process of "exec | calc" by using the call stack, and find
int __stdcall sub_51E268(signed char *** a1, int a2)
Function. ** a1 points to the string "\ x0020..exe c | calc .} ", where the int _ cdecl sub_51DFA0 (int a1) function is opposite to" \ x0020..exe c | calc .}.
For
http://localhost:80/?search=%20{.exec|calc.}
By comparing ** a1 at sub_51E268 to the string to be interpreted, we can see that {. | and other characters are encoded.
Visible
http://localhost:80/?search=%00{.exec|calc.}
The conversion of special characters in cmd.exe c | calc.} fails. Therefore, you need to locate the conversion function. Search for the "& #" string in the module and locate it to obtain
int __fastcall sub_528EB0(int a1, int a2)
Converts {| and other characters.
Sub_51E390 matches the Regular Expression and finds {| equal sign. When 202.16.exe c | calc.} is passed to the function, the return value of this function is 2. The
sub_4B827C、Sysutils::IntToStr
Convert the character to a 10-digit string, and finally replace {in the original string {.
For
http://localhost:80/?search=%00{.exec|calc.}
The return value of sub_51E390 is 0, so the {| and other characters after it are not converted, resulting in subsequent command execution.
View
int __fastcall sub_51E390(int a1, int a2)
Function, You can see "\ {[.:] | [.:] \} | \ |" and "m !", In the analysis process, if you see the string "parserLib", google it .......
View the vulnerability details, and you can see that the analysis results are consistent. Due to a regular expression problem, the final remote code execution is performed.