invited participants to exploit a XML external entity (XXE) injection (CWE-611) vulnerability

and read a file containing the challenge flag.

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

A XXE (XML External Entity) vulnerability occurs when an application allows an attacker to include insecure external entities in an XML document.

This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

Vulnerable applications may include web services, applications that use XML documents for data processing, or any workflow that improperly controls XML data.

We are presented with a web application giving us a prompt in order to give our input to an AI generating images. We can either directly give it a theme or input a base64 string of an XML file.

When we analyze the source code, we notice the 

 function, which we're going to focus on:

One line catches instantly our attention:

parser.setFeature(xml.sax.handler.feature_external_ges, True)

Indeed, this line of Python code is used to configure the XML parser to allow the processing of external general entities (external general entities are entities declared outside the DTD (Document Type Definition) of an XML document).

: is a method used to enable or disable certain features of the XML parser.

: is a predefined constant in the xml.sax.handler module that specifies the feature to allow external general entities.

This confirms that an XXE attack is possible on the web application if we manage to craft a malicious XML file.

if (dataBytes[:2] != b'\xff\xfe' and dataBytes[:2] != b'\xfe\xff'):

 checks for the presence of Byte Order Mark (BOM) signatures for UTF-16 little-endian (

). Here's the purpose of this verification:

 BOM signatures are used to indicate the encoding of a text file, especially for UTF-16. 

 signifies that the text is encoded in UTF-16 little-endian, while 

 signifies that the text is encoded in UTF-16 big-endian.

 By checking these signatures, the code ensures that the data it processes is not encoded in UTF-16. If the data were UTF-16 encoded, it would require special handling to be correctly decoded. The absence of these signatures allows the code to proceed under the assumption that the data is encoded in another format (likely UTF-8 or another encoding without a BOM).

 If the data were UTF-16 encoded but processed as another encoding, it could lead to processing errors or unexpected behaviors. By checking for and excluding UTF-16 encoded data, the code reduces the risk of such errors.

However, it appears that the code lacks explicit handling for data that contains a UTF-16 BOM. It would be prudent to add an else block to handle this situation if necessary, for instance, by returning an error or correctly decoding the UTF-16 data.

if any(x in dataBytes.lower() for x in [b'file://', b'tmp', b'flag.txt', b'system', b'public', b'entity']):

 checks for the presence of certain substrings within the decoded data. Here's the purpose of this verification:

Detection of Potentially Dangerous Content:

 This condition searches for specific keywords and substrings that could indicate dangerous or sensitive content. For example:  

 could be used to attempt file access or directory traversal.

 might refer to sensitive files or directories.

 could be related to critical system paths or publicly accessible areas.

b'entity' is relevant in the context of XML parsing and could be related to XML External Entity (XXE) attacks.

 By detecting these potentially dangerous substrings, the code can prevent the processing of malicious data that could lead to security vulnerabilities. For instance, an XXE attack might involve using external entities to access sensitive files, and this condition helps block such attempts.

 This check acts as an early warning system for malicious input, allowing the function to return 'BLOCKED' immediately if any of these keywords are found. This prevents further processing of potentially harmful data, reducing the risk of security breaches.

Overall, this condition helps enhance the security of the application by detecting and blocking potentially harmful content before it can be processed and cause damage.

The parser allows parsing of general entities.

A UTF16 little-endian of big-endian bypass the blacklist protection

In order to exploit the vulnerability, we then can take a classic XXE payload :

And use any program to encode it as UTF16 little-endian (or big), then encode it to base64 and feed it to application.

 binaries, on our XML file containing our payload:

Copy paste the result to the prompt of the application and verify the exploitation:

 file, we use the following XML payload :

In order to automate the task I wrote a script that automate the task, here is a demonstration :

XXE (XML External Entity) vulnerabilities pose significant security risks to systems. By exploiting these vulnerabilities, attackers can gain access to sensitive files on the server, execute remote code, or retrieve confidential data.
This can lead to privacy breaches, data integrity violations, or even complete compromise of the system. Vulnerable applications often include web services and other applications that handle XML data without properly controlling it, exposing these systems to significant risks of exploitation by malicious actors.

To protect against XXE (XML External Entity) vulnerabilities, we recommend following these measures:

 Configure XML processors to disable support for insecure external entities.

 Utilize secure XML libraries that implement protections against XXE attacks.

 Rigorously validate and filter all incoming XML data to eliminate unauthorized external entities and potentially malicious data.

 Ensure all XML libraries used are up-to-date with the latest security patches to mitigate risks.

 Educate developers and security teams on best practices for securing XML applications and web services.

By implementing these measures, you can effectively reduce the risks of XXE vulnerabilities in your applications and systems.

 - XML External Entity (XXE) Processing : https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing

 - Vulnerabilities affecting of the SAX parser : https://docs.python.org/3/library/xml.html#xml-vulnerabilities

Dojo challenge #34 winners!

Europe’s most successful ethical hackers and an iconic luxury fashion house proved an irresistible combination for our most glamorous Live Bug Bounty yet.

From the Paris headquarters of Louis Vuitton, around 40 high-ranking hunters deployed their eclectic skills to produce an impressive variety of findings at the second edition of YesWeHack’s ‘Hack Me I'm Famous’.

Louis Vuitton has declared itself delighted with the results – a reflection of the calibre of the hunters, the time (30 hours) and productive setting for hunting, and the target’s commitment to making its internet-facing applications as secure as possible.

YesWeHack keeps Live Bug Bounty targets under wraps until the last-possible moment. This prevents hunters performing pre-event reconnaissance on the targets to get a head start.

On day one, the hunters were kitted out in stylish, baseball-style jackets customised with their hacker alias, before being led to the mystery venue. En route, some excitedly speculated, aided by Google Maps, which nearby organisation might be welcoming them. A famous company? A government agency?

It was no anticlimax when Louis Vuitton’s impressive headquarters heaved into view.

Founded in 1854, Louis Vuitton’s clothing, bags, jewellery, perfume and other fashion items are instantly recognisable worldwide via its iconic LV monogram. The haute couture pioneer is part of LVMH group, the world’s largest luxury fashion multinational.

If the Live Bug Bounty target excels in its field, then so too do the hunters carefully handpicked for the occasion. Ten of YesWeHack’s all-time top 25 performers were enlisted, although hunters were chosen not just for their leaderboard ranking, but also for the relevance of their skillset to the scopes at hand.

Louis Vuitton was a tantalising target – and not only because of the lustre of the brand itself.

Unusually in its industry (and most industries), Louis Vuitton develops most of its digital assets internally. Adding to the anticipation for the Live Bug Bounty was an API among the scopes that had not been part of the private Bug Bounty Program.

Partly thanks to some participants’ familiarity with the scopes via the private program, the reports started rolling in relatively early. Vulnerabilities were surfaced throughout, with the final report submitted in the last few seconds of the competition.

Just 30 minutes later the Louis Vuitton team had, with YesWeHack’s support, reproduced and assessed all vulnerabilities.

The hackers seemed particularly laser-focused as they hacked for 30 hours with infrequent breaks for food, socialising and sleep.

And yet, they were still happy to take time out to patiently explain their findings to Louis Vuitton security teams during their event. There were also ‘show and tell’ presentations of the most significant vulnerabilities at the end.

“What makes this type of event unique is the intense interaction and collaboration that we saw between the researchers and Louis Vuitton security teams,” said Adrien Jeanneau, head of security analysts and researcher enablement. “We saw some great exchanges between them, and everyone appreciated it! The hunters and security teams delved deep into technical discussions about the findings, even though time was limited.” 

Alongside the hacking event, staff from various departments attended demonstrations and interactive workshops about the Live Bug Bounty, phishing attacks and protecting the brand’s global internet assets, among other things.

This, and the attentive engagement throughout of Louis Vuitton’s CIO and CISO, revealed a corporate culture that takes security very seriously – organisation-wide.

 were occupied by a Spanish trio who collaborated throughout the event and notched 26 bugs and 23 rewards apiece. Collectively the hunters reported 133 bugs in total.

YesWeHack and Louis Vuitton created special awards for notable achievements at the Live Bug Bounty, with the winners taking home YesWeHack souvenirs created for the event. Congratulations to the winners:

🧥 Shellcode Stylist (1st place): Diego Bernal Adelantado aka GoDiego

🧵 Exploit Tailor (2nd place): Diego Jurado Pallarés aka djurado

🎀 Pwnage Designer (3rd place): Carlos Rivero Molina aka hipotermia

🧶 Patchwork Pwners (team with highest points): GoDiego, djurado and hipotermia

💎 Best-Dressed Bug (biggest impact): HakuPiku

👜 Bug Trend-Setter (first valid bug): GoDiego

Christophe Plouseau, Chief Information Officer (CIO) of Louis Vuitton, said:

“This is the very first time a luxury brand has organised such an event, so I am very proud of LV_NEO Teams [Louis Vuitton’s tech team]. We were already in the forefront of cybersecurity and this event is testament that we take cybersecurity and cyber threats seriously, especially in the context of the Paris Olympic Games coming soon, where French firms will be the main target of hackers.

“This was also a tremendous opportunity to have the crème de la crème of hackers with us, to share with all LV employees tips and tricks for what they should do in their personal and professional life to mitigate cyber risk, and share what Louis Vuitton does to protect the company’s assets and information systems.”

The hunters also offered their thoughts on the event:

“The experience has been top-notch. I believe we found good bugs… the Louis Vuitton team are great. I would like to thank the YesWeHack team again for the great facilitation of the event, the rewards, the communication.”

“The office is extremely huge and beautiful so we were all looking [forward] to hunt in this place. I really enjoyed the event, honestly. I have the luck to hunt with a lot of friends.”

“This is my first experience with a live hacking event and it is an amazing event. It was possible to improve my knowledge. The place is very beautiful. Nice food, nice scope, very nice people. Fantastic hackers and friends.”

“I knew that they had a quite huge scope. So it was a great feeling knowing there is going to be a lot to hack on, probably not as many duplicates. I’d like to thank YesWeHack for inviting me to this very exclusive event and I want to thank Louis Vuitton for hosting us here at their headquarters.”

And finally, from YesWeHack: a big thank you to all participating hunters, Louis Vuitton and all partners for making this event a such as huge success.

Hack Me I’m Famous #2: Louis Vuitton sets trend with first live hacking event in luxury fashion sector

Having access to your target’s source code is obviously an invaluable advantage of white-box penetration testing.

This article will help you leverage that benefit in the context of PHP applications and using the Xdebug PHP debugger.

Specifically, you will learn how to set up a PHP web application within a docker environment; how to set up 

; how to detect PHP vulnerabilities using Xdebug; common PHP vulnerabilities; and how to leverage your white-box pentest findings to enhance future black-box testing.

Follow these steps to not only unearth vulnerabilities during white-box engagements, but to also craft custom payloads you can unleash to great effect in future black-box tests.

CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

CWE-624: Executable Regular Expression Error

CWE-434: Unrestricted Upload of File with Dangerous Type

Improve future black-box testing with code analysis

Visual Studio Code (VS Code) (or your preferred IDE)

Once you have installed Visual Studio Code, you can install the Xdebug extension from the extension tab on the left-hand side. Simply search for "

For our demonstration, we will use a vulnerable PHP code snippet from YesWeHack’s 

 Github repository (which also contains snippets written in a variety of other programming languages).

If you are completely new to using Xdebug, we recommend using the same snippet: 

. Otherwise, feel free to take a different code snippet that better suits your preferences.

Our project will use the following file structure: 

Certain files are extra-important and must be added or modified, including:

This will be the Xdebug listener configuration that is used inside Visual Studio Code on our host system.

This file contains the configurations for our vulnerable web application, which is running inside a docker container.

As well as building the docker image, the Dockerfile installs and activates PHP Xdebug inside the docker container.

To this file we will add our host’s hostname to enable our docker container to communicate with Xdebug, which will be hosted by our host system in Visual Studio Code.

 folder provided, we will create a new file in 

, we will add the code below immediately under the first line (which is: 

). This will allow us to install and enable Xdebug in our vulnerable docker container.

 file will be used to set up services for the docker container to run and make the PHP web application accessible via port 

 parameter and the value we give it is used to enable the docker container to communicate with our host system, where the Xdebug listener is running in our Visual Studio Code IDE.

Take note that we added two final lines to the 

Now our setup is ready, we can start debugging our vulnerable web application.

To make sure our debugger works, we will open Visual Studio Code on our host system and set a couple of breakpoints in the vulnerable code snippet. You can do this by simply clicking on the left side of the line number identifiers. This will make red dots appear, as you can see in the image below. This red dot represents a breakpoint that our debugger will stop at.

When a HTTP request is sent by a client to the vulnerable web application, our debugger will stop at our first breakpoint (

) and display all necessary debugging information.

We can trigger the Xdebug listener in Visual Studio Code by sending a HTTP request to our vulnerable web application with curl:

If you want to debug a HTTP request in Visual Studio Code, make sure you include the cookie 

 before you send it. This tells our Xdebug listener to start debugging. It will stop debugging at the first breakpoint, which is triggered by our HTTP request.

Xdebug is a great tool to use both for development and white box penetration testing. By providing a detailed overview of debugging results generated from each code section encountered, this utility means you, as a penetration tester, can more easily see where your input is used and how the payload is modified.

By using our previously described setup (see ‘

’), we can now start analysing our vulnerable code.

Let’s start by sending another HTTP request with curl, this time with a simple SQL injection payload (

After sending this HTTP request we can see that it hit our source code and, in the left sidebar, that our 

 parameter’s value has been determined by our payload.

Next, by pressing the curved blue arrow (second blue icon from the left) in the debug bar (on the top-left of Visual Studio Code by default), we will jump to the second breakpoint we set in the source code.

Continue pressing the arrow until you reach line 

 as shown in the image below. Then right click on the 

Once added to the Watch section, these two variables will appear at the bottom left under the debug sidebar.

We are now monitoring these two variables because 

 is the character to be escaped. If our payload contains the value presented in the variable 

, a backslash will be added before all characters within the payload (this backslash is the 

Continue pressing the blue debug arrow until the 

). This indicates that this character should be escaped in the next loop, and our payload should be modified by the filter.

Press the blue debug arrow again and you will see that our payload was modified by the filter, as shown in the image below:

 character, which it just used to escape our single quote (

) character. This means that, for the next loop, it should escape the backslash character in our payload.

As you can see below, this is exactly what happens. The backslash character 

 replace the backslash character that was previously used to escape our single quote. This makes our current backslash escape itself in the payload, leaving the single quote character unescaped.

By pressing the blue debug arrow one more time, we can see that we have jumped outside the filter and that our final payload remains as:

Finally, we stop the debugging process by pressing the red square in the debug field. We can then see that our curl contains the results from the 

Below are three of the most common weaknesses associated with the PHP programming language.

Source: https://cwe.mitre.org/data/definitions/98.html

The application uses input data that can be controlled by the user. This input value is then later used within an include, require or similar function. 

An attacker can exploit this by creating a specific value that dupes the application into including an unintended file, which can then be used to obtain arbitrary file reads or, in most cases, a remote code execution (RCE). This vulnerability is mainly known as Local/Remote File Inclusion.

White-box penetration testing with Xdebug: Debugging for PHP vulnerabilities

The world’s largest cosmetics and personal care company is the latest illustrious brand to enjoy the benefits of a live Bug Bounty with YesWeHack.

Websites, APIs and mobile apps belonging to L'Oréal are now significantly hardened thanks to the discovery of 71 vulnerabilities during an 18-hour event at the LeHack conference last week.

The live hacking event in Paris began at 10am on day two of LeHack (7 July) and concluded at 4am the following morning after some intensive triaging. The rewards grid went up to €5,000.

The scopes comprised a representative sample of L’Oréal’s most business-critical assets, including:

E-commerce websites for various brands and markets, built on different core technologies

Technologies highly specific to L’Oréal that process sensitive customer data

Impressed by the initial findings, L’Oréal’s security team extended the scope early in the evening to maximise the talent and unique opportunity available – a decision vindicated by the submission of some invaluable findings as the event drew to a close. Most notably, credentials were available for one added scope – an uncommon move for a live hacking event – which allowed hunters to dig deep into a new application and make some intriguing discoveries.

More than 50 YesWeHack-registered hunters kicked off the event and around 100 took part overall, with 31 making it onto the leaderboard.

 by a huge margin in his first-ever live hacking event (although he 

 until the second half of the event). He notched 142 points via nine bug reports.

In second place, ‘Borgi’ accrued 49 points from six vulnerabilities, while third on the podium was ‘cosades’, who scored 45 points from three reports.

However, the leaderboard is only one part of the story of live Bug Bounties, which are as much about (if not more so) collaboration and community.

“It was really nice to meet [fellow hunters] again and to discuss with some managers of programs I'm used to hunting on,” said ‘Aituglo’, one of the participants, in a 

Aituglo said his own pre-event automation work and the support of his peers paid dividends for L’Oréal. A custom plugin helped him “get a hit for an XSS” within five minutes of starting his hunt, then “with the help of some friends, I got a nice PoC to steal the password of the user”.

Despite the generous bounties on offer, Aituglo said that making “a lot of money” was not the overriding incentive. It’s “more to discuss and see your friends, hunt together and so on”.

“Thank you for this wonderful event. It was a pleasant surprise and an honour to top the leaderboard. This motivates me to continue learning and improving.

“It was my first in-person event in cybersecurity, and it was really exciting. The other participants were all friendly and warm. The event was well structured, with responsive support. A very positive and enriching experience.”

The event was also “an enriching experience for another hunter, @dropn0w, who 

 on X: “We learned many valuable lessons and measured our skills against the best hackers in France.”

Guillaume Kermarrec, threat and vulnerability manager at L'Oréal’s CyberDefence Center, and in charge of L'Oréal’s Bug Bounty Programs, said:

“The key benefits were meeting the security researchers, meeting the triage team, and working together to find and fix some complex vulnerabilities. We focused on our most critical websites, both global websites and from different regions, B2B and B2C, and some uncovered assets like APIs and mobile applications. Thanks to this live event we could test some new scopes with very specific configurations that couldn’t be added to our continuous program. We have found some interesting vulnerabilities at the live hacking event.”

Fabio Bührer, global application security manager at L'Oréal’s CyberDefence Center:

“The scopes have been tested in the past and now there’s a lot of good people here going through the scopes to see if there’s anything that needs to be taken care of. It’s good to meet the people who work on the program virtually and and see that they actually exist – they’re not just an avatar or AI! YesWeHack did a great job of organising this.”

From YesWeHack, a sincere and heartfelt thanks to all participants for helping to secure the digital assets of L'Oréal, the personal data of L'Oréal customers, and the global internet as a whole.

The L'Oréal event follows a recent Live Bug Bounty held for a similarly glamorous and legendary French brand: Louis Vuitton, which was more than satisfied with the outcome of 

YesWeHack’s second ‘Hack Me I'm Famous’ event

. This in turn came hot on the heels of a 

 in the scopes of Groupe Caisse des Dépôts (CDC), a French public financial institution, at InCyber Forum (FIC) Europe. The targets for LeHack 2023, meanwhile, were provided by the

 French Red Cross and retail distribution giant Les Mousquetaires Group

 and also yielded an impressive bug haul.

YesWeHack also welcomed a steady stream of ethical hackers, security researchers and other security professionals at our LeHack booth, in Cité des sciences et de l'industrie.

 CTF training platforms, we gave away countless t-shirts and other swag. Other sought-after merch was exclusively available to anyone who managed to take on our claw machine (pictured) and triumph.

Finally, many thanks to our tech ambassador, BitK, for the CTF he created exclusively for LeHack attendees (the ‘Pandemic CTF’).

L'Oréal lauds live Bug Bounty success at LeHack 2024

 has recounted how an attack on his own home network led him to uncover how an attacker could have breached 

The US telco that supplied the modems, Cox Communications, said it found no history of abuse of the relevant attack vector, patched the issue rapidly and promised a comprehensive security review, according to Curry.

“This series of vulnerabilities demonstrated a way in which a fully external attacker with no prerequisites could've executed commands and modified the settings of millions of modems, accessed any business customer's PII, and gained essentially the same permissions of an ISP support team,” wrote Curry in his latest 

Curry’s latest tour de force was the lead story in our latest 

, a monthly LinkedIn roundup of notable security research, new hunting opportunities, and hacking advice and inspiration.

The next story saw the Federation of American Scientists (FAD) urge Congress to establish 

 and create a safe harbour for research on generative AI platforms.

“While Congress encourages companies to provide bug bounties and protections for security research, this is not yet the case for AI safety research,” 

. AI companies were criticised for “implicitly threatening to ban independent researchers that demonstrate safety flaws in their systems,” and failing to “adequately test their models after they are deployed as part of an evolving product or service”.

The YesWeHack Blog

Dojo challenge #34 winners!

Hack Me I’m Famous #2: Louis Vuitton sets trend with first live hacking event in luxury fashion sector

White-box penetration testing with Xdebug: Debugging for PHP vulnerabilities

Dojo challenge #34 winners!

L'Oréal lauds live Bug Bounty success at LeHack 2024

Sam Curry modem masterclass, PHP threat to Windows Servers, Calls for AI safety Bug Bounties – ethical hacker news roundup

Critical infrastructure-level protections for YesWeHack cloud after switch to SecNumCloud-qualified service

L'Oréal lauds live Bug Bounty success at LeHack 2024

Apple declines to pay Kaspersky vuln reward, Bug Bounty ‘extortion’ dispute, Microsoft Recall backlash – OffSec roundup for CISOs

Dojo challenge #33 winners!

Countdown to NIS 2 compliance: Key insights and implications for your SecOps strategy

Apple declines to pay Kaspersky vuln reward, Bug Bounty ‘extortion’ dispute, Microsoft Recall backlash – OffSec roundup for CISOs

DON'T WAIT FOR THE THREATS TO STRIKE

Produits

Chercheurs

Ressources

A propos

Suivez-nous