Meet acciobugs

Hi, I'm Ileana Barrionuevo (@acciobugs) from Córdoba, Argentina! I work as a security engineer and also teach Secure Software Development at the Universidad Tecnológica Nacional - Facultad Regional Córdoba. As a security researcher, I focus on web and mobile vulnerabilities. I’m a big fan of CTFs and enjoy speaking at InfoSec conferences. Last year, I had the incredible experience of speaking at DEFCON for the first time!

How did you get into AI/ML bug bounty hunting? What parts of it do you enjoy?

I'm a big fan of code review, so when I saw new AI/ML projects to analyze on huntr, I thought it was worth checking if security had been considered, especially since many are used by big companies. I was surprised to discover basic security bugs, which made it clear that these projects need serious code inspection!

I particularly enjoy deploying the project locally, debugging the app to understand its behavior, and conducting a black-box pentest. I then complement that analysis with white-box testing, as I have access to the source code.

How did you discover huntr and what has your journey been like? 

Uncovering Improper Access Control Vulnerabilities in lunary-ai/lunary: A Deep Dive by acciobugs

Recently, @acciobugs identified a significant Improper Access Control (CWE-284) vulnerability in lunary-ai/lunary, an open-source platform designed to manage AI projects across multiple teams. This vulnerability allowed users to manipulate project and user assignments across different organizations, leading to unauthorized privilege escalation.

Here’s a look into @acciobugs' journey in finding and exploiting this vulnerability.

What Can an Attacker Do?

Due to improper backend controls, a member with team management permissions could:

• A) Manipulate user invites to force users into joining projects from other organizations.
• B) Change team members to other organizations' projects, escalating their privileges.
• C) Move other organization's users into projects under their own control or another project, allowing unauthorized privilege escalation.

This was all possible because the backend did not properly validate project identifiers when performing these actions, leaving the system open to abuse.

Step-by-Step Process

Let’s focus on case C, which demonstrates how an attacker can manipulate other organization members into joining different projects and escalate their privileges.

1. Play with the platform and understand how it works.
The platform's structure manages:
Organization > Project > Owner > Team members (Admins, Viewers, Prompt Editors, etc.).

2. Send a request to change a member from another organization to a project that doesn’t belong to them, or even into a project from your own organization. By modifying the project identifier in the request, you can assign roles such as Admin or Owner to that user, giving them full permissions in the project.

Here’s the modified request:

3. See the changes applied.
After sending the request, the platform accepts the project changes without validating the user's organization. The affected user ends up in a project they don’t own, and the attacker successfully escalates their privileges to an Admin or Owner role.

Here’s the result: