BMC Track-It! version 11.4 suffers from remote code execution and credential disclosure vulnerabilities.
d6507459a64e274eb19ea9d09ebbf627Happy 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 ([email protected]), 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 >>
===============================
EXPLOIT (TrackPwn.sln):
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.30723.0
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "TrackPwn", "TrackPwn\TrackPwn.csproj", "{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Any CPU = Debug|Any CPU
Debug|x86 = Debug|x86
Release|Any CPU = Release|Any CPU
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Debug|Any CPU.Build.0 = Debug|Any CPU
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Debug|x86.ActiveCfg = Debug|x86
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Debug|x86.Build.0 = Debug|x86
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Release|Any CPU.ActiveCfg = Release|Any CPU
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Release|Any CPU.Build.0 = Release|Any CPU
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Release|x86.ActiveCfg = Release|x86
{2F2EABA8-CEBD-47D9-9858-E616039AA5A7}.Release|x86.Build.0 = Release|x86
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
===============================
ORIGINAL README FOR EXPLOIT:
Exploit for CVE-2016-6598 and CVE-2016-6599
===========================================
>> Building:
Use Visual Studio 2013 to build the exploit. Two things to have in mind:
1- Build for the x86 configuration
2- The following files from Track-It! 11.4 need to be put under the <ROOT>\lib\ directory (where ROOT is the directory where the this and the solution file are):
DevExpress.Data.v14.1.dll
DevExpress.Xpo.v14.1.dll
Iesi.Collections.dll
Interop.TrackItBiz110.dll
Ionic.Zip.dll
NHibernate.dll
TrackIt.Core.BOM.dll
TrackIt.Core.Configuration.dll
TrackIt.Core.Configuration.MultisourceConfigurationImpl.dll
TrackIt.Core.Credential.dll
TrackIt.Core.DataAccess.dll
TrackIt.Core.FileStorage.dll
TrackIt.Core.FileStorage.FileStorageImpl.dll
TrackIt.Core.Licensing.dll
TrackIt.Core.Localization.dll
TrackIt.Core.Metadata.dll
TrackIt.Core.ResourceManagement.dll
TrackIt.Core.Security.dll
TrackIt.Deployment.Common.dll
TrackIt.Framework.Component.dll
TrackIt.Framework.ErrorHandling.dll
TrackIt.Utility.CodeGeneration.dll
TrackIt.Utility.Common.dll
TrackIt.Utility.Encryption.dll
TrackIt.Utility.Filter.dll
Pedro Ribeiro
Founder and Director of Research
[email protected] / [email protected]
================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business >>