The Ethical Hacker Network

SephStorm

Hero Member

Offline

Posts: 530

Nexpose issue

« on: January 12, 2012, 10:50:24 PM »

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.

Code:

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?


	Logged

Support my hactivities.
http://www.cafepress.com/TRUEHacker

SephStorm

Hero Member

Offline

Posts: 530

Re: Nexpose issue

« Reply #1 on: January 12, 2012, 11:01:07 PM »

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.)


	Logged

Support my hactivities.
http://www.cafepress.com/TRUEHacker

ajohnson

Recruiters
Hero Member

Offline

Posts: 1060

aka dynamik

Re: Nexpose issue

« Reply #2 on: January 12, 2012, 11:41:24 PM »

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.


	Logged

WIP: GCFA | www.infosiege.net | @infosiege

The day you stop learning is the day you start becoming obsolete.

cd1zz

Recruiters
Hero Member

Offline

Posts: 561

Re: Nexpose issue

« Reply #3 on: January 13, 2012, 08:30:41 AM »

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.


	Logged

OSCE | OSCP | GXPN | OSWP | CISSP
http://www.pwnag3.com
http://www.networkadminsecrets.com

SephStorm

Hero Member

Offline

Posts: 530

Re: Nexpose issue

« Reply #4 on: January 13, 2012, 10:54:53 AM »

Quote from: dynamik on January 12, 2012, 11:41:24 PM

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?


	Logged

Support my hactivities.
http://www.cafepress.com/TRUEHacker

cd1zz

Recruiters
Hero Member

Offline

Posts: 561

Re: Nexpose issue

« Reply #5 on: January 13, 2012, 10:56:48 AM »

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


	Logged

OSCE | OSCP | GXPN | OSWP | CISSP
http://www.pwnag3.com
http://www.networkadminsecrets.com

l33t5h@rk

Jr. Member

Offline

Posts: 79

Re: Nexpose issue

« Reply #6 on: January 13, 2012, 12:19:53 PM »

Quote from: SephStorm on January 13, 2012, 10:54:53 AM

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!


	Logged

SephStorm

Hero Member

Offline

Posts: 530

Re: Nexpose issue

« Reply #7 on: January 14, 2012, 12:43:55 PM »

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.


	Logged

Support my hactivities.
http://www.cafepress.com/TRUEHacker

Pages: [1] Go Up

« previous next »