How to get shell access with a .htaccess file | Hacker News Reader

How to get shell access with a .htaccess file

github.com

77 pointsbartman20 comments

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

Don't miss the screenshots there :D

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

That is quite interesting.

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

That will disable htaccess files. http://httpd.apache.org/docs/2.0/howto/htaccess.html

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

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.

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.

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:

    # The following lines prevent .htaccess and .htpasswd
    # files from being viewed by Web clients.

Security is seldom well served by agile's "simplest thing that could possibly work".

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.

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.

Don't allow untrusted clients to place arbitrary files on your web server.

"Bad programming? Use good programming!" Got it.

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...

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.

Adding this to the pen testing toolkit. Great link.

Reply on news.ycombinator.com