Links

Friday, May 30, 2014

Pentesting is a funny thing. Someone will drop some new way of doing something and then you get to reflect on all those missed opportunities on previous engagements. I remember when MC showed me all the Oracle stuff and I reminisced about the missed shells.

This post and part 2 is like that for me. I can't count the number of times i've had access to the folder full of an organization's virtual machines. I knew you could download the raw disk (vmdk) and use tools like volatility on them to carve out useful pieces of the file system but not memory.

While doing some research on vCenter/ESXi I came across a couple of blog posts on the subject:

Obstacle #1. You have to configure the host running the NRPE daemon to talk to a nagios server, your requests to try to exploit the client running NPRE must come from one of the hosted specfiically listed in the nrpe.config. The default is local host only. If you aren't on the list, the application will forcefully disconnect your connection. You can test this by telnetting to the host on 5666.

Obstacle #2. The NRPE daemon must be configured with the dont_blame_nrpe to 1. This is not the default setting. However, if people are using the daemon I've seen this set, otherwise I don't think anyone would be able to interact with it remotely, thus to use NRPE you have to enable it. Please correct me if i'm wrong.

Obstacle #3. You have to enable commands. However, it looks like pretty much any commands that take arguments is vulnerable.

Attack Path:
If you can gain access to any server that is allowed to access the hosts running NRPE (typically the nagios monitoring servers) and you can run the various nrpe plugins you can potentially gain access to the monitored hosts.

As always if i'm way off or there are other tricks please let me know via twitter or here in the comments and i'll update the post.