Nexpose issue

Viewing 7 reply threads
  • Author
    Posts
    • #7234
      SephStorm
      Participant

      Hi all,

      doing a vulnerability scan of one of my servers at home. I performed the initial scan this morning, and applied some simple fixes. I wanted to rescan so i did, and the scan hung. I looked at the log and saw I was getting “Failure during handshake” errors. well, I had to go to work so i aborted the scan and when I got back, I reverted some of the fixes because they broke samba. I assumed the scan would work fine, but it appears the issue is not the fixes. This is the error im getting.

      Fingerprinte2012-01-13T04:39:41 [192.168.0.10:139] Starting fingerprinting (fingerprint)...
      Fingerprinte2012-01-13T04:39:42 [192.168.0.10:139] Unexpected failure during handshake: java.lang.UnsupportedOperationException: NetServerGetInfo
      at com.rapid7.net.cifs.CifsServer.A(Unknown Source)
      at com.rapid7.net.cifs.CifsServer.getServerInfo(Unknown Source)
      at com.rapid7.net.cifs.CifsConnection.getPossibilities(Unknown Source)
      at com.rapid7.nexpose.plugin.net.protofp.CIFSProtocolHelper.fingerprint(Unknown Source)
      at com.rapid7.nexpose.plugin.net.protofp.PortFingerprinter.performMatch(Unknown Source)
      at com.rapid7.nexpose.plugin.net.protofp.PortFingerprinter.fingerprint(Unknown Source)
      at com.rapid7.nexpose.plugin.net.protofp.ProtocolFingerprinter.fingerprint(Unknown Source)
      at com.rapid7.nexpose.plugin.net.protofp.ProtocolFingerprinter.fingerprint(Unknown Source)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      at java.lang.reflect.Method.invoke(Unknown Source)
      at jess.Call.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.Bind.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.TryCatch.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.Deffunction.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.If.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.TryCatch.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.Deffunction.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at jess.FuncallValue.resolveValue(Unknown Source)
      at jess.Deffunction.call(Unknown Source)
      at jess.FunctionHolder.call(Unknown Source)
      at jess.Funcall.execute(Unknown Source)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      at java.lang.reflect.Method.invoke(Unknown Source)
      at com.rapid7.thread.ThreadedCall.invokeCall(Unknown Source)
      at com.rapid7.thread.ThreadedCall.B(Unknown Source)
      at com.rapid7.thread.ThreadedCallRunner.executeCall(Unknown Source)
      at com.rapid7.thread.ThreadedCallRunner.run(Unknown Source)

      Fingerprinte2012-01-13T04:41:57 [192.168.0.10:139] Failure during handshake: java.net.SocketTimeoutException

      any ideas? is this a problem on the scanner or the server, and any ideas whats wrong?

    • #45226
      SephStorm
      Participant

      FYI, it appears that the scan does indeed complete, (this time) but it takes quite a bit more time than the original 1 minute scan, so I am interested in resolving the issue.

      Also a question, I have a few questions regarding vulnerabilities.

      1 I have SMB signing vulnerabilities, I am not sure I can resolve this, as I am using a workgroup, not a domain, and the MS kb states that this requires client and server settings. now im sure that I could possibly fing some way to set up signing on the clients without putting them in a domain, but is it worth it? I see the vulnerability is in MITM attacks, are there any mitigation’s I can apply? Is this exploitable over the internet? (I have a feeling this is what broke samba previously.)

    • #45227
      dynamik
      Participant

      Requiring SMB signing will definitely break things unless everything supports it. There is an intermediary option that uses it only if when it’s supported.

      You can modify the local security policy instead of applying group policies; the settings are the same.

      It could only be exploitable over the internet if you had SMB directly accessible over the internet.

    • #45228
      cd1zz
      Participant

      Check to see if you’re doing full connect scans on nexpose, that would take a long time if you’re doing all ports.

      SMB signing will prevent smb_relay attacks but its only turned on by default on DCs. Member servers for example dont have it “enabled.”  Like dynamik said, there is an option to set it to negotiate if possible, otherwise not to use it.

    • #45229
      SephStorm
      Participant

      @dynamik wrote:

      Requiring SMB signing will definitely break things unless everything supports it. There is an intermediary option that uses it only if when it’s supported.

      You can modify the local security policy instead of applying group policies; the settings are the same.

      It could only be exploitable over the internet if you had SMB directly accessible over the internet.

      Thats actually what I was thinking, the local security policy. I also found out that preventing anonymous discovery of network shares prevents me from accessing the shares period.

      honestly I dont know if smb is/will be accessible from the internet. I know I intend to use the server’s VPN options to remotely access my files, so I assume it will be, but then again, once I VPN in, I am considered on the local network right? All smb traffic would be going through the tunnel and not directly accessible?

    • #45230
      cd1zz
      Participant

      It would be very very bad to expose smb to the internet.

    • #45231
      l33t5h@rk
      Participant

      @SephStorm wrote:

      once I VPN in, I am considered on the local network right? All smb traffic would be going through the tunnel and not directly accessible?

      Correct, it would all be tunneled and the cifs ports will not be exposed. It’s unlikely the ports are exposed externally as you would have to have explicitly defined this. Hope this helps!

    • #45232
      SephStorm
      Participant

      ok, sounds good. I am still going to run some scans on my public ip, just to see if anything has been unknowingly exposed. I expect the vpn port to be open.

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

Copyright ©2020 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?