Picture Perfect: How JPG EXIF Data Hides Malware
upstart writes for SoyCow7671:
Malware that hides in EXIF headers of images was reported by Sucuri a few years ago and has been known for some time, so it's not new, but we are seeing new ways of implementation. For example, a Cisco Umbrella user reported receiving a seemingly legitimate email which contained a URL to an image, that looked something like: maliciousexample.com/agagag/3egdha.jpg
When we get samples from our customers, the analysis is pretty straight forward. We closely review the document, any linked URLs or PDFs, and inspect the resources for malicious components such as macros for word documents, or web page content and domain names for phishing campaigns. In the case of the email pointing to a single .JPG, that analysis breaks down a little since it doesn't appear suspicious right off the bat. We may review the headers of the email or the domain of the link trying to identify what is malicious, but we ordinarily don't assume that the .JPG itself is the vector for malware.
[...] We began to analyze the file manually through Notepad++ and found some interesting data that shouldn't be in the file: data that looks like it might be javascript eval statements[.]
Now we're onto something! .JPG files commonly have metadata to go along with the images, textual information that can include the name of the photo or photographer, where it was taken, the time and date that the image was made, and many other snippets of useful data. Extracting the metadata of an image is easy, and in this case, it turns out to be exactly what we're looking for[.]
Look at the strange "Make" and "Model" values. The "Make" has a value of "/.*/e" and the "Model" is an eval function! It evaluates the decoded base64 string that is present. This is a big clue as to how this malware functions. If you don't know by now, it's very rarely a good idea for programs to evaluate a decoded base64 string.
[...] This is the last piece of the puzzle for us. Putting the pieces together, we can deduce the following: The malware works in stages. The first stage of the malware comes from the domain that was infected and compromised. The second stage is the search and replace function hidden in EXIF headers in the .JPG file.
[...] The key aspect here is that the code does not look malicious at all. Instead, it looks like more of a search and replace function, which is why the sandbox environments may not have detected them as malicious. Searching and replacing by itself isn't something that would be flagged. Additionally, the attacker needs to send a proper POST request, replacing the variable "zz" with malicious instructions.
[Click through to the OpenDNS Umbrella Blog for screenshots and more reading.]
Read more of this story at SoylentNews.