bugtraq - [CVE -2014-1201] Lorex security DVR ActiveX control buffer overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 10 Jan 2014 15:50:33 +0000
From: Pedro Ribeiro <pedrib@...il.com>
To: bugtraq <bugtraq@...urityfocus.com>
Subject: [CVE -2014-1201] Lorex security DVR ActiveX control buffer overflow

Hi,

I have discovered a buffer overflow vulnerability that allows remote
code execution in an ActiveX control bundled by a manufacturer of
video surveillance systems.

The company is Lorex Technologies, a major video surveillance
manufacturer that is very popular in the US and East Asia. Their
affected product range is the EDGE series, which has 16 products in
it. I have confirmed that all 16 are vulnerable at this point in time.
These security DVR's are remotely accessible, and when you access it
on a Windows computer with Internet Explorer, they try to install the
vulnerable ActiveX control INetViewX. The Lorex manual[1] instructs
the user to blindly accept the ActiveX control install when prompted.
The full list of devices, as well as links to the firware download,
can be found in [2]. Their products offer remote video viewing
capabilities, and you can find some of them on Shodan[3].

The buffer overflow can be triggered by a really long string (10000+
characters) in the HTTP_PORT parameter. The instruction pointer can be
very easily controlled in XP by the characters 109 to 113 in the
string. Please refer to the PoC file lorex-testcase.html. You will see
that the HTTP_PORT parameter is composed of D's, apart from chars 109
to 113 which are four A's. If you open this file in IE after
installing the control, you will see that IE will crash with an EIP of
0x41414141. Changing the four A's to any other value will cause EIP to
crash on that value.

The list below tells a better story about what is affected and how it
can be controlled:
Win XP SP3 with IE6 - Fully exploitable as described
Win XP SP3 with IE8 - Could not get it to crash (????)
Win 7 x64 with IE10 fully patched - Fully exploitable, though not as
easy as for XP (see analyze -v [4] and !exploitable [5] outputs)

To verify this vulnerability you can download and extract the firmware
using binwalk (http://code.google.com/p/binwalk/). To do so, please
follow the instructions in [6], and then install the ActiveX control
in INetViewProj1_02030330.cab.

I have contacted Lorex and they initially said they would fix it, but
went radio silent shortly afterwards.
17.11.2013 - Initial contact via support page
18.11.2013 - Email to sales, no response.
21.11.2013 - Second email to sales, received response by sales saying
they will forward it to technical support and get back to me.
04.12.2013 - Third email to sales saying that technical support never
contacted me back. No response.
08.01.2013 - MITRE assigns CVE-2014-1201 to this issue.
09.01.2013 - Public disclosure.

All references and proof of concept can be under the lorexActivex
folder in the repo at
https://github.com/pedrib/PoC

Regards,
Pedro Ribeiro (pedrib@...il.com)
Agile Information Security