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

Fixes to mediawiki exploits in order to support TLS #9390

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@norwat

norwat commented Jan 9, 2018

It fixes a minor issue with the mediawiki exploits, that do not work when the server has SSL enabled

@busterb

This comment has been minimized.

Show comment
Hide comment
@busterb

busterb Jan 9, 2018

Contributor

that's probably the more common case no? do we need to change the default port too?

Contributor

busterb commented Jan 9, 2018

that's probably the more common case no? do we need to change the default port too?

@wvu-r7

This comment has been minimized.

Show comment
Hide comment
@wvu-r7

wvu-r7 Jan 10, 2018

Contributor

Yeah, you need to do Opt::RPORT(443). We had talked about figuring out some magic to set one with the other, but I think we decided to leave it up to module authors in case it wasn't on 443. Feels like it's common enough to try, though.

Contributor

wvu-r7 commented Jan 10, 2018

Yeah, you need to do Opt::RPORT(443). We had talked about figuring out some magic to set one with the other, but I think we decided to leave it up to module authors in case it wasn't on 443. Feels like it's common enough to try, though.

@wvu-r7

This comment has been minimized.

Show comment
Hide comment
@wvu-r7

wvu-r7 Jan 10, 2018

Contributor

That said, cleartext 80 has been the default for quite some time now. MediaWiki can totally be run in cleartext, and many people do that for their own setups. Is this a new mandated configuration or something you saw on a pentest, @norwat?

Contributor

wvu-r7 commented Jan 10, 2018

That said, cleartext 80 has been the default for quite some time now. MediaWiki can totally be run in cleartext, and many people do that for their own setups. Is this a new mandated configuration or something you saw on a pentest, @norwat?

@norwat

This comment has been minimized.

Show comment
Hide comment
@norwat

norwat Jan 10, 2018

sorry for the late reply

That said, cleartext 80 has been the default for quite some time now. MediaWiki can totally be run in cleartext, and many people do that for their own setups. Is this a new mandated configuration or something you saw on a pentest, @norwat?

yeah i had to test a vulnerable mediawiki instance and even after changing the default port i would still have issues connecting to the webserver, thats the reason for this fix.
I also think changing the default port to 443 would be a good idea, if you want you can cancel this pull request and ill make a new one with that fix aswell.

norwat commented Jan 10, 2018

sorry for the late reply

That said, cleartext 80 has been the default for quite some time now. MediaWiki can totally be run in cleartext, and many people do that for their own setups. Is this a new mandated configuration or something you saw on a pentest, @norwat?

yeah i had to test a vulnerable mediawiki instance and even after changing the default port i would still have issues connecting to the webserver, thats the reason for this fix.
I also think changing the default port to 443 would be a good idea, if you want you can cancel this pull request and ill make a new one with that fix aswell.

Joao Santos
@bcoles

This comment has been minimized.

Show comment
Hide comment
@bcoles

bcoles Jan 10, 2018

Contributor

The module options should match the application's default configuration. I believe MediaWiki does not use HTTPS by default as its not a standalone application; rather it relies upon installation within the web root directory of an existing web server.

Contributor

bcoles commented Jan 10, 2018

The module options should match the application's default configuration. I believe MediaWiki does not use HTTPS by default as its not a standalone application; rather it relies upon installation within the web root directory of an existing web server.

@wvu-r7

This comment has been minimized.

Show comment
Hide comment
@wvu-r7

wvu-r7 Jan 10, 2018

Contributor

What @bcoles said. Thusly, did you try set RPORT 443 and then set SSL true? Changing the default for all the MediaWiki modules doesn't really seem wise. I've seen MediaWiki on plain HTTP often enough.

Contributor

wvu-r7 commented Jan 10, 2018

What @bcoles said. Thusly, did you try set RPORT 443 and then set SSL true? Changing the default for all the MediaWiki modules doesn't really seem wise. I've seen MediaWiki on plain HTTP often enough.

@norwat

This comment has been minimized.

Show comment
Hide comment
@norwat

norwat Jan 10, 2018

What @bcoles said. Thusly, did you try set RPORT 443 and then set SSL true? Changing the default for all the MediaWiki modules doesn't really seem wise. I've seen MediaWiki on plain HTTP often enough.

I did, the module was still requesting the HTTP version and breaking when the webserver redirected the request

norwat commented Jan 10, 2018

What @bcoles said. Thusly, did you try set RPORT 443 and then set SSL true? Changing the default for all the MediaWiki modules doesn't really seem wise. I've seen MediaWiki on plain HTTP often enough.

I did, the module was still requesting the HTTP version and breaking when the webserver redirected the request

@wvu-r7

This comment has been minimized.

Show comment
Hide comment
@wvu-r7

wvu-r7 Jan 10, 2018

Contributor

Ahh, it redirected the request. How did it do that? 3xx redirect? Try send_request_cgi! as a fix. We might want a global option for this like most HTTP clients.

Contributor

wvu-r7 commented Jan 10, 2018

Ahh, it redirected the request. How did it do that? 3xx redirect? Try send_request_cgi! as a fix. We might want a global option for this like most HTTP clients.

@norwat

This comment has been minimized.

Show comment
Hide comment
@norwat

norwat Jan 10, 2018

i cant test it now, the assessment already ended but i think i used send_request_cgi! aswell not sure. But when the request hit the HTTP version of the site it did return a 302

norwat commented Jan 10, 2018

i cant test it now, the assessment already ended but i think i used send_request_cgi! aswell not sure. But when the request hit the HTTP version of the site it did return a 302

@wvu-r7

This comment has been minimized.

Show comment
Hide comment
@wvu-r7

wvu-r7 Jan 10, 2018

Contributor

Also, I think your branch is a little broken. You're adding your own rdp_login.

As per CONTRIBUTING.md, we prefer topic branches for this reason. Creating a PR from master tends to mess things up when you have more than one thing in flight.

Might want to close this and create a new PR. Or you can fix your master.

Contributor

wvu-r7 commented Jan 10, 2018

Also, I think your branch is a little broken. You're adding your own rdp_login.

As per CONTRIBUTING.md, we prefer topic branches for this reason. Creating a PR from master tends to mess things up when you have more than one thing in flight.

Might want to close this and create a new PR. Or you can fix your master.

@norwat norwat closed this Jan 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment