Re: W2K Compromise - PipeCmdSrv
From: Curt Wilson (netw3@premis.lod.com)Date: 10/05/02
- Previous message: george.wasgatt@insurity.com: "RE: maybe a simple problem"
- Maybe in reply to: Philip: "W2K Compromise - PipeCmdSrv"
- Next in thread: Erik Sperling Johansen: "Re: W2K Compromise - PipeCmdSrv"
- Reply: Erik Sperling Johansen: "Re: W2K Compromise - PipeCmdSrv"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 4 Oct 2002 23:38:10 -0000 From: Curt Wilson <netw3@premis.lod.com> To: incidents@securityfocus.com('binary' encoding is not supported, stored as-is) In-Reply-To: <20021001024944.32701.qmail@mail.securityfocus.com>
Phillip,
>We had an Internet connected W2K computer compromised. I have
>found the files used to compromise it and wonder if they are
>part of a standard compromise/exploit.
>
>The first file installed during the compromise was an executable
>called PipeCmdSrv.exe in the folder WINNT/System32. This looks
>like a service executable which pipes input from a named pipe to
>cmd.exe (it was installed in the registry at LEGACY_PIPECMDSRV
>in the CurrentControlSet\Enum\Root key).
I recently found PipeCmdSrv in a compromise of a Win2K Advanced Server
system, you can find the document at http://www.netw3.com/documents.html
entitled "Analysis of Compromised Windows 2000 Advanced Server" that
includes links to the executable and some information. My report covers
all of this, as does a report to the incidents list a few weeks ago by
myself. PipeCmdSrv is the server side component to PipeCmd.exe which works
with ntcmd.exe which are part of a "auto-rooter" or attacker toolkit
called Fluxay. However, PipeCmdSrv is not actually included in Fluxay, and
I've found no place where the EXE can be obtained except from a
compromised system. These seems to be a connection between this tool and
Chinese hackers, although I'm sure others may be playing with it now that
is available.
>I cannot find any information about PipeCmdSrv.exe (I have a copy
>of it for inspection) but it seems to have been the first thing
>which was installed - how was it installed?
Looks like this is part a toolkit called LK written by Yun (I have no
further info). The translation below (many thanks to Bernard!) talks about
using a blank Administrator password to initially move PipeCmdSrv onto the
system through the usual windows file sharing methods. The article also
talks about exporting the PipeCmdSrv.exe with VC (Visual C?) from
pipecmd.exe, although I don't understand this (clarification anyone)?
>Has anyone seen PipeCmdSrv before and is it installed as part of
>a known compromise?
The translation is as follows, with many thanks to Bernard for being so
much better than babelfish!
BEGIN CHINESE-ENGLISH TRANSLATION
LK's option tools underlying analysis
Whenever we use LK and discover a machine with empty administrator
password, the first thing come to our mind is to execute commands on the
machine by using NTCMD.EXE coming with LK.
However, has anyone thought about how we actually execute commands on that
machine? What NTCMD.EXE does? NTCMD.EXE is a console program, its syntax
like this:
ntcmd \\IP -U:username -P:password
Actually, ntcmd is only a front-end program. What it does is:
pipecmd.exe ||IP -U:username -P:password command-you-inputed
It execute pipecmd.exe to complete the task. When we are in the ntcmd>
command prompt, pipecmd.exe will be evoked every time we type a command
(except exit,bye).
Then how does pipecmd.exe execute a command? Is there a mechanism that we
can send a remote NT system with a command, then the system will execute
it and return you the result? I don't know, but pipecmd.exe probably not
run in this way. So how does pipecmd.exe execute commands on a remote
machine?
When pipecmd.exe starts, it use the supplied IP address, the username and
password to evoke the function WNetAddConnection2 and connect to
\\IP\ADMIN$. When connected, it connects to \\IP\IPC$ in the same way. If
connection failed, it quit with an error message.
We know \\IP\ADMIN$ correspond to the \WINNT directory and \\IP\IPC$ is a
remote login mechanism. When connected to \\IP\IPC$, something can be done
on the remote machine.
After successfully connected to \IPC$ and \ADMIN$, pipecmd.exe will evoke
WaitNamedPipe and try to connect to pipe-name
\\IP\pipe\PipeCmd_communication on the remote machine.
Here we need to ask, how come the remote machine will have this pipe-name
waiting for your connection? Now we assume that we cannot connect to
\\IP\pipe\PipeCmd_communication. Then what should pipecmd.exe do? Of
course not quit with error. Then pipecmd.exe will evoke a series of WIN32
resource management functions like FindResource, LoadResource, etc. to
access a binary resource named "PipeCmdSrv". What is this resource? He is
our back-end hero that execute commands on the remote machine. He actually
is a console program, but one thing different from other console program
is, he is a SERVICE program.
We can use VC to export the PipeCmdSrv resource inside pipecmd.exe to
pipecmdsrv.exe and then execute it. He will report "This is a service
executable! couldn't start directly!".
After pipecmd.exe has read the resource of pipecmdsrv, it will evoke the
function CreateFile and create the document \\IP\ADMIN$\System32
\PipeCmdSrv.exe and execute a series of Win32 service control functions,
install and startup PipeCmdSrv service on the remote machine. Simple
speaking, it execute PipeCmdSrv.exe on the remote machine (however,not
exactly).
Then PipeCmdSrv service will create four pipe-names on the remote machine:
\\IP\pipe\PipeCmd_communication, \\IP\pipe\PipeCmd_stdoutXXXYYY,
\\IP\pipe\PipeCmd_stdinXXXYYY and \\IP\pipe\PipeCmd_stderrXXXXYYY.
Here XXX is the name of your machine, YYY is a number. Your machine's name
is also registered by PipeCmdSrv to the remote machine - a security issue
(smile).
OK. Now pipecmd.exe connect to \\IP\pipe\PipeCmd_communication again. After
connected, the user's command (e.g. dir c:\) was transmitted to PipeCmdSrv
service on the remote machine via this pipe-name.
PipeCmdSrv receive the command and execute it on the remote machine. I
think PipeCmdSrv may be accomplish this redirecting the input and output
of cmd.exe. After that, PipeCmd and read the output via the name-pipe
\\IP\pipe\PipeCmd_stdoutXXXYYY. If this is an interactive command, like
telnet xxx.xxx.xxx.xxx, PipeCmd.exe will also deliver user's input to
PipeCmdSrv via \\IP\pipe\PipeCmd_stdXXXYYY as well. This must be a kind of
redirection on cmd.exe. That is:
ntcmd.exe -> pipecmd.exe <--> pipecmdsrv.exe. This is the secret of
executing commands on remote machine.
Last few words: I have no special intention in writing this article. Just
want to say if we want to be a hacker, just know how to use the tools is
not sufficient. We not only need knowing how to use, but also
understanding what the tools do and how to accomplish tasks. Eventually we
have to know how to write our own. I think many user of the LK package
really want to know how tasks are accomplished. For example, ntcmd.exe,
sqlrcmd.exe, remotenc.exe, etc. Software necessarily shared. But
knowledge must be shared. I think Yun (the author of the tools) will not
mind sharing the underlying mechanisms of these tools. However, since the
underlying mechanisms are of very low (technical) level, Yun may not have
time for writing this. Then let me write it. But don't treat me as those
technical guys that patched LK. That's too hard for me.
END CHINESE-ENGLISH TRANSLATION
There you have it, as much info as anyone in the security community knows
about this toolkit. I'd love to discuss this in more depth with anyone. My
current email (netw3@premis.lod.com) is down so please use netw3@netw3.com
instead.
Curt Wilson
Netw3 Security Research
www.netw3.com
GCFW, GSEC(2000)
----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
- Previous message: george.wasgatt@insurity.com: "RE: maybe a simple problem"
- Maybe in reply to: Philip: "W2K Compromise - PipeCmdSrv"
- Next in thread: Erik Sperling Johansen: "Re: W2K Compromise - PipeCmdSrv"
- Reply: Erik Sperling Johansen: "Re: W2K Compromise - PipeCmdSrv"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|