[framework] Reading RHOSTS from a file.

[Kashif Iftikhar]

Miller,

   Why not add more code to the normalize function of OptAddressRange
class so that it checks if the address starts with something of the
format: 'file://path/to/file' then it should open the file and try to
read address ranges from it?

  The class already contains code like:

when /\//
   sets << Rex::Socket.cidr_crack(range)

  so why not add a "when /^file:\/\// " clause there and do the
processing? If you think its a viable idea, I can get it done.

  BTW, did you read my follow up questions on auxiliary modules? If
you can reply to them it would be much help.

- Kashif.


On 4/24/07, mmiller at hick.org <mmiller at hick.org> wrote:
> On Mon, Apr 23, 2007 at 10:39:08PM +0000, Kashif Iftikhar wrote:
> >  I need suggestions to implement a way to read target hosts from a
> > file similar to the RHOSTS parameter in most scanner modules of type
> > OptAddressRange. What would be the best way to implement it? Should I
> > try adding another option type say 'OptAddressRangeFromFile' that
> > takes in a filename and reads addresses from it and then converts it
> > into address range sets? Or creating a plugin that adds a command to
> > MSF say 'read_addresses_from_file' and stores it into the specified
> > option?
>
> I think one of the easier options would be to add a new option class
> called OptAddressRangeOrPath.  This would allow you to specify either an
> address range or a path to a file that contains address range(s).  The
> option validator would accept either case.  We'd just need to add an
> abstraction in the scanner mixin that would automatically read from the
> file and then process each of the embedded range(s).
>
> The problem with doing it by adding a new option is that you can't
> currently have both RHOSTS and RHOSTSFILE (for example) be required, as
> it wouldn't make sense in this case.  By switching RHOSTS to something
> that can either be a range or a file, it's easier to support.  This kind
> of munges the structure of RHOSTS, but it doesn't seem like it'd be too
> bad.
>