As you may know, blockchains such as Ethereum, Polygon, Binance Chain, Optimism etc use EVM, Ethereum Virtual Machine, as the underlying environment to execute the transaction and run the smart contracts. The EVM itself is a stack based architecture as opposed to register based architecture which is more common among the traditional processors and computers. In this article we will shed light on the architecture of EVM and why flaws like stack-too-deep occur in smart contracts.

EVM:

Before diving into the architecture, let us first define an EVM and explain how it works. So EVM is an abbreviation for Ethereum Virtual Machine, and it is the execution component responsible for running and executing smart contracts on Ethereum and other blockchains utilizing bytecode stored on the chain. It is a sandboxed virtual machine that runs on each node in the Ethereum network and is in charge of keeping the blockchain alive. The EVM is platform-independent and may be implemented in any programming language. This enables developers to create smart contracts in well-known programming languages such as Solidity, Vyper, and others. After writing the contract, it is compiled into bytecode and deployed to the EVM.

When we state that EVM is a stack-based machine, we mean that it operates on a data structure called a stack, which holds values and executes actions. The EVM has its own set of instructions known as opcodes that it uses to execute tasks such as reading and writing to storage, calling other contracts, and performing mathematical operations. This enables Ethereum to support a wide range of decentralized applications, from simple token systems to large decentralized autonomous organizations (DAOs).

What is Stack Based Architecture:

So, what is a stack-based architecture? It is a sort of computer architecture that stores values and performs actions using a stack data structure. The stack operates on a last-in, first-out (LIFO) basis, which means that the most recently inserted item is stored at the top of the stack and is the first item removed. The program’s instructions and data are kept in memory in this architecture, and the program’s execution is controlled by a stack pointer that points to the top of the stack. The stack pointer keeps track of where the next value or instruction will be saved or retrieved on the stack.

When a program runs, it adds values to the stack and performs operations on the values that are already there. When a code wants to add two numbers, it pushes the numbers onto the stack and then performs the addition operation on the top two values. The result is then returned to the stack.

One of the most important characteristics of a stack-based architecture is that it allows for highly simple and efficient operation execution. Because the stack is a LIFO data structure, it enables for easy and quick data and instruction handling. This makes it ideal for usage in virtual machines like the Ethereum Virtual Machine (EVM), which must do a huge number of operations in a short period of time.

Register Based Architecture:

The other type of architecture is register-based architecture, it is a sort of computer architecture in which the primary storage for data and instructions is a set of registers within the CPU. Unlike memory-based architectures, such as stack-based architectures, in which data is kept in main memory and accessed by memory addresses, data in register-based architectures is stored directly in the CPU and accessed directly by the CPU’s registers. We will not delve more into this architecture because it is not relevant to the topic.

Types of Storage In EVM:

If we talk about the architecture of EVM, it’s storage can be further divided into four main components that are used to store and access the data during execution, namely EVM Stack, EVM Memory, EVM Storage and Calldata.

EVM Stack:

The Stack is the main component of the whole stack-based architecture, it is the data structure in which the values are stored and operations are executed. It is used to store the operands for mathematical and logical operations, as well as the return values for function calls. The size of the stack or stack depth is 1024 items, and each item is 256 bit word with a total of 16 slots. Each item is pushed on top of the stack and removed from there as well, the opcodes that are used to perform these tasks on the stack are PUSH/POP/SWAP/DUP.

EVM Memory:

The second component is the EVM Memory, it is the volatile memory in the architecture whose data is not persistent across the blockchain, meaning the memory is a random-access data structure that stores temporary data during the execution of a smart contract. It is used to store variables and data structures that are not needed to be stored in the storage. The memory can be resized during the execution of a smart contract, but it is slower and more expensive to access than the stack. The memory is zero initialized and the opcodes that are used for accessing the memory MLOAD, MSTORE, MSTORE8

EVM Storage:

Third one is EVM Storage, which is a non-volatile storage and holds key-value pairs of 256 bits -> 256 bits. The total number of storage slots in a contract is 2²⁵⁶ which is a relatively huge number of slots and each smart contract on the blockchain has its own storage space. During function calls it is used for data that needs to be remembered between function calls. It is used to store variables and data structures that need to be available even after the smart contract execution has ended. The opcodes for accessing storage are SLOAD and SSTORE

CallData:

The last component for storing data is the Calldata, which is a read-only memory. The calldata is laid-out and behaves in the same way as memory does, the only major difference is that it is read-only space where the data parameter of a transaction or a call is held. To use the data in calldata you have to specify byte offset and number of bytes that you want to read. The opcodes that are used for calldata are CALLDATASIZE, CALLDATALOAD, CALLDATACOPY

How Stack-Too-Deep Happens:

Despite its benefits, this architecture has numerous drawbacks. For example, the stack-based architecture is not very good at handling complex data structures like linked lists or trees, which

might be more difficult to handle using a stack. Aside from that, there are some faults that can occur in smart contracts as a result of this architecture, most notably the ‘stack too deep’ issue.

So, what is a stack too deep? When a function or contract exceeds the maximum depth of the call stack, the “stack too deep” error occurs. Assume you call a function in your contract, and each time a function is called, a new frame is added to the stack, and when the function returns, the top frame is removed. In order to prevent infinite recursion and other stack overflow issues, the maximum depth of the call stack in EVM is limited. The maximum stack depth in Solidity is 1024 items with each one of them being 256 bit words. Furthermore, the EVM can only access stack items that are up to 16 slots distant from the top-most slot. So if you push more than 16 items into the stack and then try to retrieve the 17th item, EVM will throw the “Stack too deep” error.

A “Stack too deep” error can occur when a function or contract repeats itself recursively too many times, or when another function calls the original function again, surpassing the maximum stack depth, which means that the number of objects on the stack surpasses 16. It also occurs when functions have an excessive number of local variables, parameters, or return values. It may also occur as a result of infinite recursion, a long chain of contract calls, or a mix of the two.

Why Stack Depth Is Only 1024:

You may be thinking why the stack depth is so undersized, or isn’t there a way to increase the depth?

The key rationale for keeping the depth at 1024 is that if the depth were higher, the contracts would be more expensive to execute since they would require more memory, hence 1024 is a fair choice for the depth limit. Furthermore, having a dynamic depth is troublesome since having a fixed sized depth simplifies the implementation of the EVM. Furthermore, the EVM can only access objects on the stack up to 16 spaces away from the top-most slot. So, even if you had a 4096 items stack, and you could put everything in a 4096 items stack, you’d only have direct access to data stored 16 slots down from the top.

Conclusion:

That was a basic overview of the stack-based architecture of EVM and what data storage components are used and how stack-too-deep issues arise because of the architecture. The EVM’s functionality is complicated, yet it is accessible to novice developers, resulting in a plethora of decentralized apps. However, EVM is not without flaws. The system is also plagued by problems with network throughput and transaction speed. These are now critical issues for the Ethereum development community to address, and tackling them provides a roadmap for Ethereum’s continued use and success.

When solidity 0.8 was rolled out in Dec 2020 it solved a very characteristic problem in the language, integer under & overflow, that used to arise because of how programming languages are designed. Integer overflow and underflow attacks can have significant consequences in a smart contract, potentially leading to security vulnerabilities with loss of funds. This was a major challenge that blockchain developers had to overcome to make sure that their contracts are secure against these flaws and that any malicious actor would not be able to exploit the logic for monetary gain.

For this purpose, several approaches were used before like using an external SafeMath library. Since Solidity 0.8 was released, it solved this issue, and now the compiler checks on each arithmetic operation whether the variables are overflowing or underflowing by default and throws an error accordingly so developers don’t have to focus on the issue. But despite this scrutinization of solidity 0.8 there are several ways through which variables can still overflow. In this article, we will explore how compiler version 0.8 and above protect against overflow and what are the ways through which it can still happen.

What are Integer Underflow/Overflow:

Let’s define what we mean by integer overflow and underflow. They occur when an integer variable exceeds the maximum value that can be stored in that variable type, similarly, an underflow occurs when the variable goes below the minimum value that can be stored. Let’s take an example of uint8 in solidity, the maximum value allowed in uint8 is 255 and the minimum is 0. Now when you store 256 in a uint8 variable, it will overflow and the value will become 0, if you store 257 it will become 1, for 258 it will become 2, and so on. In simple terms when an integer overflow occurs, the value of the integer variable will be reset to the minimum value that can be stored in that variable plus the exceeded value. Similarly, if you try to store -1 in the uint8 variable the value of the variable will become 255, and so on as it will underflow.

Overflow and underflow can also happen if you subtract or add in the minimum or the maximum value stored in the variable. This can cause problems in your code because it can lead to unexpected results. This was one of the most common attack patterns before the advent of solidity 0.8. Suppose you are using an integer variable to keep track of the counter or more specifically to count the number of tokens held by a user, and through a specific functionality the attacker can underflow or overflow the variable then it could lead to repercussion like the variable exceeds the maximum value, it will be reset to the minimum value and start from there all over again. In case of underflow, the value will be set to maximum and the attacker could get an extremely large amount of tokens making it inflationary.

Integer underflow/ overflow is not a design flaw in computer science but it could have serious effects, depending on the program, especially in solidity and other blockchain-specific languages and framework due to the nature of how decentralized applications work considering most of the applications in Web3 are Defi (Decentralized Finance) apps.

In the past many hacks have occurred because of Integer overflow/ underflow vulnerability which include the infamous BeautyChain(BEC) contract attack, hack on the 4chan’s ponzi scheme which was called Proof of Weak Hands Coin(PoWHC), and the attack on Coinstar(CSTR) token that happened because of mintToken function.

How Solidity 0.8 protect against Integer Underflow/Overflow:

When Solidity 0.8 was launched in December 2020, it resolved this issue in the language by making some groundbreaking alternation, particularly by changing the opcodes in the language for arithmetic operations which now have built-in overflow and underflow checks and reverts upon failure.

So, how does Solidity 0.8 protect against integer overflows and underflows?

One way is through the use of built-in safe math functions. These functions, which are provided as part of the Solidity standard library, include add, sub, mul, and div, and they perform arithmetic operations on integers while checking for overflows and underflows. If an overflow or underflow occurs as a result of the operation, the function will throw an exception and the operation will not be carried out.

There are also opcodes that help the compiler in detecting overflows and underflows in the code, some of the common ones are ADDMOD, MULMOD and SMOD. The way they work are defined as follows:

ADDMOD: The first opcode is ADDMOD, this opcode performs an addition operation on two integers, takes modulus, and checks whether the remainder is greater than the maximum value of datatype, if the remainder is greater than the allowed datatype then the transaction would revert.

Suppose in the case of two integers a and b of type uint256 ADDMOD will do the operation (a+b) % N, where N is the maximum value of the datatype, and checks whether the result is greater than 2²⁵⁶-1 if it would be greater than the transaction would revert otherwise not. Similarly, for uint8 it will check the return against 2⁸-1 and so on.

MULMOD: Similar to ADDMOD, this code is used for multiplication operations. It takes two integers a and b and sends them through the formula (a*b) % N. If the result is greater than the uint, for uint256 it would be 2²⁵⁶-1, then the opcode will revert the transaction otherwise not.

SMOD: SMOD performs the unsigned modulo operation but returns the signed result. If the result of the modulo operation would cause an integer overflow the smod opcode will return zero instead of the result of the modulo operation.

These new operations can be used to perform arithmetic operations safely, as they will prevent integer overflow and underflow from occurring. Besides these opcodes, Solidity 0.8 also introduced a new type called uint256x, which is a fixed-size integer type with 256 bits of precision. This type is useful for cases where very large integer values are needed, as it does not suffer from integer overflow or underflow.

How Integer Underflow/Overflow Is Still Possible In Solidity 0.8:

Even after the update of solidity to 0.8, there are scenarios in which the integer overflow and underflow can still occur and in some cases, they can be exploited. Blockchain developers must be aware of these scenarios in order to safeguard their smart contracts from any potential vulnerabilities.

Typecasting:

The most common scenario where an integer underflow or overflow is possible is in Typecasting. This happens when you convert an integer of a larger uint data type to a smaller data type. Suppose you have stored the integer 256 in a variable of type uint256 and now you want to convert it into uint8. If you want to convert this integer from a variable of type uint256 to a variable of type uint8, you must be aware that doing so will cause the value to wrap around, overflow, and become 0. The variable will overflow and the solidity compiler won’t throw an error if done this way.. The simple solidity code that follows is a nice illustration of how overflow with typecasting can happen and how the solidity compiler overlooks it.

In the above code snippet, the value stored in b will be 9 instead of 265due to the fact that maximum value in uint8data type can be 255, so it will overflow and reset from 0. This is the simplest example of how typecasting allows integer overflow/ underflow in solidity 0.8. The code can be something complex that developers might miss during development.

Shift Operator:

The second way through which an integer overflow can occur is the use of a shift operator. Keep in mind that overflow & underflow checks are never performed for shift operations as they are performed for other arithmetic operations. The left shift << operator frequently causes integer overflow.

The following is the formula for left shift operation:

a << n = a * 2^n

This operator shifts all the bits in the first operand by the number specified in the second operand. Shifting an operand by 1 position is equivalent to multiplying it by 2, shifting 2 positions is equivalent to multiplying it by 4, and shifting 3 positions is equivalent to multiplying by 8. The below-specified code will overflow in solidity:

In the given code, left shifting a which is 100 by 2 positions b is equivalent to multiplying 100 by 4. So the result will be 400, but the maximum value allowed in a uint8 is 255, so the result will overflow and the value in c will be 144 because 400-256 is 144.

Inline Assembly:

The use of YUL or inline assembly in a solidity smart contract also makes integer overflow/ underflow possible even if the compiler version of solidity is 0.8. In YUL programming language, integer underflow & overflow is possible in the same way as Solidity and it does not check automatically for it as YUL is a low-level language that is mostly used for making the code more optimized, which does this by omitting many opcodes. Because of its low-level nature, YUL does not perform many security checks therefore it is recommended to use as little of it as possible in your smart contracts.

In the above code we are adding 1 into the variable a with inline assembly and then returning the result. Notice that the variable result will overflow and 0 will be returned, despite this the contract will not throw an error or revert.

Unchecked Code Block:

The last one is pretty obvious, which is to use the unchecked code block. Performing arithmetic operations inside the unchecked block saves a lot of gas because it omits several checks and opcodes that are used for overflow and underflow. The unchecked code blocks are very helpful in operations like looping through an array where it usually takes a lot of unnecessary gas for checks or doing arithmetic operations with no chance of over/underflow.

The purpose of an unchecked code block is to get granular control over the operations and write an efficient contract by skipping many opcodes that are used in default arithmetic operations in 0.8 to check for underflow/ overflow. The unchecked code block is only recommended if you are sure that there is no possible way for the arithmetic to overflow or underflow.

Conclusion:

Integer underflow and overflow are potential security vulnerabilities that can occur in Solidity code when arithmetic operations are performed on integers. These issues can lead to unintended end results and can potentially be exploited by attackers. Developers need to be aware of these issues and all the scenarios they can arise in and to properly handle them in their code to prevent potential exploits. In Solidity 0.8, new features such as the SafeMath library have been introduced to help mitigate the risk of integer underflow and overflow. It is recommended that developers use the updated compiler version to protect their smart contracts from these types of vulnerabilities. And despite using the updated version of Solidity the integer overflow/ underflow can still rise without even the developers noticing them therefore they need to be aware of the edge cases.

SSRF or Server Side Request Forgery is a type of vulnerability where the attacker can make the request on behalf of the vulnerable web server and can fetch any internal file from the server, this is the most precise summary of the bug I can come up with. It is one of the hottest bugs to find as the number of attacks through SSRF are growing. As web applications are becoming more and more complex and integrated, the chances for it getting vulnerable to SSRF attacks are also increasing. Moreover protecting your server from SSRF Attacks are a bit tricky for developers as every day more and more bypasses are coming. SSRF bugs are present on functionalities where the web application is fetching any data from the third part web applications. Some good examples of it are fetching an image trough URL, importing your files from services like DropBox or more specifically creating webhooks on the application. This article also assume that you can knowledge of basic pentesting tools like Burp Suite and Burp Collaborator.

HTML Injection:

Before I begin I would also like a explain HTML Injection in few words, HTML Injection is a bug in which the attacker can store or run the HTML code on the website by storing it or passing it in the parameters. HTML Injection is considered to be a low severity vulnerability and in most cases it is just considered as an Informational bug. Other than this an <iframe> tag in HTML is used to embed another document or webpage inside a current page. These two things can be used to escalate an HTML Injection into an SSRF attack which can undermine the privacy of the server.

Server Side Request Forgery through Html Injection:

There are many endpoints, functionalities and different ways to look at an SSRF vulnerability but today I will talk about only looking for SSRF through HTML Injection and more specifically HTML Injections in PDF File Generating Functionalities.

In most of the websites, specially in CRM web applications, we usually came across functionalities like Export In PDF or Generate a PDF Report. When we click on these buttons a PDF report in generated from the server and downloaded in our computer. These PDF generators in most cases are vulnerable to HTML Injections, and developers don’t even try to fix it because an HTML Injection in a PDF can never cause harm to anyone, but what they don’t realize is that through injecting an <iframe> tag in the PDF the attacker can look for SSRF Injection points and can could make a request on behalf of the server. I will be talking about looking for SSRF through HTML Injection and I will be taking an example of these PDF Generators.

These findings were made possible by the research of Nahamsec, which you can find at https://docs.google.com/presentation/d/1JdIjHHPsFSgLbaJcHmMkE904jmwPM4xdhEuwhy2ebvo/edit#slide=id.g5d4335792d_0_19.

Testing If SSRF attack could be possible here:

The first step in looking for Server Side Request Forgery through this way is to look for endpoints and parameters where you can inject the HTML Code. In most cases whenever you generate a PDF report, you usually have to fill in some parameters or sometimes some parameters like your name, message etc are reflected in the PDF. You have to inject a simple HTML code like <b>TESTING</b> into these inputs and see whether the server is rendering it as an HTML or not. If the code is getting rendered then you have move to the next step and now try to inject an <iframe></iframe> tag. Here you have to make sure of two things.

• That the src in <iframe></iframe> is making request to the third party websites.
• And that the IP from which the request is been made is not your own IP.

So now to test the endpoint further, you have to open your Burp Collaborator or you can also use your own server if you have one. Burp Collaborator is a network tool that is a part of professional version of Burp Suite, and this tool can be used to monitor the request that are made from any host or server.

On your collaborator generate a new payload and paste it in the src of your iframe tag. On the PDF generation, first you have to look if any request are made to your collaborator and if the requests are made then you have to look at the IP from which the request is made. Because the request must be made from the vulnerable server for SSRF and not from your own computer.

After it is confirmed that the host is making request to third party websites through an iframe injection. You now have to make the request to any internal file of the system and see if it is loading the contents of the file. For this purpose we mostly make the request to the /etc/passwd file using the protocol file://, so the whole URL and iframe code that you have to put in becomes <iframe src=file:///etc/passwd></iframe>. Pass it and if the server successfully shows you the contents of the etc/passwd file then the SSRF is confirmed. The contents of this file will be like following:

Now, here in most cases the websites have put protection and filters to stop any attacks on the server therefore making a request directly to an internal resource like /etc/passwd will most probably result in failure for the testers. But these protection can be bypassed in many ways, you can find a long list of bypasses at this github repository https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Request%20Forgery/README.md.

One of the bypass is using a redirect from your own site to the internal resource. What you have to do here is to create a PHP file on your website with the following code:

<?php

$address = "http://127.0.0.1/";
 
if(isset($_GET['link']))
{    
 $loc = $_GET['link']; 
} 

header('Location: '.$address);
?>

Let me explain the above code in easy words, this code will look for any address provided in the parameter link and redirect the user to that address and if no address is provided then by default it will redirect to http://127.0.0.1 which is considered as an internal IP of a server.

This file will take a URL link in its parameter link and then redirect the host to that URL address. Suppose we want to redirect the vulnerable server from our website to its internal file, then we will type in the following address https://yourwebsite.com/redirect.php?link=file:///etc/passwd. Here the name of your website is yourwebsite, the file in which the above code is stored is redirect.php and finally the location you want the vulnerable server to get redirected is given in the parameter link. In this way upon entering the iframe code like <iframe src=https://yourwebsite.com/redirect.php?link=file:///etc/passwd></iframe> in the place for HTML Injection you can bypass the protection that is placed against the SSRF attacks. If the contents of the etc/passwd file are shown in the iframe then congratulations you have pwned the security of the server and found an SSRF vulnerability.

My name is Faizan Nehal and I am doing bug and vulnerability hunting for almost a year now, before that I used to do Web Application Development. Beside working as a cyber security researcher I am also in my final year of my graduation program. In this article I will be sharing with some simple and basic 2-Factor Authentication related bugs and logic flaws that any beginner bug bounty hunter could easily look for:

1. Two-FA Bypass Through Password Reset Feature:

So, the whole reason behind 2-FA is to provide extra security to the user incase the user email and password gets compromised. But you can easily bypass this protection mechanism by looking for a simple logic flaw in the web application. All you have to do is to click on the password-reset button on the login page and generate a password reset link, open the link and change the password. On changing the credentials, if the web application logs you into the account then you have successfully found a 2-FA bypass on that particular website because of a flaw in its logic.

2. Two-FA Bypass By Sending A Blank Code:

This is another pretty common MFA Bypass vulnerability that happens because the server side don’t check for the verification code if there is no code present in the request. To reproduce these kinds of bugs, just type any random code or 000000 in the 2FA field, click on the login button and intercept the request in Burp. Inside the request, remove the random code you typed and forward the request with empty parameter. If successful response comes, then you have found a 2FA bypass.

3. Denial-Of-Service For Any Email Using 2FA:

You can also prevent someone from ever using the web application by locking their email using 2-Factor-Authentication. This bug is usually present on websites that allow you to use their application without verification of email. All you have to do is to create an account on the website using any random email address, then activate the 2FA in that account. In this way, if the real owner of email address will ever want to use the website in future, he will not be able to do so because he would need to MFA code to reactivate his account.

4. Session Authentication During 2FA Activation:

Improper session authentication during the activation of 2FA is another bug that you can look for as a beginner. All you have to do is to login to your account on two different devices. Now activate the 2FA settings on your account from the first device, if the session is still valid on your second device even after activation of MFA, then you have successfully found a simple 2FA session authentication bug.

5. Lack Of Rate Limiting On 2FA Request:

If the code are not generated using apps like Google Authenticator then you should definitely check for rate limiting and its bypasses. Because it is pretty common that developers forget to implement rate limits on these request. You can take help from Burp Intruder to implement these types of attack and to look for rate limiting bypass.

6. Login From Another Domain:

One other very common way of bypassing the 2FA protection is to try to login from another domain. Whenever you test any website, always look for any endpoint or subdomain from which you can login. Protection on subdomains are mostly weaker when compared to the main domain, therefore logging in from these endpoints will help you in bypassing the MFA protection.

7. Disabling the 2FA With CSRF Attack:

You can look for CSRF on any request, therefore always make sure to check whether you can disable the victim’s MFA with the help of CSRF. If the CSRF vulnerability is present on the request for disabling the MFA then you can easily bypass this protection from the victim’s account. If you are not sure about the CSRF bug that you should check it out.

8. Re-Use of Old 2FA Codes:

These types of bugs are rarely seen and they are mostly present where the the codes are usually long and are send to your email or phone number. Sometimes reusing the old codes again and again can help you bypass the 2FA protection because the back-end sometimes only check for the logic behind the code instead of the actual code.

There are many other ways to bypass the 2FA, all of which were not possible to describe in this article. Therefore always try to look for any logic flaw in the web application that you can exploit.

Simple 2-FA Bugs and Logic Flaws That You Can Look For As A Beginner was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.