[NT] CitectSCADA ODBC Service Vulnerability

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



CitectSCADA ODBC Service Vulnerability
------------------------------------------------------------------------


SUMMARY

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.

DETAILS

Vulnerable Systems:
* CitectSCADA version 6
* CitectSCADA version 7
* CitectFacilities version 7

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> http://www.citect.com/index.php?option=com_content&task=view&id=186&Itemid=322

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 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 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 acknowledgment 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 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.

CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2639>
CVE-2008-2639


ADDITIONAL INFORMATION

The information has been provided by <mailto:advisories@xxxxxxxxxxxxxxxx>
CORE Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/?action=item&id=2186>
http://www.coresecurity.com/?action=item&id=2186



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages