Tags:
create new tag
, view all tags

Security Alert: Gain Admin Right with TWiki Users Mapping

Problem Description

TWiki & its derivatives have a serious security issue allowing any remote user to take admin rights over any TWiki. How:

  1. Register with the site
  2. Find a username in in TWIKIADMINGROUP. (eg PeterThoeny )
  3. Edit TWikiUsers changing that user so that your username resolves to a username in the the admin group. eg:
   * PeterThoeny - MaliciousUser - 09 Aug 2002

This also works if a malicious user wants to join any TWiki group: Just hijack a WikiName, change the page, do a replace revision to eradicate traces, and then move back.

This security issue applies to both, direct registration (ie htpasswd) and external authentication (eg mod_ldap) implementations.

Background

TWiki can map from the Intranet login name (e.g. jsmith) to the WikiName (e.g. JohnSmith). This is needed for corporate installations where users are authenticated against a central NIS or LDAP, and in TWiki, you want to show the user's WikiWord signatures pointing to their home pages. This mapping is done in the TWikiUsers topic; the login name is supplied at the time of TWikiRegistration. Sample line in TWikiUsers:

   * JohnSmith - jsmith - 01 Jan 2000

This feature can be used by a malicious user to gain admin rights as described unless the TWikiUsers topic is locked down and the default users are removed in the TWikiAdminGroup and the data/.htpasswd file.

Quick Fix

Two steps should be applied:

  1. Lock the TWikiUsers topic
  2. Secure the users in the TWikiAdminGroup

1. Lock the TWikiUsers topic of your own TWiki site so that only administrators can change it. Add this line:

   * Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup

2. Secure the users in the TWikiAdminGroup:

  1. Make sure that only legitmate administrators are listed in your Main.TWikiAdminGroup topic
    • FYI, the default TWiki installation ZIP file contains some users in the TWikiAdminGroup and the data/.htpasswd file. As described in the TWikiInstallationGuide#Enabling_Authentication_of_Users, make sure that you have removed those users. One of the default's password is easy to find using "john".
  2. Make sure that your administrators have a strong password, and that they change it in regular intervals

ALERT! Important: Public TWiki sites should apply this quick fix ASAP.

Disable Login Name to Wiki Name Mapping

The two step quick fix secures your site adequately. In case you want to apply an additional layer of security you can apply the following fix to disable the login name to Wiki name mapping.

Upgrade your system to the latest TWikiAlphaRelease and set $doMapUserToWikiName = "0" in your lib/TWiki.cfg, or follow this procedure to update your current installation: (additions and changes are indicated in red color)

1. Patch lib/TWiki.cfg file

Add this after the $userListFilename setting:

#        Map login name to Wiki name, default "1", set to "0" for .htpasswd authenticated sites :
$doMapUserToWikiName = "0";

2. Patch lib/TWiki.pm file

2.1 Add $doMapUserToWikiName to the use vars qw( list

        $userListFilename $doMapUserToWikiName %userToWikiList %wikiToUserList

2.2 Change function userToWikiListInit to start with this:

sub userToWikiListInit
{
    %userToWikiList = ();
    %wikiToUserList = ();

    # bail out in .htpasswd authenticated sites
    return unless( $doMapUserToWikiName );

    my @list = split( /\n/, &TWiki::Store::readFile( $userListFilename ) );

    # Get all entries with two '-' characters on same line, i.e.
    # 'WikiName - userid - date created'
    @list = grep { /^\s*\* $wikiWordRegex\s*-\s*[^\-]*-/o } @list;

Contributors:
-- MS - 05 Nov 2003
-- PeterThoeny - 05 Nov 2003

Discussions

Micheal, thank you very much taking the time to let the main TWiki community know about this very serious vulnerability. And then going even further by submitting patches against multiple historical twiki versions.

-- MattWilkie - 05 Nov 2003

Additionally, I wonder how best to communicate this to the administrators of the 1000s of TWiki sites.

One option is to actually secure them - given that any public sites that are vunerable are too open to us editing TWikiUsers and adding a 'Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup'.

-- MartinCleaver - 06 Nov 2003

Michael, thank you very much for informing us, and also for providing a patch.

It would serve the TWiki community better to inform one of the CoreTeam members of serious security issues via e-mail (as MartinCleaver did) before posting it in Codev so that TWiki site administrators can be alerted before malicious users get the chance to crack sites.

A communication will go out shortly to all who listed their TWikiInstallation at TWiki.org and all who are listed in Codev.WebNotify

The temporary fix to disallow save of the TWikiUsers topic is an additional layer of security. One could argue that this is not really needed since one would need to lock down other topics as well to gain the same level of security, like the TWikiAdminGroup and TWikiPreferences topics. Those topics could then only be changed on the shell level.

I renamed the topic from SecurityFlaw to a more descriptive name. KnownIssuesOfTWiki01Feb2003 is updated as well.

-- PeterThoeny - 05 Nov 2003

  1. I posted the flaw/fix here a) because this is where most people who actively patch/check TWiki look b) the fix needs more work
  2. History has shown that my comments get ignored
  3. You have stated before ( repeatedly )that everything must be done in the wiki.
  4. The problem had been discussed on IRC, and that is logged. This means that the "problem" was already known about. Given Martin dropped hints about it a few days back, I presume you were notified of the problem a few days back. Posting a fix to a problem strikes me as wise. The fact you don't run standard security & user mailling lists (ala every other open source project) to contact your users isn't my problem.

IMPORTANT

  • Locking down access soley to TWikiAdminGroup is insufficient to prevent this problem. The core team passwords in the htpasswd file are insecure, and at least one of them (you only need one) is readily findable using the password tool "john". (I periodically run this against my passwd files, and decided to check the default twiki one only recently - it's been noted as a problem for years though)

  • The hack I supplied can be worked around - though it's harder to do than the working around the TWIKIADMINGROUP approach. This fix prevents the obvious attack.

-- MS - 06 Nov 2003

Michael, thanks for pointing out the default users again. Although already described, I reworded the fix to be more clear about the default users.

The communication went out to the TWiki-dev mailing list, all admins listed in TWikiInstallations, and all users in Codev.WebNotify.

For the records, Marin alerted me today Wednesday while I was at work; I was reading my e-mail after dinner and took action immediately after bringing my kids to bed. Now it is time for me to go to bed for a short 5 hour sleep...

-- PeterThoeny - 06 Nov 2003

  • I was not trying to paint you in any kind of light - I was trying to explain why I posted the flaw/fix on twiki.org. If you don't like the reasons that's not my fault. You do ask for everything on the wiki, you do tell people not to discuss things on the mailling lists, you ignore issues based on who's saying them rather than the merits of issues.

I thought I had done you a favour by posting patches against the last several releases - including the old releases which I know some core team members have said they're running at their workplaces.

  • I will think twice from doing you a favour again on security aspects in future.

-- MS - 06 Nov 2003

A few things:

  1. I must take some responsibility for not having reported this to the core team sooner. It is fair that MS could have assumed that I'd already reported to the core team by email as I discovered something was amiss 1 day before I said anything on TWikiIRC, 3 days before I managed to have a full discussion with MS and a further few hours before I made time to email the CoreTeam. I suspect that MS had posted the report before the email left my machine and it is my fault I did not CC him. I am sure we were all thoroughly delighted to see Michael's fixes - including for past revisions - go up so quickly. Again, on my part I could have either 1) requested MS not post anything until I'd notified the core team and at least 2) included MS on my email to them. If we want a "communicate to the core team by email" process we need to make this clear in advance, and we need assurances about how quickly the core team would address it. Let us just stay with our heartfelt thanks to MS - he did us all a favour. The only aspect that I might have wanted differently would have been to hold on until he made the patch available, but again, without a defined process he did only good.
  2. Let us now focus on how best we can communicate rectification. As I said before, one option might be to proactively secure sites from this mapping bug by using the TWikiGuest account to edit the TWikiUsers page to include an ALLOWTOPICCHANGE = TWikiAdminGroup.
  3. Finally, let us seek what we have in common, lest we become mired in our differences. For however we differ, everyone stands to gain more this way.

-- MartinCleaver - 06 Nov 2003

Before we go any farther down the road of whether it was or was not appropriate for MS to post the problem and fix here before doing anything by email, lets concentrate on the immediate problem at hand and get that fixed first. Afterwards we can discuss what the policy for security notification should be (because currently there isn't one, which is a major cause of the disagreement in the first place).

-- MattWilkie - 06 Nov 2003

  1. what is needed for a real fix of this problem?
    • can it be achieved in less than a week? if yes maybe wait until real fix is developed before more widespread notification is launched
  2. there are people who administer twiki sites who are not subscribed to either of the channels above (Codev.WebNotify and TWikiInstallations). What is the best way to find and contact these people? Some possibilties I can think of:
  3. Should we proactively hunt down and fix public twiki sites?
    • I'm (MWambiguous about this. I think I would say yes, provided the actual admin of the site could not in some way be locked out of their own site.
    • an alternate, slightly less proactive method, would be to use the 'feedback' links on public twiki sites to send an email. Perhaps chain the two, email first, wait a day (more?), if no reply then fix it for them.
    1. in either case, we should draw up a list of who is to be contacted and/or fixed and split it up between us so the admins don't get spammed by a blizzard of alerts.

-- MattWilkie - 06 Nov 2003

Lets focus on the facts.

Question: Assuming the site admin set his Main.TWikiAdminGroup as indicated in the installation instructions, what is the difference between:

  1. A person with malicious intent registering as JoeCracker (with password crack)
  2. A person with malicious intent cracking the password of a default user (assuming the admin did not clean out the .htpasswd) and login in as that user?

I believe both cases are on the same security level. Correct me if I am wrong, but the issue is not default users left in the .htpasswd, but an unlikely incorrect setting of the Main.TWikiAdminGroup during installation.

Now, the real fix to protect against the omission of removing the default users from the Main.TWikiAdminGroup is this:

  • Change the package script to remove the default users
    • This addresses future distributions
  • Change the code to distinguish between sites operating with login name mapping and those without. Do the mapping only if needed
    • This addresses future distributions; a patch can be provided for paranoia

-- PeterThoeny - 06 Nov 2003

I didn't realise till just now that the TWikiAdminGroup in the Feb2003 release was the same as the CoreTeam users - requiring the user to clean out this group and to delete core team users from the .htpasswd.txt file is reasonable if the person installing is security conscious, but not everyone is (and it's easy to forget a security step when installing). So this is really a security hole waiting to happen - IMO the default user entries should be deleted, leaving only the guest user, and the default TWikiAdminGroup should be set to nobody. That way, only the TWiki administrator, who can update files directly on the server, is able to enable the TWikiAdminGroup.

Having done some Internet searches for potentially vulnerable TWikiAdminGroup pages, I haven't actually found any, but that may be a flaw in my searching of course as I've not actually tried to log in to such TWikis.

-- RichardDonkin - 07 Nov 2003

May be I am missing something, but this statement seems incorrect to me:

  • Locking down to TWikiAdminGroup is insufficient in case the default logins are not removed, which can be (trivially) used to hijack control. The hack below is not a perfect fix, but it covers the majority of attacks most users would perpetrate. Public facing sites very definitely need to apply it. (or something similar - eg manual registration and make the page not writeable by the web server)

Locking down the TWikiAdminGroup and TWikiUsers topic does secure the site, even if the default users are left in the .htpasswd file. What is the difference between a default user and a newly registered user, assuming TWikiAdminGroup does not list the default users?

Nevertheless, the default users should be removed from the TWiki package. This is to prevent attacks of sites where the default users have been left carelessly in the TWikiAdminGroup. As mentioned before, I will change the package script to remove the default users. (The users are needed in our Beta installation for documentation work and for testing).

Programmatically preventing the update of the TWikiUsers topic is not needed, and it is also not a viable solution for Intranet sites. At my daytime job we have way over 1000 users, with several new users registering every week. It happens once in a while that an employee supplies an incorrect login name in the TWikiRegistration; it happens also that the login name changes (e.g. if a contracter gets converted to a fulltime employee). That is, the administrator needs to have the ability to fix login names.

A paranoia fix is now in TWikiAlphaRelease and at TWiki.org: The login name mapping for .htpasswd authenticated sites can be disabled with a new $doMapUserToWikiName = "0" flag in the lib/TWiki.cfg file. It is set to "1" in the distribution since the Intranet setup is the default one for the TWiki package.

-- PeterThoeny - 08 Nov 2003

Process improvement: I added a note to the BugReport topic stating "In case you think that you discovered a security issue that could potentially compromise public TWiki installations, please contact one of the CoreTeam members by e-mail."

-- PeterThoeny - 23 Nov 2003

Unintended side-effect?

I applied this patch, and also the one for RcsWrap. I now find that the restricted-view Webs no longer appear on the site map of the Main Web. This is just like the problem described in SiteMapIsEmpty, except that the workaround identified earlier no longer works!

Obviously I will post the solution here if I find one, but I am rather short of time at the minute and I would appreciate if someone could tell me the answer. It may of course have nothing to do with this particular patch! Please let me know if you can or can't reproduce the problem: it would help identify the area where it may be going wrong.

-- ImmoHuneke - 27 Nov 2003

Immo, exactly which patch did you apply? The essential work is:

There is also the patch to stop translation working for users. Other than that there is the patch that stops TWiki updating of TWikiUsers, although personally I don't see the need for this.

-- JohnTalintyre - 27 Nov 2003

Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r22 - 2004-11-28 - WillNorris
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.