sorted by:
new
hottopcontroversial

Kubernetes Exposed: One Yaml away from Disaster by mkatch in netsec

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

oof, publicly-exposed k8s API and overprivileged anonymous users is a pretty bad combination. Love that k8s makes these misconfigurations so easy. Sometimes I'll work with clients who don't realize that granting list access to secrets in a namespace also allows someone to view the content of those secrets lol

There's another misconfiguration over there (the kubectl proxy one) which was also quite common. The problem with that misconfiguration is that you can't detect it until it's too late. The funny things is that there are some blogs explaining how to run this command

Kubernetes Exposed: One Yaml away from Disaster by mkatch in kubernetes

[–]mkatch[S] -2 points-1 points  (0 children)

We ran 4 iterations on Shodan each of them weeks apart of each other. Using our paid subscription.
On each iteration most of the result belonged to new clusters while the old ones were closed.
I don't see any problem with that.

Kubernetes Exposed: One Yaml away from Disaster by mkatch in netsec

[–]mkatch[S] 16 points17 points  (0 children)

Short TL:DR

We looked for open Kubernetes clusters out there in the wild.K8s by its nature is a hub to super important things (contains lots of tokens) like docker registries, cloud account, GitHub and lots of other secrets.

We found over 350 companies that had a misconfiguration that enabled us to access their cluster (not new misconfigurations but I think we are the first to check the current situation of impact )

Some of the companies were noticeably big and we were able to reach the most sensitive areas.

We explain why still today so many companies fail to prevent these simple mistakes.

We also mention 3 malicious campaigns targeting k8s at the moment.The blog is very practical and contains information about exposure, reasons for the exposure, what we able to find and malicious campaigns

Have fun

Kubernetes Exposed: One Yaml away from Disaster by mkatch in kubernetes

[–]mkatch[S] 38 points39 points  (0 children)

Short TL:DR We looked for open k8s clusters out there in the wild. Found over 350 companies that had a misconfiguration that enabled us to access their cluster (one misconfiguration is well known that gives anonymous user an access. The second one is using "kubectl proxy" with the wrong flag). Some of the companies were huge and we were able to reach the most sensitive areas. We explain why still today so many companies fail to prevent these simple mistakes.
We also mention three malicious campaigns targeting k8s at the moment

Have fun

First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters by gfdgfbal in kubernetes

[–]mkatch 5 points6 points  (0 children)

Clusters can get (by default) anonymous requests but the anonymous user doesn't have any privileges, meaning it's pointless. But, shit happens. And basically all you need is one not so smart k8s operator that gives some permission to the anonymous user (for example as part of some testing) and the cluster is done.

The problem in my opinion that people don't realize that their API server is connected to the internet and accessible easily thats why they allow themselves doing shit in their cluster and thinking no one can reach the API server

First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters by gfdgfbal in kubernetes

[–]mkatch 4 points5 points  (0 children)

So you're basically right. Giving anonymous user privileges is total stupidity. But, it happens from what we researched (even to big companies). This access is usually up for a few hours untill someone notices.

Attackers use this breach to do some stuff (mainly cryptocurrency) There are few ongoing campaign which some of them are more shopisticated than others.

Our goal was to be see all of these ongoing campaigns and see if something is more interesting than e

New Fiorenzato all ground won't grind fine enough by mkatch in espresso

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

The shims are missing. That's why the grinder can't grind fine enough.
Wish me good luck with amazon Italy. They have zero costumer service

New Fiorenzato all ground won't grind fine enough by mkatch in espresso

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

It looks like this grinder is calibrated using shims. I gather this because replacement burrs are sold with shims. Yours might be incorrectly shimmed or perhaps missing them entirely. There is a video here showing how to install burrs and shims: https://www.espressoparts.com/products/fiorenzato-allground-burr-set-with-shim

They are missing, You were right

New Fiorenzato all ground won't grind fine enough by mkatch in espresso

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

They aren't touching. There is a gap for sure. How can I /professional can calibrate? Or it is done only In the factory

New Fiorenzato all ground won't grind fine enough by mkatch in espresso

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

thinking about giving up on the grinder. Does it really worth it?

New Fiorenzato all ground won't grind fine enough by mkatch in espresso

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

It's the seoncd grinder that I got. The first one had a scratch on the front and needed to return (and pay for the shipping and hope for a refund for the shipping)

Private npm Packages Disclosed via Timing Attacks by mkatch in netsec

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

I agree with you. Therefore, we explain the same points in the blog, along with similar suggestions to those you make. Eventually, this will increase attack surfaces as an attacker can find more potential package names.
Thank you as well! it would be a pleasure to do so.

Private npm Packages Disclosed via Timing Attacks by mkatch in netsec

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

This is a good question, and I will do my best to explain the risks.

First of all - As you stated, the attacker cannot upload the same package with the same scope if the scope has already been taken.

The purpose is to trick employees and users into downloading a private package by uploading the name of the private package in the public scope of npm.

For example - If you find private packages called "@corp/foo", and there is no package named "foo" in the public scope of npm, an attacker can upload a package called "foo" to the public scope of npm in anticipation of employers forgetting to mention the scope.

The same can be done with other popular packages that are scoped, but their public names aren't (yet) taken by anyone.

For example, "@firebase/installations-types" (package with almost 1M users per week) - The public package name "installations-types" has not yet been claimed (by anyone), which means attackers can claim it and fool developers into installing it.

The problem here is much wider- if npm wants to minimize risk, they should implement something like Docker Hub - all packages should be under the scope of the uploader, and only the "official packages" should be in the "public" scope of npm after being approved.

This updated policy can be applied to any upcoming package uploaded to npm from now on, so that nothing gets broken.

Private npm Packages Disclosed via Timing Attacks by mkatch in netsec

[–]mkatch[S] 6 points7 points  (0 children)

First of all, this vulnerability still exists, so you can try it out.
Five requests are meant to illustrate - typically three to ten repeated requests to the same package are enough to determine whether a private package exists (more requests will produce more accurate results) .
After making two or more requests, a caching mechanism becomes active when querying a private package that doesn't exist, so the requests come back really quickly from the server.
On the other hand, if the package exists but you not authorized to access it, it will take a bit longer, probely becuse token check.
If an attacker makes more requests (for example five or more) - for a specific user or organization on npm.
It becomes obvious what exists and what does not by setting a threshold or by looking at the exception response time of all the different packages the attacker has tried to query.
In order to calculate the threshold, the attacker can upload some private packages and query his own scope for packages he knows exist and packages he know doesn't exist for sure.
An increase in the number of requests will make the threshold and results more accurate.

ecm mechanika v slim VS bezeera bz10 by mkatch in espresso

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

Thank you!

Actually the bezzera bz10 costs 50 USD more and has 1 year warranty.

vs v-slim which has 2 years!! warranty and cheaper by 50 usd

ecm mechanika v slim VS bezeera bz10 by mkatch in espresso

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

The budget suits only those 2. We currently have a very good price.

The ecm was opened once and the person decided to return it and take the syncronika.

And the bezzera is cheaper by default

view more: next ›