Http Dlinkrouter.local Info Login.html

[Shinyoung Gedris]

Thereare two application servers and a switch. When i access application by using application server ip it works fine. However if i use switch ip in my url Bad request error throws up only for firefox and chrome for a few links only.

For server side:Increase the value for the directive LimitRequestFieldSize in the httpd.conf:LimitRequestFieldSize 12288 or 16384For How to set the LimitRequestFieldSize, check Increase the value of LimitRequestFieldSize in Apache

I was testing my application with special characters & was observing the same error. After some research, turns out the % symbol was the cause. I had to modify it to the encoded representation %25. Its all fine now, thanks to the below post

I got Bad Request, Your browser sent a request that this server could not understandwhen I tried to download a file to the target machine using curl.

I solved it by instead using scp to copy the file from the source machine to thetarget machine.

when I use curl to post a request, I see this error.The root cause is -H 'Content-Type: application/x-www-form-urlencoded', but body is empty. When I add -d '', the response is success.

I'm stuck up with this for a long time now. I've just started out on learning various basic techniques used for navigating around various security mechanisms. I referred a number of posts around the web about brute forcing routers with Hydra. Most of the articles are focused on beating the basic authentication provided by HTTP. And the links that describe brute forcing web logins do not seem to work when I've tried. My router is a DLINK DSL2750U ADSL Router left aside for testing purposes. Even most of other routers I tried consists of such web interface which is first loaded and a custom authentication web form using HTTP POST. I used this link as my main reference in understanding the process of bruteforcing.

This gives the hydra output as matching ALL passwords as correct in the dictionary. So I figure my incorrect/fail section for hydra is not right. Since my routers failed login does not give out any proper information, I tried looking at the "S=" option for the incorrect/fail section of hydra. I noticed that on successfully logging in I'm being redirected to link given below:

-bin/webproc?getpage=html/index.html&errorpage=html/main.html&var:language=en_us&var:menu=setup&var:page=wizard

hydra -l "" -P "/root/pass.txt" 192.168.1.1 http-post-form "/cgi-bin/webproc:%3Ausername=^USER^&%3Apassword=^PASS^&%3Aa ction=Login:S=?getpage=html/index.html&errorpage=html/main.html&var:language=en_us&var:menu=setup&varage=wizard:H=Cookie: %3Asessionid=68b3e673"

I've been trying many ways to get this done but am stuck up. Any help pointing towards the right direction would be helpful. If there's any more information you would want to know to help me out, please let me know. Looking to solving this somehow!! :(:(

hydra -l "" -P "/root/pass.txt" 192.168.1.1 http-post-form "/cgi-bin/webproc:%3Ausername=^USER^&%3Apassword=^PASS^&%3Aaction=Login:S=?getpage=html/index.html&errorpage=html/main.html&var\:language=en_us&var\:menu=setup&varage=wizard:H=Cookie: %3Asessionid=68b3e673"

I checked out the intruder lab. Looks more complex than the command line. Makes a lot of sense what you say about writing a custom bruteforcer but would really like to try my hands with these tools to get a larger understanding of the process I guess. I'll look more into intruder lab and its options. Do let me know if you can help out with finding the write command arguments for hydra. Everyone brags about its flexibility everywhere!

now submit your login from the browser, both screens should now show your Post request in one console and your server response in the next consol... press ctrl-c to stop the stream's and paste this information in 2 separate text editor...

You may already have this information. But now you have 2 consoles that you can use to quickly see a separate live stream ... keep at it, first you have to focus on getting hydra to produce a proper post request and see a identical server response...

Okay I'll start think on those lines. This is a cleaner output than intercept from burp-suit actually. If you do get the time, here are the files I've recorded for post request and server response for a single failed login attempt through the web browser :

I need to get a better understanding of the structures of post requests to get this going. I'll be on that now. If you could do look through these files and any guidance would be really great. Thank you...

Thank you so much for the help. You got me going in the right direction there. So I've been able to create the right post request and get the right responses. hydra works in a way. Why I say that is because when i individually try passwords out everything goes fine. ie. hydra -p "admin" or hydra -p "admin123". But when i use hydra -P to point to a file and make it work, hydra iterates through each of the password list but fails to make a match. So I figured it could be because the router is unable to handle the requests from multiple threads for some reason (beacuase its working with hydra -p "password"). So I used hydra -t 1 flag along with the command so as to keep the parallel threads to 1. Yet I'm unable to recursively read and bruteforce through a password list given to hydra. Or may be the router is locking me out after consecutive attempts ? I'm not sure. May be I should go through the packets again and see if there are any responses that are missing. or if nothing works I guess a bash script that sleeps and invokes hydra would help out. It'll be slow though I'll let you know. But have you heard of any bugs within hydra similar to this ?

Below is a video of a custom brute force I built to crack cpanel... from lfi to brute force... some firewall functions I experience... I instlled a cpanel OS in vm, I expect most admins will rely on the default firewall settings/functions of the installed software...

So, this basic firewall function will detect a username fails X times in a row and too quickly... so the service continues to respond with the same 401 header a total of 10 times in a row... the attacker will think its password list was missing the correct creds witch I thought was clever!

Router gateways are responsible for protecting every aspect of a network's configuration. With unfettered access to these privileged configurations, an attacker on a compromised Wi-Fi network can perform a wide variety of advanced attacks.

After hacking a Wi-Fi router with tools like Aircrack, Wifiphisher, and Wifite2, there are several avenues an attacker may explore to further compromise the network. Assuming the gateway isn't using default credentials, the attacker will try to exploit a vulnerability in the router or perform a brute-force attack.

With access to the router's gateway and complete control over the configurations, a hacker in this position of power can perform a variety of attacks. They could do any of the following, and then some.

Patator, like Hydra and Medusa, is a command-line brute-forcing tool. The developers have tried to make it more reliable and flexible than its predecessors. My favorite feature of Patator is the raw_request module that allows penetration testers to brute-force HTTP logins much like Burp's Intruder module.

To demonstrate, I'm going to show how to use Patator against two popular consumer routers found on Amazon. Not all router gateways handle authentication the same. I'll show a kind of general procedure to follow when performing such attacks.

Now, a word of caution: Patator isn't very beginner-friendly, so there's a bit of a learning curve with the syntax that can take some getting used to. Before proceeding, you should have a general understanding of HTTP requests, HTTP status codes, and some experience with Burp's Intruder module.

As stated, we'll focus on the http_fuzz module, designed to brute-force HTTP logins as well as perform various types of web-based injection attacks (e.g., fuzzing). View the available http_fuzz options using the following command.

Those familiar with password hashing may recognize the hash as the MD5 for "password." It can be verified using the below command which prints the desired string into the md5sum command.

That tells us that the wordlist used when brute-forcing the gateway must be in MD5 format. With this particular router, at the gateway, there's no available field for username input. We can see from the captured data that the "admin" username is embedded into the request. So there's only one dynamic parameter: the password.

Change the hashed password parameter to "FILE0" within the request. The modification will act as a placeholder in the request that indicates to Patator where to insert the passwords. (The reason for this will be clear in a later step.)

As we discovered previously, passwords are hashed in the browser before being sent to the router. Patator has a built-in feature to hash passwords, but let's take this opportunity to learn some Bash password manipulation tricks.

First, download a preferred wordlist. Any generic wordlist will do fine for testing purposes. Use the below wget command to download my wordlist generated by analyzing leaked databases.

The below Bash one-liner will use a while loop to iterate through the passwords in the wordlist. Each password will be converted into an MD5 and appended to the md5_wordlist.txt file.

3a8082e126