My Book Live FTP security hole

WD Legacy Products My Book Live
1

Hi, I just noticed something weird. I have a My Book Live. Got users and shares setup. Certain users can use certain shares. Seem pretty straight forward and at least somewhat secure. But when I enable FTP on the device, then all of a sudden any user has full read/write access to any share. Am I missing something?

Little bit more on this. I setup a user and share today. I wanted only this user to access only this share. Then I enabled web access. But the web access (through wd2go.com) is really clunky because you have to register with an email address and create a password and hope java works and then enter another password to get to the share. And that’s if it all even works (because sometimes it does and sometimes not). So to avoid all this, I enabled FTP access and told the user to use FireFTP on Firefox. Entered in the WD host IP, username/password, connect and all of a sudden, there’s everyones directorys. And the user can read and write anything to any of the directories. So what’s the deal here?

2

That’s not the case here…

While I can see that the folders for other users exist, I cannot do anything to them:

C:\Users\Tony>ftp 10.0.0.15
Connected to 10.0.0.15.
220 "Welcome to MyBookLive"
User (10.0.0.15:(none)): tony
331 Please specify the password.
Password:
230 Login successful.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
Public
tester
tony
wdtv
226 Directory send OK.
ftp: 28 bytes received in 0.02Seconds 1.47Kbytes/sec.
ftp> cd tester
550 Failed to change directory.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
Public
tester
tony
wdtv
226 Directory send OK.
ftp: 28 bytes received in 0.00Seconds 28000.00Kbytes/sec.
ftp> cd wdtv
550 Failed to change directory.
ftp> put test.txt wdtv/test.txt
200 PORT command successful. Consider using PASV.
553 Could not create file.
ftp>
3

Hmm, I wonder what I’m doing wrong. Weird.

4

I think I know what the issue is.  You see directories that have the same names as the shares and you can’t get at the directories where the user does not have any permissions, but you can create files and folders in the root of the FTP directory tree. The directories and files created won’t be seen by the Samba service.

It’s a sort-of-a-bug.  By rights the user should not be able to create files and folders at the root of the directory tree.

Known about this one for a while when I set-up my network IP camera to record snapshots and then for a while scratching my head trying to find them.

See thus . . .

> ftp nas
Connected to nas.
220 Squirrels are so happy that they don't know how miserable they are.
User (nas:(none)): Jack
331 Please specify the password.
Password:
230 Login successful.
ftp> dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxrwxr-x 2 ftp ftp 65536 May 24 01:33 Jack
drwxrwxr-x 10 ftp ftp 65536 Jun 03 02:14 Public
226 Directory send OK.
ftp: 1134 bytes received in 0.14Seconds 8.04Kbytes/sec.
ftp> mkdir Oops
257 "/Oops" created
ftp> dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxrwxr-x 2 ftp ftp 65536 May 24 01:33 Jack
drwxrwxr-x 2 ftp ftp 65536 Jun 04 01:44 Oops
drwxrwxr-x 10 ftp ftp 65536 Jun 03 02:14 Public
226 Directory send OK.
ftp: 1196 bytes received in 0.00Seconds 1196000.00Kbytes/sec.
ftp> rmdir Oops
250 Remove directory operation successful.
ftp> dir
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxrwxr-x 2 ftp ftp 65536 May 24 01:33 Jack
drwxrwxr-x 10 ftp ftp 65536 Jun 03 02:14 Public
226 Directory send OK.
ftp: 1134 bytes received in 0.00Seconds 1134000.00Kbytes/sec.
ftp> quit
221 Goodbye.

(Yes, I changed the FTP welcome banner and I censored the directory listing.)

5

I don’t think that’s actually it though. Put it this way, let’s say I create a user named, “bgates” and tell it to create a share called, “bgates”. So it creates a directory in the root called, “bgates” and only bgates has access to it. If you login through wd2go.com it works fine (only bgates can access it). If you go to “\yourserver” from the network, same thing. However, let’s say you have another user called, “sjobs”. Then sjobs logs in through FTP and can go right into the bgates directory and add files.

At least that’s my experience so far. What’s weird is that the person in the post above said he’s not having that issue. So I’m trying to figure out why I am. I haven’t done anything special or out of the ordinary. Just simply created a share for one user and one directory that anyone seems to have access to through FTP but not by any other means.

6

Public is just that - everything you have there is for everyone. Your stuff should be in a folder outside the Public folder. Also any guest, sjobs, bgates etc should be outside the Public folder (don’t forget they all  can do anything to your Public folder)

My Q is what address do I give to sjobs - is that id IP address on my computer? All my guests complain that they can’t see me.

7

It is possible to restrict Public to just the admin/owner user. Have done that. It’s only the Dashboard UI that does not allow setting any ACL to the Public share and directoy.

8

I am having the same issue.  I have created directories outside of the Public folder and restricted access to only the file owner.  For example:

dr–r-----  2 root    root  65536 Jan  8 21:01 test

Even with these permissions, all three of my ftp users have full access to the folder (rwx).   Am I missing something here?

9

Access control is not exactly controlled by the standard permissions.

For applying permissions this is what Western Digital used on the MBL and the MBLD.  Possibly using the same thing on anything that shares data.  This lives within the Linux Kernel.

Ref:  http://freecode.com/projects/linuxtrustees, http://trustees.aeruder.net/ and http://sourceforge.net/projects/trustees/.

10

Thanks Myron.  I am not familiar with trustees.  How would I go about restricting FTP permissions to a sub-directory in the Public folder?

11

Ok. I’ve not tried such granular permissions on the NAS but from what I’ve seen it is possible.  The permissions are stored in /etc/trustees.conf.  For the Public folder the entry is, for my My Book Live Duo is …

[/dev/md3]/shares/Public:*:RWBEX:*:CU

 I changes this to …

[/dev/md3]/shares/Public:admin:RWBEX:Myron:RWBEX:*:CU

 … so only my user account and the admin account has access.

Note. /dev/md3 is specific for MyBook Live Duo.  It’ll be different for the single drive MyBook Live.

With the MBL and MBLD it’s a bit more complicated becayse when the Dashboard UI does it’s thing it creates a file /tmp/trustees.mod.  In here is the contents of the trustees.conf file as well as entries to deny the other user accounts access to the folders used for SMB shares.  The same changes need to be done to this file as you do to trustees.conf and also you will need to apply the necessary DENY entries in trustees.mod

Once you’ve done all that you activate the revised trustees configuration using …

settrustees -f /tmp/trustees.mod

All I wanted to do is eliminate the Public share without actually removing it because thare are a fair few other things on the NAS that I guess reply on the /shares/Public folder to exist, so I just changed the permissions which works brilliantly for me and as long as I don’t make any changes to the Public share on the Dashboard UI then my tweak persists even through a firmware upgrade.

I see no reason why you can’t apply specific permissions to a sub-directory under a share but be aware that it may break a script or few.  From what I’ve witnessed I think it won’t.

As long as you make sure you can reverse all the changes back to the original settings, before you start twiddling, then I guess you should be ok.

Obviously if you screw anything up then it’s your NAS.  I’ll have a fiddle too and see if any permissions set beyond what the Dashboard UI sets will stay put.

On first thoughts I suspect what you want should be an easy thing to do and the Dashboard UI should leave your custom trustee settings alone with the settings persisting across firmware updates.

It’s not just FTP that is affected. It’s all the daemons.  NetATalk, Samba, FTP, etc…  Not sure about the iTunes daemon, the DNLA daemon and the remote access Daemon.

1 Like
12

Thanks Myron, that’s exactly what I needed.  It took a little fiddling around with the trustees files but I was able to restrict write access to the whole /shares/Public folder with exception to the “upload” sub-directory.  Guests can now access my ftp files but not delete them and there is a upload directory for them to dump their own stuff.

Thanks again!

13

Out of curiosity, can you post on here the changes to the trustrees.conf and trustees.mod?  Just what changes were made and obstruficate the user names.

14

Here are the lines that I edited in the /etc/truestees.conf and the /tmp/truestess.mod.  I commented out the original lines so that I could easily undo my changes.

##[/dev/sda4]/shares:+share:RWBEX:www-data:RWBEX
[/dev/sda4]/shares:www-data:RWBEX
##[/dev/sda4]/shares/Public:*:RWBEX:*:CU
[/dev/sda4]/shares/Public:2ndNature:RWBEX:guest:RBE
[/dev/sda4]/shares/Public/Uploads:guest:RWBEX

 I had to modify the first line since my guest account is a member of the share group which has write access to the shares folder on the local network, but not through FTP.  You could probably leave this line alone of your “guest” account is not a member of the share group.

The second line was modified to allow local user 2ndNature full access to the /shares/Public directory but only allow RBE permissions for guest.  The last line gives guest full permissions to the /shares/Public/Uploads sub-directory.

15

Thanks.  /tmp/truestess.mod gets re-written by the Dashboard UI hence the need to also make the same alteration in /etc/trustees.conf.  If you make alterations to the Public share in the Dashboard UI then it’ll replace [/dev/sda4]/shares/Public:2ndNature:RWBEX:guest:RBE with [/dev/sda4]/shares/Public:*:RWBEX:*:CU.