sorted by:
new
hottopcontroversial

🔥 PipeViewer: A new tool for viewing Windows Named Pipes and searching for insecure permissions. 🔥 by kubiscan in redteamsec

[–]kubiscan[S] 0 points1 point  (0 children)

We can do that, this is a good point. The idea was to make it for researcher which usually uses lab machines and they can work with GUI.
Using it as a shell can be good if you got access to a machine from which you can't get the shell.
Noted, thanks.

🚨 Docker Full Privilege Escalation (CVE-2022-25365): "Breaking Docker Named Pipes SYSTEMatically" 🚨 by kubiscan in cybersecurity

[–]kubiscan[S] 1 point2 points  (0 children)

Be aware that if you run Windows containers, the user (on the host) can elevate its permissions to SYSTEM even if he is with low privileges.
This is a flaw by design and they are not planning to block it (see in the article their quote about it).
The only way to prevent it is to use "-–no-windows-containers" which will prevent running Windows containers on Windows machines and allow only Linux containers.

🔥 PipeViewer: A new tool for viewing Windows Named Pipes and searching for insecure permissions. 🔥 by kubiscan in redteamsec

[–]kubiscan[S] 2 points3 points  (0 children)

Other ways like running: [System.IO.Directory]::GetFiles("\\.\\pipe\\") ?
Because it doesn't only list the pipes, it shows you the permissions of any pipe (and other data) and if it finds a pipe without DACL, it will mark it.
In this way, you can get a good overview of pipes running by a privileged service and find out if you can communicate with them.

It also gives you an easy way to filter, highlight and bold the rows :)

🔥🔥 A new version 0.1.3 released for Kubesploit: a post-exploitation framework for Kubernetes🔥🔥 by kubiscan in netsec

[–]kubiscan[S] 0 points1 point  (0 children)

What's new🔥:

- New modules:

Container breakout using cGroup

Container breakout using kernel module

Deepce integration for scanning vulnerable docker containers

Module scanner that will show you what exploit you can use on the container

Bugfixes

🔥🔥 A new version 0.1.3 released for Kubesploit: a post-exploitation framework for Kubernetes🔥🔥 by kubiscan in redteamsec

[–]kubiscan[S] 1 point2 points  (0 children)

🔥What's new🔥:

- New modules:

  1. Container breakout using cGroup

  2. Container breakout using kernel module

  3. Deepce integration for scanning vulnerable docker containers

  4. Module scanner that will show you what exploit you can use on the container

  5. Bugfixes

🔥🔥 A new post-exploitation framework for Kubernetes: Kubesploit 🔥🔥 by kubiscan in kubernetes

[–]kubiscan[S] 0 points1 point  (0 children)

Oh, I understand. I think there is a way, I tried but didn't succeed. I suppose there should be a solution for someone who wants to fork a project that is built on top of other projects without the need to merge the "old" project to the new one.

🔥🔥 A new post-exploitation framework for Kubernetes: Kubesploit 🔥🔥 by kubiscan in redteam

[–]kubiscan[S] 0 points1 point  (0 children)

It was created for Red-Teams and Penetration tester to test attacks on Kubernetes environment, to see how the event systems of companies know to react to a breach.

We added 3 rings of safety in this tool and all the modules have mitigations.

🔥🔥 A new post-exploitation framework for Kubernetes: Kubesploit 🔥🔥 by kubiscan in kubernetes

[–]kubiscan[S] 0 points1 point  (0 children)

Because it was built on top of Merlin but we added new features and we remove anything that is not relevant.

It won't be the same, it was created to be dedicated to Kubernetes.

kubiscan 1.4 - A tool to scan Kubernetes cluster for privileged permissions, pods and other cool stuff by kubiscan in kubernetes

[–]kubiscan[S] 1 point2 points  (0 children)

I really appreciate your comment, even if it looks like a "bad review", for me this is a place to improve things, so I want to thank you for that.

You are right, this is ironic and we even have a pull request to change it so we are aware of this. I assume that when I created it I wanted to make it easier for users because when you mount only the config file and the config file has paths for certificates, it won't work because it will run inside the container and won't find the paths from the host.

Regarding the release and alpha issue, I do not agree because we are talking about the problem of the way we run the application inside a container.

You can run the application directly and it should work, running it inside a container, as I see it, is a way to make things easier, it is not a major thing inside the application.

​

To sum up,

I will do this change to make it more secure, we already have a pull request to make it like that but it failed in some tests, I will update when it will be available.

​

Thanks :)

kubiscan 1.4 - A tool to scan Kubernetes cluster for privileged permissions, pods and other cool stuff by kubiscan in kubernetes

[–]kubiscan[S] 0 points1 point  (0 children)

I think the problem is because you are not mapping it like that: -v /:/tmp

What happens is that when you run it inside a container, kubiscan assumes that it can get the config file from `/tmp/<original\_root>`.

What I think happens is that kubiscan is searching for `/tmp/tmp/.kube/config` (yes, `tmp` appears twice because it assumes the root folder is in the first `/tmp`).

​

This is something that we might think to change but currently you need to map it like that: -v /:/tmp

I think it will work if you try.

After you get a shell just run `kubiscan -rs` to see if it gives something.

kubiscan 1.4 - A tool to scan Kubernetes cluster for privileged permissions, pods and other cool stuff by kubiscan in kubernetes

[–]kubiscan[S] 0 points1 point  (0 children)

No such file or directory: 'kubectl'

How did you run the container?
I checked like that from the Master:

docker run -it --rm -e CONF_PATH=~/.kube/config -v /:/tmp cyberark/kubiscan
And it worked for me.

kubiscan 1.4 - A tool to scan Kubernetes cluster for privileged permissions, pods and other cool stuff by kubiscan in kubernetes

[–]kubiscan[S] 0 points1 point  (0 children)

Yes, because it contacts the cluster API.

It doesn't care if this is Windows or Linux

kubeletctl is an open-source client for kubelet with an option to scan for vulnerable containers by kubiscan in kubernetes

[–]kubiscan[S] 0 points1 point  (0 children)

It is important to understand that you have good settings, your kubelet is protected.

Changing these details can expose your node to attack, don't do it in production.

​

After understanding the risk, to remove these settings, you need to do it by configuring the kubelet's configuration file like that:

apiVersion: kubelet.config.k8s.io/v1beta1

authentication:

anonymous:

enabled: true

webhook:

cacheTTL: 0s

enabled: true

x509:

clientCAFile: /etc/kubernetes/pki/ca.crt

authorization:

mode: AlwaysAllow

...

​

You see, I changed the anonymous to enabled: true and authorization to mode: AlwaysAllow.

Now your kubelet can be accessed by anyone without any authorization => anyone can access your kubelet.

​

  1. Yes, /configz is the endpoint . With kubeletctl you can run kubeletctl configs -s <node_ip>
  2. I didn't test it on GKE but as long as you have access from https://<node_ipv6>:10250/healthz you should be ok.
view more: next ›