CosmoDB Mongo Firewall not blocking unauthenticated connections

cpollfh 26 Reputation points
2020-06-18T21:24:37.203+00:00

I've set up Firewall CIDRs in my-mongodb -> Firewall and virtual networks, as per https://learn.microsoft.com/en-us/azure/cosmos-db/firewall-support

However, I'm seeing very strange behaviour:

If I try to connect from a whitelisted IP, the connection succeeds:
mongo REDACTED.mongo.cosmos.azure.com:10255 -u my_username -p my_password --ssl --sslAllowInvalidCertificates
This results in a mongo prompt globaldb:PRIMARY> and full access to the database and collections.

And if I try connecting from a non-whitelisted IP, the connection fails:
2020-06-18T16:43:12.206-0400 I NETWORK [js] DBClientConnection failed to receive message from REDACTED.mongo.cosmos.azure.com:10255 - SocketException: asio.ssl stream truncated
2020-06-18T16:43:12.207-0400 E QUERY [js] Error: network error while attempting to run command 'saslContinue' on host 'REDACTED.mongo.cosmos.azure.com:10255' :
connect@Sérgio Carapinha /mongo/shell/mongo.js:341:17
@(connect):2:6
2020-06-18T16:43:12.209-0400 F - [main] exception: connect failed
2020-06-18T16:43:12.209-0400 E - [main] exiting with code 1

However, if I try connecting without specifying the username and password, I'm able to access the mongo database. I get the mongo shell prompt and can do any unauthenticated commands, letting me do basic reconnaissance, like what the URLs are for the primary and secondaries, the name of the database, etc.

Expected behaviour: The firewall should drop all traffic not coming from a valid IP address. According to https://learn.microsoft.com/en-us/azure/cosmos-db/firewall-support it should at least result in a 403.

Azure Cosmos DB
Azure Cosmos DB
An Azure NoSQL database service for app development.
1,452 questions
0 comments
Accepted answer
  1. Mark Brown - MSFT 2,761 Reputation points Microsoft Employee
    2020-06-19T22:25:20.973+00:00

    These are not security issues for Cosmos DB. These commands only reveal information about Cosmos DB service gateway, which is publicly accessible, and not specific to to any account.

    As Mongo connections come in via TCP, the gateway must terminate the connection before knowing the identify of the account it will be routed to. The gateway must emulate pre-authentication Mongo commands so that the client is able to authenticate. Once the client is authenticated, the firewall will be encountered and will handle connections as configured.

    Thanks.

    1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Mark Brown - MSFT 2,761 Reputation points Microsoft Employee
    2020-06-18T22:57:33.4+00:00

    While you may be able to get a connection you should not have any access to any customer specific database or collections or their data. The only thing that may be visible would be the Cosmos account name itself but that is in public DNS anyway and mirrored back as part of the connection string passed in anyway.

    Can you post some screen caps for what you are seeing?

    Thanks.

    1 person found this answer helpful.
    0 comments
  2. cpollfh 26 Reputation points
    2020-06-19T13:41:51.667+00:00

    Is it possible to set it up so that the connection times out from non-whitelisted IPs?

    Unauthenticated, I'm able to run commands such as db.isMaster(), db.getLastErrorObj(), and db.version(). These reveal significantly more than the Cosmos account name.

    db.isMaster() and db.version() reveal non-public information such as Mongo version and some configuration such as maxWriteBatchSize. This information can be used to create more specific attacks against the application using the Mongo database. db.getLastErrorObj() can be used to probe whether the attack payload is effective.

    What screen caps would you like me to post?

    0 comments