Issue
Indicates how to allocate instance types to fulfill On-Demand capacity. Creates a launch configuration. If you exceed your maximum limit of launch configurations, the call fails. For information about viewing this limit, see DescribeAccountLimits. Deploy and configure network connectivity and data center services in minutes, not weeks or months with Cyxtera Extensible Data Center platform. Transforms your IT infrastructure design, configuration, and deployment approach with software-powered, on-demand provisioning and configuration of data center network connectivity and services.
- How can GDM be configured to allow remote access via XDMCP?
- When trying to connect remotely to a server using Cygwin-X or Exceed, users are unable to get a login screen. How to configure gdm to allow remote access via XDMCP ?
Environment
- Red Hat Enterprise Linux 3
- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- GDM
- XDMCP
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
Current Customers and Partners
Log in for full access
Log InNew to Red Hat?
Exceed onDemand (EoD) is a dependable managed application access solutiondesigned for enterprises. It offers pixel perfect drawing, low costscalability 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
Summary
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.
Details
Upon connecting to Cluster Manager (TCP port 5500), EoD Client sends 4 bytes:
x01x01x00x00
, in turn CM responds with 4 bytes, negotiating the version of the protocol to use. Response from current CM version is : x0bx00x00x00
. This triggers SSL handshake (similar to STARTSSL mechanism), credentials are then sent in encrypted SSLv3 connection:Wireshark dump of the beginning of connection:
(16 03 ... bytes initiate SSL connection)
However, if the attacker modifies the response, sending e.g.
x01x01x00x00
, client will send credentials in the clear without establishing SSL connection first: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).
Access conditions
Man-in-the-middle attacker
Impact
Credentials disclosure, authentication bypass
Proof of Concept
exceed-downgrade.py
script can be used to test for and exploit that vulnerability.Recommendation
Do not allow servers to downgrade a protocol in EoD Client communication. Always require that the credentials are sent in encrypted channel.
More info
- CWE-757: Selection of Less-Secure Algorithm During Negotiation('Algorithm Downgrade') - http://cwe.mitre.org/data/definitions/319.html
Summary
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.
Details
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
.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 meansthat (if authentication is required) the communicating partiesmust authenticate to each other by some means other than TLS.
- ADH is vulnerable to man-in-the-middle attacks, as a consequenceof the lack of authentication. The parties must have a way ofdetermining whether they are participating in the same TLSconnection. If they are not, they can deduce that they are underattack, 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. Noadditional configuration is necessary.
Instead, it provides administrator with the option to set up server's certificate:
![Exceed On Demand Configuration Exceed On Demand Configuration](/uploads/1/2/5/2/125279898/213600372.jpg)
When using ciphersuites that use the Digital Signature Standard (DSS), theClient verifies the identity of the server before establishing anSSL-encrypted session. For verification, the server needs a private key fileand 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.
Access conditions
Ability to intercept and modify the TCP traffic between EoD client and ECS servers
Impact
Credentials disclosure, authentication bypass, lack of connections' confidentiality and integrity
Proof of concept
exceed-mitm.py
script can be used to test for and exploit that vulnerability.Connecting the client through this mitm proxy (e.g. by hijacking DNS entries) will reveal cleartext communication between the client and the server.
Advisory
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.
More info
- 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
Summary
Application uses trivial password obfuscation mechanism in various places
Details
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 Limited
string. - return hex-asccii encoding of XORed password
To retrieve the original password, the algorithm need to be reversed, e.g.:
Access conditions
Man in the middle / Access to
.eod8
filesImpact
Credentials disclosure
Proof of concept
exceed-mitm.py
script can be used to test for and exploit that vulnerability.Connecting client through this proxy will deobfuscate all credentials being sent.
Advisory
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.More info:
- 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
Summary
Application sends unique session identificators in cleartext, allowingthe 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.
Details
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 proxyconnections is not enabled by default. If you want to secure allsession communications (not just server log in), see “ConfiguringCluster 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:
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.
Access conditions
Ability to eavesdrop and modify TCP traffic between EoD client and EoD Proxy
Impact
Session hijacking
Proof of concept
exceed-mitm.py
script can be used to test for and exploit that vulnerability.Above command will wait for two simultaneous connections and switch their sessions.
Advisory
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.
More info
- CWE-523: Unprotected Transport of Credentials - http://cwe.mitre.org/data/definitions/523.html