New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update db_connect Connection Persistence Logic #11211

Merged
merged 1 commit into from Jan 9, 2019

Conversation

Projects
None yet
2 participants
@jbarnett-r7
Copy link
Contributor

jbarnett-r7 commented Jan 8, 2019

This PR changes the functionality of the db_connect command to no longer match connection info to an existing connection if any of the properties of the connection matches a defined service already in the config file. This fixes issues when updating the connection criteria of a service on a host that you had previously connected to. An example is updating the API token for a connection to localhost when you already have the connection details for localhost saved in your config file.

The new functionality will save a new, valid connection with a randomly generated name by default. If the -n flag is specified it will save the with the value specified. If a connection with that name already exists it will update the connection details in the config file under the same name.

Verification

  • Verify the default behavior for a new setup.
    • Ensure that you do not have any saved data service connections in the ~/.msf4/config file.
    • Run msfdb reinit. Follow the prompts to restore the database and create a new web service connection set as default.
    • Run msfconsole. Use db_connect -l and db_status to verify that you are connected to an HTTPS data service running on localhost and it is saved.
  • Verify the msfdb script works when changing connection info for the local connection
    • Run msfdb reinit again, wiping the DB and data service and then persisting the new connection.
    • Run msfconsole and verify that you are successfully connected to the data service using db_connect -l and db_status.
    • Check the file at ~/.msf4/config and verify the connection info is updated with the new token
  • Verify that new connections are given unique, randomly generated names.
    • Run msfdb on a separate, external server, such as VM.
    • Connect to the remote data service using db_connect <connection info>
    • Run db_connect -l to verify the connection was persisted with a unique name.
  • Verify that you can create a connection with a user-specified name
    • Run db_disconnect, verify you are no longer connected with db_status, then run db_connect -n remote_vm_connection <connection info>. Run db_connect -l to verify the connection was created with the name you specified.
  • Verify that existing connections are updated properly.
    • Run msfdb reinit on the remote VM.
    • In msfconsole on your local machine, run db_connect -n remote_vm_connection <connection info including new token>. Verify you connect successfully.
    • Run db_connect -l and ensure that no new connection was created.
    • Check ~/.msf4/config and ensure the API token was updated for the remote_vm_connection entry.
Only lookup db connections by name
Matching on all attributes was causing issues when the connection
criteria would change for a db service at a host that already existed.
It would find the existing connection and load that outdated connection
and fail to connect.

The new functionality will save a new, valid connection with a randomly
generated name, unless the -n flag is specified to overwrite an existing
connection.

@mkienow-r7 mkienow-r7 added the msf5 label Jan 9, 2019

@mkienow-r7 mkienow-r7 self-assigned this Jan 9, 2019

@mkienow-r7

This comment has been minimized.

Copy link
Contributor

mkienow-r7 commented Jan 9, 2019

To confirm these changes allow the user to add multiple entries for the same remote endpoint, correct?

msf5 > db_connect -l

Data Services
=============

current  name                       url                       default?
-------  ----                       ---                       --------
         V7mmyJp7                   http://172.28.128.5:8080  
         local-https-data-service   https://localhost:8080    *
*        test_remote_vm_connection  http://172.28.128.5:8080  
@mkienow-r7

This comment has been minimized.

Copy link
Contributor

mkienow-r7 commented Jan 9, 2019

Not directly related to these changes, but removing the remote data service one is currently connect to with db_remove and then calling db_status the connect name is reported. Do you think this is a little confusing?

msf5 > db_connect -l

Data Services
=============

current  name                       url                       default?
-------  ----                       ---                       --------
*        V7mmyJp7                   http://172.28.128.5:8080  
         local-https-data-service   https://localhost:8080    *
         test_remote_vm_connection  http://172.28.128.5:8080  

msf5 > db_remove V7mmyJp7
Successfully deleted data service: V7mmyJp7
msf5 > db_status 
[*] Connected to remote_data_service: (http://172.28.128.5:8080). Connection type: http. Connection name: V7mmyJp7.
msf5 > db_connect -l

Data Services
=============

current  name                       url                       default?
-------  ----                       ---                       --------
         local-https-data-service   https://localhost:8080    *
         test_remote_vm_connection  http://172.28.128.5:8080  
@jbarnett-r7

This comment has been minimized.

Copy link
Contributor

jbarnett-r7 commented Jan 9, 2019

To confirm these changes allow the user to add multiple entries for the same remote endpoint, correct?

msf5 > db_connect -l

Data Services
=============

current  name                       url                       default?
-------  ----                       ---                       --------
         V7mmyJp7                   http://172.28.128.5:8080  
         local-https-data-service   https://localhost:8080    *
*        test_remote_vm_connection  http://172.28.128.5:8080  

Correct. That's where the issues we were seeing were coming from. We would match on the hostname and load the existing connection details and try to connect, even though the API token had been changed.

I personally prefer this method because we cannot run into a situation where we confuse two connections based on a single similarity. If the user accidentally creates multiple entries for the same host, they can delete them afterwards.

@jbarnett-r7

This comment has been minimized.

Copy link
Contributor

jbarnett-r7 commented Jan 9, 2019

Not directly related to these changes, but removing the remote data service one is currently connect to with db_remove and then calling db_status the connect name is reported. Do you think this is a little confusing?

msf5 > db_connect -l

Data Services
=============

current  name                       url                       default?
-------  ----                       ---                       --------
*        V7mmyJp7                   http://172.28.128.5:8080  
         local-https-data-service   https://localhost:8080    *
         test_remote_vm_connection  http://172.28.128.5:8080  

msf5 > db_remove V7mmyJp7
Successfully deleted data service: V7mmyJp7
msf5 > db_status 
[*] Connected to remote_data_service: (http://172.28.128.5:8080). Connection type: http. Connection name: V7mmyJp7.
msf5 > db_connect -l

Data Services
=============

current  name                       url                       default?
-------  ----                       ---                       --------
         local-https-data-service   https://localhost:8080    *
         test_remote_vm_connection  http://172.28.128.5:8080  

I could see how this is a little confusing. It depends on how you look at it. The db_remove operation only removes the saved connection settings. It doesn't imply that it also disconnects you. If you look at it purely from a data management perspective it makes sense as-is.

If we are trying to create a perception that the saved connections are 1:1 with the active connection, this does pose a problem. If that's the case, we can change it so db_remove also initiates a disconnect if that is the connection you are currently connected to.

@mkienow-r7 mkienow-r7 merged commit a2548fe into rapid7:master Jan 9, 2019

3 checks passed

Metasploit Automation - Sanity Test Execution Successfully completed all tests.
Details
Metasploit Automation - Test Execution Successfully completed all tests.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

mkienow-r7 added a commit that referenced this pull request Jan 9, 2019

@mkienow-r7

This comment has been minimized.

Copy link
Contributor

mkienow-r7 commented Jan 9, 2019

Release Notes

This changes the behavior of the db_connect command for storing persistent connections. Existing connections will be updated based on a matching name only rather than matching connection properties in order to fix an issue when updating an existing connection with slightly different properties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment