Lorex LNR360 NVR with Hikvision DS-7616NI-SE/P firmware
- Thread starter junglebell
- Start date
I do not believe that Hikvision has released the fix for the NVR, but I can verify that the european firmware for the cameras(v5.4) has the fix and works on my 2cd2032 cameras. I installed this version on my cameras a few days ago and everything is working great, with an improved interface as well. For a while now, I have the cameras managing the email alerts and not the NVR since I was able to get more options by using the motion detection options available on the cameras. My NVR simply records, that's it.
If Lorex tells you to have your ISP open 25,465,587, this is just Lorex being lazy. It is possible that they are blocked, but If they knew what they were doing they would be able to have you run a test from your home network to check if your ISP has blocked those ports. My ISP has not blocked the ports, and I was having the same problems as the rest of the world was. You can check this out by running a command like "openssl s_client -connect smtp.gmail.com:465" from a windows command prompt. If port 465 was blocked, you wouldn't get a response from smtp.gmail.com. Also, if you run "openssl s_client -ssl3 smtp.gmail.com:465", which tries to force sslv3 encryption, gmail kicks you out. Now, running "openssl s_client -tls1 smtp.gmail.com:465", forcing TLSv1 encryption, you will get a prompt from gmail.
Just more ammo, running nmap from a linux platform shows gmail ports and encryption types.
>nmap --script ssl-enum-ciphers smtp.gmail.com
Starting Nmap 6.47 ( http://nmap.org ) at 2016-07-15 13:11 EDT
Nmap scan report for smtp.gmail.com (74.125.22.109)
Host is up (0.012s latency).
Other addresses for smtp.gmail.com (not scanned): 74.125.22.108
rDNS record for 74.125.22.109: qh-in-f109.1e100.net
Not shown: 995 filtered ports
PORT STATE SERVICE
25/tcp open smtp
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
465/tcp open smtps
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
587/tcp open submission
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong
I have Lr380 8 channel model. A root password would be required to login into root of the lorex nvr for the firmware change. Would it be possible if someone can post it. What version of the hikvision would someone recommend?
Can you help me get the POE ports to work? I have successfully flashed the LNR360 NVR with Hikvision software, but want the POE to work. What do I need to do?
Hi. I can try to help. Have you flashed the cameras as well? If I recall correctly you have to fix the network settings, DNS server, and possibly mask.
Cameras have been flashed with hikvision firmware, I also purchased an additional Hikvision bullet camera. Do I need to login to the cameras via my POE router, hard code an IP address, then do that for the NVR as well? Any specific address that they NVR likes?
Chin Lee
n3wb
- Feb 9, 2017
- 3
- 0
Scottaroo02,
Can you tell me what firmware version you flashed to your LNR360? Also where you get the tftp flasher? Can you discribed briefly how you setup your update equipment? Did you use a switch with static IP and what windows version did you use?
My LNR 360 freezes randomly. I've replaced it and the new one still freezes. I have to put a timer to power cycle it twice a day to get it working 24/7.
thanks,
Chin Lee
Chin Lee
n3wb
- Feb 9, 2017
- 3
- 0
I was able to find the tftpserver. However, the LNR does not connect to the tftpserver. I set the IP of PC to to the instructions but I cant get the LNR to connect to it. I power cycle the LNR about half a dozen times. the PC and LNR are connected via a standalone switch. PC is running windows 10 with firewall disabled. Any other ideas?
Chin Lee
n3wb
- Feb 9, 2017
- 3
- 0
I've tried over 2 dozen times but it will not connect to the tftpserver. I have tried with PC connected directly to NVR. Can someone help me ? thanks.
So, a bit of a necropost here, but since this thread comes up when you google for 'lorex root password' and since I just successfully dealt with a Lorex LNR360 yesterday with a forgotten admin password, I just wanted to post that it is possible to get the Lorex root password from the unit itself. The last firmware I have for the LNR360 is 2.3.5, which is what is running on the box. Lorex now requires you call them to get a link emailed to you for upgrade firmware, but I had downloaded the official firmware update several years ago and hadn't deleted it.
First, the LNR360 is a hikvision box under the hood. This particular unit even helpfully has a real RS-232 console port on the back panel of the unit; a regular RS-232 USB adapter is all that's required, no need for a 3.3V TTL UART adapter on this particular unit, just a USB RS-232 adapter (I have two RS-232 adapters, one is DTE and needs a null modem cable, the other is DCE and doesn't). Pressing enter at the console drops you to a non-root shell.
There is a very glaring backdoor user and account on this particular NVR; at the non-root shell prompt on the console port, 'cat /etc/shadow' will get you the active MD5 hashes for both the hikvision and root accounts; the firmware changes the root password on boot, so the hash in the upgrade firmware is not the correct hash; the packaged /etc/shadow has a very well-known five-digit numeric password for root. But this password is replaced during boot. The hikvision user, while unprivileged, is a hole and, well, its password is already in the John the Ripper dictionary, so John came back almost instantly with it. It is possible to telnet in to the NVR and use the hikvision account to grab /etc/shadow for offline brute-forcing. This is also a security hole; unprivileged users shouldn't be able to read /etc/shadow!
Now, MD5 hashes haven't been secure against brute-forcing for quite a while. It took John the Ripper about an hour on my laptop to brute-force the root password. Once connected in by telnet as root, /dav2 is now readable and the runtime configuration is easily read; the admin credentials are in plain-text in this binary file.
This LNR360 system came with the LNB2153 (aka MCNB2153) cameras. Lo and behold, the root password for the MCNB2153's that came with the LNR360 is the same as the root password for the NVR. The cameras don't even have MD5 hashed /etc/shadow passwords, but use DEScrypt which took my laptop just a couple of minutes to brute-force.
Don't even ask: I'm neither going to post nor PM the password, but I will say that on the three LNR360's and ten MCNB2153's I tried here it's only six characters, and is a mix of numbers and lower-case letters. I have not seen this particular version's password posted anywhere, either; and it would not surprise me to find that each firmware version has a different one. So me posting this particular version's password is probably not very useful anyway.
In 2022, these units should not be allowed to tunnel out of your LAN for any reason; they should in fact be kept on their own sequestered VLAN segment with strict access controls to prevent them being accessed from any but authorized IP addresses and they should NOT be allowed to make ANY outbound connections (one easy thing you can do is give the unit a blank or invalid DNS server address). Here we use a good VPN setup and the 'IP Cam Viewer' application on Android and iPhone, and VLC on PC/Mac/Linux to view the cameras. The LNR360 and MCNB2153 system works great and does the job we need done (and we don't have the budget right now to buy a more secure new system), but the cybersecurity environment now is quite a bit more strict than it was ten years ago.
EDIT: And it's not just possible but very likely that the two holes I found (insecure non-root account with access to read /etc/shadow) have been fixed in newer firmware; I'm just posting what I did to obtain the access I needed to use the equipment that was purchased.
EDIT2: IT's already been posted that the new root password in plaintext is in one of the binaries in the firmware, but I wanted to see if I could get it from the unit itself. This way, if this password is firmware versions dependent, there is still a method that doesn't require a copy of that version of the firmware to use.
First, the LNR360 is a hikvision box under the hood. This particular unit even helpfully has a real RS-232 console port on the back panel of the unit; a regular RS-232 USB adapter is all that's required, no need for a 3.3V TTL UART adapter on this particular unit, just a USB RS-232 adapter (I have two RS-232 adapters, one is DTE and needs a null modem cable, the other is DCE and doesn't). Pressing enter at the console drops you to a non-root shell.
There is a very glaring backdoor user and account on this particular NVR; at the non-root shell prompt on the console port, 'cat /etc/shadow' will get you the active MD5 hashes for both the hikvision and root accounts; the firmware changes the root password on boot, so the hash in the upgrade firmware is not the correct hash; the packaged /etc/shadow has a very well-known five-digit numeric password for root. But this password is replaced during boot. The hikvision user, while unprivileged, is a hole and, well, its password is already in the John the Ripper dictionary, so John came back almost instantly with it. It is possible to telnet in to the NVR and use the hikvision account to grab /etc/shadow for offline brute-forcing. This is also a security hole; unprivileged users shouldn't be able to read /etc/shadow!
Now, MD5 hashes haven't been secure against brute-forcing for quite a while. It took John the Ripper about an hour on my laptop to brute-force the root password. Once connected in by telnet as root, /dav2 is now readable and the runtime configuration is easily read; the admin credentials are in plain-text in this binary file.
This LNR360 system came with the LNB2153 (aka MCNB2153) cameras. Lo and behold, the root password for the MCNB2153's that came with the LNR360 is the same as the root password for the NVR. The cameras don't even have MD5 hashed /etc/shadow passwords, but use DEScrypt which took my laptop just a couple of minutes to brute-force.
Don't even ask: I'm neither going to post nor PM the password, but I will say that on the three LNR360's and ten MCNB2153's I tried here it's only six characters, and is a mix of numbers and lower-case letters. I have not seen this particular version's password posted anywhere, either; and it would not surprise me to find that each firmware version has a different one. So me posting this particular version's password is probably not very useful anyway.
In 2022, these units should not be allowed to tunnel out of your LAN for any reason; they should in fact be kept on their own sequestered VLAN segment with strict access controls to prevent them being accessed from any but authorized IP addresses and they should NOT be allowed to make ANY outbound connections (one easy thing you can do is give the unit a blank or invalid DNS server address). Here we use a good VPN setup and the 'IP Cam Viewer' application on Android and iPhone, and VLC on PC/Mac/Linux to view the cameras. The LNR360 and MCNB2153 system works great and does the job we need done (and we don't have the budget right now to buy a more secure new system), but the cybersecurity environment now is quite a bit more strict than it was ten years ago.
EDIT: And it's not just possible but very likely that the two holes I found (insecure non-root account with access to read /etc/shadow) have been fixed in newer firmware; I'm just posting what I did to obtain the access I needed to use the equipment that was purchased.
EDIT2: IT's already been posted that the new root password in plaintext is in one of the binaries in the firmware, but I wanted to see if I could get it from the unit itself. This way, if this password is firmware versions dependent, there is still a method that doesn't require a copy of that version of the firmware to use.
Last edited: