#Netcat Listener Setup

[joy-jules]

DogCat - Exploiting LFI and Docker Privilege Escalation -TryHackMe Walkthrough

In this walkthrough, we’ll explore the Dogcat room on TryHackMe, a box that features a Local File Inclusion (LFI) vulnerability and Docker privilege escalation. LFI allows us to read sensitive files from the system and eventually gain access to the server.There are a total of 4 flags in this machine which we need to find. Let’s Dive in! Step 1: Scanning the Target Start by scanning the target…

[globalmediacampaign]

Streaming Percona XtraBackup for MySQL to Multiple Destinations

Have you ever had to provision a large number of instances from a single backup? The most common use case is having to move to new hardware, but there are other scenarios as well. This kind of procedure can involve multiple backup/restore operations which can easily become a pain to administer. Let’s look at a potential way to make it easier using Percona Xtrabackup. The Percona XtraBackup tool provides a method of performing fast and reliable backups of your MySQL data while the system is running. Leveraging Named Pipes As per the Linux manual page, a FIFO special file (a named pipe) is similar to a pipe except that it is accessed as part of the filesystem. It can be opened by multiple processes for reading or writing. For this particular case, we can leverage FIFOs and netcat utility to build a “chain” of streams from one target host to the next. The idea is we take the backup on the source server and pipe it over the network to the first target. In this target, we create a FIFO that is then piped over the network to the next target. We can then repeat this process until we reach the final target. Since the FIFO can be read by many processes at the same time, we can use it to restore the backup locally, in addition to piping it over to the next host. Implementation In order to perform the following operations, we need the netcat, percona-xtrabackup and qpress packages installed. Assume we have the following servers: source, target1, target2, target3, target4 We can set up a “chain” of streams as follows: source -> target1 -> target2 -> target3 -> target4 Looking at the representation above, we have to build the chain in reverse order to ensure the “listener” end is started before the “sender” tries to connect. Let’s see what the process looks like: Create listener on the final node that extracts the stream (e.g. target4):nc -l 3306 | xbstream -p 4 -x -C /data/mysql/ Note: the -p argument specifies the number of worker threads for reading/writing. It should be sized based on the available resources. Setup the next listener node. On target3:# create the fifo mkfifo xbackup.fifo # forward the fifo to target4 nc 3306 < xbackup.fifo & # also extract the fifo locally nc -l 3306 | tee xbackup.fifo | xbstream -p 4 -x -C /data/mysql/ Repeat step 2 for all the remaining nodes in the chain (minding the order). On target 2:# create the fifo mkfifo xbackup.fifo # forward the fifo to target3 nc 3306 < xbackup.fifo & # also extract the fifo locally nc -l 3306 | tee xbackup.fifo | xbstream -p 4 -x -C /data/mysql/ On target 1:# create the fifo mkfifo xbackup.fifo # forward the fifo to target2 nc 3306 < xbackup.fifo & # also extract the fifo locally nc -l 3306 | tee xbackup.fifo | xbstream -p 4 -x -C /data/mysql/ Note that we can introduce as many intermediate targets as we need. Finally, we start the backup on the source, and send it to the first target node:xtrabackup --user=root --password=percona --backup --compress --compress-threads=4 --parallel=6 --stream=xbstream --target-dir=/tmp | nc 3306 If we got it right, all servers should start populating the target dir. Wrapping Up After the backup streaming is done, we need to decompress and recover on each node: xtrabackup --decompress --remove-original --parallel=8 --target-dir=/data/mysql/ xtrabackup --prepare --use-memory=10G --target-dir=/data/mysql Also, adjust permissions and start the restored server: chown -R mysql: /data/mysql service mysql start Conclusion We have seen how using named pipes, in combination with netcat, can make our lives easier when having to distribute a single backup across many different target hosts. As a final note, keep in mind that netcat sends the output over the network unencrypted. If transferring over the public internet, it makes sense to use Percona XtraBackup encryption, or replace netcat with ssh. https://www.percona.com/blog/2020/08/20/streaming-percona-xtrabackup-for-mysql-to-multiple-destinations/

[vishers]

How to establish a reverse tunnel bound to anything but localhost via ssh through a bastion (and test it with netcat)

A coworker of mine had a need to set up a reverse tunnel in order to achieve the following picture:

+-----------------+ +----------------+ | public internet | | private subnet | | | | | | :7777 +---+ | +---+ | | ------->| | :6666 | | | | | | | | ---------> | | | | | +---+ | +---+ | +-----------------+ +----------------+

We were both pretty sure this should be easily accomplished with a combination of ssh and netcat but nevertheless struggled a bit to get it set up. There were a couple key bits of insight:

ssh does all the heavy lifting of opening a socket. No local bastion-machine netcat required.

Initially we thought for whatever reason that we'd have to establish the reverse tunnel from the private instance to the bastion and then, while on the bastion, open a new netcat listener to forward the traffic, forgetting that that is essentially what -R is accomplishing in the first place. ssh -R 7777:localhost:6666 ... is enough to get any traffic pointed at localhost:7777 to get back to you over the reverse tunnel because ssh is listening on 7777. If you want to bind to anything but localhost, OTOH…

sshd doesn't allow you to do this by default. You need to change the GatewayPorts option to clientspecified, preferably, or yes if for whatever reason you think that's better.

We were able to figure out what was happening after trying several incantations of -R only to discover every time that 7777 was bound to localhost by running sudo lsof -i :7777. Reading the ssh -R man page section more closely (and pinging #openssh@freenode) we realized that "Specifying a remote bindaddress will only succeed if the server's GatewayPorts option is enabled".

From the man page:

GatewayPorts

Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd(8) binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be no to force remote port forwardings to be available to the local host only, yes to force remote port forwardings to bind to the wildcard address, or clientspecified to allow the client to select the address to which the forwarding is bound. The default is no.

#openssh@freenode recommended clientspecified as the correct value.

nc has some niceties built in that we discovered while trying to get things working.

For maximum interactivity with minimal setup our testing shim was gong to be a nc instance on a machine that would ape the public internet pointed at :7777 on the bastion and a nc server on the private box listening on localhost:6666. That way all we would have to do was type some text into a terminal to verify everything worked.

Unfortunately every time we terminated the connection to the nc server the nc process would exit. Looking at the man page we remembered -k allows the server to continue to stay open after a TCP connection terminates.

Not the most groundbreaking stuff, I know, but still something that took us 30 minutes to figure out that I'd love to be able to Google for later.

For reference, the final test jig picture:

+----------------------------------------+ +----------------+ | private subnet | | | | | | :7777 +---+ | +----------------------------------+ | | $ nc B 7777 -------> | B | :6666 | | # shell 1 | | | | | | ---------> | $ ssh -R *:7777:localhost:6666 B | | +----------------+ +---+ | | | | | | # shell 2 | | | | nc -lk 6666 | | | +----------------------------------+ | +----------------------------------------+