{"id":13827359,"url":"https://github.com/koto/exceed-mitm","last_synced_at":"2026-06-16T03:31:45.595Z","repository":{"id":12560985,"uuid":"15231362","full_name":"koto/exceed-mitm","owner":"koto","description":"Exceed OnDemand MITM proof-of-concept ","archived":false,"fork":false,"pushed_at":"2013-12-16T17:43:48.000Z","size":120,"stargazers_count":3,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-02-23T14:46:14.401Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/koto.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2013-12-16T16:48:29.000Z","updated_at":"2022-09-22T13:43:24.000Z","dependencies_parsed_at":"2022-09-05T10:51:20.503Z","dependency_job_id":null,"html_url":"https://github.com/koto/exceed-mitm","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/koto/exceed-mitm","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/koto%2Fexceed-mitm","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/koto%2Fexceed-mitm/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/koto%2Fexceed-mitm/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/koto%2Fexceed-mitm/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/koto","download_url":"https://codeload.github.com/koto/exceed-mitm/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/koto%2Fexceed-mitm/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34390052,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-16T02:00:06.860Z","response_time":126,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-04T09:01:54.613Z","updated_at":"2026-06-16T03:31:45.577Z","avatar_url":"https://github.com/koto.png","language":"Python","funding_links":[],"categories":["\u003ca id=\"42f9e068b6511bcbb47d6b2b273097da\"\u003e\u003c/a\u003e未分类"],"sub_categories":["\u003ca id=\"3bd67ee9f322e2c85854991c85ed6da0\"\u003e\u003c/a\u003e投毒\u0026\u0026Poisoning"],"readme":"Exceed onDemand (EoD) is a dependable managed application access solution\r\ndesigned for enterprises. It offers pixel perfect drawing, low cost\r\nscalability and trusted security access over any network connection.\r\n\r\nVulnerabilities are present in the current version of the software:\r\n\r\n - Product URL: http://connectivity.opentext.com/products/exceed-ondemand.aspx\r\n - Product Name: **OpenText Exceed OnDemand 8**\r\n - Client version: \u003c= **13.8.3.497**\r\n - Server version: \u003c= **13.8.3.521**\r\n\r\nCredits\r\n=====\r\n  - Slawomir Jasek `\u003cSlawomir dot Jasek at securing dot pl\u003e`\r\n  - Krzysztof Kotowicz `\u003ckkotowicz at securing dot pl\u003e`\r\n\r\nDates\r\n=====\r\n - 18.11.2013 - Vendor disclosure\r\n - 21.11.2013 - Additional vulnerabilities found \u0026 reported to vendor \r\n - 21.11.2013 - Vendor acknowledges the report, \"no further details to share\"\r\n - 06.12.1013 - Query about issue resolution \u0026 initial public disclosure date, vendor ignores\r\n - 16.12.2013 - Full disclosure\r\n\r\nAuthentication bypass due to protocol downgrade (CVE-2013-6806)\r\n===============================================================\r\n\r\nSummary \r\n-------\r\nIf 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.\r\n\r\nDetails\r\n-------\r\nUpon 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:\r\n\r\nWireshark dump of the beginning of connection:\r\n\r\n    00000000  01 01 00 00                                      ....\r\n        00000000  0b 00 00 00                                      ....\r\n    00000004  16 03 00 00 6d 01 00 00  69 03 00 52 8d e8 02 cf ....m... i..R....\r\n    00000014  88 d3 96 14 f4 a3 7c 47  f3 0d 85 57 58 d6 c9 f7 ......|G ...WX...\r\n    00000024  18 24 95 15 2e 05 82 27  b7 1e ff 00 00 42 00 3a .$.....' .....B.:\r\n    00000034  00 39 00 38 00 35 00 34  00 33 00 32 00 2f 00 1b .9.8.5.4 .3.2./..\r\n    00000044  00 1a 00 19 00 18 00 17  00 16 00 15 00 14 00 13 ........ ........\r\n    00000054  00 12 00 11 00 0a 00 09  00 08 00 07 00 06 00 05 ........ ........\r\n    00000064  00 04 00 03 c0 19 c0 18  c0 17 c0 16 c0 15 00 ff ........ ........\r\n    00000074  01 00                                            ..\r\n\r\n(16 03 ... bytes initiate SSL connection) \r\n\r\nHowever, 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:\r\n\r\n    00000000  01 01 00 00                                      ....\r\n        00000000  01 01 00 00                                      ....\r\n    00000004  11 01 30 0d 08 03 f1 00  00 00 00 00 00 00 00 00 ..0..... ........\r\n    00000014  00 ff ff 7f 00 00 01 ac  3d 08 08 68 69 6a 61 63 ........ =..hijac\r\n    00000024  6b 65 64 0a 30 35 31 45  31 45 31 41 32 36 00 01 ked.051E 1E1A26..\r\n\r\nExemplary 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.\r\n\r\nWe 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).\r\n\r\nAccess conditions\r\n---------------------------\r\nMan-in-the-middle attacker\r\n\r\nImpact\r\n----------\r\nCredentials disclosure, authentication bypass\r\n\r\nProof of Concept\r\n------------------------\r\n`exceed-downgrade.py` script can be used to test for and exploit that vulnerability.\r\n\r\nRecommendation\r\n-------------------------\r\nDo not allow servers to downgrade a protocol in EoD Client communication. Always require that the credentials are sent in encrypted channel.\r\n\r\nMore info\r\n-------------\r\n  - CWE-757: Selection of Less-Secure Algorithm During Negotiation\r\n('Algorithm Downgrade') - http://cwe.mitre.org/data/definitions/319.html\r\n  - http://en.wikipedia.org/wiki/Opportunistic_encryption\r\n\r\n\r\nMan in the Middle vulnerability (CVE-2013-6807)\r\n============================================\r\n\r\nSummary \r\n-------\r\nIf 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.\r\n\r\nDetails\r\n-------\r\nCurrent 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`.\r\n\r\n    $ sudo ssldump -d -i eth1 tcp port 5500\r\n    New TCP connection #1: [redacted](43426) \u003c-\u003e eod.opentext.com(5500)\r\n    0.1783 (0.1783)  C\u003eS\r\n    ---------------------------------------------------------------\r\n    01 01 00 00                                        ....\r\n    ---------------------------------------------------------------\r\n\r\n    0.3480 (0.1697)  S\u003eC\r\n    ---------------------------------------------------------------\r\n    0b 00 00 00                                        ....\r\n    ---------------------------------------------------------------\r\n\r\n    1 1  0.3483 (0.0003)  C\u003eS  Handshake\r\n          ClientHello\r\n            Version 3.0 \r\n            cipher suites\r\n            SSL_DH_anon_WITH_AES_256_CBC_SHA\r\n            SSL_DHE_RSA_WITH_AES_256_CBC_SHA\r\n            SSL_DHE_DSS_WITH_AES_256_CBC_SHA\r\n            SSL_RSA_WITH_AES_256_CBC_SHA\r\n            SSL_DH_anon_WITH_AES_128_CBC_SHA\r\n            SSL_DHE_RSA_WITH_AES_128_CBC_SHA\r\n            SSL_DHE_DSS_WITH_AES_128_CBC_SHA\r\n            SSL_RSA_WITH_AES_128_CBC_SHA\r\n            SSL_DH_anon_WITH_3DES_EDE_CBC_SHA\r\n            SSL_DH_anon_WITH_DES_CBC_SHA\r\n            SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA\r\n            SSL_DH_anon_WITH_RC4_128_MD5\r\n            SSL_DH_anon_EXPORT_WITH_RC4_40_MD5\r\n            SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA\r\n            SSL_DHE_RSA_WITH_DES_CBC_SHA\r\n            SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\r\n            SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA\r\n            SSL_DHE_DSS_WITH_DES_CBC_SHA\r\n            SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA\r\n            SSL_RSA_WITH_3DES_EDE_CBC_SHA\r\n            SSL_RSA_WITH_DES_CBC_SHA\r\n            SSL_RSA_EXPORT_WITH_DES40_CBC_SHA\r\n            SSL_RSA_WITH_IDEA_CBC_SHA\r\n            SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5\r\n            SSL_RSA_WITH_RC4_128_SHA\r\n            SSL_RSA_WITH_RC4_128_MD5\r\n            SSL_RSA_EXPORT_WITH_RC4_40_MD5\r\n            Unknown value 0xc019\r\n            Unknown value 0xc018\r\n            Unknown value 0xc017\r\n            Unknown value 0xc016\r\n            Unknown value 0xc015\r\n            Unknown value 0xff\r\n            compression methods\r\n                      NULL\r\n    1 2  0.4896 (0.1412)  S\u003eC  Handshake\r\n          ServerHello\r\n            Version 3.0 \r\n            session_id[32]=\r\n              70 23 26 fb 1c a5 eb c3 28 62 d6 e1 85 41 7e 49 \r\n              cf bd 69 35 26 de e3 a7 0b 3c f8 be 0a 84 8b a2 \r\n            cipherSuite         SSL_DH_anon_WITH_AES_256_CBC_SHA\r\n            compressionMethod                   NULL\r\n\r\nAnonymous ciphers do not transfer any server certificate. As a consequence, client has no way of authenticating the server - as noted by RFC 3268:\r\n\r\n\u003e   1. ADH provides confidentiality but not authentication.  This means\r\n\u003e     that (if authentication is required) the communicating parties\r\n\u003e      must authenticate to each other by some means other than TLS.\r\n\u003e\r\n\u003e   2. ADH is vulnerable to man-in-the-middle attacks, as a consequence\r\n\u003e      of the lack of authentication.  The parties must have a way of\r\n\u003e     determining whether they are participating in the same TLS\r\n\u003e      connection.  If they are not, they can deduce that they are under\r\n\u003e      attack, and presumably abort the connection.\r\n\r\nMan-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.\r\n\r\nExceed Connection Server Administrator’s Guide (v13.8)\r\nhttp://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:\r\n\r\n\u003e  By default, Exceed Connection Server uses anonymous authentication.\r\n\u003e  Connections to Exceed Connection Server always use SSL encryption. No\r\n\u003e  additional configuration is necessary. \r\n\r\nInstead, it provides administrator with the option to set up server's certificate:\r\n\r\n\u003e  When using ciphersuites that use the Digital Signature Standard (DSS), the\r\n\u003e  Client verifies the identity of the server before establishing an\r\n\u003e  SSL-encrypted session. For verification, the server needs a private key file\r\n\u003e  and a certificate file. \r\n\r\nOur investigation shows that this does not provide any form of protection at all.\r\nDuring 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.\r\n\r\nCurrent 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.\r\n\r\nAccess conditions\r\n------------------\r\nAbility to intercept and modify the TCP traffic between EoD client and ECS servers\r\n\r\nImpact\r\n------\r\nCredentials disclosure, authentication bypass, lack of connections' confidentiality and integrity\r\n\r\nProof of concept\r\n------------------------\r\n`exceed-mitm.py` script can be used to test for and exploit that vulnerability.\r\n    \r\n    $ python exceed-mitm.py --dump eod.opentext.com\r\n\r\nConnecting the client through this mitm proxy (e.g. by hijacking DNS entries) will reveal cleartext communication between the client and the server.\r\n\r\nAdvisory\r\n--------\r\nDo 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.\r\n\r\nMore info\r\n----------\r\n  - CWE-923: Improper Authentication of Endpoint in a Communication Channel - http://cwe.mitre.org/data/definitions/923.html\r\n  - CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle') - http://cwe.mitre.org/data/definitions/300.html\r\n  - RFC 6101: http://tools.ietf.org/html/rfc6101\r\n  - RFC 3268: http://www.ietf.org/rfc/rfc3268.txt\r\n  - http://en.wikipedia.org/wiki/Opportunistic_encryption\r\n\r\nUse of password obfuscation (CVE-2013-6805)\r\n===========================================\r\n\r\nSummary\r\n-------\r\nApplication uses trivial password obfuscation mechanism in various places\r\n\r\n\r\nDetails\r\n-------\r\nAuthentication 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.\r\n\r\nThe algorithm used is:\r\n\r\n  1. reverse the bytes of given password\r\n  2. XOR each byte with bytes of `Hummingbird Communications Limited` string.\r\n  3. return hex-asccii encoding of XORed password\r\n\r\nTo retrieve the original password, the algorithm need to be reversed, e.g.:\r\n\r\n    pwd = 0200102C\r\n    rpwd = 2C 10 00 02\r\n    \"Humm\" = 48 75 6d 6d\r\n    \"Humm\" XOR rpwd = 'demo'\r\n\r\nAccess conditions\r\n-----------------\r\nMan in the middle / Access to `.eod8` files\r\n\r\nImpact\r\n------\r\nCredentials disclosure\r\n\r\nProof of concept\r\n------------------------\r\n`exceed-mitm.py` script can be used to test for and exploit that vulnerability.\r\n    \r\n    $ python exceed-mitm.py --dump eod.opentext.com\r\n\r\nConnecting client through this proxy will deobfuscate all credentials being sent. \r\n\r\nAdvisory\r\n--------\r\nIn 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.\r\n\r\nMore info:\r\n----------\r\n- CWE-261: Weak Cryptography for Passwords - http://cwe.mitre.org/data/definitions/261.html\r\n- CWE-319: Cleartext Transmission of Sensitive Information - http://cwe.mitre.org/data/definitions/319.html\r\n\r\n\r\nSession hijacking (CVE 2013-6994)\r\n=================================\r\n\r\nSummary\r\n-------\r\nApplication sends unique session identificators in cleartext, allowing\r\nthe 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.\r\n\r\nDetails\r\n-------\r\nEoD 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):\r\n\r\n\u003e  The option to enable SSL encryption for proxy\r\n\u003e  connections is not enabled by default. If you want to secure all\r\n\u003e  session communications (not just server log in), see “Configuring\r\n\u003e  Cluster Settings” on page 18.\r\n\r\nHowever, 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.\r\n\r\nExample: Beginning of the proxy server traffic:\r\n\r\n    00000000  04 01 00 00                                      ....\r\n        00000000  09 00 00 00                                      ....\r\n    00000004  4c 41 39 30 34 46 36 43  31 35 45 30 35 32 38 44 LA904F6C 15E0528D\r\n    00000014  45 36 32 43                                      E62C\r\n\r\n`LA904F6C15E0528DE62C` is the session id sent in cleartext.\r\n\r\nUsing this session identifier the atttacker can connect to EoD proxy server directly, skipping the authentication part.\r\n\r\nOur 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. \r\n\r\nAccess conditions\r\n-----------------\r\nAbility to eavesdrop and modify TCP traffic between EoD client and EoD Proxy\r\n\r\nImpact\r\n------\r\nSession hijacking\r\n\r\nProof of concept\r\n------------------------\r\n`exceed-mitm.py` script can be used to test for and exploit that vulnerability.\r\n    \r\n    $ python exceed-mitm.py --nossl --hijack eod.opentext.com\r\n\r\nAbove command will wait for two simultaneous connections and switch their sessions. \r\n\r\nAdvisory\r\n--------\r\nSSL encryption of proxy connection should be enabled by default. Protocol needs to be changed to send session id in encrypted part of the connections.\r\n\r\nMore info\r\n---------\r\n  - CWE-523: Unprotected Transport of Credentials - http://cwe.mitre.org/data/definitions/523.html","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkoto%2Fexceed-mitm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkoto%2Fexceed-mitm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkoto%2Fexceed-mitm/lists"}