[SERVER-70549] Speculative authentication with SCRAM-SHA-256 disabled on mongod creates audit message Created: 13/Oct/22  Updated: 29/Oct/23  Resolved: 12/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.4.16
Fix Version/s: 6.3.0-rc0

Type: Bug Priority: Major - P3
Reporter: Spencer Brown Assignee: Militsa Sotirova
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Assigned Teams:
Server Security
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
  • Run a standalone server 4.4.x with auditing enabled (no filter), setParameter authenticationMechanisms has SCRAM-SHA-1 but not SCRAM-SHA-256.
  • Create a test SCRAM user and authenticate with that user in mongosh.
  • In the mongod log, notice there is a speculative authentication attempt against SCRAM-SHA 256 from the node.js driver even though it's disabled at the server.
  • In the audit log, notice an audit log message for the SCRAM-SHA-256 speculative login attempt with result code 18.
Sprint: Security 2022-12-12, Security 2022-12-26, Security 2023-01-09, Security 2023-01-23
Participants:
Case:
Linked BF Score: 141

 Description   

When running with SCRAM-SHA-256 not enabled on a mongod server, speculative authentication attempts with SCRAM-SHA-256 cause audit messages to be logged indicating authentication failures (result code 18).

This is undesirable, as the appearance of an authentication failure message in the audit log can be taken as an indication that someone is actually trying to login with a bad password.

The ask here is to stop triggering audit events for speculative authentication failures.



 Comments   
Comment by Githook User [ 12/Jan/23 ]

Author:

{'name': 'Militsa Sotirova', 'email': 'militsa.sotirova@mongodb.com', 'username': 'militsasotirova'}

Message: SERVER-70549 Fix AuthenticationSession logic
Branch: master
https://github.com/mongodb/mongo/commit/a8d5b7a8a8298b00a069f648b9d3f8734812e49e

Comment by Githook User [ 12/Jan/23 ]

Author:

{'name': 'Militsa Sotirova', 'email': 'militsa.sotirova@mongodb.com', 'username': 'militsasotirova'}

Message: SERVER-70549 Fix AuthenticationSession logic
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/e887c768db4dc3a1398729b195abe8785fd03f38

Comment by Sara Golemon [ 13/Dec/22 ]

Oh, it should be noted that for clients experiencing this spurious log warning/audit, they can instruct their clients to use a URI which includes the authentication mechanism.  e.g.   `mongodb://alice:secret@server1:27017/admin?authenticationMechanism=SCRAM-SHA-1 . The client/driver should then speculate saslStart using the correct mechanism.

Comment by Sara Golemon [ 12/Dec/22 ]

Just want to clarify that the goal here is for the speculative failure to not cause the logging IF AND ONLY IF it subsequently succeeds for the same user via saslStart/saslContinue ?

I don't want to see a blanket skip on the auth failure as that opens an avenue for brute forcing.

Comment by Spencer Jackson [ 21/Oct/22 ]

I expected this to have been resolved by SERVER-52863, but I just reproduced this on the master branch. Since SERVER-52863, the server's AuthenticationSession gets created during hello's SASL mechanism negotiation. It seems that failed speculation is causing the AuthenticationSession to get torn down and re-created, producing an audit event as a side effect.

Failed speculative auth should not be considered an error by the AuthenticationSession, nor produce an audit event. The session should remain active, until a subsequent hello, definitively auth exchange, or if the Client it's attached to is destroyed.

Generated at Thu Feb 08 06:16:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.