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

update owa plugin to use forms auth #42

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

techspence
Copy link

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
Copy link
Owner

knavesec commented Aug 2, 2023

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

Copy link
Owner

@knavesec knavesec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're able, please resubmit with ways to obscure operator infrastructure

@techspence
Copy link
Author

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
Copy link
Owner

knavesec commented Aug 3, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants