update owa plugin to use forms auth

[techspence]

TLDR: This PR seeks to resolve the issue OWA/EWS Plugins Authentication Failed with Valid Credentials by changing the owa plugin to use forms auth instead of NTLM against the auto-discover endpoint.

Note: There are a couple of opsec drawbacks with this, but for the purposes of testing a client environment, I'm personally ok with those drawbacks.

Summary of changes:

• Add a list of possible owa endpoints to search through
• Implement 2 new functions in the init module, check_url and check_path
  • check_path uses check_url to check each of the owa endpoints to see which one is in use
  • one drawback of this is it's not very opsec safe since it's sending a get request from the operator's host to the endpoint
• The pluginargs URL is also used to get the internal domain name, again not very opsec safe but it works
• Successful authentication (valid credentials) are found when there response code is 302 and 4 or more cookies are set

Strange behavior:

• I had trouble getting the x-amzn-remapped-www-authenticate header to work with the OWA plugin so I fall back to using WWW-Authenticate. I'm not sure of the implications of this
• For some reason the "Content-Type": "text/xml" header causes the request to fail with 400 errors, so I exclude it

I've tested this a bit in my lab, but I would very much welcome others testing this to see if I've introduced any bugs/issues/incompatibilities/etc. If there's anything that requires fixing I'm happy to work on it.

I hope this PR can help the project even just a tiny bit. Cheers!

[knavesec]

Apologies for the 6mo wait

I like and appreciate the work you did for this, but the goal of this tool is to remain as opsec-conscious as possible. If you're able to find ways to abuse these services through fireprox I'd be happy to merge but I can't knowing there would be leaks. I do agree, we're testing verified client environments, but leaking any infrastructure is a dealbreaker

[techspence]

I definitely understand the opsec requirements. I appreciate you reviewing the PR. If I can find a way to do this while meeting your requirements I will send another PR.

[knavesec]

From what I'm seeing, there are 3 places where there is a leak:

• On the initial connection for the three URIs to determine version, IMO this can be done through the API
• On the testconnect to get the Domain associated, unsure why this is failing, it's worked in the past which is curious
• On each password tested

Idk, it doesn't seem like it uses the fireprox apis at all unless I'm mistaken, at that point you could just use the Metasploit module or something that's better tried and tested