Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2010-05-30 03:54:30
- fjdekermadec
- New Member
- From: Paris, France
- Registered: 2010-05-30
- Posts: 7
[feedback] An argument for a random admin folder name
Hello all,
I am installing my twentieth Textpattern instance today, and started questioning my practice of renaming the Textpattern admin folder to some random value for each different site. After perusing the forums, the general consensus seems to be that this is merely security through obscurity, which is in an inherently bad thing.
I agree with security through obscurity not being “real” security, but it seems allowing users to rename the Textpattern folder during the installation would safeguard against automated scripts that perform crude “tricks” (XSS or else) from the web or from the host’s own server. Indeed, it seems it is not uncommon for crackers now to gain access to a user’s shell on a hosting server and run a script that attempts to insert code in every account on the server at pre-defined locations (such as admin folders, index.html files, etc.) By making the location of this folder harder to “guess” we could provide a line of defence against such crude exploits.
Am I talking through my hat? Alas, I do not have the coding knowledge to propose a patch, but I would be curious to hear thoughts from those who could make it happen — even if they won’t.
— FJ
Offline
Re: [feedback] An argument for a random admin folder name
I think we would need some evidence for “it seems it is not uncommon for crackers now to […] to insert code at pre-defined locations” in the first place. If I were to abuse somebody elses server I’d rather traverse all directories and modify any index.php that pops up, no longer than a few days after a target CMS has introduced random admin directories.
Offline
#3 2010-05-30 14:05:53
- fjdekermadec
- New Member
- From: Paris, France
- Registered: 2010-05-30
- Posts: 7
Re: [feedback] An argument for a random admin folder name
Hello Wet,
I am thinking of something like this or even this where scripts target known locations for headers or footers, betting on the fact these files are rarely, if ever, opened and examined by hand — compared to say, a home-whipped PHP script at the root of a domain.
Even something crude like this could probably be avoided unless the attacker takes the time to find references to the name of the Textpattern folder for a particular install. Not impossible, certainly, but incompatible with the idea of unleashing a script on a domain. Of course, this is a very old vulnerability and I assume one would be hard pressed to find such holes in today’s Textpattern, but it’s just for illustration purposes.
Thanks for your insights!
— FJ
Offline
Re: [feedback] An argument for a random admin folder name
Yes, there is evidence well-known blog engines and their file layout are targets, but this does not allow us to conclude that crackers won’t adapt their tools once we’d use random locations to find these just the same.
The necessary code changes in core are minimal, but they add a new set of setup permutations to test (single site, multi site, random /textpattern directory and combinations thereof) so we’d rather be quite sure that this effort pays off.
Offline
#5 2010-06-02 11:18:52
- fjdekermadec
- New Member
- From: Paris, France
- Registered: 2010-05-30
- Posts: 7
Re: [feedback] An argument for a random admin folder name
Yes, there is evidence well-known blog engines and their file layout are targets, but this does not allow us to conclude that crackers won’t adapt their tools once we’d use random locations to find these just the same.
In a way, the same could be said of every security measure under the sun. Even bona-fide data encryption requires larger keys and new methods because existing algorithms are slowly but steadily cracked or bypassed. Finding a randomly-named folder on a server, whose name does not appear in the HTML source, and without local access or with local access but not execute permissions on the web directory, would require educated guesses or brute force attacks, none of which are really practical.
The necessary code changes in core are minimal, but they add a new set of setup permutations to test (single site, multi site, random /textpattern directory and combinations thereof) so we’d rather be quite sure that this effort pays off.
That’s indeed a lot to check, and I see how this “simple change” could open a Pandora’s box of QA issues. Is there a way to test whether this could pay off, or an analysis process you would, as a developer, consider valid?
Last edited by fjdekermadec (2010-06-02 11:19:05)
Offline