Yara CTF – The Answers

Share Now


Hello everyone, and thank you for coming to check out the Yara CTF answers! We had a TON of folks who were interested in the challenge, many submitted answers, and many folks enjoyed the challenges. Some of the best feedback we received was “This was the shortest plane ride over to Vegas. Thanks, PhishMe!”

For the challenges, we had every intention to write up the answers and solutions on how to do them. Tyler Hudak, the winner of the PhishMe Yara CTF, decided to write up the answers as well. Since Tyler did a better job writing the solutions up than we could, we wanted to feature his blog for solutions #1-10.

Part 1, puzzle #1-4: https://blog.korelogic.com/blog/2015/08/17/yara-ctf-1

Part 2, puzzle #5-8: https://blog.korelogic.com/blog/2015/08/19/yara-ctf-2

Part 3, puzzle #9-11: https://blog.korelogic.com/blog/2015/08/21/yara-ctf-3

For #11, the challenge was to find an exploit in Yara and submit it as an answer. Our intentions here were to work with the developers behind the scenes to help and patch it, as we’ve done that in the past. Here’s one possible solution to #11.

Early in the Triage days, we were testing different versions of Yara for fun and interesting things. When we started, there was no hashing function that would let you do an MD5 hash for matching a sample. So we went out to try and do something like this in Yara. Our first approach was to calculate all of the hex out for the file, then create a Yara rule for this information. Here’s what that would look like:

Figure 1 – Converting the hex to ascii

By doing this approach, it will theoretically work… however, it means you have long Yara rules.

Figure 2 – Long Yara rule is long

When running the rule, we get something that many exploit writers love. A process crash!

Figure 3 – Yara crash

With a little sleuth work in IDA, we can see that we have stumbled on a stack-based overflow. By removing a little bit at a time and working backward, we can start to see exactly where our overflow takes place. You can also use Metasploit and pattern_offset.rb for this, but we did ours by hand. By doing it by hand, we can get close to see the exact values that crash the process.

Figure 4 – Guess and check exploit development

For our Windows 7 64-bit install, here are the lengths that crash it.

>>> a = open (“rule.yar”, “wb”).write(“rule large {strings: $h1 = {” + (“00 ” * 64327) + “} condition: any of them }”)

>>> a = open (“rule.yar”, “wb”).write(“rule large {strings: $h1 = {” + (“00 ” * 64328) + “} condition: any of them }”)

At the time, we tested this in OSX as well. These are the lengths which didn’t crash / did crash:

>>> a = open (“rule.yar”, “wb”).write(“rule large {strings: $h1 = {” + (“00 ” * 261912) + “} condition: any of them }”)

>>> a = open (“rule.yar”, “wb”).write(“rule large {strings: $h1 = {” + (“00 ” * 261913) + “} condition: any of them }”)

Once we found the exploit and had the details of it, we passed it over to Victor, the creator of Yara. Within about 20 minutes of sending him the email, not only did he respond back with exactly which routine was causing the problem, but he also sent back the code commit upstream which was patched for future versions, setting a bounds on hex values to 10,000 characters. Victor and his team at VirusTotal have been a pleasure to work with!



We use our own and third-party cookies to enhance your experience by showing you relevant content, personalizing our communications with you, and remembering your preferences when you visit our website. We also use them to improve the overall performance of our site. You can learn more about the cookies and similar technology we use by viewing our privacy policy. By clicking ‘Accept,’ you acknowledge and consent to our use of all cookies on our website.

This site is registered on wpml.org as a development site.