How I Handled A Hacked Dahua NVR

I had a client with a hacked Dahua NVR that I had to battle these past few weeks. The only way we knew it had been hacked was because we could not save any changes. We found this out when I attempted to install three additional Dahua cameras at this site.

The NVR had no issue adding the new cameras, but as soon as it rebooted (Dahua devices reboot weekly on Tuesday @ 02:00 by default), it lost the new cameras.

When I was called back to the site Wednesday AM, I found that the NVR had been reverted to the settings just before I added the three cameras. It was after digging further that I found an additional user account named "service" that had a note on the account that said "your_device_has_been_hacked_ple".

I was unable to make any changes to the NVR config that would survive a reboot. My admin credentials remained intact and usable, but there was little hope of fixing the issue via the NVR GUI. I attempted to navigate CLI via telnet, but was not able to correct the issue myself.

I leaned on my Dahua OEM suppliers for their assistance in locating a newer firmware with hopes that it would overwrite / correct the permissions issues. After upgrading the firmware, the permissions issue persisted. Note that I could not run the firmware update via the GUI, I had to use the Dahua DVR Upgrade Tool Ver1.16 utility to push it to the device.

My next step was trying to again use telnet access to try and unlock the NVR. However, there was a new roadblock. The original firmware 2.608 allowed up to 8 character passwords, but the newer firmware 2.616 only allowed 6 character passwords. This made my 8 character password unusable. I could use the Dahua daily code to make changes in the NVR GUI, but these were not saved to the telnet level password list. So now I was locked out of telnet access.

My final attempt was to connect via RS232 and try to erase everything on the NVR and upload a complete firmware image. To do this, you will need a few programs, NCOM and a Cisco TFTP server app. NCOM allows you a CLI console to run commands. I was able to use the HELP command to find ERASECFG, which successfully cleared the permissions issue. I also used the NCOM/TFTP method to upload the complete Dahua firmware image (update.img).

I guess I am documenting this here in case others have a similar issue. To fend off this from happening again, we now are using a non-standard port externally forwarded to port 37777 in hopes that this will prevent its discovery by hackers again. This isn't a sure fire way to prevent future hacks, but it will surely take longer for them to find it.

NOTICE: This comment was moved from an existing discussion: Should I Hack 10,000 Dahua Cameras?


Yo, wasn't Sean Nelson and myself involved in helping you? Lol

At least shout us out by name :P

We didn't suddenly become nameless "Dahua OEM suppliers".

Anyway, congrats on killing the bug!

Also, proper credit due to BahamasSecurity for the guides he got, ftp.asm.cz for all the firmware and tool downloads, and also to my Dahua rep for verifying some info for me.

Thank you Robert @ SavvyTech and Sean @ Nellys for helping me solve this issue. Couldn't have done it alone.

So how does Dahua corporate fit into all of this? This was not an official branded Dahua product? I ask because since it is a Dahua product people will reasonably want to understand what responsibility Dahua has or not.

At the time this product was purchased, Dahua USA didn't exist. The only option of buying Dahua based recorders was through an OEM at that time. I am unsure how Dahua corporate would react to this.

So is the NVR labelled Dahua or no label or the OEM's label? Of course, it's Dahua but I am just trying to understand how its marketed.

It was sold to me as an Eyesurv brand from Nellys Security.

Basically, old product, not much support. Unforeseen new challenges from cybersecurity flaws.

**** happens. Hell, 4 years is a long time for any product of this nature to be exposed to different exploits. IPVM itself reported on Axis getting blown wide open not too long ago, let alone a couple of Chinese companies who weren't all the rage back then.

This isn't a story about manufacturers ****ing up. It's about distributors and integrators coming together to make things work.

IPVM itself reported on Axis getting blown wide open not too long ago, let alone a couple of Chinese companies who weren't all the rage back then.

The Axis vulnerability (see details) is far harder to exploit than Dahua's.

John, do you know the attack vector used on my NVR? They had port 80 and 37777 forwarded from the internet. All default passwords were changed. At that time, they were eight character mixed case letters and numbers. Dahua doesn't allow other characters, like punctuation marks. I honestly don't know myself. I thought if Telnet wasn't open that this wasn't possible?

I thought if Telnet wasn't open that this wasn't possible?

Telnet is how Mirai has spread, but it is not the only method that a DVR (or any other device) can get infected.

Based only on what you have posted, I would suspect that your DVR got infected through some kind of HTTP exploit. Accessing an admin script that did not require auth, or doing some kind of a form/POST hack, URL exploit, etc. Essentially, someone accessed the machine with a specific URL request that caused an exploit.

These kinds of attacks are nearly impossible to prevent if you have it open for remote access, unless you have a highly advanced firewall that can do deep packet inspection (unlikely).

I'm just worried that it's still vulnerable. I've done my best to evade known vectors, but not knowing how this was done makes that a challenge.

I'm just worried that it's still vulnerable

I reported this to CyberSecurity@global.dahuatech.com pursuant to Dahua's cybersecurity guidelines.

If I receive any response, I will post here.

iphone5 released 21september 2012, still able to upgrade to iOS10.

where consumer products life cycle is very small. Credit to Apple.

Chinese products, obsolete the time the boat lands at the port.

Unforeseen cybersecurity indeed is a challenge that all new products should never be compromised at currently understandings.

But it does not mean you forget about the past, that's narrow minded thinking.

Ethics and responsibility should be number one for any company.

Dahua's USA office didn't even exist at the time this NVR was sold to John and the NVR (released earlier than that iPhone, btw) cost less than half of what that iPhone did. I highly doubt we're talking the same category of device. One is purely an import with barely a translation to the UI slapped on. The other was designed and supported by an American company for the American market.

The context being that Dahua is adapted to the price sensitive, high-volume, high-expendability (high-turnover), market of China.

Apple charges out the wazzoo to generate high margins for their cut rate equipment to give the veneer of quality. They survive on at least providing some semblance of service through software, but their hardware is garbage tucked in shiny aluminum.

Dahua's USA office didn't even exist

Dahua USA's tactic of "Hey we did not exist until last year" is irresponsible since Dahua USA is a fully owned subsidiary and agent of Dahua Technology corporate.

The context being that Dahua is adapted to the price sensitive, high-volume, high-expendability (high-turnover), market of China.

And if Dahua wants to convey to the overseas market (which they have been knowingly selling into for years) that they are not going to take full responsibility for these issues, then they will suffer the consequences in the market.

Dahua USA's tactic of "Hey we did not exist until last year"

To be fair, is that Dahua's tactic or Robert's rhetoric?

And if Dahua wants to convey to the overseas market (which they have been knowingly selling into for years) that they are not going to take full responsibility for these issues, then they will suffer the consequences in the market.

Has Dahua actually refused to help here?

And isn't it on EyeServ anyway?

In any event, if Dahua did refuse, isn't this accepted practice by pretty much everyone in regards to unbranded gray product?

For instance, Hik and the (for months) unpatched firmware on wbox?

Has Dahua actually refused to help here?

I think that Dahua has resisted to go back and fix firmware/exploit issues with older models. Another roadblock is that they use different part number for all US models. On top of that, anything made prior to the USA office being created isn't supported by them.

Well, that's my personal rhetoric, not Dahua's stance. Tohan (my Dahua engineer) did actually express some willingness to help, but only through the original channel that sold it. Considering that channel has dropped Dahua as a partner it was more or less a no go.

Either way, you're talking about products designed before Dahua's foray into the US market in official capacity. The distributors who brought Dahua's product in before were companies who went and sought them out to import into the States (which is probably why GenIV and other long time distributors feel betrayed by Dahua taking their customers). This was not Dahua looking for people to sell snake oil to.

Granted, they need to improve the security of their products overall, but going back to support something that's out of your 3 year warranty sold to an OEM distributor in a country you had little presence in at the time you sold it is a bit of a task when even your primary market barely remembers that product. Heck, it didn't even get sold with Dahua's faceplate.

People weren't nearly as aware of cybersecurity issues and especially not for IoT devices as they are now. This device even predates Snowden's leaks.

Another difference is in the change between processors and chipsets for a lot of their models.

Apple can develop a unified firmware/OS architecture because they have a relatively similar hardware platform along generations. More powerful in increments, but still overall the same hardware command structure. For companies like Dahua and Hikvision, they have multiple chipsets to program for and QA for and some have extended capabilities and others are limited. Going from ARM/RISC to Intel/CISC changes the codebase a lot.

Besides, the only reason John went back to support this model is that the customer wasn't interested in spending on updating his equipment. This was even past service warranty.

Somewhat correct. The client wished to add more cameras to his existing six camera system. The NVR would not allow me to add these due to the hacked nature of the system. So, Dahua made and marketed a 16 channel NVR that had the ability to only hold 6 cameras, in my client's eyes. So in order for me to add the new cameras, I had to resolve the issue. Being that I sold him the NVR to start and charged him to install it, I found myself liable to correct this issue, whether or not it was technically my responsibility to do so under any warranty. He would have purchased an NVR if I wasn't able to correct the issue. He still may choose to replace the NVR, however, I think he is afraid of Dahua at this point. We may resort to a PC/VMS instead.

Wow! Robert have you even seen the inside of an iPhone? I think if you had worked on some mobile devices, you would quickly respect the hell out of Apple for their ability to engineer such a great product. They don't use cheap plastic frames and assemblies like LG and other low end models. You would have to have hands on knowledge to give such a strong statement. I am unsure you have that with that statement.

And for being as patriotic about America as you seem to be, you sure crap all over our best example of US engineering and capitalism at its finest. They are the gold standard.

It's all Foxconn parts and I did work @ Dr. Cell Phone in Houston for about 3 years. Honestly, between HTC, LG, Samsung and the rest of the bunch, Apple's actual hardware and component choice was nothing special. You'd know that from benchmark comparisons between the SOC/processors alone. Frame design is really where the differentiation was apparent and in the end Apple was only good enough to tie for top or second place. They weren't leagues beyond the foreign engineered models.

The plastic that Samsung used for their frames actually kept them fairly durable. Apple's had more than it's fair share of design flaws over the years and as people who repaired these phones on a regular basis, we stuck with Samsung for the most part. This was before the whole exploding battery thing of course.

Either way, in the world of technology, the best devices aren't always the ones that get the widest adoption. It's a fact of life. I'd rather have a Nexus or a Pixel any day of the week over an iPhone.

Just one little bit to finish this thread. As John said they been selling for a while.

And that Dahua has been at many international shows, and for sure ISC West for many years. I know they have been at shows outside China since 2003. I'm sure they didn't start in the yard sale sections with the rest of the flea market stands.

One last bite (pun), Apple is still the richest company in the world yes? and still, the only one who making profits on high-end smartphones yes?

The argument is not about hardware, it's about software, knowing how to do it properly is an art form and not something you search on bing.com or baidu.com

End of Line.

It's all Foxconn parts...

Yeah, there is that inventory. But there is a long standing tradition of Apple relying on Foxconn for a huge percentage of its manufacturing. Whether its the parts themselves, or the assembly, Apple is basically married to them.

Honestly, I can generalize and make the blanket statements that I do facetiously, but it comes down to benchmarks and features and build quality, there are better phones than the iPhone, especially in recent generations.

I have a Telnet Removal Tool for all Dahua Firmware dated <2015. All official Dahua FW with build dates 2015+ should have telnet functionality removed, this should also be the case for IPC.

Please see the link below to my OneDrive.

https://1drv.ms/u/s!AuILo2G6gRA83VOwJMsysKqh7i6Y

In side the zip will be 3 folders: config, Log, and temp.

Also the dependency files for the Upgrade program to work.

The file to launch is Upgrade.exe. If using Windows 7+ right click and run as admin.

To use the tool, enter the IP of the DVR/NVR you wish to patch, and enter the credentials.

Once you click upgrade, be a bit patient, it should take 30sec to 1 min to complete.

Check the log file in the Log folder, and scroll to the bottom to see if you get the Repair success message. (The program will have a window that appears when completed, but its in Chinese, {or scrambled text} so check the log.) If you are not successful, reboot the DVR/NVR and retry, also make sure all anti virus or internet security is paused.

This tool works the majority of the time I have used it, but there are obviously failures you can expect. In such cases as described by Jon this tool may not work, but since it is so easy to try and surprisingly effective I felt compelled to share.

Brendon - is this something you got from Dahua, or is it a tool that was developed independently?

This is a tool directly from Dahua.

Brandon,

Thanks for your addition to the discussion here. Could you tell me the method your utility uses to make these changes? Is it dependent upon Telnet being enabled beforehand? Or are you using HTTP strings via port 80?

I found a simple string to enable Telnet via HTTP and am wondering if your method would remove this ability to enable Telnet via HTTP/80?

http://192.168.1.108/cgi-bin/configManager.cgi?action=setConfig&Telnet.Enable=true

Does this work without authentication?

I would assume yes, since authentication was added in later FW. And most of the later FW with Authentication would be on >2015 FW.

No, the HTTP string I provided above requires admin creds to execute.

So what's the concern then?

My concern is that someone was able to add an admin level account to my NVR and with this set of creds, they could enable Telnet and possibly infect it. There are a lot of unknowns about the attack vector used to create these credentials to begin with. What I would like to know is if Brandon's method simply turns off Telnet, or if it permanently disables it.

I had completed log files that showed all of the executed scripts but since lost the log files.

If I use the tool in the next days I will post my Log file so you can see what is going on. Otherwise, just wait to use the tool and read the results yourself. I just wish I had a successful log file on hand so I could answer your questions.

My concern is that someone was able to add an admin level account to my NVR and with this set of creds...

If someone can add an admin level account to your NVR, the horse has already left the barn...

What if you disable Authentication in the IPC Gui?

Could you give me steps of how to do this? I am not sure I understand your question.

ONLY FOR IPC not DVR/NVR

Log into the IPC from browser.

Go to Setup

Go to Network

Go to Connection

ONVIF TAB

Authentication:

Enable is Default Toggle to Disable.

OK, that makes more sense now. You mean the ONVIF Authentication on IP cameras. We enable that setting, but also use ONVIF Manager to change the credentials from the default admin:admin.

Telnet must be enabled before hand for the tool to work.

I personally do not know many of the details involved in the code executed to remove the Telnet Function. I wish my knowledge of Linux based OS was better so I could offer more details.

However, after using the tool and checking the log files, you can see the activity going on. I am sure some of the readers on this site can offer some more details after reviewing their own log files.

Looking at this utility, it adds a Linux script to the device as below:

function kill_telnetd()
print("kill_telnetd start");
os.execute("ps > /mnt/mtd/kill_telnetd.txt");
local pf = io.open("/mnt/mtd/kill_telnetd.txt");
if not pf then
print("kill_telnetd open file failed");
return;
end;
print("kill_telnetd pf = ", pf);
local buf = pf:read();
while buf do
local s, e = string.find(buf, "telnetd");
if s and e then
s, e = string.find(buf, "root");
print("kill_telnetd = ", buf);
local pid_str = string.sub(buf, 1, s - 1);
local pid = tonumber(pid_str);
print("kill_telnetd pid = ", pid);
if pid and pid > 0 then
local cmd = string.format("kill %d", pid);
print("kill_telnetd shell cmd = ", cmd);
os.execute(cmd);
end;
end;
buf = pf:read();
end;
io.close(pf);
os.execute("rm -rf /mnt/mtd/kill_telnetd.txt");
end;

kill_telnetd();

What this does is execute the Linux command ps ( which lists the current processes ) pipes this to a file, then they do a search on this file for the telnetd ( that's the telnet daemon, that is the process / service which is telnet ) then kill it! and then goes and deletes the tempory files used for search results.

Maybe a better approach would rename the telnet application, so that it could not be run again via of the system, as from what looks like below the CGI commands may re-activate this. Telnet Daemon in itself a major security issue. But I'm not sure if this is absolutely needed for things like upgrades. I think the problem might be the Linux kernel is part of the firmware in a compressed format on flash memory, and then expanded when the system is re-started. Not being the programmer of the device I can't comments on this, but this is a common thing, where space is premium, hence the need to updates for entire part. I think moving the telnet off the default port would also help, as searching 65536 port numbers on a IP can take some time.

Also, for customers with issues connecting to internet the second the DVr/NVR is added to the network, you can fix the system without going online.

1: Log into the DVR/NVR locally and change the IP to Static. Set to an IP and Gateway Unique and Identifiable. EX: 192.168.20.108 / 255.255.255.0 / 192.168.20.1

Apply and reboot

2: Connect the DVR/NVR to a PC LAN port. (Tool only works on PC anyway)

3: Change the PC LAN to Static, and Set to EX: 192.168.20.120 / 255.255.255.0 / 192.168.20.1

This will make the DVR/NVR recognizable on the network. (pseudo crossover cable) Use Config tool to confirm.

4: Use the telnet removal tool I provided.

The fact that this CGI call works (I've confirmed it myself) is alarming in that it shows that the problem has not been truly addressed, but has only had a band-aid applied. Using this CGI call to re-enable the telnet backdoor, even if it requires authentication, will allow OS access again using credentials that have been posted as part of the Mirai code. Until this low-level OS network access is completely removed, the device will always be at risk. I don't understand why it's even there, if you need access at that level, it should be done using the RS-232 interface while onsite with the unit. This is completely unacceptable for a network "security" device and begs the question, for what purpose is this access even designed to be used?

Even Axis has similar, and show no signs of repentance.

Axis OrwellLabs Exploit Tested

My sentiments exactly!

A little further investigation: I applied a "close telnet" patch that was provided by the manufacturer (not sure if it was the same one mentioned above) and would receive a "connection refused" message upon trying to connect. However, after once again issuing the CGI string, this time using the "888888" account which is admin level but it supposed to be restricted to console only access on the unit, I was once again able to gain full OS access using telnet.

What I have found is that there are differing levels of credentials in a Dahua product, that don't always align, as you would expect them to. The UI credentials and OS credentials weren't in sync for me here. That is what caused some of the issues I had and was the reason I had to resort to RS232 to resolve the issue.

I found an additional user account named "service" that had a note on the account that said "your_device_has_been_hacked_ple".

Hacker FAIL!

Where was the Q/A here? This inadvertant truncation of the hack's only message is unacceptable.

And it's not clear to me what was intended either, perhaps:

  1. your_device_has_been_hacked_please_change_root_password
  2. your_device_has_been_hacked_please_pay_ransom
  3. your_device_has_been_hacked_pleas_ignored
  4. your_device_has_been_hacked_plenty_time_before

All these have distinct differences in intention. Number one might even be a whitish/gray hat attempt to warn those that are vulnerable.

Perhaps the problem is merely one of display; and the data is in the system. If so, I would ask anyone infected, and in the name of (computer) science, to goto the following URL in hopes of shedding some light on the true purpose of this 'hack':

http://<ip>/cgi-bin/userManager.cgi?action=getUserInfo&name=service

Thank you.

Too bad I have erased the entire config. I can only imagine the info I would have found with your HTTP string. Lol

If you truly know what would have been discovered, please share.

I truly think it would be: