February 2, 2017
This is Part 3 of the series implementing IoT securely in your company, click here for part 1 and here for part 2. As it is quite common that new IoT devices are ordered and also maintained by the appropriate department and not by the IT department, it is important that there is a policy in place.
This policy is specially important in this case as most non IT departments don’t think about IT security and maintaining the system. They are often used to think about buying a device and it will run for years and often even longer, without doing much. We on the other hand in the IT know that the buying part is the easy part, maintaining it is the hard one.
Extend existing security policies
Most companies won’t need to start from scratch, as they most likely have policies for common stuff like passwords, patching and monitoring. The problem here is the scope of the policies and that you’re current able to technically enforce many of them:
- Most passwords are typically maintained by an identity management system and the password policy is therefore enforced for the whole company. The service/admin passwords are typically configured and used by members of the IT department. For IoT devices that maybe not true as the devices are managed by the using department and technically enforcing it may not be possible.
- Patching of the software is typically centrally done by the IT department, be it the client or server team. But who is responsible for updating the IoT devices? Who monitors that updates are really done? How does he monitor that? What happens if a department does not update their devices? What happens if a vendor stops providing security updates for a given device?
- Centrally by the IT department provided services are generally monitored by the IT department. Is the IT department responsible for monitoring the IoT devices? Who is responsible for looking into the problem?
You should look at this and write it down as a policy which is accepted by the other departments before deploying IoT devices. In the beginning they will say yes sure we’ll update the devices regularly and replace the devices before the vendors stops providing security updates – and often can’t remember it some years later.
Typical IoT device problems
Beside extending the policies to cover IoT devices it’s also important to check the policies if the fit the IoT space and cover typical problems. I’ll list some of them here, which I’ve seen done wrong in the past. Sure some of them also apply for normal IT server/services but are maybe consider so basically that everyone just does it right, that it is maybe not covered by your policy.
- No Update is possible
Yes, there are devices out in the wild that can’t be updated. What does your policy say?
- Default Logins
Many IoT devices come with a default login and as the management of the devices is done via a central (cloud) management system, it is often forgotten that the devices may have also a administration interface.What does your policy say?
- Recover from IoT device loss
Let’s assume that an attacker is able to get into one IoT device or that the IoT device gets stole. Is the same password used on the server? Do all devices use the same password? Will the IT department get informed at all? What does your policy say?
- Naming and organizing things
For IT devices it’s clear that we use the DNS structure – works for servers, switches, pc’s. Make sure that the same gets used for IoT device. What does your policy say?
- Replacing IoT devices
Think about > 100 IoT devices running for 4 years and now some break down, and the the devices are end of sales. Can you connect new models to the old ones? does someone keep spare parts? What does your policy say?
- Self signed certificates
If the system/devices uses TLS (e.g. HTTPS) it needs to be able to use your internal PKI certificates. Self signed certificates are basically the same as unencrypted traffic. What does your policy say?
- Disable unused services
IoT enable often all services by default, like I had a device providing a FTP and telnet server – but for administration only HTTP was ever used. What does your policy say?
I hope that article series helps you to implement IoT devices somewhat securely.
January 12, 2017
After Part 1 which focused on setting up your network for IoT this post focus on making sure that the devices are the right ones and that they work in your network. The first can be accomplished by asking basic security questions and talking only with the more secure vendors further. In my experience that also leads to the better vendors which know IT and whom will make your life easier in the long run. There are plenty of vendors out there for whom the whole IT part is new as they are an old vendor in a given field which now needs to do the “network thing” and don’t have the employees for it. Johannes B. Ullrich at SANS ISC InfoSec came up with the idea to preselect IoT vendors with 5 questions. (You can read more on his reasoning behind each question in his post):
5 preselect questions
- For how long, after I purchase a device, should I expect security updates?
This time frame will show us how long we can plan to use the device in our network, as using devices which get no security updates will be a compliance violation in most companies.
- How will I learn about security updates?
Responsible vendors will add you to a security mailing list where you will get informed on all security related stuff via email.
- Can you share a pentest report for your device?
If the vendor cares at all at security he let an external expert make a pentest, which will at least find the worst and stupid security holes. If the vendor is able to show you such an report, you should really take that vendor in consideration.
- How can I report vulnerabilities?
We often found security holes in programs or devices and sometimes it is really hard to report that to the vendor in a way he accepts it and fixes the hole in a reasonable time frame. Sometimes we needed to go via our local Austrian CERT and sometimes that even was not enough as the vendor was in the US and only did something after their CERT asked them pointed questions. So a direct connection the guy(s) responsible for the security of device is important.
- If you use encryption, then disclose what algorithms you use and how it is implemented
If the vendor tells you something about “Proprietary” run away from the product! If you read that they use MD5 or RC4, the software on the device seems a little bit dated.
After selecting the best vendors ranked by the preselect questions you should make sure that the devices will run in your network. If you’re new to this kind of work you will not believe what garbage some vendors deliver. Some points are connected to your network and how it will look in the future.
- The device needs to support DHCP!
- Use DHCP reservations to provide fixed IP addresses
- Special case in a secure network is to disable ARP learning on the Layer 3 switches (makes MitM attack a lot harder). In this case DHCP is used for filling the ARP table.
- Check if the device will work with MAC oder 802.1x authentication flawlessly
- Some devices only send a packet if queried, which won’t work if the device got de-authenticated e.g. idle timeout or network problem. The device needs to send a packet ever so often so the switch sees the MAC address and can make a RADIUS request.
- The devices needs to support routing
- We had devices that where only able to talk within the subnet. In some cases we were not sure if the product really didn’t support it or just the technician was unable to configure it.
- As the PCs and servers need to be separated via a Firewall (see Part 1), this feature is a deal breaker
- It should be possible to configure a local NTP Server
- If not, the device time runs off or you need to allow the device to connect to the Internet, which can get complicated or insecure if you’ve different devices each using an other NTP server
- The devices needs to support automatic restart of services after power or network outage
- We had some devices which needed manual interventions to reconnect to the servers again after a network problem
- Embedding of external resources should be looked at. e.g. If a device needs jquery for its web GUI and lets the browser load that via jquery.org it will not work it your Internet is down. In some cases that does not matter, in some thats a deal breaker.
- support of 1Gbit Ethernet connection
- Sure I know that IoT devices do not need 1Gibt, but the devices will maybe run 10 years and you’ll have 10Gbit switches by than. It is not sure that 100Mbit will be supported or work flawlessly. e.g. Some current Broadcom 10Gbit chipsets don’t support 100Mbit half duplex anymore. You need an other chipset which is a little bit more expensive .. and you know what switch vendors will pick? 😉
So so far for part 2 of this series … the next part will be on some policy stuff you need to agree with department wanting that devices.
January 6, 2017
The last articles in this blog about IoT (often called Internet of Targets 😉 ) where about a specific cam or about IoT at home. This article series will be different, it will focus on the IoT in companies. Part one will talk about what you need to in order to prepare your network for IoT.
Prepare your network for IoT
There are 2 kinds of IoT devices/setups:
- ones that are directly connected to your network (e.g. house automation, access systems, …)
- ones that are connected via a mobile operator via GPRS, LTE, …. (e.g. car traffic counter, weather stations, webcam at remote places, …)
For the first ones it is a good idea to implement a separate virtual network, which means the traffic from and to the IoT devices always goes over a firewall before going to your servers or PCs. A normal company network should have following separate virtual networks outside the data centers.
- external Clients / visitors
- services = IoT
All those networks are connected to each other via a firewall and only required ports are opened. This separation is not arbitrary as it runs along some important differentiating factors:
- You’re PCs are normally centrally managed (monthly software updates, no administrator privileges for the users, …) and are allowed to access many and critical servers and services. Also there is normally no communication needed between 2 PCs, so you can block that to make an attacker the lateral movement harder/impossible.
- The VoIP phones need QoS and talk directly which each other, as only SIP runs to the server, the (S)RTP media streams run between the phones – peer to peer.
- Let’s face it, nobody installs software updates on their printers, but they are full computers often with Windows CE or Linux. So like IoT devices we need to contain them. Also one printer does not need to talk to an other printer – block printer to printer traffic.
So lets talk about the IoT network:
- Put the servers of IoT devices (if they are not fully cloud based) into you’re data centers in the proper DMZ.
- IoT normally don’t talk directly which each other as the don’t require that the different devices are in the same network at all. So I highly recommend to block client 2 client traffic also in the IoT network. This blocking is important as if an attacker got his hand on one device, he cannot exploit wholes in other IoT devices by simply leap frogging from the first.
After you got your internal IoT network set up we take a look at the devices you need to connect via a mobile operator. First it is never a good idea to put IoT devices directly onto the Internet. Sure you can can use a VPN router for each IoT device to connect back to your data centers, but there is an easier way if you’ve more than a few devices. Most mobile operators provide a service that contains following:
- separate APN (access point name in GSM/UMTS/LTE speech) which allows authorized SIM cards to connect to a private non Internet network
- you can choose the IP range of this special mad-for-you network
- Each SIM card gets assigned a fixed IP address in this network
- IPsec tunnel which connects the private network to you data center(s)
Here in Austria you pay a setup fee and monthly for the private network but the SIM cards and the cost for bandwidth are basically the same as for normal SIM cards which connect to the Internet. I recommend to choose 2 providers for this kind of setup as it will happen that one as a bad coverage at a given spot. With this network and the fixed IP addresses it is quite easy to configure the firewall securely.
The next part will take a look at the policy for implementing new IoT devices, on making sure that the devices are the right ones and that they work in your network.
December 29, 2016
There are many articles on how to use Metasploit or some other mighty stuff that is fine if you work with it all day. But if you just found a MySQL server on an appliance listening in your network and need to do a fast small security check there is something easier. First find the MySQL server and check the version – maybe there is a exploit available and you don’t need to try passwords. The first choice for this is nmap, just install it with
sudo apt-get install nmap and call it like this:
# nmap -sV -O <IP>
Starting Nmap 7.01 ( https://nmap.org ) at 2016-xx-xx xx:xx CET
Nmap scan report for hostname (<IP>)
Host is up (0.020s latency).
Not shown: 986 closed ports
PORT STATE SERVICE VERSION
3306/tcp open mysql MySQL 5.6.33-79.0-log
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.0
Network Distance: x hops
You need to call it as root with these options. The -sV shows the versions of the listening services and -O guesses the operating system. For brute forcing we need 3 things
- a list of usernames to try
- a list of passwords to try
- a software that does the trying
The first is for one thing quite easy as the default users are known and you maybe know something about the system .. like software name or vendor name or the online download-able manual shows the username. So lets write the file:
$ cat > usernames.txt
Now we need a list of likely passwords .. sure we could think about some by our own, but it is easier to download them. A good source is Skull Security. Choose your list and download it and extract it with
bunzip2 xxxxx.txt.bz2. Now we only need the software … we’ll use THC Hydra, but you don’t need to download it there and compile it, as Ubuntu ships with it. Just type
sudo apt-get install hydra. Now we just need to call it.
$ hydra -L usernames.txt -P xxxxx.txt <ip> mysql
Hydra v8.1 (c) 2014 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2016-12-29 14:19:38
[INFO] Reduced number of tasks to 4 (mysql does not like many parallel connections)
[DATA] max 4 tasks per 1 server, overall 64 tasks, 86066388 login tries (l:6/p:14344398), ~336196 tries per task
[DATA] attacking service mysql on port 3306
[STATUS] 833.00 tries/min, 833 tries in 00:01h, 86065555 todo in 1721:60h, 4 active
I think this password list is too long 😉 Choose a shorter one 😉
November 18, 2016
If you know Mikrotik Routers you know that you’re able to access them via MAC Telnet (see here for more details) via Layer2 with Winbox. But running Winbox via Wine on a Linux is not that great for using MAC Telnet, and there is a better way .. just use MAC-Telnet from Håkon Nessjøen. On Ubuntu/Debian you can just install the package with
sudo apt-get install mactelnet-client
and you see its feature like this:
$ mactelnet -h
Usage: mactelnet <MAC|identity> [-h] [-n] [-a <path>] [-A] [-t <timeout>] [-u <user>] [-p <password>] [-U <user>] | -l [-B] [-t <timeout>]
MAC MAC-Address of the RouterOS/mactelnetd device. Use mndp to
identity The identity/name of your destination device. Uses
MNDP protocol to find it.
-l List/Search for routers nearby (MNDP). You may use -t to set timeout.
-B Batch mode. Use computer readable output (CSV), for use with -l.
-n Do not use broadcast packets. Less insecure but requires
-a <path> Use specified path instead of the default: ~/.mactelnet for autologin config file.
-A Disable autologin feature.
-t <timeout> Amount of seconds to wait for a response on each interface.
-u <user> Specify username on command line.
-p <password> Specify password on command line.
-U <user> Drop privileges to this user. Used in conjunction with -n
-q Quiet mode.
-h This help.
So lets give it a try, first with searching for my home router
$ mactelnet -l
Searching for MikroTik routers... Abort with CTRL+C.
IP MAC-Address Identity (platform version hardware) uptime
10.x.x.x 0:xx:xx:xx:xx:xx jumpgate (MikroTik x.x.x. xxxx) up 139 days 5 hours XXXXX-XXXX vlanInternal
and then we’ll connect
$ mactelnet 0:xx:xx:xx:xx:xx
and we’re connected.
November 14, 2016
I’ve some info for you, if you’re running Mikrotik RouterOS in a version below 6.34rc45 and are using a tunnel (like IPIP over IPsec). If you don’t boot the router for about 248 days, your router will get inaccessible. This is specially bad if your routers are in remote locations and you’ve got multiple routers with the same updates ( like > 100 😉 ) as you did the firmware update at the same time.
The changelog for the 6.34rc45 version states the problem, but it doesn’t tell you that the router is offline and can only be accessed via serial cable.
*) tunnel – fix complaining about loop after ~248 days;
If you look into the log via the serial port you’ll see
07:21:13 interface,info tunnel_1 link down
07:21:13 interface,info tunnel_2 link down
07:21:13 interface,info tunnel_3 link down
07:21:13 interface,info tunnel_4 link down
07:21:14 interface,warning tunnel_1 transmit loop detected, downing interface for 60 seconds
07:21:14 interface,warning tunnel_2 transmit loop detected, downing interface for 60 seconds
07:21:14 interface,warning tunnel_3 transmit loop detected, downing interface for 60 seconds
07:21:14 interface,warning tunnel_4 transmit loop detected, downing interface for 60 seconds
and nothing else. 😉
If you’re running an affected version you need to reboot before reaching 35 weeks or upgrade to a new version.
October 2, 2016
You ask why you should need this at all? Easy, sometimes a tcpdump is not enough or not that easy to use:
- You want to check the TTL/hop count of BGP packets before activating TTL security
- You want to look at encrypted SNMPv3 packets (Wireshark is able to decrypt it, if provided the password)
- You want to look at DHCP packets and their content
Sure, it’s quite easy to sniffer on a remote Linux box with tcpdump into an file and copy that that over via scp to the local system and take a closer look at the traffic. But getting used to the feature of my Mikrotik routers to stream traffic live to my local Wireshark, I thought something similar must also be possible with normal Linux boxes. And sure it is.
We just use ssh to pipe the captured traffic through to the local Wireshark. Sure this is not the perfect method for GBytes of traffic but often you just need a few packets to check something or monitor some low volume traffic. Anyway first we need to make sure that Wireshark is able to execute the dumpcap command with our current user. So we need to check the permissions
-rwxr-xr-- 1 root wireshark 88272 Apr 8 11:53 /usr/bin/dumpcap*
So on Ubuntu/Debian we need to add ourself to the wireshark group and check that it got applied with the
id command (You need to logoff or start a new sesson with
su - $user beforehand). Now you can simply call:
ssh [email protected] 'tcpdump -f -i eth0 -w - not port 22' | wireshark -k -i -
And now the really cool part comes. I’m using Ubiqity Unifi access points in multiple setups and I sometimes need to look at the traffic a station communicates with the access point on the wireless interface. With that commands I’m able to ssh into the access point and look at the live traffic of an access point and a station which is hundreds of kilometres way. You can ssh into the AP with your normal web GUI user (if not configured differently) and the bridge config looks like this
BZ.v3.7.8# brctl show
bridge name bridge id STP enabled interfaces
br0 ffff.00272250d9cf no ath0
You can choose one of that interfaces (or the bridge) for normal IP traffic or go one level deeper with wifi0, which looks like this
ssh [email protected] 'tcpdump -f -i wifi0 -w -' | wireshark -k -i -
That’s cool!?! 😉
September 17, 2016
It is good practice to configure an individual MD5 password for each BGP peer, but this is not enough. Why?
- Resource consumption attacks against TCP connections protected with MD5 as the router must verify the MD5 signature of packets it receives
- Many routers are based on Linux as there base operating system and there is a weakness which allows an attacker to insert arbitrary data into TCP connection. For more details click on this link.
The classical BGP TTL security is based on using a low TTL, generally 1, for single-hop BGP connections. The measure is effective in preventing a BGP connection from being established from a peer more than one hop away. Why? routers decrement the TTL when routing the packets and won’t route packets with a TTL of 1. So if your BGP session is a multi hop connection over one router a TTL of 2 makes sure the packet travels only over one router and not more. That sounds fine but has still has a drawback, as packets with a TTL of 1 are trivial to spoof, so rogue packets will still reach the router – leading to the problems described above.
GTSM (Global TTL Security Mechanism; RFC 5082, which obsolated RFC 3682) suggests the opposite approach. Instead of using a TTL value of 1, it suggests a value of 255 and discarding any packets received with have a TTL lower than 255 minus the hop count for this BGP session. Doing that an attacker is not able to perform the attack as the TTL gets decremented by every router (something the attacker can’t prevent). So setting the TTL on the router to 255 and having no multi hop BGP session allows to drop all packets on the receiving router which are lower than 255. This way only an attack in the same subnet is possible.
After the theory here the actual doing:
For Cisco routers is quite easy, just add
ttl-security hops 1 (for a BGP session in the local subnet) to the peering config
neighbor x.x.x.x command. For Mikrotik routers it is a little more complicated. For IPv4 connections configure following (should be default anyway):
/routing bgp peer set 0 ttl=255
For dropping incoming packets just use the firewall on the Mikrotik with a command like this:
/ip firewall filter add action=drop chain=input log=yes log-prefix="RFC 5082 block" src-address=xxx.xxx.xxx.xxx ttl=less-than:255
For IPv6 it is a little more complicated as setting the TTL for bgp peer configuration does have no effect (I’ve reported the bug already) but there is a simple workaround possible. Just use the mangle function of the firewall to set the correct hop count:
/ipv6 firewall mangle add action=change-hop-limit chain=output dst-address=xxx:xxx:xxx::xxx/128 new-hop-limit=set:255
Now you need only to filter the IPv6 packets:
/ipv6 firewall filter add action=drop chain=input log=yes log-prefix="RFC 5082 block" src-address=xxx:xxx:xxx::xxx/128 hop-limit=less-than:248
This configuration is quite easy and minimal invasive but should help a lot against attacks on your BGP routers.
August 3, 2016
Today I cam across some not well done encryption. To be exact I surfed the website of the German news magazine Der Spiegel and clicked on an article that was of the type Spiegel Plus. That type is indicated by this logo:
Scrolling down after some paragraphs I saw following:
That’s some kind of pay wall. Lets take a look at the source code of the page with the Firefox Web Developer tools. Using the Inspector and clicking on the blurred paragraph I get to following CSS
Ok readable … but that does not look like German …. but it looks like a ROT13 algorithm, which is is a simple letter substitution cipher that replaces a letter with the letter x (in the case of ROT13 x=13) letters after it in the alphabet. ROT13 is a special case of the Caesar cipher, developed in ancient Rome. Lets try some ROT variations. As I was just playing around I used a website for this and clicked through it … and I took until ROT25 get readable text.
That was too easy … under 10 minutes to get the clear text. I can’t be the first one … and I’m right … there is a Firefox plugin on Githup. So it seems this is common knowledge already. Searching the German web I found that one blogger also from Austria already reported it to Spiegel, some Weeks ago … maybe ITIL does not allow a change ;-).
July 8, 2016
I’ll reached out to the company which got back to me today and told me that they are working on fixes for the problems. I’ve also changed my cam from wired to wireless mode today and the app sent the wpa2 password via UDP to the Internet in the clear – I’m glad I used a separate SSID and password for this ;-). I also reported that info to the company.
In my last blog post I’ve written about IoT devices and their bad security and what you can do to mitigate that on a network level – what I didn’t know that I would have such a device in my hands only days later.I did get my hands on a HiKam A7 IP cam, which is at the German Amazon Store the number one product for surveillance cams – so not a nobody. At the end I’ll found 5+ security problems in 2 hours looking at it, but keep on reading for the details. 🙂
As first act I’ve installed the app you need for configuring the cam in the first place. At first start you need to create a user, which should/must be unique per mobile / tablet. Looking at the network traffic I saw a HTTP request to api4.cloud-links.net and guess what was the content of that POST request?
Yes, that seems to be the user name and password in an effort to check if the username is already taken. The Pwd parameter is 32 chars long and looks like hex …. that couldn’t be MD5? Lets ask crackstation.net
Yes! Sure its unsalted MD5 and the password matches. So here are the first 2 security related errors … no HTTPS and than unsalted MD5 over an Internet connection. Something funny – you need to enter the password twice to guard against typing errors … both values are send to the server in the clear …. why not compare them on the client and send the request only if they match? of course also via HTTP and not HTTPS
So the account is also created with an MD5 password – which leads to the third security related problem …. customer passwords are stored as unsalted MD5 in the database … for years now we should know that that’s bad.
Ok, we got an UserID and soon after the app starts sending UDP packets to Chinese server (cloudlinks.cn) … let’s convert the UserID to hex, maybe we find it again
and of course we find it again in the UDP packets
So the userID is also send in the clear every few seconds and is only a 32bit integer … not hard to guess for an attacker – third security related error. So this userID seems to be something important, lets call that registration function multiple times with curl and look at the answers.
one minute wait
Oh yeah, the UserID are assigned sequentially for each registration and provided to the user and used later by the client …. not a good idea .. lets call it fourth security related error
So lets stop looking at the app and take a quick look at the cam it self …. first a nmap scan:
PORT STATE SERVICE VERSION
554/tcp open rtsp?
5000/tcp open soap gSOAP soap 2.8
MAC Address: 4A:81:49:xx:xx:xx (Unknown)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.2
Network Distance: 1 hop
hm … RTSP ….. let’s take a look with VLC to check if there is a username/password required
Of course there is no password required, everyone in the same network or who is able to connect port 554 can look at the video (There is no option in the app to configure a RTSP password). So the next security problem is that there is no authentication required at all for RTSP, fifth security problem. As my router has UPNP disabled I did’t check if the cam would open port 554 on the router.
Interesting, I could not find the MAC vendor – even online. Anyway looking at the traffic the cam sends to the Internet, it seems to talk at once after booting to the same UDP port the app does – even the same IP address, but an other DNS name.
a look at the UDP packet shows that the device ID (printed on the cam) in hex is at the same place of the packet as the UserID is:
I could find an authentication between the cam and the cloud servers …. but maybe I missed something … but as I’m not 100% sure I’ll won’t count it. 😉
Ah there is also a button in the app for a firmware update of the cam …… and of course its HTTP and not HTTPS …. easy code inject? I couldn’t find a signature for the file to protect against it, but I didn’t try it so I’ll also don’t count it.
Here is the link to the firmware file, I couldn’t resist an fast check of the file:
$ binwalk npcupg_13.00.00.90.bin
DECIMAL HEX DESCRIPTION
32 0x20 JFFS2 filesystem, little endian
2998728 0x2DC1C8 ELF 32-bit LSB executable, ARM, version 1 (SYSV)
3002209 0x2DCF61 LZMA compressed data, properties: 0x03, dictionary size: 524288 bytes, uncompressed size: 196608 bytes
so lets take a look at the filesystem by mounting the jffs2 file system in RAM.
# modprobe mtdram total_size=32768 erase_size=256
# modprobe mtdblock
# dd if=20.jffs2 of=/dev/mtdblock0
5869+1 records in
5869+1 records out
3005295 bytes (3,0 MB) copied, 0,026426 s, 114 MB/s
# mount -t jffs2 /dev/mtdblock0 /mnt/
but that’s for an other time …. the blog post is already really loooooong. There seem to be much more possibilities to hack that cam. It even seems possible to access cam from others, as the authentication is only based on one or two 32bit values. But looking at that more deeply would take more than 2 hours (without writting this post itself)