Posts Tagged ‘testlink’

TestLink 1.8.5 security bugs

Posted: 26.10.2010 in Security
Tags: , ,

Download text in format: testlink-1.8.5-report.txt

Version table:
2010-10-26 1.0 – Public release, some minor fixes at text and formatting
2010-01-04 0.3 – Developers notified
2009-12-31 0.2 – Added incorrect acce control and Insecure directory creation, more SQL injection cases added
2009-12-29 0.1 – Initial version

Table of content:

  • Vulnerable versions
  • Cross site scripting
  • Session fixation
  • SQL injection
  • Cross site request forgery
  • Insecure default configuration
    • Logs
    • Attachment uploads
  • Incorrect access control
  • Insecure directory creation

Testlink 1.8.5 has multiple security vulnerabilities.

Vulnerable versions

Testlink 1.8.5

Scope and environment

Only the basic installation is tested. Any extra libraries like LDAP are not tested at all. The test environment is Ubuntu 9.04 with its default Apache configuration. XMLRPC was not tested at all.

TestLink is installed to following URL’s:
http://192.168.56.101/workspace/testlink/ at physical directory /var/www/workspace/testlink
http://192.168.56.101/testlink-1.8.5/ at /var/www/testlink-1.8.5

Cross site scripting

At the index.php is parameter ‘reqURI’ which is loaded to central frame after login. That parameter is vulnerable for XSS and it can also contain external URL which is loaded to the frame.

After the user has logged in if he is tricked to click link like:
http://192.168.56.101/testlink-1.8.5/index.php?reqURI=javascript:alert(document.cookie);

the XSS is exploited. This XSS can be used to set persistent cookie which exploits the session fixation. The escaping of double quote (“) is done with backslash (\) which is incorrect way to escape tag-parameters.

The same parameter can be used to inject external pages to central frame. This is risk for phishing attack.

Testlink should check that given URL is valid inside the application and integrated bug tracking system. It should not allow any domain to URL, it should also check that URL is http- or https-protocol.

Session fixation

Testlink is mishandling the session id which enables XSS or any other cookie manipulation attack to set persistent cookie which is known by attacker. E.g. if cookie is set to “PHPSESSID=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; expires=Tue, 29 Dec 2011 14:06:24 GMT; path=/” somehow, it is used as valid session id by Testlink. Each time when user with previous cookie logs in, his session id which is used for authentication is “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa”.

After login Testlink should create new session id and dispose the old session ID. It also must make sure that every time when PHPSESSID has value which is not generated by Testlink, it is decided to be invalid session id and requires logging.

SQL injection

eventviewer.php has SQL injection at parameter object_id. The SQL injection can exploit the weaknesses at database configuration or other security related issues at it. E.g. following query tries to write to file /tmp/test.txt.

http://192.168.56.101/testlink-1.8.5/lib/events/eventviewer.php?object_id=1)union%20SELECT%20%271%27%20FROM%20testplans%20into%20outfile%20%27/tmp/test.txt%27%20%23+–+aa

Another SQL injection is at set execution as can be seen in the error message of query:
http://192.168.56.101/testlink-1.8.5/lib/execute/execSetResults.php?version_id=17&level=testcase&id=9&build_id=1&include_unassigned=0&tplan_id=x’

Error message points out that ‘ is not escaped. It also shows that tplan_id is placed directly to SQL-query.

This is only small subset of possible SQL injection places. The testing has been manual which reduces the possibility to go thru all possible parameters which would most likely show other similar problems.

Cross site request forgery

Testlink contains cross site request forgeries at all administrative tasks. With well crafted URL you can put IMG-tag to test case which executes tasks like changing user permission, removing projects or modifying the content if user with sufficient permissions views the test case. E.g. to change user’s access level to admin he has to know his user id and add following link to test case:

http://192.168.56.101/testlink-1.8.5/lib/usermanagement/usersEdit.php?user_id=2&user_login=test&firstName=firsttest&lastName=lasttest&emailAddress=example%40test.com&rights_id=8&locale=fi_FI&user_is_active=on&doAction=doUpdate&do_update=Save

To fix CSRF Testlink should add extra parameter which is validated against the session. The parameter should not be session id. Every task which modifies data should have this additional parameter.

Insecure default configuration

Default configuration of off the shelf program should be as secure as possible. After that the administrator can add risky features and understand the risks.

Logs

At the default installation logs are stored to directory /logs. This is insecure practice because the directory is readable with browser. Logs also contains users’ session id so session hijacking is too easy.

By default the logs should not include the session id. They should not be at browser readable directory.

Attachment uploads

The default installation has attachment uploading enabled. The storage directory is /upload_area. Uploaded file is named so that file extension stays same as the original file and beginning of file is renamed to random hash value. Default upload area is accessible with browser. With this setting the attack is able to upload php file to the server and execute it as soon as he founds the random hash value of file. That can be found thru other vulnerabilities or security weaknesses. E.g. if Ubuntu server has default Apache installation, it is allowing file listing if index -file is missing. So just by going to http://192.168.56.101/testlink/upload_area the attacker can see the directory structure and list of files.

By default the attachments should be turned off and upload directory be such that administrator must edit it. This way the administrator knows the security risks and accepts them.

Incorrect access control

Test case handling has incorrect access control. The attacker requires only guest account to system to be able to view and modify any test case. Even if he does not have any access to the project, he is still able to view the test cases of project. He just has to use direct url’s to them:

To view the test case: http://192.168.56.101/workspace/testlink/lib/testcases/archiveData.php?version_id=undefined&edit=testcase&id=9
To modify the test case: http://192.168.56.101/testlink-1.8.5/lib/testcases/tcEdit.php?testcase_id=14&tcversion_id=15&has_been_executed=0&doAction=edit&edit_tc=Edit
To upload the attachment:
http://192.168.56.101/workspace/testlink/lib/attachments/attachmentupload.php?id=9&tableName=nodes_hierarchy
To export test cases:
http://192.168.56.101/testlink-1.8.5/lib/testcases/tcExport.php?containerID=3&bRecursive=1

As soon as he is able to view the test case, he is also able to at least view and delete the existing attachments.

At requirement management the access control seems to work. So following the style which is done there should be followed also there.
Similar problem might be at other parts also.

Insecure directory creation

It is possible to upload files to incorrect directories as attachments. For example url:
http://192.168.56.101/workspace/testlink/lib/attachments/attachmentupload.php?id=9&tableName=../../../../../tmp/die

wrote at our test environment to /tmp -directory the attachment. This can lead to situation where the attacker is able to choose single insecure directory from the whole web server where he writes his attack. Or he can block server to write some important file which could be used to detect hacking.

Testlink must make sure that the files are written only to directories which are authorized by the administrator.