Re: [NSE] sip-extensions.nse

[Hani Benhabiles <kroosec () gmail com>]

On 07/14/2012 10:38 PM, Aleksandar Nikolic wrote:
> Hi Hani,
>
> I'm glad that this is the first script that uses new functionality in brute.lua!
>
> But I noticed one thing.
> You set a username iterator with setUsername iterator but you don't
> set any other options.
> So, as far as I can tell, the script uses the default iterator, which
> is pw_user_iterator.
> Which means that it will iterate over passwords as well, and it would
> repeat usernames as it test all the usernames against all passwords
> even tho you don't use the passwords (it uses the default password
> iterator from unpwdb).
>
> Am I right?
>
> If that is the case, what you could do is use
> setPasswordIterator instead of setUsernameIterator and specify that
> you want password only bruteforcing by setting the passonly option of
> engine to true.
>
> Altho I only took a quick glance over the script
> so I might be wrong.
>
> Aleksandar
>
>
> On Sat, Jul 14, 2012 at 11:26 PM, Hani Benhabiles <kroosec () gmail com> wrote:
> > On 07/04/2012 12:45 PM, David Fifield wrote:
> > > On Sat, Jun 30, 2012 at 11:14:41AM +0100, Hani Benhabiles wrote:
> > > > On 06/29/2012 09:07 PM, Patrik Karlsson wrote:
> > > > > There seems to be some overlap here with sip-enum-users?
> > > > > Or am I missing something?
> > > > Hi Patrik,
> > > >
> > > > SIP servers in the wild use usually either usernames or numbers as
> > > > extensions. The later seems to be more common as I came across it
> > > > more often and given how many testing tools and suites (i.e
> > > > sipvicious, metasploit aux etc...) focus on scanning ranges of
> > > > numbers (with things such as padding 0's) rather than on usernames
> > > > from a dictionnary list. I believe having two separates scripts that
> > > > do simple and effective work depending on the situation is better
> > > > than one bloated script with many options and requiring the user to
> > > > supply many script-arguments.
> > > I disagree with this thought. There should not be two scripts with two
> > > implementations of what is basically the same function.
> > >
> > > Both scripts should be the same script and should probably use the brute
> > > library. A custom user name iterator can handle creating all the numeric
> > > extensions. There are not many name in usernames.lst, so checking them
> > > in addition to extensions will not be much more cost.
> > >
> > > David Fifield
> > Hi,
> >
> > I am attaching an overhauled version (renamed to sip-enum-extensions). The
> > script now is ported to brute.lua and also allows iterating over users list
> > (from usernames.lst or one provided by the user).
> >
> >
> > Cheers,
> > Hani.
> >
> > --
> > Hani Benhabiles
> >
> > Twitter: https://twitter.com/#!/kroosec
> > Blog: http://kroosec.blogspot.com
> >
> >
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
Hi Aleks,

Thanks for the quick input!
No, it doesn't iterate over passwords from default list, just repeating 
the same password value as username.
As an example, if I provide as script arguments, minext=1, maxext=3 and 
users=1 (later means, use usernames.lst), the script will try these 
combinations:
username    password
    1                    1
    2                    2
    3                    3
   root               root
   admin           admin
    ...                    ...

Obviously, the script is using the usernames values only. But you have a 
good point, though. In case default values for brute.lua are changed 
(either in the library, or as user set arguments for other brute 
scripts), this may end up adding iteration. So, for precaution, I am 
changing the script to using the password values, setPasswordIterator 
and brute.options.passonly to true.

Cheers,
Hani.

--
Hani Benhabiles

Twitter: https://twitter.com/#!/kroosec
Blog: http://kroosec.blogspot.com

Attachment: sip-enum-extensions.nse
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/