SECURITY BUG! Can access files from within private shares publicly!

WD Legacy Products My Book Live
1

I have named my MBL NAS . .   So…

I have a text file on the path \\NAS\Myron\Google.txt and this is a private share so you need the right password and permissions to access this share.

Erm…  NOPE!

If I use http://nas/Myron/Google.txt in the web browser then I can access this file WITHOUT using any user name and password!

When will this one be fixed?

It looks like the folliwing two files may have been incorrectly configured by the Web UI:

/etc/nas/apache2/auth/require.inc

/etc/nas/apache2/auth/htpasswd

Has Apache2 been globally configured to deny access to any and every access attempt from outside of it’s own subnet to prevent anyone from the Internet exploiting this security vulnarability?  I still don’t like this because I wish the security to also be valid on the local area network.

2

Voila!   That’s WEBDAV in action!  :smileyvery-happy:

3

This seems to apply to Twonky as well

http://nas:9000/ lets me access private shares without a password

4

jeffz wrote:

This seems to apply to Twonky as well

 

http://nas:9000/ lets me access private shares without a password

Can you give an example specific URL?

(nas:9000 only brings up the Twonky control panel on mine…)

5

@Tony

In the Twonky control panel, you can hit ‘Media Browser’ and browse all files. You can even upload files…

Twonky ver 5.1.9

6

With Twonky I believe tehe idea is that you have a share or two that have your media for your TV and stuff and configure those shares to be indexed by Twonky. You should be able to tell Twonky what NOT to touch.

jeffz wrote:

This seems to apply to Twonky as well

 

http://nas:9000/ lets me access private shares without a password

7

This is scary. I didn’t realise this. This is a problem because, for example, I got a text file that has a few user names and passwords that I use and it’s in a share that should only be accessabel by the admin user and it’s password, yet this same text file can be accessed through the web browser WITHOUT the use of any user name or password!   This is a rediculous situation.  :cry:

8

Myron wrote:

This is a rediculous situation.  :cry:

I agree…  This ain’t good.   …  and it cannot be DISABLED any further through the UI.

9

@Myren yes, but I DO want Twonky to touch these files, I just don’t want them visible to everyone. I have a WD TV Live as well, and I want that device to see my private shares.

10

I think I’ve been misunderstood.  What I’m on about is that files that are to remain private be placed in a share that Twonky does not touch and a username and password MUST be supplied when accessed by SMB or WebDAV.

Audio and video media to be stored in another share that Wronky does index so multi-media devices can play directly off the MBL, through Twonky, without needing to give the MBL a username and password.

The issue I am discussing is that WebDAV is accessing and displaying files that are protected by a username that has a password against it.  Through the browser I displayed a text file WITHOUT being asked for any security login credentials!  I have Twonky, iTunes and Remote access disabled on my MBL.

11

Yes, I am having the same issue with HTTP and private shares as well. I brought it up in the other thread ‘Web Permissions’

This is a separate issue with Twonky. If I understand correctly, you’re telling me that anything shared by Twonky can be accessed by anyone on my LAN without a password. In that case, I think I will do the same as you-- disable Twonky and simply use the ‘Network Share’ option on my WD TV Live.

12

Twonky should share what it’s told to share. It might list folders it’s not shareing but will it allow access to stuff Twonky is told to ignore.   Think it’s time I re-enabled Twonky on my MBL and had a play.

13

Copying in to this thread something I posted to another.  In response to . . .

TonyPh12345 wrote:

Voila!   That’s WEBDAV in action!  :smileyvery-happy:

If you make any changed within the Web UI the configuration files might be re-written and WebDAV re-enabled. I’ve not checked this out.  For sure /etc/nas/apache2/auth/require.inc is re-created every time a change is done to a user or share. though the Web UI.

What you may be able to so is copy the entry for the Public folder from /etc/nas/apache2/auth/require.inc into /etc/apache2/sites-enabled/000-Apollo3G and comment out the line Include /etc/nas/apache2/auth/require.inc.  you 'll need to do the same thing on /etc/apache2/sites-enabled/000-Apollo3G-ssl

The Web UI and associated scripts will still re-write /etc/nas/apache2/auth/require.inc but because Include /etc/nas/apache2/auth/require.inc is now # Include /etc/nas/apache2/auth/require.inc in both /etc/apache2/sites-enabled/000-Apollo3Gand /etc/apache2/sites-enabled/000-Apollo3G-ssl all the other shares desired as private will be inaccessible to WebDAV.  Ine point to remember…  WD2GO may also not have access to those shares omitted from WedDAV and I read something about Windows 7 accessing shares through WebDAV and not Samba’s SMB so maybe there may be issues with Windows 7’s ability to access files.  I’ve not moved to Windows 7 yet because XP does everything I need it to do (why upgrade/fix when it ain’t broke?) so can’t prove or disprove the latter.

Point of note is to journal all your changes so when there is a desire to apply a official firmware update you can put back the original configuration BEFORE applying a future official firmware update.

So, the “before” would be . . .

############################
    # WebDav Extension
    ############################

    Include /etc/nas/apache2/auth/alias.inc
    Alias /shares /shares

    <Location /shares>
        Dav On
        Order Deny,Allow
        Deny from all
        Allow from all
        AuthName DeviceUser
        AuthType Digest
        AuthDigestDomain /shares
        AuthDigestProvider file
        AuthUserFile /etc/nas/apache2/auth/htpasswd
        AuthGroupFile /etc/nas/apache2/auth/htgroup
        #AuthzGroupFileAuthoritative Off
    </Location>

    Include /etc/nas/apache2/auth/require.inc

    #############################

 … and after the change it should look like …

############################
    # WebDav Extension
    ############################

    # Include /etc/nas/apache2/auth/alias.inc
    Alias /shares /shares
    Alias /Public /shares/Public

    <Location /shares>
        Dav On
        Order Deny,Allow
        Deny from all
        Allow from all
        AuthName DeviceUser
        AuthType Digest
        AuthDigestDomain /shares
        AuthDigestProvider file
        AuthUserFile /etc/nas/apache2/auth/htpasswd
        AuthGroupFile /etc/nas/apache2/auth/htgroup
        #AuthzGroupFileAuthoritative Off
    </Location>

    # Include /etc/nas/apache2/auth/require.inc

    <Directory /shares/Public/>
        Dav on
        Allow from all
        AuthName DeviceUser
        AuthType Digest
        AuthDigestDomain /shares/ /shares/Public/ /Public/
        AuthDigestProvider file
        AuthUserFile /etc/nas/apache2/auth/htpasswd
        AuthGroupFile /etc/nas/apache2/auth/htgroup
        <Limit PROPFIND>
            Require valid-user
        </Limit>
    </Directory>

    #############################

 Try that.  If you’re not using WebDAV then it should plug this security issue and still keep the Public folder accessible to WebDAV, any changed to on the Web UI won’t change the WebDAV configuration and also should not break the Web UI.

Someone remind me the reason why WebDAV exists on the MyBook Live?  What is it’s purpose and use?

14

Myron wrote:

 

Someone remind me the reason why WebDAV exists on the MyBook Live?  What is it’s purpose and use?

I am really hesitant to make changes to the configs…  because I don’t know what the consequences can be long term…  

I do it al the time on my QNAP, because despite its eccentricities, it is a familiar environment… 

I can almost guarantee WebDAV is for WD2Go.

15

I know what you mean, but the changes are based on a very educated assumptuion that a factory restored MyBook Live will contain entries for the Public share and the edit maintains the configuration for the Public share and folder.

Plus, the two failed are included so the official firmware will have it’s original and un-tampered files to play with. It seems the main apache2.conf file is static so the edit will prevent the WebDAV set-up from making available all the other user defined shares to WebDAV.

At the moment it’s not an issue to me because I only have the FTP port open to the Internet but now I have completely lost faith in WD2go and how WebDAV allows files to be accessed where access should be denied.

16

Myron wrote:

Someone remind me the reason why WebDAV exists on the MyBook Live?  What is it’s purpose and use?

This is used for the remote access.

17

All, I wanted to post here letting everyone know that we are actively looking into these reported issues and will work to have them resolved and deployed soon.

18

Right. In that case the WebDAV remote access appears to be used, from what I’ve read, by Windows 7 and it seems this is a functionality that is not desired by Western Digital, with devices on the LAN should be accessing files using Samba and media players accessing Media using Twonky and iTunes services?

19

Myron wrote:

Right. In that case the WebDAV remote access appears to be used, from what I’ve read, by Windows 7 and it seems this is a functionality that is not desired by Western Digital, with devices on the LAN should be accessing files using Samba and media players accessing Media using Twonky and iTunes services?

You’re correct.  Webdav wasn’t intendedto be used locally.

20

Ah. Then there is a problem that needs to be corrected. I’ve not experienced my computer using WebDAV to read and write files from the MyBook Live because I believe this is because I have the OS’s Web Client disabled, but it’s been reported that even with that service disabled the OS still establises files shared not through Samba but through WebDAV.  It’s also scary that access permissions, as set within the Web UI, are being totally ignored through WebDAV.

I’m guessing when WE2Go was put together you lot at Western Digital have got caught out? Not knowing that some computing configurations will establish live network connections through WebDAV and not through Samba?

I’m also guessing a quick fix would be to configure the Apache2 server not to accept WebDAV connections from any device on the local area network?  Thing is, cat’s out of the bag that if such a quick fix is is implemented then people will be asking how it will be possible to test that WebDAV in the MBL is 100% honouring and enforcing the permissions set-up though the Web UI?

Not criticism. Just feedback.  :smiley: