Terminal Challenge - Yara Analysis
This is terminal challenge “Yara Analysis” in the 2021 SANS Holiday Hack Challenge (https://2021.kringlecon.com/). Objective:
HELP!!!
This critical application is supposed to tell us the sweetness levels of our candy manufacturing output (among other important things), but I can’t get it to run.
It keeps saying something something yara. Can you take a look and see if you can help get this application to bypass Sparkle Redberry’s Yara scanner?
If we can identify the rule that is triggering, we might be able change the program to bypass the scanner.
We have some tools on the system that might help us get this application going: vim, emacs, nano, yara, and xxd
The children will be very disappointed if their candy won’t even cause a single cavity.
This challenge was all about modifying a binary to bypass Yara rules (https://github.com/VirusTotal/yara). By their on definition,
YARA is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of >malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a. rule, consists of a set of strings and a >boolean expression which determine its logic.
The challenge description names of simple tools like text editors and xxd to solve this challenge. This told me that there wasn’t going to be anything to fancy other than byte manipulation to solve the challenge. The first step I took was to simply run the binary.
This output suggests that Yara rule number 135 is being triggered. There was a file yara_rules/rules.yar which contained an ordered set of rules.
snowball2@8c75ea42d787:~$ vim yara_rules/rules.yar
This was triggering off of the word “candycane”. So, I used vim and xxd to convert the binary into its corresponding hex representation using vim command “:%!xxd”.
The hex representation for candycane is 63616e647963616e65. So, I changed 63 to 64 to make the string become “dandycane”
Revert back to binary with vim command “:%!xxd -r” and “:wq” to save.
Re-run the application
Now we are snagging on rule 1056. Let’s take a look at that:
So we see that it is looking for 2 strings that are represented in hex - “6c6962632e736f2e36” and “726f6772616d2121”. Let’s open the executable back up in vim and convert to the hexadecimal representation using “:%!xxd”, and do a search for those values
There are two strings. $s1 (6c6962632e736f2e36) is the hex representation for “libc.so.6”. This is a shared library object that the application depends on for execution so we cannot alter that. $hs2 is the hex representation for “rogram!!”. This we should be able to safely change and not alter program behavior. The important note about yara rule 1056 is that the condition is “all of them”. This means that both $s1 and $hs2 must be true. So, as long as we can make one of those conditions false we can bypass the rule.
After making the change, converting back to binary (:%!xxd -r), saving, and re-running the program we get.
Rule 1732 now. Let’s take a look
There is a lot going on here. But if we look at the condition:
We see that 3 things need to be true, and therefore only need to defeat 1 of them to bypass the rule. The easiest of those three was the filesize check. We can easily pad the binary with null bytes to make it larger than 50kb
Re-run the app, and we have it!