Basic Auth no longer works (for --http-auth, --headers and --basic-auth)

burninatorsec commented 2 years ago

Before submitting an issue, please make sure you fully read any potential error messages output and did some research on your own.

Subject of the issue

I don't have a way to scan a WordPress site that uses basic auth. The --basic-auth option has disappeared. --headers does not recognize the authentication header, and --http-auth gives an "invalid" error for the username:pw format (and a different error about not using base64 if I base64 encode it). Anything else I can try?

Your environment

Version of WPScan: 3.8.20
Version of Ruby: 2.5.1p57
Operating System (OS): Ubuntu

Steps to reproduce

Try using any of the 3 parameters described above to authenticate to a Wordpress site that uses Basic Auth.

Expected behavior

The scanner should successfully authenticate and proceed with scanning a site that uses basic auth.

Actual behavior

WPScan throws an error about authentication.

What have you already tried

Tell us what you have already tried to do to fix the issue you are having.

Things you have tried (where relevant): --basic-auth (doesn't exist anymore) --http-auth --headers 'Authorization: Basic *base64valueehre&'

Update WPScan to the latest version [ x]
I noticed that WPScan continue to prompt for updates although I have updated it several times.
Update Ruby to the latest version [x ]
Ensure you can reach the target site using cURL [x ]
Proxied WPScan through a HTTP proxy to view the raw traffic [ ]
working on this one, will provide updates
Ensure you are using a supported Operating System (Linux and macOS) [x ]

burninatorsec commented 2 years ago

Mystery solved! Apparently the credentials are too long, so WPScan cuts off the last few characters of the credentials. Which is why it says login invalid. Any chance of getting the string that stores the credentials lengthened as a bug fix?

burninatorsec commented 2 years ago

For anyone looking for a quick workaround in the mean time, here's what I did: proxy through Burp and do a match/replace rule on the base64 value in the Authorization header and replace it with the right base64 value :D

erwanlr commented 2 years ago

Hummm that's a weird one.

How long were the credentials ?
Are there any $ characters towards the end, such was xxxxxxxx$something ? (in such case, $something is getting interpreted by the terminal and needs to be escaped if I recall correctly)

burninatorsec commented 2 years ago

Hummm that's a weird one.

* How long were the credentials ?

* Are there any $ characters towards the end, such was `xxxxxxxx$something` ? (in such case, `$something` is getting interpreted by the terminal and needs to be escaped if I recall correctly)

There sure was! There was a $ near the end of the password. I had assumed it was the length because the username was about 18 characters with a 8 character password, but your explanation makes a lot more sense.

erwanlr commented 2 years ago

Great, thanks for confirming, I will keep the issue open to add a message about that in the help of the option.

To have it properly handled by the terminal, either surround the option with ' or escape the $ with \:

% echo hellloooo$aaa
hellloooo

% echo 'hellloooo$aaa'
hellloooo$aaa

 % echo "hellloooo$aaa"
hellloooo

% echo hellloooo\$aaa 
hellloooo$aaa

I am surprised that --headers 'Authorization: Basic base64valueehre&*' did not work though

burninatorsec commented 2 years ago

Great, thanks for confirming, I will keep the issue open to add a message about that in the help of the option.

To have it properly handled by the terminal, either surround the option with ' or escape the $ with \:
% echo hellloooo$aaa
hellloooo

% echo 'hellloooo$aaa'
hellloooo$aaa

 % echo "hellloooo$aaa"
hellloooo

% echo hellloooo\$aaa 
hellloooo$aaa
very cool, thanks for your help!

I am surprised that --headers 'Authorization: Basic base64valueehre&*' did not work though

same, I also tried throwing in some other cookies, but I wasn't 100% sure if it was right to separate headers with \n, but it definitely didn't like [space].

erwanlr commented 2 years ago

Ah nop, the separator for headers is ;, so I guess here the \n was put in the basic auth hence why it failed:

--headers HEADERS     Additional headers to append in requests
                      Separator to use between the headers: '; '
                      Examples: 'X-Forwarded-For: 127.0.0.1', 'X-Forwarded-For: 127.0.0.1; Another: aaa'

For cookies, you can use --cookie-string or --cookie-jar btw:

--cookie-string COOKIE   Cookie string to use in requests, format: cookie1=value1[; cookie2=value2]
--cookie-jar FILE-PATH   File to read and write cookies

burninatorsec commented 2 years ago

aha, thank you again!

miguelxpn commented 10 months ago

https://github.com/wpscanteam/CMSScanner/pull/248 adds to the docs that the $ character should be properly escaped

wpscanteam / wpscan