MONTEARROYO SE HACE ECO DE LAS PUBLICACIONES DE LA ASOCIACIÓN DE VECINOS INDEPENDIENTE 'ALANA' Y DE SUS BOLETINES DE NOTICIAS (http://www.asociacionalana.org)
We hear about the need for better visibility in the cybersecurity space – detecting threats earlier and more accurately. We often hear about the dwell time and the time to identify and contain a data breach. Many of us are familiar with IBM's Cost of a Data Breach Report that has been tracking this statistic for years. In the 2021 report, IBM found that, on average, it takes an average of 212 days to identify a breach and then another 75 days to contain the breach, for a total of 287 days.
A new solution overview document provides insights on how XDR provider Cynet tackles the difficult problem of greatly improving threat visibility. Cynet takes a modern approach that includes a greater level of native technology integration and advanced automation purposely designed for organizations with smaller security teams than Fortune 500 organizations. A live webinar will discuss the same topic (Register here)
Cynet's Keys for Threat Visibility
Einstein said that the definition of insanity is doing the same thing over and over while expecting a different outcome. The old approach to threat visibility involving multiple protection technologies and trying to sift through a sea of alerts and information is obviously not working well. Cynet's different – and seemingly saner – approach to prevent, detect, and respond to modern-day threats involves several integrated capabilities.
According to the new Cynet solution overview, the following key technologies are used to provide extended threat visibility along with enhanced response capabilities.
Include Multiple Threat Detection Technologies
Cynet includes multiple prevention and detection technologies, all natively orchestrated in the platform:
NGAV – Fundamental endpoint protection based on known bad signatures and behaviors.
EDR – To detect and prevent more complex endpoint threats that bypass NGAV solutions.
NTA – To detect threats that have made their way into the network and so-called lateral movement.
UBA – To detect unusual activity that could signal stolen credentials, a rogue insider, or bots.
Deception – To uncover intrusions that have bypassed other detection technologies
CLM – To mine the extensive log data generated by IT systems.
SSPM – To find and correct configuration errors in SaaS applications.
Coordinate All Signals
Making sense out of multiple detection technologies by integrating, coordinating, and prioritizing information was supposed to be the realm of Security Incident and Event Management (SIEM) technologies. Unfortunately, SIEM doesn't do well with real-time data and requires significant care and feeding.
XDR solutions, like Cynet's, are purpose-built to integrate real-time signals from multiple points of telemetry on a single platform. Cynet even includes an Incident Engine that automatically investigates threats to determine the attack's full scope and root cause.
Automate All Response Actions
Quickly and accurately identifying threats is a game-changer. The ability to automatically and fully eradicate identified threats is, well, a game-changer changer. This means security teams won't have to be burdened with lengthy investigations, which many don't have the time or skills to undertake. Cynet provides an extensive set of remediation actions across files, hosts, networks and users as well as remediation playbooks that can be configured to be invoked manually or automatically.
Provide Full MDR Oversight
Beyond the technology platform, Cynet offers all clients a full, 24x7 MDR service at no additional cost. This team continuously monitors client environments to ensure nothing dangerous is overlooked or mishandled. Having an expert team watching out for issues should put smaller organizations with smaller security teams at ease, knowing an expert team of cybersecurity experts has their backs.
In With the New
With the time required to identify and contain data breaches steadily increasing, we need to rethink the traditional cybersecurity approach. It seems companies keep throwing more money, more technology, and more bodies at the problem, yet achieving the same (or worse) results. Cynet is one company that seems to be approaching the problem differently by combining multiple prevention, detection, response, and automation capabilities on a single, unified breach protection platform. Rather than buying all this stuff separately and munging it all together, the Cynet platform seems to expand and improve threat visibility out of the box.
In this post, Christian Fries shows an approach to unveil security flaws in OpenID Connect Certified implementations with well-known attack methods. One goal of the master's thesis Security Analysis of Real-Life OpenID Connect Implementations was to provide a platform for developers and security researchers to test implementations in a reproducible and maintainable OIDC lab environment.
We included six OpenID Provider (OP) and eight Relying Party (RP) services in the lab environment. For the comprehensive security analysis, we tested the implementations against eleven Relying Party attacks and seven OpenID Provider attacks in different variations with our tool PrOfESSOS. In addition, we carried out manual tests as well. We have disclosed twelve implementation flaws and reported them to the developers in a responsible disclosure process.
Two developer teams fixed (✔) the vulnerabilities before the deadline of the master's thesis. One Redirect URI Manipulation vulnerability was rejected (✖). This particular case can be permissible for only one registered URI for reasons of interoperability and fault tolerance. We informed three further development teams (✦).
Name
Vulnerability
Fixed
CVE
MITREid Connect
PKCE Downgrade Attack
✦
mod auth openidc
ID Spoofing, JWKS Spoofing
✔
node oidc-provider
Redirect URI Manipulation
✖
OidcRP
Replay Attack
✦
phpOIDC
Message Flow Confusion, ID Spoofing, Key Confusion
We explain the method of how we have archived this result in the following sections.
Introduction
The OpenID Connect protocol framework defines three basic flows, Authorization Code Flow (or just Code Flow), Implicit Flow, and Hybrid Flow. OAuth 2.0, which is the foundation of OpenID Connect, introduces several extensions. One of the latest extensions is Code Flow with PKCE (Proof Key for Code Exchange, RFC7636).
Compliance with the specification requirements is essential for application security. Settings and parameter conditions are changed. For example, in Code Flow, a nonce parameter in the Authentication Request is optional but required for the Implicit Flow. The developers have to deal with such changes. They end up implementing several code branches and various state machines. The implementation's code complexity naturally increases if it supports more features and extensions. This complexity implies that minor changes with only one specific flow in mind can introduce a security issue in another flow.
Various well-known attacks are published in different papers and several mitigations are mentioned in best practice guides. One tool, which can perform the fully automated evaluation of services with generic attack vectors, is PrOfESSOS.
PrOfESSOS
PrOfESSOS is our evaluation as a Service (EaaS) security tool. We have implemented significant improvements into it over the past few years. The latest version can simulate a malicious RP that can carry out the attacks against an OP. In addition, PrOfESSOS can simulate an honest and a malicious OP to perform Single-Phase and Cross-Phase attacks. A penetration tester can access the RESTful API directly or the Web UI to start an evaluation.
Supported attacks on Relying Parties
Single Phase
# Attack Patterns
Cross Phase
# Attack Patterns
ID Spoofing
12
Issuer Confusion
1
Replay Attack
6
IdP Confusion
1
Key Confusion
13
Malicious Endpoint Attack
1
Signature Manipulation
4
Session Overwriting
2
Cross Site Request Forgery
3
Token Recipient Confusion
3
Token Substitution
2
Supported attacks on OpenID Provider
Attack
# Attack Patterns
Authorization Code Reuse and Substitution
5
Redirect URI Manipulation
15
Open Redirector
1
Client Authentication Bypass
15
Message Flow Confusion
2
PKCE Downgrade Attack
5
Sub Claim Spoofing
5
The Lab Environment
Overview
A developer or security researcher needs a running web application to start an evaluation. One way to create an analysis is to execute the web application and evaluation tools on a local development machine. This approach might be a practical compromise for small-scale projects. For multiple instances of applications with different configurations, this approach can be cumbersome. Docker containers can help here. Various RP and OP already offer a container setup, or there are examples of creating Dockerfiles, at least. It is possible to have reproducible build results through the container concept. In addition, this approach enables us to store static configuration files and SQL dumps for a specific instance.
We introduced three networks running on a server for our lab environment setup. The ProfNET for all evaluation tools can be controlled and debugged from a remote client. Furthermore, we added a RPNet for all Relying Parties and an OPNet for all OpenID Provider. The MitMProxy connects the networks and the users' browser. It allows us to observe and manipulate every http(s) communication in front- and back-channel.
Setup
Server Side
It is only required to checkout the oidc-docker-libs. The docker-compose setup can be built and run with:
git clone https://github.com/RUB-NDS/oidc-docker-libs docker-compose build docker-compose up -d
The following ports are used by the lab: 8787, 9990, 8888, 8042, 8080, 8081. You should ensure that you don't have service running on those ports.
The docker-compose provides the possibility to run only a small subset, for example:
docker-compose up -d professos mitmproxy mitreid-server
Docker Structure
The basic idea of our docker containers is to build from sources in a more or less generic way. We intended that each application runs as a completely independent unit. The application configuration can be performed with build arguments, environment variables, or complete SQL dumps.
You can see that we structured a Dockerfile in four blocks:
FROM ubuntu:18.04 ARG BRANCH=v3 ARG FLOW=implicit ARG CONTROLLER_URL ARG SERVER_HOST # Setup the application ENV APPDIR /opt/app WORKDIR ${APPDIR} RUN git clone --depth=1 --branch=$BRANCH https://github.com/YOU/YOUR_APP RUN cd YOUR_APP \ && echo config=$FLOW >> configuration_file \ && ./build # deploy automatically created certs ARG CA_DIR="/certs" ARG CA_CERT="oidc-ca.crt" VOLUME ["$CA_DIR"] # Configure apache or nginx COPY config/apache-ssl.conf /etc/apache2/sites-available/ssl.conf RUN sed -i "s#SERVER_HOST#$SERVER_HOST#g" /etc/apache2/sites-available/ssl.conf RUN a2enmod headers ssl proxy proxy_http rewrite && a2ensite ssl RUN echo"https://$CONTROLLER_URL" > /var/www/html/.professos # Start the application and apache/nginx server COPY docker-entrypoint.sh ${SUBDIR}/ WORKDIR ${SUBDIR} ENTRYPOINT ["./docker-entrypoint.sh"]
From this point, it is possible to add two or more configured instances to the docker-compose.yml file. Every instance can be tested independently and without influencing each other. This independence enables us to test various switches, e.g., different flows or authentication methods in different combinations.
The user solely has to establish a proxy connection to SERVERIP:8080. For example, in Firefox, the addon FoxyProxy can switch easily between different proxy settings.
It is advisable to install the generated Root-CA (oidc-ca.crt) in the browsers' certification store. Otherwise, self-signed certification warnings will be displayed. After the web browser is connected to the proxy, it should be possible to reach the landing page https://lab.
Automatic Tests with PrOfESSOS
We have two options for automatic tests with PrOfESSOS. We can either use the Web UI at https://professos, or call the RESTful API methods directly. Both options require a configuration file with target information. PrOfESSOS requires this information to find all needed URLs and parameter fields to login with selenium scripts.
You can use the following JSON file for the MITREid Connect Client:
Only the CHANGE_ME parameter must be replaced manually with the displayed Test ID, as you can see in the following screenshot. The Test ID represents a unique OP address. This allows parallel testing as long as the implementation supports Dynamic Registration.
After clicking the "Learn" button, PrOfESSOS tries to log in with the honest and evil OP. Note that it takes a while until the process is finished.
If everything has worked as expected, PrOfESSOS displays a green checkmark. Otherwise, the UI provides minor logs and a few screenshots until the error has occurred. The MitMProxy Web UI can be a helpful additional tool to debug such issues.
On success, explicit tests or all tests can be executed. Each test step provides a small description and a test execution log.
The other option to start these tests is to use the RESTful API. Therefore, we provide a python cli tool in the oidc-docker-libs/oidc-lab-scripts folder. For all currently implemented RP and OP solutions, we have stored the json configurations. After starting the cli tool you solely need to select a target and run a complete test. An HTML report is also created which can be shared with collaborators.
#> ./cli.py [*] Professos CLI started Starting Control Center for Professos! cli> load rp mitreid-client Start session default cli>> rp> mitreid-client> full_test Create new test plan: TestId = 6RZmcJHNd6o Learn: { "HonestWebfingerResourceId": "https://honest-idp.professos/6RZmcJHNd6o", "EvilWebfingerResourceId": "https://attack-idp.professos/6RZmcJHNd6o", "UrlClientTarget": "https://mitreid-client/simple-web-app/login", "InputFieldName": null, "SeleniumScript": "", "FinalValidUrl": "https://mitreid-client/simple-web-app", "HonestUserNeedle": "{sub=honest-op-test-subject, iss=https://honest-idp.professos/6RZmcJHNd6o}", "EvilUserNeedle": "{sub=evil-op-test-subject, iss=https://attack-idp.professos/6RZmcJHNd6o}", "ProfileUrl": "https://mitreid-client/simple-web-app/user", "Type": "de.rub.nds.oidc.test_model.TestRPConfigType" } ================================================================================ Run Test Step [0]: ID Spoofing 1 - ID Token (sub) - PASS ================================================================================ Run Test Step [1]: ID Spoofing 2 - ID Token (sub+iss) - PASS ================================================================================
Semi-Automated and Manual Tests
The MitMProxy can intercept and manipulate front and backend communication for minor manual tests. For example, the MITREid Connect client can perform user authentication with Keycloak as the OpenID provider. To simulate a redirect URI attack, you can intercept the Authentication Request or Token Request and manipulate the values.
Another reproducible way is to combine a specific PrOfESSOS attack, and a prepared script that is uploaded to the MitM scripting interface. Therefore, we added a server application to the MitM scripting interface, which can be controlled with the lab script cli tool.
We used such a workflow to check if a special redirect URI is vulnerable to an XSS attack. You can try it on your own. The command to prepare this attack is:
./cli.py [*] Professos CLI started Starting Control Center for Professos! cli> load op mitreid-server Start session default cli>> op> mitreid-server> create Create new test plan: TestId = vWmdL4XHe2w cli>> op> mitreid-server> learn Learn: { "HonestRpResourceId": "https://rp.professos/vWmdL4XHe2w", "EvilRpResourceId": "https://evilrp.professos/vWmdL4XHe2w", "UrlOPTarget": "https://mitreid-server/oidc-server", "OPMetadata": "", "AccessToken1": "", "AccessToken2": "", "User1Name": "user1", "User2Name": "user2", "User1Pass": "user1pass", "User2Pass": "user2pass", "LoginScript": "", "ConsentScript": "", "Client1Config": "", "Client2Config": "", "Type": "de.rub.nds.oidc.test_model.TestOPConfigType" } cli>> op> mitreid-server> run_pyscript pentest/mitreid-server-redirect.py Received: OK Received: OK cli>> op> mitreid-server> run 48 ================================================================================ Run Test Step [48]: Custom 1 - Redirect URI - PASS cli>> op> mitreid-server> export cli>> op> mitreid-server> report
As a result, in the screenshot you can see that our javascript was escaped correctly.
Another new feature for RP tests is to expose a specific attack pattern with PrOfESSOS and go through the login process manually with a browser. This is archived with the cli and the expose command. If you want to test, execute these commands:
./cli.py [*] Professos CLI started Starting Control Center for Professos! cli> load rp mitreid-client Start session default cli>> rp> mitreid-client> create Create new test plan: TestId = hDOAisJy9OE cli>> rp> mitreid-client> learn Learn: { "HonestWebfingerResourceId": "https://honest-idp.professos/hDOAisJy9OE", "EvilWebfingerResourceId": "https://attack-idp.professos/hDOAisJy9OE", "UrlClientTarget": "https://mitreid-client/simple-web-app/login", "InputFieldName": null, "SeleniumScript": "", "FinalValidUrl": "https://mitreid-client/simple-web-app", "HonestUserNeedle": "{sub=honest-op-test-subject, iss=https://honest-idp.professos/hDOAisJy9OE}", "EvilUserNeedle": "{sub=evil-op-test-subject, iss=https://attack-idp.professos/hDOAisJy9OE}", "ProfileUrl": "https://mitreid-client/simple-web-app/user", "Type": "de.rub.nds.oidc.test_model.TestRPConfigType" } cli>> rp> mitreid-client> expose --test 3
Start login at https://mitreid-client/simple-web-app/login
For the OpenID Provider use the exposed attacker OP address https://attack-idp.professos/CHANGE_ME which can be copied from the learn step.
The browser should display a simple message: Authentication Failed: Id Token Issuer is null -> Our attack was unsuccessful
The honest OP address can be used to compare the result with a successful login attempt.
Integer overflow and underflows often occur when user supplied data controls the value of an unsigned integer. The user supplied data either adds to or subtracts beyond the limits the variable type can hold. If you remember back to your computer science class, each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers. The types of numbers they are allowed to hold is based on their "signedness." An unsigned integer can only hold positive numbers while a signed integer can hold positive and negative numbers. We will get to the significance of that in a short bit.
If you violate the value constraints of the variable type you are using, the application may act in unintended ways. For example, the overflow may result in an error condition for accessing out of bounds items or perhaps cutting the number off at the maximum or minimum value. This usually depends on the language in use, the context in which the value is used or the decisions taken by the programmer when flagging error conditions. If un-handled, the error from an attacker's perspective is usually an opportunity for exploitation.
For example, if you were calculating a number for an authorization check within an application and the calculation contains an unchecked value with user-controlled data. Then an attacker may be able to bypass authorization restrictions with that user-controlled data and gain additional access to unintended services. For example, overflowing a larger unsigned value to a more advantageous value, such as zero or one, these lower values could bypass security checks. The first ("1") value in a dataset is often indicative of an administrator who set up the application and may create a situation to persist actions with administrative context.
In the Solidity language for Ethereum, when we overflow a uint value using a value larger than our uint can hold, the value wraps back around to a number it understands. The lowest or highest possible value the uint can hold. For example, if we have a variable that can only hold a 2-digit number when the number 99 is reached and then incremented one more time, we will end up with 00. Inversely if we had 00 and we decremented 1 we would end up with 99.
Normally in your math class the following would be true:
99 + 1 = 100
00 - 1 = -1
In solidity with unsigned numbers the following is true:
99 + 1 = 00
00 - 1 = 99
So, the issue lies with the assumption that a number will provide a correct value in mathematical calculations when indeed it does not. Comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that overflows a value, but that does not check that the value is accurate in the context of the mathematical operation.
In an overflow conditions the comparison with a require statement may very well be comparing the output of an over/under flowed value and be completely meaningless. The "Require" statement may return true, but not based on the actual intended mathematical value.
This in turn will lead to an action performed which is beneficial to the attacker, for example, checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Let's go through a few examples.
Simple Underflow Example:
Let's say we have the following Require check as an example:
1.require (balance - withdraw_amount > 0);
Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously, they don't have the money for this transaction correct?
This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above and our variable can hold 2 digits with an unsigned integer?
Let's do some math.
5 - 6 = 99
Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.
The below example snippet of code illustrates a withdraw function with an underflow vulnerability:
1.function withdraw(uint _amount){
2.require(balances[msg.sender] - _amount > 0);
3. msg.sender.transfer(_amount);
4. balances[msg.sender] -= _amount;
5. }
In this example, the require on line 2 checks that the balance is greater than 0 after subtracting the _amount. However, if the _amount is greater than the balance, it will underflow resulting in a large value greater than 0. So even though the require check should fail the check will return a true value.
After the check is under flowed, it will send the value of the original _amount on line 3 to the recipient without any further checks resulting in sending more funds then the user has.
To make matters worse, on line 4 another underflow exists, which increases the value of the senders account due to a similar underflow condition, even though the balance should have been reduced based on application logic.
Depending on how the "require" check and transfer functions are coded, the attacker may not lose any funds at all, while still transferring large sums of Ether to other accounts under the attacker's control. The attacker would achieve this by simply under flowing the require statements which checks the account balance before transferring funds each time.
Overflow conditions often happen in situations where you are sending a batched amount of values to multiple recipients. If you are performing an airdrop, sending tokens to 200 users, each receiving a large sum of tokens, checking the total sum of all users' tokens against the total funds may trigger an overflow. The logic when overflowed would compare a smaller value of overflowed tokens to the total tokens and seem like you have enough to cover the transaction.
For example, if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?
You have 10,000 tokens in your account
You are sending 200 users 499 tokens each
Your total sent is 200*499 or 99,800
The above scenario should fail, and it does, since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Let's do some more math and see how that changes the outcome.
You have 10,000 tokens in your account
You are sending 200 users 500 tokens each
Your total sent is 200*500 or 100,000
New total is actually 0
This new scenario produces a total that is 0 even though each users amount is only 500 tokens. This may cause issues if a require statement is not handled with safe math functions to sanitize the mathematical output.
Let's take our new numbers and plug them into the below code and see what happens:
1: The total variable equals 100,000 which becomes 0 due to the 5-digit limit. When a 6th digit is hit at 99,999 + 1 the total now becomes 0.
2: This line checks if the users balance is higher than the total value to be sent. Which in this case is 0 so 10,000 is more than enough and this check passes due to the overflow.
3: This line deducts the total from the sender's balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.
4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 and this individual action does not trigger an overflow condition. Thus, sending out 100,000 tokens without reducing the sender's balance or triggering an error due to lack of funds. This is essentially creating tokens out of thin air.
In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.
Now that we understand what overflows and underflows are, we are going to take a closer look at a real-life hyperinflation attack from 2018. When a bunch of erc20 tokens incorrectly checked the results of mathematical calculations. This lack of safe checks led to exchanges freezing all erc20 token transfers. We will first exploit this code from the original attack. We will then re-code the smart contract to protect against this attack.
The effected tokens in this attack used an insecure batch send function that was not protected from integer overflows. This is similar to our batch send example above. This vulnerability was copy pasted into many different tokens and when exploited it forced exchanges to suspend all erc20 token transfers until the issue was resolved.
üLet's first pull down the code and take a look at the vulnerable function. üThen we will take a look at the actual payload on etherscan from the real attack to decipher
how it happened. üThen we will exploit it ourselves. üThen we will fix the issue and test our fix.
Action Steps:
üReview the following lines of code and see if you can spot the vulnerability
üFollow the attack on EtherScan and understand how the attack works
üThen watch the video walk and talk to solidify the process
Below is the function from the ERC20 contract which had the initial vulnerability. Also, a link to view the code for yourself on etherscan. Just do ctrl+f search for the batch transfer function on the contract page.
The issue with this function is it's performing a balance check against the amount on line 5 but that amount value comes from a mathematical operation on line 3 which has an overflow vulnerability.
You will see that the amount results from multiplying the length of the array times the value being sent. Since there are no checks that this mathematical operation does not overflow to a value lower than our balance, we can easily set the amount to 0 using a very large number as our _value.
When the actual balances are updated on line 10, we are not using the amount of 0, but instead we are using the initial large _value sent to the function, but this time there is no multiplication, so it does not cause an overflow, it only updates the value to a very large number.
Now let's take a look at an actual transaction that caused this overflow attack.
Below is the transaction from the overflow attack. Also, a link to view the transaction for yourself on etherscan. Just click the "click to see more" button and check out the "input data" section.
If you reviewed the transaction on chain you would see the above transaction data.
Let's go into a little detail as to what the transaction values are and how they were derived. This will help in understanding what is going on with this attack.
The data in the transaction can be broken down as the following
üA 4byte MethodID
üFive 32-byte values
The 4-byte MethodID which precedes the function parameters is the first 4 bytes of a sha3 hash of the batchTransfer method declaration minus the variable names and spaces. We can derive this sha3 value from the transaction by using the web3 utility functions and a substring of the sha3 output.
You can try this out with the following node commands.
The 5 parameters following the MethodID are defined as follows:
[0] Offset to the _recievers Array, length value: 40Hex or 64 bytes (2x32 = 64bytes to the Array length held at [2])
[1] This is the actual _value which is being sent that when multiplied causes an overflow. (A very large number)
[2] This is the size of the _recievers array sent to batch transfer in this case 2 addresses
[3] This is the first address from the _recievers array used in the batch transfer.
[4] This is the second address from the _recievers array used in the batch transfer.
Reviewing a Live On-Chain Attack Transaction:
So, what this attack did was take a very large value from [2] and multiplied it times the length of the array which is the value 2. This creates an overflow condition that results in the value of 0. Don't believe me, let's do it for ourselves with a simple function that calculates the value sent times two.
1.pragma solidity ^0.6.6;
2.
3.contract noAuth {
4.function amount(uint256 myAmount) public returns(uint){
5.return myAmount * 2;
6. }
7.}
Action Steps:
üDeploy the contract from above.
üFirst put in a low number like 5 and review the output window, what do you get?
üNow put in the attack value in hex for aka 0xnumber 0x8000000000000000000000000000000000000000000000000000000000000000
üWhat happened?
As you will see an amount of 0 results which will pass the checks allowing an attack to work. Resulting in a very large value sent as the _value variable to the user. Causing hyperinflation of the token.
This is pretty cool, but let's actually exploit this attack ourselves. I have taken the liberty of updating the function from Beauty Chain to meet the current compiler standards with a few small tweaks and some functions so you can check your balance during the stages of the attack. Deploy this contract and try to exploit it before reading the walkthrough!!
For this one you can type it out for practice or grab it from the github folder since this is a case study and not the normal learning material per say. I will allow laziness this one time.
I slightly modified the vulnerable function from beautychain to work with the newer versions of solidity by adding in a few keywords and new syntax but this is basically the same code. Solidity requirements have changed a lot since version 4 when this was originally deployed. So I updated it to make it so you could actually deploy it without any issues in a newer version and learn the differences between versions.
Action steps:
üUsing account 1 deploy the BEC_Vuln Contract and deposit some wei, maybe 2000.
üCheck the value of account 1, account 2 and account 3.
üSend the attack from account 1 and perform a batch transfer by sending in an array of 2 addresses followed by the attack value in hex. See the below example for reference.
üNow check the values of the 3 accounts, what are they? What happened?
Now let's take a quick look at fixing issues related to integer overflows and underflows. As always in application security, we should not try to roll our own security libraries. We should instead use opensource well vetted security libraries for coding projects. Ethereum is no exception to this rule and has its own opensource libraries from OpenZeppelin which handle anything from safe mathematical calculations to role based authentication. Below is a direct link to the safe math library you will now import into your BEC_Vuln.sol file and then fix the current overflow issues.
We will do this by using the following line under ae pragma solidity definition
pragma solidity 0.6.6;
import"PASTE OPENZEPPELIN LINK HERE";
With this import statement we will now have access to the math functions within safe math for example:
üAdd
üSubtract
üMultiply
üDivide
These functions can be accessed with dot notation. For example in the following:
SafeMath.mul(value1, value2)
Action Step
üLocate all of the mathematical functions in the example
üRe-code all of them to match the above format
üTry your attack again, results?
üHow many did you find and update?
üWhat happened when you ran the attack again?
Safe Math Walk Through
We need to update all of the mathematical functions within our contract and then try our attack again. First try to locate all of these and update them according to the type of mathematical calculation.
You should have found 3 locations which need updating to comply with safe math standards These are shown below with the correct syntax needed to fix them with OpenZeppelin. Apply these changes to your code if you have not already.
If you apply the above fixes within your code then the returned values of the mathematical operations are double checked to make sure they make sense. For example, check out the OpenZeppelin code for multiplication:
1.function mul(uint256 a, uint256 b) internal pure returns (uint256) {
2.if (a == 0) {return0;}
3.
4. uint256 c = a * b;
5.require(c / a == b, "SafeMath: multiplication overflow");
6.return c;
7. }
Note that 2 parameters are taken into the function on line 1 which are our two values we are multiplying together. In our case our number of addresses in the array and the _value to send. These values are multiplied on line 4 and stored in the value c.
Then on line 5 the reverse operation Is performed on the result, dividing the returned value c by a and requiring that it is equal to the value of b. If this was an overflowed and wrapped around back to 0 then this check would obviously fail as the number would be incorrect.
If this check fails an error condition is shown like the following:
If this check passes then the transaction finishes as normal and the transaction completes as intended. Make sure that you re-code this and then run the attack again yourself. Review the output from the transactions for both. Also review the Add and the Subtract functions, which you also re-coded and make sure you understand how they are working as well.
You can find the open zeppelin code at the link where you imported if from, or within remix where it was imported to a github folder path. Review the code and use the functions in your applications to protect against math issues. If you are a penetration tester make sure that the contracts you are reviewing are using safe math functions whenever math is used.
Using OpenZeppelin Safe Math Libraries To Prevent Integer Attacks:
We went through what might have been an overwhelming number of concepts in this chapter regarding over/underflow scenarios. Make sure that you type out each of the examples and execute the code to understand what the issue is and how to spot it. Then re-code the examples to fix the issues.
