How a malware could infect digitally signed files without altering hashes on macOS
Hello,
Recently, the researcher Tom Nipravsky discovered a way to hide datas in a digitally signed file on Windows (and even execute these datas in some case but -I will not talk of this here- (see bottom of the page) as I don’t have any way to achieve the same thing on macOS). I wanted to find a way to do the same thing in macOS so I looked deeper into how code signatures (more specifically codesign) and .app works.
Each time you download a new file, the browser (or the app that download the file) add a special extended attribute named com.apple.quarantine. If it’s an app, when you run it, macOS Gatekeeper will fully check the file integrity and will warn the user that the file has been downloaded from the internet. You probably know that window:
After clicking on “Open”, the com.apple.quarantine flag is removed. But, if in any way the app has been tampered with or wrongly downloaded it will fail like this:
So… how to add datas inside that app while keeping the code signature intact? Well, you may laugh but there is a extremely simple way to do it. Much simpler than what Mr. Nipravsky found. Here is how I added datas to a digitally signed file in 1 Bash Line™:
The file Icon\r is supposed to hold a user-provided icon for the app. Because Icon\r is totally ignored by codesign (and spctl) this makes it possible to hide any amount of datas inside.
The Icon\r is by default hidden and inaccessible from the Finder so I reproduced the same behaviour by setting the hidden flag and copied the same very special extended attribute that makes the file inaccessible from the Finder “iconMACS@” (69636F6E4D414353401000000000000000000000000000000000000000000000)
Well, after executing the 1 Bash Line™, you can see that~70Mb of random datas have been added to the Dropbox.app:
Of course, we can put anything in this Icon file including a malware or who knows, a picture of Guy Fieri?
Here is the codesign -vvvv / codesign — display — verbose=4 / spctl — verbose — assess — type execute -v of both the original and modified app:
And here is what I get when I run the modified Dropbox Modified.app:
This trick leave signed app opens to extra invisible datas. Normally, this should be prevented by Gatekeeper like when you add regular files:
To conclude, I don’t think the icon should be ignored by codesign nor the .DS_Store (yeah, it works with that file too). In fact, I don’t think codesign should ignore a single file. The icon should be put somewhere else (maybe somewhere in the system where the full path could be in an extended attribute?) and .DS_Store files forbidden from being created in an .app.
I have opened a Bug Report and Apple will review and probably fix the issue. In the meantime, you can check by yourself if your applications contain hidden datas with a single bash script.
Cheers!
Just a note regarding self-execution: In a scenario where someone is in possession of an ImageIO exploit, he could possibly replace the app Icon with a malicious one and create a .DS_Store that will be executed once the exploit runs while keeping the .app signature clean without altering hashes. I’m not sure if this is feasible but it could be, who knows.
