Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thread failed to connect #124

Open
raff-s opened this issue Feb 18, 2023 · 5 comments
Open

Thread failed to connect #124

raff-s opened this issue Feb 18, 2023 · 5 comments

Comments

@raff-s
Copy link

raff-s commented Feb 18, 2023

Thanks for this amazing tool, I was able to run it on my old machine but on this one I'm seeing the following error

java.net.ConnectException: Connection refused
	at java.base/sun.nio.ch.Net.connect0(Native Method)
	at java.base/sun.nio.ch.Net.connect(Net.java:579)
	at java.base/sun.nio.ch.Net.connect(Net.java:568)
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588)
	at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
	at java.base/java.net.Socket.connect(Socket.java:633)
	at java.base/sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:304)
	at java.base/sun.security.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:184)
	at java.base/sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:137)
	at burp.ThreadedRequestEngine.sendRequests(ThreadedRequestEngine.kt:141)
	at burp.ThreadedRequestEngine.access$sendRequests(ThreadedRequestEngine.kt:17)
	at burp.ThreadedRequestEngine$1.invoke(ThreadedRequestEngine.kt:50)
	at burp.ThreadedRequestEngine$1.invoke(ThreadedRequestEngine.kt:49)
	at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)

This happens on portswigger labs or even google.com or example.com
I tried the debug.py script when I change concurrentConnections from 1 to 5 it starts failing after a couple of requests.
Changing Engine.THREADED to Engine.BURP fixes the problem.
Using the regular intruder with a pool of 30 also works fine, so I think it's something specific to TurboIntruder.
Any help would be great, thanks

Config
MacBook Air (M1, 2020)

~ java -version
openjdk version "17.0.4" 2022-07-19
OpenJDK Runtime Environment Homebrew (build 17.0.4+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.4+0, mixed mode, sharing)

➜  ~ sw_vers
ProductName:	macOS
ProductVersion:	12.3
BuildVersion:	21E230
@albinowax
Copy link
Contributor

That's really strange, I'm not sure what would cause that, looks like something unusual about your environment. Is your traffic going through any proxies or fancy firewalls that might be doing traffic shaping or suchlike?

Also, assuming you're currently running Burp via the jar, can you try using the installer version? This will put you on the same JRE as most users.

@albinowax albinowax reopened this Feb 21, 2023
@raff-s
Copy link
Author

raff-s commented Feb 22, 2023

I also thought that maybe was an issue with my VPN but turning it off didn't change anything
Originally I tried the installer version and then tried the JAR the outcome is the same.
Another thing I noticed is that the RPS is always 1 or 2 independently of the value of concurrentConnections

@albinowax
Copy link
Contributor

That's a crazy low RPS. Are you seeing that regardless of the target domain? Maybe you've got an anti-virus that's doing some horrific local MITM stuff?

@raff-s
Copy link
Author

raff-s commented Feb 23, 2023

Yes the RPS are always at 1 or 2.
I ran kill -9 -1 to kill all running processes and only open burp and it's the same.
I thought maybe was something to do with the wifi extender so I connected directly to the router and still no change
Running on an old windows PC it works great
I tried to run other tools that do concurrent connections like fuff and they work fine so maybe it's something to do with java in this OS, but I don't know enough about java to try to debug this

@albinowax
Copy link
Contributor

I don't think that kill strategy would fix AV/endpoint-protection/malware issues, since they'll all be running as other users / root. I wouldn't be inclined to blame Java if you can see the issue on different JREs. It might be related to the flags I set on the socket but that feels unlikely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants