Re: Jiayi's Status Report - #17 of 17

[Paulino Calderon <paulino () calderonpale com>]

Hey,

Thanks for the detailed feedback Daniel. I appreciate it and will look into
it.

Regarding interactive mode, while I agree is not standard to read from
stdin I find it very useful for those cases when the product name and
version are not determined correctly. It allows you to enter a custom
lookup string. Maybe we could also incorporate an option to even skip the
check if the version is too generic and avoid returning a lot of false
positives. I didn't find issues with nmap interactive mode but I could have
overlooked this in my testing.

I'll go over this again and submit a new version that address all this.

Cheers
El 15/9/2015 11:55, "Daniel Miller" <bonsaiviking () gmail com> escribió:

> Jiayi, Paulino,
>
> I took some time today to look at the vulscan script and here is my
> detailed feedback:
>
> 1. The update feature should be accomplished in the script prescanning
> phase by using a prerule. As I read it, if a user were to use --script-args
> vulscan.updatedb along with a network range like 192.0.2.0/24, the update
> functions would be called for every host in the range. You can look at
> scripts like nfs-ls and ssh-hostkey to see examples of running a script in
> multiple phases.
>
> 2. We should use a unique user agent string for the update features so
> that the owners of those databases can distinguish this update traffic. I'd
> suggest something like "Mozilla/5.0 (compatible; Nmap Scripting Engine
> vulscan.nse; https://nmap.org/nsedoc/scripts/vulscan.html)"
>
> 3. Output needs work: We shouldn't be building strings with repeated
> concatenation (e.g. loops over s = s .. "something"). This is
> resource-intensive. Instead, use strbuf [1] or just a table and
> table.concat(). I would prefer to see the output table structured in such a
> way as to produce useful text output by automatic processing (using
> __tostring metamethods as needed) but I think that's not absolutely
> necessary.
>
> 4. The report_parsing function could be done much simpler with either the
> table or the function versions of string.gsub [2]. Realize that every call
> to string.gsub requires the string to be searched again from the beginning.
> Also, the \n and \t substitutions could be done just once at the beginning
> of execution, since they don't depend on the finding itself.
>
> 5. The "interactive mode" doesn't fit with Nmap's usual mode of operation.
> It is a significant enough change that I think it deserves its own
> discussion before being added: no other script is allowed to read directly
> from stdin like that. How does it even work with Nmap grabbing terminal
> input for runtime interaction?
>
> 6. I don't understand the "versiondetection" argument. Can we expand the
> documentation on that?
>
> 7. Watch for string concatenation badness throughout. I spotted more x = x
> .. "y" in the update_cve and other update functions.
>
> Dan
>
> [1] https://nmap.org/nsedoc/lib/strbuf.html
> <http://nmap.org/nsedoc/lib/strbuf.html#>
> [2] http://www.lua.org/manual/5.2/manual.html#pdf-string.gsub
>
> On Mon, Sep 14, 2015 at 9:24 PM, Paulino Calderon <
> paulino () calderonpale com> wrote:
>
> > Hey,
> >
> > I've been using the vulscan script these past weeks and  there are a
> > couple of additional checks that I added to my working copy but I think it
> > is ready for inclusion after updating the installation instructions.
> >
> > I'll keep working with jiayi to include everything that is stable this
> > week.
> >
> > Cheers.
> > El 14/9/2015 15:28, "Fyodor" <fyodor () nmap org> escribió:
> >
> > > On Sun, Aug 23, 2015 at 6:03 PM, Jiayi Ye <yejiayily () gmail com> wrote:
> > > > It was great to take part in GSoC. It was a fun summer.
> > >
> > > Thanks Jiayi.  We all enjoyed working with you too!
> > >
> > >
> > > >  Here are what I accomplished and what I will do next.
> > >
> > > This is a great summary and helps us in trying to make sure that as much
> > > as possible can be integrated into the Nmap trunk where it can benefit
> > > millions of Nmap users.  Regarding that:
> > >
> > >
> > > >  *  Tor-consensus-check (NEW): This script works by using
> > >
> > > I think this one is already all integrated!
> > >
> > > *
> > > > smtp-vuln-cve2015-0235 (NEW): This script checks for and/or exploits a heap-based buffer overflow in the GNU C 
> > > > Library's gethostbyname functions on x86 and x86_64 GNU/Linux systems (CVE-2015-0235) that run the Exim mail 
> > > > server. I finished the detection part to report vuln CVE 2015-0235 in Exim mail server, besides, I wrote the part 
> > > > of information leak, but I failed to perform successful exploitation in my vulnerability environment.
> > >
> > > How about removing the (not fully working) exploitation part and then
> > > checking in just the version of the script which does the vuln check?  And
> > > then you could integrate the rest if and when it's working?
> > >
> > > *
> > > > vulscan (UPDATE): This script attempts to discover vulnerabilities by matching information from the version 
> > > > detection engine with databases such as CVE, ExploitDB and Scipvuldb. I updated the script in the following 
> > > > aspects.
> > >
> > > I haven't looked at this one real closely yet.
> > >
> > >  *
> > > > http-vuln-cve2015-1635 (UPDATE): This script checks for a remote code execution vulnerability (MS15-034) in 
> > > > Microsoft Windows systems (CVE2015-2015-1635). And I updated http-vuln-cve2015-1635 to perform reliable 
> > > > information disclosure by trying different byte ranges.
> > >
> > > Great.  If you and Paulino agree that this is ready to check in, please
> > > do so.
> > >
> > >
> > > >  *  smb-check-vulns.nse (UPDATE): I split the script into six scripts (
> > > > https://github.com/nmap/nmap/issues/171) and ported these
> > > >
> > > >  vulnerability scripts to the vulns library. Besides, I set vulnerability environment for each of them and tested 
> > > > the splitted scripts in different vuln environment.
> > >
> > > Nice!  Dan was telling me how valuable he thought this sort of
> > > reorganization would be.  I think he's going to take a look at it and
> > > provide feedback.
> > >
> > >
> > > > NSELIB:
> > > >
> > > >
> > > > * I spent a amount of time on implementing functionality related to SMB2 protocol. At first I wrote a sperated lib 
> > > > named smb2.lua. Then I combined smb2.lua with current smb.lua.
> > >
> > > This may actually turn out to be the most valuable of all your
> > > contributions this summer.  Neither Dan nor I have very much SMB2
> > > expertise, but Dan said he'd at least take a look soon.  It's of course
> > > encouraging that you've tested it on both Windows and Samba SMB servers.
> > >
> > > This is a lot of good stuff and I just want to make sure that as much as
> > > possible can make that final but crucial Nmap integration step.
> > >
> > > Cheers,
> > > Fyodor
> > >
> > >
> > > _______________________________________________
> > > Sent through the dev mailing list
> > > https://nmap.org/mailman/listinfo/dev
> > > Archived at http://seclists.org/nmap-dev/
> >
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/