Flashback is Mac malware that has recently been showing up with a vengeance. The latest version .K is exploiting a newly patched java vulnerability on OS X. F-secure recently posted about detecting and removing it from a system. In this post, I’ll cover some addition artifacts found on an infected machine and include a script to remove it.
When responding to an infected system, I noticed that in the /var/log/secure.log it included a couple of indicators of infection. The indicators below may help you detect infected users if you are using syslog for your OS X devices. Seeing a “/bin/sh” followed by the “suppressing keychain prompt” within a couple of minutes of each other that has been a solid indicator in the log. When looking through the systems, the suppressing keychain prompt did not show up in a years worth of logs until after it was infected.
Mar 31 14:17:32 K-MacBook-Pro com.apple.SecurityServer: UID 501 authenticated as user k (UID 501) for right ‘system.privilege.admin’ Mar 31 14:17:32 K-MacBook-Pro com.apple.SecurityServer: Succeeded authorizing right ‘system.privilege.admin’ by client ‘/private/tmp/Software Update’ for authorization created by ‘/private/tmp/Software Update’
Mar 31 14:17:32 K-MacBook-Pro com.apple.SecurityServer: Succeeded authorizing right ‘system.privilege.admin’ by client ‘/usr/libexec/security_authtrampoline’ for authorization created by ‘/private/tmp/Software Update’
Mar 31 14:17:32 K-MacBook-Pro authexec: executing /bin/sh
Mar 31 14:19:55 K-MacBook com.apple.SecurityServer: suppressing keychain prompt for invalidly signed client /Applications/Safari.app(658)
I also collected file system MAC times on the infected machine. You can see the malware being created .QUICKHEALXGEN.png and .QUICKHEALXGEN.xsl. Additionally you see chmod and mv accessed. This matches up with F-secure analysis.
2012 Mar 31 Sat 14:17:32
102 m.c. drwxr-xr-x 0 0 0 /Applications/Safari.app
374 m.c. drwxr-xr-x 0 0 0 /Applications/Safari.app/Contents
4643 m.c. -rw-rw-rw- 501 20 0 /Applications/Safari.app/Contents/Info.plist
20400 m.c. drwxr-xr-x 0 0 0 /Applications/Safari.app/Contents/Resources
403744 m… -rwxrwxrwx 501 0 0 /Applications/Safari.app/Contents/Resources/ .QUICKHEALXGEN.png
26168 m… -rwxrwxrwx 501 0 0 /Applications/Safari.app/Contents/Resources/.QUICKHEALXGEN.xsl
62656 .a.. -r-xr-xr-x 0 0 0 /bin/chmod
44848 .a.. -r-xr-xr-x 0 0 0 /bin/mv
Submitting the malware to virus total had poor results with only 8 out of 42 detecting it as of April 4th.
This script has several components: It checks for both types of infections discussed by F-Secure, backups a copy of the two plist files and names them .infected, prompts user if they want to clean the infection and also prompts the user to disable java in Safari. While I have tested this script on the cleanup of the Safari Info.plist, I have not seen an infection of the environment.plist. The cleanup should work, but please test it before you use it. I will not be held liable for any problems.
I have built in a simple update function that will check for a new version using the -u switch at the command line. If a new outbreak happens, I’ll try and keep it updated. You can submit bug fixes to the blog or to the email address in the script.
To run the program, unzip the download below and double click on the flashback-detect.command file. It will prompt you for your password and check to see if your infected. You can also run it from terminal using the flashback-detect.sh.
Get the script HERE.
During a recent response call, I had the perfect storm of failure. It started on Friday afternoon when we got a notice about a potential compromise on a low value system. Normally, on these systems we just hand the information off to the system admin, but we wanted to verify some information. I was armed with my trusted IR tools. Once on the system, the first thing I noticed was that the server was three major OS versions behind and running a non-X86 platform. Hmmm this is going to be interesting….
I ran my live IR script and had a massive failure on every command. I switched to my trusty version of F-response to collect MAC times on the system. F-response also failed to run on the server. Fortunately the system had GCC on it and I pulled down the source-code for mac-robber. I did not have access to another server with this OS version and architecture combination, so I had to compile the binary on server.Make failed! Thankfully, in the install.txt, it references if make does fail try make -simple. That worked, the first good news and now I was able to collect file times on the server.
Making changes to systems you are responding to is not a deal breaker, but you need to make sure that you document everything that you do and include the reason why.The rest of the volatile information was gathered by running the built-in binaries on the server. While using this method has its issues, it’s best to collect volatile data any way you can before the system is taken offline.
- No matter how well tested your documentation is, be ready for hiccups.
- This procedure had been tested many times on incidents, but never had all our contingencies failed when trying to collect data.
- It’s critical in these instances that you have experienced team members that understand the systems they are responding to.
- Compiling source code on a server you are responding is never a great option, but you should include source-code of critical tools to your response toolkit in case you need it.
Preparation, in my opinion, is the most important phase of incident response. When possible you should have well test procedures for all major tasks you preform, especially when it comes to how you collect your data. In many situations, you will get only one chance to gather the information and you need make it count. These procedures should be review on a quarterly bases, so setup a reoccurring calendar appointment to get that done today.
Having a IR CDROM with all your collection tools is critical to having a great start to a incident. I’ve previously talked about a couple freely available ones, but now I’m we are going to cover what the basic requirements that need to be met when creating your own. Why create your own CDROM? The simple answer is control. Creating your own script allows you to do what you want to do, when and how you want to do it. Additionally, you want to make sure the trusted binaries are really trusted. Installing and verifying them yourself is the best way to make sure you can trust them.
One of the hardest questions to answer when first trying to get started is, what do you need to collect from a compromised host? It depends on your policy and questions you want to answers from the investigation, but here is a list of some of the most common things to collect and analyze from a live host:
-Processes lists ( process id, user running, parent process, path of executable)
-Network stats (listening process, established connections, PID)
-List of open files
-Modify,Access,Creation times (mac)
-System logs (logs for services running, authentication and authorization)
-Schedule’s tasks and start-up items
You could run these tools manually, but this leads to inconsistent data collection. The most effective way to collect this data is using an automated script. Scripts are a great way to help reduce documentation for collecting the evidence and make data collection consistent.The data should be collected using trusted binaries, which are ran from an external source. It’s best to rename the trusted file to distinguish the difference between versions that may already be running on the system ( e.g. ls to ir_ls). The script and tools should be ran from a write protected USB or CDROM where the result are dumped to another system (smb or cryptcat) or an external drive.
Lessons learned is generally the step most people do not to complete. Many time you may have overlapping incidents with little time to document things that went right and wrong. This step is important to make sure that you improve on your experience, and prevent the same mistake from happening more than once. If you do not have a formal meeting, it’s good to keep a to-do list of things that need to be added to your collection script, new tools and process adjustments. Keep it as an ongoing list and when you start your quarterly review of processes you’ll have an action list.