Introduction:
I found out about and started bug bounties in the beginning of high school while looking for ways to make money online. This seemed like a good idea because it was related to security which I was already interested in and it did not have any requirement to start. The programs offer a part of the pathway into cybersecurity careers without requiring traditional job applications or entry-level positions. Bug bounty is the only path where anyone can legally hack real companies without being hired. You also get the knowledge of how companies are run (tech and personnel) and the systems behind them. You learn this during interacting with the company via the vulnerability reports but also when researching/manipulating the systems they use. Bug bounty can teach you more technical skills than some jobs that do require applications. This path for me was one of the things that enabled me to secure multiple internships during my current college experience.

Bug bounty is a great training ground:

Doing hands-on security research with live production systems across diverse tech stacks and real environments, you learn how companies and infrastructure actually operate. The knowledge comes from seeing their product development or dealing with security team sizes (sometimes just one person) all the way to different resource constraints like money or development time. It forces you to master reconnaissance and identification of potential bugs or vulns, in mostly black box and constrained situations. The experience builds five key transferable skills for red teaming: general process flow understanding (systems, HR, finance, IT), application security (APIs, Access Control, etc.), timing and processing vulnerabilities, privilege escalation, and understanding the business implications the vulnerabilities have (payment bugs, compliance fees, etc)

The psychology, beyond the money:

The benefits of participating in bug bounties extend far beyond financial gain. Initially, I did not achieve success with monetary bounties, but the experience taught me invaluable lessons about security flaws that I would never have thought about. As a side note, I eventually did start to receive some nice paying bounties. The psychological aspects to security in general are crucial, but specifically when you are hunting for bugs. Using persistence to your advantage by focusing on one app, one site, one function, you will become an expert and know it inside out. Leading to finding bugs or inconsistencies faster. Handling rejection is a big part of the game as well, you must control your emotions and understand there is never 100% success. You must also recognize there is an aspect of luck to the entire process of vulnerability reporting. Dealing with duplicates teaches you that you aren’t the only one that can do what you do, which means there’s actual competition. This is good. That means you have to become fast at finding things or looking at them in a unique way to survive. Lastly, learning from triage feedback becomes a skill in itself. You have to be able to take criticism and not let your ego get in the way.

Building a network and reputation

Being involved in the security community in general helped me build a network and ultimately led to a job opportunity. By being online constantly, liking, searching, following all got me there, engagement is key. Make it so that people can’t ignore you. Go to webinars, discord servers, and publish things to GitHub. The word I ring in my head everyday: output. Before applying for positions, I built a resume and site to be able to showcase my contributions to the field.

Creating tools and sharing knowledge:

I have built multiple projects that have helped spread my name and also help operators as well. Building tools or sharing research for free proves multiple things. First, you are doing it for no cost, showing interest and pride in your work it also proves your competence and establishes your credibility in the community.

Filling the gap:

I have used resources to learn beyond pure experimentation on platforms. To learn more of the technical and foundational ideas, I used sites like TryHackMe and HackTheBox, watching a lot of videos on YouTube, and taking different certifications and their subsequent courses.

The skills I needed to learn for red teaming that bug bounty didn’t teach are included but not limited to OPSEC, command and control structure, looking for different material sometimes (not just strict credentials), and being attack path focused. There is a heavy focus on credential material and using that to expand your scope of damage as an attacker. This shows you, with whatever you are studying, there is always something else to explore or learn.

Start now:

I started in the beginning of high school to get capital and experience without employment. Just find one that has a good amount of functionality and dig in, no questions asked. Focus on learning, not just bounties.

Document everything:

How you document your learning & building journey matters. I use blog posts for spreading your research, X and short form for quicker info, YouTube for longer form content, LinkedIn for the career side, and GitHub repos to store all the code, research, and POCs. A lot of the work you are doing doesn't matter unless it is shared to the community or proper consumers. Security is a community effort, therefore we should all give some of our output towards it.

Conclusion:

I started my career as a high school student with no formal experience. Bug bounty provided technical training, real-world experience, and networking opportunities. It teaches you to think critically about security from both attacker and defender perspectives. The backwards implications of bug bounty help you learn a technical skill, gain experience, and transfer that into career knowledge or career positions. As you advance, you either abstract from the previous job or get really fine tuned from your starting point, and bug bounty is the perfect foundation for either path. Start researching and hacking. Everything will fall into place as you go. Don’t ask too many questions or you will never get started.

Hello everyone! Today I have completed the “Sneaky Patch” box, which is rated easy but is a forensics box which I have not had to much experience with. Although it was pretty straight forward. Lets start with reading the description:

Investigate the potential kernel backdoor implanted within the compromised system.

This means we should keep our eyes peeled for a couple items:

• A patch?
• Backdoor?

Lets keep that in mind, while we list loaded kernel modules and look for anything unusual. We run:

lsmod | sort

and get the following output:

8021q 45056 0
Module Size Used by
aesni_intel 356352 0
autofs4 57344 2
binfmt_misc 24576 1
crc32_pclmul 12288 0
crct10dif_pclmul 12288 1
cryptd 24576 2 crypto_simd,ghash_clmulni_intel
crypto_simd 16384 1 aesni_intel
dm_multipath 45056 0
efi_pstore 12288 0
ena 151552 0
garp 20480 1 8021q
ghash_clmulni_intel 16384 0
input_leds 12288 0
ip_tables 32768 0
llc 16384 2 stp,garp
lp 32768 0
mrp 20480 1 8021q
msr 12288 0
nfnetlink 20480 2
parport 73728 3 parport_pc,lp,ppdev
parport_pc 53248 0
polyval_clmulni 12288 0
polyval_generic 12288 1 polyval_clmulni
ppdev 24576 0
psmouse 217088 0
sch_fq_codel 24576 3
serio_raw 20480 0
sha1_ssse3 32768 0
sha256_ssse3 32768 0
spatch 12288 0
stp 12288 1 garp
x_tables 65536 1 ip_tables

The first thing that pops out to me is the size of certain modules and if they are being used by anything. Also what we were looking for earlier, a patch or a backdoor? We see spatch 12288 0 with a relatively low module size and is not being used by anything, it also matches the name for a patch.

Lets investigate this module further, with the following command:

sudo modinfo spatch

and we get the following output:

filename:       /lib/modules/6.8.0-1016-aws/kernel/drivers/misc/spatch.ko
description:    Cipher is always root
author:         Cipher
license:        GPL
srcversion:     81BE8A2753A1D8A9F28E91E
depends:        
retpoline:      Y
name:           spatch
vermagic:       6.8.0-1016-aws SMP mod_unload modversions 

I am not too sure for what to look at here but two things stand out to me, the location and author of the module. author: Cipher and /misc/spatch.ko.

With knowing the location, lets take a look at the strings of it, to see if we can identify any IP addresses, URLs, or commands. With the following command:

strings /lib/modules/6.8.0-1016-aws/kernel/drivers/misc/spatch.ko

and we get the following output at the top of the file:

Linux
Linux
AUATL
[A\A]]1
AUATL
get_flagH9
[A\A]]1
cipher_bd
/tmp/cipher_output.txt
/bin/sh
%s > %s 2>&1
get_flag
/root/src/spatch.c
HOME=/root
3[CIPHER BACKDOOR] Failed to create /proc entry
6[CIPHER BACKDOOR] Module loaded. Write data to /proc/%s
6[CIPHER BACKDOOR] Module unloaded.
3[CIPHER BACKDOOR] Failed to read output file
6[CIPHER BACKDOOR] Command Output: %s
3[CIPHER BACKDOOR] No output captured.
6[CIPHER BACKDOOR] Executing command: %s
3[CIPHER BACKDOOR] Failed to setup usermode helper.
6[CIPHER BACKDOOR] Format: echo "COMMAND" > /proc/cipher_bd
6[CIPHER BACKDOOR] Try: echo "%s" > /proc/cipher_bd
6[CIPHER BACKDOOR] Here's the secret: 544-HEX-REDACTED-FOR-WRITEUP
PATH=/sbin:/bin:/usr/sbin:/usr/bin

This seems to be exactly what we are looking for, the Cipher Backdoor. The last line of that [CIPHER BACKDOOR] looks interesting, by decoding that, we find the flag.

If you liked this and want to see more, consider following me here on medium or visiting my site:
https://atomiczsec.net

and don’t forget to check out https://tryhackme.com/room/hfb1sneakypatch

These are one of my favorite bugs to hunt for because it requires a different type of thinking. Plus it’s all manual so there is a little less chance of duplicates.

First Bug: Request Manipulation leads to infinite amount of money on trading simulator

Introduction: Trading simulators offer a safe platform to learn about cryptocurrency markets without real financial risks. However, vulnerabilities can be exploited for unauthorized gains. This article discusses a significant bug in a trading simulator that allowed users to generate limitless money through a logic error.

The Bug: Exploiting Negative Trading, Within the trading simulator’s trade function, a flaw enabled users to manipulate trading requests. By purchasing “negative” amounts of cryptocurrency using a tool like Burp Suite, users could trick the system into adding funds to their cash wallet.

Exploitation Process: Burp Suite was used to intercept and alter the trading requests, changing the intended purchase amount to a negative value. The system’s flawed logic failed to account for this, resulting in unauthorized wealth generation. I did this through changing the purchase order from 5000 to -5000

Impact:
Unauthorized Funds Gain: The attacker can exploit the ability to buy “negative” amounts of cryptocurrencies, essentially receiving money back into their cash wallet. This unauthorized funds gain can lead to financial losses for the crypto exchange, as well as undermine the integrity of the market simulator.

Market Manipulation: By injecting fake trades with negative quantities, the attacker can manipulate the market simulation, distorting prices, and misleading other users. This can create a false sense of market activity and affect legitimate traders’ decisions.

Financial Losses for Legitimate Users: The presence of an attacker engaging in negative trades could potentially impact other legitimate users’ trades. It may lead to unexpected price movements, liquidity issues, or failed trades, resulting in financial losses for innocent participants.

Reputation Damage: The existence of such a vulnerability in a crypto exchange simulator can significantly damage the platform’s reputation and trust among its users. Security flaws in financial systems, even if limited to a simulation environment, raise concerns about the overall security and reliability of the platform.

Regulatory and Legal Implications: If the crypto exchange market simulator is being used for training or demonstration purposes within a regulated financial environment, the presence of this vulnerability may raise regulatory compliance issues. Such issues could result in legal consequences for the organization operating the simulator.

Loss of User Confidence: Users who are testing the crypto exchange simulator for learning or training purposes might lose confidence in the platform’s reliability and data accuracy, affecting its educational value.

Tips to test for this bug:

1. Input Validation and Boundary Testing: Similar to the described bug, always test input fields for unexpected inputs. Manipulating inputs beyond the expected boundaries, such as negative values or excessive values, can reveal vulnerabilities.
2. Use Tools like Burp Suite: Tools like Burp Suite are invaluable for intercepting and modifying requests. By altering requests and observing how the application responds, you can identify potential vulnerabilities like the one described.
3. Logic Errors: Look for logic errors in the application flow. Consider scenarios that the developers might not have anticipated, like buying negative quantities in this case. Exploiting overlooked logic can lead to unauthorized gains.
4. Simulator Environments: In simulated environments, developers might not prioritize security as much as in production environments. Exploit this by checking if flaws in the simulator exist due to relaxed security measures.
5. Impact Assessment: Analyze the potential consequences of discovered vulnerabilities. Consider how they could be exploited beyond just immediate financial gain. This could include market manipulation, data integrity, and potential harm to legitimate users.
6. Market Manipulation: Be aware of how vulnerabilities could manipulate the intended behavior of the platform. This can distort prices, create false market trends, and mislead users.
7. User Interaction: Analyze how different users’ actions might interact with one another and how vulnerabilities could impact user experiences. This includes considering interactions between malicious and legitimate users.
8. Reputation and Trust: Think about how vulnerabilities, even in non-real environments, can impact user trust and reputation. Consider how these issues might be perceived by users, even if they don’t result in real financial losses.
9. Regulatory and Legal Implications: If the platform is related to a regulated industry, be aware of the potential regulatory and legal consequences of discovered vulnerabilities. This can add another layer of seriousness to the situation.
10. User Education: If the platform is used for educational purposes, vulnerabilities can impact the learning experience. Explore how vulnerabilities might affect users’ confidence in the platform’s educational value.
11. Third-Party Components: Investigate any third-party components or libraries used in the platform. These can sometimes introduce vulnerabilities that attackers can exploit.
12. Continuous Testing: Just as developers need to continuously update and maintain applications, security testers should continuously explore for new vulnerabilities, as new features and changes can introduce new attack vectors.

Second Bug: Race Condition Leads to infinite enterprise seats bypassing pricing model

The bug identified is a race condition vulnerability in the “Invite Collaborators” feature of the bug bounty platform. By exploiting this vulnerability, an attacker can bypass the seat limit of a pro license and invite an unlimited number of users to their project, gaining enterprise-level access without paying for it. This can lead to unauthorized access to resources and privileges, potentially compromising the integrity and security of the platform.

Exploitation:
I used the race condition vulnerability to rapidly send multiple requests to the “Invite Collaborators” feature. This manipulates the system’s response time, allowing the attacker to invite collaborators beyond the intended seat limit before the system can properly enforce restrictions.

Impact:

Unauthorized Enterprise Access: Attackers can exploit this flaw to access enterprise-level privileges without the necessary payment or authorization. This not only devalues the premium pricing model but also jeopardizes the platform’s integrity by allowing unauthorized users to benefit from premium features.

Financial Losses: By bypassing the pricing model, attackers can avoid paying for higher-tier licenses. This results in direct financial losses for the platform, undermining its sustainability and ability to provide quality services.

User Management Disruption: Legitimate users might face confusion as unauthorized users occupy available seats, impacting their collaborative efforts and diminishing the platform’s functionality.

Security Compromises: Unrestricted access granted through this vulnerability may compromise the security of sensitive resources and data shared within projects. The integrity of the platform is at stake as unauthorized access can lead to data breaches and exposure.

Trust Erosion: The presence of such a vulnerability erodes user trust. Clients expect that access tiers are maintained to ensure fair pricing and resource allocation. Discovering that these boundaries can be manipulated damages the platform’s reputation.

Mitigation and Prevention: Bug bounty platforms must prioritize security by conducting comprehensive testing and implementing rigorous access controls. Regular vulnerability assessments and code reviews can identify and rectify such flaws before they are exploited.

Tips to find this bug:

1. Understand Race Conditions: Develop a solid understanding of what race conditions are and how they can occur. A race condition happens when multiple processes or threads compete to access shared resources, potentially leading to unexpected behavior.

2. Identify Critical User Actions: Focus on user actions that involve multiple steps or transactions, especially those that might involve simultaneous interactions with the system. In this case, the “Invite Collaborators” feature triggered a race condition.

3. Concurrency Testing: Use tools or techniques that allow you to simulate concurrent interactions. You can run multiple instances of an action simultaneously to see if they interfere with each other and lead to unintended outcomes.

Third Bug: User Impersonation Vulnerability in Retention Request Form

The Retention Request Form on this program allows users to submit a request for items in your department would like to retain on the website. However, there is a vulnerability in the form that allows an attacker to impersonate another user and submit this request on their behalf. The vulnerability is due to a lack of validation and authentication checks on the form inputs. Furthermore, there is no rate limiting on the number of submissions that can be made from a single IP address. This means that an attacker can send a number of messages acting like different emails to convey a message or frame users.

Impact:
An attacker can use this vulnerability to impersonate any staff or faculty member of the website and submit a request on their behalf. This could lead to reputational damage for the impersonated individual and potentially compromise the security of the website. An attacker could also use this vulnerability to gather sensitive information by tricking users into submitting feedback containing confidential data. In addition, the lack of rate limiting allows an attacker to submit a large number of Retentions from different emails and with different messages, potentially overwhelming the system and causing a denial-of-service (DoS) attack. This can impact the availability and performance of the website and disrupt normal operations.

Tips to find this:

• Test Different Inputs: Experiment with different types of inputs. Try submitting requests with fake email addresses, attempting to impersonate other users. Test if you can inject malicious content into the form fields.
• Use Tools: Utilize web security tools like Burp Suite, OWASP ZAP, or similar tools to intercept and inspect the requests being made. These tools can help you understand the data being sent and received by the form.
• Inspect Server-Side Processing: Examine the server-side code that processes form submissions. Check whether the submitted data is being properly validated and authenticated. Look for any potential vulnerabilities or weaknesses in this part of the code.
• Check for Authentication Flaws: Verify if the form properly enforces user authentication before allowing submission. Ensure that only authorized users are allowed to submit requests on behalf of others.
• Implement Proper Validation: Enhance the form’s input validation to ensure that only legitimate data is accepted. Validate email addresses, limit the input length, and sanitize input to prevent potential injection attacks.

Bug Number One:
IDOR leading to disclosure of location of any team

I was hunting on a program on hackerone and I was spidering through their application. For this, I click on every function through the app. I click every single button, and try every single feature it has to offer. Sometimes I will go to the extent of buying the premium version just to get access to more functionality.

I came across this one endpoint: /forecasts/ which allowed you to get the forecast of your teams weather so you know when to have practice or meet. I then looked at the full request in my burp history and saw the full endpoint: “api.redacted.com/forecasts/search?team_id=123” I looked at what type of data I am getting back from the program and the response was showing [State, City, County, Longitude , Latitude ] of the team! Next thing in mind was for me to change the team id. I changed the ID and BOOM! I got a new location with all of this information. An attacker could enumerate a team by its name and exact location.

Bug Number Two: IDOR leading to viewing messages of any user

Stumbling Upon the POST Request
While sifting through the Burp Suite’s HTTP history, I noticed an intriguing POST request — /Messages/MostRecent. My curiosity piqued as I realized this could be a significant entry point into the companies messaging system.

Analyzing the Payload:

Delving deeper into the POST request, I examined the request payload and identified a critical parameter called “userId.” It seemed that this parameter dictated whose recent messages were fetched by the application.

Testing with My Own User ID

I decided to start with my own user ID and crafted a POST request with the payload containing my ID. To my confirmation, the calculator responded by displaying my most recent messages.

POST /Messages/MostRecent HTTP/2
Host: www.redacted.com
Content-Length: 94

{"userId":57231173,"count":18,"freeStepsTrialTest":{"cvid":null,"type":0}}

The Vulnerability Unveiled

With growing concern, I realized that if I could access my messages this way, there was a possibility that other users’ private conversations could be exposed too. The vulnerability of an Insecure Direct Object Reference (IDOR) loomed before me.

Tampering with the “userId” Parameter

To validate my suspicions, I devised a plan to tamper with the “userId” parameter in the POST request’s payload. Changing the value to a random user ID, I executed the request again. To my dismay, the application obediently returned private messages that did not belong to me.

Bug Number Three: Information Disclosure with IDOR

This IDOR was the quickest IDOR I have ever found. I was hunting on a private programming with one of my friends and we were exploring the application. I once again was checking all of the requests through my burp history and found the endpoint:

/v2/groups/ID-HERE

I noticed the ID as usual and change the ID to see what would happen. This bug lead to me being able to get the following information for random teams:

The data returned includes the full names, phone numbers, and amount of users subscribed to the group, among other sensitive information.

1. Deep Dive into HTTP History: When hunting for Insecure Direct Object References (IDORs), always take the time to thoroughly inspect the HTTP history within Burp Suite or any other interception proxy. Frequently, you’ll stumble upon undiscovered endpoints with sensitive functionalities or data that can lead to significant vulnerabilities.
2. Parameter Manipulation Testing: Don’t limit yourself to testing only the most obvious parameters for IDOR vulnerabilities. Go beyond the standard parameters and explore different combinations, custom headers, cookies, or even URL variations. Sometimes, a simple tweak in these elements can expose critical IDOR flaws.
3. Contextual Assessment for Impact: Understand the potential impact of an IDOR beyond the immediate vulnerable endpoint. Consider how the information obtained can be leveraged to attack other parts of the application or the system. For instance, if you can access user data, can you escalate privileges or compromise other accounts?
4. Bypassing Access Controls: Investigate whether there are any access controls in place for sensitive resources. Often, IDOR vulnerabilities can be mitigated by proper access control mechanisms. Attempt to bypass these controls to ensure they are robust and effectively protect against unauthorized access.
5. Comparative Analysis: When you discover an IDOR in one part of the application, check if there are similar functionalities or endpoints that handle similar data. These might be susceptible to the same vulnerability. Look for patterns and commonalities in how the application handles object references.
6. Parameter Whitelisting: Some applications use parameter whitelisting to restrict user access to specific resources. Look for patterns in the allowed values for parameters and test whether you can manipulate these values to access unauthorized resources.
7. Enumerate and Exploit User Roles: If the application employs role-based access control, systematically test each user role to identify potential IDORs. Different roles might have varying access privileges, so enumerate all possible roles and test them individually.
8. Horizontal and Vertical IDORs: Distinguish between horizontal and vertical IDORs. Horizontal IDORs involve accessing the same type of resources belonging to other users (e.g., accessing another user’s profile). Vertical IDORs entail escalating privileges to access higher-level resources (e.g., administrative accounts). Both types can coexist, so check for both.
9. Context-Specific Testing: Tailor your testing approach based on the application’s specific functionalities and requirements. Different applications handle data and resources differently, so adapt your testing methods accordingly to improve the chances of discovering IDOR vulnerabilities.
10. Limiting Scope: While IDOR testing should be thorough, it’s essential to stay within the scope defined by the program or the project. Avoid testing resources that are clearly out of scope, as it may violate the rules and negatively impact your reputation as a security researcher.
11. Document and Report Clearly: When you find an IDOR, document the steps to reproduce the vulnerability thoroughly. Provide a clear and concise report to the development team or the organization, including the potential impact and possible remediation steps. A well-documented report increases the likelihood of a swift and effective fix.

Here are the stats that I will be breaking down for my last 15:

Total Hours Spent: 20.95 hours

Total Bugs Reported: 26

Triaged & Resolved : 4
Duplicate Bugs: 6
Paid: 4
Informative: 13

Several bugs have been discovered across a diverse range of platforms and websites, encompassing a wide array of vulnerabilities. These include impersonation vulnerabilities in various forms. Additionally, CSRF attacks and information exposure vulnerabilities have been identified. Other bug types that were found include default admin credential misuse, enumeration vulnerabilities, XSS vulnerabilities, and instances where users were able to pass courses without completing them. These bug discoveries have played a crucial role in improving security measures and reinforcing the importance of bug bounty programs. Like I have said previously, the rewards for finding and reporting these bugs were significantly higher than what I could have earned from any job at my current age.

Here are some tips to aid in finding bugs:

1. Utilize Shodan: Shodan is a search engine for Internet-connected devices. By using Shodan, you can identify hidden services and potential entry points that may contain vulnerabilities.
2. Explore Non-Public Workflows: Pay attention to workflows or processes that are not publicly advertised. These hidden areas may have overlooked security flaws that can be exploited. Try to navigate through different steps and inputs to identify any potential vulnerabilities.
3. Analyze API Requests: Examine API requests thoroughly. Check the parameters, IDs, and email inputs for potential vulnerabilities. Test different payloads and inputs to ensure the system handles them securely and does not expose any sensitive information.
4. Practice Comprehensive Testing: Leave no stone unturned and test every possible entry point or interaction within the system. This includes form inputs, file uploads, user authentication, and any other user-driven actions. The goal is to identify potential vulnerabilities across the entire application or platform.
5. Employ a Methodical Approach: Systematically go through different components and features, keeping a detailed record of your findings. This helps in identifying patterns, common vulnerabilities, and potential attack vectors.

Summary

Over the course of my 30-day bug hunting journey, I have gained valuable experience and learned a great deal. Throughout this period, I dedicated myself to improving my skills and exploring various platforms and websites for vulnerabilities. It was an enlightening experience, and I am pleased to note that I have seen progress in terms of my accuracy in identifying bugs. However, it’s important to acknowledge that I am still young and have much to learn. I recognize that mistakes are an inherent part of the learning process, and I am committed to continually enhancing my knowledge and refining my bug hunting techniques.

Happy Hunting!!!

— atomiczsec : )

Now lets get started with my first 15 days of the #30daysofbugbounty challenge. I got the idea from:

Here are the stats that I will be breaking down for my first 15:

Total Hours Spent: 22.84 hours

Total Bugs Found: 15

Triaged : 4
Paid: 2 (Still waiting for other bounties)

Informative: 9

Duplicate Bugs: 2

Several bug reports were marked as informative based on specific program specifications. The reports include issues such as broken link hijacking with a Facebook account, low-level user access to admin-only features, information disclosure vulnerability due to improper access control, leakage of name and email of organization users in, access to internal documents, low-level user access to admin-only information, confidential information exposed in a PDF, and access to confidential information in another PDF. The severity levels vary from high to medium and low, while some reports did not specify any severity.

With just those 2 bounties paid, I made more hourly than I do at any job I can get at my age.

There aren’t much technical details about the bugs I have found but I can describe some methodologies to look for these types of bugs:

Broken Link Hijacking:

1. Identify the target: Choose a website or web application that includes links to unclaimed social media accounts. These are typically links pointing to social media profiles that haven’t been claimed or associated with any specific user or organization.
2. Explore unclaimed social media profiles: Visit the unclaimed social media profiles mentioned on the target website. Check if these profiles are associated with any vulnerabilities or misconfiguration that could be exploited.
3. Analyze the profile URLs: Examine the URLs of the unclaimed social media profiles. Look for patterns or parameters that indicate the profile’s uniqueness or identify a specific user or organization.
4. Attempt account claiming: Try to claim the unclaimed social media profiles by following the account recovery or verification processes provided by the respective social media platforms. This may involve providing ownership proof or completing any required steps to prove control over the profile.
5. Monitor for successful claiming: If you successfully claim an unclaimed social media profile, document the steps taken and any relevant information regarding the vulnerability.
6. Document and report findings: Compile a report detailing the broken link hijacking vulnerability, including the affected URLs, the process followed to claim the unclaimed profiles, and the potential impact of this vulnerability. Submit the report to the website or web application owner, following responsible disclosure guidelines.

Internal Documents:

1. Understand the target: Identify the website or web application where you suspect information disclosure vulnerabilities may exist. These vulnerabilities typically involve sensitive internal documents being accessible to unauthorized users.

2. Define site-specific dorks: Craft specific search queries, known as dorks, tailored to the target website or web application. These dorks will help you narrow down the search results to pages or documents that are potentially sensitive or internal in nature.

3. Utilize Google Dorking: Use search engines like Google and leverage advanced operators to perform site-specific searches. Combine relevant keywords, file types, and other search operators with the site operator to restrict results to the target website.

4. Analyze search results: Examine the search results obtained from the site-specific dorks. Look for URLs that point to internal document repositories or directories. Pay attention to file extensions like .doc, .pdf, .xls, .ppt, or any other formats that indicate potentially sensitive documents.

5. Access and review the documents: Access the URLs of the discovered documents and review their contents. Look for sensitive information such as confidential reports, financial data, employee records, customer information, or any other information that should not be publicly accessible.

6. Document and report findings: Capture screenshots or record any relevant details about the identified information disclosure vulnerabilities. Compile a report that includes the URLs of the exposed documents, the nature of the vulnerability, and any other pertinent information.

These methodologies have helped me find a good amount of bugs that are typically low but will still pay out : )

In later blogs, I will be going into detail about some of more specific parts of the bugs!

Thanks for reading ❤

Hello all! Glad to see you back : ) Today I will be writing about my first paid bug, it has a funny story line so read along!

Here is the art for today’s story by rez0 : )

So lets start with how I found this IDOR

1. Setup: I was in English class on my laptop which is not my main hacking device. I was peeking around on burp suite, waiting for class to start and decided to look at this specific company.
2. Recon: I first started with the scope of *.redacted.com, I did not know a lot about subdomain recon and what not which doesn't matter in this case. Also, In general most of the bugs I have found on platforms has been on the main application so don't forget to check that : ) I started browsing through every endpoint on the site, but there wasn't a lot of functionality I was seeing. Once I have browsed every possible link on the site I moved on to the second step.
3. Analyze: Once I had all of those endpoints, I started looking through my burp suite site map which looked something like this:

After looking through a couple of these folders I saw a weird lonely endpoint. The endpoints name was “/opt-out/”. I went to check the request in burp but nothing rendered so I visited the URL in my browser. I then came with a page that looked like an older version of the website that let me enter an email to “Opt-Out” of their mailing lists and what not. This is normal functionality, but I wanted to see what happens when I submit an email. At this point my teacher said “we have a quiz today guys!” but I knew I found something interesting, so I decided to fail my quiz on purpose and fill in random answers so I could keep hacking.

4. Exploit: Once submitted, I got redirected to a new subdomain which looked extremely old, this peaked my interest for multiple reasons:

The new subdomain was something like: http://link.XXX-XXX.redacted.com/manage/optout/. When I entered in an email I got this page asking to “Opt Back In” or “Do Not Email”. I then looked at the URL and saw ?profile_id=54613e813b35d0f1328c4533 ….. OK, we are getting somewhere ;) Now I go to change the id by 1 digit to ?profile_id=54613e813b35d0f1328c4534 and BOOM! A new email pops up. Perfect, I can now Opt-Out any user on this platform which includes password reset requests. I can also enumerate emails on this huge platform.

5. Report: My report included all of the details above and at the time, I wasn't the best at writing reports but it did the job. I included the steps to get to this endpoint, 2 screenshots of different emails, and an entire video of each step.

Here is a timeline for reference:

• Reported: 2021–10–28
• Internal Discussion: 2021–11–02 20:24
• Triaged & Bounty: 2021–12–03 13:30
• Resolved: 2022–02–09

6. Conclusion: I made $1,000 in class but consequently failed my quiz. In my opinion, it was worth it! Stay in school but maybe…. hack in school :)