Author Topic: Security Concerns  (Read 3584 times)

Offline Priest

  • Jr. Member
  • **
  • Posts: 72
  • Karma: +4/-0
Re: Critical Security Issues - Is Vera Going Out of Business?
« Reply #15 on: June 12, 2017, 09:07:37 am »
Also, just because something is using TCP/23 does not actually mean that it is actually unencrypted TELNET protocol. It just means that this port is being used and other services could actually be listening on the port vs. TELNET. Best way to verify is use a sniffer inline or by spanning the switch port and actually look at the traffic to see if it is clear or obfuscated/secure in some way.

If I get a chance this coming weekend I'll drop a dumb hub in line between Vera and my cable modem so the traffic is promiscuous then run wire shark against Vera's Wan side IP to see what's talking and how.

Online BOFH

  • Sr. Hero Member
  • ******
  • Posts: 2335
  • Karma: +107/-136
Re: Critical Security Issues - Is Vera Going Out of Business?
« Reply #16 on: June 12, 2017, 11:45:00 am »
Unfortunately this doesn't work with the Vera. The device hardcodes Google DNS 8.8.8.8 and 8.8.4.4 so you won't see DNS requests show up in PiHole. I had to add firewall rules that redirect DNS going to Google and have it goto PiHole. Vera customer support's response wasn't satisfactory on why they ignore DNS given out via DHCP.

This is interesting as I do see entries in the pi-hole log for my Vera's. All of mine are setup in the net & wifi section of the settings for DHCP and there is an option there to set the DNS. Which is pointed to 'my leetle friend' pi-hole. If I am reading you right, not all Vera's traffic uses that setting but instead uses a hard coded google DNS? Thank you, time to update my firewall.

Attached is what my VeraPlus is doing currently as captured by Pi-Hole. (I've masked the IP address for privacy)
« Last Edit: June 12, 2017, 03:51:36 pm by BOFH »
Vera3 UI5 UI7 Edge Plus
Trane TZEMT400AB32 | Schlage BE369 FE599 | GE 45601 45602 45603 45604 45606 45609 45631 | Intermatic HA01C HA03C HA05C HA07C CA600 CA3000 | Aeon DSC06106 | Telguard GDC1 | Foscam FI8910W FI8905W FI9821W | D-Link 930L | Wanscam JW0011 | ZModo ZPIBH13W

Offline John M.

  • Administrator
  • Sr. Member
  • *****
  • Posts: 408
  • Karma: +25/-3
    • getvera.com
Re: Critical Security Issues - Is Vera Going Out of Business?
« Reply #17 on: June 12, 2017, 02:22:01 pm »
Hi there,


Just to clarify a few things


Found this topic by searching for the IP address my Vera connects... I'm fine that Vera connects to the "centralized management". I'm fine that these servers are at Linode or Amazon AWS. But Vera connects over TCP/23... Unencrypted TELNET port. And transmits something over the Internet IN CLEAR TEXT.



This is false, ALL inbound and outbound data is encrypted. No sensitive information is sent in clear text.
Ports do not have vulnerabilities. The services listening on the ports do. Which is not the case here.


Vera uses a bunch of different servers for various parts of their infrastructure.  Most use Hurricane Electric hosted, a couple (relay servers) use Linode,  QuadraNet, for provisioning, and Logs seem to go to a  Romanian server. You can see the server assignments on the /etc/cmh/servers.conf file.



Information in servers.conf file is dynamic and constantly changes based on certain factors la geographic location and the load of a certain server.


The bulk of our development team is located in Iasi - Romania, hence the location of the logs servers. Alongside a hand full of other server around the world, for redundancy and geographic reliability.


Our customers privacy and data security is paramount to us, and our security team is constantly improving and updating the security layer, based on the latest threats.

If you might have something to report or found a vulnerability don't hesitate to contact us. But posting publicly all these assumptions does nothing more than creating an unnecessary fear factor.
« Last Edit: June 12, 2017, 03:52:42 pm by John M. »
John.M. ▾ Senior Customer Care Advocate
Vera Control, Ltd. ▾ Smarter Home Control  ▾ support@getvera.com ▾www.getvera.com ▾ +1 (866) 966-2272

HOURS OF OPERATION (Pacific Time Zone, UTC -8 )
Monday - Friday   12:00 am ? 06:00 pm
Saturday - Sunday   04:00 am ? 06:00 pm

Offline niharmehta

  • Sr. Member
  • ****
  • Posts: 317
  • Karma: +14/-0
Re: Critical Security Issues - Is Vera Going Out of Business?
« Reply #18 on: June 12, 2017, 03:44:29 pm »
Hi there,



This is false, ALL inbound and outbound data is encrypted. No sensitive information is sent in clear text.
Ports do not have vulnerabilities. The services listening on the ports do. Which is not the case here.[/font]



Information in servers.conf file is dynamic and constantly changes based on certain factors la geographic location and the load of a certain server.


The bulk of your development team is located in Iasi - Romania, hence the location of the logs servers. Alongside a hand full of other server around the world, for redundancy and geographic reliability.[/font]

Our customers privacy and data security is paramount to us, and our security team is constantly improving and updating the security layer, based on the latest threats.

If you might have something to report or found a vulnerability don't hesitate to contact us. But posting publicly all these assumptions does nothing more than creating an unnecessary fear factor.



Great to hear  that you are  geographically distributing the services.  This makes it more resilient than some of the other common HA systems that have less robust designs with a single cloud provider within a single AZ or region. Within that file there is a static section. The static seems self explanatory and the host names do not have any country designator.

For the 'dynamic' section,  Is that created based on the region the Vera is installed in?  Thus, does UK based veras use a UK based host entry ?

Most important question however is the logs.  In the past these were using regular FTP to the logs server. . These were sent out on the public side without any file or network encryption.  Is this still the case? I have noticed in the past these logs do contain pin codes and other sensitive information.
2x VeraLite; 2xTrane Tstats; 45 x Switches/Dimmers/Appliance Modules; 4x Everspring Water Sensors; DSC Integration; 2 x Zwave Door Locks; 1x Ted5K; 1x Rainforest Eagle; Onkyo AVR; 6x Squeezebox;

Offline John M.

  • Administrator
  • Sr. Member
  • *****
  • Posts: 408
  • Karma: +25/-3
    • getvera.com
Re: Critical Security Issues
« Reply #19 on: June 12, 2017, 04:12:39 pm »
I don't personally have some of the answers as I need to consult myself with our networking team. But I will update as soon as I have the info.

Pin codes and everything z-wave related is encapsulated with hardware encryption, however some of the user luup code and third party plugin data might still store clear data in logs. These strings should not contain sensitive data.
« Last Edit: June 13, 2017, 01:39:05 pm by John M. »
John.M. ▾ Senior Customer Care Advocate
Vera Control, Ltd. ▾ Smarter Home Control  ▾ support@getvera.com ▾www.getvera.com ▾ +1 (866) 966-2272

HOURS OF OPERATION (Pacific Time Zone, UTC -8 )
Monday - Friday   12:00 am ? 06:00 pm
Saturday - Sunday   04:00 am ? 06:00 pm

Offline MrCCIE

  • Newbie
  • *
  • Posts: 10
  • Karma: +0/-0
Re: Critical Security Issues
« Reply #20 on: June 15, 2017, 10:50:31 pm »
I don't personally have some of the answers as I need to consult myself with our networking team. But I will update as soon as I have the info.

Pin codes and everything z-wave related is encapsulated with hardware encryption, however some of the user luup code and third party plugin data might still store clear data in logs. These strings should not contain sensitive data.

Any updates?

Using an unencrypted file transfer protocol with the assumption that all data inside it will be encrypted is naieve at best - and downright negligent if you believe that user code and third party apps could be clear-text.  As just a basic reason why this would be a hideous practice, FTP does transmit usernames and passwords in clear text as part of session establishment.  Even if those credentials are not something that I as the user would set (and might re-use elsewhere), it seems like it would necessarily open the platform to impersonation and escalation.

As far as the Telnet issue goes, no, I don't buy the idea that port 23 was used for something other than telnet - that would be very strange custom programming. But I do like the idea that it could have been used by a third-party plugin and I hope that is the case.  However, I noticed your answer did not directly state that your software does not use port TCP/23 - can we get a conclusive answer on that?


*** NOTE ***

I want to re-iterate what John said because, to be fair, it has not yet been firmly established that there IS an issue; at this point there are just questions which Vera has initiated a dialogue about responding to.  That's a good sign.
« Last Edit: June 15, 2017, 10:52:03 pm by MrCCIE »

Offline niharmehta

  • Sr. Member
  • ****
  • Posts: 317
  • Karma: +14/-0
Re: Critical Security Issues
« Reply #21 on: June 17, 2017, 04:55:44 am »
I can conclusively state that the logs do contain sensitive information. My logs do.   

 Maybe not from Vera processes, but I did see  plugin based alarm system pin codes in there.  Also the Vera logs do provide enough information that could allow somebody to determine the type and number of devices, version info, API, plugin APIs,  etc that can be used for other attacks. Granted this requires a good MITM or spoof attack, but still plausible with DNS spoofing and other methods since auth is only by the server.  For example the MiOSRestApi.log files contain some very useful information if I was a hacker. (mac, internal IP, OS version).  I do my own DNS  spoof and Vera happily uploads the logs to my own FTP server to capture the logs.

So although it may be accurate to state the Vera does not leak pins,  the reality is that plugins are what makes Vera useful and these do  log sensitive data ( as well as vera itself does). The continued use of plain FTP with only user/pass is a terrible, terrible idea today. It would be trivial to convert this to SCP and using certs to auth the server.

Right now, the FTP log upload is using a hard coded password that writes to a directory but the directory or files cannot be listed or files downloaded.  Well, most of the time..  A couple of years ago I identified an error they had where all the logs for everyone was left in a state where anyone could download if they used the hard coded credentials.  This was fixed, but I have never really tried to see if the FTP server was truly configured and hardened appropriately.

@MrCCIE (good to see another network pro here.. I wonder if we work at the same place maybe)
  Ports can be used for anything.  You know this. :-)  To be clear though, this is not about Vera running a Telnet SERVICE for inbound, it is about using Telnet as an outbound protocol.   In 10s I  can easily make Apache/SSL run on port 23 if I wanted.  It would look like Telnet port is being used, but the payload is encrypted. Ugly, but easy.

 Granted a plugin would need root to open a connection using privileged  port, but since LuaUPnP process runs   as root, would not be surprised if the plugins run at this level.  Regardless, my Meraki has not seen Telnet traffic from it, and a 'netstat' of the system does not show open sockets to that port either.    If I was home and sufficiently motivated, I would put a sniffer on that spanned port for a few days and trigger if port 23 was being used.  Maybe you have some time?

2x VeraLite; 2xTrane Tstats; 45 x Switches/Dimmers/Appliance Modules; 4x Everspring Water Sensors; DSC Integration; 2 x Zwave Door Locks; 1x Ted5K; 1x Rainforest Eagle; Onkyo AVR; 6x Squeezebox;

Offline Beakon

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
Re: Security Concerns
« Reply #22 on: July 08, 2017, 12:54:45 pm »
I really love how all the Vera representatives/personal just disappeared from here one then where proven wrong.
Feels like the support cases I have been having with them.. First weird, unclear and evasive answers and then nothing..

Offline John M.

  • Administrator
  • Sr. Member
  • *****
  • Posts: 408
  • Karma: +25/-3
    • getvera.com
Re: Security Concerns
« Reply #23 on: July 10, 2017, 08:31:17 am »
@Beakon and all,


No one disappeared, these forums, are in fact, very closely monitored. But the idea of this community is to let the people have a voice, being it positive or negative. This is most of the time appreciated because it's a luxury some of the competitors are totally avoiding.


All people are entitled to their opinion, however, for the sake of not arguing about some items, we choose to not intervene.


As stated before, EVERYTHING that leaves the network and Vera is encrypted. I don't want to go into details even more, as it can lead to security sensitive details to go public. This is a public forum after all. It's ethical, that if you have a security concern, to please report this to our support team, instead of debating it publicly.


Thank you for your understanding.
« Last Edit: July 10, 2017, 08:55:37 am by John M. »
John.M. ▾ Senior Customer Care Advocate
Vera Control, Ltd. ▾ Smarter Home Control  ▾ support@getvera.com ▾www.getvera.com ▾ +1 (866) 966-2272

HOURS OF OPERATION (Pacific Time Zone, UTC -8 )
Monday - Friday   12:00 am ? 06:00 pm
Saturday - Sunday   04:00 am ? 06:00 pm

Offline niharmehta

  • Sr. Member
  • ****
  • Posts: 317
  • Karma: +14/-0
Re: Security Concerns
« Reply #24 on: July 12, 2017, 05:22:01 am »
John.. I do  appreciate your participation in the forums. Since Marc seems to have left MCV, its good to see that management is committing resources here. 

Anyways, not  trying to be an alarmist and I try to take a pragmatic approach to security issues .  I am also a Vera supporter and happy with my system so not trying to ding you guys for no reason.
 
Your security team already knows about this. I reported a security issue regarding logging  couple of years ago. It took two weeks of begging, calls, emails, for somebody in support to respond  and only after I publicly shared here in desperation that the issue was addressed.  If your security team thinks that sending logs over FTP that clearly contain private information is OK, that is an entirely troubling issue as well.  I would rather you guys honestly say you do not have a security team rather than still thinking its ok to use FTP to send the log files.

I don't think you can really claim that EVERYTHING that leaves the network is encrypted.  Below I will walk through to show that your statement may not be totally true.  Note, I am not trying to hack anything or cause any damage to Vera.  If I am off base and missing something major in what I am showing below, I am happy to be corrected. 

 Lets look at the log rotation process:

Crontab for Log_Rotation:
Code: [Select]
root@OpenWrt:~/.ssh# crontab -l
*/1 * * * * /usr/bin/Rotate_Logs.sh #Rotate_Logs

As expected, that is an alias to the script in the mios bin directory:
Code: [Select]
root@OpenWrt:/mios/usr/bin# ls -la /usr/bin/Rotate_Logs.sh
lrwxrwxrwx    1 root     root            28 Mar 18 15:14 /usr/bin/Rotate_Logs.sh -> /mios/usr/bin/Rotate_Logs.sh

So checking this file here is some useful information such as when logs are rotated and WHICH logs are rotated.
MAX_ROTATION_INTERVAL=43200 # 12 hours   
MIN_FREE_DISK_SPACE=5120 # KB

# Put here all files from the logs directory which you want to be uploaded to the LOGS server.
TMP_LOG_FILES="log.MiOSRestApi log.upgrade log.mios_services log.Provision log.freshinstall log.RouterMode
                           log.mios_firmware log.Report_AP log.Init-LuaUPnP log.Init-NetworkMonitor log.cmh-ra
                           log.fixNetwork log.WanFailover log.UpgradeZwaveFW log.hotplug-usb log.opkg"

Still in this file, this is where it gets interesting. Look, you have hard coded FTP passwords for the logs servers.  (Note: FTP is NOT ENCRYPTED)
Code: [Select]
# Get servers and FTP configs.
[ -f "$MIOS_SERVERS_FILE" ] && source "$MIOS_SERVERS_FILE" || log "FILE-NOT-FOUND: servers.conf"
[ "${pkap%[02468]}" == "$pkap" ] && defaultLogsServer="logs1.mios.com" || defaultLogsServer="logs2.mios.com"
ftpServer=${Server_Log:-${Server_Log_Alt:-$defaultLogsServer}}
ftpUser=${Server_Log_User:-"logs"}
ftpPass=${Server_Log_Pass:-"romania09iasi"}

Lets first check the
Code: [Select]
/etc/cmh/servers.conf file as referenced above. It also seems to have the log server DNS names and the user/password
Code: [Select]
# Log
Server_Log=oem-log5.mios.com
Server_Log_Alt=oem-log3.mios.com
Use_Server_Log_Alt=0
Server_Log_User=logs
Server_Log_Pass=romania09iasi

What path does the network take to the log servers?  Definitely not a vpn tunnel. 
Code: [Select]
root@OpenWrt:/mios/usr/bin# nslookup oem-log5.mios.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      oem-log5.mios.com
Address 1: 213.164.247.146 artis8.iasi.astral.ro

traceroute to 213.164.247.146 (213.164.247.146), 30 hops max, 38 byte packets
 1  192.168.XX.1 (192.168.XX.1)  0.461 ms  0.233 ms  0.224 ms
 2  *  *  *
 3  ip68-4-12-158.oc.oc.cox.net (68.4.12.158)  7.939 ms  7.680 ms  8.002 ms
 4  ip68-4-12-2.oc.oc.cox.net (68.4.12.2)  7.683 ms  7.896 ms  7.646 ms
 5  chgobprj01-ae0.0.rd.ch.cox.net (68.1.4.42)  68.733 ms  64.394 ms  62.928 ms
 6  213-46-190-141.aorta.net (213.46.190.141)  64.101 ms  64.300 ms  73.936 ms
 7  us-was02a-rd2-ae11-0.aorta.net (213.46.190.185)  231.337 ms  231.301 ms  233.924 ms
 8  nl-ams05a-rc2-lag-57-0.aorta.net (84.116.130.234)  231.801 ms  230.709 ms  231.782 ms
 9  nl-ams17b-rc1-lag-40-0.aorta.net (84.116.130.9)  231.693 ms  231.281 ms  233.632 ms
10  de-fra01b-rc1-ae40-0.aorta.net (84.116.130.10)  232.060 ms  231.918 ms  238.276 ms
11  ro-cj01a-rd3-ae0-0.aorta.net (84.116.131.54)  232.233 ms  226.218 ms  222.620 ms
12  ro-is01a-rd4-bundle-ether2-1770.aorta.net (84.116.186.6)  232.569 ms  234.172 ms  231.853 ms
13  ro-is01a-ra3.upcnet.ro (95.77.60.38)  231.892 ms  235.362 ms  232.982 ms



For fun, lets just log in using those credentials to your servers.. Oh look. it is listening on normal FTP! At least this time the device directories seem to be locked down. ( I will not show my test commands I used to check)

Code: [Select]
host:~ me$ ftp oem-log5.mios.com
Connected to oem-log3.mios.com.
220 mios-logs3-service
Name (oem-log5.mios.com:me): logs
331 Password required for logs
Password:
230-MiOS LTD LOG SERVER 3
230 User logs logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Anyways, back to the actual log rotation process. Vera does quite a few cool things to decide when to Rotate and Upload  Logs which I will skip over since its not material. (although quite interesting) :

Code: [Select]
# Move certain log files in /tmp to the cmh logs directory, so they'll get uploaded to the LOGS server too.
for file in $TMP_LOG_FILES; do
        if [ -f "$MIOS_LOGS_PATH/$file" ]; then
                log "Copy tmp log file: $file"
                cp "$MIOS_LOGS_PATH/$file" "$MIOS_CMH_LOGS_PATH/${file#log.}.log"
                log "Truncate tmp log file: $file"
                echo > "$MIOS_LOGS_PATH/$file"
        fi
done


The Rotate_Logs script does some log renaming in preparation, then closes the file in preparation for upload.
Code: [Select]
        if [ $archiveLogsOnServer -eq 1 ]; then
                newLogFile="${logFile}_${dateStamp}"
        else
                newLogFile="${logFile}.1"
        fi
        mv -f "$logFile" "$newLogFile" 2>>$log_file
        logs="$logs"$'\n'"$newLogFile"

---
---
---
# Signal processes to close and re-open the logs files.
log "Signal processes to close files"
kill -USR2 $(ps ax | grep 'LuaUPnP$\|LuaUPnP $' | awk '{print $1}' | head -n 1) 2>/dev/null
kill -USR2 $(ps ax | grep 'NetworkMonitor$\|NetworkMonitor $' | awk '{print $1}' | head -n 1) 2>/dev/null
kill -USR2 $(pidof 'CamProxyServer') 2>/dev/null
killall tail 2>/dev/null

All the build up is done. The logs rotate, get prepared,  the script loads the server names, user, password as variables and now:
Code: [Select]
################################
#         Upload files         #
################################
numLogFiles=0
numUploadFails=0

log "Start uploading files: $logs"
for logFile in $logs; do
        log "Processing log file: $logFile"
        rm -f "${logFile}.gz" 2>>$log_file
        gzip "$logFile" 2>>$logFile
        rm -f "$logFile" 2>>$log_file
        ls -al "${logFile}.gz" >> $log_file 2>/dev/null
        if [ $archiveLogsOnServer -eq 1 ]; then
                # If unit is not provisioned, don't upload logs on server.
                if [ -n "$pkap" ] && [ -n "$ftpUser" ] && [ -n "$ftpPass" ] && [ -n "$ftpServer" ]; then
                        log "Sending file with CMD: curl -s -S -f --connect-timeout 60 --max-time 300 -u \"$ftpUser:$ftpPass\" -T \"${logFile}.gz\" \"ftp://$ftpServer/${pkap}/${pkap}_$(echo $logF
                        sendOk=0
                        try=0
                        while [ $((++try)) -le 3 ]; do
                                log "Try $try/3"
                               [b] curl -s -S -f --connect-timeout 60 --max-time 300 -u "$ftpUser:$ftpPass" -T "${logFile}.gz" "ftp://$ftpServer/${pkap}/${pkap}_$(echo $logFile | awk -F '/' '{print[/b]
                                if [ $? -eq 0 ]; then
                                        log "Sent OK"
                                        sendOk=1
                                        break
                                else
                                        log "Sent FAILED"
                                fi
                        done
                        let numLogFiles++
                        if [ $sendOk -eq 0 ]; then
                                let numUploadFails++
                                echo "Failed to upload file: $logFile"
                        fi
                else
                        log "Router isn't provisioned, just removing log file: ${logFile}.gz"
                fi
                rm -f "${logFile}.gz" 2>/dev/null
        fi
done




So it is clear that your are using basic unencrypted FTP over the public network to send the log files.  It is not encrypted.  The next question is what is IN these files. I am not going to post everything, but here are some useful info I found in the MIOS API file for example:


2017-06-03_09:18:42 -[17589]- curl CMD: curl -k -sS -L --retry 0 --connect-timeout 30 -m 120 -D "/tmp/rest/response_header_17589.txt" -o "/tmp/rest/response_data_17589.txt" -H "Expect: " -H "MMSSession: 00000000D868SOMESESSIONID" -X PUT  -F "MacAdress=MAC_ADDRESS" -F "InternalIP=MYPRIVATEIP" -F "FirmwareVersion=1.7.2608" -F "ZWaveVersion=4.5-l1_r0_h178c61c_n113_s198_is0_o1_si0_rp1_su0_pr0" -F "Uptime=57-10_08" -F "UIVersion=7" -F "UILanguage=en" -F "UISkin=mios" -F "Platform=Sercomm%20G450" -F "Server_Event=vera-us-oem-event11.mios.com" -F "Server_Relay=vera-us-oem-relay31.mios.com" -F "Server_Support=vera-us-oem-ts11.mios.com" -F "Server_Storage=vera-us-oem-storage23.mios.com" -F "Server_Device=vera-us-oem-device11.mios.com" -F "LocalPort=80" -F "AccessiblePort=29365" -F "Timezone=America|Los%20Angeles|PST8PDT,M3.2.0,M11.1.0" -F "DistributionType=squashfs" -F "DistributionVersion=mt7621-3.10-OpenWrt-mios_g450-Barrier Breaker-14.07" -F "DistributionBuild=121" -F "WifiSsid=VERA_SSID" -F "WifiPassword=MYVERAROOTPASSWORD" -F "Oem=mios" -F "AccessPermissions=15" -F "Using_2G=0" "https://vera-us-oem-device11.mios.com/device/device/devic/VERASERIALNUMBER"
2017-06-03_09:18:42 -[17589]- curl exit code: 0
2017-06-03_09:18:42 -[17589]- Request OK, MMSResponse: 200
2017-06-03_09:18:42 -[17589]- MiOSRestApi terminating with exit code 0
2017-06-03_09:18:42 -[17674]- START MiOSRestApi.sh ReportIP -p InternalIP=MYPRIVATEIP from /bin/sh /usr/bin/Report_AP.sh --report-only [17348] with parent /bin/sh /usr/bin/cmh-ra-daemon.sh 127.0.0.1 80 vera-us-oem-relay31.mios.com 29365 MAYBEANOTHERSESSIONID [17271]
2017-06-03_09:18:42 -[17674]- Get server 'Server_AuthD', alt=0, strict=0
2017-06-03_09:18:42 -[17674]- Got servers: main=vera-us-oem-authd11.mios.com, alt=vera-us-oem-authd12.mios.com, Use_Server_AuthD_Alt=0
2017-06-03_09:18:42 -[17674]- Return Server_AuthD=vera-us-oem-authd11.mios.com
2017-06-03_09:18:42 -[17674]- curl CMD: curl -k -sS -L --retry 0 --connect-timeout 30 -m 120 -D "/tmp/rest/response_header_17674.txt" -o



And although not your fault, here is a security pin code captured in the LuaUPnP log files by a plugin. Regardless of the fault, you now have this information and are transferring it via a clear text protocol that is quite simple to spoof.
08   06/22/17 21:01:49.043   JobHandler_LuaUPnP::HandleActionRequest device: XXX service: urn:micasaverde-com:serviceId:XXXXX action: XXXXXXX <0x77214320>
08   06/22/17 21:01:49.043   JobHandler_LuaUPnP::HandleActionRequest argument State=XXXXXX <0x77214320>
08   06/22/17 21:01:49.044   JobHandler_LuaUPnP::HandleActionRequest argument PINCode=MYPIN <0x77214320>



So I have spent the last two hours  or so providing a ton of detail to show clearly that your statement actually does not seem to be true.  If this is still not clear enough, when I have some time I would be happy to privately share some packet captures on my WAN interface  that show the negotiation, the directory change, and putting the gzip log files up to your servers.
2x VeraLite; 2xTrane Tstats; 45 x Switches/Dimmers/Appliance Modules; 4x Everspring Water Sensors; DSC Integration; 2 x Zwave Door Locks; 1x Ted5K; 1x Rainforest Eagle; Onkyo AVR; 6x Squeezebox;

Offline ceefin

  • Full Member
  • ***
  • Posts: 107
  • Karma: +5/-0
Re: Security Concerns
« Reply #25 on: July 12, 2017, 08:49:44 am »
niharmehta,

I have reviewed the above and must applaud you on a very detailed post. I'm disappointed that I have to come to the same conclusion that you have, based on the information presented. I am not at home to verify your findings, but I expect that I'd find similar results.

The fact that this kind of relatively sensitive data appears to be sent over an unencrypted pipe is concerning. I wanted to think that there is something setup on the Vera box encrypting that connection at a lower level, but looking at the information below it appears that you were able to connect to their log servers from a command line that wasn't on the vera unit, scrapping that idea.

With all this info in mind, I have a few questions now..
  • How often is Vera receiving log file uploads?
  • Why?
  • Do we need to be doing this? Can I opt out? (While still using the unit?)
  • What else is in that file, beyond the data points that you've obfuscated in your example? Are my camera logins also being broadcast? (They're all currently in a box from a recent move, and weren't accessible to the broader internet), etc..
  • Is there some other security for this that we're not seeing?
  • Where do we go from here?

Also, some googling shows that Marc Shenker appears to have left in April.

Offline jlind

  • Full Member
  • ***
  • Posts: 167
  • Karma: +6/-5
Re: Security Concerns
« Reply #26 on: July 12, 2017, 09:55:22 am »
If this is true, and it looks to be just that, I'll reiterate that Vera needs to hire a quality head of software engineer.  At this point they could also use a good code review by a third party.  The fact that they didn't have their ducks in a row before getting into the home security field shows that salesmen are calling the shots and not the engineers.  :'(
VeraLite/VeraPlus with UI7, Multiple GE switches, GE Outlets, Aeon Smart Switches, Minimote, GE Portable outlets  Apps: (Countdown Timer, Weather Underground, Honeywell WiFi Thermo (newest manual install), Virtual on/off switches, eMail Notifications, System Monitor, AlternateUI)

Offline jlind

  • Full Member
  • ***
  • Posts: 167
  • Karma: +6/-5
Re: Security Concerns
« Reply #27 on: July 12, 2017, 10:00:13 am »
A huge THANK YOU to @niharmehta for not taking the conversation private for the benefit of the forum!
VeraLite/VeraPlus with UI7, Multiple GE switches, GE Outlets, Aeon Smart Switches, Minimote, GE Portable outlets  Apps: (Countdown Timer, Weather Underground, Honeywell WiFi Thermo (newest manual install), Virtual on/off switches, eMail Notifications, System Monitor, AlternateUI)

Online BOFH

  • Sr. Hero Member
  • ******
  • Posts: 2335
  • Karma: +107/-136
Re: Security Concerns
« Reply #28 on: July 12, 2017, 11:22:49 am »
The quick and dirty way to prevent these logs from being transmitted would be to block oem-log3.mios.com and oem-log5.mios.com (both incoming and outgoing traffic) in your firewall or Pi-Hole. However I am not sure what that would do to your Vera's functionality.

Vera3 UI5 UI7 Edge Plus
Trane TZEMT400AB32 | Schlage BE369 FE599 | GE 45601 45602 45603 45604 45606 45609 45631 | Intermatic HA01C HA03C HA05C HA07C CA600 CA3000 | Aeon DSC06106 | Telguard GDC1 | Foscam FI8910W FI8905W FI9821W | D-Link 930L | Wanscam JW0011 | ZModo ZPIBH13W

Offline niharmehta

  • Sr. Member
  • ****
  • Posts: 317
  • Karma: +14/-0
Re: Security Concerns
« Reply #29 on: July 12, 2017, 12:48:13 pm »


With all this info in mind, I have a few questions now..
  • How often is Vera receiving log file uploads?
  • Why?
  • Do we need to be doing this? Can I opt out? (While still using the unit?)
  • What else is in that file, beyond the data points that you've obfuscated in your example? Are my camera logins also being broadcast? (They're all currently in a box from a recent move, and weren't accessible to the broader internet), etc..
  • Is there some other security for this that we're not seeing?
  • Where do we go from here?

For your questions. The vera log rotate script has several rules on to when and what logs are uploaded.  In general it is based on time and disk availability. There are other rules for 3G, USB and other that influence the settings. 
The logs are uploaded to help with troubleshooting and support.  Having the logs available to their support engineers I am sure helps reduce support times significantly without having to walk less technical customers through capturing and uploading.  Also, I assume their development teams aggregate this info to help identify and fix bugs.

Yes.. you can opt-out.   There is a logs setting "Archive old logs on MiOS (recommended)" that enables/disables this and the unit works fine. As long as their script honors this setting before upload, it will just rotate your logs and not upload.    However, this does make troubleshooting more difficult for MCV.

The log file(s) contain quite a bit of info.  It just depends on what features you are using and if the plugin/app writers are logging sensitive information.  As John stated  previously they really cannot control what the plugin writers send to the log file other than forcing them to use their own logging.  I cannot say if Vera is logging your Camera/Security logins are exposed.  I would assume so, but hopefully your cameras are behind your firewall anyways.  Just don't use the same credentials on your cameras for other things.   

I really hope there is some magical security I am not seeing. I would be more than happy to be wrong in this case.  However, at this point it seems doubtful as I did a quick packet capture on my router WAN interface and indeed see the FTP negotiation happened and for example here is a FTP response captured.

Code: [Select]
08:57:04.679568 00:14:fX:XX:XX:XX > 88:15:4X:XX:XX:XX, ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 51, id 29132, offset 0, flags [none], proto TCP (6), length 86)
    213.164.247.146.21 > 68.4.XXX.XXX.35365: Flags [P.], cksum 0x56d3 (correct), seq 4168782456:4168782490, ack 1648855707, win 256, options [nop,nop,TS val 3884845721 ecr 2076053261], length 34: FTP, length: 34
257 "/" is the current directory

Where do we go from here?  1) Vera implements proper security  2) You can disable log archiving which is probably not ideal for troubleshooting 3) Capture logs to your own server which at least allows you to have that information available but now it becomes your problem to manage.

I capture the logs myself by spoofing the  name resolution. I posted the method a couple of years go.   Essentially you just spoof dns via your own server or editing the /etc/hosts file. Then creating your own FTP server with the ftp credentials in the above.  Very will happily just upload to your server instead.   


If you really, really feel the need to block access to the servers , you need to do a DNS block.  Either at the network level or redirecting the /etc/hosts file.  The IP addresses for these severs could change so just doing s simple IP block may not last. I would not recommend blocking log archiving if you frequently need support from MCV as it does makes their job significantly more difficult to help you. For now, I would just deselect the log archive setting instead if that is all you want to do.
2x VeraLite; 2xTrane Tstats; 45 x Switches/Dimmers/Appliance Modules; 4x Everspring Water Sensors; DSC Integration; 2 x Zwave Door Locks; 1x Ted5K; 1x Rainforest Eagle; Onkyo AVR; 6x Squeezebox;