I had so many different ideas for the title of this post because there are so many different ways to call attention to this problem.  "Too much point and click."  "Attention to detail."  "Understanding your environment."  All of these apply.  

The other day, I was playing around with (I will post on this soon!) Oracle Glassfish --  "Glassfish is the world's first implementation of the Java Platform, Enterprise Edition (Java EE) 6 specification."  I managed to get credentials and with that, I am able to deploy an application which is very much like deploying an application on Tomcat.  

I setup Metasploit:






Mind you, I'm in play hack mode and I'm giving this about half of my attention.  I didn't notice what I've highlighted above and the payload above type above that.  To spell it out, this is a Windows machine but my payload is Java, not Windows.

I execute:




I get a meterpreter session and I attempt getsystem but it fails.  I stare for a moment and then I realize the error of my ways but my penance for not paying attention is to take every bad turn, show you how it repeatedly fails, and then give you one possible solution.  My goal is to ingrain this mistake in my brain so that even when I am only half paying attention that I will remember the time I wrote an entire post about neglecting to read the target and payload type.  I should also add that getsystem is highly unlikely to work these days since the elevation methods have long since been patched but it's instinctive at this point -- and hey, you never know, it might just work.

Continuing on, I still have a meterpreter session even though it's not acting as I would expect.  I will background that session and I will use the exploit suggester:




Again, take note -- it's giving me clues.  But I continue to dig my hole deeper by attempting to inject a Windows meterpreter payload:



I execute:




I fail again. 

Let's say I want to turn my hole into a crater and I dump a meterpreter executable onto the box and I spawn another session:




I"m still failing.  You know why?  Architecture.  Let's say we ignore that and we run the exploit suggester again:




This time it gives us back some suggestions and we go for a likely candidate:




Take note, x86. I also assume that line about 32 and 64 bit is also due to incorrect architecture.

We are reaching canyon-sized proportions with our hole as we change our target to 64bit:



Ok, that was painful to do. 

I did NOT make all of these mistakes today.  I made the one, saw my error, corrected it and I moved on.  But at some point, I most definitely did make a few of these mistakes in the past.  

Now here's how it should have gone down. 

Starting with my original exploit:



Setting up a listener job for a 64bit meterpreter shell and letting that simmer in the background:




There might be another way to do this but this is the easiest way I know because I know this machine does not have antivirus:



I move to the exploit suggester:




This time our architecture matches and we go for the promising candidate:



I execute:



Root!  

When I wrote this up, the original exploit was suggested to me again when I had matching architecture.  When I went through the process a second time, after exploiting it the correct way, it wasn't suggested.  I didn't reboot the box and maybe something went sideways after the first use.  ?  The point was not about any exploit in particular though -- it's about how Metasploit is very pointy & clicky and sometimes it's easy to let the details slip past us.  

When I originally popped Glassfish through the deployment avenue, I did it manually.  I went to Metasploit following that path and given how things turned out, there's something to be said for manual exploitation.  There's nothing wrong with Metasploit, or any automated tool, but if we can learn manual exploitation, we will understand what's happening under the hood. 

Somewhere on this site, I've written that a .war file is essentially a zip file containing the following:





A root directory, a WEB-INF directory and one file in each of those directories.  Something I wouldn't have learned if I'd solely relied on Metasploit.  One more thought as I wrap this up.  It actually takes longer for me to dig up the msfvenom syntax for creating a .war file as it does to edit the .jsp file which looks like this at the center:





Change that line, zip it up, change the extension and that's it.