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

Turbo Intruder Attacks Queue But Never Launch #49

Open
maxicorbs opened this issue Dec 16, 2021 · 7 comments
Open

Turbo Intruder Attacks Queue But Never Launch #49

maxicorbs opened this issue Dec 16, 2021 · 7 comments

Comments

@maxicorbs
Copy link

Not sure if something has changed recently with the script that the plugin inserts into turbo intruder but when I click 'Launch CL.TE/TE.CL attack' I can see the engine starting and the requests queueing but no requests are actually made. Have tried this on multiple lab instances, on 2 different machines with 2 different versions of Burp and consistently get this bug. Have watched plenty of YT videos in which they follow the exact same steps and the requests launch no problem. Screenshots of script and queue attached.

Extension output says:

"The engine has already started - you no longer need to invoke engine.start() manually. If you prefer to invoke engine.start() manually, set autoStart=False in the constructor
Cancelled attack
Attack aborted with items waiting to be queued."

No requests in Logger++
turbo1
turbo2

@albinowax
Copy link
Collaborator

Can you confirm which version of HTTP Request Smuggler you're using? Did you install it from the bapp store?

@maxicorbs
Copy link
Author

Version v2.01

Got it from the bapp store yep.

Seem to have found a simple workaround by looking through archive.org for what changed in the python script. Reverting the 'engine=Engine.BURP' to 'engine=Engine.THREADED' seems to have fixed for me, but unsure if there will be other repercussions to changing this value?

Also, just want to say a big thanks for your research, papers, tools and maintenance of all things HRS James! You've got me set on finding my first triaged HRS bug

@maxicorbs
Copy link
Author

Not sure if this is a direct result of the amdended workaround above, but currently all TECL attacks are being generated with a Content-Length that is 1 too many, i.e Content-Length should be 12 but it is 13. I have got round this by changing
attack = attack.replace('Content-Length: '+content_length, 'Content-length: '+str(int(content_length)+len(chunk_size)-3))
to
attack = attack.replace('Content-Length: '+content_length, 'Content-length: '+str(int(content_length)+len(chunk_size)-4))

Could this be some nuance to the BURP/THREADED workaround?

@albinowax
Copy link
Collaborator

Maybe you've got a non-printable character in the request that's breaking the engine and messing up the content-length.

@maxicorbs
Copy link
Author

Hmm, can't see anything but that is an easy fix. Are you able to confirm if others are also having the issue with turbo intruder queueing and needing to change the THREADED? If it is just me for whatever reason then i'll close this for you

@albinowax
Copy link
Collaborator

Which lab were you having this issue on?

@maxicorbs
Copy link
Author

I am still having this issue on multiple instances of the burp plugin, not on any lab in particular. No matter the attack im trying, I can only launch the turbo intruder by changing BURP to THREADED, but by looking at other peoples video demonstrations this appears to fix the issue but cause some performance issues as it runs slower

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