Vulnerability Information

Vulnerability Description

MacOS X Server 10.5 [1], also known as Leopard Server features a Wiki Server [2], which is a multiuser web application written in Python. The Wiki Server is vulnerable to a path traversal attack, which can be exploited by non-privileged system users via a forged file upload to write arbitrary files on locations in the server filesystem, restricted only by privileges of the Wiki Server application...

Vulnerable packages

• Mac OS X Server v10.5.2 (Leopard Server).
• The Wiki Server is also available for Mac OS X v10.5 (Leopard).

Non-vulnerable packages

Vendor Information, Solutions and Workarounds

Apple security updates are available via the Software Update mechanism:
http://docs.info.apple.com/article.html?artnum=106704

Apple security updates are also available for manual download via:
http://www.apple.com/support/downloads/

Cross-reference to Apple security updates:
http://docs.info.apple.com/article.html?artnum=61798

Credits

This vulnerability was discovered and researched by Rodrigo Carvalho, from the Core Security Consulting Services (CSC) team of Core Security Technologies, during Bugweek 2007. Special thanks to Norberto Kueffner for infrastructure support.

Technical Description / Proof of Concept Code

A path or directory traversal attack technique forces access to files, directories, and commands that potentially reside outside the web document root directory. An attacker may manipulate the http requests in such a way that the web site will write, execute or reveal the contents of arbitrary files outside the intended path of the web documents. Any device that exposes an HTTP-based interface is potentially vulnerable to path traversal.

In the MacOS X Server the python web server called "Wiki Server" is enabled by default and every system user has a weblog available to post articles and files. Attached files are written for example in path /Library/Collaboration/Users/guest/weblog/3f081.page/attachments/731b1/ for user guest where 3f081 are hash/random hexa characters assigned to the blog post title and 731b1 are hash/random hexa characters assigned to the file uploaded.

Next, we show a Proof of Concept (PoC) attack to the Leopard's Wiki Server. It creates a file popote.php at /tmp/[xxxxx]/ where [xxxxx] are random hexa characters assigned to the file, as we have said. You can write on all the folders where user _teamsserver, the user running the Wiki Server, has permissions.

For example, to reproduce the attack using Paros proxy [3], follow these steps:

- Check the web server is up.

- Check you have a system user/password in the system, for example guest, and the log in.

- Start editing a new post in your blog.

- Start Paros proxy, go to Trap tab and enable Trap requests checkbox.

- Start uploading your preferred file, for example popote.php.

- In Paros, press Continue until you find the POST request.

- Append ../../../../../../.. at the beginning of popote.php plus your wished path, for example /tmp/.

- Press Continue a couple of times to send the request.

- If user _teamsserver has permissions on the wished folder, you will write file popote.php inside subfolder [xxxxx], where [xxxxx] are hash/random hexa characters that depend on the file.

There are several strategies that can be used in combination with a path traversal to gain complete control of the victim's server, although we will not discuss them here.

Report Timeline

• 2008-01-30: Vendor is notified that vulnerabilities were discovered and that an advisory draft is available.
• 2008-01-31: Vendor acknowledges the notification and requests the draft.
• 2008-01-31: Core sends the draft, including the PoC http request.
• 2008-02-12: Core requests update information on the vulnerability and offers to coordinate the date of the disclosure.
• 2008-02-18: Core requests again information on the vulnerability.
• 2008-02-18: Vendor replies that the vulnerability will be fixed after the update to be released in March, and asks Core to keep the issues private until the disclosure.
• 2008-02-19: Core writes back to the Vendor confirming that the release will be coordinated unless there are clear indications of the vulnerability being exploited in the wild, in that case the advisory will be published as "forced release".
• 2008-03-03: Core requests update info on the vulnerability, a concrete schedule and text for the advisory section called "Vendor Information, Solutions and Workarounds".
• 2008-03-04: Vendor sends information to be included in advisory CORE-2008-0123 including the Vendor's updates channels, draft of Vendor's own advisory and confirmation that the path traversal affects Wiki Server as opposed to Calendar Server as said earlier by Core. The vendor believes the security update will be made publicly available on March 17th.
• 2008-03-05: Core confirms that information sent by the vendor will be keep confidential until the release of the fixed version.
• 2008-03-13: Core requests the vendor an update on the coordinated date of disclosure.
• 2008-03-13: Vendor confirms that the exact date of fix release is March 18th.
• 2008-03-14: Core acknowledges the mail with the coordinated date.
• 2008-03-18: Advisory CORE-2008-0123 is published.

References

Original Article 

Comments Index (Total Messages: 0)

Post Reply
Name:	Guest
Title:
Comment:
Enter this security word

Powered by a Zone-H(ified) version of AkoComment 3.0!