Reinstall SLS saving calendar, mail & other user data

Question

Reinstall SLS saving calendar, mail & other user data

I have apparently sustained some kind of attack on the web portion of my server, whereby whenever I access it externally I get directed to a site that has an expired/unvalidated SSL certificate. I can access everything inside my network just fine, but from outside it's getting redirected to this external site. This is now affecting my calendar and mail server.

I am considering reinstalling the entire server, assuming that there is some malicious code inserted somewhere. How can I save all of the user names, permissions etc. but more importantly save the mail and calendar data that has collected in the various user accounts, and upon reinstall of the server (after erasing the disk) reassociate the directories containing that data with the user accounts? I can see the directories but they have a UUID-type identifier associated with them, and I don't see anything within Server Admin or Workgroup Manager that would allow me to point to those directories.

Is this as simple as backing up my OD settings from Workgroup Manager, then after reinstall importing those settings, then putting the directories back in place?

Thanks -

Mac OS X (10.6.7), Server

Posted on Nov 5, 2012 7:53 PM

Reply

Answer 1

Best reply

MrHoffman

Community+ 2024

Level 10

116,463 points

Nov 7, 2012 4:05 AM in response to davisfromhouston

You have two choices: you can figure out what happened and address it and work to clean up the mess that has been made (potentially including a reinstall and rolling in backups), or you can reinstall OS X and OS X Server (all of it) and (if you don't figure out what happened) get breached again.

Best case: isolated web server hackery, with no futher changes and no backdoors left behind.

Worst case: Anything on that disk is not trustworthy. Not until it's been verified. And if that system has access into your local network, the breach can be (was) extended to other systems in your network. (qv: DMZ)

Backdoors can be left in OS X files. Or in OS X Server files. In configuration data. Certainly in LDAP directory; that's an obvious spot. In web server files. OS X and OS X Server and a typical environment installs somewhere between a half-million and a million files, and a whole lot of those can be tweaked by a savvy attacker to do, um, unexpected things...

That UUID you're seeing is just the user's internal identification within OS X and OS X Server. It's merely a value that uniquely identifies that particular user. (With that UUID value generated for each user that's been created and with a new UUID for a deleted and recreated user, identifier collisions are extremely unlikely.) The UUID doesn't encode or hash or hide or mask or decrypt into anything; it's just a likely-very-unique serial number for the user.

You'll also want to get your backups sorted out. That's the easiest recovery path for these things; multiple copies of good backups, and preferably kept entirely separate from the server — a savvy attacker can insert the breach into the backups, after all. (For disaster recovery, preferably with some backups kept somewhere other than your local site, but that's another discussion.)

There's just no easy way to do this decontamination, either. Not unless you have a good and complete pre-breach backup, and can roll that in – well, after you figure out how the attacker got in, as the same attack will be repeated indefinitely.

Here's a short write-up on getting hacked.

Reply

Answer 2

Nov 9, 2012 7:38 PM in response to MrHoffman

Ok, thanks for your post MrH, it turns out that it wasn't my OSX server that was hacked but my Uverse 2wire gateway. I had been trying to switch from a personal ssl certificate that I put on the server to a signed certificate, when I noticed that an expired certificate that didn't belong to me would appear each time I went to the site on port 443. The certificate was self signed by "Mini Webservice Ltd". My suspicion was that my apache2 implementation had been hijacked and this certificate was the product of the hijacking. Having not found anything on the server despite a pretty thorough search, I resolved to reinstall everything, and hence my question.

Each time I googled the certificate issuer though I kept getting a site that listed several AT&T ip addresses, and certificate details that were identical to the one I was seeing. Here's an example: http://dazzlepod.com/ip/99.120.101.68/.

Also today for the first time I found some code in a code repository with these same certificate details in them, associated with "mini_httpd", a small web server that runs on unix appliances. Here is the code site: http://projects.plentyfact.org/repositories/entry/btoy/btoy/trunk/utils/mini-htt pd-1.19/mini_httpd.cnf?rev=55.

I began to suspect that someone had inserted this program or one like it on my router. So I turned off port 443 forwarding to my OS X server and went back to the site from an external VPN connection, and sure enough it still came up with the false certificate.

So here's what I think is happening, and why your comments helped.

The uverse router comes stock with an all numerical ~10 digit password, and the option to prevent excessive session detection is not enabled by default. So I am guessing that someone cracks the router password through a brute force attack and then installs this web server to do who knows what. I can't figure out how they did that, but I'm going to let AT&T know and cogitate on that one.

So, following your advice I did a hard reset to defaults and reboot, and immediately changed the password and enabled excessive session detection. Viola, no problem accessing 443 on my server, and my new signed certificate even works. For now.

So word to the uverse unwise - change your router password to something complicated and enable excessive session detection under Settings - Firewall - Advanced Configuration. Someone is actively putting a bogus web server on uverse boxes.

Final note - I know, you're thinking "uverse? 2wire gateway?" It's a server i use for our family and for me to learn on, and guess what - I've just learned a lot.

Reply

Answer 3

Nov 10, 2012 9:56 AM in response to davisfromhouston

uverse is a very common source of networking discussions around the Internet; AT&T has a very strange set-up with that product.

Reply

Answer 4

Nov 16, 2012 3:14 PM in response to MrHoffman

Ok, since my earlier posts I've learned more, but it's not necessarily good.

In uverse, if you use a wireless set top box inside the house, such as I do, then an application using this bogus certificate occupies port 443 and AT&T uses that opening to manage the wireless and transmitter and probably the set top box remotely. So when I rebooted/reset the router, it cleared that opening in the firewall, but it was later reestablished by the router.

So good news, it's not an external hack. And Mr. H is correct, AT&T has an odd setup. Bad news, you can't use 443 on Uverse if you have wireless set top boxes inside the house. I am guessing that if one used hard wired set top boxes this behavior would go away, and plan to test that. Or dump Uverse, still thinking that over.

Reply