Re: [NSE] http-vuln-cve2015-1427 Remote Code Execution in Elastic Search

[Daniel Miller <bonsaiviking () gmail com>]

Gyani,

This looks good! If you can fix the following minor issues, you can go
ahead and commit this (check with me on IRC if you are unsure about
procedures):

* Don't use nocache options for the initial version check; this was only
needed for the index check later on.
* For the @output section, use the output of a run without a custom
command, i.e. containing "ElasticSearch version:" and "Java version:". Also
make sure the "ISSUE" is not part of this section.
* Convert stdnse.print_debug calls to stdnse.debug
* Cleanup trailing whitespace.

Dan

On Sat, Mar 14, 2015 at 5:28 AM, Gyanendra Mishra <anomaly.the () gmail com>
wrote:

> Hi,
>
> Thanks for your help!
>
> On Sat, Mar 14, 2015 at 1:04 AM, Daniel Miller <bonsaiviking () gmail com>
> wrote:
>
> > So what is left? I don't like how we don't give any output if we can't
> > create the new index. We should either:
> >
> > 1. create the index as needed without a script-arg (I don't like this
> > option), or
> > 2. Check the version number (GET / => response.version.number) and set
> > LIKELY_VULN if it matches "1.3.[0-7]" or "1.4.[0-2]". Then proceed to
> > exploit regardless of version reported and set EXPLOITED if that succeeds.
> > Only return nil if it's not Elasticsearch at all.
>
> I too found option 2 better. I implemented the same in the attached
> script. Now the script checks for the version, if a vulnerable version is
> found then it sets vuln_table.state to LIKELY_VULN along with updating the
> port version. The report table is returned instead of nil in most places
> now.
>
> Gyanendra
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/