29 ms·

How to get shell access with a .htaccess file

77 points by bartman 15y ago

magamiako 15y ago
I was thinking about this the other day when I was messing with .htaccess configuration for WordPress. Unfortunately there's a lot of stuff that relies on .htaccess capability. There's also a lot of stuff that relies on write access to the web directory. Wordpress auto-update and plugin update wants write access to the web directories. The alternative to this is to manually update the wordpress files, which potentially means bringing down the site for a minute while you maintenance it, and having to turn it into far more of a process than simply clicking 'upgrade'. In this case, the barrier to upgrading could backfire and make web servers even more insecure than they are now. WP-Supercache requires write-access to some caching folders in the web dir. A perfect place to dump scripts and run them even if you've locked writes to the rest of the website. This complicates theme and plugin management for Wordpress as well. And this is just one framework out of many that has these problems. The big question is: with all of these dynamic things happening on websites, how do you handle them at the filesystem level? SELinux and AppArmor are great ways to do it--but have massive configuration difficulties and really relies on you understanding quite a bit more about the OS than normal. It's easy to screw yourself if you don't use these tools properly. I propose that we rethink what .htaccess has access to and see if we can work on separating various functions into separate security zones and document that. For example: "AllowOverride Options" is insecure, but what if we allow only subsets of that?
bartman 15y ago
Blog post by the author explaining how it works: http://www.justanotherhacker.com/2011/05/htaccess-based-attacks.html http://www.justanotherhacker.com/2011/05/htaccess-based-atta...
- chopsueyar 15y ago
  That is quite interesting. Nginx? cough
  - wizard_2 15y ago
    I like Nginx a lot but apache isn't insecure by comparison. Nginx is possibly more secure out of the box with minimal configs but that's not a given either. You can do dumb things with either product. AllowOverride None That will disable htaccess files. http://httpd.apache.org/docs/2.0/howto/htaccess.html http://httpd.apache.org/docs/2.0/howto/htaccess.html
    - chopsueyar 15y ago
      But, then how to I get my pretty URLs?
      - saphead 15y ago
        httpd.conf? "You should avoid using .htaccess files completely if you have access to httpd main server config file...Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance." http://httpd.apache.org/docs/current/howto/htaccess.html http://httpd.apache.org/docs/current/howto/htaccess.html
        wireghoul 15y ago
        ^^^^^This
- ltamake 15y ago
  404, do you have an archived copy?
trebor 15y ago
How do apache hosts prevent against attacks like this? Or, at least how do they harden their implementations against it? I'm not much of a sysadmin but this intimidates me. I've always known that allowing PHP/.htaccess uploads are dangerous, if not fatal, and have done everything I know how to prevent them.
- muppetman 15y ago
  Using mod_security (seeing attempts to access filenames with htaccess in them) and using the grsecurity kernel patch to disallow binaries from running that aren't "owned by root in a root owned directory". So you can upload all the binaries you want, but you won't be able to run them.
- jerf 15y ago
  Speaking broadly, you really can't afford to let users stuff things on to your filesystem directly. You need to fully control the location of the file in some manner the user has no access to, and the "filename" of the file should exist only as database entries somewhere mapping back to your controlled name. Probably shouldn't even be in the web server's path. Oh, and if you've never thought about this before, odds are about 48% that you've got a JS injection on your file, too. Go upload a file called <script>alert("Hi")</script> and see what happens. The other 48% is that the shell you shouldn't be passing this filename directly to will go crazy because of the angle brackets being syntactically invalid. Oh, and if you can request files by name, can you request ../../../../../../../etc/passwd? Statistically speaking, probably yes. It's theoretically possible to safely manipulate the filesystem from within a web server but it's a great deal harder than it appears at first; there's a lot more than just learning the parameters to the "open" call.
  - tptacek 15y ago
    Generally, sound to somehow include the SHA1 of the filename in the filename, and to map [^A-Za-z0-9\.] to "_". If there's no reason to store a semantically valid filename on the filesystem, we usually just use the hash. It's easy and fast.
- Pahalial 15y ago
wadetandy 15y ago
Adding this to the pen testing toolkit. Great link.
nprincigalli 15y ago
This was common-practice back in the early 2000s, when you had to troubleshoot your webapp in production and the hosting company didn't provide you with ssh access (or it was too overpriced and/or required too much red tape). I was particularly fond of this one: http://www.rohitab.com/cgi-telnet http://www.rohitab.com/cgi-telnet Don't miss the screenshots there :D
sucuri2 15y ago
Nice hack in there. But the "bad guys" are already using the .htaccess for a while as well. Posted about it here: http://blog.sucuri.net/2011/05/understanding-htaccess-attacks-part-1.html http://blog.sucuri.net/2011/05/understanding-htaccess-attack...
- anthonyb 15y ago
  He's a friend of mine here in Melbourne, and currently working as a pentester for banks and other organisations. Believe me, he knows all of the things that the bad guys get up to.
  - sucuri2 15y ago
    Never said that :) Just wanted to show some of the techniques that the other side are currently using.
    - wireghoul 15y ago
      Hi there, As Antony said, I am a penetration tester, which tends to drive my research. I have seen several malware based attacks via .htaccess when I worked for a shared hosting company many years ago. The append iframe has always been a malware staple. Although I saw more redirects to specialized exploits based on user-agent rewrite rules than the blackhat SEO ones you are showing. SANS ISC has also covered several of these techniques over the years, but I digress. The point of my .htaccess based attacks are remote code execution or information disclosure that are valuable to an attacker during a targeted attack. Malware distribution is a very different beast. However, in both cases Apache hardening will help if not mitigate the attacks as dicussed in the earlier comments.

77 points by bartman 15y ago

I was thinking about this the other day when I was messing with .htaccess configuration for WordPress. Unfortunately there's a lot of stuff that relies on .htaccess capability. There's also a lot of stuff that relies on write access to the web directory. Wordpress auto-update and plugin update wants write access to the web directories. The alternative to this is to manually update the wordpress files, which potentially means bringing down the site for a minute while you maintenance it, and having to turn it into far more of a process than simply clicking 'upgrade'. In this case, the barrier to upgrading could backfire and make web servers even more insecure than they are now. WP-Supercache requires write-access to some caching folders in the web dir. A perfect place to dump scripts and run them even if you've locked writes to the rest of the website. This complicates theme and plugin management for Wordpress as well. And this is just one framework out of many that has these problems. The big question is: with all of these dynamic things happening on websites, how do you handle them at the filesystem level? SELinux and AppArmor are great ways to do it--but have massive configuration difficulties and really relies on you understanding quite a bit more about the OS than normal. It's easy to screw yourself if you don't use these tools properly. I propose that we rethink what .htaccess has access to and see if we can work on separating various functions into separate security zones and document that. For example: "AllowOverride Options" is insecure, but what if we allow only subsets of that?

bartman 15y ago

Blog post by the author explaining how it works: http://www.justanotherhacker.com/2011/05/htaccess-based-attacks.html http://www.justanotherhacker.com/2011/05/htaccess-based-atta...

chopsueyar 15y ago
That is quite interesting. Nginx? cough
- wizard_2 15y ago
  I like Nginx a lot but apache isn't insecure by comparison. Nginx is possibly more secure out of the box with minimal configs but that's not a given either. You can do dumb things with either product. AllowOverride None That will disable htaccess files. http://httpd.apache.org/docs/2.0/howto/htaccess.html http://httpd.apache.org/docs/2.0/howto/htaccess.html
  - chopsueyar 15y ago
    But, then how to I get my pretty URLs?
    - saphead 15y ago
      httpd.conf? "You should avoid using .htaccess files completely if you have access to httpd main server config file...Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance." http://httpd.apache.org/docs/current/howto/htaccess.html http://httpd.apache.org/docs/current/howto/htaccess.html
      - wireghoul 15y ago
        ^^^^^This
ltamake 15y ago
404, do you have an archived copy?

trebor 15y ago

How do apache hosts prevent against attacks like this? Or, at least how do they harden their implementations against it? I'm not much of a sysadmin but this intimidates me. I've always known that allowing PHP/.htaccess uploads are dangerous, if not fatal, and have done everything I know how to prevent them.

muppetman 15y ago
Using mod_security (seeing attempts to access filenames with htaccess in them) and using the grsecurity kernel patch to disallow binaries from running that aren't "owned by root in a root owned directory". So you can upload all the binaries you want, but you won't be able to run them.
jerf 15y ago
Speaking broadly, you really can't afford to let users stuff things on to your filesystem directly. You need to fully control the location of the file in some manner the user has no access to, and the "filename" of the file should exist only as database entries somewhere mapping back to your controlled name. Probably shouldn't even be in the web server's path. Oh, and if you've never thought about this before, odds are about 48% that you've got a JS injection on your file, too. Go upload a file called <script>alert("Hi")</script> and see what happens. The other 48% is that the shell you shouldn't be passing this filename directly to will go crazy because of the angle brackets being syntactically invalid. Oh, and if you can request files by name, can you request ../../../../../../../etc/passwd? Statistically speaking, probably yes. It's theoretically possible to safely manipulate the filesystem from within a web server but it's a great deal harder than it appears at first; there's a lot more than just learning the parameters to the "open" call.
- tptacek 15y ago
  Generally, sound to somehow include the SHA1 of the filename in the filename, and to map [^A-Za-z0-9\.] to "_". If there's no reason to store a semantically valid filename on the filesystem, we usually just use the hash. It's easy and fast.
Pahalial 15y ago

wadetandy 15y ago

Adding this to the pen testing toolkit. Great link.

nprincigalli 15y ago

This was common-practice back in the early 2000s, when you had to troubleshoot your webapp in production and the hosting company didn't provide you with ssh access (or it was too overpriced and/or required too much red tape). I was particularly fond of this one: http://www.rohitab.com/cgi-telnet http://www.rohitab.com/cgi-telnet Don't miss the screenshots there :D

sucuri2 15y ago

Nice hack in there. But the "bad guys" are already using the .htaccess for a while as well. Posted about it here: http://blog.sucuri.net/2011/05/understanding-htaccess-attacks-part-1.html http://blog.sucuri.net/2011/05/understanding-htaccess-attack...

anthonyb 15y ago
He's a friend of mine here in Melbourne, and currently working as a pentester for banks and other organisations. Believe me, he knows all of the things that the bad guys get up to.
- sucuri2 15y ago
  Never said that :) Just wanted to show some of the techniques that the other side are currently using.
  - wireghoul 15y ago
    Hi there, As Antony said, I am a penetration tester, which tends to drive my research. I have seen several malware based attacks via .htaccess when I worked for a shared hosting company many years ago. The append iframe has always been a malware staple. Although I saw more redirects to specialized exploits based on user-agent rewrite rules than the blackhat SEO ones you are showing. SANS ISC has also covered several of these techniques over the years, but I digress. The point of my .htaccess based attacks are remote code execution or information disclosure that are valuable to an attacker during a targeted attack. Malware distribution is a very different beast. However, in both cases Apache hardening will help if not mitigate the attacks as dicussed in the earlier comments.