On Sunday, I encountered a break-in on an Xserve running OS X Leopard Server 10.5.2. All Apple-issued fixes had been applied. I cannot locate the vector of intrusion, but following the break-in I noticed the following: Kerberos authentication was disabled, making the system extremely slow to respond to LAN-based secure shell (ssh) initiation requests. Screen sharing sessions would not connect at all. However, Server Admin was fully functional All e-mail was down A launch script for Communigate Pro 5.2.x had been placed in /System/Library/StartupItems, causing Postfix and Cyrus to abort on launch after logging that SMTP, IMAP and POP ports were already opened. All of these services answered with Communigate Pro’s greeting rather than Postfix or Cyrus The StartupItems launch script was removed after Communigate Pro was successfully launched Communigate Pro’s HTTP administration ports were not open at either their default TCP ports or any other listening ports Communigate Pro reinstalled itself when the contents of its configuration directory were deleted Several inbound messages from Eastern European senders were addressed to the recipient pw@mydomain.com. This account did not exist in Postfix prior to the attack Command-line searches for Communigate’s distribution tarball and executable were unsuccessful until I interrupted the reinstall process prior to completion No listening or established TCP port connections were listed by netstat Postfix SMTP logs were stuffed with relay attempts (far more than usual) for days prior to the break-in Persistent ssh dictionary attacks preceded the break-in and the period following my blocking of external access. No successes were logged (not surprising) Fortunately, I interceded before the intruder managed to crack my server into acting as an open SMTP relay. It is possible that my server is wired as a DOS bot, but I doubt it (see below) The intrusion was only active for one day. However, the intruder was able to obtain periodic intelligence on my actions to thwart his efforts. This was evident in the fact that while I was investigating the cause, the passwords to the two privileged accounts on my server were altered System configuration files were not altered in any obvious way, and my server is apparently restored to normal function after this response: a) I shut down both WAN ports; b) I changed the root password to the serial number on a $2 bill I received as a high school graduation gift; c) I emptied the Communigate Pro configuration directory and applied ACLs that made it inaccessible except to a freshly-created user with an obscenely complicated password; d) I removed the Communigate Pro StartupItem; e) I wiped out the persisted keys for ssh It’s my suspicion that my system was placed under limited remote control via exploitation of a vulnerability, probably a manufactured one as no reported exploit exists, in Communigate Pro that allowed an attacker to submit very limited commands via SMTP and/or POP3. I think he was flying blind, unable to see the results of the commands he issued, and he therefore made rather slow progress. It was sloppy of him to change my administrative passwords while I was logged in. If I had missed his presence prior to that, that action would have given him away.How he injected Communigate Pro into my system in the first place remains a troubling mystery. I’m fairly confident that his original exploit and remote control vectors have been disarmed. Now it falls to me to discover any backdoors he’s left behind. There is no sensitive data on this server, and it is not gatewayed to the rest of my network. Rather than reinstall the OS, I’m leaving my server on-line as it is, with all logs set to debug and privileged accounts disabled for non-console login, to see if the attacker has established another way in.I don’t have time right now to do more than this. Ironically, I’m doing a review of Xserve. This event does not color my opinion of Leopar or Leopard Server. I used canned OS X tools and methods to shut down the attack, so I feel the system is adequately armed to foil an attacker. I expect that the original vulnerability was of my own making. Software Development