Security Alert: Foswiki Script Insertion Vulnerability via unchecked user registration fields

All versions 1.0.0 - 1.1.4 inclusive for sites that use the standard user registration process

Attack Vectors

Foswiki's /bin/register (see Foswiki/UI/Register.pm) does not perform any validation or sanitization of registration fields submitted for the UserForm. These input fields (Eg. "FirstName", "OrganisationName", "OrganisationUrl", etc.) could then be used to inject arbitrary HTML markup, including script code, into the user topic which is generated by the RegistrationAgent.

E-mail notifications to site administrators and other subscribed users may provide exposure to injected HTML, especially if templates have been modified to send HTML email.

If the site does not use the provided bin/register script and the UserRegistration topic and instead uses an external mechanism like LDAP, then the site is not vulnerable.

Impact

If your Foswiki installation already allows newly registered users CHANGE permission anywhere in the wiki, they have already been able to inject arbitrary HTML markup including script code, and will continue to have that ability even after the fix at has been applied. The ability of using JavaScript in Foswiki pages is a feature.

However, not all Foswiki installations have their access controls configured to immediately trust newly registered users. If your site uses a variation of the practice suggested at Support.BestPracticeTip26, that is:

• the site allows registrations
• newly registered users have zero CHANGE permission anywhere in the wiki
• requires a member of AdminGroup or some ModeratorGroup to explicitly grant CHANGE permission so that new users can modify content

Then this vulnerability provides an attack vector which could allow an attacker to perform actions on the wiki on behalf of whoever visits a compromised user topic.

For example:

• A moderator notices a suspicious user topic (Eg. via WebChanges)
• The moderator visits the user topic, intending to delete it
• The malicious script injected via the /bin/register vulnerability is executed
• The malicious script makes requests on behalf of the moderator user, potentially without their knowledge

Foswiki is designed to prevent several forms of cross site scripting (XSS) and cross site request forgeries (CSRF), and we will make our best effort to continue to both pro-actively review code for security holes and react to vulnerability reports sent to us.

Countermeasures

Foswiki has made a hot fix available for Foswiki which "safe encodes" the registration fields in the register script. The fix, detailed below, adds 3 lines of code to lib/Foswiki/UI/Register.pm

Foswiki 1.1.5 will contain a more extensive fix that adds pluggable validation in the User Mapper code. This permits installations using customized mappers to do additional validations specific to their installation. Date of release of 1.1.5 not yet decided.

• For 1.1.4 Apply the hotfix made available by replacing the lib/Foswiki/UI/Register.pm
• For earlier releases make a manual edit of Register.pm as described below. Or better - upgrade to 1.1.4 and apply patch.
• Upgrade to the latest patched production Foswiki 1.1.5 once it is released.

Hotfix for Foswiki Production Releases 1.1.0-1.1.4

This fix is currently tested on all versions of Foswiki since 1.1.0. It assumes that <, >, %, ' and " cannot occur in any field except the password. The other fields listed below are validated elsewhere.In lib/Foswiki/UI/Register.pm, search for the line "#DO NOT UNTAINT THESE DATA HERE" and insert the code as shown in here marked with ">":

            # DO NOT UNTAINT THESE DATA HERE!
>            unless ( $name =~ m/^(?:wikiname|name|loginname|username|password|confirm)$/i ) {
>                $value =~ s/([<>%'"])/'&#'.ord($1).';'/ge;
>            }
            $data->{$name} = $value;

• Register.pm: Patched Register.pm from Foswiki 1.1.4

Action Plan with Timeline

#	Action	Date/ Deadline	Status	Who
1.	Uncoordinated reports are made public	2012-02-02	N/A	Sony
2.	Developers verify issue	2012-02-02	Done	Sven Dowideit, George Clark
3.	Security team triage the issue	2012-02-03	Done	George Clark, Paul Harvey
4.	Developer fixes code, Tasks.Item11501	2012-02-08	Being worked on	George Clark
5.	Security team creates advisory with hotfix	2012-02-09	Done	George Clark, Paul Harvey
6.	Send alert to foswiki-announce and foswiki-discuss mailing lists	2012-02-09	Done	Paul Harvey
7.	Publish advisory in Support web and update all related topics	2012-02-09	Done	Paul Harvey
8.	Reference to public advisory on Download page and Known Issues	2012-02-09	Done	Paul Harvey
9.	Issue a public security advisory (vuln@secunia.com, cert@cert.org, bugs@securitytracker.com, full-disclosure@lists.netsys.com, vulnwatch@vulnwatch.org)	2012-02-09	Done	Paul Harvey

The following sites are known to be reporting this issue:

• http://www.securitylab.ru/vulnerability/419289.php
• http://secunia.com/advisories/47849/
• http://packetstormsecurity.org/files/109393
• http://www.ehackingnews.com/2012/02/foswiki-web-application-vulnerable-to.html
• http://osvdb.org/show/osvdb/78827
• http://cxsecurity.com/issue/WLB-2012020033
• http://forums.cnet.com/7726-6132_102-5269585.html
• http://cyberleaks.org/index.php/2012/02/foswiki-xss-vulrble/
• http://itgeeks.us/2012/02/03/foswiki-web-application-vulnerable-to-cross-site-scripting/
• http://st2tea.blogspot.com/2012/02/foswiki-cross-site-scripting.html
• http://twiki.org/cgi-bin/view/Codev/TWikiUserOrganizationScriptInsertionVulnerability

• Set ALLOWTOPICCHANGE = SecurityGroup