NeXpose vulnerability scanner review

Viewing 14 reply threads
  • Author
    Posts
    • #5851
      SephStorm
      Participant

      Hello all,

      I was preparing to turn in after a successful night, when I realized that I should probably share it with you all.I have been wanting to use a vulnerability scanner at home to see my vulnerabilities, and get some experience doing it. I have been looking at Nessus, but I didnt feel ready to go for it, and I worried with some modules requiring payment. While looking into Metasploit Unleased in an attempt to understand tools I was using in my studies, I found a scanner called NeXpose from Rapid7, the owners of the popular Metasploit Framework. So I am writing a quick review based on my experience.

      NeXpose is vulnerability management software from Rapid7. The community edition is a free single user license program. One of the first things I noticed is that it claimed to be a full vulnerability management program, unlike the Secunia PSI program I use, which only scans for out of date/EOL/vulnerable software.

      In any case, I looked into the program after a short registration process, I was emailed the activation code and the email included links to the download, and the software manual. I downloaded and began reading the manual while downloading the software, and found it easy to understand, and the walkthough was fairly comprehensive. I defiantly appreciated that, although it was not really necessary for most of the installation.

      Installation was a breeze, no configuration changes necessary during install although according to documentation, security software will interfere with its use, so they appear to want you to disable WF, and any other applications that could interfere, AV was mentioned, I assume because of the exploit databases. Obviously this will require forward planning, insure your hosts are behind a boundary firewall, if you require internet connectivity (which you will at least for the program update)

      The one issues I encountered that was not noted in the manual was issues that ended up being caused by Internet Explorer’s enhanced security configuration (The software is supported on Windows Server 2k and 2k3 and Linux OS’ only)

      There was one additional issue after I completed my first scan, where the program stayed at the scanning page, but the console said the scan was done, I simply closed and reopened the browser, and it was GTG.

      Scanning time was fairly quick, I would say under 5 minutes for one host, but I wasnt counting, It may have been closer to 3. I was able to monitor the action via the program’s console, in which the program would attempt to access services, attempt exploits. I am pleased to announce that it only found 1 vulnerability, which it gave me an easy to follow recommendation for remediation. I can say there is little else as pleasing as seeing those words scroll by: NOT VULNERABLE, LOGIN ATTEMPT FAILED, ect… 🙂 I’ll be glad to answer any questions you guys may have, and thanks for letting me share.

    • #36724
      tturner
      Participant

      Did you do a credentialed scan?

    • #36725
      SephStorm
      Participant

      I originally tested this, putting in my credentials, but it was unable to connect or something. My thoughts at the moment was that the service it was trying to connect to was unfamiliar to me, so im not sure there was any program to answer the login call…

    • #36726
      tturner
      Participant

      The reason why I ask is you will likely see a much larger number of vulns if you are supplying credentials to the scan process. I’d highly recommend looking at your configuration and using credentialed scanning. What service were you connecting with?

      I typically use SMB for Windows and SSH for Linux and other protocols when I need visibility inside a specific application. Make sure you can get through the firewall with those protocols or disable it for your test. Obviously you need to be running an SSH server to connect via SSH. NeXpose is a pretty awesome vuln scanner. I love that it tells me when a vuln is metasploitable. I get all giddy when I see the “m”!

    • #36727
      sil
      Participant

      Couldn’t agree more with tturner on this. When I’m tasked to perform security tests I almost always opt for “credentialed” testing second to a blackhat test. Too many people forget about escalation privileges and many times, escalatable vulnerabilities can lead to a full blown compromise.

      When I test something, this is the format I use whenever possible:

      Blackhat zero knowledge –> target –> EXTERNAL addressing
      Allows me to find the low hanging fruit which is easily visible. This also allows for Incident Response testing. I prefer zero knowledge testing to avoid alerting admins that “we’re coming” since many times admins seem to think you’re there to lay blame. Often, they’ll “patch” things up against you and stupidly leave it vulnerable to the world. “I’ll show those pentesters… Firewall em when I see them” I rely heavily on decoys for my testing to avoid having underclued admins block me out from doing what I was hired to do.

      Greyhat limited knowledge –> target –> EXTERNAL addressing
      Using credentials allows me to see if anyone can abuse privileges. Not only this, it allows me to NOT resort to bruteforcing which can be noisy and time consuming unless you’ve built your own distributed cracker (not a hard thing to do ya know)

      Blackhat zero knowledge –> target –> INTERNAL addressing
      Allows me to find out WHAT – if someone carried out a client side attack – would be exploitable on the target. Remember, from an internal perspective, most machines will show a lot more information since many networks believe all their machines should trust all of their machines.

      Greyhat limited knowledge –> target –> INTERNAL addressing
      Using credentials INTERNALLY allows the same outcome as above – however, makes for easier escalation and hopping (pivoting/hopping/jumping LANs/VLANs)

    • #36728
      SephStorm
      Participant

      Well, previously, I was using the test option to test an attempt using the credentials and it was denied. I tried today using both admin and non  admin creds, and they went through fine, so I must have just forgotten something.

      Anyway, I first performed a scan using the non privileged account, and got 4 vulnerabilities, including the one I thought I fixed… It was the ICMP Timestamp… the other three are best practices I dont need on my home PC, Password expiration, account lockout, password length. I’ll make a few changes, but i probably wont make the password expiration.

      Later on today I’ll run the scan with admin creds, see what happens.

    • #36729
      hayabusa
      Participant

      Yeah, tturner and sil were dead on.  The issue with NOT using ‘credentialed’ scanning is that you miss issues that might be necessary to address, should someone already have access to the network or target machine.    I think sil covered the bases enough with his reply, but suffice to say, it’s always safest to cover all bases when testing, assuming the scope of the testing / analysis is permissive of the same.  (Remember to cover these things in depth with clients, when setting the scope of your projects, so that they understand not only what you want to do, but WHY.)

    • #36730
      SephStorm
      Participant

      Understood and agreed.

      Let me ask, how was my review? Is there anything I should have covered and left out?

    • #36731
      hayabusa
      Participant

      I thought you did a well with the review.  Nothing really ‘left out,’ and you gave good detail about your personal experience with the entire process, from registration / activation, to usage.  Good job.

    • #36732
      kagyu
      Participant

      Has anyone had any luck using credential scans when sudo is required?  It seems that NeXpose expects root credentials and I don’t know many places that would allow direct SSH logins with root.  As of yet, I haven’t found a configuration point that allows me to leverage sudo.

      Do those of you that are happy with this product allow direct root logins via SSH?

    • #36733
      SephStorm
      Participant

      The Academy Pro has several videos on the NeXpose scanner, that may include the info you need.

      http://www.theacademypro.com

    • #36734
      tturner
      Participant

      @kagyu wrote:

      Has anyone had any luck using credential scans when sudo is required?  It seems that NeXpose expects root credentials and I don’t know many places that would allow direct SSH logins with root.  As of yet, I haven’t found a configuration point that allows me to leverage sudo.

      Do those of you that are happy with this product allow direct root logins via SSH?

      It’s really straightforward to set this up for a non root account. Just give the scanner non root credentials. If it’s not working, then check your SSHD configs. As for needing sudo, I’m not sure how to resolve this other than temporarily modifying the sshd config to allow root. I don’t know how to tell NeXpose to sudo, but the account I use to SSH in and scan has read permissions in most places that I need so it’s usually not an issue.

      I’ll play around with this later in the metasploit module for nexpose and see if there are some other options there we can leverage.

    • #36735
      tturner
      Participant

      Busy day today, just got a chance to look at this again. Within Metasploit you have the -c option for credentialled scanning for the nexpose module

      -c  Specify credentials to use against these targets (format is type:user:pass[@host[:port]]

      So that’s pretty much what we have in the GUI. Not much help really.

      I loaded up the diagnostics console at https://127.0.0.1:3780//admin/diag_console.html and issued the

      show scan configs

      command and got back the following entry on one of my SSH enabled configs

       (173 char hex value)

      *Edit* According to R7 this is not supported at all. They suggested the use of RSA keys.

    • #36736
      timmedin
      Participant

      I use Nessus and NeXpose regularly. I really like NeXpose’s UI (Nessus’s sucks) and its web checks. The pretty export formats are nice, but the down and dirty csv and xml formats leave much to be desired.

      NeXpose is also a memory pig! So buy some more ram. Support won’t even talk to you if you don’t have 4Gb available. After making a few [unsupported] tweaks to the db config it doesn’t pound my testing lappy when I run it.

      They also have a few false positives (MS09-001), but otherwise it is quite accurate.

      The biggest pain point is it licensing model. You have to pay by the number of IPs it can scan, which is counter to Nessus’s scan the planet method.

      I know I sound like I’m dogging on NeXpose, but I actually quite like it. The UI is something I really like. Also, if you run it internally, you can compare scans which is a big plus!

    • #36737
      timmedin
      Participant

      Someone asked for my changes. Here they are, but they may invalidate support, cause other problems, kill puppies, or cause bad breath. Proceed at your own risk.

      Edit /opt/rapid7/nexpose/nsc/nxpgsql/nxpdata/postgresql.conf
      Line 61, change max_connections from 100 to 50

      Line 104, change shared_buffers from 32MB to 16MB

      The combination of these two settings reduces memory consumption by 75%.

Viewing 14 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.

Sending

Sign in with Caendra

Forgot password?Sign up

Forgot your details?