webcit-multi.txt
Posted on 17 July 2007
Vendor contacted: 2007-06-24 Affects: Webcit < 7.11 Fixed: 2007-07-06 (WebCit 7.11) 1. Background WebCit is the webfrontend to administer and use Citadel, which is an open-source groupware server. 2. Session Riding 2.I. Problem Description It is possible for an attacker to execute actions in the name of a victim, simply by having him visit a website the attacker controls content on. There are no precautions to prevent Session Riding at all. 2.II. Impact All userdetails, preferences and settings can be modified by an attacker in whatever he likes to. It is also possible to create new rooms, tasks, responses and pretty much everything else too in the name of the victim. 2.III. Solution I would recommend to use nonces that uniquely identify every action and are checked when the action is executed. For the change of the password I would additionally recommend to require the old one before being able to change it. 3. Stored Cross-Site-Scripting 3.I. Problem Description At several locations the user given input does not get properly sanitized and thus enables Cross-Site-Scripting. 3.II. Impact In the calender mode entries can be viewed by holding the mouse over it. The user input displayed in the onmouseover window does not get sanitized. When in "Bulletin Board" mode the content of an entry does not get sanitized properly and may contain malicious javascript. If the preferences contain a "> it is possible to break out of the value attribute of the input field. At first glance this does not seem too evil, since this entries are made by the users themselves, but due to the fact that the preferences may be set by an attacker utilizing the possibility of Session Riding. Room names are not sanitized properly too, when displayed on the room page itself. Because the name of a file, that gets uploaded is not changed by the application and the filename is not escaped when displaying, it is possible to include html or javascript code into the filename. Possibly some other places I did not see yet. 3.IV. Solution As far as i can see, the only thing you have to do is to apply the existing filters to sanitize the situations above. 4. Reflected Cross-Site-Scripting 4.I. Problem Description In the context of viewing a user the username may be chosen by the who parameter. By using a specially crafted username it is possible to inject html and javascript into the page. 4.II. Impact There are several scenarios how this behavior may be used in favor of an attacker. A pretty good diorama is, that an attacker sets up a website which contains an invisible iframe that loads a Webcit page, the user, that visits the attackers website, is logged in to. The loaded Webcit URL looks similar to the proof of concept below, but contains possibly more malicious javascript code, that enables the attacker to execute arbitrary actions in the name of the victim. 4.II.5. Proof of Concept Request showuser?who=%3Cscript%3Ealert('xss')%3C/script%3E 4.III. Workaround Do not echo the username given by the who parameter on the page. 4.IV. Solution Escape the username within the h1 tag the same way as it is done in the "send a message" link below. Greetings, Christopher Schwardt The CInsects-Team
