The Vera Community forums have moved!

Advanced => Security => Topic started by: umtauscher on April 24, 2010, 05:46:40 am

Title: Vera Hijacked by update to 1.0.994
Post by: umtauscher on April 24, 2010, 05:46:40 am

I have another serious security concern. This is quite technical but I think the people involved will understand it anyway.

During the update from 988 to 994 my vera got hijacked. I found that some of my scenes where not working any more. Those scenes had some loop statement that addressed another of my network devices by using a wget command. The device I addressed was in my local network and the ip was resolved by my local dns.

After the update this internal device was resolved by the vera to an external address that I don't know and has nothing to do with my network.

By investigating the issue I found, that the update inserted and external name server into the resolv.conf file so that every name request by vera was first propagated to "

AGAIN I would consider this a severe security breach by MCV. This external nameserver is nowhere shown in the user interface in fact this nameserver is put in front of the configured one so every request can be hijacked by someone out of out control.

I will now will again completely firewall my vera. Great work! I pity the poor people who don't understand what you are doing...

Title: Re: Vera Hijacked by update to 1.0.994
Post by: mikeholczer on April 24, 2010, 10:39:56 am
I agree that it should be documented, but you shouldn't be using domain names that you don't own, even within a local/closed network. If you don't trust the DNS system (which is fine, there are vulnerabilities in it) you should only make connections via SSL. wget supports https, so if you are as security focused as your posts imply you should get/generate certs for the system you are connecting to and use a secure protocol.

I don't mean to dismiss you concern, but it seems that you consistently are blaming others for security issues that you could mitigate on your own. The bottom line is that unless you build all your hardware and compile all software you use from source code (that you have read) you have treat it as an untrusted system and put other mitigating controls in place.
Title: Re: Vera Hijacked by update to 1.0.994
Post by: mikeholczer on April 24, 2010, 10:49:39 am
I guess my main issue with you post, is that you took an aggressive tone. The proper way to discuss a security issue would be a calm message to MCV in private first. The message you posted would have been appropriate had you attempted to contact them in private several times for a week and got no response.
Title: Re: Vera Hijacked by update to 1.0.994
Post by: umtauscher on April 24, 2010, 02:24:27 pm
I agree that it should be documented, but you shouldn't be using domain names that you don't own, even within a local/closed network.
First of all, let me apologize for the harsh tone. I'm really sorry.

Neither the internal domain name nor the device name I use for my internal network are part of the public domain name system. Despite of that  delivered an IP-address in a public zone.
But that really isn't the point here.

What really makes me sort of mad is the fact, that an public ip-address gets set in a rather global config file as resolv.conf without anybodies concern. The so called QA even didn't realize the change I suppose.

So anyway, sorry again.


Title: Re: Vera Hijacked by update to 1.0.994
Post by: micasaverde on April 24, 2010, 04:16:51 pm
umtauscher, I'm confused about your security concern.  The DNS servers in resolv.conf are used only when the Linux networking system needs to resolve a domain name.  Whether the first entry in resolv.conf is your ISP's DNS server, or an OpenDNS DNS server, either way it doesn't seem like it would have any effect on Vera's ability to resolve internal names on your network, right?  I mean if the name "ABCxyz" doesn't resolve and the Linux networking on Vera goes to a DNS server to resolve it, whether the DNS server is the normal one from your ISP or from OpenDNS, either way it's not going to resolve to your internal network address, right?

But let's assume that you somehow do have a deal with your local ISP so that they resolve domain names to your internal addresses, or that you're running your own DNS server through your gateway, I still don't get how this is a security risk.  Vera is retrieving files (ie making an outbound connection) from the network, such as an IP camera.  So, if you create a name like: 'garage_camera', and Vera uses OpenDNS and resolves that name to a public IP, it seems the only result is that you won't see the camera since the wget will fail, right?  How is this a security risk?  How is that going to allow a hacker to get into your network and hijack your Vera as you suggest?

Now I wasn't involved with the change to add OpenDNS, and I'm not saying it's the right call to put it in resolv.conf ahead of other DNS servers...  But, it seems that as far as security goes, it's very unlikely that a global, trusted DNS provider like OpenDNS is going to be hijacked and return hacked IP addresses.  It's far more likely that if you live in a small town and maybe have a small ISP that your local ISP's DNS server could be hijacked.  So it seems using a trusted global DNS server is more secure than using whatever DNS server your local ISP has.

As I said I'm not all that familiar with the change (another dev handles the Linux networking stuff), but I remember we got a very angry call from a customer who couldn't access Vera in his vacation home and he had to go back to it to troubleshoot (something along those lines--I wasn't on the call).  Anyway, after hours of talking him through telnet, etc., the problem was that his ISP's DNS server went down so the name wasn't resolving, and, also, it wasn't updating his system time because the time server wasn't resolving, etc., and the customer was furious that we didn't put a known-good DNS server in the config file automatically.  So, I think that was what predicated the need for having an 'always on' DNS server, and illustrates the problem that you can't please all the people all the time.

You'll probably counter that and say "well there should be an option for specifying custom DNS settings"...  But, consider our target audience.  We're trying to make a simple home automation device for a mainstream, non-techie consumer.   Vera is definitely not positioned an IT networking product, like a managed switch.  So, if we put in the setup wizard a step for "Now let's configure your custom DNS settings", our target customer and the 99.9% of our users who have no idea what that even is will be totally turned off by the product and claim it's way too techie for them.  The fact is that if anything Vera is too technical and we're doing everything we can to reduce the 'tech stuff'--not increase it.  None of our competing products, like the Schlage LiNK, etc., even let the user do so much as assign a static IP.  They all provide *no* networking options at all.  So I don't really agree that the best place for us to focus our development resources is on building a user interface to allow users to create custom DNS servers.  While I wasn't involved in the decision to use OpenDNS, and question putting it first in resolv.conf, I can say that I definitely agree with the idea that Vera should have some 'default' network settings that improve reliability and make it easier for the 99.9% of our users who don't want to know what a DNS server is but just want to know that when they go to turn on the heat in their home that they will be able to even if their ISP is having some technical problems.

In any event, send an email to cj [at] micasaverde [dot]com since he's the one who handles the IT stuff in Vera and would know why OpenDNS was put in resolv.conf and what the reasoning was behind it.
Title: Re: Vera Hijacked by update to 1.0.994
Post by: umtauscher on April 25, 2010, 06:50:49 am

again please accept my apology (again) to come on so angry.
It just was another debug session, which was caused by a firmware update on the vera, which was forced because the SQ-Remote wasn't working any more.

Anyway, let me explain:
In my environment vera doesn't run as a router and instead as a network device behind another router. It gets it's IP-settings trough dhcp which is a normal setup and also supported by the UI2 user interface. So Vera is not able to get any other dns setting than the one propagated by the dhcp. The web interface shows the internal dns for its dns entry. So the dns entry which is set by the ISP is certainly outside of vera's reach.

The dns entry set into the resolve.conf is the IP address of an external dns. I don't know how it gets there, but I suppose it's setup up as a constant. If so, this might produce more problems in the long run as it's supposed to solve.

I agree, and I don't consider a potential security risk myself, but if the vera is used as a router the first resolver, as you also stated, is critical for function.  If this is not displayed correctly in the user interface, how could any user find out? In my opinion, the root servers or the isp's dns are the only way to go, but not in dhcp mode.

In my case, the erratic response  of was the cause of 4 scenes not working after the update. I don't consider it the proper way for a user to have to write lua or telnet into a router, but since you propagate this doing, you  have to bare the consequences of changes that will always drop through your testing.
(please keep that in mind when designing UI4).

To summarize that all, I think the active dns should always be shown in the network settings. That way you yourself can also easily debug customers problems.
I was just surprised, that what was shown in the network settings in he UI wasn't the setting that was actually used.

Title: Re: Vera Hijacked by update to 1.0.994
Post by: cj on April 26, 2010, 03:11:53 pm
After clients complained that their Vera unit can't connect to the internet caused by bad dns servers, I've included in the default LAN network configuration also the free dns servers. This servers can be viewed in the OpenWRT WebIf interface under Network->Networks->lan Configurations. (Note:I've noticed in certain cases that the settings for Static are not displayed if you don't change the "Connection Type" drop-down to something else and back to Static.)
In UI4 we'll add a checkbox for this dns servers in our UI also under Advanced->Net&Wifi tab, so users could easily opt to not use them.

Between the two major free dns provider OpenDNS and GoogleDNS I've choose first because they offer also some nice filtering support.
Also on the first page of you can see also which big companies trust and use their services.
Title: Re: Vera Hijacked by update to 1.0.994
Post by: zmistro on April 26, 2010, 03:58:41 pm
thanks cj
I peisrsonally have not had this  problem come up in any of my installs as far as I know. I do like the fact you will be adding this option as it will be likely it will be needed in the future.
Title: Re: Vera Hijacked by update to 1.0.994
Post by: guest4690 on April 26, 2010, 04:10:06 pm
Besides the explanations about why a fallback DNS, and why OpenDNS (yeah, i use them too), I tried to get what had really happened to umtauscher.

What I found is that when you ask OpenDNS for a nonexistant domain, it answers with a fixed IP, so if you're doing an HTTP request, is redirected to their search page.  yeah, I don't like that kind of 'service' either.  But there are two ways to get the (correct) NXDOMAIN answer:
Title: Re: Vera Hijacked by update to 1.0.994
Post by: umtauscher on April 27, 2010, 08:31:05 am
Thanks for your explanations.
Anyways, this is relevant for "router mode" only. If I configure Vera as a device in my internal network, it should obey the dns its given by the dhcp, don't you think?

Title: Re: Vera Hijacked by update to 1.0.994
Post by: guessed on April 27, 2010, 11:39:34 am
I'm inclined to agree with @umtauscher. 

The fix as implemented breaks any plugin that connects to it's [local internal Network] Device using a [local internal Network] DNS Name.

I just tried it to confirm that.

I have a lot of IP-attached devices connected to my Vera, and the only reason I didn't notice the change is that [currently] I'm using their raw IP Addresses to talk to them... but to do that I had to set them to have Static IP (via my Local DHCP server) so there's no reason I couldn't have used their [local internal Network] DNS Name.... which would have broken with this work-around solution (as implemented).

Most devices don't implement mDNS/Bonjour yet either, and Vera doesn't yet have an mDNS resolver, so people with "IP-Based" devices on their networks are likely also going to have static DNS local as well.

IMHO, the changes should be:

a) Have Vera show a "health" option somewhere on the front page/UI
This could be determined in the background, so-as not to slow down the UI, but would "work out" all the "external" dependencies that Vera has and show a status based upon being able to resolve those depends.  There's a way to get this as a report right now, but it's buried, so make that "visual" (a Heartbeat icon, or Traffic Light or something representing the health/completeness of the config) and put it front and center so it draws attention when something's wrong in the config.

b) Have the "override" option for as the Backup option, not the default.
This can then be the suggested work-around if the "Health" option above indicates there's a problem with the DNS resolution of any of the "key" names that Vera goes looking for (, ra1, ra2, controlmyhouse etc)
Title: Re: Vera Hijacked by update to 1.0.994
Post by: rmf on May 05, 2010, 12:21:16 pm
I also agree with @umtauscher/guessed.

In general, it's a Bad Idea(TM) to use "hidden" servers (dns, ntp...).  But this particular case
breaks a well-known dns workaround.   It's not at all uncommon that places will use dns
to map an external address to an internal address.  This allows people with portable
devices to have one setting for both internal and external use (like imap/smtp server) in
networks where the gateway does not handle reflecting.  By interjecting an outside DNS
server, you could induce a failure in a non-obvious way, since the external address might not work from the inside.   

As for is this a security risk, various places would consider leaking internal information outside to be a security issue.  At minimum, someone snooping the outside line could figure out internal network addresses....