This article will cover the essentials to get started with bug bounty hunting. There are many organizations with a need to have their assets tested for security. A bug may be present for a very long period before it is found and acknowledged as a security flaw in your application. Software engineering has developed several methods for developing and testing software, but these methods cannot guarantee bug-free software due to the intricate interdependencies that exist inside a single piece of code and across distributed programs operating on different platforms.
Software vulnerabilities allow unauthorized actors to break into, corrupt, modify or steal data from an information system when a defect is found to have security ramifications on a computer system or network. These software flaws and exploits provide value to many parties, including commercial software developers and vendors who have a strong interest in the security and safety of their products. As a result, as part of a professional software development approach, software businesses engage internal security researchers, engineers, and penetration testers to examine their software, uncover security vulnerabilities, and fix them regularly.
Bug Bounty Program vs Vulnerability Disclosure Program We have to choose between a Vulnerability Disclosure Program (VDP) and a Bug Bounty Program (BBP) without fully understanding the distinctions between the two. Let us dig into the detail.
Bug Bounty Program A bug bounty program encourages third parties to identify security flaws in a company’s software and submit them to the business so they may be resolved securely. The discoverers of the vulnerabilities are compensated financially in exchange. You may pick whether a BBP is private or public, depending on which option would work best for you. A bounty structure and response targets are only two additional components and parameters that make BBPs slightly more complicated than VDPs. Under general settings, you can see every parameter that must be customized for BBPs.
Vulnerability Disclosure Program
A VDP only specifies the precise procedures through which a company would wish to be alerted of potential security flaws discovered by outside third parties. Its goal is to provide information on where and how to disclose vulnerabilities so that the right team can take action.
A public vulnerability disclosure policy is a recommended practice because it motivates people to disclose security problems they discover.
A look into OWASP Top 10 2021 and trends
A01:2021-Broken Access Control Since the 2017 list, it moved up from the fifth spot to the category with the greatest danger to the security of web applications; the data that was submitted shows that, on average, 3.81% of applications evaluated had one or more Common Weakness Enumerations (CWEs), with more than 318k occurrences in this risk category. There were more instances of the 34 CWEs assigned to Broken Access Control than any other category in apps.
A02:2021-Cryptographic Failures It moves up one spot to no.2, formerly A3:2017-Sensitive Data Exposure, which was more of a symptom than a cause. The emphasis of the new term continues to be implicitly on cryptographic weaknesses. This category frequently results in compromised systems or the exposure of sensitive data.
A03:2021-Injection The 33 CWE is mapped into this category had the second-highest in applications with 274k occurrences, with a maximum incidence rate of 19% and an average incidence rate of 3.37%. 94% of the apps were checked for some type of injection. In this version, cross-site scripting is included in this category.
A04:2021-Insecure Design It is the latest category for 2021 that concentrates on design defect hazards. We require greater threat modeling, safe design patterns and principles, and reference architectures if our industry is to actually “go left.” A flawless implementation cannot repair a risky design since, by definition, the necessary security safeguards were never developed to protect against certain attacks.
A05:2021-Security Misconfiguration It goes up from no.6 in the previous edition; 90% of applications were examined for misconfigurations of some kind, with an average incidence rate of 4.5% and more than 208k CWE incidences assigned to this risk category. It’s not unexpected to see this category advance given the increasing shift toward highly flexible software. This risk category now includes the old category for A4:2017-XML External Entities (XXE).
A06:2021-Vulnerable and Outdated Components It was once known as “Using Components with Known Vulnerabilities” and is ranked no.2 in the Top 10 community survey. However, data analysis also allowed it to rank in the Top 10. This category rises from position nine in 2017 and is a well-known problem for which we struggle to test and evaluate risk. The default exploit and impact weights of 5.0 are taken into account when calculating their scores because it is the only category without any Common Vulnerabilities and Exposures (CVEs) mapped to the included CWEs.
A07:2021-Identification and Authentication Failures Dropping to second place, and now comprises CWEs that are more concerned with identity problems. Although the availability of standardized frameworks has expanded, this category still ranks in the Top 10 and appears to be benefiting from it.
A08:2021-Software and Data Integrity Failures It is a new category for 2021 that focuses on making unfounded assumptions about CI/CD pipelines, crucial data, and software upgrades. One of the 10 CWEs in this category has one of the largest weighted impacts from Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Scoring System (CVSS) data. The category A8:2017-Insecure Deserialization has been added to this one.
A09:2021-Security Logging and Monitoring Failures It was formerly A10: 2017-Insufficient Logging and Monitoring-and is included in the Top 10 community survey, rising from #10. This category has been widened to encompass a wider range of failure kinds, is difficult to test for, and is underrepresented in the CVE/CVSS statistics. However, visibility, event warning, and forensics can all be badly impacted by failure in this area.
A10:2021-Server-Side Request Forgery It comes in at number one on the Top 10 Community Survey. The information reveals a comparatively low incidence rate, above-average testing coverage, and above-average assessments of the potential for exploitation and impact. Although it isn’t yet shown in the statistics, this category indicates the scenario in which members of the security community inform us that it is crucial.
Black-box security testing
Sometimes, bug hunters are unable to access the target technology for reverse engineering because they are unaware of how it functions. This may apply to firmware that is contained in the software, network equipment, or even tamper-proof devices. In this case, bug hunters might approach the target technology as a “ black box”-a unit that receives particular inputs and generates a specific set of outputs. In essence, they are aware of the device’s function but not its mechanism.
Various parameters checked in black box testing are:
Accurate actions performed by users
The response time of the system
Use of data structures Issues in the user interface
Usability issues
System’s interaction with the inputs
Abrupt application failure, unable to start or finish
Performance issues
Black-box Testing Spotlight: State Transition Testing
Implementing various aspects of the same circumstance is the broad definition of “state transition,” and the state transition technique operates under this definition. It is used to record how a software program behaves when the same function is given several input values.
We all use ATMs, and when we withdraw cash, it displays our account information. Now when we complete another transaction, the ATM will once again display account information; however, the information presented following the second transaction will differ from that displayed on the first transaction.
State transition refers to the fact that the same function was used here, but the result changed each time. This method checks if a function is complying with state transition criteria while receiving various inputs when testing a software application. This relates to the kinds of programs that permit a certain number of access attempts, such as the login feature of an application that locks after a predetermined number of unsuccessful tries. To access the application, we must enter our email address and password. After the allotted number of attempts has been reached, the application is locked and an error notice appears. Let’s take a look at the state transition table below:
We can see that state S1 stands for the initial login attempt in the state transition table above. If the initial attempt is unsuccessful, the user will be sent to the subsequent try (state S2). A third try will be shown to the user if the second attempt is likewise unsuccessful (state S3). Now, if the user’s third and final attempt is unsuccessful, they will be sent to the error page (state S5).
However, if the third try is successful, the user will be sent to the homepage (state S4). Let’s see state transition table if third attempt is valid:
Software programs may be tested using the state transition table shown above. By identifying the intended output, we can simulate this table, which we can then use to test the software system to see if the required output is being produced. There are additional black box techniques used for testing such as:
Boundary Value Analysis
Equivalence partitioning
Decision Table Testing
Graph-Based Testing
Error Guessing Technique
Client- and Server-side Vulnerabilities
Client-Side Vulnerabilities In addition to utilizing a variety of third-party libraries that are both served by the custom application and frequently integrated with third-party services that supply their custom code and libraries into the same client-side application, browser-side applications are frequently a complex combination of custom HTML, CSS, and JavaScript. Instead of being controlled, maintained, and secured by the application owner, everything is run in the customer’s browser in the real world. Not simply the initial server hosting the server application and supplying the main components of the client-side JavaScript program to the user’s browser, browser apps typically communicate with a variety of servers.
As a result, client-side code is subject to several dangers that are not present in server-side programs. Consequently, a specific Top 10 is needed to address the security of the client-side web application code. A separate Top 10 for mobile apps, the OWASP Mobile Top 10, is comparable to this. The server side of a web app delivers REST services to the mobile app, which is typically the client side of a web app.
The main goal of this project is to categorize and list the security vulnerabilities that pertain to client-side browser code, such as JavaScript, Web Assembly, etc.
DOM-based XSS
Sensitive Data Leakage
Vulnerable and Outdated Components
Lack of Third-party Origin Control
JavaScript Drift
Sensitive Data Stored Client-Side
Client-side Security Logging and Monitoring Failures
Not Using Standard Browser Security Controls
Including Proprietary Information on the Client-Side
Server-side Vulnerabilities
A server-side request forgery (SSRF) attack makes use of server capabilities to provide the attacker access to or control over internal resources. By carefully selecting the URLs, the attacker may be able to connect to internal services like HTTP-enabled databases, retrieve server configuration data like AWS metadata, or submit post requests to internal services that are not supposed to be exposed. The URL that the server’s running code will use to read from or transmit data might be provided by the attacker or altered by them.
The server-side code detects the altered URL and tries to read data to it when the corrupted request is sent to the server. For example, the attacker may be able to read data from services that are not immediately exposed on the internet by choosing target URLs:
Cloud services such as AWS provide a REST interface on http://169.254.169.254/ where important configuration and sometimes even authentication keys can be extracted.
NoSQL database such as MongoDB provide REST interfaces on HTTP ports. If the database is expected to only be available to internally, authentication may be disabled and the attacker can extract data.
Internal REST interfaces.
The attacker may be able to read files using file:// URIs.
Additionally, the attacker might avoid input validation by using this feature to import untrusted data into code that only expects to read data from reliable sources. Bug Bounty Hunter’s core pathway
1. Learn Networking Fundamentals: You need to understand computer networks to start the bug bounty program. To start with, bug bounty, you don’t have to be an expert in computer networking, but you should at least be aware of the fundamentals, such as IP addresses, MAC addresses, the OSI stack (and TCP/IP stack), etc.
2. Learn the inner workings of the Web: A component of this is understanding the principles of web development and web protocols. HTML, CSS, and JavaScript are among the main programming languages used for the web. A fundamental skill level of proficiency in these languages is more than enough to get started. Learn about protocols including HTTP, FTP, TLS/SSL, and more.
3. Application Security and Techniques:
To do this, you’ll need to learn about common security precautions and safeguards and how to get past them, as well as about common web application vulnerabilities and how to spot, repair, and avoid them. These are books to take a look at:
Bug Bounty Bootcamp
Bug Bounty Hunting Essentials
Real-World Bug Hunting: A Field Guide to Web Hacking
Mastering Modern Web Penetration Testing
Alice and Bob Learn Application Security
4. Look into hands-on training: It takes practice to come up with a plan of attack for a target. As you encounter more various targets with differing degrees of complexity, it will become easier for you to approach a web application in a way that increases your chances of uncovering a serious vulnerability (or even finding a vulnerability if the application is well-secured and has already been tested by many hunters). Make the most of these tools by attempting to: Internet programs at risk: These virtual computers or web software packages are intentionally vulnerable. Susceptible web applications can be divided into two categories: generic versions that cover a wide range of flaws and specialized versions that focus on a single flaw and its intricacies.
There are several ways to train before jumping into a bug program. The most consistent way to get practical training in application testing is to deploy one of your own. The Vulnerable Web Applications Directory (VWAD) by OWASP lists various vulnerable mobile, offline, containerized and online applications that are are available for use in hands-on training.
Instances such as BWapp, DVWA, and Webgoat are good for beginners and learning the steps required to deploy an application in general. Refer to this article below if you plan on using Kali Linux to start training:
https://systemweakness.com/deploy-vulnerable-web-applications-for-application-security-appsec-training-in-under-30-minutes-1554585ccd74
5. Exploitation in the field:
When you have thoroughly mastered the essentials and are competent enough, you may start looking at reliable websites. Several websites provide bug bounty programs for their online resources. Major programs include:
Those listed on BBP platforms HackerOne, BugCrowd, and Intrigriti
Big companies such as Google, Twitter, Verizon, Facebook, Apple
Due to their tough competition, some organizations offer substantial incentives, but finding a security weakness in any of their assets is quite difficult. Keep in mind that the world’s top bug bounty hunters are also testing these websites but that doesn’t always mean you can’t find anything. Stay motivated!
6. Threats, Vulnerabilities and Reporting methods:
By adopting the efforts of famous academics, you may benefit from their discoveries. You may look at reports that have been made public on websites for BBPs like the ones above.
Computer Emergency Readiness Team Coordination Center (CERT/CC) offers a comprehensive, regularly updated vulnerability database.
SecurityFocus provides a feed of recent advisories but updates may not be as frequent.
National Vulnerability Database (NVD) is a reputable source of information on vulnerabilities with 2 feeds: all recent CVE vulnerabilities & fully analyzed vulnerabilities.
US-CERT and ICS-CERT regularly publish summaries of high-impact security incidents.
Full Disclosure (now SecLists.org) is an older feed of vulnerability information, may contain discussion and chatter.
Many vendors offer their own feeds of advisories, asset management can help stay informed of vulnerabilities/patches specific to products used.
Check this out!! Bug Bounty Platforms often host “hacktivity” alerts in which hunters can see the latest disclosed vulnerabilities right in their dashboards. There are also alternative ways to get alerts such as twitter and RSS feeds.
You should be aware that if you’re serious about participating in the bug bounty program, it doesn’t matter what kind of degree you have or what your current job is-you can immediately start acquiring the required skills and gear and start searching right away!
Related
Bug Bounty for Beginners (Part 2): Recon for Modern Bug Hunting
Bug Bounty for Beginners (Part 3): Understanding The Reporting Process
References
OWASP Top 10:2021
Page404 | Briskinfosec
Deploy vulnerable web applications for Application Security (AppSec) training in under 25 minutes
OWASP Top 10 Client-Side Security Risks
OWASP Vulnerable Web Applications Directory
Originally published at https://www.linkedin.com.
Comments