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

improve exploit for more restrictive location regexp #1

Closed
neex opened this issue Sep 24, 2019 · 6 comments · May be fixed by #2
Closed

improve exploit for more restrictive location regexp #1

neex opened this issue Sep 24, 2019 · 6 comments · May be fixed by #2
Labels
help wanted Extra attention is needed

Comments

@neex
Copy link
Owner

neex commented Sep 24, 2019

Currently, our exploit works only when Nginx config is like this:

location ~ [^/]\.php(/|$) {
   ...
}

I believe that far more popular config snippet is like this:

location ~ \.php$ {
   ...
}

which allows only URLs that end with .php (and not just contain .php/ somewhere).

Given location ~ \.php$, there're two further config options:

  1. It includes something like try_files $uri =404 into the location section. There's nothing we can do in this case as it forbids access to non-existing files (and we need it). However, this requires php-fpm and Nginx to share their FS, and I believe many DevOps consider this not modern enough.
  2. The config doesn't have any further restrictions; it passes to php-fpm all URLs that end on .php. We can win in this case as fastcgi_split_path_info is still probably here (and it doesn't matter which regexp it uses).

However, to improve our exploit for case 2, we need even shorter php.ini options. We have 23 bytes currently and after adding ;.php to every string we have only 18 left. So there's a research field.

@neex neex changed the title improve exploit for more restrctive location regexp improve exploit for more restrictive location regexp Sep 24, 2019
@neex neex added the help wanted Extra attention is needed label Oct 23, 2019
@gl3nc4rt3r
Copy link

gl3nc4rt3r commented Oct 28, 2019

<?=`$_GET['a']`;
might be a payload right?

@kaylined
Copy link

Combined with XSS this could be used to get HTTPOnly cookies, such as PHP Session ID - and 1 character to spare! Can dump $_SESSION and be at 23 chars

@mehov
Copy link

mehov commented Jan 14, 2020

However, this requires php-fpm and Nginx to share their FS, and I believe many DevOps consider this not modern enough

I can't help but ask what's modern enough then? :)

@neex
Copy link
Owner Author

neex commented Jan 16, 2020

I can't help but ask what's modern enough then? :)

I meant that it's simpler to use two different containers, one for nginx and other for php-fpm, and nginx doesn't actually needs to have access to the php files as it only proxies requests to php-fpm.

@neex
Copy link
Owner Author

neex commented Jan 16, 2020

This ticket was opened before we released the PoC in hope we'll discover a way to bypass the limitation before the issue is public. Obviously this is not such an interesting question anymore as the bug is long fixed by now. Closing.

@neex neex closed this as completed Jan 16, 2020
@SD19-90
Copy link

SD19-90 commented Nov 25, 2024

Hi how are you
Can you tell me how to hack a website running on Nginx 1.20.1 server
thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants