CORE-2008-0125: CitectSCADA ODBC service vulnerability
-----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&Itemid=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%20Whitepaper.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&Itemid=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.asc.
-----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-----