Foot-hold: Remote Code Execution with Drupalageddon2

Nmap showed a few ports open, but it was obvious that the website was to be exploited for this box. The website shows a Drupal install.

Check out the changelog to get further enumeration into the version. We can use this information to do some searching on google for exploits, as well as searchsploit.

The searchsploit will reveal different results based on using ‘drupal 7’ and ‘drupal 7.54’ but both are worth pursuing. The one with ‘drupal 7’ showed the Drupalgeddon2 as well, so I went down that path.

I used this program: Drupalgeddon2

The program let’s you execute commands using commands sent to the server. As an example, I can try to create a file called test2.txt.
drupalgeddon2>> echo hello world2 >> test2.txt
I tried a few times, so the screenshot is from one of those…

Now, I’d like to try to get a php page on the machine that I can call for a reverse shell… unfortunately, the echo command parses some characters, and I till won’t be able to run the php command. In addition, when I try to simply run the php command through Drupalgeddon2, it doesn’t yield any results.

Searchsploit time…

Learned that you can run a searchploit -m to have the module copied to your current directory… pretty cool.

This google seemed to yield results… github
I think it’s basically the same thing as the Drupalgeddon2

So back to Drupalgeddon2… instead of trying to write files, let’s just see if we can go get the user flag… YEP! using the dir command, I was able to see each directory, including the c:\Users directory, which revealed dimitris. “type c:\Users\dimitris\desktop\user.txt” to get the flag.

This doesn’t mean that we have a foot-hold, however. It’s more like the tip of the toe holding onto the box. I still haven’t figured out how to get a reverse shell so that we would be able to go into privilege escalation…

With being able to execute commands, I went ahead and set up the SimpleHTTPServer to send a PowerUp.ps1 to the box.

The file was grabbed, and theoretically executed… but …. I have no way to view the output. I was hoping that it would show up in Drupalgeddon2, but there was no output. The output would only be informational anyway, so who knows if it would help. What I really want to do is upload a file like netcat onto the machine (64 bit version per the systeminfo above) and envoke a shell.

Maybe try to write the content to a file and see if we can view it?

Nope, the test.txt was written, but nothing was in it. So at this point, I went to the tutorials to see what I was missing. I certainly have no quams about getting to a point where I need help!

The tutorials all showed a php script that would run and give you credentials. I tried it out, but got an error message each time. Even with all of the changes showed in the tutorials, I still couldn’t get it to run.

I wasn’t able to get the php script to run because of an error that I didn’t understand. Theoretically, after executing that shell, I would have been able to both execute commands, and upload files. With Drupalgeddon2, I was only able to execute commands, but never got the file upload capability.

To finish this foot-hold exercise, I would have uploaded netcat and had it reach back to my listener to open a shell.

I will consider this a fail for me, which is never a bad thing. I learned tons about Drupal, and the exploits surrounding it. Although I was never able to get the script to work, I was able to find plenty of tutorials and videos that showed the execution of the entire exploit. I’m happy about the progress I made today in my learning.

NOTES:

Notes.txt