Author Topic: Vera lite bug ever fixed?  (Read 583 times)

Offline user1121

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-0
Vera lite bug ever fixed?
« on: October 21, 2016, 06:58:31 pm »
This website details several security flaws in Vera Lite.  Are other Vera platforms impacted?

https://www.tenable.com/blog/do-you-know-where-your-upnp-is


Offline bwhittaker69

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Re: Vera lite bug ever fixed?
« Reply #1 on: December 18, 2016, 02:45:58 pm »
I am fairly certain my veralite was hacked.   I found a file called "magic" with a bunch of gaming references to it.

When the December 13 2016 firmware upgrade was release my system reported insufficient space to install it (yes, my logs are onto a USB stick).

To discover where your space is being consumed here is a command you can use from any directory on your vera to see where the largest files are located:

Code: [Select]
alias spacehog='for i in G M K; do du -ah | grep [0-9]$i | sort -nr -k 1; done | head -n 11'
Starting from my / directory this was the result:

root@MiOS_3500xxxx:/# spacehog
63.2M   .
20.3M   ./mios
15.4M   ./rom
11.2M   ./mios/www
10.9M   ./mios/www/cmh
10.5M   ./usr
10.2M   ./rom/usr
6.9M    ./overlay
6.5M    ./mios/usr
6.0M    ./usr/lib
5.8M    ./mios/www/cmh/js

Now let's tale into consideration the overall mount points for the various USB and internal devices built into the OS:

root@MiOS_3500xxxx:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 4.5M      4.5M         0 100% /rom
tmpfs                    30.5M    440.0K     30.1M   1% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock7           11.0M      8.9M      2.1M  81% /overlay
overlayfs:/overlay       11.0M      8.9M      2.1M  81% /
/dev/sda1               506.2M     17.0M    463.4M   4% /tmp/log/cmh
/dev/mtdblock8            6.0M      6.0M         0 100% /mios

So, why is /overlayfs:/overlay consuming 81% of its 11M allocated storage capacity?

root@MiOS_3500xxxx:/# cd /overlay
root@MiOS_3500xxxx:/overlay# spacehog
6.9M    .
3.4M    ./etc
3.0M    ./usr
2.4M    ./usr/lib
1.3M    ./usr/lib/libcrypto.so.1.0.0
1.2M    ./etc/cmh-zwfw
861.0K  ./etc/cmh-ludl
639.0K  ./usr/bin
529.0K  ./etc/mios
528.0K  ./etc/mios/sslcerts
509.0K  ./www

By looking at the results above, it looks like the /usr directory is the odd duck.  Specifically, the /usr/lib directory. 

root@MiOS_3500xxxx:/overlay/usr/lib# spacehog
2.4M    .
1.3M    ./libcrypto.so.1.0.0
327.0K  ./libcurl.so.5.3.0
291.0K  ./libssl.so.1.0.0
208.0K  ./libexif.so.12.3.1
129.0K  ./libjpeg.so.62.0.0
64.5K   ./lua
55.5K   ./lua/ssl.so
45.5K   ./opkg
32.0K   ./opkg/status
13.5K   ./opkg/info


Does anyone know of any legitimate reason for these files/directories to exist in the /usr/lib directory?

Additionally, I find it very odd how so many of these files are tagged with the date of Dec 31 1969 as per below:

root@MiOS_3500xxxx:/usr/lib# ls -la
drwxr-xr-x    1 root     root             0 Apr 28  2014 .
drwxr-xr-x    1 root     root             0 Jul 14 13:04 ..
drwxr-xr-x    1 root     root             0 Dec 31  1969 cmh
drwxr-xr-x    2 root     root            37 Nov 13  2013 crda
drwxr-xr-x    2 root     root           115 Nov 13  2013 ddns
drwxr-xr-x    2 root     root           812 Nov 13  2013 iptables
lrwxrwxrwx    1 root     root            35 Dec 31  1969 lib3rdPartyStorage.so -> /mios/usr/lib/lib3rdPartyStorage.so
lrwxrwxrwx    1 root     root            30 Dec 31  1969 libPlutoUtils.so -> /mios/usr/lib/libPlutoUtils.so
lrwxrwxrwx    1 root     root            26 Dec 31  1969 libSerial.so -> /mios/usr/lib/libSerial.so
lrwxrwxrwx    1 root     root            19 Dec 31  1969 libZB_mios.so.1 -> libZB_mios.so.1.0.0
lrwxrwxrwx    1 root     root            33 Dec 31  1969 libZB_mios.so.1.0.0 -> /mios/usr/lib/libZB_mios.so.1.0.0
lrwxrwxrwx    1 root     root            15 Nov 13  2013 libblkid.so.1 -> libblkid.so.1.0
-rwxr-xr-x    1 root     root         40627 Oct  5  2011 libblkid.so.1.0
lrwxrwxrwx    1 root     root            17 Nov 13  2013 libcom_err.so.2 -> libcom_err.so.2.1
-rwxr-xr-x    1 root     root          8051 Oct  5  2011 libcom_err.so.2.1
-rw-r--r--    1 root     root       1360927 Jul 28 06:31 libcrypto.so.1.0.0
lrwxrwxrwx    1 root     root            16 Dec 17 21:50 libcurl.so.5 -> libcurl.so.5.3.0
-rwxr-xr-x    1 root     root        334419 Jul 28 06:37 libcurl.so.5.3.0
lrwxrwxrwx    1 root     root            13 Nov 13  2013 libe2p.so.2 -> libe2p.so.2.3
-rwxr-xr-x    1 root     root         21419 Oct  5  2011 libe2p.so.2.3
lrwxrwxrwx    1 root     root            17 Dec 17 21:50 libexif.so.12 -> libexif.so.12.3.1
-rwxr-xr-x    1 root     root        212795 Jun 30 05:16 libexif.so.12.3.1
lrwxrwxrwx    1 root     root            17 Nov 13  2013 libexpat.so.1 -> libexpat.so.1.5.2
-rwxr-xr-x    1 root     root        141727 Oct 21  2011 libexpat.so.1.5.2
lrwxrwxrwx    1 root     root            16 Nov 13  2013 libext2fs.so.2 -> libext2fs.so.2.4
-rwxr-xr-x    1 root     root        182799 Oct  5  2011 libext2fs.so.2.4
-rwxr-xr-x    1 root     root          3915 Oct  5  2011 libgpio.so
lrwxrwxrwx    1 root     root            17 Nov 13  2013 libip4tc.so -> libip4tc.so.0.0.0
lrwxrwxrwx    1 root     root            17 Nov 13  2013 libip4tc.so.0 -> libip4tc.so.0.0.0
-rwxr-xr-x    1 root     root         21391 Feb 14  2013 libip4tc.so.0.0.0
lrwxrwxrwx    1 root     root            17 Nov 13  2013 libip6tc.so -> libip6tc.so.0.0.0
lrwxrwxrwx    1 root     root            17 Nov 13  2013 libip6tc.so.0 -> libip6tc.so.0.0.0
-rwxr-xr-x    1 root     root         22491 Feb 14  2013 libip6tc.so.0.0.0
lrwxrwxrwx    1 root     root            16 Nov 13  2013 libiptc.so -> libiptc.so.0.0.0
lrwxrwxrwx    1 root     root            16 Nov 13  2013 libiptc.so.0 -> libiptc.so.0.0.0
-rwxr-xr-x    1 root     root          1943 Feb 14  2013 libiptc.so.0.0.0
lrwxrwxrwx    1 root     root            16 Dec 31  1969 libixml.so -> libixml.so.2.0.4
lrwxrwxrwx    1 root     root            16 Dec 31  1969 libixml.so.2 -> libixml.so.2.0.4
lrwxrwxrwx    1 root     root            30 Dec 31  1969 libixml.so.2.0.4 -> /mios/usr/lib/libixml.so.2.0.4
lrwxrwxrwx    1 root     root            17 Dec 17 21:50 libjpeg.so.62 -> libjpeg.so.62.0.0


Just looking for some insight if anyone has any for me.... much appreciated.

 ???

Brett

Offline bwhittaker69

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
Re: Vera lite bug ever fixed?
« Reply #2 on: December 18, 2016, 03:52:12 pm »
I researched how to find accounts without passwords..... this command does the trick on veralite:

Code: [Select]
awk -F":" '($2 == "!" || $2 == "*") {print $1}' /etc/passwd
However its response leaves me confused, should these accounts exist?  Why do they not have a password?

root@MiOS_3500xxxx:/etc# awk -F":" '($2 == "!" || $2 == "*") {print $1}' /etc/passwd
nobody
daemon


Still waiting for moderator to approve my messages ...... hopefully soon !  (By now this is moot because you are reading my messages hence the moderator has approved them.... so sorry moderator for being impatient!)

Brett

Offline daniel

  • Customer Care Manager
  • Administrator
  • Full Member
  • *****
  • Posts: 143
  • Karma: +2/-0
    • Vera Control
Re: Vera lite bug ever fixed?
« Reply #3 on: December 19, 2016, 07:44:18 am »
Hello,

There's no security risk here and I'll explain further below.

1. "nobody" and "daemon" are default users on Linux used by different applications or daemons. Even though there's no password set for them, they cannot be used as they have "/bin/false" assigned as a shell, which is just a binary that immediately exits, returning false.
root@MiOS_350xxxxx:~# egrep 'daemon|nobody' /etc/passwd
nobody:*:65534:65534:nobody:/var:/bin/false
daemon:*:65534:65534:daemon:/var:/bin/false

2. The date of some files may be shown as "Dec 31  1969" because the symlinks were created before the date was updated on the unit. In some situations Vera starts up with the Unix's epoch date (1 Jan 1970 UTC) and then synchronizes it as soon as it gets Internet access. However, because you're in a different emisphere you get the day before January 1st.

3. The 'magic' file is again something used in Linux in general. You can find more information on the URL below, but if you want you can send us the file so we can verify that everything is in order.
https://linux.die.net/man/5/magic

You can find this information online from different sources as it's something generic for Linux and not specific just to Vera. I hope I was able to clear things out, but please let us know if you have any further questions.