Being part of the Checkmarx SCA Research Team who supports our next-gen Software Composition Analysis (SCA) solution, my team members and I often participate in Capture the Flag (CTF) types of competitions to hone our skills and share our knowledge with the rest of the team. Not only are we expected to be skilled defenders, but we also spend time thinking and acting like attackers since both skillsets are imperative to increasingly improve our open source analysis solution. Performing continuous security research is a fundamental activity at Checkmarx.
Every year, the Israeli Security Agency (ISA), also known as Shabak, releases several tech challenges which helps them find and recruit new agents. Since most articles you read are from a defender’s perspective, in this blog I will provide some insight from an attacker’s perspective and explain how I solved the two CTF web challenges that were recently published. The first CTF challenge is below:
The page reloads, and this time we got this wonderful dog gif and an md5 hash of the file contents. Looking at the browser address bar, I could also see a new query parameter named “pic” with the gif full URL as shown below.
I immediately started thinking about SSRF (Server-Side Request Forgery) and XSS (Cross-Site Scripting) vulnerabilities. SSRF since the server must download the image file in order to produce the md5 hash, and XSS because the page reflects the gif URL in the src attribute of an image tag.
I tested for XSS using the simplest payload I could think of, and sure enough, it worked.
However, unlike the latest Google CTF, there was no way to get a headless browser to visit that page, and since it was too easy, I moved on to explore SSRF.
I wanted to see the raw request the server was making, so I used Netcat to listen on port 5000. Then I made a request from gifon by changing the pic query parameter to my server IP address.
We can see in the image above that a simple GET request was made using curl version 7.52.1. I tried a few common SSRF payloads to see if I could access some internal services. However, they all return an empty response, evident by the generated md5 hash “d41d8cd98f00b204e9800998ecf8427e”, which is the md5 hash of an empty string.
Back to square one, I decided to look at the server response headers as shown below to look for clues.
The X-Powered-By header shows the server is running PHP version 5.6.40.
I decided to fuzz the pic query parameter, and one of the payloads I used contained a null byte that triggered the following warning:
It seemed the null byte was passed to a PHP system call, which means it probably had a command injection vulnerability.
I tried the following payload: pic=https://example.org&&whoami&&.gif and it worked, we can see that the current user is “www-data” below.
I tried to read /etc/hosts but was blocked with the following error: “spaces in URL not allowed”. So, we can’t use spaces. I next tried using a URL encoded tab but that also didn’t work. So finally, I remembered the good old ${IFS} (Input Field Separator).
Then I started looking around the file system when I noticed a folder named “secret”.
The folder contained a file named flag that unsurprisingly contained the challenge flag.
Below is the final payload I used to read the flag.
gifon.shieldchallenges.com/?pic=https://example.org/%26%26cat${IFS}/var/www/html/secret/flag%26%26.gif
flag{DIS-IS-FLAG-I-R-VERY-H4X0R-U-2?}
Now, let’s move on to the next CTF challenge I participated in.
After looking at the website source code, it became apparent that the author-based filtering was done via the client-side, while the search functionality required the server.
Looking at the response headers, I could see the server was running PHP version 7.4.13 and Apache version 2.4.38 (Debian).
I assumed the server-side search was querying some kind of database, so I decided to test for possible injections. I tried the following payloads:
search=ice%
search=ice’ or ‘a’ = ‘a
search=ice” or “A” = “A
search[$regex]=ice.{1,}
Unfortunately, all of them failed. Next, I started exploring other pages. The post.php was particularly interesting since it contained an unfinished form that seemed to be for updating existing posts as shown below.
I could see all of the good stuff here, no authentication, a file picker, and it also related to what was said in the challenge description: “Pnina insisted she'd implemented each and every feature.” This got me thinking that maybe the backend was vulnerable?
I disabled the JavaScript that was preventing the form submission and pointed the form action to “/post.php” but no luck; the server just responded with the same response.
I tried tweaking the form a bit more, adding enctype=multipart/form-data attribute, trying PUT and PATCH methods, and even posting the form data to other files, but I wasn’t able to make any progress.
I fuzzed the server using common PHP file names, but I wasn’t able to find any relevant additional PHP files.
I decided to go back to the main gallery page since it was the only place where I knew the server was processing my input. I fuzzed the search query parameter, and just like in the last challenge, the null byte saved the day as shown below.
I got 3 warnings, each of them exposing a different method index.php uses. index.php is responsible for the server-side search, so when I saw that the glob method was used, I immediately knew how the backend search worked.
Glob is a built-in method in PHP that finds files and folders based on a pattern. To confirm that, I simply used the glob wildcard character as part of my search, and it worked as expected.
So now that I knew glob was used, and that I controlled the query, I tried to perform a path traversal attack that could help me find some new PHP files or even the flag.
As you can see above, I sent the following payload: search=../*
Interesting… Some of the results were rendered, but some seemed to be missing.
I assumed the base path used in glob was /files, so going back once should show me index.php, post.php, and any other file that might be in that directory. But instead, I just got 7 open and closed HTML comments. This is probably due to array_filter dropping files without an image extension.
Previously when I fuzzed the server looking for upload endpoints, I managed to find the following 5 PHP files:
And as you can see above, I got exactly 5 open and close comments for the 5 PHP files on the server root directory. This was when I came to the realization that the HTML comments can be used as an oracle in a side-channel attack to leak the full path of any file on the server.
I wrote a short script that simply goes through the alphabet, changing just a single character in the following search: */*.{char}* After a few seconds, I had the results. I noticed that */*.t* was rendering a single HTML comment, meaning, somewhere in the “/files” folder there was a file with an extension that starts with the letter “t”.
I could now get the next character by repeating this process with the following search: */*.t{char}*, and discovered the next character was “x”. I repeated this process again revealing that the file extension was “.txt”. Now I just need to repeat this process from the other side to get the full file path.
This was a bit tricky since I needed to encode some of the characters like & and #, but in the end, I extracted the full file path which was Habier/Habier&Valery4ever_#WEBISFUN.txt
Now I just need to download this txt file to capture the flag by visiting art.shieldchallenges.com/files/Habier/Habier%26Valery4ever_%23WEBISFUN.txt
And here is the flag:
FLAG{You-R-Gl0bMast3R}
GiFON
Points: 200 Scenario: Jeff D. Spleier applied for a job in the ISA. His interview went really well, and he seemed the right man for the job. Naturally, we decided not to recruit him. We suspect that he is in possession of some classified documents that must not be leaked. We worry that he might act out his revenge and publish them. We know that he maintains an online Gif Displayer. Probably irrelevant, but who knows? https://gifon.shieldchallenges.comSolving Challenge 1
When I opened the gifon website, I immediately saw a dropdown list and a “show me!” button. I chose the first option “Dogs” and clicked on the button.
The page reloads, and this time we got this wonderful dog gif and an md5 hash of the file contents. Looking at the browser address bar, I could also see a new query parameter named “pic” with the gif full URL as shown below.
I immediately started thinking about SSRF (Server-Side Request Forgery) and XSS (Cross-Site Scripting) vulnerabilities. SSRF since the server must download the image file in order to produce the md5 hash, and XSS because the page reflects the gif URL in the src attribute of an image tag.
I tested for XSS using the simplest payload I could think of, and sure enough, it worked.
However, unlike the latest Google CTF, there was no way to get a headless browser to visit that page, and since it was too easy, I moved on to explore SSRF.
I wanted to see the raw request the server was making, so I used Netcat to listen on port 5000. Then I made a request from gifon by changing the pic query parameter to my server IP address.
We can see in the image above that a simple GET request was made using curl version 7.52.1. I tried a few common SSRF payloads to see if I could access some internal services. However, they all return an empty response, evident by the generated md5 hash “d41d8cd98f00b204e9800998ecf8427e”, which is the md5 hash of an empty string.
Back to square one, I decided to look at the server response headers as shown below to look for clues.
The X-Powered-By header shows the server is running PHP version 5.6.40.
I decided to fuzz the pic query parameter, and one of the payloads I used contained a null byte that triggered the following warning:
It seemed the null byte was passed to a PHP system call, which means it probably had a command injection vulnerability.
I tried the following payload: pic=https://example.org&&whoami&&.gif and it worked, we can see that the current user is “www-data” below.
I tried to read /etc/hosts but was blocked with the following error: “spaces in URL not allowed”. So, we can’t use spaces. I next tried using a URL encoded tab but that also didn’t work. So finally, I remembered the good old ${IFS} (Input Field Separator).
Then I started looking around the file system when I noticed a folder named “secret”.
The folder contained a file named flag that unsurprisingly contained the challenge flag.
Below is the final payload I used to read the flag.
gifon.shieldchallenges.com/?pic=https://example.org/%26%26cat${IFS}/var/www/html/secret/flag%26%26.gif
flag{DIS-IS-FLAG-I-R-VERY-H4X0R-U-2?}
Now, let’s move on to the next CTF challenge I participated in.
The Art Gallery Challenge
Points: 300 Scenario: Pnina Terest applied for a job in the ISA. We asked her to implement a web-based art gallery to store all of ISA's best pictures. When Pnina submitted her finished work, we were disappointed to find out that she did not implement some of the features we requested. However, when we asked Pnina about this, she insisted that she'd implemented each and every feature and that we didn't look hard enough. Pnina is annoying. We decided not to recruit her. https://art.shieldchallenges.comSolving Challenge 2
When I opened the website, I could see, as promised, a gallery. I could filter images based on their author and search for a specific image by name.
After looking at the website source code, it became apparent that the author-based filtering was done via the client-side, while the search functionality required the server.
Looking at the response headers, I could see the server was running PHP version 7.4.13 and Apache version 2.4.38 (Debian).
I assumed the server-side search was querying some kind of database, so I decided to test for possible injections. I tried the following payloads:
search=ice%
search=ice’ or ‘a’ = ‘a
search=ice” or “A” = “A
search[$regex]=ice.{1,}
Unfortunately, all of them failed. Next, I started exploring other pages. The post.php was particularly interesting since it contained an unfinished form that seemed to be for updating existing posts as shown below.
I could see all of the good stuff here, no authentication, a file picker, and it also related to what was said in the challenge description: “Pnina insisted she'd implemented each and every feature.” This got me thinking that maybe the backend was vulnerable?
I disabled the JavaScript that was preventing the form submission and pointed the form action to “/post.php” but no luck; the server just responded with the same response.
I tried tweaking the form a bit more, adding enctype=multipart/form-data attribute, trying PUT and PATCH methods, and even posting the form data to other files, but I wasn’t able to make any progress.
I fuzzed the server using common PHP file names, but I wasn’t able to find any relevant additional PHP files.
I decided to go back to the main gallery page since it was the only place where I knew the server was processing my input. I fuzzed the search query parameter, and just like in the last challenge, the null byte saved the day as shown below.
I got 3 warnings, each of them exposing a different method index.php uses. index.php is responsible for the server-side search, so when I saw that the glob method was used, I immediately knew how the backend search worked.
Glob is a built-in method in PHP that finds files and folders based on a pattern. To confirm that, I simply used the glob wildcard character as part of my search, and it worked as expected.
So now that I knew glob was used, and that I controlled the query, I tried to perform a path traversal attack that could help me find some new PHP files or even the flag.
As you can see above, I sent the following payload: search=../*
Interesting… Some of the results were rendered, but some seemed to be missing.
I assumed the base path used in glob was /files, so going back once should show me index.php, post.php, and any other file that might be in that directory. But instead, I just got 7 open and closed HTML comments. This is probably due to array_filter dropping files without an image extension.
Previously when I fuzzed the server looking for upload endpoints, I managed to find the following 5 PHP files:
- index.php
- post.php
- author.php
- 404.php
- 403.php
And as you can see above, I got exactly 5 open and close comments for the 5 PHP files on the server root directory. This was when I came to the realization that the HTML comments can be used as an oracle in a side-channel attack to leak the full path of any file on the server.
I wrote a short script that simply goes through the alphabet, changing just a single character in the following search: */*.{char}* After a few seconds, I had the results. I noticed that */*.t* was rendering a single HTML comment, meaning, somewhere in the “/files” folder there was a file with an extension that starts with the letter “t”.
I could now get the next character by repeating this process with the following search: */*.t{char}*, and discovered the next character was “x”. I repeated this process again revealing that the file extension was “.txt”. Now I just need to repeat this process from the other side to get the full file path.
This was a bit tricky since I needed to encode some of the characters like & and #, but in the end, I extracted the full file path which was Habier/Habier&Valery4ever_#WEBISFUN.txt
Now I just need to download this txt file to capture the flag by visiting art.shieldchallenges.com/files/Habier/Habier%26Valery4ever_%23WEBISFUN.txt
And here is the flag:
FLAG{You-R-Gl0bMast3R}
Closing Thoughts
I think this was the best CTF events ISA ever released. Unfortunately, I didn't have the time to dive into all of them. I'm looking forward to the challenges that next year’s event brings.About Checkmarx SCA Research Team
Discovering security issues in open source components and third-party libraires is why the Checkmarx SCA Research Team performs investigations into open source projects. With open source being used within the vast majority of today’s applications, security vulnerabilities and risks in open source must be taken seriously and handled carefully across the entire software industry. Solutions like Checkmarx SCA (CxSCA) are essential in helping organizations identify, prioritize, and remediate open source risks more efficiently to improve their overall software security posture. For more information or to speak to an expert about how to detect, prioritize, and remediate open source risks in your code, please contact us here. 
