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

Question only: docker-splitted enviroments attackable? #29

Open
hersche opened this issue Nov 5, 2019 · 2 comments
Open

Question only: docker-splitted enviroments attackable? #29

hersche opened this issue Nov 5, 2019 · 2 comments

Comments

@hersche
Copy link

hersche commented Nov 5, 2019

Just a technical question, our servers are updated :)
We use a splitted enviroment where nginx runs in one container, php-fpm in another. I tried to reproduce the issue with your exploit, but it seems to hang at

2019/11/05 21:30:58 The target is probably vulnerable. Possible QSLs: [1735 1740 1745]

while the project runs localy (8mins now). As i inspect your docker-file, you seem to have your enviroment combined in the same container. If the split we did protected us from the attack anyway, this would be a nice side-info :)

Also, if this is really the case, it would be may a idea to add it to the requirements?

Thanks for developing this poc!

@neex
Copy link
Owner

neex commented Nov 5, 2019

No, splitting nginx and php-fpm in different containers doesn't protect you in any way.

It is strange that QSLs are found even though you have updated your servers. I suggest you to double check that.

@hersche
Copy link
Author

hersche commented Nov 5, 2019

It is strange that QSLs are found even though you have updated your servers. I suggest you to double check that.

i am sorry as i was unclear. i retest the attack by downgrading the docker-images to our previous versions and run them only local.
as i tested it on our productive servers, it was not able to do any part of the attack.

No, splitting nginx and php-fpm in different containers doesn't protect you in any way.

ok, interessting then, it still hangs there. i guess your exploit would be able to handle that "remote-connection" (to the other container).

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

No branches or pull requests

2 participants