Exceed onDemand (EoD) is a dependable managed application access solution designed for enterprises. It offers pixel perfect drawing, low cost scalability and trusted security access over any network connection.
Vulnerabilities are present in the current version of the software:
- Product URL: http://connectivity.opentext.com/products/exceed-ondemand.aspx
- Product Name: OpenText Exceed OnDemand 8
- Client version: <= 13.8.3.497
- Server version: <= 13.8.3.521
- Slawomir Jasek
<Slawomir dot Jasek at securing dot pl> - Krzysztof Kotowicz
<kkotowicz at securing dot pl>
- 18.11.2013 - Vendor disclosure
- 21.11.2013 - Additional vulnerabilities found & reported to vendor
- 21.11.2013 - Vendor acknowledges the report, "no further details to share"
- 06.12.1013 - Query about issue resolution & initial public disclosure date, vendor ignores
- 16.12.2013 - Full disclosure
If communication between EoD Client and Cluster Manager can be intercepted and tampered with (e.g. by using ARP poisoning/DNS hijacking/rogue access point), EoD Client can be forced to using older authentication protocol, sending out credentials in the clear.
Upon connecting to Cluster Manager (TCP port 5500), EoD Client sends 4 bytes: \x01\x01\x00\x00, in turn CM responds with 4 bytes, negotiating the version of the protocol to use. Response from current CM version is : \x0b\x00\x00\x00. This triggers SSL handshake (similar to STARTSSL mechanism), credentials are then sent in encrypted SSLv3 connection:
Wireshark dump of the beginning of connection:
00000000 01 01 00 00 ....
00000000 0b 00 00 00 ....
00000004 16 03 00 00 6d 01 00 00 69 03 00 52 8d e8 02 cf ....m... i..R....
00000014 88 d3 96 14 f4 a3 7c 47 f3 0d 85 57 58 d6 c9 f7 ......|G ...WX...
00000024 18 24 95 15 2e 05 82 27 b7 1e ff 00 00 42 00 3a .$.....' .....B.:
00000034 00 39 00 38 00 35 00 34 00 33 00 32 00 2f 00 1b .9.8.5.4 .3.2./..
00000044 00 1a 00 19 00 18 00 17 00 16 00 15 00 14 00 13 ........ ........
00000054 00 12 00 11 00 0a 00 09 00 08 00 07 00 06 00 05 ........ ........
00000064 00 04 00 03 c0 19 c0 18 c0 17 c0 16 c0 15 00 ff ........ ........
00000074 01 00 ..
(16 03 ... bytes initiate SSL connection)
However, if the attacker modifies the response, sending e.g. \x01\x01\x00\x00, client will send credentials in the clear without establishing SSL connection first:
00000000 01 01 00 00 ....
00000000 01 01 00 00 ....
00000004 11 01 30 0d 08 03 f1 00 00 00 00 00 00 00 00 00 ..0..... ........
00000014 00 ff ff 7f 00 00 01 ac 3d 08 08 68 69 6a 61 63 ........ =..hijac
00000024 6b 65 64 0a 30 35 31 45 31 45 31 41 32 36 00 01 ked.051E 1E1A26..
Exemplary bytes sent right after the 8-bytes handshake contain user login and obfuscated password. In standard connection, the same packet is sent within SSL stream.
We did not try to use Kerberos-based authentication protocol, but the attack against that will most likely be identical (instead of credentials the Kerberos ticket will be sent in the clear).
Man-in-the-middle attacker
Credentials disclosure, authentication bypass
exceed-downgrade.py script can be used to test for and exploit that vulnerability.
Do not allow servers to downgrade a protocol in EoD Client communication. Always require that the credentials are sent in encrypted channel.
- CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') - http://cwe.mitre.org/data/definitions/319.html
- http://en.wikipedia.org/wiki/Opportunistic_encryption
If communication between EoD Client and Cluster Manager can be intercepted and tampered with (e.g. by using ARP poisoning/DNS hijacking/rogue access point), communication over SSL channel can be man-in-the-middled due to using anonymous SSL ciphers.
Current version of EoD client when connecting to server side components, establishes encrypted SSL connection (with the exception of connecting to EoD Proxy, for which SSL encryption is optional and turned off by default). In SSL ClientHello message EoD client advertises several anonymous ciphers. In their default configuration EoD servers choose one of advertised anonymous SSL ciphers for encryption SSL_DH_anon_WITH_AES_256_CBC_SHA.
$ sudo ssldump -d -i eth1 tcp port 5500
New TCP connection #1: [redacted](43426) <-> eod.opentext.com(5500)
0.1783 (0.1783) C>S
---------------------------------------------------------------
01 01 00 00 ....
---------------------------------------------------------------
0.3480 (0.1697) S>C
---------------------------------------------------------------
0b 00 00 00 ....
---------------------------------------------------------------
1 1 0.3483 (0.0003) C>S Handshake
ClientHello
Version 3.0
cipher suites
SSL_DH_anon_WITH_AES_256_CBC_SHA
SSL_DHE_RSA_WITH_AES_256_CBC_SHA
SSL_DHE_DSS_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_AES_256_CBC_SHA
SSL_DH_anon_WITH_AES_128_CBC_SHA
SSL_DHE_RSA_WITH_AES_128_CBC_SHA
SSL_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_AES_128_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_WITH_IDEA_CBC_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
Unknown value 0xc019
Unknown value 0xc018
Unknown value 0xc017
Unknown value 0xc016
Unknown value 0xc015
Unknown value 0xff
compression methods
NULL
1 2 0.4896 (0.1412) S>C Handshake
ServerHello
Version 3.0
session_id[32]=
70 23 26 fb 1c a5 eb c3 28 62 d6 e1 85 41 7e 49
cf bd 69 35 26 de e3 a7 0b 3c f8 be 0a 84 8b a2
cipherSuite SSL_DH_anon_WITH_AES_256_CBC_SHA
compressionMethod NULL
Anonymous ciphers do not transfer any server certificate. As a consequence, client has no way of authenticating the server - as noted by RFC 3268:
ADH provides confidentiality but not authentication. This means that (if authentication is required) the communicating parties must authenticate to each other by some means other than TLS.
ADH is vulnerable to man-in-the-middle attacks, as a consequence of the lack of authentication. The parties must have a way of determining whether they are participating in the same TLS connection. If they are not, they can deduce that they are under attack, and presumably abort the connection.
Man-in-the-middle attacker can establish two SSL connections - one with EoD client, one with OnDemand server side components and be able to eavesdrop and tamper with the data being exchanged.
Exceed Connection Server Administrator’s Guide (v13.8) http://connectivity.opentext.com/hostedmedia/Documentation/EoD_8/Manuals/ExceedConnectionServer.pdf, page 64 (About SSL features) mentions using anonymous ciphers by default, however it does not describe the risk associated:
By default, Exceed Connection Server uses anonymous authentication. Connections to Exceed Connection Server always use SSL encryption. No additional configuration is necessary.
Instead, it provides administrator with the option to set up server's certificate:
When using ciphersuites that use the Digital Signature Standard (DSS), the Client verifies the identity of the server before establishing an SSL-encrypted session. For verification, the server needs a private key file and a certificate file.
Our investigation shows that this does not provide any form of protection at all. During standard connection, if the server provides the client with appropriate certicate and chooses non-anonymous cipher, client correctly validates the certificate and displays the warning when if differs with the one stored during the first-time connection. However, during the man-in-the-middle attack EoD client connects to attacker's SSL server instead, still offering anonymous cipher as an option. Attacker server may choose this cipher and the client will accept the connection, ignoring the certicate stored during previous connection attempts. This scenario has been tested by us with full success.
Current setup allows for transparent man-in-the-middle attacks for all connections to ECS and ESC proxies, even those using SSL FIPS mode. The attacker can observe and tamper any traffic betwen EoD client and those servers.
Ability to intercept and modify the TCP traffic between EoD client and ECS servers
Credentials disclosure, authentication bypass, lack of connections' confidentiality and integrity
exceed-mitm.py script can be used to test for and exploit that vulnerability.
$ python exceed-mitm.py --dump eod.opentext.com
Connecting the client through this mitm proxy (e.g. by hijacking DNS entries) will reveal cleartext communication between the client and the server.
Do not advertise anonymous ciphers in EoD client when establishing SSL connections. Disallow anonymous ciphers in EoD server side components (OpenSSL cipher setting: !aNULL). SSL connections must be based on authenticated ciphers, server certificate generation should be enforced during installation instead of being provided as an option.
- CWE-923: Improper Authentication of Endpoint in a Communication Channel - http://cwe.mitre.org/data/definitions/923.html
- CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle') - http://cwe.mitre.org/data/definitions/300.html
- RFC 6101: http://tools.ietf.org/html/rfc6101
- RFC 3268: http://www.ietf.org/rfc/rfc3268.txt
- http://en.wikipedia.org/wiki/Opportunistic_encryption
Application uses trivial password obfuscation mechanism in various places
Authentication message (in various versions of the protocol being transferred in-the-clear or in SSL connection) contains an obfuscated password, which can be trivially decoded by the attacker observing the transmission. The same password obfuscation mechanism is being used when storing connection parameters in .eod8 files, allowing the attacker who gets access to .eod8 files to retrieve the original passwords.
The algorithm used is:
- reverse the bytes of given password
- XOR each byte with bytes of
Hummingbird Communications Limitedstring. - return hex-asccii encoding of XORed password
To retrieve the original password, the algorithm need to be reversed, e.g.:
pwd = 0200102C
rpwd = 2C 10 00 02
"Humm" = 48 75 6d 6d
"Humm" XOR rpwd = 'demo'
Man in the middle / Access to .eod8 files
Credentials disclosure
exceed-mitm.py script can be used to test for and exploit that vulnerability.
$ python exceed-mitm.py --dump eod.opentext.com
Connecting client through this proxy will deobfuscate all credentials being sent.
In authentication protocol, consider establishing a challenge-response handshake to disallow revealing the password during man-in-the middle attacks and protect from replay attacks, where the attacker replies the authentication message without knowing the password. This can also be mitigated by using proper SSL ciphers and enforcing SSL communication. Passwords should not be stored in trivially reversible form in .eod8 files, consider storing encrypted passwords with an installation-unique or user-provided key instead.
- CWE-261: Weak Cryptography for Passwords - http://cwe.mitre.org/data/definitions/261.html
- CWE-319: Cleartext Transmission of Sensitive Information - http://cwe.mitre.org/data/definitions/319.html
Application sends unique session identificators in cleartext, allowing the attacker eavesdropping TCP traffic between EoD client to hijack the authenticated user session. This happens also if proxy server has enabled SSL encryption for connections.
EoD connection handshaking relies on three TCP connections. First connection authenticates the user in Cluster Manager (this is SSL encrypted). Second connection (also SSL encrypted) provides the client with session id - 20 bytes alphanumeric identificator. Third TCP connection is with EoD Proxy. This connection is by default unencrypted as mentioned in Exceed Connection Server Administrator’s Guide (v13.8) - http://connectivity.opentext.com/hostedmedia/Documentation/EoD_8/Manuals/ExceedConnectionServer.pdf, page 64 (About SSL features):
The option to enable SSL encryption for proxy connections is not enabled by default. If you want to secure all session communications (not just server log in), see “Configuring Cluster Settings” on page 18.
However, even if the connection switches to SSL negotiation, session identifier is sent in cleartext before the SSL handshake begins. Therefore it is possible to read the authenticated session identifier even without decrypting SSL traffic.
Example: Beginning of the proxy server traffic:
00000000 04 01 00 00 ....
00000000 09 00 00 00 ....
00000004 4c 41 39 30 34 46 36 43 31 35 45 30 35 32 38 44 LA904F6C 15E0528D
00000014 45 36 32 43 E62C
LA904F6C15E0528DE62C is the session id sent in cleartext.
Using this session identifier the atttacker can connect to EoD proxy server directly, skipping the authentication part.
Our investigation shows that the session hijack has to occur during a short time-window. Within a few seconds from obtaining the session id, original user must be disconnected (e.g. by changing his session id in-traffic to a dummy one) and his session id must be used by the attacker. We were able to prepare a proof-of-concept where two simultaneous connections were made with EoD server with separate EoD clients, their session identifiers were read from the cleartext traffic and switched. As a result, users got each other's sessions.
Ability to eavesdrop and modify TCP traffic between EoD client and EoD Proxy
Session hijacking
exceed-mitm.py script can be used to test for and exploit that vulnerability.
$ python exceed-mitm.py --nossl --hijack eod.opentext.com
Above command will wait for two simultaneous connections and switch their sessions.
SSL encryption of proxy connection should be enabled by default. Protocol needs to be changed to send session id in encrypted part of the connections.
- CWE-523: Unprotected Transport of Credentials - http://cwe.mitre.org/data/definitions/523.html