Don’t Panic -- the saga continues
OK, it looks like this is going to be an ongoing saga, with lots of interesting information and things to be learned about Internet security in general, and Macintosh Internet security in particular.  In our first “episode,” it was disclosed that a report had been made about an item forwarded to a security mailing list from another list in which a Macintosh user indicated that his Mac had been infected with a purported virus.  Got that?  It was also disclosed that the main thing to do was not to panic.
All of the above has so far proven to be correct: the report, the forwarded item, the original item, the infected Mac and the not panicking.  The infected Mac?!  If that’s really correct, shouldn’t there be some panicking?  Read on...
First, kudos again to Macintouch for their following this issue so closely and with such immediacy. Today’s Macintouch report (search for “Linux.RST.B”) pretty much confirmed everything in our first episode, but added a lot more detail.  In particular, the actual infected user wrote in, removing at least two levels of indirection and providing lots more information. There was also an interesting contribution from a reader who may have been indirectly associated with the hacker responsible.
To address the most pressing issue (infection but no panicking), the infected user confirmed that he’s pretty sure that the infection was not caused by a virus.  Panic would only be appropriate (well, even then, not really) if the infection had been caused by a Mac-attacking virus, which could potentially spread to other Macs. In this case the infection was almost undoubtedly caused by an unfortunate combination of:
  1. 1. mistakes by the user and his daughter
  2. 2. possible mistakes by a third party
  3. 3. a specific, one-time malicious act by a hacker.
It’s going to take a while, and a number of blog entries, to go through the whole thing, but let’s get started:
The presumptive infected user (remember, we are talking about the Internet -- you can pretty much never be sure about anything) says that he is “>95% certain” that the malicious application was “planted” on his machine via SSH (called “Remote Login” in the Sharing panel of Network System Preferences). He goes on to describe his home setup, and how he has his home router configured to allow SSH access (apparently from anywhere on the Internet) to his home machine (which apparently either does not have a personal firewall running on it, or has Internet-wide SSH access allowed through that firewall).   He details how the SSH log shows a single, successful access to his daughter’s account over SSH, with no unsuccessful access attempts, and logically concludes that someone must have obtained his daughter’s account name and password on that machine and used that information to log in as her.  (An added clue he doesn’t mention: the hacker would have also had to obtain that machine’s, or actually the router’s, IP address).
All of this makes sense, but the rest is speculation.  The user speculates that his daughter used the same account name and password on some Web site that she went to and perhaps it was “snooped” or “phished” from there (more on snooping and phishing in a future entry).  Regardless, somehow the information (including IP address) was obtained and used to log in via SSH and implant the malicious application on the user’s Mac.
The user goes on to state that “fortunately” his daughter’s account was one without admin privileges.  If so, this was a very smart move on the user’s part, as the damage could have been a lot worse otherwise.  However, if this was the case, it’s not clear how the hacker was able to implant the malicious code in such a way that it ran, presumably across reboots, under the user’s account where he found it.
A second Macintouch reader’s report suggests a way of allowing SSH access to a Mac with improved security.  There are actually, however, in our humble opinions, a number of additional, more basic security measures that should be taken first, which we’ll get into in future blog entries.
A third reader’s report is quite interesting and illuminating.  That reader is (claims to be) an administrator for the IRC (Internet Relay Chat) network whose domain name appears in a file on the compromised machine.  As we mentioned in the previous blog entry, IRC is often used by hackers for doing and communicating bad things.  It is good to see this administrator wanting to get involved in helping to bring the perpetrator(s) to justice (or at least get them kicked off his IRC network).
Hopefully that’s a good overview of the current state of things.  In our next episode(s), we’ll try to point out what could have been done to prevent this sort of occurrence, and what lessons can be learned from it, as well as bringing you up to date with related events as they continue to unfold (which they usually have a way of doing).
Tuesday, February 14, 2006