Security Research

A good time to update your Veeam to Update 3 – VeeamVixProxy Vulnerability

Pasquale `sid` Fiorillo, Francesco `ascii` Ongaro from ISGroup, an Italian Security firm, and Antonio `s4tan` Parata from ush team, have just released a critical security advisory for any version of Veeam Backup & Replication prior to 8 Update 3 (released today, October 8th, 2015). The issue potentially involves 157,000 customers and 9.1 million Virtual Machines worldwide and could lead to full Domain Administrator compromise of the affected infrastructures.

Veeam 6 7 8 Vixproxy Vulnerability

This vulnerability is caused by a component, VeeamVixProxy, that logs in an obfuscated way the administrator username and password used by Veeam to run. An attacker could easily “decode” the password to cleartext. From subsequent analysis it turns out that Veeam’s admin user is often a Domain Administrator user and this enables a scenario in which an unprivileged user, or even an hacked IIS website, inside a single Virtual Machine, can escalate his privileges to Domain Administrator. Even if Domain escalation is not possible, the attacker will at least get the Local Administrator’s credentials.

Users are strongly advised to update their systems to the latest version released by the vendor.

–The press team
You can use the images in this post under the Creative Commons Attribution 4.0 International License.

Security Research

Security researchers servants of a morbid system

Yesterday I was reading an article based on a Microsoft report titled “Security researchers exploiting vulnerabilities“.

For me, somebody who born in the security and hacking scene, it’s total nonsense. The community has been, finally, destroyed by a short sighted security market around five years ago in the five years before.

Underground is dead, hackers were saying. As in an Andersen tale.

The fact is that nowadays exploit development gone underground or in the direction of paid bounties and “intelligence” exploit packs, eg: in the money direction.

Since not every hacker or researcher want to play this sick and ethic-less game (see the disappearance of the Full Disclosure mailing-list for instance) less vulnerabilities are researched and disclosed pro-bono, and if you want to access that knowledge you need extensive financial resources.

What is the result?

Vendor, big intelligence agglomerates and security corporations can tell people that they did a great job in securing the world while the truth is exactly the opposite. High impact vulnerabilities are now a bargaining chip and will not be disclosed publicly in a timely manner.

For who believed in the Full Disclosure paradigm this is the last lost battle of a lost war.

Full Disclosure is part of a real Responsible Disclosure process, notify the vendor and force him to fix the issue fast as it will be available to the public soon, and let the people know the risk they are or were exposed to. Or feel free, also form an ethical point of view, to disclose the issue directly. This allowed independent security researchers to get the credit they deserved while guaranteeing transparency, naturally really little money was involved.

With the current model of vulnerability trading the researcher loses any control on the disclosure process, that could not happen at all.

It’s easy to speculate, seen the facts that are emerging every day (NSA, artificial crypto-weakness, cyber-intelligence and offense), that information gathered for a fraction of it’s value is now retained for an indefinite amount of time to allow it’s exclusive access and use by a number of well known actors.

Call me idealistic but this maturity model smells of control.

Information is not free anymore.

–Francesco Ongaro

Security Research

OCZ RevoDrive 3 and OCZ RevoDrive 3 X2 PCIe SSD support for Linux 2.6

Support for OCZ RevoDrive3, RevoDrive3 X2, zDrive R4 in Proxmox (and vanilla 2.6 kernel sources) is possible thanks to the work of robbat2 and geneanon. This repository contains all the information needed to patch your kernel and backport RevoDrive support in the stable 2.6.32 Proxmox kernel (The only one with OpenVZ support at the time of writing, Gen 2014).

Security Research

Proxmox 2.6.32 support for OCZ RevoDrive3, RevoDrive3 X2, zDrive R4

Please sustain the request for better PCI Express SSD support in the stable version of Proxmox VE: post a comment on and contact the maintainers!

Dear Proxmox kernel mantainers,

OCZ is providing a terrible Linux support, in an attempt to “protect” the technology of their VCA chip, build on a Marvell 88SE9485 controller. Basically they try to push down the adoption of RevoDrive3 and RevoDrive3 X2 on Linux machines in favor of other “enterprise” class products (zDrive R4). All summed, this attitude will grant lifetime exclusion from the kernel and painful user experience.

In reality the device just works with minor modifications of the mvsas driver [1]. Modifications that are already included in the mainline 3.2 kernel [2].

Additionally it seems, according to the report of b3rlin3r, that VCA actually decrease performance compared to the standard Marvell device [4]. Vanilla mvsas driver does 4612 TPs VS 3605 TPs for the OCZ VCA driver (actually 2, oczpcie and oczvca).

My request is to backport the robbat2 patch to the rhel6-2.6.32 [3] kernel, it’s just a matter of adding some PCI ids to the driver.

Thanks and have a great day,
Francesco ascii Ongaro –





Francesco `ascii` Ongaro

Security Research

Connecting to Proxmox VE OpenVZ containers using VNC

Proxmox VE has an administrative panel that allows connecting to KVM and OpenVZ virtual machines using a Java applet and the VNC protocol (RFB). The issue is that Java is a show-stopper for me, it’s unsafe, bloated and barely runs as a browser plugin. A lot of Proxmox users complain about this part of the implementation, and try to find alternative ways to directly connect to the virtual VGA adapter of their machines.

Seen the amount of VNC implementations that use modern HTML5, WebSockets and Canvas this seems a really poor choice to me. Proxmox’s devs if you are listening please implement this!

While it’s possible to directly “enter” in an OpenVZ container by issuing a “vzctl” command, this would require a shell access on the server node:

vzctl enter 101

There are many reasons that would make you prefer a VNC access to the guest machine, one for all avoid giving access to the host node to a sysadmin or a customer.

For KVM there are solution available (manually editing the KVM configuration of the virtual machine to enable the VNC server) but for OpenVZ I wasn’t able to find a decent solution.

As in Xen a component called “vncterm” is used to connect to OpenVZ, or any other interactive command. Internally it uses X11VNC (

The main issue was that the VNC server was offering a security type unsupported to most VNC clients (the infamous “Server did not offer supported security type” error).

$ vncviewer localhost::6900
Connected to RFB server, using protocol version 3.8
Server did not offer supported security type

Luckily vncterm allows passing arguments to x11vnc, by usign a mix of such arguments we can re-enable a standard, password based,  unencrypted VNC server that works with most clients. The command is like the following (please change the “test” password to a stronger one!):

ssh -L 6901:localhost:6901 root@pve-node 'vncterm -nossl -nopw -vencrypt never -passwd test -rfbport 6901 -listen localhost -localhost -timeout 20 -c vzctl enter 101'

It creates an SSH TCP tunnel between the localhost:6901 port on the server to the localhost:6901 port on the client (the sysadmin notebook, for example). Then the admin will be able to connect using a standard vncviewer client:

vncviewer localhost::6901

This will work without the annoying VNC security type error and can be easily tweaked to work from inetd/xinetd or stunnel if you need encryption.

For me it was a complete life saver!

Francesco `ascii` Ongaro

ISGroup, Security Research

Scada Exposure released! Scada Internet Exposure 2013-11

ScadaExposure is the first attempt to create a permanent observatory on the presence of overexposed scada gears. The project is a collaborative effort of Francesco Ongaro and Gianluca Pericoli, aimed to build an open framework for SCADA exposure benchmarking. Knowing the updated index of exposed ICS devices allows to answer many questions of public interest.

Get the Scada Internet Exposure 2013-11 report

Our goal is to obtain fresh data (exposed/vulnerable devices) from public search engines like Shodan and Google and categorize it around three main dimensions: the Temporal axis, the Geographical axis and our Taxonomy.

Temporal axis

Each dataset belongs to a release that refer to a specific time. Our first release is the November 2013 one.

  • Is SCADA exposure higher or lower than before?
  • Is the current awareness and effort level effective in order to secure private and critical infrastructures?

Geographical axis

Results are separated by country. The first release includes Switzerland, Italy and World.

  • Is a country more exposed than another?
  • How is a country relatively exposed? (Indexed devices VS Scada devices)
  • How is a country relatively exposed compared to the world? (Country Scada devices VS World Scada devices)
  • How is a country relatively exposed compared to another country?


ScadaExposure’s taxonomy is a hierarchy of Vendors, Products and Product versions. Every search query (“dork“) is linked to a Product Version, Product, Vendor or can be generic. Products belong to two categories: Systems and Devices, as described by the Glossary.

  • What is the most exposed vendor?
  • What is the most exposed product?
  • What is the most exposed system type or device class?


We would love to know you reaction (!.

The project is sponsored by the security company ISGroup SRL.