Skip to content
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

Module 'info'? #170

Open
0x646e78 opened this issue May 25, 2020 · 3 comments
Open

Module 'info'? #170

0x646e78 opened this issue May 25, 2020 · 3 comments

Comments

@0x646e78
Copy link

0x646e78 commented May 25, 2020

Coming from recon-ng here, so perhaps I've missed a piece of info in the docs, but so far I can only see high level info on a module.

For example, using shodan-certs:

I can get some high level info here:

> pkg search shodan
kpcyrd/shodan-certs (0.1.0) - 639 downloads [featured] [installed]
        Find IPs using certificates for target subdomains

It doesn't tell me if it needs an API key or not, which would be useful.

I then 'use' it, but I find no way of finding out more about it - such as api key, if I can manipulate the input to it, perhaps anything else that could be useful to know about it? recon-ng has an info when in the context of a module, which can be helpful. In this case maybe the detail such as -- Keyring-Access: shodan from the module could be used?

[sn0int][default] > use shodan-certs 
[sn0int][default][kpcyrd/shodan-certs] > 
activity      autonoscope   back          help          mod           pkg           scope         select        target        quickstart 
add           autoscope     delete        keyring       noscope       run           set           workspace     use 
$ sn0int --version
sn0int 0.18.2
@kpcyrd
Copy link
Owner

kpcyrd commented Jun 6, 2020

Sorry for the late reply. This is definitely a big todo since there's also no way to know which options can be set unless you look into the source.

I'm thinking about adding:

  • a long description that can be used to show demo usage
  • a list for available options so they can be listed and tab-completed
  • which access keys are required and preferably also how to get them
  • a tag system that's also going to be used for "noise control", so you could configure sn0int to be fully passive and never send a request to the actual target or "very noisy" which would allow triggering things like password resets. The default would be somewhere in the middle.

@limakzi
Copy link

limakzi commented Sep 5, 2020

@kpcyrd This is something I really miss too. Take a look at mine modules.
Shodan ports scanner is fully passive, like ctlogs. On the other hands, url-metadata is aggresive.
Is there anything I can help you with delivering this feature?

@kpcyrd
Copy link
Owner

kpcyrd commented Sep 13, 2020

thanks! I've broken this up into smaller issues:

@limakzi Ideally there'd be something like:

[sn0int][default] > use shodan-certs 
[sn0int][default][kpcyrd/shodan-certs] > info

I'm a bit stuck in the design phase though. Information I've been considering to include:

  • The short description, version, author and repository url if known
  • A long description - right now there's only one line to describe the module. Some modules may require a longer description about usage or how to works that could be shown.
  • The info from Add support to track module stealth in metadata #183 and pkg list should show if an api token is required and if it's missing #184
  • Options that are set, can be set, and what they are supposed to do. This is slightly complicated because right now we don't track this in metadata, and we'd need a format that's somewhat powerful:
    • The type may matter, specially for boolean options we could consider limiting possible values to true/false/yes/no
    • We might want to display the default value. This is not possible with the current getopt('foo') or 1 constructs, so we need to move this into metadata and make getopt know about this.
    • The description of the option

Input very welcome!

A naive -- Option header could look like:

-- Option: foo: describe the option here

This is easy to parse but lacks the default value and the type of the option.

The challenge with the long description is that this would require multi-line support. I'm not sure about the aesthetics, I was considering something like:

-- Description: asdf
-- Version: 0.1.0
-- License: GPL-3.0
--- Text goes here
--- in multiple lines.
---
--- And paragraphs.

function run()
    info('ohai')
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants