Saturday, October 26, 2013

security fail: home DVR/camera systems

Many people, such as myself, decide to invest in home security camera systems.  Most of them nowadays allow you connect directly to the system via your smartphone.   As I am in the computer security field, I tend to wonder just how secure things are in my own home.  So I put my NiteOwl 16 channel DVR system to the Pepsi challenge.  It failed horribly.

Whenever I send my username and password across the internet to look at my home security cameras, the credentials are sent in clear text.  Anyone in computer security knows is a not a good thing.  Clear-text credentials are very easy to intercept.  And most people don't know how to properly defend themselves and their home against cyber threats.  So lots of people will use one password for everything.  So if someone was to intercept this DVR password, the attacker has a lot of helpful information.

The intercepted information will include:

  1. the username, which is likely the username also used in at least one of the computers on the victim's home network. 
  2. the username's password, which is also likely to be the same password on the computer mentioned above
  3. the destination IP address, which tells the attacker where you are and what to attack.  
Given how many people use the same password for everything and leave their home network devices on the default settings, sending a clear-text password can be a recipe for disaster.  So let's see which home security DVR systems failed the test.

NiteOwl - failed

Zmodo - failed

A-See Pro - failed

Q-See:  no credentials passed at first, but I can't be sure it never will since I don't have the DVR to make a valid connection.  Chances are the exchange happens after the javascript file is executed.  If I can find someone with a Q-See system, I should be able to properly verify.
Samsung:  At first it looked ok since unlike the others, it was not sending clear text passwords up front.

But then i noticed it was providing a field called "Authorization" and a value that looked like a base64 code.   So i took the code to my favorite web site for decoding base64

And there is our username/password.  Weak security, but better than nothing compared to the others.

Defender:  same thing as Samsung, just base64

Lorex - failed
Swann - failed

still testing a few more, but so far I am not impressed by any of them.

My advice for now, if you have one of these systems, make sure the password you use to connect to the system is a password you do NOT use for anything else.  Also make sure the cameras are not recording anything sensitive.  If they are, I recommend disconnecting the DVR from the internet.

Sunday, October 6, 2013

SSH PKA the easy way

this tutorial involves 2 computers, a client and a server.  As you should know, a client will connect to the server.  You can always add an ssh server to your client machine, but we aren't going to worry about that today.

on the client machine:
# cd /home/username
The username needs to be the username you are going to use to connect, and that username must exist on the server machine as well.  You can do it other ways, but that is a complication we won't get into today.
# mkdir .ssh
# chmod 700 .ssh/
# cd .ssh
# ssh-keygen -t rsa -b 2048

(some ssh servers like hardware appliances require dsa, so use ssh-keygen -t dsa in those cases)
Accept the default values and it should put the keys in the folder you just created.
# chmod 640
# chmod 600 id_rsa

# nano /etc/ssh/ssh_config
Add the following line (or uncomment the line if it already exists)
IdentityFile ~/.ssh/id_rsa
Then use CTRL-O to save and CTRL-X to exit

One the server machine:
Install the SSH server software.
For Ubuntu, use
# apt-get install openssh-server.  
For RHEl/centOS, use
# yum install openssh-server. 

Now make the folder and key on this machine as well.
# cd /home/username
# mkdir .ssh

# chmod 700 .ssh/
# cd .ssh/
# touch authorized_keys
# chmod 740 authorized_keys

Now you need to get the pub file from the client machine over to the server.  I will include a command to use SCP to transfer it using SSH.  But in general, you should always think of ways to transfer keys using out of band methods, like maybe email or USB, etc.
# scp username@client.ip.address:/home/username/.ssh/ /home/username/.ssh/
Replace username with your username and client.ip.address with the IP address of the client machine, or you can use the DNS name as long as your DNS is working.

Now that the pub key is transferred, let's lock it down and enable.
# chmod 640
# cat >> authorized_keys
# nano /etc/ssh/sshd_config

Adjust the port and other settings after you get the ssh server working.  for now, let's just get the keys working.  Look for the below settings and uncomment them and change the values as needed.   The settings below are how they should be.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys
Now use CTRL-O to save and CTRL-X to exit

Restart the server, for RHEL use:
# service sshd restart
For Ubuntu, use:
# /etc/init.d/sshd restart

Now go back to your client machine and test
# ssh ServerMachineIP
Replace ServerMachineIP with the IP of the server machine.  If you are using the same username on both machines, then you don't need to specify a username.  It assumes you are using the same username as the client machine.

If it works, you should be taken directly to a new shell with the

username@client:~$ ssh serverName
Last login: Sat Oct  5 15:45:53 2013 from
[username@serverName ~]$ 

If something goes wrong, use the logs to find out what the client and server are complaining about.

from the client machine, use:
# ssh -vvv ServerMachineIP 

From the server machine, run a tail on the logs:
# tail -f /var/log/secure
In most cases, secure is the log you need.  but if not, just google it.

If you want to connect to a different user account, all you need to do is:
- on the server machine: do the above server machine steps but instead of going to the /home/username folder, go to the user folder that belongs to user you wish to login as.  eg.  /home/Robert
- on the client machine:  just specify the username when you connect
# ssh Robert@serverMachineIP

You CAN place them in the /root/.ssh folder and connect to the server as root.  But you will need to make sure the sshd_config file is set to allow login as root.  In general, it's best to use normal accounts to login via SSH, then use the su - command (switch user) to switch to the root account.
PermitRootLogin yes