www.oligo.security Open in urlscan Pro
52.17.119.105  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Product
Focus

Fix only what matters


ADR

Stop attacks before they impact your business

About
Resources
Blog

Deep dives into recent trends, product updates, and expert insights.


Resources

Your go-to hub for everything AppSec.


Case studies

See how businesses enhance their security posture with Oligo.


Podcasts

Engaging discussions on the latest in application and runtime security.


News

Latest announcements & security updates.


Events

Join us at upcoming security events, roundtables and workshops.

ShadowRayContactBook a Demo






SHADOWRAY: FIRST KNOWN ATTACK CAMPAIGN TARGETING AI WORKLOADS ACTIVELY EXPLOITED
IN THE WILD

Avi Lumelsky
,
Guy Kaplan
,
Gal Elbaz
March 26, 2024

Thousands of publicly exposed Ray servers compromised as a result of Shadow
Vulnerability


TL;DR

The Oligo research team has recently discovered an active attack campaign
targeting a vulnerability in Ray, a widely used open-source AI framework.
Thousands of companies and servers running AI infrastructure are exposed to the
attack through a critical vulnerability that is under dispute and thus has no
patch. This vulnerability allows attackers to take over the companies' computing
power and leak sensitive data. This flaw has been under active exploitation for
the last 7 months, affecting sectors like education, cryptocurrency, biopharma
and more. All organizations using Ray are advised to review their environments
to ensure they are not exposed and to analyze any suspicious activity.


INTRO

In late 2023, five unique vulnerabilities in Ray—a widely-used open-source
framework mainly used in AI workloads—were disclosed to Anyscale, the developers
and maintainers of Ray. The vulnerabilities were disclosed (some simultaneously)
by Bishop Fox, Bryce Bearchell, and Protect AI.

Following the disclosure, Anyscale released a blog [1] to address the
vulnerabilities, clarify the chain of events, and detail how each CVE was
addressed. While four of the reported vulnerabilities were fixed in Ray version
2.8.1, the fifth CVE (CVE-2023-48022) remains disputed, meaning that it was not
considered a risk and was not addressed with an immediate fix.

Because CVE-2023-48022 was disputed, many development teams (and most static
scanning tools) are not aware that this vulnerability should concern them. Some
of them might have missed this documentation section of Ray, while some of them
are unaware of this feature.

Researchers at Oligo Security have observed instances of CVE-2023-48022 being
actively exploited in the wild, making the disputed CVE a “shadow
vulnerability”—a CVE that doesn’t show up in static scans but can still lead to
breaches and significant losses.

In our research, we found that thousands of publicly exposed Ray servers all
over the world were already compromised as a result of this new vulnerability,
dubbed ShadowRay by Oligo’s research team. Some of the impacted machines were
compromised for at least 7 months. Many of the machines included command
history, making it much easier for attackers to understand what resides on the
current machine and possibly leaking sensitive secrets from production that were
used in previous commands.



A complete list of Indications of Compromise (IoCs) is available at the end of
the blog. Hundreds of companies have been publicly exposed to remote code
execution (RCE) through Ray, with some remaining vulnerable to this day.

Oligo researchers (who have been at the forefront of uncovering shadow
vulnerabilities) named this CVE ShadowRay, marking the first known instance of
AI workloads actively being exploited in the wild through vulnerabilities in
modern AI infrastructure.

In this summary of our research, we will dive into:

 * Why AI infrastructure is a goldmine for attackers.
 * What the Ray open-source framework is, who uses it, and how it is used in AI.
 * The Ray clusters that have been exploited in the wild, including the wealth
   of data that has been compromised, the collective value of compromised
   machines, how attackers are monetizing their efforts, and more.

> Disclaimer:
> This blog will discuss recent vulnerabilities in the open-source Ray framework
> that were reported by Bishop Fox [2], Bryce Bearchell [3], and Protect AI [4].
> It does not relate to Anyscale’s (the developers of Ray) SaaS offerings or
> paid products. The sole intention of this blog is to support users of Ray by
> increasing awareness of its security aspects and common pitfalls.


IN THIS ARTICLE:

 1. AI Infrastructure: A Goldmine for Attackers
 2. Meet Ray
 3. The Story of CVE-2023-48022: ShadowRay Explained
 4. Indications of Compromise (IoCs)
 5. Special Thanks




AI INFRASTRUCTURE: A GOLDMINE FOR ATTACKERS

A typical AI environment contains a wealth of sensitive information—enough to
take an entire company down. Why is an AI environment such a lucrative
environment for attackers? Let’s take a look at the components and the risks
they present.

An ML-OPS environment consists of many services that communicate with each
other, inside the same cluster and between clusters.

When used for training or fine-tuning, it usually has access to datasets and
models, on disk or in remote storage, such as an S3 bucket. Oftentimes, models
or datasets are the unique, private intellectual property that differentiates a
company from its competitors.

Additionally, AI environments will typically have access to third-party tokens
(in a readable secret or environment variable) and integrations of many kinds
(HuggingFace, OpenAI, WanDB, and other SaaS providers).

AI models are now connected to company databases and knowledge graphs. The AI
infrastructure can be a single point of failure for AI-driven companies—and a
hidden treasure for attackers.

AI models typically run on expensive, high-powered machines, which makes the
computing power they use a prime target for attackers.




MEET RAY

Ray is a unified framework for scaling AI and Python applications for a variety
of purposes.

At high level, Ray consists of:

 1. Core distributed runtime, known as Ray Core.
 2. A set of complementary AI Libraries and extensions that are built on top of
    it or depend on it, for accelerating and distributing domain-specific ML
    workloads efficiently.




WHO USES RAY AND HOW?

Today, Ray has 30K stars on GitHub [5]. According to Anyscale, some of the
world’s largest organizations use Ray in production, including Uber, Amazon, and
OpenAI. [6]


Source: anyscale.com [6]

Many projects rely on Ray for mainstream SaaS, Data, and AI workloads,
leveraging the project for its high levels of scalability, speed, and
efficiency.

Anyscale maintains the Ray project, which serves as a base for numerous
libraries including Ray Tune, Ray Serve, and more.


Source: ray.io

Ray uses boilerplate code that bootstraps product installations and deployment
using Helm charts and other cloud-native methods. Ray’s many integrations with
cloud providers enable managed services use cases as well.

Models like GPT-4 comprise billions of parameters, requiring massive
computational power. Such large models cannot possibly fit on the memory of a
single machine. Ray is the enabling technology that allows these models to
run.Ray quickly became a best practice in the industry—especially for AI
practitioners, who are proficient in Python and often require models to run and
distribute among multiple GPUs and machines.




HOW RAY IS USED IN AI

Ray’s capabilities match the needs of AI perfectly:

 * Ray enables distributed workloads for training, serving, and tuning AI models
   of all architectures and frameworks.
 * Ray requires very low proficiency in Python. It has a lean Python API with
   minimal configuration.
 * Ray is rock-solid and uses best practices to optimize performance, with a
   robust, effortless installation, few dependencies, and production-grade,
   battle-tested code.
 * Ray goes beyond Python, allowing you to run jobs of any kind, including bash
   commands.

Ray is the Swiss Army knife for Pythonistas and AI practitioners, allowing them
to effortlessly scale their AI applications.




THE STORY OF CVE-2023-48022: SHADOWRAY EXPLAINED

Following the disclosure of five vulnerabilities by Bishop Fox, Bryce Bearchell,
and Protect AI, Anyscale handled a challenging situation with transparency and
responsiveness, demonstrating their commitment to the security and integrity of
the Ray ecosystem. Anyscale promptly addressed four of the issues in Ray version
2.8.1 and provided a detailed blog post explaining the vulnerabilities and their
remediation [7].

One of the vulnerabilities, CVE-2023-48022, arose from Ray’s lack of
authorization in the Jobs API. Unlike the other CVEs, which were addressed with
Ray’s new release, this CVE remained disputed by Anyscale—in fact, according to
them, it’s an expected behavior and a product feature, rather than a
vulnerability or bug.

However, in many GitHub boilerplate repositories to help companies deploy Ray to
their cloud environment, Ray remains vulnerable not only to the CVEs that were
successfully fixed (running Ray versions between 2.6.3 - 2.8.0), but also
ShadowRay—because Ray’s dashboard always binds on 0.0.0.0 (all network
interfaces), together with port forwarding on 0.0.0.0, possibly exposing the
machine to the internet by default [8].




HOW CAN LACK OF AUTHORIZATION BE ABUSED?

Ray does not include any kind of authorization in its Jobs API. The result:
anyone with dashboard network access (HTTP port 8265) could potentially invoke
arbitrary jobs on the remote host, without authorization. 

According to Ray’s official documentation, the security best practices begin
with the following:

> ”... Security and isolation must be enforced outside of the Ray Cluster. Ray
> expects to run in a safe network environment and to act upon trusted code.
> Developers and platform providers must maintain the following invariants to
> ensure the safe operation of Ray Clusters …” [9]

Ray includes code execution capabilities by design, so Anyscale believes the
users should be responsible for its locality and security. The dashboard should
either not be internet-facing, or be accessible only to trusted parties. Ray
lacks authorization based on an assumption that it will run in a safe
environment with proper routing logic: Network isolation, Kubernetes namespaces,
Firewall rules, or Security Groups.

When we discussed these issues with industry experts, we found that they were
not aware of the Jobs API in Ray’s Dashboard, nor had they heard about this CVE
disclosure.

For example - Ray’s official Kubernetes deployment guide [10] and Kuberay’s
Kubernetes operator encourage people to expose the dashboard on 0.0.0.0:




Kuberay’s Kubernetes operator encourage people to expose the dashboard on
0.0.0.0

AI experts are NOT security experts—leaving them potentially dangerously unaware
of the very real risks posed by AI frameworks.

Without authorization for Ray’s Jobs API, the API can be exposed to remote code
execution attacks when not following best practices. The CVE is tagged as
“disputed” - In these cases, the CVE Program makes no determination as to which
party is correct.

> A “DISPUTED” tag in a CVE Record could be for one (or more) of any number of
> reasons, for example, questions of accuracy, completeness, or whether the bug
> in question is, in fact, a security hole at all [11]

Disputed tags make this kind of attack difficult to detect, with many scanners
simply ignoring a disputed CVE. Users may not be aware of the risk, even with
the most advanced solutions available in the market.

According to Anyscale, this issue does not constitute a vulnerability, but is
instead a feature essential to Ray's design, enabling the triggering of jobs and
execution of dynamic code within a cluster. While an authorization feature is
recognized as a technical debt that will be addressed in a future version, its
implementation is complex and may introduce breaking changes. Therefore,
Anyscale decided to postpone its addition and disputed CVE-2023-48022 [6].

This approach reflects Anyscale's commitment to maintaining Ray's functionality
while prioritizing security enhancements. This decision also underscores the
complexity of balancing security and usability in software development,
highlighting the importance of careful consideration in implementing changes to
critical systems like Ray and other open-source components with network access.




LACK OF VISIBILITY

Due to the disputes surrounding whether it constituted a vulnerability,
ShadowRay (CVE-2023-48022) did not appear in several databases. This created a
blind spot: security teams around the world had no idea that they could be at
risk. Let’s look at how ShadowRay is portrayed by MITRE and OSV, for example.




MITRE:

While receiving a critical score of 9.8, it is currently tagged as “disputed” on
MITRE [7] .The description explains why:

> Anyscale Ray 2.6.3 and 2.8.0 allows a remote attacker to execute arbitrary
> code via the job submission API. NOTE: the vendor's position is that this
> report is irrelevant because Ray, as stated in its documentation, is not
> intended for use outside of a strictly controlled network environment [12]


A note from the disputed CVE



OSV 

Google’s Open Source Vulnerability Database did not contain this vulnerability
[13]. We opened an issue to understand why.
Because it was disputed, this vulnerability will likely be suppressed in SCA and
SAST tools that rely on CVE for vulnerability management, which decreases the
overall awareness of this CVE.

This means that this disputed CVE is actually a Shadow Vulnerability [14]  - one
that has already been leveraged by attackers and will be leveraged at increasing
rates.

CVEs tagged as “Disputed” with a high vulnerability score (9.8) are very
interesting. While invisible to scanning tools, they can pose massive risks.




EXPLOITED RAY CLUSTERS IN THE WILD: WHAT SENSITIVE DATA WAS COMPROMISED?

When attackers get their hands on a Ray production cluster, it is a jackpot.
Valuable company data plus remote code execution makes it easy to monetize
attacks—all while remaining in the shadows, totally undetected (and, with static
security tools, undetectable).

A trove of sensitive information has been leaked via the compromised servers.
Let’s dive into the specific information we uncovered.

 * AI Production Workloads were compromised, meaning an attacker could affect an
   AI model's integrity or accuracy, steal models, and infect models during the
   training phase. Impacted organizations came from many industries, including
   medical companies, video analytics companies, elite educational institutions,
   and many more.
   ‍


Sensitive Environment Variables or the Ray process inside a compromised machine
that was running Ray with internet access, exposing OpenAI, Stripe, Slack, and
DB credentials.

Cluster Dashboard with Production workloads and active tasks

AI model in action: handling a query submitted by a user in real time. The model
could be abused by the attacker, who could potentially modify customer requests
or responses.
 * Production DB Credentials were exposed, allowing attackers to download
   complete databases silently. On some machines, attackers could modify the
   database or encrypt it with ransomware.


Production database credentials
 * Passwords - We saw evidence that the attackers have stolen password hashes
   from the machines - using a simple cat /etc/shadow, which was successfully
   executed multiple times in the job history.


Ray jobs history is visible from the dashboard: Attackers stole passwords and
opened a reverse shell
 * Private SSH keys - We have found several private SSH keys that can be used by
   attackers to connect to more machines from the same VM image template (like
   AMI), reaching more compute capability for crypto-mining campaigns or simply
   gaining persistence in the environment.


AWS cluster machine credentials - allows connecting via SSH to all the machines
in the cluster.
 * OpenAI Tokens - We found OpenAI tokens that attackers could use to gain
   access to OpenAI accounts, which could be used to drain the impacted
   company’s credits on the OpenAI platform. The compromised tokens we found
   were all disclosed to OpenAI through the official bug bounty program [15].




 * HuggingFace Tokens - (access to private repositories) - We found HuggingFace
   tokens that enable adding and overriding existing models. Attackers could use
   the account’s repositories for supply chain attacks, potentially reaching
   other machines by uploading models to the platform or overriding existing
   ones.


 * Stripe Tokens - We found Stripe tokens that attackers could use to drain
   payment accounts by signing their transactions on the live platform.


 * Access to the Cloud Environment (AWS, GCP, Azure, Lambda Labs) - Many of the
   clusters ran with high privileges (root).


Attackers had access to sensitive cloud services, potentially leaking sensitive
production data: complete databases with customer data, codebases, artifacts,
and secrets.
 * KubernetesAPI access - Enables attackers to infect cloud workloads, steal
   Kubernetes secrets, and more.


Kuberay Operator running with Administrator permissions on the Kubernetes API.


‍

 * Slack Tokens - We found Slack tokens that attackers could use to read an
   impacted organization’s Slack messages or send arbitrary messages to certain
   channels on Slack.
   



‍




THE FINANCIALS: WHAT IS THE COLLECTIVE VALUE OF THE COMPROMISED MACHINES?

Most of the GPU models we found compromised are currently out of stock and are
hard to get. For example, the A6000 GPUs from the machine above are out of stock
on NVIDIA’s website:


nvidia-smi output from a compromised machine

Source: NVIDIA Shop

‍

As of now, Oligo has found hundreds of compromised clusters. Each cluster
consists of many nodes, which are machines connected to the cluster over the
network. Most nodes have GPUs, which are leveraged by attackers for
cryptocurrency mining, making this infrastructure an even bigger target for
attacks.

In other words, attackers choose to compromise these machines not only because
they can obtain valuable sensitive information, but because GPUs are very
expensive and difficult to obtain, especially these days.

The on-demand price of a GPU machine depends mostly on the GPU type and memory.
At the time of writing, GPU on-demand prices on AWS can reach an annual cost of
$858,480 per machine.

The total amount of machines and compute power that might have been compromised
can be estimated to be worth almost a billion USD, based on the clusters we
observed in the last few weeks alone. Moreover, the first evidence of an attack
that we have observed is from September 5th, which gave the attackers at least 7
months to leverage the hardware.

Attackers are doing the same math.




DO TARGETED CLUSTERS HAVE ANYTHING IN COMMON? (CRYPTO MINERS)

Most of the clusters Oligo Research has identified and reported were already
hacked with crypto-miners or reverse-shells. We noticed some patterns along the
compromised clusters, indicating that they were targeted by the same attackers.

Oligo Research Team has identified crypto-mining campaigns that leverage
ShadowRay to hack organizations and install cryptocurrency miners of different
kinds.

The first crypto-miner we noticed was installed on Feb. 21, 2024. Using public
web intelligence tools, we discovered that the IP has been accepting connections
to the target port since Sept. 5, 2023, indicating the breach might have started
before the vulnerability was disclosed. Due to the scale of the attacks and the
chain of events, we believe the threat actors are probably part of a
well-established hacking group.

We uncovered crypto miners including:

 * XMRig Miners - some of them running in a volatile manner, in-memory, without
   being downloaded to disk.


XMRig crypto miner connected to Zephyr mining pool

XMRig crypto miner with the attacker's email address (username)

Multiple XMRig miners, one of them is running with root user

Established connections to mining pools

History from a compromised machine: attackers download and run XMrig crypto
miner in the background

‍


Attackers download a privilege escalation payload to gain root access without
sudo on the machine

 * NBMiner
   


Downloading NMBiner and running it in the background
 * Java-based Zephyr miners


Proprietary miner executed as Java .jar file, with is connected to
miningocean.org



TRACING THE ATTACKERS

Usually, the command line used includes the unique username AND password of the
attacker. Miners must connect to a centralized server to function. The server it
communicates with is also present in the command line. In one example,
zephyr[.]miningocean[.]org was used. We looked at the mining pool and managed to
identify the attacker in the leaderboard:


There are thousands of miners in the mining pool

The attackers already have squeezed juice from the machines, reaching 148th
place out of 3216 miners in this pool, placing them in the top 5% of miners in
the mining pool.


The attacker have reached 148th place out of 3216



REVERSE SHELLS (GAINING PERSISTENCY)

We found multiple reverse shells that enabled the attackers to run arbitrary
code in the production environment, and gain persistence on its machines:


Opening a reverse shell through a tunnel
 * Active reverse shells


Python pty spawning with dup() and dup2() syscalls
 * Attackers open reverse shells successfully:


The image above wasthe oldest record of reverse shell we observed on a Ray
cluster, executed on September 5th, 2023

An attacker-controlled IP address that served the payload

Successful reverse shells found in the jobs history

‍


ATTACKERS ARE LEVERAGING THE OPEN-SOURCE SERVICE INTERACTSH TO EVADE DETECTION

The following job was inspected on a compromised ray cluster:


base64 encoded payload

The domain oast[.]fun was hiding in the payload as base64. Here is the decoded
payload that attackers successfully ran on the Ray clusters:


Decoded base64 payload

The attackers tried to evade detection by using a base64 encoded Python
code.When decoded, the Python code dispatches DNS query to a subdomain under
oast[.]fun.

We looked at the certificate history of this domain: https://crt.sh/?q=oast.fun
and found that the first Let'sEncrypt certificate is from 2022:


Let'sEncrypt certificate for the domain from 2022

After a quick search, we understood that this domain is connected to the
interactsh open source service:
https://github.com/projectdiscovery/interactsh?tab=readme-ov-file#using-self-hosted-server
‍

The domain oast.fun is one of the public servers the project maintains.



The default page on the public server

The attackers have leveraged the free public servers to avoid detection. When
the attackers successfully execute the base64 payload using the Jobs API, a DNS
query is invoked from the compromised machine to the attacker-controlled free
subdomain. By invoking the DNS query from the compromised machine, the attackers
immediately received a notification about the compromised machine’s IP address:



An example of interactsh usage: The attacker receives out-of-band notifications
about DNS queries from clients in real time.

The same tool is known to be used by threat actors, as mentioned in the article
by Palo Alto's Unit 42:

> ‍Even though Interactsh can be used for legitimate purposes, it is widely used
> by attackers to test malicious traffic. Its testing traffic therefore could be
> followed by a series of exploits. [16]

‍


WE STARTED INVESTIGATING THE PAYLOADS OF THE REVERSE SHELLS

We delved into the reverse shell payload from bit[.]ly/akuhGet.The file content
made it clear: The attackers tried to escalate their privileges using sudo,
which was not present on the attacked machine. The attackers used the service
www[.]akuh[.]net using an open source repository.


The script used by the attackers is open source:
https://github.com/akuhnet/wqemu/blob/main/su.sh

‍

Virus Total did not raise any red flags:



VirusTotal has no detections for the payload (0/59)



INDICATIONS OF COMPROMISE (IOCS)

DescriptionTypeValueDescription IP Address23.146.184.38/Reverse Shell Endpoint
#1IP Address54.176.108.174/Reverse Shell Endpoint #2IP
Address158.247.217.90/Reverse Shell Endpoint #3IP Address206.189.156.69/Reverse
Shell Endpoint #4Domain Nameclo4q41v1v85ed814bogstepb5jwkbxtj.oast.fun/Reverse
Shell Endpoint #5Domain Namebore.pub/Mining Pool Endpoint #1Domain
Namexna.2miners.com/Mining Pool Endpoint #2Domain Namekryptex.network/Mining
Pool Endpoint #3Domain Namezeph.kryptex.network/Mining Pool Endpoint #4Domain
Namezeph.kryptex.network/Mining Pool Endpoint #5Domain
Namepool.hashvault.pro/Mining Pool Endpoint #6Domain
Namezephyr.miningocean.org/Mining Pool Endpoint #7Domain
Namerx.unmineable.com/VirusTotal Reverse Shell Payload #1VirusTotal
Hash98f0bf732ebae8f3ba250c02e02a0787a68039caa484e688e0391343eaf0b527Reverse
Shell PayloadMD5 Hashf3636232ed136fed658521682f6fa9f4Reverse Shell PayloadSHA1
Hash8d53ade3599ca39d9ad22d9360834514e9a6c6dcAttacker Email - found in the logs
of a compromised machineEmail Addressfintagixgames[at]gmail[.]comAttacker Wallet
Address - found in the logs of a compromised machineZEPHYR Wallet
AddressZEPHYR3KfKQNQrfBwHtsEWyuLn1nzXvjAraxAVBuoKrKFHn3pgtqLqX96h3sWa5kP4Y2i48a4RZnbBQoivU6dQCcFTyTHDofzW55




IP GEOLOCATIONS:


Source: maxmind.com

‍




RESPONSIBLE DISCLOSURE

The Oligo research team has actively notified numerous companies through
responsible disclosure while providing further details and assistance with
remediation.




DETECTION AND MITIGATION IN RUNTIME

Shadow vulnerabilities will always exist, but without CVEs that are visible in
build time, these vulnerabilities are invisible to SCA and SAST approaches. Code
and Static Testing alone don’t hold the complete context about what is deployed.

To detect Shadow Vulnerabilities, the runtime environment, which includes the
exploit indicators, must be monitored continuously. The signs of an exploit
vary, potentially triggered by specially-crafted input, loading data from
untrusted sources, missing firewall rules, behavior of dependencies that are not
taken into account, and more.




MITIGATION STRATEGIES

 * Follow the best practices for securing Ray deployments [9]
   * Start with running Ray within a secured, trusted environment.
   * Always add firewall rules or security groups to prevent unauthorized
     access.
 * Add authorization on top of Ray Dashboard port (8265 by default):
   * If you do need Ray’s dashboard to be accessible, implement a proxy that
     adds an authorization layer to the Ray API when exposing it over the
     network.
 * Continuously monitor your production environments and AI clusters for
   anomalies, even within Ray.
   * Ray depends on arbitrary code execution to function. Code Scanning and
     Misconfiguration tools will not be able to detect such attacks, because the
     open-source maintainers of Ray (Anyscale) marked it as disputed and
     confirmed it is not a bug—at the time of writing, it is a feature.
   * Don’t bind on 0.0.0.0 to make your life easy - It is recommended to use an
     IP of an explicit network interface, such as the IP that is in the subnet
     of your local network or a trusted private VPC/VPN.
   * Don’t trust the default - Sometimes tools assume you read their docs. Do
     it.
   * Use the right tools - The technical burden of securing open source is
     yours. Don't rely on the maintainers, there are tools that can help you
     protect your production workloads from the risks of using open source in
     runtime.

We’re also hosting a threat briefing where we’ll go over the potential impacts
of ShadowRay, as well as essential mitigation steps.

BOOK A 1:1 BRIEFING WITH OUR RESEARCH TEAM






SUBSCRIBE TO OUR UPDATES AND BE THE FIRST TO LEARN ABOUT THE NEXT CYBER ATTACKS




SPECIAL THANKS

We want to thank Anyscale, first of all for creating Ray, which is truly an
awesome open-source framework. We were also incredibly impressed by Anyscale’s
security team, which responded quickly and cooperated fully with our team,
clearly demonstrating real concern for the safety of Ray users and the
community. Additionally, we want to thank Bishop Fox [2], Bryce Bearchell [3],
and Protect AI[4] for their amazing prior work on findings and for disclosing
vulnerabilities responsibly.




OLIGO RESEARCH TEAM

Oligo Research Team is a group of experienced researchers who focus on new
attack vectors in open source software. The team identifies critical issues and
alerts Oligo customers and the technology community about their findings. The
team has already reported dozens of vulnerabilities in popular OSS projects and
libraries, including Apache Cassandra, Atlassian Confluence, and PyTorch.


AVI LUMELSKY

Avi has a relentless curiosity about business, AI, security—and the places where
all three connect. An experienced software engineer and architect, Avi’s
cybersecurity skills were first honed in elite Israeli intelligence units. His
work focuses on privacy in the age of AI and big data.


REFERENCES

[1]
https://www.anyscale.com/blog/update-on-ray-cves-cve-2023-6019-cve-2023-6020-cve-2023-6021-cve-2023-48022-cve-2023-48023
‍[2] https://bishopfox.com/blog/ray-versions-2-6-3-2-8-0
‍[3] https://huntr.com/bounties/787a07c0-5535-469f-8c53-3efa4e5717c7/
‍[4] https://protectai.com/threat-research/november-vulnerability-report
‍[5] https://github.com/ray-project/ray
‍[6] https://www.anyscale.com/
‍[7] https://cveawg.mitre.org/api/cve/CVE-2023-48022
‍[8]
https://docs.ray.io/en/latest/ray-observability/getting-started.html#set-up-dashboard
‍[9] https://docs.ray.io/en/latest/ray-security/index.html
‍[10] https://github.com/ray-project/kuberay/tree/master/helm-chart/ray-cluster
‍[11]
https://www.cve.org/Media/News/item/blog/2024/01/30/CVE-Records-DISPUTED-Tag-Clarification
‍[12] https://nvd.nist.gov/vuln/detail/CVE-2023-48022
‍[13] https://github.com/google/osv.dev/issues/2038#issuecomment-1996386489
‍[14] https://www.youtube.com/watch?v=tQEkqgOMA8Q
‍[15] https://forms.gle/h8bQ5YKWzXb8FtrQ8
‍[16] https://unit42.paloaltonetworks.com/exploits-interactsh/


SUBSCRIBE AND GET THE LATEST SECURITY UPDATES





ACCELERATE DEVELOPMENT WITH RUNTIME APPLICATION SECURITY AND OBSERVABILITY

Streamline security by pinpointing your attention at the exploitable
vulnerabilities, gain the trust of your development team by keeping them focused
on the relevant issues.

Book A Demo


Oligo Focus
Oligo ADR
About
Resources
Blog
Case studies
News
Contact Us
Book a Demo
Copyright © oligo Runtime Application Security and Observability | All Rights
Reserved 2024
Terms of use
Privacy Policy

Manage Cookies

When you visit web sites, they may store or retrieve data in your web browser.
This storage is often necessary for basic functionality of the web site or the
storage may be used for the purposes of marketing, analytics, and
personalization of the web site such as storing your preferences.



Powered by Privado

Save

By Clicking on "Accept", you agree to the storing of cookies on your device to
enhance site navigation, analyze site usage, and assist in our marketing
efforts.

Cookie Settings Deny All Accept All