Tib3rius
A line was longer than 64 KiB and cannot be processed. Ignoring.
Hi, I'm running AutoRecon with ffuf. My config.toml contains:
# Configure plugin options here.
[dirbuster]
tool = 'ffuf'
threads = 50
wordlist = ['/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt']
ext = ""
My dirbuster output has many lines of: [!] [192.168.243.245/tcp/80/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring. [!] [192.168.243.245/tcp/443/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring. [!] [192.168.243.245/tcp/8000/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring.
But I cannot see any entries about this in _errors.log or any of the other outputs.
What does it mean?
Can any of you give me a HTB / THM / etc. machine this reliably occurs on? This will require some specific testing I believe.
Can any of you give me a HTB / THM / etc. machine this reliably occurs on? This will require some specific testing I believe.
@Tib3rius, I would love to, but unfortunately it's a part of the Challenge Labs in OffSec.
Can any of you give me a HTB / THM / etc. machine this reliably occurs on? This will require some specific testing I believe.
@Tib3rius, I would love to, but unfortunately it's a part of the Challenge Labs in OffSec.
@Tib3rius I ran this against a vuln linux and windows machine in my local lab. Performed flawlessly. I could not replicate the behavior. I wonder if this is a networking issue of some kind. I ran with sudo permissions in Kali native terminal with zsh and terminator with zsh. I can test more later, but for now I need to get back to the Challenge Labs. :)
I'll let you know if I see this again in the labs.
It's pumping out the error message again. Of course, connected to openvpn and the challenge labs. I'm going to let this run over night and check in the morning.
At this rate I think I might just have to run this against a load of hosts and see if I can replicate it. Or I could turn off this error message. 🫠
At this rate I think I might just have to run this against a load of hosts and see if I can replicate it. Or I could turn off this error message. 🫠
The only difference I've noticed is running locally vs. running over a vpn. I let it run overnight and it's still cycling on /udp/137/netbios-ns/smbmap. Is there a way to let the script progress past and maybe run that portion manually? That would be cool :) Let me know if I can submit something that may aide you in figuring it out.
At this rate I think I might just have to run this against a load of hosts and see if I can replicate it. Or I could turn off this error message. 🫠
The only difference I've noticed is running locally vs. running over a vpn. I let it run overnight and it's still cycling on /udp/137/netbios-ns/smbmap. Is there a way to let the script progress past and maybe run that portion manually? That would be cool :) Let me know if I can submit something that may aide you in figuring it out.
Today it is hung up on port 139 :( Still works locally perfectly. Smbmap has been where I see it hang for me consistently. A mix of nix and windows. Hope this might help so you can narrow the testing scope .
Same issue here. I was scanning the GOAD (game of Active Directory) Lab when getting this error.
next one :)
doing the practice range of cpent
issue is with smbmap-module.
i had a quite similiar experience once where the code was going to the wrong interface maybe thats an issue when using tun0
further information my machine was changed by pimpmykali
I am doing the PEN-200 challenge labs. Relia to be specific. Im seeing a ton of these. Ive only actually received them from the challenege labs. Mine appears to be coming from SMBMAP and not dirbuster.
same here from smbmap on challenge labs, it goes on forever
[] 15:06:23 - There are 2 scans still running against 192.168.221.248: tcp/139/netbios-ssn/smbmap, tcp/445/microsoft-ds/smbmap [] 15:07:23 - There are 2 scans still running against 192.168.221.248: tcp/139/netbios-ssn/smbmap, tcp/445/microsoft-ds/smbmap [!] [192.168.221.248/tcp/139/netbios-ssn/smbmap] A line was longer than 64 KiB and cannot be processed. Ignoring. [!] [192.168.221.248/tcp/445/microsoft-ds/smbmap] A line was longer than 64 KiB and cannot be processed. Ignoring. [] 15:08:23 - There are 2 scans still running against 192.168.221.248: tcp/139/netbios-ssn/smbmap, tcp/445/microsoft-ds/smbmap [] 15:09:23 - There are 2 scans still running against 192.168.221.248: tcp/139/netbios-ssn/smbmap, tcp/445/microsoft-ds/smbmap
If you run the smb map manually you get hung at authenticating. Seems related to passing a user to the command. If you do pass a user it seems to work. Probably something funny with smbmap and newer versions or something.
- This is first command generated from smbmap.py and gets hung after ran.
smbmap -H 10.10.11.202 -P 445 2>&1
When you specify the user it no longer hangs .
smbmap 1.9.2 is the current version in kali, and 1.9.3 and 1.9.3.1 have fixes for hanging with no auth or no shares that seem to be the fix for my problem. Pushing a kali request to update to 1.9.3.1 or higher.
Nice....I will try that out after updating
On Wed, Feb 21, 2024, 2:13 PM Steve Pinkham @.***> wrote:
smbmap 1.9.2 is the current version in kali, and 1.9.3 and 1.9.3.1 have fixes for hanging with no auth or no shares that seem to be the fix for my problem. Pushing a kali request to update to 1.9.3.1 or higher.
— Reply to this email directly, view it on GitHub https://github.com/Tib3rius/AutoRecon/issues/199#issuecomment-1957730567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGSCDXP7W7XXDL4PTQIBBTTYUZBNHAVCNFSM6AAAAAAYASQ3W6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJXG4ZTANJWG4 . You are receiving this because you commented.Message ID: @.***>
Can any of you give me a HTB / THM / etc. machine this reliably occurs on? This will require some specific testing I believe.
@Tib3rius , the problem is reproducible with this THB lab: Blue Same problem even using smbmap==1.10.2
I have the same issue with ffuf like OP.
[!] [10.129.214.99/tcp/80/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring.
[*] 14:03:53 - There is 1 scan still running against 10.129.214.99: tcp/80/http/dirbuster (PIDs: 30343, 30344, 30345)
[!] [10.129.214.99/tcp/80/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring.
[*] 14:04:53 - There is 1 scan still running against 10.129.214.99: tcp/80/http/dirbuster (PIDs: 30343, 30344, 30345)
[!] [10.129.214.99/tcp/80/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring.
[*] 14:05:53 - There is 1 scan still running against 10.129.214.99: tcp/80/http/dirbuster (PIDs: 30343, 30344, 30345)
[*] 14:06:53 - There is 1 scan still running against 10.129.214.99: tcp/80/http/dirbuster (PIDs: 30343, 30344, 30345)
[!] [10.129.214.99/tcp/80/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring.
[*] 14:07:53 - There is 1 scan still running against 10.129.214.99: tcp/80/http/dirbuster (PIDs: 30343, 30344, 30345)
[!] [10.129.214.99/tcp/80/http/dirbuster] A line was longer than 64 KiB and cannot be processed. Ignoring.
[*] 14:08:53 - There is 1 scan still running against 10.129.214.99: tcp/80/http/dirbuster (PIDs: 30343, 30344, 30345)
At this rate I think I might just have to run this against a load of hosts and see if I can replicate it. Or I could turn off this error message. 🫠
The only difference I've noticed is running locally vs. running over a vpn. I let it run overnight and it's still cycling on /udp/137/netbios-ns/smbmap. Is there a way to let the script progress past and maybe run that portion manually? That would be cool :) Let me know if I can submit something that may aide you in figuring it out.
Today it is hung up on port 139 :( Still works locally perfectly. Smbmap has been where I see it hang for me consistently. A mix of nix and windows. Hope this might help so you can narrow the testing scope .
same issue with SMB here
