Posts Tagged ‘bug’

Phun with redirects

Posted: 31.10.2010 in Security
Tags: , ,

I love redirection at web applications. They are so often broken. I’m trying to list here several mistakes which I’ve seen most often. Redirections are often used in places like login. That tries to make system friendlier for users by returning user to same page where he clicked the “Login”-link. So let’s imagine there is page ‘brokensite.xyz’ which has that kind of redirection. When user clicks “Login”, he is directed to page http://brokensite.xyz/login.jsp?returl=returnpage.jsp.

First: Lack of url validation. The attacker is able to set any url to returl-parameter. I usually try to replace valid destination with http://google.com/ and if I end up to that page after I’ve logged in, system is vulnerable. This should be one of the basic checks with web applications. In this case it would be: http://brokensite.xyz/login.jsp?returl=http://google.com/.

Second: Middle of URL %0A and especially with jsp. That is new line, and when redirection is made with http-result code 30x (302, 301 or some other). Then the target destination is given with Location-header. If the web application is not url encoding the destination properly, attacker can add new headers with %0A. And web browsers (at least Firefox) are redirecting to the last Location-destination. So in this case the attack URL would be: http://brokensite.xyz/login.jsp?returl=correctone.jspLocation:+http://google.com/

Third: Incorrectly escaped ” or ‘ when redirection is done with META-tag or JavaScript. Those cases are more like XSS or html injection errors. But still they can be very effective. Usually the mistake happens with META-tag. Developers tend to forget that proper quote escaping is not with backslash at tag-parameters. Let’s expect that quote is now escaped wrong with backslash so ” at parameters are converted to \”. Only characters ‘ and ” are escaped.

To produce result below our url must be: http://brokensite.xyz/login.jsp?returl=correctone.jsp?”<script>alert(1);</script>.

<META
HTTP-EQUIV="Refresh"
CONTENT="0; URL=correctone.jsp?\"><script>alert(1);</script>

Fourth: JavaScript-redirection is not properly escaping character combination – -> or ]]> – depending what kind of hiding is used at JavaScript. Those are usually ending the JavaScript hiding and also escaping from quotes. So JavaScript below is totally legal. It is created with url http://brokensite.xyz/login.jsp?returl=correctone.jsp+- -></script><script>alert(1);</script> (remove the space between dashes. WP seems to combine multipe dashes to longer dash.)

<script><!--
window.location="corretone.jsp --></script><script>alert(1);</script>");

//-->
</script>

If you are developer and plan to make redirection, please, use response codes instead of JavaScript and META-tag. The JavaScript is most vulnerable type of redirection. And META-tag can be turned off too easily. Always URL-encode everything you receive. Never trust to anything which is coming from the browser. Testers – like me – can be evil, but criminals can be even more evil.

Why redirection errors are bad? Well – thanks for the insecure SMTP-protocol, phisher can send to victims the mail with from-address admin@brokensite.xyz. Mail says that account has been suspended and requests the user to login to http://brokensite.xyz/login.jsp?returl=attackers_own_url. And that can insert malware, steal password by telling that user gave wrong password and requests to resubmit the password and so on. Attack possibilities are nearly unlimited.

Advertisements

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&#8217;

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.


Usually we know what bugs should be fixed. But that’s not always clear to other people at project. This problem appears usually with security issues. Project and product managers don’t usually see how some security issue or risk can be so destructive, that they should be high priority issues. Most proof of concepts from security issues are not real exploits, but rather “Hello world”-types because creating good proof of concept just costs too much to be justified.  Instead of writing POC, one should know how to write story about problem. And that’s what I’m now days usually doing when I submit security bug.

Every story has some common components. So must have every bug report which is telling the story. They should be:

  • Technical details at the beginning. The problem must be found easily by developer.
  • Actors. I’m always giving some kind of description who they are. Almost always there is one villain and victim, but villain can be also some innocent person, who just tries to get her work done more quickly.
  • Motivation. The villain has to have good motivation to exploit the bug.
  • Result. It should hurt someone, kill the business or reveal sensitive data.

For example:

Many PHP-applications has weak session handling. If the attacker can give own value for PHPSESSID, it is accepted and used by the application. Those can happen with cross site scripting bug or local access to the computer and tempering directly the cookie storage of Firefox. The tested application – women’s social site about home violence WSSAHV.COM – has weak session handling, but the tester didn’t find XSS. So report with story would be:

(Place technical details before the story. Also describing how the session should work.)

There is family and members are Hilma (wife) and Onni (husband). Onni is jealous. At some point he finds out that Hilma is using site WSSAHV.COM. Of course he suspects that she’s cheating or telling lies about him there. He directly doesn’t want to attack against her and force to give the password so he starts hacking and notices the weak session handling.

He has the administrator rights to their shared Windows desktop; he has also access to Hilma’s personal files. He goes to Firefox profile files, opens cookies.sqllite with sqllite. There he inserts new cookie for WSSAHV.COM. Domain is ‘WSSAHV.COM’, path ‘/’, name is ‘PHPSESSID ‘ and value is ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa‘, expiration is set to July 15th, 2020.

Next time when Hilma logs in to WSSAHV.COM, Onni has access to her profile from different computer. He just sets PHPSESSID at his machine to ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa‘. Onni can alter the profile, read the private message, and see the hidden areas where Hilma might have access and so on. This violates the privacy and meaning of the site. It also places the users to danger.