As reported Wednesday, there’s a new piece of OS X malware in the wild— a Trojan Horse that changes your Mac’s Domain Name Server address. We’re already covered how to detect and remove that particular piece of malware. Now let’s turn our attention to what you can generally do to prevent such things from getting installed in the first place.
Note that this is a discussion focused on trojan horse malware packages in particular—software that pretends to be one thing, but is actually something else, typically a program with malicious intent. The general practices, however, could be applied to nearly any sort of program you download.
The things I’m going to demonstrate—with one small exception—are also Terminal-free, and require little to no technical knowledge. In short, anyone should be able to use these techniques to examine downloaded programs before installation. Note that this walkthrough is long and detailed; here’s the executive summary version:
Control-click on the installation package and choose Show Package Contents. Navigate into the various files within the installer, and look at each in a text editor. Some may open as gibberish, which indicates that they’re binaries. Close those files. For the files you can read, look for anything that just doesn’t make sense. If you find even one thing that seems weird, do not install the program.
Read on for a more detailed look at the process of examining installers.
Rule #1: Avoid untrusted sources
As I noted in my article on detecting the OSX.RSPlug.A Trojan Horse, the best thing you can do to avoid such programs is to stick with software from known and trusted sources. Software update sites such as MacUpdate, VersionTracker, download.com, and MacGameFiles are typically safe bets—especially if you stick to software for which you can read comments by a number of other users before proceeding. No need to lead the pack in this race; if someone else finds something malicious on a large site, you can bet they’ll comment on it (and more than likely, the package will be quickly removed).
In short, do not download and install software from sources that you don’t trust. Follow this simple rule, and the odds of being exposed to trojan horse applications is greatly diminished.
Rule #2: Follow rule #1
Really. I mean it. Stay away from untrusted sources. If you regularly ignore these two rules, you really should invest in some good anti-virus/malware software. It’s not perfect protection, but it’s a lot better than flying blind.
But what if…
OK, so somehow, through no fault (or all fault) of your own, there’s a disk image sitting in your Downloads folder. You’re pretty sure it’s legitimate, but you did find it on a not-well-known site, and you’d like more of a warm-and-fuzzy feeling before you take the risk of installing it. You’re not an ultra-geek with l33t Terminal skills, though, so you may think your options are limited.
I’m here to tell you that’s not the case: with just a text editor and the ability to read English (assuming we’re talking about an English application, of course), you can actually do quite a bit of snooping on your own—all without ever running the program in question, or requiring any technical skills beyond the ability to click the mouse button.
I’m going to focus today on programs that come as package installers—these are the programs that run with Apple’s installer, and many will ask for your admin password. If you supply it, you’re basically granting the program the right to do anything it wants to to your Mac. As such, these are the programs you should be most concerned about. (Regular applications can be malicious without requiring your admin password, of course, but they can’t install things in places where your user cannot do so without authenticating. A package installer with your password can put anything anywhere, and change anything it wants to.) The tips I provide here, though, are useful for looking at any sort of program you’re going to install.
To demonstrate the differences between a malware package and a normal package, I’ll be using the actual installer for the OSX.RSPlug.A Trojan Horse (RSPlug.A for short), and Microsoft’s new Remote Desktop Connection 2 beta 2 (RDC2). As you read the following, remember that the malware package was purported to be an installer for a video codec, to help you watch some online videos. Step with me now, into the wonderful world of package installers…
About packages
Package installers are a lot like applications in OS X—they’re folders disguised as something else. As such, they can be opened and explored, which is the key to avoiding malware installation on your machine. But even before you get to that point, there’s a fair bit you can figure out just by looking at the installer’s disk image mounted on your Mac—so that’s where this exercise starts, by mounting the questionable disk image.
Important note: Everything that I’m about to show you can be worked around by a dedicated malware author; there’s no guarantee you’ll always find these “tells,” but there’s one thing working in our favor—malware authors are usually interested in getting their stuff out as quickly as possible. That means they’re probably not going to invest the time necessary to do all the detail work required to disguise their tracks—so you may very well find this information useful for future sleuthing. Please don’t take any of it as a guarantee, however.
With that note in mind, now consider the two icons below, with Microsoft’s RDC2 on the left, and the RSPlug.A malware on the right.
Notice how the Microsoft disk image has a “real” name, while the malware is named simply “76.” That should be a pretty good clue that something’s not right already—very few Mac programs are named with numbers and nothing else. Obviously, malware authors could take the time to think up a phony name, but that’s the point—it takes time, so they may not make the effort. If the name of something doesn’t look right, that’s your first clue that it may not be right.
Next, let’s examine the details on the package on each disk image. Here’s a shot of each, as taken from the preview in column view mode:
There are two things here that catch my eye. The first is that—even if you accept that “76” is the name of the program—notice that the name of the actual installation program on the disk image is install.pkg . This doesn’t match the name of the disk image, nor does it seem like anyone serious about their software would release an installer named simply install.pkg. Compare that to the RDC2 image on the left, where the name of the installer matches the name of the disk image, which matches the name of what you think you’re installing.
While you’re looking at this disk image, notice the Size entry. RDC2 is 13.7MB. Not tiny, but not huge in today’s world of multi-gigabyte game demos and 350MB software update downloads. Now look at the size of the install.pkg on the right: 100KB. I took a look at MacUpdate and sorted its file list by size. Out of 1,300 programs that appear in the list, only about 50 are 100KB or smaller. I then searched on “codec,” and only two of the 23 matches are under 100KB. Most of the video-related codecs are in the 3MB to 10MB range. Simply put, 100KB is too small to be a real video codec.
But you don’t have to do all the searching I did to know that something’s wrong with the size of this bundle. Think about everything you’ve downloaded lately, and how many of them were under 100KB. Excluding text files, the answer is probably none.
So while we haven’t even really started looking at this package yet, it’s already got three strikes against it: 1) The disk image has an odd name; 2) the installation package’s name doesn’t match that of the disk image; and 3) the size is too small to be legitimate software. At this point, if this were “real life,” I’d trash this disk image immediately; it simply cannot be what it purports to be, so the odds are high that it’s something that I really don’t want to install.
Diving into packages
But this isn’t real life, this is the Web, so we’ll keep digging. By examining the contents of the installation package, you can usually find all the evidence you need to convince yourself as to the authenticity of a given program. Just keep my caution in mind—it’s possible that a well-developed piece of malware may not have any of the following “tells.” Still, it never hurts to look.
Control-click on the installer package in the Finder and select Show Package Contents from the pop-up menu—you’ve now “entered” the installer’s bundle of files, and it’s here where you’ll really discover what makes up this particular program. Here you can see both the valid RDC2 package (on the left) and the RSPlug.A trojan (on the right).
You really can’t learn much at this level yet, but here’s the important bit: Many of the files in an installer package are text files, even if their icons don’t look that way. So one way to explore is to drag and drop each icon onto a text editor, and see if you get readable text or not. I’ve outlined a few of the more interesting files in red boxes—all but the first are pure text files. Let’s take a quick look at each, skipping the first (Archive.bom) for now.
• 76.info: If you see a .info file in a package, you can probably learn a lot by opening it first. So what’s in this particular file? Here are the first few lines of the one from the 76 disk image:
Title MacCodec Version Description Its a suppa puppa desc yo DefaultLocation /Library/Internet Plug-Ins/ DeleteWarning
Line one tells you the name of the installer, but the interesting stuff is found on the Description line. If the first three strikes didn’t make you toss this program, hopefully the Description line will! “Its a suppa puppa desc yo” is definitely a sign that all is not right in 76-land. That’s strike four.
The other important line in this file is the DefaultLocation line. This tells you where the files will be installed. In this case, the listed directory is /Library/Internet Plug-Ins. This makes sense for a video codec, so there’s no useful info there. However, knowing the installation folder will be useful later on.
• Description.plist: If you can’t find a .info file, look for this file instead, as it will contain similar file. Opening this file, I found another copy of the “Its a suppa puppa desc yo” description. Strike five.
• License.txt: The 76 package includes this file, which at first glance, appears quite official:
“LICENSE AGREEMENT !
YOU SHOULD CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS BEFORE USING THIS PRODUCT. IT CONTAINS SOFTWARE, THE USE OF WHICH IS LICENSED BY LICENSOR TO ITS CUSTOMERS FOR THEIR USE ONLY AS SET FORTH BELOW. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT USE THE SOFTWARE. USING ANY PART OF THE SOFTWARE INDICATES THAT YOU ACCEPT THESE TERMS.
THE PRODUCT IS PROVIDED “AS IS”. THERE ARE NO WARRANTIES UNDER THIS AGREEMENT, AND LICENSOR DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR PARTICULAR PURPOSE.”
So what’s the problem? If you were to read the entire agreement, not once would you find a company name listed. Even in the quote above, it’s always “licensor,” which is never defined. Contrast that with any other license agreement you’ve ever seen, where the company name will be mentioned at least once, but usually many times. Strike six.
• preinstall and postinstall: These are the scripts that are executed at the start and end of the installation process. They’re the ones that actually install everything. (In the screen shot above, you can also see preupgrade and postupgrade; these are scripts that would run if you were doing an upgrade install. In this case, though, they’re identical to their “install” counterparts.)
If you’re not a programmer, you might think what you find here is useless. But that’s not the case. Open the files in a text editor, and you may find that you can actually understand some of it, or you may find things you can use to search the net. Consider this one piece of code from preinstall:
/usr/sbin/scutil << EOF open d.init d.add ServerAddresses * $s1 $s2 set State:/Network/Service/$PSID/DNS
The very first line is a unix executable named scutil. Using Google or your favorite search engine, you can look up scutil and find that it doesn’t seem to have anything to do with video codecs, so for me, that’s strike seven.
As you scan the code, look for other words that can be fed to Google to find more information; there’s a ton of knowledge out there to be found, and even with just a few key words, you may be able to get a sense of what the program is doing. It’s not guaranteed, of course, but you can’t hurt anything by looking.
The bom file
Time to revisit the first file in the list, the Archive.bom file. By now, at least for this app, this step would be completely optional, as I’ve already counted up way too many strikes for the app to be installed. But the .bom file is a potential treasure trove of information, as it contains a list of all the files the installer will install. These files may not always be named Archive.bom, but they will always end in .bom. You will have to use Terminal—very briefly—to get to the contents of this file. Here’s the easiest way to do it.
Open a Terminal window, type cd , press the Space Bar, then switch to the Finder (don’t press Return yet). In the Finder, get to the window containing the installer’s Contents folder—you may have to control-click on the installer and choose Show Package Contents if you closed this window earlier. Now drag the Contents folder into the Terminal window, and drop it.
Terminal will auto-complete the path to the Contents folder; press Return to execute the cd command. To get the contents of the bom file into a usable text file, type this command:
lsbom Archive.bom > ~/Desktop/xyzinstaller.txt
The first half of the above line runs a Unix command that reads the bom file. The greater-than sign redirects the output to a file you specify. In this case, that file is on the Desktop, and it’s named xyzinstaller.txt. Note: don’t use a name with spaces in it—it just complicates matters. Keep the name short and easy, and rename it in the Finder later if you want.
Now switch to the Finder, and open the file you just created in a text editor. Here’s what you’d see if you did this for the 76 package:
. 40777 501/501 ./Mozillaplug.plugin 40775 0/80 ./Mozillaplug.plugin/Contents 40775 0/80 ./Mozillaplug.plugin/Contents/Info.plist 100664 0/80 930 1525506808 ./Mozillaplug.plugin/Contents/MacOS 40775 0/80 ./Mozillaplug.plugin/Contents/MacOS/VerifiedDownloadPlugin 100775 0/80 24584 1275209212 ./Mozillaplug.plugin/Contents/Resources 40775 0/80 ./Mozillaplug.plugin/Contents/Resources/VerifiedDownloadPlugin.rsrc 100644 0/80 381 4223255919 ./Mozillaplug.plugin/Contents/Resources/VerifiedDownloadPlugin.rsrc.ROVE 100664 0/80 381 2963929028 ./Mozillaplug.plugin/Contents/Resources/VerifiedDownloadPlugin.rsrc.bak 100644 0/80 338 3415230991 ./Mozillaplug.plugin/Contents/version.plist 100664 0/80 471 2911002047 ./plugins.settings 100755 0/501 526 2742581597 ./sendreq 100644 0/501 1214 3210924043
Ignore all the numbers you see; the other data there is the list of actual files the installer will install. The location is what you noted earlier from the DefaultLocation line, so all of these are going in the /Library -> Internet Plug-Ins folder. Depending on the installer you’re looking at, the information provided here may or may not be useful. However, if you have installed something and want to get rid of it, you can use the information from the bom files to remove all traces of it.
One thing about this list that I question immediately is the naming: why is a plug-in being named with “Mozilla” when it’s not necessarily tied to a given browser? Remember, this is supposed to be a video playback codec, not some extension for a particular browser or class of browser. It should be named something like my other video codecs—DivX, Flip4Mac, RealPlayer, etc. The last file, sendreq, also gives me pause: what’s it sending, and why? Taken together, this is strike eight.
Optional aside: The actual installation files
So the bom file tells you what’s going to be installed where. But where are those actual files that the bom file refers to? They’re hiding inside a compressed file within the installer—typically something like Archive.pax.gz or Archive.pax. You can copy this file to another location, and then expand it (you can’t expand it in place, because you’re using a read-only disk image) in the Finder—it will handle the .pax.gz and .pax formats.
When you expand the file, you’ll wind up with a folder containing the files shown in the bom file. In the case of the 76 malware, there were three files there—the Mozillaplug.plugin (which is actually a bundle containing the other files shown in the bom file), plugins.settings, and sendreq. For many programs, these files will be binary code, which aren’t viewable in a text editor. But in the case of 76, they were text files—shell scripts—so I was able to look at them in my text editor.
Plugins.settings is a copy of the preinstall script, and it’s the code that is executed by the cron job (as described in my initial article) to insure that the ‘bad’ DNS server information is always in place. Sendreq is run only once, then deleted. It collects some basic info on your machine (surprisingly nothing overtly scary, just your processor type and machine name), and then sends it to one of the bad servers.
Analyzing these files is a bit more complex than analyzing the others, but the process is basically the same: eyeball the words, and see if it makes some amount of sense. Find keywords and get Google to help you define what those keywords do. Look for references to things that shouldn’t be associated with whatever you’re doing. In the case of sendreq, for example, there were references to IP addresses and some ‘socket’ stuff associated with network activity, which led me to wonder why a video codec needs to collect information about my machine and send it somewhere?
Wrapping it all up
At this point, I would have killed this download eight times over—typically any one strike would be enough for me to do that. But I wanted to walk through the complete process so you could gain some insight into how a non-technical type can take a look at a questionable package prior to installing it—and using (basically) nothing other than a text editor and the Finder.
Of course, the safest thing to do with any questionable package is to just throw it away and see if you can find out more about it on the Net before proceeding. But if you’re inquisitive, the methods I’ve outlined here will allow you to safely examine application packages prior to installation. Just keep in mind that nothing is guaranteed, it’s possible to realistically fake nearly everything I’ve just demonstrated, and that you could still get burned if you proceed with an installation of questionable package.
[ Senior editor Rob Griffiths oversees the Mac OS X Hints Web site. ]