Regarding the recent vulnerabitliy issue.

1,278 views
Skip to first unread message

GW Security Q&A forum

unread,
Oct 3, 2017, 7:46:45 PM10/3/17
to GW Security Q&A forum
From the Pinned topic regarding the hack unit. A user posted the following reply:

Saying there was glitch in one of your servers is mis-leading.
I understand that you simply re-brand hanbang / Dahua camera's and DVRs, so maybe you don't actually have any knowledge of the undocumented telnet access that is still running in the latest version of your firmware.
And maybe you don't actually know that the camera's and DVRs connect to a T2uSvr @ nat.vveye.net regardless of what the settings are, and register with a dns server that doesn't show in the settings anywhere and cannot be removed.

But the people who's products you rebrand were notified in March of the issue and it was documented in CVE-2017-14335
https://nvd.nist.gov/vuln/detail/CVE-2017-14335
You could consider CVE-2017-14335 a "glitch" since it is an exploit of the HTTP server not properly handeling authentication.
But the previous CVE's going back 5 years specifically mention the backdoor telnet access.
You have been "patching" this backdoor since at least 2012, and while thousands of camera's and NVR get hacked over and over, the backdoor is never removed, just the undocumented account and password are changed.

hikvision and Dahua refused to admit it existed, and Hanbang simply refused to respond.

I ran a port scan on your latest firmware and sure enough Telnet on port 23 is responding, although it is not documented anywhere in your product information.

On your camera, after I downloaded the latest firmware it took less than 10 minutes for me to guess the backdoor password you still have in place.
I understand you only resell what the Chinese feel like giving you, that isn't your fault.
Continuing to do it when you know about it is.

I was hoping You could just copy this to GW SECU, and GW Security-inc etal "QA" areas and save on the reposting.

regards
DJ

For some reason it wasn't showing correctly on that particular thread so we decided to make an announcement with it.

We want to be as transparent as we can be on this issue that effects a lot of our customer. Please note that the information we provide is what we receive from our supplier.

We will do everything we can to rectify the issue; new firmware are available to patch the vulnerability mentioned above.

The suggestion for separate admin rights is in the works, we will know the progress by next week.

Please let us know if you have any questions, concerns, or suggestions; we will do our best to accommodate your need.

You can contact us through Email, live chat, or phone. Please note that due to limited manpower, phone will be answer by first-come-first-serve bases, and it is recommended to make an appointment with us first.

Dan Spiteri

unread,
Oct 5, 2017, 1:13:55 PM10/5/17
to GW Security Q&A forum
Thanks for the quick replies to all these issues!

The vulnerability reported in CVE-2017-14335 is exploited via a man-in-the-middle attack. I noticed that the authentication token is sent over clear text, which is just base 64 encoded, so if I was at a coffee shop sniffing network traffic I would be able to get someone's username and password. We really should be authenticating via https or another secure protocol.

GW Security Q&A forum

unread,
Oct 5, 2017, 1:17:49 PM10/5/17
to GW Security Q&A forum
Our developers are looking into adding SSL option at the moment. We should receive a report from them soon.

Shawn Thompson

unread,
Oct 27, 2017, 3:18:14 AM10/27/17
to GW Security Q&A forum
Your video surveillance client software is also blasting data to port 8000 every chance it can.  My firewall is being blasted internally, because this software is desperately trying to publish on that port:

Service  
 Packets %
1
udp/8000

47.­91.­75.­222 1 630 34.59
2
udp/8000

198.­11.­174.­237 1 410 29.92
3
tcp/10086

121.­43.­235.­2 507 10.76
4
udp/8000

47.­91.­131.­102 409 8.68

Dan O'Reilly

unread,
Nov 9, 2017, 10:02:44 AM11/9/17
to GW Security Q&A forum
I am also able to do a basic GET API call and pull the user's email address and password in plain text without authentication if your NVR is being port forwarded. Crazy. You can also do this an obtain each camera's IP address, username and password but this I haven't found a way to access if outside the network since they aren't obviously exposed to the public internet like your NVR would be if using port forwarding.

Dan Spiteri

unread,
Nov 9, 2017, 11:53:02 AM11/9/17
to GW Security Q&A forum
Would you be able to list the API endpoint you used to retrieve those? I want to test it on mine and see if the latest patch addressed that.

Thanks!

Dan O'Reilly

unread,
Nov 9, 2017, 1:54:29 PM11/9/17
to GW Security Q&A forum
These were the major ones, but it seems they were patched on mine, not that they are for every model...The URLs are case sensitive, your ip address has to go in front of these and they are all "GET"s. No authentication was required for any of these and I used POSTMAN.

Obtain email address and password in plain text:
/ISAPI/System/Network/mailing

IP addresses, user names, and passwords for cameras connected to your NVR. Passwords are in Base64 so you can decode and see your password in text:
/ISAPI/ContentMgmt/InputProxy/channels/status
and
/ISAPI/ContentMgmt/InputProxy/channels/

All your ports being used for your NVR:
/ISAPI/Security/adminAccesses

UPnP ports:
/ISAPI/System/Network/UPnP/ports/status

NVR information:
/ISAPI/System/deviceInfo

User Permissions (modify the number at the end to see other users):
/ISAPI/Security/UserPermission/1


Here are some still open on mine. There are others but I don't want to ruin all of your fun of finding them. :)

  • /ISAPI/Security/users
  • /ISAPI/ContentMgmt/InputProxy
  • /doc/script/params/device.js
  • /doc/script/checkform.js
  • /doc/script/params/user.js
  • /doc/script/login.js

Here is another thing. In POSTMAN, on your local network, type in the ip address of one of your cameras and you can view a snapshot from it with no authentication. So essentially anyone on your network can access the cameras fairly easily.

  • cameraipaddress/cgi-bin/video_snapshot.cgi


Dan Spiteri

unread,
Nov 9, 2017, 3:01:47 PM11/9/17
to GW Security Q&A forum
Cool, thanks for posting that. I think the issue is fixed on mine because I get an error code back from all of those endpoints if I don't pass my authentication parameters in the request header.

My cameras all run into a switch, and then into the NDVR, so their IP addresses are all local to the NDVR. Is that how yours is setup as well?

Dan O'Reilly

unread,
Nov 9, 2017, 3:20:08 PM11/9/17
to GW Security Q&A forum
Even these are closed on yours?
  • /ISAPI/Security/users
  • /ISAPI/ContentMgmt/InputProxy
  • /doc/script/params/device.js
  • /doc/script/checkform.js
  • /doc/script/params/user.js
  • /doc/script/login.js
All of my camera run into a POE switch, then to my NVR (model 2208E). Yes, the IP addresses for the cameras are local, but I was able to identify the cameras hooked up to the switch, user names and passwords for each of them through the open, unauthenticated endpoint on the NVR. Are you using POSTMAN to get to those endpoints?

Jim Acheson

unread,
Nov 12, 2017, 9:45:53 PM11/12/17
to GW Security Q&A forum
Thanks Dan O'Reilly for the good info!
Reply all
Reply to author
Forward
Message has been deleted
0 new messages