Attacker Value
Unknown
(1 user assessed)
Exploitability
Unknown
(1 user assessed)
User Interaction
Unknown
Privileges Required
Unknown
Attack Vector
Unknown
0

HP iMC 5.0 TFTP WRQ "Remote Code Execution" Vulnerability

Disclosure Date: May 13, 2011 •
CVE-2011-1849
Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

tftpserver.exe in HP Intelligent Management Center (IMC) 5.0 before E0101L02 allows remote attackers to create or overwrite files, and subsequently execute arbitrary code, via a crafted WRQ request.

Add Assessment

2
Technical Analysis

Setup

  • 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

Breakpoints

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"

Thoughts

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:

  1. The user can traverse their way out, and write the malicious file onto a specific place such as WBEM.
  2. 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.
  3. 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
Log in to Add Reply
CVSS V3 Severity and Metrics
Base Score:
None
Impact Score:
Unknown
Exploitability Score:
Unknown
Vector:
Unknown
Attack Vector (AV):
Unknown
Attack Complexity (AC):
Unknown
Privileges Required (PR):
Unknown
User Interaction (UI):
Unknown
Scope (S):
Unknown
Confidentiality (C):
Unknown
Integrity (I):
Unknown
Availability (A):
Unknown

General Information

Offensive Application
Unknown
Utility Class
Unknown
Ports
Unknown
OS
Unknown
Vulnerable Versions
Unknown
Prerequisites
Unknown
Discovered By
Unknown
PoC Author
Unknown
Metasploit Module
Unknown
Reporter
Unknown

Vendors

  • hp

Products

  • intelligent management center 5.0

Additional Info

Authenticated
Unknown
Exploitable
Unknown
Reliability
Unknown
Stability
Unknown
Available Mitigations
Unknown
Shelf Life
Unknown
Userbase/Installbase
Unknown
Patch Effectiveness
Unknown
Technical Analysis