More problems with handling remote cmd.exe shell

["Berend-Jan Wever" <skylined () edup tudelft nl>]

Hi all,

I am working on a cmd.exe shell file transfer program which I'll call cmdftp. I need a decent shell handling routine so 
you can type commands in the shell and a way to up/download files.

The shell handling routine has some problems with buffering (which I now sort of fixed with tcgetattr and tcsetattr) 
and with forwarding "special" keys like ctrl+(key), arrowkeys, etc... I figured it shouldn't be that much of a problem, 
but if you want to do it _right_ it seems there's more to it then just forwarding bytes... I'm probably not the first 
one to code this so if anybody's got a working example of a shell handling routine I'd be much obliged.
I had a look at netcat, but it has way to much features to quickly copy paste code from and to be honest: it's 
spaghetti-code so I can't be arsed to go thought all of it to find out what's doing the usefull things...

The file transfer routine will create small .com files on the target that assist in the transfer, which are created 
with "echo". While testing this I found a REALLY weird problem, an example will demonstrate:
- Connect to a remote cmd.exe shell
- type this echo command: (if it wraps, take out the cr/lf's, there should be spaces spaces between the "t" and all the 
6's and before and after "CPZ2!2" near the end of the command)

  echo 61L+1L=1LO1L_1Lj1Lv1Lx1LQ1LR1LdP4APTZSY5A=H2!P[X_r9AAAA5AW5AP2!WP4At 
66666666662!-7T_P]1-III5AG2!X_s0WX5A=2!WX5aA5 CPZ2!2 >%TEMP%\put.com

- Close the connection
- Reconnect to the shell
- type:

  %TEMP%\put.com
  1234A

(put.com creates one byte out of every two read and will terminate on reading "A". I know this is a very inefficient 
way to encode data, but it's only a trial version)
put.com will print "A", meaning everything worked and it should have created a file called "A" in the current 
directory. The file "A" contains two bytes: 0x12 0x70. This proves that the transfer worked.

Ok, so far no problems. This is because I had you reconnect between creating put.com and executing it.
- Disconnect from the shell
- Delete "A"
- Connect to the shell
- use the echo command to create put.com again
- execute put.com immediately without reconnecting first
- Again type "1234A".

This time put.com will not terminate !? If you close the connection, put.com will be killed and you can see the file 
"A" is again two bytes 0x12 0x70. This means put.com did receive the "1234" but somehow didn't exit when it got the "A" 
!?

I figure put.com is exactly the same program in both cases, so what causes it to hang after receiving "A" in the second 
case !??? The only thing different is reconnecting between the "echo" command and executing put.com. How can this 
affect the execution of put.com !? What THE HELL is going on here !?

Cheers,
SkyLined


----- Original Message ----- 
From: "Berend-Jan Wever" <skylined () edup tudelft nl>
To: <vuln-dev () securityfocus com>
Sent: Tuesday, September 14, 2004 12:46
Subject: Problem with keyboard forwarding to cmd.exe shellcode


> Hi guys,
>
> I'm working on a "shellcode client" that'll forward I/O to a cmd.exe shellcode on a remote computer. I ran into two 
> problems:
> - To forward ^C and ^Z, I'm catching interrupt and terminal stop signals and send a 0x03 or 0x1A respectively. This 
> doesn't seem to work: if you'd type "copy con file.txt", you're doomed because neither the ^C nor the ^Z will break 
> the command.
> - Turning off buffering on stdin doesn't work like I would expect it to, does anybody know how to do this properly ? 
> (see the code below)
> babyjee@papa:~/prg/tools/w32_cmdftp$ ./test
> abc
> [61][62][63][0a]
> babyjee@papa:~/prg/tools/w32_cmdftp$
>
> ---start test.c---
> #include <stdio.h>
> #include <stdlib.h>
>
> int main() {
>   int byte;
>
>   if (setvbuf(stdin, NULL, _IONBF, 0) != 0) {
>     perror("Cannot remove buffering from stdin");
>     exit(EXIT_FAILURE);
>   }
>
>   do {
>     fprintf(stdout, "[%02x]", byte=getchar());
>     fflush(stdout);
>   } while (byte != '\n');
>
>   fprintf(stdout, "\n");
>   exit(EXIT_SUCCESS);
> }
>
> ---end test.c---