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.

Thank you to all participating hunters and kudos in particular to the top three:

Running non-stop for more than 24 hours, a Live Bug Bounty is very much a marathon, not a sprint. And the bugs don’t arrive with metronomic regularity.

Indeed, the first significant findings in Lille did not come quickly, since the scopes had already been successfully hardened with private YesWeHack programs. ‘Low-hanging fruit’ was in short supply.

Nevertheless, our hunters relish a challenge, and were energised by the variety of applications and technologies to explore. They kept plugging away and the vulnerabilities duly started to arrive.

The dazzling denouement again shows the primacy of patience and persistence to successful hacking (as 

 have pointed out). The most valuable findings were submitted by hunters who, sleeping aside, hacked throughout the 30-hour event with few breaks.

Credit must also go to the CDC security team for their swift bug triage and assessment and setting of fair rewards.

The intrinsic benefits of the in-person format were also apparent. Most notably: the unusual coexistence of competition and collaboration drove hunters to greater heights, while senior managers from CDC were given demos of the vulnerabilities and their implications.

As usual, the event culminated in the announcement of prizes and the final leaderboard, and more fruitful interactions between hunters and the security team.

Providing a platform for knowledge-sharing and awareness-raising, these events clearly offer security benefits beyond the vulnerabilities discovered during the competition itself.

“This year again, the event was intense and full of twists and turns. After a rather slow start in terms of discoveries in the first few hours, it was finally after a long night of hunting that the first interesting vulnerabilities were found by the BZHunt team.

“A big thank you once again to YesWeHack for organising this and allowing us to be there for the past four years. It's always great for us to interact with other hunters and introduce Bug Bounty to younger ones. And also, a big shoutout to Caisse des Dépôts for the quality of triaging but also for the transparency they showed in terms of communication regarding the trust they placed in the ethical hacking community.”

Founded in 1816, Groupe Caisse des Dépôts makes investments with long-term benefits for reducing social and regional inequality, protecting the environment and the economic development of France. Among other things, it manages the pensions of one fifth of French citizens, and invests in social housing, renewable energy and sustainable transport.

“We've been working with YesWeHack for several years now. Taking part in this live event at Forum Incyber 2024 was an opportunity to meet the hunters who work all year round on our programs, which allow us to interact in real time. 

“We were able to discuss the bugs they had reported, their understanding of our applications. An exceptional experience to be repeated, thanks again to the hunters and to YesWeHack!”

Aside from overseeing the Live Bug Bounty, a YesWeHack team was also on hand to demo and discuss our vulnerability management solutions – Bug Bounty, Vulnerability Disclosure Policy, Pentest Management and Attack Surface Management products – with FIC visitors. We were also delighted to announce an integration between 

Sekost’s scan engine and our Attack Surface Management product

If you want to know how a Live Bug Bounty or regular Bug Bounty Program can harden your digital assets, strengthen your security posture and provide assurance to customers and investors, contact us to book a demo.

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

Server-side template injection (SSTI) vulnerability

and capture the flag that appears in the environment variables of the vulnerable application.

We are delighted to announce the winners of Dojo Challenge #31 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!

, Server Side Template Injection, type vulnerability. Vulnerabilities of this type are critical, because very often through an SSTI, 

 (remote code execution) is easily carried out, even remote access via 

These vulnerabilities are generally due to 

, but also require special code logic to function.

In our DOJO #31 case, user input is used for a first rendering to display a review via code:

” method will produce a first rendering of the template and this will be done for each element present in the “

And so even if in the getPage() function we have already done a first rendering, before displaying the HTML rendering we still restart another “render” to generate the final HTML before its display. It is this last call to the “render” method that 

. Indeed if we manage to add for example ${ 1 * 42 }, yes we will go a little out of 7 * 7, for the value of our review text, during the second pass in the render method, the template engine will see that there are still variables/commands to execute and will therefore process them.

The developer to add the following rule in his code to prevent command/code injection into the application:

This rule aims to prohibit all user inputs that contain unicode codes such as 

. Note that the search is not case sensitive, nor limited to the fact that these prohibited characters are present only at the beginning of the string. At first glance, 

At first glance only, this is what we will see in operation.

We spotted a double call to render which confirms that we will be able to do an 

, remote shell access is not relevant in this case.

Important information is communicated at the beginning of the code, in fact, it is noted in a comment that the template engine will respond to the following constraints to produce these renderings:

In particular, we have confirmation that the variables which will be interpreted will be of the form ${ myVariable }. Which brings us back to our developer regular expression which aims to prohibit the following elements in our user inputs: \u or \x or \0, but also the $ sign.

The $ is understandable, because it would be enough to make a stupid ${ 1*42 } to demonstrate that an 

 is present and carry out our attack. The fact of “blocking” the entry of unicode code in strings such as \u0024 (for the dollar sign) is explained, since before adding the review coming from our user input the developer comes to decode the string unicode before sending it to add a review, this is done here in the code:

And so we would just have to add \u0024{ 1*42 } to bypass the filter on the $ sign:

So we need to find a way to interpret a string to have a 

 in our string. In the first hint we are sent to the page 

https://docs.python.org/3/howto/unicode.html

By reading the documentation, we have a super interesting element which is the following:

In the screenshot above, we have three ways of producing characters, the last two will be filtered by the developer's code because they contain \u and \U. On the other hand, the first example 

 should, according to the documentation, display a lowercase E.

It works ! Great, so we can act a little on the code. What we want is not a letter, but to be able 

 which during the second pass in the render will be our variable interpreter.

To save time i found the list of Unicodes with the unicode code but also their character name (the list is available here: 

https://www.unicode.org/Public/9.0.0/ucd/UnicodeData.txt

 )! We saw it above, the unicode code that interests us is 0024. A search in the document gives us this:

The result is indeed a $ as expected! It remains to be seen if the SSTI as suspected is indeed possible for this we will perform a rendering calculation via the input \N{DOLLAR SIGN}{ 1 * 42 } which gives in effect this:

So there, we have acquired the certainty of being able to master the code in the template engine.

We will therefore list the functions / methods that we could use via the following entry:

Via this command, we obtain the list of methods and classes that we will be able to use. I deliberately truncated the feedback to focus on something that we systematically look for in SSTI attacks: the import method:

Note that the method is not directly accessible, but via the builtins class which groups together available methods. Moreover, the simple fact of having access to builtins allows us to access all the following functions (link to the builtins documentation: 

https://docs.python.org/3/library/functions.html#built

 method which will take as a parameter the name of the module that we want to load we will be able to load a module missing in the original code which will be very useful to us to finalize our RCE it is the python 

 , which will allow us to communicate with the host directly and launch commands with the rights of the user who launched the script. The goal of the exercise is to successfully launch the command: 

 which will ask Linux to display all the environment variables accessible to our user.

The code above must import the os module, then via popen launch a command on the os, the command in question is '

' and we finally call the read() method to retrieve the output of the command is the display.

But this doesn't happen at all as expected:

The important part in the error message is “

Before trying to better understand the error, it seems essential to me to be certain that the builtins function call is possible. We therefore test the payload:

So there is something that is causing concern in the previous payload. In the developer's filtering nothing seems to pose a problem. On the other hand, there is one element that goes almost unnoticed: it is the list management of reviews. And therefore at the first rendering the presence of characters such as ' are translated into &27 and are obviously the cause of the error.

To do this, simply test the following payload:

It works, we just add the method call with our 

To confirm, simply run the payload: \N{DOLLAR SIGN}{ ' } to get the same error.

To overcome this, the simplest thing quickly becomes to call the builtins method: 

, this method does not take a character string as a parameter, but integers and in return outputs a character string with the character corresponding to the code integer passed as parameters.

To know the code that interests us, two solutions are an ASCII table or a piece of Python code for example: print( ord('o')) which will display 

 to obtain the lowercase letter o is 111.

We just need to test concatenating an o and an s to see if we load the 

” will not pose any problem, because with a quick search on the Internet we will find the following information and confirms that the “frozen” state will not pose a problem:

We still have to finish our payload with the call to popen and the ‘

The final payload is therefore as follows:

Which will be interpreted by the Jinja template engine as follows:

And therefore give us as output in the HTML of the page the list of environment variables available for access to our user executing the script, and therefore give us the flag which is: 


Exploitation of the vulnerability can lead to unauthorized access to sensitive data stored on the server, potentially compromising user information, including personally identifiable information (PII) and other confidential resources.


Attackers could manipulate or tamper with sensitive data stored on the server by executing arbitrary commands, leading to unauthorized modifications and compromising data integrity.


A successful attack could result in service disruptions or downtime, preventing legitimate users from accessing the application or its services, thereby affecting availability.

Dojo challenge #31 winners!

Covid-19 lockdowns gave people unprecedented amounts of spare time to reconsider their careers and try out new hobbies.

Among those to pursue their dreams was 19-year-old ethical hacker 

, who discovered the joys of breaking into applications for legitimate reasons while still at school.

In our latest bug hunter Q&A, the US-based Israeli – alias ‘RL’ – also reflects on how long it takes to learn Bug Bounty and why going straight into Bug Bounty might not be the wisest first step.

RL ON HOW COVID LOCKDOWN SPARKED HIS INTEREST IN HACKING…

I was 15, it was quarantine and we had no school. I honestly had nothing to do, so I kind of picked up hacking for some reason.

I played a little bit of Hack The Box and then a few months later I moved on to Bug Bounty. I found my first bug, which was a reflected XSS. After that was triaged, I picked it back up again and started hacking even more – and that’s pretty much it.

My browser! Burp Suite is the one that I use 24/7. [It also depends] on what program I’m hunting on and what I’m currently doing.

ON THE UNDERAPPRECIATED VALUE OF DOCUMENTATION…

Documentation is highly underrated in my opinion.

If you’re working on WAF bypasses, which I do a lot, [it gives you] a strong understanding of whatever you’re hacking. For me, it would be JavaScript usually or little browser quirks. [Documentation is] a goldmine of information in my opinion.

When I approach a target I don’t have much of a methodology, but I try to see what’s going on in the website, how it works, all of the different technologies, all of the weird stuff that happens in it – specific things like parser confusion, things that I really like looking for.

And when I find a lot of these weird little pieces of the puzzle, I kind of put it together and eventually create a really cool bug. And that is, I think, the most fun part about it.

Sometimes I also have the documentation by my side and just scroll through the documentation if I’m trying to find a WAF bypass or something.

So: a lot of documentation-reading, a lot of trial and error and a lot of putting pieces of the puzzle together.

ON HIS MOST IMPRESSIVE BUG FIND SO FAR…

My most interesting bug was not necessarily my most critical one, but was a cache poisoning vulnerability in Glassdoor. It was pretty interesting because it abused the URL parser confusion between the front-end server and the back-end server.

So I was actually able to use an uncacheable header XSS and trick the CDN into caching it by abusing a caching rule and the path traversal, and pretty much get a stored XSS through there.

ON THE THREE WORDS THAT BEST DESCRIBE HIM AS A HACKER…

I think I’m creative – I always like finding new ways to abuse vulnerabilities or find them; lazy – I don’t have much of a set methodology, but in some ways it actually helps me; and motivated.

HIS ADVICE FOR HUNTERS STARTING OUT IN THEIR ETHICAL HACKING CAREER…

The biggest mistake that I think I see people make – well, there are a few – but the biggest one is expecting results immediately and not staying consistent. It took me a year to find my first bug, maybe two years to get my first paid bug, so it takes time.

Meanwhile, what you want to do is, instead of getting frustrated with Bug Bounty, don’t start out with Bug Bounty. You can, but it’s hard.

What you do instead is play CTFs, do hacking labs, stuff like that, and, honestly, just have fun with it. You won’t be making money – you likely won’t be making money for quite a while – so just have fun, learn, challenge yourself, stay consistent.

Stay consistent – consistency is very important. Make sure you actually have fun and enjoy what you’re doing. If you don’t enjoy what you’re doing – and I think that goes with anything – you probably won’t be very good at it.

So you really want to enjoy it. The more you enjoy it, the more you’ll want to do it; the more you want to do it, the more consistent you will be. So the more you do it, the better you’ll get. I think that’s my biggest advice. Also, [do] CTFs!

Learn more about hunting through YesWeHack

, or learn about the latest hacking tools and techniques 

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

Bug Bounty is a “good addition” to Thüringer Aufbaubank’s fulfilment of its compliance obligations around pentesting, according to the development bank’s head of software engineering.

In this interview with YesWeHack, Jürgen Krug reflects on the benefits of crowdsourced security testing – not least for software development practices – and his tips for running an effective Bug Bounty Program.

 (TAB) is a publicly-owned development bank that provides loans, grants and guarantees to projects and organisations in the central German state of Thuringia. Among other things, the bank provides financing on favourable terms to infrastructure projects, environmental protection initiatives and proposals that prioritise sustainable development.

Why did Thüringer Aufbaubank decide to launch a Bug Bounty Program?

Only by ensuring the integrity, confidentiality and availability of the data we process can we maintain the necessary trust of our customers, which is the basis of the business we carry out. 

The foundation for this is a systematic consideration of threat scenarios and the measures derived from them. This approach guarantees that the most important aspects of security are considered, but it also means that we are moving on pre-thought-out paths.

, we want to complement this necessary approach with a pragmatic approach that also considers new, unexpected aspects of cybersecurity. 

With the many bug hunters that YesWeHack connects us to, we have access to a large amount of know-how in the security space that all of our products can benefit from.

Why did you choose YesWeHack over rival platforms?

Our choice fell on YesWeHack since the European data protection requirements 

 without a doubt, as well as the platform having sufficient popularity to be able to activate enough hunters, and finally due to the adequate pricing, as we are only a small company.

What are the most significant benefits of Bug Bounty so far?

 We received information on specific attack scenarios that we were able to prevent.

The hackers’ approach also showed us topics and approaches that we continue to pursue ourselves and that we take into account in the development process.

How has the program evolved and expanded so far?

We started by inviting a limited selection of hackers, so we could gain experience of using a Bug Bounty platform before increasing the flow of bugs to remediate. After the number of reports plateaued, we decided to 

What are your plans or hopes for how your Bug Bounty Program will grow or become more optimised in the coming years?

 First, we are concentrating on business applications that are accessible on the internet.

An extension to other services offered by the bank is conceivable. Testing from an internal perspective, with extended authorisations on separate test systems, is a topic we want to address in the future.

Have you faced any challenges adapting your program to the demands or constraints of your security maturity and internal skills and resources?

The volume of reports was easily processed by our internal teams. Of course, we also benefited from the sophisticated scoping of reportable vulnerabilities, as well as the triage services provided by YesWeHack.

All reports that are ultimately relevant to us flow into a general process for known security vulnerabilities in the bank, which can be centrally controlled and monitored regardless of the source of the information.

Are there any particular challenges or opportunities that Bug Bounty presents for the banking/financial services sectors, given their strict compliance and security requirements?

The requirements of the supervisory authorities for banks already include the performance of penetration tests. In this respect, Bug Bounty is a good addition, since it has the same objective as pentests, but utilises a different approach.

What best practices do you follow that other organisations could benefit from by emulating?

We try to classify a report as quickly as possible and provide feedback to the hacker quickly.

And if a piece of information is of value to us, even though the report itself has no direct impact, we sometimes give a voluntary bonus to show our appreciation to the bug hunters.

Thüringer Aufbaubank recently launched a public Bug Bounty Program on the YesWeHack platform with rewards ranging up to €5,000 for critical vulnerabilities. 

 to find out about the scopes, rewards and rules of engagement.

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

The archetypal hacker is a solo freelancer who sits alone at their laptop trying to induce software into misbehaving – but this does not tell the full story.

Because some seriously impressive vulnerabilities have emerged from cooperation between ethical hackers (not least at 

 that are as much about collaboration as competition).

YesWeHack spoke to a pair of hunters about the merits of pooling hacking expertise with trusted peers, as well as the importance of perseverance in a process that is intrinsically about trial and error.

’ – aka Esdras Dago and William Le Berre of French cybersecurity firm BZHunt – also reflect on their favourite vulnerability finds so far and offer some invaluable tips to aspiring and inexperienced hunters.

Their advice carries no little weight given their presence on the 

: Chackal currently in 12th position, Serizao in 21st (note: their positions were different when the interview was conducted).

SERIZAO AND CHACKAL ON HOW THEY GOT STARTED IN BUG BOUNTY…

 thanks to a co-founder of YesWeHack, who came to give courses at CentraleSupélec [an elite engineering school in France] about finding vulnerabilities in applications. All the reports were made on YesWeHack. After meeting him, I decided bug hunting was something I liked and tried to dig into.

The YesWeHack Blog

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

‘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

Dojo challenge #31 winners!

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

‘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

‘I stay on targets for a long, long time’: Chackal and Serizao on passion, persistence and partnerships in Bug Bounty

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

Dojo challenge #30 winners!

‘Adapt payloads to your targets’: Brumens’ Bug Bounty tips for newbies

How to write an effective Bug Bounty report

Dojo challenge #30 winners!

DON'T WAIT FOR THE THREATS TO STRIKE

Products

Researchers

Resources

Company

Follow us