Skip to content

Latest commit

 

History

History
92 lines (69 loc) · 3.14 KB

README.md

File metadata and controls

92 lines (69 loc) · 3.14 KB
Raw

Mongo ObjectId introduction

Mongo ObjectIds are generated in a predictable manner, the 12-byte ObjectId value consists of:

  • a 4-byte value representing the seconds since the Unix epoch,
  • a 3-byte machine identifier,
  • a 2-byte process id, and
  • a 3-byte counter, starting with a random value.

Some web and REST APIs use these as resource IDs, and because developers believe they are randomly generated or difficult to guess, they are also frequently used as (a very weak) authorization layer: if you know the ObjectId then you have to be the right user.

A potentially vulnerable REST API will look like this:

GET /pet/5ae9b90a2c144b9def01ec37 HTTP/1.1
Host: vulnerable.com
X-API-Key: ...

And the code that handles that request (notice the lack of authorization):

@route('/pet/{id}')
@is_authenticated
def handle_get_pet(id):
    return PetFromMongoORM.get(id)

Predicting Mongo ObjectIds

The tool I created will predict Mongo ObjectIds given a valid initial value:

./mongo-objectid-predict 5ae9b90a2c144b9def01ec37
...
5ae9bac82c144b9def01ec39
...
5ae9bacf2c144b9def01ec3a
...
5ae9bada2c144b9def01ec3b

Usually you'll use this tool together with Burp, or your own custom script in order to brute-force a resource:

import requests

from mongo_objectid_predict import predict

for objectid in predict('5ae9b90a2c144b9def01ec37'):
    response = requests.get('http://target.com/resource/%s' % objectid)
    process_response(response)

Controlling the prediction process

There are two command line parameters which will control how many potential mongo ObjectIds are generated: --counter-diff and --per-counter.

Counter diff will control the iteration over the last 3 bytes (the counter) of the ObjectId. So, if the last 3 bytes from the base ObjectId were 000020, you can control how much to increment or decrement this value using --counter-diff. By default we set it to 20.

Per counter will control the first 4 bytes of the ObjectId: the epoch time. For each newly generated counter (last 3 bytes) the tool will generate N --per-counter epoch times.

It is important to know that ObjectIds are generated for all MongoDB tables: the counter will be incremented for objects which are not the one queried by the application. This means that depending on the way the application was developed, its load, etc. you might need to play with --counter-diff and --per-counter until something interesting is found.

The last parameter you can use is --backward. Instead of adding to the counter the tool will decrease it. The same thing happens with the epoch counter.

Improvements

This tool should work on simple MongoDB installations, where no clusters are used (machine identifier remains constant) and the MongoDB hasn't been restarted (process ID remains constant).

For other scenarios prediction is still possible, but requires more requests and potentially a different algorithm which receives more samples, analyzes them and then starts producing ObjectIds for that specific installation.