How to get shell access with a .htaccess file(github.com)
github.com
How to get shell access with a .htaccess file
https://github.com/wireghoul/htshells
6 comments
Blog post by the author explaining how it works: http://www.justanotherhacker.com/2011/05/htaccess-based-atta...
That is quite interesting.
Nginx? cough
Nginx? cough
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
But, then how to I get my pretty URLs?
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
"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
404, do you have an archived copy?
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.
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.
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.
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.
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.
Palliative: AllowOverride None
As jerf (+1, great answer), stepping back a little... it has been ~fifteen years since we started noticing problems with htaccess. It filled a niche when webserver configuration was hard and when CRUD admin interfaces were significant work. Htaccess (and friends) should go now. I don't just mean "use the palliative above": I mean any time a remote client can potentially download or overwrite the ACL then the design is probably broken. (Apache is not alone here).
With the myriad of possible use cases and massive deployed base apache is probably stuck with htaccess until extinction. Forever more, we will see this comment in httpd.conf:
Worse, there is certainly other "best of breed" security stuff that we are doing right now that will be incontestably bad from a future viewpoint. What is that stuff?
As jerf (+1, great answer), stepping back a little... it has been ~fifteen years since we started noticing problems with htaccess. It filled a niche when webserver configuration was hard and when CRUD admin interfaces were significant work. Htaccess (and friends) should go now. I don't just mean "use the palliative above": I mean any time a remote client can potentially download or overwrite the ACL then the design is probably broken. (Apache is not alone here).
With the myriad of possible use cases and massive deployed base apache is probably stuck with htaccess until extinction. Forever more, we will see this comment in httpd.conf:
# The following lines prevent .htaccess and .htpasswd
# files from being viewed by Web clients.
Worse, there is certainly other "best of breed" security stuff that we are doing right now that will be incontestably bad from a future viewpoint. What is that stuff?
As usual, allow the smallest subset of functionality which still permits legitimate uses. In these cases they're relying on .htaccess files being allowed specific overrides - FileInfo and Options being the most powerful ones.
'AllowOverride AuthConfig Indexes' is generally relatively safe (in my humble experience) - i'd be scared to see an htshell like these with just those.
'AllowOverride AuthConfig Indexes' is generally relatively safe (in my humble experience) - i'd be scared to see an htshell like these with just those.
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.
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-attack...
http://blog.sucuri.net/2011/05/understanding-htaccess-attack...
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.
Never said that :) Just wanted to show some of the techniques that the other side are currently using.
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.
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.
Adding this to the pen testing toolkit. Great link.
I was particularly fond of this one:
http://www.rohitab.com/cgi-telnet
Don't miss the screenshots there :D