-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ~ Core Security Technologies - CoreLabs Advisory ~ http://www.coresecurity.com/corelabs/ ~ CitectSCADA ODBC service vulnerability *Advisory Information* Title: CitectSCADA ODBC service vulnerability Advisory ID: CORE-2008-0125 Advisory URL: http://www.coresecurity.com/?action=item&id=2186 Date published: 2008-06-11 Date of last update: 2008-06-10 Vendors contacted: Citect Release mode: Coordinated release *Vulnerability Information* Class: Buffer overflow Remotely Exploitable: Yes Locally Exploitable: Yes Bugtraq ID: 29634 CVE Name: CVE-2008-2639 *Vulnerability Description* Citect is a supplier of industrial automation software with headquarters in Australia and over 20 offices in Oceania, South East Asia, China, Japan, the Americas, Europe, Africa and the Middle East. Citect's products are distributed in over 80 countries through a network of more than 500 partners. According to Citect's website [1] the company, a fully owned subsidiary of Schneider Electric, has more than 150,000 licenses of its software sold to date. Citect's products are used by organizations worldwide in numerous industries including Aerospace & Defense, Oil & Gas, Power/Utilities, Chemical, Pharmaceutical, Manufacturing and others. CitectSCADA (Supervisory Control and Data Acquisition) is a system with the primary function of collecting data and providing an interface to control equipment such as Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs) etc. with an integrated Human Machine Interface (HMI) / SCADA solution to deliver a scalable and reliable control and monitoring system. The system is composed by software installed on standard computer equipment running on commercial-of-the-shelf Microsoft Windows operating systems. A vulnerability was found in CitectSCADA that could allow a remote un-authenticated attacker to force an abnormal termination of the vulnerable software (Denial of Service) or to execute arbitrary code on vulnerable systems to gain complete control of the software. To accomplish such goal the would-be attacker must be able to connect to the vulnerable service on a TCP high-port. *Vulnerable Packages* . CitectSCADA v6 . CitectSCADA v7 . CitectFacilities v7 *Non-vulnerable Packages* . Contact the vendor for fixed versions of the product. *Vendor Information, Solutions and Workarounds* In general process control networks should be physically isolated from corporate or other publicly accessible data networks as such an isolated network will limit the exposure of systems with network facing vulnerabilities only to accidental disruption or potentially malicious users or systems within the process control network itself. However, if physical isolation of the process control network is not feasible it is strongly recommended to enforce and monitor strict network access control mechanisms to verify that only the absolute minimal required set of systems from both within and outside the process control network are allowed to connect to any systems within the process control network. In this particular case, access control mechanisms on both end-systems and network boundary devices such as firewalls and IPSes must ensure that only hardened and trusted systems from that minimal set can connect to systems in the process control network running potentially vulnerable software. Nonetheless systems on that minimal set must still be considered potential attack vectors into the process control network and should they become compromised, providers of transitive trust from the process control network to external untrusted systems. Besides the recommendation of a secure network architecture with strict network access control measures, OS hardening and other sound system administration practices a specific workaround for the vulnerability reported in this advisory is provided below. The vulnerability is located in the ODBC server service, vulnerable organizations that do not require ODBC connectivity may disable the service with no adverse effects to the CitectSCADA software. Installations that require ODBC connectivity to SQL databases, spreadsheets, etc. will suffer loss of connection with ODBC data sources if this workaround is applied. Vulnerable organizations should obtain positive verification that ODBC connectivity is not necessary in their installation and prepare appropriate contingency procedures before the workaround is applied. Vendor statement: CitectSCADA is not designed to be accessible on public networks and recommends that the SCADA and control networks be protected by firewall or similar on live sites. The system must be network hardened regardless of the corrupt packet software change to ensure a secure system given the likelihood that on the same network are open industry standard protocol devices perhaps communicating via ethernet. Please follow this link on Citect website under "Industries and Solutions" for security, that provides some information for customers interested in securing their SCADA systems: http://www.citect.com/index.php?option=com_content&task=view&id=186&Item id=322 *Credits* This vulnerability was discovered and researched by Sebastian Muñiz from the Core IMPACT Exploit Writers Team (EWT) at Core Security Technologies. Exploitation was further investigated by Nicolas Economou also from the Core IMPACT Exploit Writers Team (EWT). Core would also like to thank Paul Fahey of AusCERT, Gaston Franco and Patricia Prandini of ArCERT and Art Manion and Chris Taschner of CERT/CC for their assistance during the vulnerability reporting process. *Technical Description / Proof of Concept Code* The CitectSCADA and CitectFacilities applications include ODBC server capabilities to provide remote SQL access to a relational database. The ODBC Server component listens on port 20222/tcp by default to service requests from clients on TCP/IP networks. The application layer protocol used over TCP reads an initial packet of 4 bytes that specifies the length of data that follows in the next packet. A second packet of that length with a 5-byte fixed header is then read from the same TCP socket. Once this second packet is read from the network into a buffer, the data it is then copied to an internal buffer of fixed size allocated in the stack. Due to a lack of a proper length checking of the read data, a memory copy operation that uses as destination a buffer of fixed size allocated in the stack can be overflowed allowing an un-authenticated attacker to execute arbitrary code on vulnerable systems. This bug is a textbook example of a classic stack-based buffer overflow that can be exploited by overwriting the return address of the currently running thread. The following binary excerpt shows the nature of the problem: /----------- ~ .text:0051BC33 loc_51BC33: ~ .text:0051BC33 lea ecx, [ebp+pDestBuffer] ~ .text:0051BC39 push ecx ; stack based buffer ~ .text:0051BC3A mov edx, [ebp+arg_0] ~ .text:0051BC3D push edx ; class that contains packet ~ .text:0051BC3E call sub_52125A ; memcpy - -----------/ *Report Timeline* . 2008-01-30: Initial contact mail sent by Core to Citect's support team. . 2008-01-30: Additional mail sent to Citect support team asking for a software security contact at Citect. . 2008-01-30: Email from Citect's support team acknowledging notification and requesting information in plaintext. . 2008-02-06: Core sends the draft advisory, including proof of concept code to demonstrate the vulnerability. . 2008-02-28: Core requests a response from the vendor and asks for the vendor's plan to release fixes to vulnerable products. . 2008-03-06: Email from the vendor's technical architect confirms reception of the report and indicating that there are not concerns around publication of a security advisory disclosing the vulnerability. The vendor asks for a phone conference to ensure that both Core and Citect have a common understanding of the issue and expresses the possibility of adding additional information to the advisory. The vendor also states that it will formulate a plan for handling this issue. . 2008-03-12: Core asks to continue the discussion concerning the vulnerability by mail so as to have all the involved parties informed simultaneously and all communications documented. Core requests confirmation that the vendor has been able to reproduce the vulnerability and requests details concerning the plan to release fixes and asks for the additional information that the vendor would like to include in the advisory (in the "vendor information" section). Core reminds the vendor that the original publication date of the advisory was February 25th and states that the publication of the advisory is now re-scheduled to March 24th because fixed versions were not available at the date initially scheduled. . 2008-03-25: Vendor confirms that it reproduced and identified the vulnerability and indicates that the official stance is that CitectSCADA is not designed to be accessible on public networks and recommends that SCADA and control networks are protected by firewalls and other security measures on live sites. The vendor also states that it has no immediate plans to support CitectSCADA on public networks but is investigating the possibility of having a security audit of the product. . 2008-03-25: Core notifies the vendor the intention to release the advisory on March 26th given that the vendor has no immediate plans for fixing the vulnerability. . 2008-03-26: Core consults under NDA with a process control security expert to obtain a better understanding of the scope and impact of the vulnerability. The specific technical details about the vulnerability are not disclosed, only the general type of bug and the specific TCP port on which the vulnerable service listens are discussed. . 2008-04-02: Core revisits its current plan to disclose the vulnerability and decides to get Computer Emergency Response Teams (CERTs) involved in the process. Core notifies the vendor that it will postpone the publication of the advisory, and that it will contact the Computer Emergency Response Teams (CERTs) of countries were Core has physical offices (Argentina and USA) and the country were Citect has its headquarters (Australia). Core will then determine the contents and date of publication for the security advisory based on further communication with the vendor and CERTs and more precise details that the vendor may provide regarding availability of fixes. . 2008-04-02: Core notifies the vendor that it will contact the CERTs of Australia, USA and Argentina. Core reminds the vendor that the vulnerability reported is a classic example of a stack-based buffer overflow bug trivial to exploit in present times and that although the previous email from the vendor provided a vague statement indicating that "the scenario is under consideration for the next release", to date there has not been any concrete details about development and release of fixes or a firm commitment to any specific date to release them. . 2008-04-08: Core sends an initial notification to AusCERT, CERT/CC and ArCert including a draft advisory describing the bug and the vendor's contact information, requesting an acknowledgement within 2 working days. . 2008-04-08: AusCERT acknowledges reception of the advisory . 2008-04-09: ArCERT acknowledges reception of the advisory . 2008-04-10: CERT/CC acknowledges reception of the advisory on a phone call . 2008-04-10: AusCERT notifies Core that so far it has not been able to contact the vendor and asks for approval to disseminate the information to the Australian government and other national and international entities overlooking national infrastructure security. AusCERT also asks if CORE intends to publish the advisory and if so requests some time to be able to notify affected organizations. Meanwhile AusCERT indicates that it will continue to try to work with the vendor. . 2008-04-10: Core responds that it has no problems with AusCERT notifying other parties that may be able to better prepare risk mitigation procedures and/or work more closely with the vendor towards development and release of a fix. However, Core asks to keep the dissemination of the information to a minimum in order to avoid a potential leak. Core indicates that it has asked the vendor to provide concrete details about how and when it plans to address the issue and that based on the response to that question it will determine a publication date for the security advisory. Lacking a response from the vendor, Core will determine the publication date based on the feedback received from the CERTs and the progress of their preparations to address the report. . 2008-04-10: AusCERT asks if it is ok to contact other CERTs and international government communities to make them aware of the issue and to ensure everyone is prepared when the report is published. . 2008-04-10: Core response indicating that it is ok to contact any organization that AusCERT deems relevant for the stated purpose . 2008-04-10: ArCert reports that it will start gathering information about appropriate organizations in Argentina to report the problem and start contacting them. . 2008-04-11: CERT/CC reports that US-CERT has been made aware of the issue and will be kept updated going forward. If AusCERT is already in contact with the vendor CERT/CC will standby and follow AusCERT's lead. . 2008-04-14: AusCERT reports that after several communication attempts the vendor said that it will address the issue in the next release of the product (by mid-year) and release a patch in a couple of months. However, the information is not to be considered an official statement and there is no official indication of a plan to provide immediate resolution. . 2008-04-14: CERT/CC asks if Core will publish the advisory before mid-year and states concerns about the potential time elapsed between advisory publication and release of the fix. CERT/CC will likely put out information soon after Core does and expresses its interest to receive more information from the vendor regarding their response plan. . 2008-04-14: AusCERT notes that Core has given the CERTs the time to notify possibly affected organizations before the report is published and requests any specific questions to be asked to the vendor. . 2008-04-14: Core states that it is entirely possible to re-visit the publication date of the report (which has been done twice so far) but to do so Core requires concrete details and a committed date for the release of a fix noting that it wasn't until AusCERT's email from April 14th that the possibility that the vendor would release of a patch seemed realistic. Core is willing to postpone publication of the report provided that the vendor commits to release a fix no later than June 30th (the upper bound to the promised mid-year deadline indicated by the vendor). Core also reminds the CERTs that its intent in notifying them of the bug was to help to coordinate a way to address the bug should an official patch or fix is not made available by the vendor. . 2008-04-24: Core sends an email to the 3 CERTs requesting a status update and any further details about the availability of fixes. Core would like to set a final date for the publication of its report. . 2008-04-28: AusCERT indicates that after several calls and messages, the vendor has stated that it does not publish specific release schedules for updates and does not indicate what will or will not be their contents and that once a release is finalized all relevant materials are updated to reflect that fact. AusCERT asks about Core's plans regarding the issue. . 2008-04-28: CERT/CC suggests that in light of the vendor statement one last effort should be attempted, setting a date for publication one or two weeks into the future and presenting the final drafts of the report to the vendor. . 2008-04-28: Core sets the advisory publication date to May 12th and indicates to the three CERTs that the date is considered final unless concrete details about a patch release schedule are communicated no later than May 8th. The vendor has already been sent drafts of the advisory, the last one sent on March 25th, and Core has little confidence that the current status process will change in a positive manner. Core will consider the time up to May 12th as a period to finalize the preparation of guidance documents about how to deal with the issue without an official fix available. Should such a document be provided, Core is willing and open to include its recommendations in the security advisory. . 2008-05-06: Core informs the CERTs that it is still editing its security advisory and that once the final draft is ready it will be sent for review to the vendor and the CERTs before it is published. Core informs that it will also issue a press release disclosing the issue and invites spokesmen from any of the CERTs to participate with a quote should they want to do so. . 2008-05-08: CERT/CC acknowledges Core's email and thanks for the update indicating that it will not participate in a press release. . 2008-05-14: Core sends its final draft of the security advisory to Citect and the 3 CERTs indicating that the publication date is set to May 19th, 2008 at approximately 3pm UTC. Should the vendor or the CERTS have any official comments or statements or workarounds that they would like to be included in Core's advisory they must be provided them by email no later than Friday May 16th 2008 at 9pm (UTC). . 2008-05-15: Email from the vendor indicating the Citect has allocated resources to address the issue and is pleased to advise that a patch will be available by the end of May. The vendor assumes that publication of the advisory will be postponed given Core's previous email from April 14th stating that it is willing to review the publication date if the vendor commits to releasing a fix no later than June 30th. . 2008-05-16: Email from CERT/CC asking about Core's plan to publish the advisory and stating that CERT/CC is inclined to hold off publication for a couple of weeks provided that Core does the same. JPCERT has been informed of the vulnerability to prepare for the upcoming disclosure. . 2008-05-16: Core sends email to Citect and the three CERTs stating that publication of the advisory has been re-scheduled to June 2nd 2008 and reiterating that should the vendor want to include additional information or specific pointers to the patch it should be provided at least a day in advance. . 2008-05-28: Core sends a follow up to the email sent on May 16th requesting confirmation that Citect is on track to release fixes for the vulnerability. Core had re-scheduled publication of the security advisory to June 2nd, 2008 (next Monday) and wants to confirm that software fixes will be ready to roll out and to provide the opportunity to include in the advisory any official guidelines on how to obtain them and/or any alternative workarounds to the problem. Specific questions about the potential workaround of disabling the vulnerable service are sent to the vendor as well as a request to provide a list of both vulnerable and not vulnerable packages. This information should be received no later than Friday June 30th, 2008 at 1pm UTC. . 2008-06-01: Email received from the vendor stating: "The fix is on track and is currently in code review and testing stage. We will advise when and how the patch will be released". . 2008-06-01: Core asks if the vendor has a concrete estimated date for the patch release. It is noted that publication of the security advisory was re-scheduled to June 2nd, 2008 on the basis of the vendor's commitment to release fixes "by the end of May" as indicated in the vendor's email from May 15th 2008. May is already past and Core still has no concrete details about when and how the fixes will be available. Core also notes that the previous email from May 28th 2008 had specific questions that may help craft guidance and recommendations for vulnerable organizations to mitigate risk due to the vendor's software security exposure and asks if the vendor is able to provide answers to those specific inquires. Core also states that it would like to discuss with the CERTs any specific details and information about their plans to address this issue in the upcoming week. In the absence of concrete fix details and workarounds from the vendor Core would like to coordinate with CERTs the dissemination of information to help reduce risk to vulnerable organizations worldwide. . 2008-06-01: AusCERT indicates that it's ready for the publication and that it will publish its own report after Core has done so. . 2008-06-04: Email from CERT/CC asking for a status update from Core and noting that neither the vendor patches nor Core's advisory have been published by June 2nd as planned. CERT/CC is ready to publish information about the issue and is willing to do so on Core's timetable. . 2008-06-04: Citect informs that the patch for the reported issue has been completed at the code level and is being QA tested. The timing of software releases is a company commercial decision, and no guarantee of delivery dates is given. However, the vendor anticipates the patch will be published on its website in the next day or so, assuming QA approval is given. The vendor informs that the suggested workaround of disabling the ODBC server is viable for users that do not need this functionality (most users of CitectSCADA) and would not affect the operation of the software in any other way. The vendor states that "Although this patch will be made available to our supported customers, Citect maintains the stated stance that under NO circumstances should any SCADA/PLC/DCS/RTU/Process Control network should ever be exposed unprotected to the internet. The network should either be securely firewalled or better still isolated, or otherwise protected using approved IT security methodology. Citect has previously published security recommendations in a whitepaper located on our website at http://www.citect.com/documents/whitepapers/SCADA%20Security%20Whitepape r.pdf "SECURING AN INTEGRATED SCADA SYSTEM - Network Security & SCADA Systems Whitepaper". The vendor also indicates that "copies of the security alert report appear to have been circulated before the advised date of publication, contrary to the undertaking given to Citect." . 2008-06-04: Core's email to Citect, AusCERT, CERT/CC and ArCert informing them that publication of the security advisory has now been re-scheduled to June 11th 2008. The date is final. The advisory will include references to the vendor's security recommendations and white paper as well as the proposed workaround. Core also indicates that to date the company has not published any report about the issue and has no indication of any such reports circulating "in the wild" but cannot discard that as a possibility given that the vendor's lack of proper secure communications procedures forced all the involved parties to communicate without any form of email encryption and that those communications have occurred over a public network such as the Internet for a period of over 4 months. . 2008-06-04: Email from CERT/CC indicating that it will too publish a report on June 11th also noting the importance of sound system administration practices such as disabling unneeded features and a secure network architecture. CERT/CC agrees on the need of isolated or otherwise secured process control networks but indicates that in practice that is not always the case. Further information about any potential information leak is requested. . 2008-06-10: Final draft of the advisory sent to Citect and CERTs, asking for confirmation that patches are now available. . 2008-06-10: Citect confirms that patches are available to customers upon request and reiterates that the vendor's official stance is that the control network must be secured, and customers requesting the patch will be offered advice and links on how to do this. . 2008-06-10: CERT/CC asks for any official guidance or wording that could be used in documents to direct readers appropriately. For example, an URL to a support/contact web site, or a case number. . 2008-06-11: Security advisory CORE-2008-0125 published. *References* [1] Citect Corporate Profile http://www.citect.com/index.php?option=com_content&task=view&id=94&Itemi d=151 *About CoreLabs* CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://www.coresecurity.com/corelabs/. *About Core Security Technologies* Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com. *Disclaimer* The contents of this advisory are copyright (c) 2008 Core Security Technologies and (c) 2008 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. *GPG/PGP Keys* This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.a sc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhP2lEACgkQyNibggitWa29yQCdHfYtgLzOvys9Msi95eqF8H/X ADEAoKB9r52U9KXlEvBn5GgCaqXqC8OG =5qtX -----END PGP SIGNATURE-----