update on this?
Even Iām facing similar issue in port 135 did anyone received any solution or workaround from Support team?
Same issue with us, Telnet is successful on port 135 but credentials are failing, with message ājava.util.concurrent.ExecutionException: com.hierynomus.smbj.common.SMBRuntimeException: com.hierynomus.protocol.transport.TransportException: java.io.EOFException: EOF while reading packetā
Support suggested to troubleshoot the same with the network team.
Same issue here, we are currently working with support, but the replies are to slow and donāt provide any value.
Weāve created a Server specifically to test this issue, we created a FW rule exclusive for Nexpose Engine and Console, Tested the connections with Telnet and the port availability with Nmap, our install is on prem in Ubuntu, Iāve tested the connections with some python scripts too.
It seems that the issue is only happening within Nexpose, we get the Same EOF error when testing credentials and when running a scan in the logs we see the following error too:
wmi-service-admin-session: java.net.ConnectException: Connection timed out
Hope we get a solution fast.
Regards
The fix is to create new user accounts. Donāt have same username across multiple domains used for scanning. Use a different username for every domain. That works!
In my case Iām working with one single domain, and approximately 200 assets.
this happens even when I run a scan of a site that has only 30 assets in it.
So that fix unfortunately wonāt apply to me.
If you scan each asset individually do you get credentials success?
Iāll give it a try tonight an provide some feedback during the weekend or on Monday.
Regards
1 Like
Hi,
I have noticed that this seems to be a commonly viewed thread and wanted to offer some insight into the error message from my experience:
TransportException: java.io.EOFException: EOF while reading packet
This tends to occur when there is a network or security device in between the scan engine and the target asset. This can be some sort of network firewall, router, traffic analysis tool or other device or even security software on the endpoint you are targeting such as anti-virus or security configs designed to reject connections.
Some things to try would be to first check the devices that are between the scan engine and the target machine. You can do this by connecting to the scan engine and running a trace route from the scan engine to the target machine. This should provide you a list of the devices which the traffic is being routed through. It is worth quickly checking with your network team if any of those devices would likely alter or modify traffic (If any of them are a firewall or traffic analysis tool this is often the culprit. As it is very difficult to analyse every rule on these tools setting up a connection directly from the scan engine to the asset without going through these devices can be an easy way to rule this out).
The next thing to check would be the security settings on the target machine in question. You can confirm these configurations by connecting to the machine using the protocols in question (e.g. directly ssh to the machine, or connect to the relevant service). You should also check you can connect using the scan engine to confirm that there isnāt any allow/block lists in place that would only affect the scan engine.
If you have confirmed that the scan engine can connect to the end machine without any interfering devices in between and you have been able to connect using the standard connection from the scan engine to your target machine however the scan still fails then this could be an issue with the commands/environment available to the session.
Different protocols may authenticate differently but some may try to elevate using sudo or other such means (e.g. cisco elevation etc). The session that the scan engine will create will not load many of the default profiles (for security reasons) and so if you grant permissions or access to commands through those profiles or configurations these will not be available to the scan engine and would explain the failure while you are manually able to access the system. The situation I am describing most commonly presents as fingerprinting issues or policy scanning issues however if the restrictions on the connections are strict enough it may prevent a full authentication to the service in question. It is worth noting that because the connection tester is designed to test if you can connect to the machine not that you have permission to run all the commands required by the scan (this would take too long to test).
If you are still unable to identify the root cause of this sort of issue it can be very helpful to detail all the steps you have tested so far and open a support ticket. The more information provided the better as support will have access to view across many previous issues and may be able to find a known issue or solution that lines up.
1 Like
Hi team,
Is this case resolved? Or have a solution from TAC Support?
I have the same problem. I can not scan via wmi 135 (pop-up error java.util.concurrent.ExecutionException: ā¦) and 445 (test credential success).
Before, All the server scan port 135 and 445 was working
This probably wonāt solve some of the more complex issues, but some of you might want to just try removing the domain prefix from the domain prefix field where you save the credentials. That allowed some authentications on devices that were previously failingā¦
Hey, were you able to fix the issue with the policy scanning? Iām getting the same credentials failing on port 135 for the CIS policy scanning.
Just throwing this out there for those that are still struggling. We had a similar cred failure on port 135 related to DCE Endpoint Resolution (RPC) causing ~80% fingerprints. When we enabled RPC on the box the creds were successfully authenticated, fixing our issue and giving us a 100% fingerprint. Hope this helps anyone else out there with this headache!
Although the most recent post on this was from Junā 22 this post still happens to be our most viewed post in the discussion forums so I think itās good to note that there are better ways to authenticate other than using the Domain Credentials.
The InsightVM Scan Assistant can be used in place of the CIFS credentials which eliminates the headache of permission issues for the user accounts and the services themselves. The Scan Assistant can be found here and is available for both Windows and Linux. The Scan Assistant uses itās own executable and presents a certificate that you create from the console. You deploy the Scan Assistant on all of your endpoints passing the certificate into the install command. The endpoint would then display that certificate on port 21047. The scan templates would then need to be updated to look for TCP 21047 in both Asset and Service discovery.
With this method, you can use a single certificate to authenticate to all of your Windows and Linux devices (although there are different installers for the two) among however many domains you need. The scan assistant has access to the registry service, command execution service, and the file system service which gives it all the ability it needs to run the vulnerability test and nothing else. This method provides less overhead for password management etc and is actually more efficient when scanning.
TLDR; donāt fight with windows permissions/issues and use the Scan Assistant
As far as I know, port 445 does vulnerability scanning and port 135 is used for policy scans. Say for instance if you wanted to scan for CIS policies, they will show a difference if scanning succeeds over 445 but fails to scan port 135.
check whether the 135 port is listening or not on affected machine.
Open CMD and run ānetstat -aonā and check.
Rapid7 support will definitely help you figure it out.