← Back to context

Comment by rtuin

20 hours ago

Did you successfully run a RCE test, or only a vulnerability check? So far all write-ups and PoC's i've found fail to "cash in" on the RCE part.

3 comments

rtuin

Reply
system2  19 hours ago

I was able to bring it to the point of memory corruption. It is 3 am where I am now; I will continue in the morning. As a precaution, I configured .htaccess rule.

  # BEGIN php2shell-mitigation
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP:Content-Type} multipart [NC]
  RewriteRule .* - [F,L]
  </IfModule>
  <If "%{HTTP:Content-Type} =~ /multipart/i">
  Require all denied
  </If>
  # END php2shell-mitigation

I added a rewritecond to ignore multipart before php-fpm receives anything. I did a similar thing for nginx servers. Also in .user.ini added "session.upload_progress.enabled = Off".

These two seem to do the trick, but again I am not 1000% sure until tomorrow morning's deeper dive. My eyes are burning, and I can't sleep because of the stress this exploit.

  • Macuyiko  19 hours ago

    I've done the same in caddy:

    @multipart header_regexp Content-Type (?i)multipart respond @multipart 403

    @uploads_php path_regexp uploads_php ^/(?:./)?wp-content/uploads/.\.php(?:/.*)?respond @uploads_php 404

    Plus the php.ini changes, "session.upload_progress.enabled = Off" and strict mode. Let's hope it holds until then

    • bombcar  18 hours ago 

          @multipart header_regexp Content-Type (?i)multipart
    respond @multipart 403

    @uploads_php path_regexp uploads_php ^/(?:.*/)?wp-content/uploads/.*\.php(?:/.*)?
    respond @uploads_php 404