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.

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.

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

I started Bug Bounty with a friend, and we spent every evening bug hunting together, but we couldn’t come up with much because we didn’t have a good methodology.

Then I was lucky enough to meet Serizao and 

 as well as other bug hunters from the YesWeHack platform, with whom I started to collaborate, and since then we’ve continued talking about Bug Bounty and doing more of it.

ON WHAT THEY LIKE MOST ABOUT YESWEHACK…

 What I like most about YesWeHack is how close it is to the community. It doesn't matter what you want to talk about: as long as it has something to do with Bug Bounty, you'll find someone on the other side who will understand and even give you ideas.

In particular, it’s not unusual for me to talk to [hacker and YesWeHack R&D engineer] 

 about certain bugs where I sometimes get stuck, in order to progress and achieve a successful exploitation. Sharing is caring!

I like hunting on YesWeHack because the platform is pretty cool, pretty simple and I'm a very simple person – so I like when the options are straightforward and there aren't 50 sub-menus!

ON THE THREE WORDS THAT BEST DESCRIBE THEM AS HACKERS…

 Resilient, passionate and, once again, passionate – because you have to be resilient.

I'd define myself as patient and persistent because I like to stay on the same targets for a long, long time, which allows me to find bugs that some people won't find because they haven't spent as much time on the target.

And lastly, passionate, because without passion it would be impossible to stay on these targets for so long.

I like everything that involves recon, so the tools I use include 

 of course. But there are other tools that I’ve created that correspond to my needs.

Mainly, I use Burp Suite because it allows me to inspect requests, especially Burp Suite with the 

 plugin, which allows me to quickly see differences between requests and therefore between the privilege levels used for the test accounts I create.

 to try and quickly see the technologies associated with a target I’m attacking. And if I need to do a bit of recon because we have quite a wide scope, I use the wonderful tools that William [Le Berre] and Jomar have developed, like ‘EyesInTheSky’, 

I start by reading the description very scrupulously, because I know that many people sometimes go over it quickly – despite the fact you can learn a lot, especially if there’s a link to the application documentation.

Then, as I’m very focused on vulnerabilities relating to access control, I try to understand the application as much as possible, so that I can spot any behaviour that isn’t normal and could lead to a security problem.

. I search in the JavaScript and in the JavaScript files, looking for new parameters, new endpoints… something to build on what I initially saw of interest in the application – like other parts of the application or platform that I didn't see at first glance.

ON THE VULNERABILITIES THEY ARE MOST PROUD OF…

 With a certain bank [application] I discovered that it was possible to make negative transfers – which meant that instead of taking money from my account and paying it to a third party, it took it from the third party and put it in my account. So the reaction of the internal team was funny!

It’s a fairly simple vulnerability: a blind XSS present in an account deletion feature.

To delete your account, you were asked why you wanted to delete it, so in that field I injected a payload that gave me access to the administrator section, which normally isn’t accessible to a normal user of the site. This gave me access to the underlying functionality of this section, as well as any personal data it could contain.

THEIR ADVICE TO WOULD-BE AND NEWBIE HUNTERS…

 Above all to be very patient, to get to know as much as possible about the applications you're going to target, and to try and understand how the platform has designed its functions.

Based on my own experience, I’d say you need to be surrounded by people who want to teach you, which makes it easy to share ideas and go a bit further than you might have otherwise thought possible.

And secondly, you need to find a program with a huge number of features, so that you can stay on it as long as possible and get to know the application well. This way you can spot potential features that will lead to the discovery of vulnerabilities or behaviour that shouldn't be there – and enable you to dig even deeper.

Interested in emulating Chackal and Serizao? 

The YesWeHack Blog

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

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

Dojo challenge #31 winners!

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

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

‘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

Dojo challenge #30 winners!

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

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

How to write an effective Bug Bounty report

‘Be curious, be persistent’: Icare on thriving as a Bug Bounty hunter

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

DON'T WAIT FOR THE THREATS TO STRIKE

Products

Researchers

Resources

Company

Follow us