As a cybersecurity and penetration testing company, it is important for us to have a clear and thorough methodology in place to ensure the effectiveness and reliability of our services. In this article, we will discuss our approach to penetration testing and the tools and techniques we use to identify and address vulnerabilities in our clients’ systems and networks. We will also address the role of automation in our testing process and the importance of manual analysis in ensuring the thoroughness of our testing. By understanding our methodology, clients can have confidence in the reliability of our findings and recommendations for improving their cybersecurity posture.

The Mindset

Having the right mindset is crucial in any field, as it can greatly influence your approach and attitude towards tasks and challenges. In the field of cybersecurity and penetration testing, having the right mindset is especially important, as it can determine how effective you are at identifying and addressing vulnerabilities.

A system is typically made up of three main components: a tech stack, a code base, and the logic of the system.

The tech stack refers to the underlying technologies and infrastructure that support the system. This can include things like the operating system, web server, database, and programming languages.

The code base refers to the actual source code of the system, including any custom scripts or libraries.

The logic of the system refers to the application logic, business processes and rules that the system is designed to follow & implement.

Each of these components can have its own set of vulnerabilities that can be exploited by attackers.

For example, the tech stack may have vulnerabilities if the system has used an operating system with known vulnerabilities or mis-configured web server that can be exploited. The code base may have vulnerabilities due to poor coding practices or the use of outdated libraries. The logic of the system may have vulnerabilities due to flaws in the way that business & application logic is implemented.

To ensure that a system is secure, We at Snapsec test all three aspects of the system: the tech stack, the code base, and the logic of the system.

This includes looking for mis-configurations issues, finding unpatched and misconfigured services and components in the tech stack. It includes using open-source or commercial tools to do vulnerability scanning an well as well manually performing research on the tech stack implemented in the target syste,

If we are granted access to the code base, we conduct a comprehensive security test by manually reviewing the code and utilizing automated scanning tools to identify potential vulnerabilities. This process involves detecting issues such as SQL injection attacks, buffer overflows, and other types of vulnerabilities.

However, in the absence of access to the source code, we interact with different parts of the system to gain a thorough understanding of its workings. Once we have identified all possible attack points in the target system, we perform a comprehensive vulnerability test to determine any security loopholes.

We also spend in numerous amount of time in learning the workflows and the business logic of the target system and then alter the normal workflows to produce a malicious behaviour in the system and finally try to escalate that to security venerability that can be used against the system.

Our Methodology

Modern web applications often have complex and extensive information processing systems, which can make secure implementation challenging. To address this, people often use various methodologies such as OSSTMM, OWASP, NIST, and PTES to conduct security assessments. However, these methodologies often focus on attacking the technical aspects of the application and may not address the more logical elements of the system. This can leave certain vulnerabilities unaddressed for example Busness logic issues are a really good example supporting this claim.

So we at snapsec have a 5 step process of Finding security vulnerabilities in any target system:

• Understanding the Business Purpose of the System
• Understading the technical purpose of the System
• Understanding How they do it
• Creating Assumptions
• Attacking the system

Let’s use the example of Snapsec testing Google Forms to examine these steps in more detail.

• Understanding the Business Purpose of the System

To begin with, it is important to understand the purpose of the web application being tested. In the case of Google Forms, the app is used for collecting responses and conducting surveys and polls. This understanding of the app’s purpose can help guide the testing process and ensure that all relevant areas are covered.

• Understading the technical purpose of the System

After understanding the purpose of the web application, the next step is to examine its technical details. This may include identifying the number and types of APIs exposed, understanding the flow of information between the browser and server, and determining the presence of access control models or technologies such as markdown. In the case of Google Forms, it would be important to understand the types of information being published about forms and any technologies being used to manage access to them. This technical analysis can help identify potential vulnerabilities and areas of focus during the testing process.

• Understanding How they do it

After gaining a broad understanding of the web application, the next step is to examine individual features in more detail. This may involve understanding how certain features are implemented and how they work. For example, in the case of Google Forms, this could include looking at how the app handles making forms public and private, and how the export feature functions. By thoroughly analyzing individual features, it is possible to identify any potential vulnerabilities or weaknesses and plan the testing accordingly.

It is crucial to comprehend how the company you are targeting has achieved and designed their product, as if you were to request 100 developers to construct Google Forms, they would each create it in a unique way.

• Creating Assumptions

After understanding the app both from technical and business perespective, We start making assumptions about various aspects of the target system and consider what could go wrong. For example, in the case of Google Forms, this could involve asking questions such as: Can responses be sent via HTTP requests for a Closed/Private form? Can an out-of-range option be selected in a poll and, if so, what potential issues could arise? By considering these types of scenarios, it is possible to identify potential vulnerabilities and develop a plan to test them.

• Attacking the APP

Once assumptions have been made, the next step is to test them to see if they can cause abnormal behavior in the web application. Continuing with the example of Google Forms, this could involve attempting to select an out-of-range option in a poll and determining if it is possible to distort the collected response data. By testing these assumptions, it is possible to identify any vulnerabilities and take steps to address them.

Vulnerability Chaining

During the assesment we keep record and track any abnormal behavior that is detected, even if it is not immediately exploitable. This is because these behaviors may indicate the presence of a potential vulnerability that could be exploited in the future. By keeping a record of these issues, it is possible to identify other vulnerabilities that may be chanined toghether and potentially combine them to create a more impactful vulnerability.

What type of issues do we Look for ?

The types of security vulnerabilities that are looked for during a penetration test can vary depending on the asset being tested. For example, if the asset being tested is a web application, a list of relevant web application vulnerabilities will be targeted. These may include vulnerabilities such as SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and insecure direct object references.

If the asset being tested is an Android app, a different set of relevant vulnerabilities will be targeted. These may include vulnerabilities such as insecure data storage, insecure communication, and inadequate cryptography.

It is important to note that the list of vulnerabilities that are targeted during a penetration test can differ from asset to asset, and may also vary depending on the specific goals and objectives of the test.

INJECTION ATTACKS: Injection attacks involve injecting malicious code or commands into a system or application in order to execute unintended actions. These attacks can be difficult to detect and can have serious consequences, such as data loss or unauthorized access to sensitive information.

BROKEN AUTHENTICATION AND SESSION MANAGEMENT: This refers to vulnerabilities in the way that a system or application handles authentication (verifying the identity of users) and session management (maintaining a user’s authenticated state). If these processes are not implemented securely, it can leave the system open to attack.

SERVER SECURITY MISCONFIGURATION: This refers to servers that have not been configured correctly, which can leave them vulnerable to attack. Common security misconfigurations include open ports, insecurely configured services, and outdated software.

UNPATCHED SERVICE: This refers to software or services that are not kept up to date with the latest security patches. Outdated software can contain known vulnerabilities that can be exploited by attackers.

INSUFFICIENT SECURITY CONFIGURABILITY: This refers to systems or applications that do not allow sufficient control over security settings, which can leave them vulnerable to attack.

CLIENT SIDE VULNERABILITIES (XSS, CSRF, CORS MISCONFIGURATIONS ETC): These types of vulnerabilities refer to weaknesses on the client side (e.g. the user’s web browser) that can be exploited by attackers. Examples include cross-site scripting (XSS), cross-site request forgery (CSRF), and misconfigured cross-origin resource sharing (CORS).

BUSINESS LOGIC ISSUES: This refers to vulnerabilities in the way that a system or application handles business processes and rules. These vulnerabilities can allow attackers to bypass security controls or manipulate data in unintended ways.

INFRASTRUCTURAL ISSUES (HTTP REQUEST SMUGGLING, CACHE DECEPTION ETC): These types of vulnerabilities refer to weaknesses in the infrastructure (e.g. network devices, servers, etc.) that support a system or application. Examples include HTTP request smuggling and cache deception.

FILE UPLOAD VULNERABILITIES: These types of vulnerabilities refer to weaknesses in the way that a system or application handles file uploads, which can allow attackers to execute malicious code or gain unauthorized access.

PRIVACY VIOLATION ISSUES: This refers to vulnerabilities that can allow attackers to access or misuse sensitive personal information.

INSECURE RANDOMNESS ISSUES: This refers to weaknesses in the way that a system or application generates random numbers or strings, which can leave it vulnerable to attack.

CRYPTOGRAPHIC ISSUES: This refers to vulnerabilities in the way that a system or application implements cryptography, which can leave it vulnerable to attack.

DEFAULT MISCONFIGURATION ISSUES: This refers to systems or applications that have not been properly configured, which can leave them vulnerable to attack.

PRIVILEGE ESCALATION ISSUES: This refers to vulnerabilities that allow attackers to gain unauthorized

DEFAULT CREDENTIALS ISSUES: This refers to the use of default or easily guessable credentials (e.g. “admin” as the username and “password” as the password) for accessing systems or applications. This can be a security issue because it makes it easy for attackers to gain unauthorized access.

What kind of tools do we use for testing?

Tools used for identifying vulnerabilities can vary depending on the type of asset being tested. For web applications, tools such as Burp Suite, SQLmap, Metasploit, FFUF, Dirseach, Nuclei, nessus, Amass and a tons of Burpsuite plugins are commonly used to identify vulnerabilities.

While as for testing the security of Mobile applications, tools such as APKtool, Drozer, Burp Proxy, MobSF and Android Studio are to be used.

Other tools that may be used for identifying vulnerabilities in different types of assets include:

Network scanners and analyzers: These tools are used to scan networks and identify vulnerabilities in network infrastructure. Examples include Nmap and Wireshark.

Vulnerability scanners: These tools are used to scan systems and applications for known vulnerabilities and provide recommendations for addressing them. Examples include Nessus and Qualys and Nuclei by @projectdiscovery.

Ultimately, the choice of tools used for identifying vulnerabilities will depend on the specific needs and characteristics of the asset being tested, as well as the preferences and expertise of the testers.

About us

Snapsec is a team of security experts specialized in providing pentesting and other security services to secure your online assets. We have a specialized testing methodology which ensures indepth testing of your business logic and other latest vulnerabilities.

If you are looking for a team which values your security and ensures that you are fully secure against online security threats, feel free to get in touch with us #support@snapsec.co