Message-ID: <CAEDdjHe58zrOSe0wNZ6B_s9Zecj0_Qp9w=A10VhO88BFePyxUw@mail.gmail.com>
Date: Fri, 26 Jan 2018 15:27:00 +0700
From: Pedro Ribeiro <pedrib@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] [CVE-2016-6598/9]: RCE and admin cred disclosure in BMC
	Track-It! 11.4

Happy new year!

I was doing some new year cleaning and realised I never released this
advisory properly. Two vulnerabilities in BMC Track-It! 11.4 which were
disclosed by SecuriTeam Secure Disclosure on July 2016.

Posting here because I've seen quite a few of these still in active use,
live and deployed in corporate networks.
The exploit is available in my repo at [3]. It's also interesting to see
how they completely ignored my advice, but I'm used to that. Here it is
in full glory for your reading pleasure.

This advisory and exploit can also be fetched at my github repo
(https://github.com/pedrib/PoC) and in the SSD blog at
https://blogs.securiteam.com/index.php/archives/2713. A big thanks to
SecuriTeam for helping out as always.

>> Multiple critical vulnerabilities in BMC Track-It! 11.4
>> Discovered by Pedro Ribeiro (pedrib@...il.com), Agile Information
Security
============================================================
=====================
Disclosure: 04/07/2016 / Last updated: 01/01/2017


>> Background and summary
BMC Track-It! exposes several .NET remoting services on port 9010. .NET
remoting is a remote method technology similar to Java RMI or CORBA
which allows you to invoke methods remotely and retrieve their result.

These remote methods are used when a technician uses the Track-It!
client console to communicate with the central Track-It! server. A
technician would invoke these methods for obtaining tickets, creating a
new ticket, uploading files to tickets, etc.

On October 2014, two 0 day vulnerabilities for Track-It! 11.3 were
disclosed (under CVE-2014-4872, see [1]). The vulnerabilities were due
to the Track-It! server accepting remote method invocations without any
kind of authentication or encryption. The vulnerabilities were very
severe: one allowed an attacker to execute code on the server as NETWORK
SERVICE or SYSTEM, while the other would allow an attacker to obtain the
domain administrator and SQL server passwords if the Track-It! server
had password reset turned on.

These vulnerabilities were discovered in a trivial manner - simply by
turning Wireshark on and observing the packets one could see the remote
method invocations and objects being passed around. Duplicate and even
triplicate packets would not be rejected by the server, which would
execute whatever action was requested in the packet.

Disclosure was done by the US-CERT, which attempted to contact BMC but
received no response after 45 days. After this period they released the
vulnerability information and I released two Metasploit exploits.

BMC contacted me asking for advice on how to fix the issues, to which I
responded:
"For #1 [file upload] and #2 [domain admin pass disclosure] the fix is
to implement authentication and authorisation. There is no other way to
fix it.
[...] Make sure the auth is done properly. You will have to negotiate
some kind of session key using the user's credential at the start and
use that session key for encryption going forward. Do not use a fixed
key, as this can be reverse engineered.
If you don't implement such mechanism, it's just a question of time
before someone else breaks your protection and finds new vulnerabilities."

On December 9th 2014, BMC released Track-It! 11.4 [2], which they
claimed had fixed the security vulnerabilities.

At first glance, this seemed to be true. Traffic in Wireshark did seem
to be encrypted. However upon further inspection, it became obvious that
while the actual method invocation and its arguments were being
encrypted using a DES key, there was still no authentication being done.
What this means in practice is that anyone can negotiate a new
encryption key with the server and use that from then on to invoke
remote methods without ever authenticating to the server, even for the
initial encryption key exchange.

The code can be inspected by decompiling TrackIt.Utility.Common.dll. The
interesting part is in:
namespace TrackIt.Utility.Common.Remoting
{
    internal enum SecureTransaction
    {
        Uninitialized,
        SendingPublicKey,
        SendingSharedKey,
        SendingEncryptedMessage,
        SendingEncryptedResult,
        UnknownIdentifier,
        UnauthenticatedClient
    }
}
This represents the state machine that the server uses to track client
requests. The initial state is UnauthenticatedClient for any unknown
client. A typical communication would be as follows:
1- Client generates a RSA key, which it shares with the server by
sending a Modulus and an Exponent.
2- Server creates a DES key and sends that key back to the client
3- Client and server now share an encryption key; that key is used to
pass back messages back and forth (states SendingEncryptedMessage and
SendingEncryptedResult).

As it is evident, at no point there is any authentication or credentials
being passed from the client to the server. So while all traffic is
encrypted, anyone can negotiate an encryption key with the server and
invoke any remote method.

>From here on, building an exploit is trivial. All that is needed is to
import the library DLL's from the Track-It! client application and
invoke the methods in the code.

A special thanks to SecuriTeam Secure Disclosure (SSD), which have
assisted me in disclosing this vulnerability to BMC. Their advisory can
be found at https://blogs.securiteam.com/index.php/archives/2713.

Exploit code for this vulnerability has been released, and can be found
in the same github repository as this advisory [3].


>> Technical details:
#1
Vulnerability: Remote code execution via file upload
CVE-2016-6598
Attack Vector: Remote
Constraints: None; exploitable by an unauthenticated attacker
Affected versions: 11.4 (versions <= 11.3 are affected by CVE-2014-4872,
which is very similar)

The application exposes an unauthenticated .NET remoting file storage
service (FileStorageService) on port 9010.
This service contains a method that allows uploading a file to an
arbitrary path on the machine that is running Track-It!. This can be
used to upload a file to the web root and achieve code execution as
NETWORK SERVICE or SYSTEM.


#2
Vulnerability: Domain administrator and SQL server user credentials
disclosure
CVE-2016-6599
Attack Vector: Remote
Constraints: None; exploitable by an unauthenticated attacker
Affected versions: 11.4 (versions <= 11.3 are affected by CVE-2014-4872,
which is very similar)

The application exposes an unauthenticated .NET remoting configuration
service (ConfigurationService) on port 9010.
This service contains a method that can be used to retrieve a
configuration file that contains the application database name, username
and password as well as the domain administrator username and password.
These are encrypted with a fixed key and IV ("NumaraIT") using the DES
algorithm. The domain administrator username and password can only be
obtained if the Self-Service component is enabled, which is the most
common scenario in enterprise deployments.


>> Fix:
Upgrade to BMC Track-It! 11.5 or above.


>> References:
[1]
https://raw.githubusercontent.com/pedrib/PoC/master/
advisories/bmc-track-it-11.3.txt
[2]
https://communities.bmc.com/community/bmcdn/bmc_track-it/
blog/2014/12/09/track-it-114-is-now-available
[3] https://github.com/pedrib/PoC/tree/master/exploits/TrackPwn


================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists