Dozens of vulnerabilities discovered and promptly remediated is a reliable measure of a Live Bug Bounty’s success.

However, the immediate hardening of applications used by certain European supermarket and DIY chains was apparently not the only benefit of a 

 that took place at leHACK, in Paris in 2023.

The then Digital Lab technical lead at Les Mousquetaires said findings from the live hacking event – which also featured scopes from the French Red Cross – would help the French distributor and symbol group “anticipate corner cases” in software development and implement “security by design”.

And in an interview with YesWeHack, Fabrice Bru, CISO at STIME, the IT department of Les Mousquetaires Group, observed that live hacking events facilitated fruitful collaboration with ethical hackers and offer stakeholders reassurance about their security posture.

Read or watch the interview below to also hear Fabrice Bru’s reflections on the Bug Bounty journey so far and the benefits of partnering with YesWeHack, for both continuous security testing and intensive live hacking events.

Les Mousquetaires (‘The Musketeers’ in English) operates 4,100 retail stores in France, Belgium, Portugal and Poland, as well as logistics hubs and support services. Retailers in its stable include Intermarché, Netto, Bricomarché, Bricorama, Brico Cash, Roady and Rapid Pare-Brise.

FABRICE BRU ON THE BUG BOUNTY JOURNEY SO FAR…

We started the Bug Bounty initiative in November 2022, initially on the intermarche.com website, which is an e-commerce site, with around 10 researchers to start with, and gradually we increased the number of hunters to 80.

The whole point for us is, beyond having an occasional overview of the security state of our site, to have a constant monitoring of all the vulnerabilities and potential cases of fraud that we could have on the e-commerce site, since we carry out daily updates on this site.

For this Live Bug Bounty, we obviously included the Intermarché e-commerce site in the scope. We also wanted to add the e-commerce sites of our DIY stores: Bricomarché, Bricorama and Brico Cash. We are also in the process of opening up a new application to our suppliers and shops, which will become an essential part of their day-to-day operations at points of sale, and we also wanted to assess its security through this event.

ON THE LIVE BUG BOUNTY SO FAR [THE INTERVIEW WAS CONDUCTED PARTWAY THROUGH THE EVENT]…

So far, the Live Bug Bounty is going very well for us. Four people from the STIME teams are here – three from the cyber teams and one from the development teams – to try and assess as fully as possible the business impact of the four vulnerabilities identified by the hunters [at the time of the interview].

I have to say that, for the time being, we're actually achieving our objectives, since we’ve started to identify some very interesting cases.

ON THE VALUE OF PARTNERING WITH YESWEHACK…

The collaboration with YesWeHack obviously began before we started our Bug Bounty Program.

We worked very closely with the [YesWeHack] teams. We were able to review the solution and, above all, when we started, what we really enjoyed was the quality of the hunters, their relationship with the YesWeHack teams and the quality of the triage, which saved us an immense amount of time and enabled us to focus on what is essential.

And when you start this kind of initiative, you never really know how much you're going to spend in rewards, and the whole point of being supported by YesWeHack has been to gradually learn how much to value a vulnerability reported by the hunters.

Today's collaborations are very fluid and close-knit. During the event today, we have managed to meet hunters who regularly hunt on our sites, so it's a great way of networking and getting close to them. It’s amazing!

ON THE VALUE OF HARDENING DIGITAL ASSETS THROUGH LIVE HACKING EVENTS…

For STIME, taking part in this event is also about demonstrating the dynamism of our cyber teams, using all the techniques and innovations that exist in our profession today to assess the level of maturity and security of our sites, and reassure our businesses about our ability to protect the company’s activities.

Want to learn more about the YesWeHack Bug Bounty & Vulnerability Management Platform? Click the button below to reach out to us.

‘Our businesses are reassured that we’re protecting their activities’: Les Mousquetaires CISO on leveraging live hacking events

In terms of useful results, Bug Bounty Programs are typically 90% cheaper than traditional pentesting, according to one speaker at YesWeHack’s ‘Client Success Stories’ event in Stockholm.

The presenter, an application security engineer from a Scandinavian financial services company, also hailed the fact that financial input tracks actionable output – specifically the number and severity of valid reports. “There’s no cheaper way of getting security testing,” he said. “It’s a no-brainer.”

Bug Bounty had been an “incredibly useful asset” overall, he continued, and would only become more useful across the economy in the age of digital transformation since hunters focus on internet-exposed assets.

Bug Bounty deepens cyber-defences by adding a valuable, complementary layer to offensive security operations.

The speaker noted how Bug Bounty mostly supplements rather than duplicates the results of penetration tests, because the former specialises in internet-facing assets, while the latter can focus more on internal networks.

And, drawing on tens of thousands of hunters, Bug Bounty clients can more easily find testing expertise specific to their targets than is typically the case through conventional pentests.

The upshot for the YesWeHack customer in question was the security team being “flabbergasted” at some of the hunters’ discoveries. “Never in a million years” would they have found one particular misconfiguration issue internally, recalled the AppSec engineer delivering the presentation.

Sometimes hunters did find bugs that had already been discovered internally, but which hadn’t yet been fixed. Yet once reported through the Bug Bounty pipeline, they were promptly remediated, the speaker noted.

The Bug Bounty success story began (and it’s 

) with a pair of good-faith bug reports – one submitted externally, another internally. Recognising the need for a secure, structured reporting mechanism, they duly launched a Vulnerability Disclosure Policy (VDP).

Once the VDP was in place, the move to paying researchers was “not a big jump”, insisted the AppSec engineer – albeit this was not a universal perception. “Won’t this just encourage people to hack us?” was one misgiving encountered at boardroom level.

The speaker simply pointed out that traffic logs showed malicious attacks were happening on a regular basis anyway. At least ethical hackers would mitigate the risk of attacks succeeding – and halt their activities in the unlikely event of services being unwittingly disrupted.

Once boardroom buy-in was secured, YesWeHack’s 

strict compliance with EU data security rules

But it was endorsements from peers that sealed the deal for a 

 type of security testing and what the speaker conceded is a “very conservative” financial services industry.

“Wow, we need this,” they said, having seen a Swiss Post presentation about their 

 and meeting another YesWeHack client, Scandinavian telco 

After three months, the pilot was so successful they had “no doubt” about continuing.

Watch our Live Bug Bounty with Swiss Post

The organisation’s conservatism is now the biggest barrier to making the program public, admitted the speaker.

Fortunately, the biggest worry about going public – that the flow of bugs might become an unmanageable flood – is abating as the private program expands, he added. The current program continues to cope well with a gradually growing number of hunters, and the leap to accepting reports from all registered hunters seems ever-smaller and less daunting.

The speaker was currently “fighting” to persuade decision-makers to launch a public Bug Bounty Program, in order to access the full spectrum of hacking skills and publicly demonstrate their commitment to security.

Intriguingly, he believed going public might even aid recruitment in a fiercely competitive market for talented developers, since many are keen to learn more about application security. The Bug Bounty Program findings also inform security training programs and raise the security team’s profile internally, said the engineer.

The speaker echoed advice expressed in many of our 

: start small (with limited scopes and few hunters) to prevent an overload of reports; periodically add scopes, and sometimes increase rewards, to sustain hunter interest; and treat hunters well.

“The way you talk to hunters can be a meaningful factor in whether they come back,” especially if severity is lower than anticipated, said the speaker. Thank them, compliment them and fix their bugs promptly, he advised.

Hunters will also benefit from simpler rules of engagement if you create separate programs for “very different types of systems”. YesWeHack allows customers to create as many programs as they need for no additional cost.

There were some invaluable insights around choosing scopes and providing infrastructure that mitigates risk.

For instance, the speaker’s fellow BBP managers were urged to beware reliance on third parties. Can we count on Microsoft promptly remediating an Office 365 endpoint issue, he asked?

He also pointed out that the UX is a commonly abused attack vector that demands attention. Why not spin up a replica application, separate from production environments, to eliminate risk?

Overall, the workload has been greater “than expected – not an incredible amount, but you have to be active in your program management”.

It’s therefore wise to accept YesWeHack’s assistance, including our recommendations for choosing hunters with relevant skills. The in-house triage service is worth leveraging too, “to filter out chaff, all the noise”, said the speaker. This “first line support” was “incredibly useful” for his employer, especially early on.

YesWeHack’s “handholding” helped them keep the flow of bugs manageable and stay within budget, as has testing assets internally before adding them to the scopes. “Pluck the [easy] weeds in your garden before bringing in a professional weed hunter,” advised the speaker.

YesWeHack has an office in Stockholm dedicated to catering to its clients – 20 and growing – in the Nordic-Baltic region. We also have a dedicated hacker community manager for the region, who caters to the needs of more than 1,500 vetted researchers in the Nordic-Baltic countries.

If you would like to discover another of our case studies, you can check out 

the Bug Bounty success story from risk-management giant DNV

‘No cheaper way of getting security testing’: financial services Bug Bounty success story

Class Pollution (Python's Prototype Pollution) vulnerability

and capture the flag stored in the flag.txt file of the vulnerable application.

We are delighted to announce the winners of Dojo Challenge #32 below.

Want to create your own monthly Dojo challenge? Send us a message on Twitter!

 feeds to be notified of upcoming challenges.

Read on to find out how one of the winners managed to solve the challenge.

We asked you to produce a qualified report explaining the logic allowing exploitation, as set out by the challenge. 

To ensure contestants actually solved the challenge themselves rather than copy-pasting the answer from elsewhere.

To determine contestants' ability to properly describe a vulnerability and its vectors within a professionally redacted report. This gives us invaluable hints on your unique talent as a bug hunter.

We want to thank everyone who participated and reported to the Dojo challenge. Many other high quality reports were submitted alongside those of the three winners. 😉

Below is the best write-up overall. Thanks again for all your submissions and thanks for playing!

 occurs when an attacker manipulates special attributes and methods associated with Python classes to modify their behavior or even their state at runtime. This vulnerability typically affects mutable objects, such as dictionaries, lists, or custom classes. In this case, the discovered vulnerability was found in the 

 function, which on the one hand allows users to modify the server's security settings, but on the other hand allows a remote attacker to execute arbitrary code on the web server by providing malicious input as a new security configuration.

During the security tests, an administration panel was discovered. A phase of exploration took place, so as to understand its functionalities.
The panel corresponds to an endpoint accessible to administrators, allowing them to modify a server's configuration based on an input string converted to JSON format.

To begin, we will review, block by block, the available code excerpt, shedding light on the backend logic:

At the very beginning, after receiving the request containing the new configuration, the server defines 2 variables:

: which contains the name of the configuration file on the server,

 as a parameter. According to the provided indications, calling this script would update the server's configuration from a JSON configuration file.

Thus, we immediately identify what appears to be a variable of interest, 

, mastery of which would allow the execution of arbitrary code on the server, potentially resulting in remote code execution (RCE). However, these 2 variables are hardcoded and seem initially unmodifiable, unless it was possible to modify them through the input configuration file in some way.

The next block of code then defines a class and a function:

 is defined, corresponding to an implementation of a key-value dictionary. This class will likely instantiate objects containing security configurations.

 allows, on the other hand, to merge 2 dictionaries (or security configurations): the 

 configuration overwriting the values of 

In the next block of code, a default security configuration containing a few arguments is defined and instantiated. Then, the file 

, containing the result page, is read by the program.

Now comes the part where our input comes into play

. Subsequently, from what we understand of the code, the user-provided security configuration, which has been URL-encoded, is:

 to retrieve the original input string (because of the initial URL-encoding by the Web Application Firewall), using the 

 function. This method takes as input a string containing JSON and transforms it into a Python dictionary.

⚠️ If this conversion to JSON fails, the program terminates. Therefore, it is essential to ensure that, regardless of the payload used, the conversion works.

Once the user-provided security configuration is transformed into a dictionary, it is merged into the default security configuration with a call to 

merge_config(user_config, security_config)

⚠️ This results in an object of type 

) to convert it into a dictionary in the next code block.

 file is opened for writing, and the values contained in the new security configuration resulting from the merge are inserted into it using the 

json.dump(vars(security_config), config, indent=4)

 method. This method serializes a Python object into a file, effectively replacing the content of the JSON file on the server.

Next, the HTML page to be displayed to the user, containing the values of the server's new security configuration, is prepared, and the server's configuration update is performed by executing the previously defined 

To start, I will perform some tests with simple values to observe the nominal behavior of the server.

Thus, I will first attempt to add keys with arbitrary names to the default configuration, which will work. Then, I will try to replace an already existing value in the default configuration, such as the value associated with the firewall_enabled key, which was initially set to true:

 → Overrides the original value with the boolean 

 → Overrides the original value with the string 

. Thus, no strict type validation seems to have been implemented ;

 → Predictable validation error at attribution when merging with the default security configuration:

I will also note that the values of the configuration file are reset before each request, which does not allow reusing a payload across multiple requests.

After thorough research, I will find the existence of a vulnerability in Python applications called 

, a kind of equivalent to Prototype Pollution in JavaScript.

Thus, this vulnerability would stem from the very use of an object merging method such as the one defined in the body of 

Indeed, in Python, it is possible to access certain special attributes of objects in order to obtain 

 (meaning information unrelated to the business use of the objects).

According to this blog article (https://blog.abdulrah33m.com/prototype-pollution-in-python/), it is hence possible to "pollute" a class by using some of these attributes:

: allows direct access to an object's class,

: in case of inheritance, allows access to the parent class of level 

: allows access to the dictionary of the class method 

, containing its global variables, including all imported modules.

From this point, the attack path initially envisioned becomes feasible: if one could modify the 

 variable directly, then one would be able to execute arbitrary code remotely on the server.

To do this, I will go through the only class method defined for the 

 class, which also is the destination of the string taken as input and then converted into an object: I named 

Thus, the payload will be crafted as follows:

In the server's response, I will obtain the output of this command:

We now have a working remote code execution on the server.

It will then be left for me to attempt to display the contents of the file 

Sending this payload will allow us to obtain the final result, the flag 

FLAG{J4v4ScRipT??No_Pyth0N_cl4Ss_p0lluTi0n!!}

As shown in the PoC, the vulnerability allows a remote attacker to execute arbitrary commands on the server. Depending on the level of privileges required to be able to send the payload to the vulnerable endpoint, an (authenticated or not) attacker could then use this access to tamper with data, access sensitive information on the server, attempt to proceed with its exfiltration, and even try to elevate his privileges to continue the exploitation.

Remediating the issue mainly depends on business requirements. However, some mitigating steps for class pollution in this specific case are:

 Strict input validation mechanisms should be enforced so as to make sure that only expected and valid input is accepted. The Python library 

 can notably be used to validate JSON data against a given set of expected properties and types.

 The attributes that can be accessed or modified dynamically based on user input should be restricted, by implementing whitelists of allowed attributes in order to prevent access to sensitive or class-wide properties.

 The process should be executed within a sandboxed environment with restricted privileges, using Python's built-in sandboxing mechanisms or a third-party sandboxing solution so as to isolate potentially harmful operations. Although this is not a remediation of the vulnerability itself, it would limit the impact of any further remote code execution.

https://blog.abdulrah33m.com/prototype-pollution-in-python/

https://portswigger.net/daily-swig/prototype-pollution-like-bug-variant-discovered-in-python

Dojo challenge #32 winners!

A new UK cybersecurity law shows that governments are losing patience with the widespread failure to implement basic security measures for connected devices.

In force since 29 April, the Product Security and Telecommunications Infrastructure (PSTI) Act mandates that Internet of Things (IoT) manufacturers must publish contact information for anyone – from users to security researchers – to report security vulnerabilities in their internet-enabled devices. The information should be “accessible, clear and transparent”, 

Manufacturers are also obliged to give reporters of suspected vulnerabilities timescales for acknowledging vulnerability reports and status updates until the issue is remediated or invalidated.

 (PDF) conducted by UK cybersecurity firm Copper Horse for the IoT Security Foundation, 76% of smart device vendors still provided no means for security researchers to contact them.

LAUNCH YOUR VULNERABILITY DISCLOSURE POLICY

”, the PSTI regime also proscribes weak and easily guessable default passwords like ‘admin’ or ‘12345’. Shipping products with easily guessable default passwords enables devastating attacks such as the corralling of hundreds of thousands of devices into the 

, which brought down numerous popular websites in 2016.

A third PSTI security requirement mandates a commitment to a minimum end date for sustaining security updates – again, “in a clear, accessible and transparent manner”. Committing to finding and fixing vulnerabilities and rolling out patches over the long haul gives vendors an edge in winning consumer trust and complying with increasingly stringent regulation around the world.

UK households own an average of nine connected devices, according to the UK government. Amid reports of vulnerabilities that enable cybercriminals to take over devices and covertly view footage from security cameras, connected toys and smart baby monitors, UK Minister for Cyber Viscount Camrose said the new law should give consumers “greater peace of mind”.

Anyone can report a product they suspect is failing to comply with the PSTI legislation to the 

Office for Product Safety and Standards (OPSS)

. Organisations found to have flouted the law can be fined.

Automotive vehicles are exempt from the law since separate legislation is being drafted for online automotive systems.

Copper Horse CEO David Rogers said: “Manufacturers should not be providing anyone with products like webcams that are so weak and insecure that they are trivial to hack into and takeover. This stops now and people [in the UK] can have greater confidence that the internet connected products that they buy have better security measures built-in to protect them.”

VDP: Best practice for secure, coordinated vulnerability disclosure

 (VDP) is the most secure and efficient means of complying with vulnerability reporting requirements, such as those prescribed by the PSTI regulations.

VDPs are advocated by NIST, ENISA and CISA and prescribed through standards ISO 29147 and ISO 30111. A US government-wide VDP platform “facilitated the remediation of 1,119 vulnerabilities out of 1,330 unique, validated submissions” in its 

As a secure channel for coordinated vulnerability disclosure, a VDP shows your customers that you take security seriously and and can fruitfully complement a 

 in line with industry best practices and your specific requirements and integrate it into your website. Other product features:

Unified interface for receiving reports and managing vulnerabilities

Receive only valid, actionable reports thanks to our in-house triage service

Triage team can evaluate bug severity and liaise with security researchers

End-to-end encryption ensures confidential communication

UK PSTI Act: ‘World first’ IoT security rules offer reminder of VDP virtues

In few sectors is cybersecurity as high a priority as it is in healthcare. At stake is huge volumes of highly sensitive personal information and even lives.

It’s therefore a testament to YesWeHack that security-testing of medical software used by 340,000 healthcare personnel and 80 million patients should be entrusted to tens of thousands of our 

In this interview, Cedric Voisin and Paul Marty, respectively CISO and senior product security engineer at 

, reflected on the European healthcare booking platform’s five-year journey in crowdsourced security so far.

Among other topics, the pair discussed Bug Bounty success factors, a trio of special scenarios for claiming maximum bounties, and a ‘panic button’ for hunters embedded within its production instances.

One, to ease access to care for every patient. The second mission is to ease practitioners’ lives in providing them with handy solutions, in order to ensure that they can focus on delivering care to patients.

Cedric on the evolution of Doctolib's Bug Bounty Program…

 five years ago with YesWeHack, first on a very limited scope on the patient side. Then we expanded it to the pro side, in order to stress[-test] the application that we sell to practitioners.

Then we introduced our IT landscape, to finally make the patient program public and raise the bounties associated to those programs.

Paul Marty on increasing the maximum bounty…

Since then, we did two major updates to our program: first, we raised the maximum bounty to €25,000; second, we have updated our Bug Bounty Program.

High rewards require a very detailed program, which aims to cover all the cases. To address this, we continuously improve, based on the feedback from participants and the YesWeHack team.

Paul on a collaborative vulnerability disclosure process…

The Bug Bounty at Doctolib is a collaborative effort. The YesWeHack triage team will first qualify the report, then a security specialist from our team will take ownership of the entire Bug Bounty process. He discusses [the bug] with security researchers as well as the team in charge of the feature [containing the vulnerability].

Cedric on key factors for a successful Bug Bounty Program…

First, I would say that it is really important to start with a very limited scope, well identified, with which you can act very easily in fixing the vulnerabilities that are shared by hunters, and also limit the financial impact of providing rewards to hunters.

Then, as soon as you gain confidence on that program, it’s really easy to expand it to more and more applications. And the final point is to write a very well-defined vulnerability disclosure policy, in order to state clearly to hunters what is expected from them and what is not.

Paul on what has impressed most about the Bug Bounty model…

Efficiency: it’s a very good way to uncover security vulnerabilities. And when you think about it, the high reward is still a good price for a critical bug.

Transparency: it reflects our willingness to deliver a product with the highest standard of security.

Paul on the support provided by YesWeHack…

YesWeHack acts as a partner that helps us to qualify the reports, improve our program and sometimes to define the high rewards we give to security researchers.

Paul on an exciting new avenue for earning maximum bounties…

We have added three special scenarios where participants can earn the maximum bounty.

First, we have the ‘Game Over’ scenario – if a security researcher can access an environment variable. Second, we have the ‘One Shot’ scenario – if the hunter can access a large dataset of patient health information. And third, the ‘Casper’ scenario – if the security researcher can exploit a critical bug without being detected by the security team.

All our production instances have a secret button that any security researcher can push at any time to demonstrate that they successfully hacked Doctolib. You can read more about this panic button in our public program.

Looking for fresh bug-hunting targets? Check out 

 for further details on rules, rewards and scopes.

Want to learn more about the YesWeHack Bug Bounty & Vulnerability Management Platform? Click the button below to schedule a demo with one of our experts.

‘An efficient way to uncover vulnerabilities’: Doctolib's five years in Bug Bounty

A spectacular finale saw participants of a YesWeHack Live Bug Bounty rewarded for 30 straight hours of patient probing with a late flurry of serious vulnerabilities.

It was hard going early on given the already hardened scopes, but the ethical hackers’ persistence ultimately paid off. The most significant bugs were only unearthed as the clock ticked down to the final hour.

The upshot was 22 validated bugs and significantly more secure digital assets for 

 (CDC), a French public financial institution.

The competition, which ran between 10am on 26 March and 4pm the following day, took place at 

, the security event in Lille. Bug hunters competed for points, YesWeHack swag created for the occasion and bug bounties ranging up to €6,000 for the most critical vulnerabilities.

As usual, YesWeHack kept the target under wraps until immediately before the event.

 (aka Brice Augras) and also featuring Chackal, Serizao and Kix29.

BZHunt finished up on 295 points, accrued via 10 reports, with an impact score of 29.5. In second place, 

) notched 165 points via five vulnerabilities, with an impact score of 33. The final podium place was occupied by 

), scoring 150 points, with eight bugs and an 18.75 impact score.

It represented a fourth win in a row for BZHunt at YesWeHack’s annual Live Bug Bounty at FIC.

The YesWeHack Blog

‘Our businesses are reassured that we’re protecting their activities’: Les Mousquetaires CISO on leveraging live hacking events

‘No cheaper way of getting security testing’: financial services Bug Bounty success story

Dojo challenge #32 winners!

‘Our businesses are reassured that we’re protecting their activities’: Les Mousquetaires CISO on leveraging live hacking events

UK PSTI Act: ‘World first’ IoT security rules offer reminder of VDP virtues

‘An efficient way to uncover vulnerabilities’: Doctolib's five years in Bug Bounty

Bug Bounty hunters mount impressive sprint finish to Caisse des Dépôts marathon

UK PSTI Act: ‘World first’ IoT security rules offer reminder of VDP virtues

Dojo challenge #31 winners!

‘Hunters’ biggest mistake? Expecting immediate results’: ‘RL’ on building a Bug Bounty career

‘Large amount of knowhow’: Why Thüringer Aufbaubank harnesses Bug Bounty to bolster customer trust

Dojo challenge #31 winners!

Don't wait for threats to strike

Produits

Chercheurs

Ressources

A propos

Suivez-nous