DT3 Web Server security issue

I thought more people should know about this after writing to DEVONtech last night and receiving no response yet:

First: If you have a DT3 web server running, where it is accessible to anyone else but you, STOP IT until this is fixed.

The issue: A user with limited access could gain full access to all databases on the system, even those which are not shared at all.

How to trigger it: I am not 100% certain on this, but basically you need to follow these steps:

  • log in as any user
  • leave the window open and do nothing
  • wait a few hours (maybe change your IP with a VPN, not sure about this)
  • return to the window and hit reload in the browser

The web server then lists all available databases, as if you are sitting in front of the computer, with full read/write/delete access as well.

I think this is a browser session problem. The browser should log you out after inactivity, but instead gives you admin access.

Tested on Safari running on Catalina.

The sessions should actually expire after some time. Could you please post a screenshot of the permissions of the user you used to login? And which version of macOS (10.5.x?) did you use? And what exactly was still listed?

I’m not seeing this issue. In fact, I see this when reloading the page after two hours idle…

This would be a different issue, @aedwards :slight_smile:

Thanks for the responses. I will post screenshots privately to the team.

Jim, yes, either this or the log in screen would be good. I will keep on checking my setup and if this happens again. Christian, I will keep you updated via support mail.

Are you still advising people to STOP IT?

…well it DID happen to me a few times now, and I am pretty sure I can reproduce it.

Even if it doesn’t happen to every user, there seems to be an issue, so I would say: proceed with caution, for the time being…

Stopping it would only be potentially necessary if you had other users accessing the web sharing.

I guess I’d be looking to see some sort of risk assessment that quantified what could go wrong, impact, and probability before doing anything … I don’t see that with a STOP IT recommendation.

I am not servng my databases to anyone, also not serving off my network, and also not able to reproduce the specific issue reports, so my risk assessment is very low here. :wink:

An assessment would be dependent on those factors.

2 Likes

Does this still happen after disabling all Safari extensions?

WELL, I need to apologize a bit.

After finally getting around to check all suggested solutions, I found this:

  • When accessing the login screen of the server, you get to log in

  • However, if you access the URL after logging in (for example when hitting “reload” in the browser), the server checks for potentially saved logins in the macOS keychain!

Since I had another account with full access saved to my keychain, the web server then automatically accessed this login - despite having logged in as another user before!

So… if you are not saving your login credentials in the keychain, your server security should be fine - and if you do, you better don’t leave it unlocked or let anyone else use that browser…

if you are not saving your login credentials in the keychain,

Which is the proper way to do things :wink: :slight_smile:

Come ooooooon, you’re adding insult to the injury! :joy::sweat_smile::wink:

Hahaha!
Apologies then :slight_smile:

I’ve long been an advocate of not storing logins in Keychain Access. To the point I still don’t do it on my single-user machines! :open_mouth: :slight_smile:

1 Like

Interesting take, do you mean this in general with regard to PW managers?

So all your logins are on stickies attached to the monitor? :crazy_face:

4 Likes

Nope. They’re where they belong… in my brain :stuck_out_tongue::blush:

I don’t use password managers. I use my brain. :blush:

Same password for all logins then? :smiley:

Hahaha! Nope.