Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing Vulnerable Vote Function #15

Closed
Ronnieraj37 opened this issue Mar 5, 2024 · 4 comments
Closed

Fixing Vulnerable Vote Function #15

Ronnieraj37 opened this issue Mar 5, 2024 · 4 comments

Comments

@Ronnieraj37
Copy link
Contributor

Ronnieraj37 commented Mar 5, 2024


Fixing Vulnerable Vote Function

Analysis of Attack

This vulnerability arises from the ability to manipulate the voting process by inserting fake user addresses into the contract. Malicious actors could exploit this weakness to cast fraudulent votes, undermining the credibility and fairness of the election.

Risk - High

Likelihood - High

function vote(address _voter, uint _candidateID, uint weight,uint[] memory voteArr) external {
        require(getStatus() == Status.active, "Election needs to be active to vote");
        // if (electionInfo.electionType==0) {
        //     require(isAuthenticated(msg.Sender),"Voter must be authenticated to cast vote");
        // }
        ballot.vote(_voter,_candidateID, weight,voteArr);
        voterCount++;
        emit VoteCasted(address(ballot),candidateWithID[_candidateID],weight);
    }

This code snippet is vulnerable because it allows anyone to directly use the Diamond Proxy contract's address to cast a vote, bypassing any authentication or authorization checks based on the sender's identity (msg.sender).

Here's how the attacker can exploit the vulnerability using the provided JavaScript code

async function voteLoop() {
	while (true) {
	const wallet = ethers.Wallet.createRandom();
	const voterAddress = wallet.address;
	// Call the vote function
	const tx = await contract.vote(voterAddress, candidateID, weight, voteArr);
	await tx.wait();
	}
}

As the attacker's loop continues to execute indefinitely, it effectively floods the contract with fraudulent votes, potentially overwhelming the contract and disrupting its functionality.

Possible Implementation

To mitigate this vulnerability, the code should be updated to ensure that only authorized users are allowed to cast votes, possibly by using msg.sender for authentication checks instead of relying solely on the _voter parameter.

@a-singh09
Copy link

a-singh09 commented Mar 16, 2024

Hi there, I made a PR fixing this issue.

The updated vote function now checks if the sender is authenticated before proceeding with the voting process. The authentication was already being done in Authentication.sol, so its instance is created in Election.sol and later a require() statement is used to allow only authenticated users.

@Ronnieraj37
Copy link
Contributor Author

@a-singh09 I've fixed this issue already and was waiting for @harsh-mr to reply first. Secondly the issue you've solved is not complete as the function is still vulnerable. The vote function can be manipulated to fake votes as I can just use the contract address to hinder the elections by passing my own arguments while voting posing to be another voter.

@a-singh09
Copy link

Hey, wasn't aware of you already fixed this issue and secondly, modified my code as per your suggession.

@Ronnieraj37
Copy link
Contributor Author

Ronnieraj37 commented Mar 17, 2024

Hey, I've fixed the issue on local but didn't commit the PR as I was waiting for confirmation from Mentors. Your code still holds vulnerability. I'll Pull a PR for this issue soon, you can have a look at it !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants