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? 

Learn more about hunting through YesWeHack

, or learn about the latest hacking tools and techniques 

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

', invited participants to exploit a command injection vulnerability and gain remote code execution on the target system.

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

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!

OS Command Injection is a critical security vulnerability which allows attackers to execute arbitrary commands on the host operating system of an application. This type of vulnerability arises when user-supplied input is improperly validated or sanitized before being passed to system commands for execution. In such scenarios, attackers can manipulate the input to inject malicious operating system commands, which are then executed with the privileges of the application.

In the context of this application, the OS command injection vulnerability is introduced within the 

 class. This function processes user-provided input with inadequate validation and sanitization, leading to the execution of arbitrary commands in the server environment.

The mechanisms employed by the application to mitigate against OS command injection vulnerabilities are insufficient, leading to Remote Code Execution (RCE) in an unauthenticated context, as outlined below.

The PHP code snippet above first URL decodes the input using 

 and splits it into multiple array elements using any whitespace characters as delimiters via 

Next, the application checks if the resulting array contains exactly two elements, which correspond to one command and one argument. If the count is not equal to 2, an error message is generated and the command execution is aborted. However, this approach is not foolproof against command injection, which can occur even if spaces do not separate multiple arguments.

The mechanism behind command substitution will be explored in more detail later. What is important to highlight for now is that the payload uses shell redirection operators 

 to read the contents of the file /tmp/flag.txt. Therefore, it demonstrates how complex commands can be constructed without spaces to bypass simplistic input validation checks.

In addition to the previous input validation, the application performs sanitization against the argument provided by replacing certain dangerous characters with underscores (_): double quotes ("), single quotes ('), backticks (`) and curly braces ({}). However, the set of dangerous characters implemented is not comprehensive by any means and therefore leads to incomplete sanitization.

Using the payload referenced above again as an example, the argument 

 does not rely on any of the aforementioned dangerous characters and instead uses special characters associated with command substitution 

Input sanitization using escapeshellarg()

 is used to perform further sanitization. This function adds single quotes around the argument and escapes any single quotes within the string by adding a backslash before them. However, it is important to note that 

 may not neutralize all potential injection vectors, even when combined with previous validation and sanitization techniques.

The overall security of the application also depends on how the argument is used subsequently. In this case, using the 

 command to handle user-supplied input poses a risk, as 

 can be manipulated to execute arbitrary commands or output data in unintended ways.

Command substitution within echo argument

 in particular introduces an important vulnerability. Despite the 

 function's effort to secure the argument by enclosing it within single quotes, by placing its output within double quotes as in 

 for execution allows for shell command substitution.

 provided by the payload, the final command launched by 

There is a mix of single and double quotes in 

 part is where the shell "command substitution" takes place. This means that whatever command is placed inside 

 gets executed independently, and its output replaces 

 argument didn't contain the final enclosing double quotes, as in the command below, this would prevent command substitution due to the way it is interpreted by the shell.

However, since the shell treats everything within double quotes as an expression to be evaluated, including a string already enclosed within single quotes, this allows for command substitution to occur. In this context, it allows the shell to interpret the payload as a command to read from the file 

This oversight demonstrates a crucial point in secure coding practices: even when arguments are properly escaped, the context in which they are used can introduce vulnerabilities. Thus, ensuring that commands constructed with user-supplied input are handled securely requires careful consideration of both the escaping mechanism and the way in which the input is subsequently processed or executed.

 to the endpoint https://dojo-yeswehack.com/challenge-of-the-month/Dojo-30 results in the disclosure of the /tmp/flag.txt file content: 

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.

As an interim measure, the following patch should be applied to the existing sanitization process in order to increase its robustness.

 command construction should be modified by removing the enclosing double quotes, as below.

Neither of the previous hotfixes should introduce any unintended side-effects.

To effectively mitigate against further OS command injection vectors and enhance the overall security of the application, more robust mechanisms should be implemented. It is always preferable to rely on standardized, built-in PHP functions designed for security and input handling. 

 to sanitize both the command and its argument. 

 ensures that any shell metacharacters in the command itself are escaped, preventing command injection attempts at the command level.

Dojo challenge #30 winners!

Customisation is key when it comes to unearthing code vulnerabilities, according to Bug Bounty hunter ‘Brumens’.

, who is also researcher enablement analyst for YesWeHack, shares his Bug Bounty tips and tricks for beginners, and reflects on his own experiences as a successful ethical hacker.

Among other things, we asked the 23-year-old (22 when the interview took place) to reflect on his defining qualities as a bug hunter, about how he chooses his hunting targets and for his preferred hacking tools.

When I was young, I always mixed with a lot of computers. I did a lot of networking, learning, and when I grew up I liked coding, so I started to build some code. And then I also started to learn how different things worked and I think that’s how I got into hacking.

 on YesWeHack with a little bit of background about programming and IT security. I started hunting on a 

, and I managed to find my first vulnerability there. From that point, I got some private invites and started my journey on YesWeHack and continued to do hunting.

The triage is amazing. When you report something, the triage is done in a really short amount of time, so that’s a huge benefit about the platform.

And also, the way that you’re able to structure your report and communicate with the company, it’s amazing.

I always go for the functional ones that have a lot of functions, and from there I just like to discover and use the website or the programs as a regular user. And from there, I take the interesting points or interesting functions and go deeper and try to hack them.

ON THE MOST CRITICAL VULNERABILITY HE HAS DISCOVERED SO FAR…

The most critical vulnerability that I discovered myself was an unauthorised SSRF, also known as 

, that led to a remote code execution on an administration panel in the backend.

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

I would say creative, persistent and very much patient.

My top three hacking tools that I always use are 

ON THE MOST COMMON MISTAKE MADE BY INEXPERIENCED HUNTERS…

In my opinion, the thing that is very common to new hackers is that they take a lot of tools and they spray them on the target with a default configuration, without any customisation.

I would recommend to new hunters: make your own wordlist, make your own payloads, and understand the technology and adapt it to your target. Not spray and use the same methodology for all your programs, but adapt them to the specific one you are hacking.

MORE ADVICE FOR ANYONE STARTING OUT AS A BUG HUNTER…

Pick a target that you’re comfortable with, that you feel motivated to hunt on – not just a target that everyone is hacking on, but a program that you feel would be fun.

When you have that target, then just discover a function, and do research about how that function works. When you’ve got that information and find a behaviour, just keep digging and, eventually, you’ll probably find a vulnerability.

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

Writing an effective Bug Bounty report is not as easy as it might seem if you haven’t written one before.

Getting it right is crucial for proving the validity and severity of a vulnerability and getting paid promptly and fairly for your discovery.

As with the severity score, well-written bug reports will earn points that propel you up the leaderboard and unlock lucrative new hacking opportunities.

Whether your bug is low, moderate or critical severity, the following best practices for vulnerability disclosure can build trust with security teams and earn invitations to private Bug Bounty programs.

Before you report a vulnerability, you should first evaluate whether it is valid under the rules of the Bug Bounty Program. Do this by answering the following questions:

 As a bug hunter, you must respect the program rules and only hunt on perimeters authorised as within scope.

Does your bug fall within the program’s list of qualifying vulnerabilities? 

A non-qualifying vulnerability risks the report being rejected and closed in RTFS (

Does the bug have any potential security impact?

 As a general rule, validation requires some direct security impact (unless the program policy says otherwise).

The impact of a vulnerability directly influences the severity of your findings and, subsequently, the reward you might receive. Demonstrate impact by:

: Assess what data could be compromised or which functionality could be abused and to what effect. For example, could the vulnerability lead to unauthorised access to sensitive information or lead to financial losses? What is a realistic worse-case scenario?

: Provide a realistic attack scenario that demonstrates how an attacker could exploit the vulnerability. This helps the program’s security team grasp the practical implications of the security flaw.

This SQL injection vulnerability could allow attackers to retrieve the entire user database, including sensitive customer information such as passwords and credit card numbers.

Write a behaviour analysis that explains how you identified the vulnerability by inducing the application or system into behaving abnormally. For instance:

: Understand how the application or system is 

 to function based on documentation, use cases and legitimate user interactions

: Show deviations from expected behaviour that are indicative of a vulnerability, such as unexpected error messages, undocumented features or inconsistent application responses to user inputs.

During the analysis, it was observed that submitting a specially crafted payload in the user login form caused an unusual delay in the application response. This behaviour is indicative of a time-based SQL injection vulnerability, as the application's response time varied significantly with different payloads, suggesting it was executing unauthorised SQL commands.

A report can be divided into the following sections:

 related to the vulnerability. This gives the reader a broad understanding of the vulnerability you discovered.

A description of the process of how you discovered the vulnerability.

The PoC essentially serves as evidence that the vulnerability exists. One of the best ways to do this is to combine a short summary text with a visual reference in the form of an image and/or video.

A demonstration of the steps an attacker could take to exploit the vulnerability. These steps must be easy to follow so that triagers can reproduce your exploit and validate your report as quickly as possible.

You can also include an exploitation script, which is particularly handy for advanced vulnerabilities comprising numerous complex steps.

Clearly describe the impact of your vulnerability and link it to the Proof of Concept.

Provide a technical solution for how the vulnerability might be resolved. This is not obligatory, but providing a potential fix could be a time-saver for the security team and will be much-appreciated.

Add links to resources that provide further context or information that will help the security team understand the vulnerability. For example, it could include URLs for the relevant CWE definition and security advisories for existing vulnerabilities that your bug can be chained with.

.  To create or find your templates, navigate to:

When you're about to submit a report to a program, your custom templates will be accessible from a dropdown menu at the top of the page:

Here you can simply choose a Bug Bounty report template that reflects the vulnerability you are reporting. This auto-fills details adapted to the program and vulnerability you have discovered - saving you time in the process!

. Ensure your report is comprehensible to all readers, regardless of their familiarity with the specific vulnerability type. The technical depth of your report should not obscure its understandability. 

Remember, whoever reads your report may lack an in-depth knowledge of the vulnerability type you're reporting. To bridge this gap:

: Incorporate comprehensive details about the vulnerability, leaving no room for ambiguity.

: Where possible, supplement your explanations with screenshots, diagrams or videos. Visual aids can significantly enhance understanding and are particularly helpful for complex vulnerabilities.

 (see above section): Creating report templates for specific vulnerability types not only streamlines your reporting process for similar future discoveries, but also ensures consistency and completeness across your reports. Remember to anonymise the template by removing any program-specific details.

Vulnerability reports: your path to private Bug Bounty Programs

Poorly written Bug Bounty reports make it harder for security teams to reproduce legitimate vulnerabilities. This can lead to delays to the remediation of serious vulnerabilities or – worse still – their erroneous rejection. 

It’s therefore wise to take report-writing as seriously as hacking itself. This will help to build strong relationships with programs and open doors to exclusive hacking opportunities, such as private programs or Live Bug Bounties.

How to write an effective Bug Bounty report

Bug Bounty hunting need not be a full-time pursuit to make a big impact or earn a decent income.

’, is proof positive of this claim. The French ethical hacker has reached 11th on YesWeHack’s 

 (at the time of writing) despite working in the daytime as a pentester for Thales Group.

In this writeup and video, Amel explains how he discovered YesWeHack and Bug Bounty, revisits a pair of particularly impressive LibreOffice exploits, and offers some bug bounty hunting tips for beginners.

ICARE ON ENCOUNTERING BUG BOUNTY FOR THE FIRST TIME…

At the time, I was working for a small IT services company. They were testing a web application, which I tested myself and found some fairly critical vulnerabilities.

Since the application wasn’t managed by the company in question, I contacted the publisher, who thanked me for my work and then offered to let me test the product through a Bug Bounty platform.

I didn’t know what it was, but it was YesWeHack. So I signed up to the platform and that’s where it all started.

ON WHAT HAS IMPRESSED HIM MOST ABOUT YESWEHACK…

I would say the team. They are really nice – like a family! The programs are very interesting.

The platform is really user-friendly: it’s super easy to make a report, you don’t get lost in the tabs, it’s really simple and effective!

ON THE THREE WORDS THAT BEST DESCRIBE HIS APTITUDE FOR HACKING…

ON THE VULNERABILITY HE IS MOST PROUD OF UNEARTHING…

I’m quite proud of that one, because it was one of the first that enabled me to develop my skills on the platform and start sharing with the community. It was in collaboration with 

It was an application where you rendered a document and we did an RCE on it, which was great. There was a CVE on LibreOffice that we took advantage of. We went all the way: performed an exploit and got a reverse shell on the machine. And that wasn’t bad, because it got us a nice €10,000 reward.

This is the most recent one, which I found not long ago. It’s a CVE I found on LibreOffice that lets you execute code without any warning: in other words, you open a document – a CV for example – and open it on your machine with LibreOffice, then I can execute the command I want.

I check out the invitation, see if I like the application, and if I do, I work on it. I just follow my gut feeling.

ON THE MOST COMMON MISTAKE MADE BY NEWBIE BUG HUNTERS…

The YesWeHack Blog

‘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

‘We opted for Bug Bounty for agility reasons’: European Community of Alsace CISO

YesWeHack hunter achievements: Unveiling the Galactic Guardians series

‘Proficiency takes time’: Xel on his best Bug Bounty finds and the primacy of patience in ethical hacking

‘We opted for Bug Bounty for agility reasons’: European Community of Alsace CISO

Don't wait for threats to strike

Products

Researchers

Resources

Company

Follow us