SAPwned: SAP AI vulnerabilities expose customers' cloud environments and privat
wiz.io
wiz.io
> The root cause of these issues was the ability for attackers to run malicious AI models and training procedures, which are essentially code
It's being researched and investigated, to my understanding, due to the prevalence of AI products and the need to be mindful of the infrastructure.
Securing it or knowing to secure it or testing it or never releasing it until it was secure is all things that are with the brand making the sale.
Smaller companies can hide behind obscurity, not big company.
If the same thing happened to a company much smaller then SAP, it wouldn't have made hacker news.
Crowdstrike took a 10% stock hit, but i from what i've seen of corps i work with the longterm affect at C-level decisions won't change and most if not all the contracts will stay in place and the stock will recover in a few weeks.
Researchers also usually mention which points they asked for additional permissions at in writeups, but now always.
Question is, do they live it or is it just some binder sitting on a shelf.
All the major clouds use vm boundaries and separate K8s clusters between customers. Microsoft was similarly bitten a few years ago with one of their function products that expected K8s to be the primary security boundary.
Maybe I missed something in the article but where are they expecting any hard guarantees. If there is a model being trained for example (running arbitrary code) where does a multi K8 tenency play?
The main issue I see is all internal network communication was trusted once behind the proxy/firewall (Istio) but I probably just don't understand k8 clusters too well.
https://istio.io/latest/docs/ops/deployment/architecture/
Being able to run as the Istio user (1337) renders the proxy itself moot right ?
Kubernetes itself is very complex. The "who needs a UI when you have configuration files and an API?" approach makes it even more opaque to the people who often end up responsible for it. The landscape changes very rapidly.[2] I'd trust Kelsey Hightower to set up a secure multi-tenant deployment, but probably not anyone else.
Is it not practical to deploy clusters on top of virtualization? That should make efficient use of hardware while still giving each tenant their own cluster, therefore providing stronger isolation than the typical Kubernetes configuration tends to.
[1] I am specifically referring to a Kubernetes deployment where different customers are running custom code on the same underlying hosts. Using Kubernetes to host a service that is multi-tenant at a higher level is not something I would recommend, but it's not as immediately dangerous as a model where customers run container-level custom code.
[2] This is not surprising for a relatively new technology, especially one that's as paradigm-shifting as Kubernetes was. But most people are not going to rearchitect and redeploy everything every six months just because the Kubernetes developers decided to replace a pod security or network security model with a non-backward-compatible alternative again.
No it is not. Not in the way they are using it.
There are two main use-cases. One is multiple teams, in which case they are bound by their company's policies and guardrails
The second is multiple customers. But that also assumes they have no direct access to the cluster. A vendor would, instead, deploy multiple instances of a workload; the customers would not.
Straight from the horse's mouth: https://kubernetes.io/docs/concepts/security/multi-tenancy/
There's also nothing that says that multiple clusters need to be expensive, if they are sized right. They can be as small as you need both in number of instances and instance size. The overhead here is the control plane but, for small clusters, the resource requirements are similarly small.
That said, if hard multi tenancy is what you need, then you need to use things like this: https://github.com/kubernetes-sigs/cluster-api-provider-nest...
(for the control plane - you still need to worry about the data plane)
One needs to look into things like VirtualClusters to even begin to consider hard multi-tenancy with potential hostile tenants(https://github.com/kubernetes-sigs/cluster-api-provider-nest...). That is just about the control plane. It doesn't even touch the data plane.
How secure that is even with the extra layer, I do not know. Even in the VM land we have seen crazy VM escape exploits over the years.T
“We thanked them for their co-operation”. Sounds kinda like extortion.
Your comment could be rephrased as, "Companies who carelessly collect and store sensitive user data insecurely should not be closely scrutinized, and should be left alone to continue exposing innocent user data to malicious cyber criminals."
Looks a lot different when you look at it from that angle, right?
but as the law practice says "If you have billions of USD, laws don't apply to you anymore".
It's possibly the fastest rocket for an enterprise software company ever.
$100M in just 1.5 years time
$350M at end of 3-year
https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...
And the first test is running, and no one is screaming yet, so fingers crossed.
any pentesting companies that you could recommend which do more than just drive-by shooting with metasploit?
However, what I'd really like is budget and time for a dedicated infrastructure pentest. I'd like to give the pentesters the same access as our office has, to see if that's fine. And since I like pain, I'd also like to simulate compromise of an application server: Deploy some reverse shell / kali container as an unprivileged container with some middleware service access, and later on deploy a privileged containers as well. Ideally the first simulation should only lead to loss of data the service needs to function, but as the article shows: Who knows. Maybe we also lose everything.
Regarding companies, at my current job we're having good experiences with Secuvera[1] from germany. They are doing the usual ZAP/Metasploit drive-bys, but they are also poking and prodding at various security boundaries, the services behind the application. We're getting good results from them.
At my previous test, we also had a few encounters with Redteam Pentesting[2]. Those guys used an incorrectly used cipher-mode to exploit the links allowing users to "single-sign-on" (only in spirit, not in current tech) from the game-client to the forum in order to hijack arbitrary forum accounts by modifying the encrypted forum-account-id inside the link. And other fun hijinks.
1: https://www.secuvera.de/ (I can't find an english version of that site)
https://www.bleepingcomputer.com/news/security/researcher-re...
Edit: Nvm, I guess they blurred text in some places, pixelated in others
Blurring is like a hashing algorithm. If you know the font, size and placement that was used, you can try out reblurring and Thus brute forcing characters
But a security fist to a leaky side door? I’d bet that upsets some customers.
Many of these accounting systems are starting to sell AI to automate transactions, which may explain the read+write nature of the access described in the comments.