2

https://nexla.zendesk.com/hc/en-us/articles/360053720333-Database-Connection-Options

Specifically:

In a text editor, add the below public SSH key to the authorized_keys file. The key must be all on one line. Make sure that you don’t introduce any line breaks when cutting and pasting.

This is the last portion of "Step 1." - this implies each user does not generate their own key, and there is no method to, as there is no where to import a private key within the platform. As far as I can tell this is reusing the same private key for multiple users.

It seems like there is potential for users of the platform to access other user's of the platforms data. Obviously the attacker would not only have to be a user of the platform but also know the database details post-ssh connection. It would also require the use of the same username (but given a default is suggested, seems likely). There is a lot an attacker would have to know to successfully access data they aren't supposed to, but I thought the rule in security is assume the attacker knows every detail of the set up, and make sure it's still secure (0 trust).

Edit: Hopefully add clarity and retract my statement in my first comment. I'm fairly confident after more research and double checking the phrasing that this is re-using one key per user and not good practice. Would love to see a more reputable (or at least a more security focused engineer than myself) confirm or deny this in an answer.

TCooper
  • 336
  • 1
  • 8
  • To whoever downvoted, can you help me understand why this isn't a good question for the site? I'm not implying it is insecure, just trying to understand.... – TCooper Jul 26 '22 at 19:10
  • I didn't downvote, but I'm not sure where you are seeing a concern. The article seems to describe typical SSH public key based authentication. First, a secure connection is built based on the server's private/public key pair (is this what you mean by same private key for multiple clients?). Then, clients authenticate using public key authentication, where clients prove possession of the private key associated with the public key stored on the server (each client uses a unique keypair to authenticate, only public keys are stored on the server). Where are you seeing a security concern? – mti2935 Jul 26 '22 at 20:23
  • @mti2935 because each user uses the *same* public key if following that guide. That implies they're setting up their server to connect to the same private key used by the platform for each account attempting to connect, no? – TCooper Jul 27 '22 at 14:38
  • @mti2935 each client doesn't generate a new key, instead they're instructed "In a text editor, add the below public SSH key to the authorized_keys file. The key must be all on one line. Make sure that you don’t introduce any line breaks when cutting and pasting." – TCooper Jul 27 '22 at 14:43
  • The authorized_keys file is for Public Keys. Perhaps the vendor is giving you their public key and asking you to authorize it for access. – tjd Jul 27 '22 at 15:39
  • @tjd They are, but given its the same public key for every user, doesn't that necessarily imply it's using the same private key for every user? – TCooper Jul 27 '22 at 15:41
  • 1
    Smells like they're giving a single Private Key access to each user. Potentially the key belongs to their Support team? I'd definitely ask the Vendor. – tjd Jul 27 '22 at 15:58
  • @tjd I've reached out their support team and will update the question as I learn more. – TCooper Jul 27 '22 at 16:30
  • @TCooper It looks to me like these instructions allow access to your database from *Nexla's SSH bastion server* (at 34.231.167.112 or 54.209.27.1). So, it's akin to a web application where a web server is allowed access to a db server. In both cases, there may be many users accessing the db through another server (either a bastion server in this case, or a web server in the case of a web app). If that's the case, the private key would live on the bastion server, and users that can access the bastion server can access your db, but there would not be a need to give each user the private key. – mti2935 Jul 28 '22 at 00:06
  • @mti2935 the instructions are for connecting *your* external database through *your* bastion server (please see diagram just under first section listing bastion host in "your network"), and are the same for every user. They're asking each user to create a connection to their platform using the same private key. I'm not sure how that isn't obvious at this point (though I've spent more time on this than I probably should) – TCooper Jul 28 '22 at 10:10
  • @TCooper I was assuming that the server all the way to the left of the diagram (with the Nexla logo) is another bastion server, but it could be any type of server. In any case, I think we are saying the same thing - these instructions simply allow the 'Nexla server' (for lack of a better name) access to your database server, through your bastion server. But, I don't see why the private key would ever have to leave the Nexla server. It's simply a tunnel, to reach the database server - not much different than allowing multiple users to access a protected server through a VPN. – mti2935 Jul 28 '22 at 11:51
  • @mti2935 this configuration opens up my protected server to be accessed by the *same* private key that Kim at fake company one has access to through the same platform. That Bob at fake company two has access to through the same platform. That Chloe at fake company three has access to through the same platform, etc. The private key isn't and shouldn't ever leave the server, but there should be a different private key per user – TCooper Jul 28 '22 at 12:17
  • @TCooper Yes, this is correct. If Kim, Bob, and Chloe can access (and authenticate with) the Nexla server, then they can reach your database server through this ssh tunnel. But, let's assume you have Sue, Steve, and Mary, who are legitimate users that need to access your db. Wouldn't giving Sue, Steve, and Mary access to your db through this tunnel be better than exposing your database server to the whole world, just so Sue, Steve, and Mary can access it? – mti2935 Jul 28 '22 at 13:05
  • @TCooper The tunnel just makes it possible for users to *reach* your db server. Presumably, there are more levels of authentication - first at the Nexla server, then secondly at your db server - that any user (legitimate or malicious) would have to complete in order to access any data. – mti2935 Jul 28 '22 at 13:06
  • @mti2935 more levels of authentication doesn't change that providing a single private key for multiple users is bad practice. "Better than nothing" isn't exactly the way I want to secure the data of the businesses I work for. I'd prefer everything done right every step of the way. All this would take is a place in the UI for users to provide their own private key and then they can generate their own public key to match. Rather than rely on key re-use. I won't accept that I'm opening up my **SECURE** shell to *any* other user of the same platform. That defeats the purpose. – TCooper Jul 28 '22 at 22:46
  • "Yes, this is correct. If Kim, Bob, and Chloe can access (and authenticate with) the Nexla server, then they can reach your database server through this ssh tunnel." more importantly, in what world is this not a security vulnerability? – TCooper Jul 28 '22 at 22:49
  • @TCooper, Consider a company with two locations, location A and location B. The company has a private LAN at A, and a private LAN at B. Employees at A sometimes need to access servers at B, and vice versa. So, the network admin creates a VPN between the firewall at A and the firewall at B, using a key pair. Now, Kim, Bob, and Chloe at location A can access servers at location B. Are Kim, Bob, and Chloe sharing the same key pair? – mti2935 Jul 28 '22 at 23:52
  • @mti2935 I'm not sure if you know what Nexla is/does? These aren't users from the same company. – TCooper Aug 01 '22 at 13:50

0 Answers0