I used that all the time back in school. You'd often recognize the names that turned up, students in the same course, TAs, etc. Occasionally you'd get stuff like this:
jsmith - - - emacs cs350/assignment3.c
and it was hard to resist the urge to take a peek at what jsmith was working on. Practically no one bothered to set proper file permissions, leaving their files readable to anyone who knew how to find them.
I had to inform a professor he was running an open home directory like that. Pretty tricky to do as it implies you were looking for it in the first place.
I learned my lesson about never talking about the security flaws i found in school.
Our web access went over secured proxy servers, which determined via our windows login which services to allow or disallow us.
As our deputy rector considered himself an open IT advocate, he ensured all browsers we're installed on all machines, including Opera. Back then Opera couldn't use the Windows login to auth with the proxy server, which he "fixed" by using a pre-configured user which just had student rights.
As i'd never use opera i didn't notice it until one of my teachers tried to block me from using any webmail client as a way to transfer files to the school pc.
Trying different things i got the tip from a classmate to start opera. I was struck by a preentered login box which i was told to just hit ok. I got curious and inspected the fields. The loginname had admin in it, so i thought the password might be used elsewhere...
Well, i've seen our deputy rector on our central win 2003 server via windows remote desktop before, so i connected to it, using the user and pass from opera and logged in to an open session on the server which stored all critical school data, including grades of all students attending that school and the transfer tool to send the grades to the statewide server which would make the grades final.
As it was so ridiculously easy i got scared that someone from my class would do the same and then get into deeper trouble for actually trying to change grades or something, i immediately went to our deputy rector and told him all about it.
He banned me from using school pc's for the rest of the year and afterwards all teachers were told to keep their eyes on what i was doing on the school pcs...
Imagine if you had just changed the background picture on the server you accessed to a lolcat or something funny, and left a short text file how you got in, saying that you didn't change anything.
Even better would be to change the password, then leave him an anonymous typed note with it, which would prevent others from abusing the system.
True anonymous reporting is almost as good as whistleblower protection.
But this may be even more frightening to the person you're "reporting" the breach to, who is obviously no tech genius. Now they've been burgled by invisible elves. Even if the elves appear to have done nothing but leave behind delicious cookies and thoughtfully-written notes, it's pretty freaky to the uninitiated.
They may literally change their locks and buy an alarm system. Worse, when some idiot comes along peddling a "magical charm to ward off the bad e-criminals that lurk invisibly on your Facebook page" they'll be in a nice receptive state of free-floating subliminal panic.
The moral of this story is, I guess, is that as a solo whistleblower without institutional or cultural support all available options are bad. We are slowly educating the world's organizations - lots of sites and services these days have security officers who might understand the social dynamics of exploit reports and not be so quick to fly off the handle - but I'm sure there's room for a lot more basic training. Meanwhile, it's hard being a pioneer. ;)
I had a similar story, though not as technically amusing. In HS I noticed that our copies of MS Office allowed macros, i.e. you could run any VB you wanted. Of course, even in the horror that is VBA, you can easily run escalated privileges (e.g. installers). I made the mistake of showing one friend how to install ROMs (I just use it for winamp + a CD from home, because I was 1337 enough to have bought a $400 2X CD-RW). Needless to say, it spread like wildfire and I found myself in front of a dean and the IT director.
Thankfully, that Dean (a) liked me and (b) had a disdain for the drowning bureaucracy that was public high school. So, I explained everything, explained how it was because the IT guy (who was 3ft away) was incompetent, and said I had no intention of hurting anybody. I apologized for not reporting it directly.
That probably is what helped me get into IT/ITsec, because I wasn't punished for being curious.
That's why shared hosting accounts are so bad. The Unix security model isn't designed for hosting a bunch of unrelated websites on the same box. Why should I even be allowed to make a file world readable or run the w command on a web host on which the users don't even know each other?
People should really be using VPS now that they are so cheap.
Edit: After reading the answer to this comment it seems my fear of shared hosting may not be justified. Obviously good sysadmins know how to properly secure these systems.
Still it seems that when Unix was designed it was expected that people would chat with the talk command, see who was online with the who command, and intentionally make files readable by other. With web hosting you really don't want that. You shouldn't even be able to see what other accounts there are on the machine. I was probably wrong to say that shared hosting accounts are "bad" but it doesn't seem like a perfect fit either.
The Unix security model is designed for mutli-user hosts. Shared hosting works very well under Unix, iff the admins know what they are doing. Why do you think that before virtualization got popular people were using shell accounts, chroots and BSD Jails for their webhosting/IRC/... needs? Why do you think we have CGI, SuExec, ...?
I won't deny that VPS are great, but a properly set up shell server will allow you to do many of the same things a VPS can do.
> The Unix security model is designed for mutli-user hosts.
Reminds me of the story of RMS complaing about evil admins that were restricting root level access. The views on computer users and security were quite different in the early days of UNIX.
RMS' views might have been different. In a little thing we call actual reality the sysadmin is an employee hired by the same people who bought the system (no small investment in those days) to maintain it, and I don't think any reasonable person has ever denied that.
I built a shared hosting platform on Linux once. The "home" directories for each user were owned by the Apache user, and readable by the user the site ran as. IIRC, something like this:
drwxr-x--- and "www-data:mike"
The htdocs directory inside was writeable only by the "mike" user in this case.
Of course, all cgi/php ran as the user account, rather than as the Apache user.
So even if the user screwed up the permissions and created globally read/write files, there was no way that any other user could access them.
Oh man, bugging people in pine with talk was the worst/best. Kids, it was a world in which someone could destroy your email session and spray characters all over the screen just by IM-ing you. Everyone knew how to do it, and everyone checked in on one another all the time (using who or w of course), so the odds against your completing a long email and sending it before someone wrecked your pine session were pretty long. The really hardcore kids figured out how to compose emails in pico or vi and then mail them from mail.
A year or two later everyone started using gopher and Mosaic and Eudora instead, which was obviously way more civilized.
We would figure out what /dev/tty our friends were using and echo a ^L into their VT100. I remember one friend had a whole ASCII-art picture that he would spray into a tty and really freak them out.
The AIM comment really stuck out to me as strange. AIM is fine, but hardly special relative to its many competitors. His link goes to a preview page for (I guess) a new version of AIM with fancy things like twitter integration, but I don't really see that mattering much.
If anything, to throw my anecdotal evidence into the ring, AIM was big in my middle- through high-school experience, but most of my friends have dropped it as adults. Its uses back then were "hey, saw you were online, let's chat" and occasionally leaving short-term messages not worth an email or a call. It's have been replaced by facebook chat and texting for those uses respectively. I'm not a fan of facebook chat compared to an AIM client (desktop-based or web-based), but what're you gonna do?
Won't 'ps aux' show them anyway? I imagine there are some restricted userland tools available for shared hosts to use, but having just checked on a couple of my personal machines, it'll display arguments even for processes started by root.
In the past I've wrapped things in a trivial shell-script to hide their args (and messing with $0 from a perl script can probably be used for fun & games, if desired)
I personally think the UNIX security model is broken for multiuser, so I basically run systems in dedicated security mode (as does ~everyone else; single-user laptop/desktops under OSX or Linux, and servers dedicated to a single user/task/application, or at least VMs dedicated to a single user/task).
UNIX local system security is still nice as a belt-and-suspenders thing, but once someone's on a box, assume they own it. The only exception is some special magic stuff like Hardware Security Modules.
I was appalled when an application - one we paid a lot of money for - did just that by default.
Which is funny because their app sits on top of WebLogic which provides an easy-peasy way of encrypting the passwords. The vendor either doesn't know enough about WLS to make it happen or they don't care.
It's kind of crazy how open the old unix systems used to be. Even when I was in college in the mid 90s almost everything was still on and open. w, talk, finger, rwho, even write. Windows was almost as open for a while, it took a while for the messenger service to be disabled by default.