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>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Jan 2014 16:55:08 +0000
From: Pedro Ribeiro <pedrib@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: [CVE -2014-1201] Lorex security DVD 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 can be found at:
https://github.com/pedrib/PoC/lorexActivex/lorex-report.txt

Proof of concept:
https://github.com/pedrib/PoC/lorexActivex/lorex-testcase.html

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

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists