Dahua responds to IoT attack - offers replacement discounts

[rotorwash]

http://www.cepro.com/article/dahua_addresses_recent_report_regarding_ddos_attack

Specific to this issue, we are offering replacement discounts as a gesture of goodwill to customers who wish to replace pre-January 2015 models. Dealers can bring such products to an authorized Dahua dealer, where a technical evaluation will be performed to determine eligibility.

Here is an article that describes the vulnerability in more detail:

https://krebsonsecurity.com/2016/10/europe-to-push-new-security-rules-amid-iot-mess/

 

[alastairstevenson]

Specific to this issue, we are offering replacement discounts as a gesture of goodwill to customers who wish to replace pre-January 2015 models.

If the underlying issue was the use of default ID/passwords, why would they offer replacement devices?
And does this imply there is another vulnerability that cannot be rectified by a suitable firmware update?
The article raises as many questions as it answers.

Members may recall that Hikvision suffered much adverse publicity after many installations using their products were found to be vulnerable due to installers not changing the default passwords, and not providing a 'strength indication' on a change.
Hence the introduction of the 'Device Activation' feature, which in my view was a good development.

 

[rotorwash]

I believe it has to do with the root passwords hardcoded in the firmware. In the article, they found the devices that were most vulnerable had firmware older than January 2015. Dahua in the article states firmware upgrades are available to authorized dealers, and in the event this is not possible, they will offer a discount on replacement.

 

[rotorwash]

For example, here is an article that discusses the hardcoded username/passwords pulled from the Mirai source code:

https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/

There are several vendors listed there, all with the hardcoded root/admin backdoor credentials.

 

[alastairstevenson]

I believe it has to do with the root passwords hardcoded in the firmware. In the article, they found the devices that were most vulnerable had firmware older than January 2015.

Exactly - so a firmware update will presumably fix that.

and in the event this is not possible, they will offer a discount on replacement.

The quote implies the discount replacement is conditional on the dealer doing the footwork, so suggesting a pre-condition that the device was sourced through an authorised channel.
But it does usefully suggest the Dahua Wiki as a self-service route.

 

[Myllerman]

Does this mean that firmware newer than Jan 2015 is "safe" (from this particular exploit).

 

[nayr]

Newer firmware requires you to set a unique password on first login and does not include the backdoor logins (888888/666666) by default..

the root login is now whatever password you setup and not a default.

The newer firmware is merely much more secure by default, meaning if you set your credentials to admin/admin its nobody's fault but your own.

If you have older firmware, go change the passwords for the backdoor logins so they are not default.. change the admin password so its not default.. oh, and DONT PUT YOUR CAMERAS ON THE INTERNET.

 

[dexterash]

Newer firmware(s) have telnet deactivated by default, but it can be enabled via an URL command - requires username&password, but if the default credentials are used -> the telnet will again be open => again a possible victim.

On the other hand, please bear in mind that these where extremely low-tech hacks, yet they affected an unknown (for now) number of devices. From our monitoring, there are many more that haven't been yet infected. Yet...

There are hundreds of thousands of [DAHUA's] devices across the world that use default admin:admin credentials (or the other ones; or vulnerable to login bypass). And we have yet to see (at, least for now) how the newer devices can be attacked.

Be cautious and do your due diligence.

On a laughing note, check this [ where DAHUA advices into disabling features that people bought/paid for ]:
http://www.dahuasecurity.com/best-practices.html
http://www.dahuasecurity.com/us/best-practices.html

 

[dexterash]

If you have older firmware, go change the passwords for the backdoor logins so they are not default.. change the admin password so its not default.. oh, and DONT PUT YOUR CAMERAS ON THE INTERNET.

On older firmware(s), telnet passwords are kind-of-read-only; they can only be changed via a software update/patch.

 

[nayr]

using, let alone exposing telnet over the internet should be a sin by now.. mebe its time for residental ISP's to start nailing it down like they did with mail servers and windows domain services heh.

 

[dexterash]

I thought of that too - but I don't find it the best way... heck, we can change telnet ports and the whole "protection" goes down the drain. Bare in mind that there are very fast Internet scanners ( ZMAP/ Masscan) that can find a whole bunch of things in a very short time.

But... is telnet different from unsecured HTTP (& exploitable web pages/configs) or JSON calls made via HTTP? I doubt it's a protocol problem - seems to be more of an "approach" problem.

The whole telnet / SSH open / unsecured / exploitable brings me back to 1995-2000 - when Linux first started to appear as a server solution on a large scale. And the IoT devices are, for now, at the same level. But... now we have 100Mbps+ or Gbps residential connections, not 48-128kbps.

 

[nayr]

preaching to the chior brotha

the approach has been embedded into the name of the industry, Closed Circuit TV.. as long as you physically secured the infrastructure the devices were reasonably secure.. unfortunately that mindset has not really changed.

plugging them into a IP network with other devices kinda defeats most of that inherent security; then putting them on the internet with a billion other devices really just throws it all away as now they are very capable worldwide broadcasting devices.

 

[dexterash]

We have to adapt - no problem with/in that. It's called an evolution and it should be ok. But there are good ways to adapt and silly/bad/childish/money losing/privacy lost way to adapt.

 

[alastairstevenson]

On older firmware(s), telnet passwords are kind-of-read-only; they can only be changed via a software update/patch.

Yes, but not always - it depends on the running environment of the device.
It's very bad security practice to embed any credentials in firmware code where the world can see it, but not uncommon.
Hikvision store the telnet / SSH password in the device configuration, stored in flash, though just recently encrypted, not now in plaintext, and run almost entirely in RAM.
A couple of recent camera brands I've explored though have used a mixed approach with a rw file system and the classic Linux method (so available for inspection in the firmware), and are changeable directly.
This, for example, survives a reboot:

ubi0:rootfs on / type ubifs (rw,sync,relatime)

alastair@PC-I5 ~ $ telnet 192.168.254.17
Trying 192.168.254.17...
Connected to 192.168.254.17.
Escape character is '^]'.

Ipcamera login: root
Password: 
# whoami
root
# passwd
Changing password for root
New password: 
Retype password: 
Password for root changed by root
# mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,sync,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=53172k,nr_inodes=13293,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,relatime)
tmpfs on /run type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
ubi1:upgrade on /hs/upgrade type ubifs (rw,relatime)
ubi1:param on /hs/param type ubifs (rw,relatime)
ubi2:user on /hs/user type ubifs (rw,relatime)
#

 

[dexterash]

You are right, but r/w filesystems [ that are not memory maped / temporary ] pose other problems:
1. They are exposed to filesystem failures
2. They are the perfect ground to be infected. When the space is limited or the r/w partition is small, there is a chance that the malware doesn't fit (we've already seen it - check this: https://evosec.eu/new-iot-malware/ ). When all space available can be used to make the malware permanent... trouble incoming - sooner or later.

 

[alastairstevenson]

2. They are the perfect ground to be infected.

Agreed.
Many QNAP users discovered the hard way after being hacked (various high-severity Linux vulnerabilities) that even re-initialising the device didn't clear the changes that had been written into the system flash, which is rw when transiently mounted during bootup.

1. They are exposed to filesystem failures

Agreed again.
I suspect that's one of the underlying causes of the Huisin Mini PTZ 'bricked' cameras - those I've seen have had flash contents overwritten. Too easy to do.
CRAMFS as used by Hikvision does have some merit from the robustness viewpoint, if not the modding viewpoint.

 

[TVT73]

I have noticed over the weekend and in the last days on one of my cams a massiv try to connect to admin account. I have activated mailing for login fails, but it was terrible, that the account has bee locked out most over the day. Now i use seperate accounts...
But this is a nice way to lock out user. I hope my password is good enough, but here is the next security problem of dahua, they don´t accept special carracter! Only letters and numbers is´t good enough today.

 

[rotorwash]

I have noticed over the weekend and in the last days on one of my cams a massiv try to connect to admin account. I have activated mailing for login fails, but it was terrible, that the account has bee locked out most over the day. Now i use seperate accounts...
But this is a nice way to lock out user. I hope my password is good enough, but here is the next security problem of dahua, they don´t accept special carracter! Only letters and numbers is´t good enough today.

Have you looked at implementing a VPN? OpenVPN is pretty awesome and it has clients for mobile devices as well as many OS. At the very least, can you change the port forward for the web port to something different for the time being?

 

[dexterash]

Bruteforce can't happen - or, at least, not in a reasonable amount of time. After 3 (or 5) tries, the account will be locked for about ~30 minutes. That means, at max, 240 tries per day.
6 chars passwords yeld around 50 milion possible combinations (a-zA-Z0-9)...

 

[nayr]

another possible attack vector is the password reset tool, I dont have access but they link to it on the wiki: http://dahuawiki.com/Password_Reset

obviously, like Hikvision.. they have the ability to generate a login for any device regardless of its existing credentials..

if the method for generating these logins gets reverse engineered it could make trivial to hack into em, especially over something like p2p that shares serial/mac info with foreign servers.