 publishes articles on exploitation techniques, tools and tips to help hunters find vulnerabilities in their reconnaissance process and hunting routine. The goal is to provide ideas and keys to attack and understand the various web technologies hunters may face on their private programs.

The world’s biggest rainforest is what we referred to when we heard the word Amazon. But since 1994 this reference started to change when Amazon as an e-commerce company was launched and took pace in 2006 when AWS (Amazon web services) as a cloud service company was started. With the increasing greed for space and authority, humans started exploiting thick covers of Amazon rain forests and on the other hand, hackers started abusing AWS S3 bucket permissions. Since we are dealing with the technological part here, let’s wear our black hats and take a deep dive into how attackers abuse S3 bucket permissions.

According to Amazon, S3 buckets are containers for objects stored in Amazon S3. You can store any number of objects in a bucket and can have up to 100 buckets in your account. To simplify it a bit, it is a pubic cloud storage resource which is similar to file folders that store objects containing data and its respective metadata. Amazon provides several features with S3 buckets few of which are versioning, Access logging, Object-level API logging, tags and encryption.

The use case for S3 can be a situation where a web application wants to share certain files and has some image dependencies. S3 can come to the rescue where it can hold all such data and provide it to users as requested and required. Also, it can be used to store data/images/profile photos of users and also other dependencies of web applications like JavaScript and CSS.

AWS S3 comes equipped with a range of permissions and access control mechanisms which if in the case overlooked by administrators and improperly implemented can act as a treasure of data for malicious hackers and bounty source for 

Misconfigured AWS S3 buckets that leave unauthorized access are thus abused by attackers to compromise the privacy of the data stored in those buckets breaching the privacy of millions of users around the world. If the case misconfigured S3 Bucket contains EC2 snapshot instances, then attackers might be able to retrieve the snapshot instance and then get security keys for the EC2 instance itself.

There Are various ways to identify S3 buckets few of which are

HTML inspection (S3 Bucket URL hardcoded in HTML of webpage)

Testing and Abusing S3 Bucket permissions

Once you have identified S3 buckets, it is time to test out permission they have and once they are identified, we can start abusing them. But what are the permissions in particular assigned to S3 buckets? Let us have a brief look at them

This permission allows reading the contents/objects of the bucket. At the object level, it allows reading the contents as well as metadata of the object. Testing this permission is really simple. The first way is to try and access it via URL. Use this as a skeleton and modify as according to your needs

This same thing can be done by using the AWS command line as well. Following is the command that can be used to list the contents

No sign request switch that we used in the above command is used to specify not to use any credential to sign the request. A bucket that allows reading its contents will spit out all the contents once requested by any of the above methods. HTML request will show output on the XML page and the command line will give a list of files.

This permission allows to create, overwrite and delete objects in a bucket. Speaking of object-level access, it allows editing of the object itself. As far as testing goes, this permission can only be tested by the AWS command-line interface, unlike reading permission where you had a chance to test it through a web browser. Following is the command that you can use and modify according to your needs

A bucket that allows unrestricted file upload will show a message that the file has been uploaded.

At bucket, level allows to read the bucket’s Access Control List and at the object level allows to read the object’s Access Control List. Read ACL can be tested with the AWS command line using the following command

Once we execute both these commands, they will output a JSON describing the ACL policies for the resource being specified.

This policy at the bucket level allows setting access control list for the bucket. At the object level, allows setting access control list for the objects. To test this, all you need to do is run the following g command :

To test for a single object, following command can be used

For this though, there is no output shown in the form of a message

This term is self explanatory which means it grants full control (

). The same goes for object-level access as well.

Finally is the most destructive one which is any authenticated AWS CLIENT. This permission allows any authenticated AWS client to access the account regardless of what type of account they are using. To test this, simply take any command from above and replace –no-sign-request with –profile [your_profile_name].

Following is an excellent open-source resource where you can test out all the permissions. Assuming that ACL and proper policies are in place, only one or few commands might show successful output. You can always set up your own S3 bucket and test out these commands as an unauthenticated user on your bucket. You can then see the output. Later you can add on policies and Access control measures on your bucket and test again with these commands.

 gives CTF like challenges where the content of each flag is entry to the next challenge so you can test out your skills in securing the cloud with these challenges.

To demonstrate the above commands, we have created an AWS bucket and configured it in a vulnerable fashion. Let us look at the above commands one by one. First, we will show you what the output will look like once we run the above commands and later, we are going to look at the vulnerable policy that we have set on our bucket and also other misconfigured buckets that might have on open public internet.

In this, when we ran command for first time, it showed error because s3 bucket blocked file uploads. Later on, we modified permission hence it allowed file uploads.

You can test out write ACP by creating your own custom Access control Policy and uploading it by running command mentioned previously.

Let us have a look at vulnerable policy we set on our bucket.

The main problem here is with the Action tag which is set to *. It means that to allow all the actions including reading write upload delete etc. This is a quick and convenient way for administrators to assign access control to the bucket but at the cost of convenience comes the security which leaves the bucket vulnerable. To mitigate this, administrators should set each and every permission/Action manually as per requirement and configure the bucket properly such that public access is blocked.

Here are summed up steps you can take to secure an s3 bucket or recommendations you can give after you have found the s3 bucket.

Making Bucket private / Disallow public access

Using assumed IAM roles which has access to the bucket for read/write

Enabling CloudTrail and Server access logging for your bucket.

Abusing S3 Bucket Permissions

Web applications & APIs are often the highly exposed asset of any organization. With the use of modern frameworks, the development process becomes handy and faster. However, often the developers leave some 

unlinked, unreferenced or unintentionally/accidentally open for use. Often, attackers may utilize these to perform attacks such as Cross-Site Scripting (XSS), Open Redirection, Server-Side Request Forgery (SSRF), SQL Injection and others.

In this article, we will be discussing identifying the hidden attack surface by identifying the hidden parameters.

The process of identifying unlinked, unreferenced or simply hidden parameters that are accepted by the application and could allow a user to control the behaviour of the application using these hidden parameters is often known as 

As mentioned, the hidden parameters may allow an attacker to control the behaviour of the application and may result in the execution of successful attack scenarios such as Cross-Site Scripting, Open Redirection, SQL Injection, Local File Inclusion, Command Injection, Server-Side Request Forgery, Server-Side Template Injection and other security vulnerabilities such as an IDOR.

Hence, it is an essential step to perform 

as part of your Recon process for building an attack surface that is inclusive of the Hidden Attack Surface through these parameters. This often helps bug bounty hunters and security professionals to find unconventional and high reward paying bugs.

Since the purpose and motivation behind identifying the 

is now clear, let’s look for different tools & methodology to perform parameter discovery.

Tools for performing Parameter Discovery:

Arjun is a python based command-line tool that helps in the detection of the parameters present in the application. By default, the tool utilizes a custom wordlist to check for the parameters but this can be modified by the user to set their own parameters.

Detailed information and installation instructions can be found on the official repository of the Arjun tool:

Run the following command: arjun -u https://demo.testfire.net

Observe the parameters returned by the tool.

Note: By default, the tool uses GET request method but you can define other methods such as POST by using -m flag. Ex: python3 arjun.py -u https://target.com/test -m POST

ParamSpider is a python based command-line tool that helps in the identification of the parameters. It has the ability to find parameters from web archives, subdomains and other sources as well. This is one of the most effective tools to identify the parameters.

Detailed information and installation instructions can be found on the official repository of the ParamSpider tool:

 https://github.com/devanshbatham/ParamSpider

Finding Hidden Parameters with ParamSpider

Run the following command: python3 paramspider.py -d <target_domain> –level high

Param-Miner is a Burp Suite Extension that is handy and useful to find hidden and unlinked parameters that are specifically useful while looking for the Web Cache Poisoning related vulnerabilities.

Detailed information about the extension can be found here:

 https://github.com/PortSwigger/param-miner

As per the official GitHub Repository, the tool combines advanced diffing logic from Backslash Powered Scanner with a binary search technique to guess up to 65,000 parameters names per request. Param names come from a carefully curated built-in wordlist, and it also harvests additional words from all in-scope traffic.

To use it, right-click on a request in Burp and click “

”. If you’re using Burp Suite Pro, identified parameters will be reported as scanner issues. If not, you can find them listed under Extender -> Extensions -> Param Miner -> Output

In this section, we will look at a simple example of chaining multiple tools to perform parameter discovery and further utilize the identified parameters to check against cross-site scripting using tools such as KXSS.

First, let’s perform parameter discovery using ParamSpider:

Now, We have all the parameters identified, let’s run XSS GF patterns to extract the parameters that could be vulnerable to XSS:

on the URLs that are potentially vulnerable to XSS:

Observe that we have found some valid Cross-Site Scripting Issues

As we were able to find valid cross-site scripting issues, you can also attempt to write your own one-liners or small scripts to automate other security vulnerabilities as well.

Thank you for reading the article till the end and we hope you have learned something new. Make sure to check out the programs on the 

 platform and apply your newly learned skills to find some interesting security vulnerabilities. We will be back with some other interesting articles soon.

Parameter Discovery: A quick guide to start

, is launching the first live Bug Bounty event dedicated to European scale-ups and unicorns!

The idea was born in September 2021, during the 

Why not organise an event that would encourage all French scale-ups and unicorns to collaborate with ethical hackers, all in a fun and friendly atmosphere?

After some discussions with the unicorn Blablacar, already familiar with Bug Bounty with its 

 on the YesWeHack platform, then with Malt, the idea became a reality! The first edition of Hack Me I’m Famous will happen on 13 & 14 April 2022 at the 

13 & 14 April 2022 – A Promising First Edition

For this first edition, YesWeHack called on around fifty of the best European hackers to come and challenge the information systems of Doctolib, Blablacar and Malt. For more than 30 hours, day and night, the hunters will try to find vulnerabilities in the partners’ information systems. If they succeed, they will receive rewards based on the reward grids as well as unique goodies and special prizes!

For corporate security teams, it’s a unique and invaluable opportunity to discuss their findings with researchers, and better understand security bugs. For hackers, it’s an easy way to ask live questions to program managers and YesWeHack’s teams to get more information about the programs and thus go even further in their research. Furthermore, researchers may collaborate with each other to pool their skills and expertise and thus go further in the hunt for new vulnerabilities and exploitation. 

In a nutshell, a live Bug Bounty is an amazing experience for everyone to get to the top!

Alongside the live Bug Bounty, a workshop of the 

, of which YesWeHack is a member, will take place on the first day of the event. The SPARTA project is a novel Cybersecurity Competence Network supported by Horizon 2020, aiming to develop and implement excellent R&I actions and to ensure digital security and strategic autonomy of the EU. Strongly guided by concrete challenges, this workshop aims to gather the European ethical community to discuss their contribution to the European cybersecurity. 

You can download the SPARTA workshop programme here

This event aims to be replicated every year, with new scale-ups and unicorns joining every year. If you are interested in the initiative and would like to discuss with our teams, we invite you to contact us.

This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 830892.

Founded in 2015, YesWeHack is the #1 European Bug Bounty & VDP Platform. YesWeHack offers companies an innovative approach to cybersecurity with bug bounty (pay-per-vulnerability discovered), connecting tens of thousands cybersecurity experts (ethical hackers) across 170 countries with organizations to secure their exposed scopes and reporting vulnerabilities in their websites, mobile apps, infrastructure and connected devices. YesWeHack runs private and public programs for hundreds of organizations worldwide in compliance with the strictest European regulations.

In addition to the Bug Bounty platform, YesWeHack also offers support in creating a Vulnerability Disclosure Policy (VDP), a learning platform for ethical hackers called Dojo and a training platform for educational institutions, YesWeHackEDU. For more information: 

The first live Bug Bounty for European scale-ups and unicorns

Smart contracts security has had an increasingly bad reputation over the last few years, with over 

 worth of cryptoassets stolen in this first quarter of this year alone. The need for whitehat hackers to help protect smart contracts has never been higher.

This article is a guest blog post written by 

Smart contracts are blockchain computer programs that execute when established conditions are met by some counterpart. The typical real-world analogy for smart contracts are 

. When a customer sends money to the vending machine, and some indication of which snack to dispense, the machine validates that certain pre-established conditions are met before dispensing the snack. In this case, the machine validates that the money received for the selected snack was enough, and that there is sufficient stock of the selected snack. The vending machine’s internal validation and processing removes the need for a shopkeeper to perform the same actions, and this idea is generalised to smart contracts to execute arbitrary actions such as exchanging and transferring assets, taking out a loan and more, each action with their own set of pre-determined conditions.

For this post, I’m going to be talking about smart contracts in general, but I’m referring to contracts that run on the EVM, the Ethereum Virtual Machine. The EVM is a virtual machine that enables the execution of smart contracts and is what updates the state of smart contracts as transactions are processed. There are several EVM-based blockchains, and the information in this blog can be used interchangeably.

Why are smart contracts good targets to hack?

Compared to Web3 vulnerabilities, a blackhat will generally need to make an extensive effort to find a way to monetize their Web2 vulnerabilities, such as setting up a spear-phishing campaign in hopes to trick victims into sending them money. In the case of smart contracts, a single mistake in a smart contract could lead to irreversible theft of millions of dollars, which has already happened 

. Smart contracts are excellent targets for hackers due to it’s ability to 

, and with the complex smart contract code 

 being immutable, it may take just one error to compromise the entire protocol. To reflect the growing need for whitehat hackers, project teams have stepped up and have started to offer larger and larger bounties, with bounties 

up to $10m offered for critical vulnerabilities

The most popular smart contract language for smart contracts is 

. Since most protocols open-source their smart contract code, there is less need to rely on intermediary steps like reconnaissance, compared to traditional web bug hunting. This means that being able to read and understand the code will be your most powerful tool to find bugs, more so than any kind of automated tooling. To this end, you should spend plenty of time with smart contract development. This means following beginner syntax tutorials like 

. Understanding the basics such as the importance of correct function visibility, or why private state variables can still be freely read beyond the smart contract level, are vital to building a solid foundation.

As you start reviewing code for bugs, you’ll want to test out any leads you may have. However, since smart contracts live on blockchains, it’s very important to not test out any potential exploits on mainnet or testnets. That’s because blockchains are very transparent, in the sense that anyone can read exactly what you’re trying to do when interacting with a smart contract. A bad actor may notice what you’re attempting to do and front running to exploit the issue you’ve picked up. To get around this, most researchers make use of mainnet forks: a simulated environment that replicates blockchain state up until some block height. This allows anyone to test their exploits with existing contracts in their current state, without broadcasting what they’re doing to the actual blockchain. I’ve already written a separate blog post on how to do this, which can be found 

Once you have the basics down, the next step should be upskilling yourself to learn about the different security practices and common vulnerabilities related to smart contracts. The best way to do this would be to play CTFs (

) and wargames to learn how to exploit intentionally vulnerable smart contracts. There 

, with one of the most popular materials being 

 due to its easy setup and progressive difficulty. Other popular training materials are 

Beyond training, there are some other general tips to stay up to date with the smart contract security scene. Since the space is incredibly fast-paced, it’s helpful to always get updates in real time from projects. This means following prominent personalities on Twitter (I’ve found Twitter to be the most up-to-date and reliable source of news), as well as joining the local hacker communities on Telegram, Discord etc. Beyond community, it’s important to take initiative wherever possible. Learning about how the latest exploits work under-the-hood will give you a notch above hunters who aren’t familiar with the new pattern. For example, trying to replicate exploits detailed on 

 is an excellent way to keep your skills sharp.

Lastly, once you have the basics and some training under your belt, I’d recommend just diving into some targets from a smart contract 

. This where you’ll gain the most experience compared to any of the above tips, since you’d be reviewing production code (or staging code, occasionally) and you’ll hopefully be stumbling on some bug leads that you’d want to test on your local fork. Many of your bug leads may lead to dead ends, but each dead end should come with a valuable lesson that you can take with to your next hunting session. For example, you may think you’ve found a way to drain assets from a Uniswap V2 pool, only to realize how the constant product formula was enforced in the code. Each failure should teach you something, even if it’s not obvious at the time.

I thought it would be interesting to detail what a bug hunting session might look like, so I’ll demo a walk through of a simple (but critical) vulnerability I 

. To find interesting targets, I’m usually looking through 

, but I also enjoy keeping an eye out on Twitter for interesting opportunities. I stumbled on this 

 and got the 3 relevant contract addresses after DM’ing abwagmi. The 3 contracts are AxonsToken, AxonsAuctionHouse and AxonsVoting. Immediately, we can see what the contracts inherit and we can start asking the following questions:

Are the parent contracts (ERC20, Ownable) standard contracts (e.g. written by OpenZeppelin), or are they custom written contract by the dev?

Are any of the ERC20 functions overridden?

Where is the owner role used? Are there any functions that should have made use of the owner role, when it didn’t?

Are the parent contracts standard contracts or are they custom written contract by the dev? (This question should be asked for pretty much all contracts)

Which functions does the important pause function affect? Is there relevant access control to prevent attackers from pausing the contract?

Where is the reentrancy guard used? Why is it necessary? Was it implemented correctly, and does it handle reentrant tokens?

Where is the owner role used? Are there any functions that should have made use of the owner role, when it didn’t? (Again, any time access control roles are imported they should be inspected closely for their intended use compared to what was actually implemented)

Are the parent contracts standard contracts or are they custom written contract by the dev?

You should notice that even by inspecting just a few contracts we already have some overlap in things to check with regards to access control, reentrancy and custom imported contracts.

After starting to answer the above questions, you’ll notice that our second question for AxonsToken has an interesting answer: The transferFrom function is overridden. Immediately, an overridden function that handles token transfer should be inspected closely. To understand any issues relating to the transferFrom function, you’ll need to understand how transferFrom works in 

The transferFrom function is used to transfer tokens on behalf of another user, provided they set some prior allowance on the number of tokens to transfer. In the case of the AxonsToken transferFrom function, the dev was hoping to circumvent the need to approve the auctionHouse contract to save on gas costs and immediately proceed with a transfer if the sender or recipient was the auctionHouse contract:

While the function is ‘functional’ in the sense that it does circumvent the need to approve the auction house, there is a flaw in the way we validate that the sender is who they say they are. Right now, there is no check that the person performing the transfer is the sender or the auctionHouse. This means we should be able to do 2 things:

We can move tokens from any user to the auctionHouse contract: transferFrom(victim, auctionHouse, balance).

We can move tokens from the auctionHouse contract to any user: transferFrom(auctionHouse, attacker, balance).

Putting these to points together means we can sweep all user balances to the auctionHouse contract, and then move it back to ourselves to steal the entire token balance! Of course, this seems great on paper, but we need to validate it with a 

 and use your Etherscan key from the previous step.

Once setup, your hardhat config should look similar to the following:

Note that since the contracts were deployed on Rinkeby, we need to specify chainId: 4 and a relevant block number to Rinkeby. In this case, any block number after the contract was deployed will work, but in general it will depend on the state you want to test against. (e.g. something happened after block x, so fork from block x+1)

Before we write the POC, we want to test that the fork is working as intended and that the correct state is being fetched. A simple way to do this is to create a file in the test folder and print some state, such as the current owner:

Run the test and confirm that it matches the correct owner (e.g. by reading the owner from Rinkeby Etherscan):

The owner address matches the state of the chain, so we can start building our POC. We want to code the following steps:

Move both accounts’ balance to the auction house contract

Move the auction house contract balance to some third address

A successful test confirms that we can move arbitrary token balances to and from the contracts. Start by funding 2 accounts through the devmint function (Note that this function was confirmed to be used on testnet only, so this arbitrary mint is not a bug).

Then, from the context of a different account (see that accounts[3] is used), move the tokens from account 1 and 2 to the auction house contract:

And finally, pull the auctionHouse balance back. In this case, account 3 is pulling the balance back to their own account:

And the test confirmed our idea – we can arbitrarily move anyone else’s token balances around, leaving everyone’s balances vulnerable to theft. The 

 would be to check that the sender is indeed the msg.sender, or that the auctionHouse is performing the transfer.

An actual hunting session should then end by writing a report for the dev – this is easily the most important part of effective bug hunting since it should precisely detail the issue, impact and fix. Unfortunately, report writing is out-of-scope for this tutorial 🙂

Over time, everyone develops their own techniques for hunting. There is no single correct technique, but I think it’s important to identify the style of hunting you prefer, and optimize for it. For example, you could prefer to hunt for bugs in a staging environment, in which case you’d prefer to find bugs on projects hosted on 

. In this case, it would make sense to read 

 to get a sense of the type of bugs other wardens have found. Alternatively, you may prefer to find bugs on deployed contracts, in which case you may look for targets hosted on 

. In this case, getting comfortable with mainnet fork testing, or quick heuristic testing with 

 will help your test your ideas quicker than other hunters, and prevent the chance of getting duped.

You could refine your hunting style further to look for common code-level bugs, or dig deeper to find contextual bugs. If you prefer to find common code-level bugs, such as an 

, it would make sense to iterate through all available targets as opposed to diving deep to fully understand all of a project’s nuances. On the other hand, if you are looking to find contextual bugs, it would make sense to read available audit reports to see what auditors have already highlighted as sensitive points. Even if the bugs are patched, you’ll get a sense of critical functionality, which may have changed since the code was frozen for an audit. Finding deep contextual bugs for a project has an additional advantage for hunters since many 

, meaning that your report will be valid across multiple targets from just one bug.

Lastly, as with traditional Web2 bug hunting, it’s important to just keep going! Keep testing and reviewing code, keep learning what new exploits are in the wild and you’ll come across valid bugs very soon. GLHF! 🙂

Getting started with smart contract in Bug Bounty

iOS is a widely used platform and in the previous article 

Getting Started with iOS Penetration Testing (Part 1)

, we discussed basic concepts of the iOS platform, different attack scenarios in static analysis and touched on the basic concepts to get started with the iOS penetration testing.

In this article, we will focus on a more advanced approach and continue solving other challenges available in our test application DVIA-v2, some important tools, and also look at the OWASP Mobile Top 10. This article will give you good knowledge to confidently perform a penetration test on an iOS application.

a list curated from research and feedback that identifies types of security risks faced by mobile applications

. The current version of OWASP Mobile Top 10 at the time of writing this blog is 

The first category in the list of OWASP Mobile Top 10 covers the aspects where an attacker can abuse the security control features provided by the iOS platform. In addition, sometimes due to failure in the proper implementation of platform features, multiple security issues could arise.

There are multiple components that are required to be analyzed under this category such as 

Biometric Authentication, Keychain, Platform Permission, etc.

Some of the general risks that occur under this category are:

Bypassing Local Biometric (Touch/Face ID) Authentication [Explained in Part-1]

The iOS applications often store some data locally in different components. There is a chance of getting sensitive data stored in the local storage that could be exploited if an attacker has access to the physical device of the user.

Most of the above-mentioned test cases were discussed in part-1 of the series.

The iOS application communications on a client-server architecture. Due to improper/weak implementation of the communication standards such as communication over HTTP, an attacker can attempt to steal sensitive information over unencrypted checks, perform Man-in-the-Middle or attempt to analyze the request/response by capturing them with proxy tools such as Burp Suite.

Communication over HTTP [Unencrypted Communication]

Plain-Text Submission of Sensitive Information

Logging Sensitive information in the Logs

When an application fails to properly perform the authentication checks or allows an attacker to manipulate the login/authentication requests to gain access to the victim user’s account, it is generally considered under the Insecure Authentication category.

Authentication Bypass using attack such as Injection Attacks

The iOS applications tend to store the user data or utilize the user data in different client-server requests. Due to a lack of strong cryptography, an attacker may attempt to access the data that is encrypted using the weak cryptographic method and gain hold of sensitive information.

Accessing Encrypted Client-Server Request Endpoints

The insecure authentication and insecure authorization are usually two checks which cause confusion. This attack talks about abusing the weak implementation of user authorization checks to perform attacks out of the user’s privilege and access level.

Due to the poor code quality, often, an attacker may attempt to pass the crafted inputs to function calls made within an app in an attempt to execute them or observe the application’s behaviour. It may lead to some mal-function and exploitable scenarios in the application.

If the application does not implement the code tampering checks, an attacker may attempt to modify the application code and inject malicious code such as a backdoor and distribute it using App Store and other methods that could lead to stealing sensitive information and comprising the user’s device as well.

The reverse engineering approach involves analyzing the binary and it’s code using tools such as Hopper, otool, IDA Pro in order to understand the application’s code patterns, various function implementation and performing bypass/attacks using runtime & dynamic instrumentation approaches.

One of the common examples is to analyze the implementation of SSL Pinning logic and understand the functions that are responsible for pinning checks and using tools such as Frida to bypass it by writing a custom logic script.

In general, before pushing an application to production, the development team keeps code to have easy access to the backend server, create logs to analyze errors or carry staging information and testing details. This code is extraneous to the functioning of the app. Basically, It has no use for the intended use once the app is in production and it is required only during the development cycle.

In certain cases, this code can carry information related to databases, user details, user permissions, API endpoints, etc. or disable functionalities like two-factor authentication.

Since we are now aware of the common security vulnerabilities that are often found in the iOS application, next we will be looking at some of the attack vectors using the 

application and also attempt to see how API analysis looks for the APIs originated from iOS devices.

It is recommended to read the attack description for each section provided in the application to understand the scenario we will be exploiting.

Launch the DVIA-v2 application and navigate to the 

Now, run the fridump tool on the application to extract the information from memory


https://github.com/Nightbringer21/fridump

Command: python fridump.py –usb -s DVIA-v2

file and search for sensitive information such as passwords and observe that the sensitive information was found in the application memory.

provide a malicious cross-site scripting payload such as 

Observe that the webview unsafely rendered the input and resulted in Cross-Site Scripting (XSS).

Ghidra to bypass the Anti Hooking and Debugging controls is nicely explained in the following blog:

https://philkeeble.com/ios/reverse-engineering/iOS-Anti-Anti-Hooking/

Launch the DVIA-v2 application and navigate to Side Channel Data Leakage > App Screenshot.

Add Some Information in the input field and background the application

/var/mobile/Containers/Data/Application/DVIA-v2/Library/SplashBoard/Snapshots

Open the SceneId and observe that the screenshot is present containing the information.

Launch the DVIA-v2 application and navigate to Side Channel Data Leakage >Pasteboard

Hook the application using objection and run the following commands:


Now, add some input in the input box, copy it and observe that the content is visible on the objection console.

The YesWeHack Blog

Abusing S3 Bucket Permissions

Parameter Discovery: A quick guide to start

The first live Bug Bounty for European scale-ups and unicorns

Abusing S3 Bucket Permissions

Getting started with smart contract in Bug Bounty

Getting Started with iOS Penetration Testing (Part 2)

DOJO CHALLENGE #15 Winners!

Getting started with smart contract in Bug Bounty

Subdomains Tools Review: a full and detailed comparison of subdomain enumeration tools

DOJO CHALLENGE #19 Winners!

DOJO CHALLENGE #18 Winners!

Subdomains Tools Review: a full and detailed comparison of subdomain enumeration tools

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous