HP Intelligent Management Center contains a flaw related to thetftpserver.exe component allowing the creation or upload of arbitrary files when handling Write Request packets. This may allow a remote attacker to upload arbitrary files which will allow for the execution of arbitrary code as the SYSTEM user.
Recent assessments:
wchen-r7 at September 12, 2019 6:07pm UTC reported:
Windows Server 2003 SP2
.Net Framework 3.5 SP1
Windows Installer 4.5
HP iMC 5.0
Microsoft SQL Server 2008 Express
LocalSystem to run the service
sa account enabled
TCP/IP and Named Pipes enabled
bp 00402542 ".printf /ow \"\\nHandling WRQ request\\n\"; g"
bp 00402241 ".printf \"File path check for '/', you have:\\n\"; db esi L1; g"
bp 0040225a ".printf \"File path check for ':', you have:\\n\"; db esi+1 L1; g"
bp 00402268 ".printf \"Searching for '..' in file path, found: %x\\n\", eax; g"
bp 00402277 ".printf /oe \"You have hit File Access Violation in RRQ\\n\"; g"
bp 00401ea0 ".printf /ow \"\\nHandling DATA request\\n\"; g"
bp 00402097 ".echo \"File handles before open():\"; .foreach /pS 1 /ps 1 (h {!handle 0 0x04 File}) {.if ($scmp(\"${h}\",\"type\") > -1) {} .elsif ($scmp(\"${h}\", \"handles\") > -1) {} .else { .printf \"File handle \"; .echo h} } ;.echo; g"
bp 00402096 ".echo \"Opening file handle for path:\"; db eax; ; .echo; g"
bp 004020a1 ".echo \"File handles after open():\"; .foreach /pS 1 /ps 1 (h {!handle 0 0x04 File}) {.if ($scmp(\"${h}\",\"type\") > -1) {} .elsif ($scmp(\"${h}\", \"handles\") > -1) {} .else { .printf \"File handle \"; .echo h} } ;.echo; g"
bp 00402108 ".echo \"Writing to file...\"; g"
ZDI claims that this is a âremote code executionâ bug, because a remote user can upload an arbitrary
file onto the remote server. In theory, being able to write to the victim machine COULD lead to code
execution, but after looking at the bug, itâs probably a long shot.
Ideally, an arbitrary WRITE vulnerability requires one of the conditions to be met in order to ensure
automatic code execution:
The user can traverse their way out, and write the malicious file onto a specific place such as WBEM.
Having the upload folder mapped as a WWW virtual directory. That way you can upload a malicious web
script using TFTP, and then send a HTTP request to execute the script.
If thereâs already an executable placed in the upload folder, and itâs called by some other services
or programs, in theory you could overwrite that file, and then gain code execution when itâs called.
The technique ZDI is referring to is probably #3, because this is what they say in the advisory:
"When handling WRQ opcode types the server allows arbitrary file creation. Additionally,"
the server is configured to truncate/overwrite existing files."
However, the default upload directory does not have any executable in there, except for a âLicense.txtâ
file. So attack vector #3 is very unlikely. Note: The default location of that directory is:
C:\Program Files\iMC\server\tmp\
Attack vector #2 should also be ruled out, because by default, the upload directory isnât mapped or
shared to anything.
And that leaves us attack vector #1 (dir traversal)âŠ
Itâs rather easy to make a WRQ request using the tftp command. Hereâs an attempt of trying to write to
a location outside of the âtmpâ directory:
tftp> connect 10.0.1.8
tftp> put /tmp/test.txt ../../../../blah/test.txt
Error code 256: Access voilation.
During the above experiment, folder âblahâ is set to allow full access to âeveryoneâ.
Process Monitor also does not show any signs of the tftpserver.exe process attempting to access path
test.txt before hitting an âAccess violationâ:
tftpserver.exe 4092 UDP Receive sinn3r-qixn9ta2:tftp -> 10.0.1.3:50839 SUCCESS Length: 40
tftpserver.exe 4092 UDP Send sinn3r-qixn9ta2:tftp -> 10.0.1.3:50839 SUCCESS Length: 22
tftpserver.exe 4092 QueryStandardInformationFile C:\Program Files\iMC\server\conf\log\tftpserver.2012-09-14.txt SUCCESS AllocationSize: 4,096, EndOfFile: 2,815, NumberOfLinks: 1, DeletePending: False, Directory: False
tftpserver.exe 4092 QueryStandardInformationFile C:\Program Files\iMC\server\conf\log\tftpserver.2012-09-14.txt SUCCESS AllocationSize: 4,096, EndOfFile: 2,815, NumberOfLinks: 1, DeletePending: False, Directory: False
tftpserver.exe 4092 WriteFile C:\Program Files\iMC\server\conf\log\tftpserver.2012-09-14.txt SUCCESS Offset: 2,815, Length: 132
This is what we get from the TFTPâs log file:
2012-09-14 14:36:27.182 [ERROR (-1)] [THREAD(6196)] [TFTPService::handle_input] Receive error packet
2012-09-14 14:37:00.869 [ERROR (-1)] [THREAD(6196)] [TFTP::handleRRQ] File Access Voliation,filename=../../../../../blah/test.txt!
Based on these clues, I suspect the âAccess violationâ error is thrown before tftpserver.exe actually
tries to write âtest.txtâ to the file system.
In particular, this is the code thatâs the reason we get âAccess violationâ â when thereâs a ââŠâ in
our path, we get rejected:
.text:0040225C loc_40225C: ; CODE XREF: handleWRQ+84j
.text:0040225C push offset SubStr ; ".."
.text:00402261 push esi ; Str
.text:00402262 call ds:strstr
.text:00402268 add esp, 8
.text:0040226B test eax, eax
.text:0040226D jz short loc_402298 ; If no ".." found, go to 0x402298
.text:0040226F
.text:0040226F loc_40226F: ; CODE XREF: handleWRQ+71j
.text:0040226F ; handleWRQ+8Aj
.text:0040226F push esi ; ArgList
.text:00402270 push offset aTftpHandlerr_2 ; "[TFTP::handleRRQ] File Access Voliation"...
.text:00402275 push 0FFFFFFFFh ; int
.text:00402277 call sub_408180
.text:0040227C add esp, 0Ch
.text:0040227F lea eax, [esp+0ACh+var_98]
.text:00402283 push eax
.text:00402284 mov ecx, ebp
.text:00402286 mov [esp+0B0h+var_98], 2
.text:0040228E call buildErrorPacket
Other characters that can lead to the same rejection (part of the same function â 0x004021D0):
.text:00402239 cmp eax, 1 ; Make sure there's at least 1 byte of file path to check
.text:0040223C jb short loc_402243
.text:0040223E cmp byte ptr [esi], '/' ; Check if the file path begins with "/"
.text:00402241 jz short loc_40226F ; Access Violation
.text:0040224F sub eax, edx
.text:00402251 cmp eax, 2 ; Make sure there's at least 2 bytes in the file path
.text:00402254 jb short loc_40225C
.text:00402256 cmp byte ptr [esi+1], ':' ; Check the second byte for ":"
.text:0040225A jz short loc_40226F ; Access Violation
Environment variables can bypass these checks. However, it wonât be recognized as a legit file path.
Hereâs the routine that creates/writes the file:
.text:00402096 loc_402096: ; CODE XREF: handleDATA+1CDj
.text:00402096 ; handleDATA+1D9j
.text:00402096 push eax
.text:00402097 lea ecx, [esp+0B8h+var_94]
.text:0040209B call ds:?open@?$basic_ofstream@DU?$char_traits@D@std@@@std@@QAEXPBDHH@Z ; std::basic_ofstream<char,std::char_traits<char>>::open(char const *,int,int)
...
.text:00402103 loc_402103: ; CODE XREF: handleDATA+25Cj
.text:00402103 push ebx
.text:00402104 lea ecx, [esp+0B4h+var_94]
.text:00402108 call ds:?write@?$basic_ostream@DU?$char_traits@D@std@@@std@@QAEAAV12@PBDH@Z ; std::basic_ostream<char,std::char_traits<char>>::write(char const *,int)
The actual file path that will be opened (see that itâs also rejected):
tftpserver.exe 4092 CreateFile C:\Program Files\iMC\server\tmp\%SystemDrive%\blah\test.txt PATH NOT FOUND Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0
Assessed Attacker Value: 0
Assessed Attacker Value: 0Assessed Attacker Value: 0