>> Multiple critical vulnerabilities in BMC Track-It! 11.4
>> Discovered by Pedro Ribeiro (pedrib@gmail.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 (EDB Mirror: https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/43883.zip)


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