T.R | Title | User | Personal Name | Date | Lines |
---|
34.1 | | PSYCHE::MCVAY | | Sun Jul 22 1984 10:31 | 35 |
| <Flame on>
I love management's response to hacking, especially when they have no
technical background whatsoever. If I read your story right:
1. A senior VP who should have known better had a nonsecure password.
How this dummy got to be VP of a bank I'll never know: you may try
to excuse him by saying that he knew nothing about computers--but
a password is the same as the combination to a vault. You can bet
that if this idiot had put his birthday on a vault combination he
would be out on the street the next day. Bankers at every level
know security--what he did was stupid.
2. The programmer's response wasn't too bright; I'm surprised he
didn't get more than a wrist-slapping. But from the story I gather
that NOTHING was done to the VP (again).
3. The kids broke in again so the whole DP staff was disciplined.
Brilliant. They got in because of bit-brains like the VP who had
unsecure passwords. That's like shooting your dog to discipline
the cat.
4. In an effort to tighten security, they put in locks, passes, and
cameras. This is another typical idiot response by uninformed (and
sometimes incompetent) management. The kids were nowhere near the
bank when the raid was conducted--did they put some software
security in place too? The story doesn't say, but based on the
rest of the story, I would guess not.
Somehow management thinks PD security, protection, and accidents are
all the fault of DP and its resident hackers. It's about time
management assumed some of the responsibility, and either went back to
school to enter the latter half of the 20th Century, or else got out
of the way of the technical staff!
<Flame off>
|
34.2 | | NY1MM::YANNIOS | | Wed Jul 25 1984 19:30 | 40 |
| I agree....the senior management at this bank had very little computer
science education. The VP was told to change his password which
he never did and as a result the poor unfortunates who were on the
systems staff got the flack. Politics at some of the banks
here in NY can get rather unfair and this is a typical example of what
can sometime happen...
...this brings me to my next story:
About 3 years ago - the Digital office in New York had a couple of
VAXes, one DECSYSTEM-2020 and about 3 or 4 PDP-11s. One late evening
while logged in on the 2020 working on a program, I noticed a user logged in
under a customer account. The user was conducting ^ECREATE commands
which are used under TOPS-20 to create new userid/directories. Finding
this rather peculiar for a customer account to be doing, I proceeded to
SPY on him using the TOPS-20 spy utility which essentially allows
a privleged person to monitor everything that is going on the
target terminal. Sure enough, this "customer" was dumping all the
userids and passwords. Somehow, he had acquired privileges. I
then issued a TALK command (sort of similar to phone...) and
politely asked him what the heck he was doing. His excuses were too
lame and so I logged him off the system and disabled all remote logins.
However, during the course of the discussion, I found out that he had
acquired the password from someone that recently left our office.
Corrective measures were taken and the alien user never again
used the new york office's system.
Moral: - change ALL passwords AFTER someone has left - even if he
was a nice guy and especially so. He might just decide
to give his old account out to all his friends.
Question: Anyone out there know of a similar sort of SPY utility
that can run under VMS that will allow a privleged user
to see what another user is doing (Maybe this question
belongs on VAXUUM::TOPSVMS??) other than doing something
like hooking up a datascope??
/Nick
|
34.3 | | NY1MM::MUSLIN | | Thu Jul 26 1984 09:26 | 12 |
| Nick, there was a utility like that written at our office by Mark
Maxson a while ago. I don't know what happened to it. In NY there are two
companies who are selling a utility like that. Both of these companies are
started by ex-employees of our office - Ben Rosenberg and Bob Pasker. The
companies are ASCE and TPS (I think) respectively. They have programs called
PSS and VAXwatch respectively (they also have something similar to PHOTO
utility on the -20). VAXwatch is available at our office (Barry has it). It
was never installed, because for a long time we couldn't agree on the
licensing issues. Now I think, however, VAXwatch will be installed if you
request Barry to do that (or is it Bill nowadays).
- Victor -
|
34.4 | | LATOUR::AMARTIN | | Thu Jul 26 1984 10:44 | 19 |
| A company named Precision Business Systems (33 Rector St, NY, NY 10006,
(212) 425-0200) advertised a program named SPY for VMS in the January
1984 issue of Hardcopy, the magazine that DEC customers turn to for
full color ads. The description is "SPY - Watch other users with or
without their knowledge; real-time or recording mode. Give demos from
remote sites!".
I had it posted on my office wall, along with the January editorial in
Hardcopy, titled "Orwell Missed By A Mile". The editorial flames about
how people have been waiting for 1984 to see whether we have to worry about
Big Brother watching our every move. The closing paragraph says:
"If HARDCOPY's 1984 debut is any indication, the eleven succeeding months
will be anything but Orwellian. How can we be pessimistic and downcast about
a year that promises so much for the DEC community?"
They obviously don't read their own ads.
/AHM
|
34.5 | | NY1MM::MUSLIN | | Thu Jul 26 1984 14:16 | 7 |
| Precision Systems Inc. is the company that is dealing with Bob Pasker
(my understanding is that PSI is a stockholder or something of the sort in
Bob's company). SPY (and PHOTO) are parts of VAXwatch...as far as I understand.
Bob demoed his products for me once before trying to sell them to Barry (who
used to be my boss). Both of them looked good.
- Victor -
|
34.6 | | TURTLE::GILBERT | | Fri Jul 27 1984 17:13 | 31 |
| A few years ago, I did such a hack. However, it only showed what the user was
typing -- there was never any great need to see what the system was spitting
back at him. It ran in kernel mode, and took a few crashes to get right.
Such a hack could EASILY be abused. Some uses are clearly immoral, and are
similar to riffling through personal subdirectories.
This hack had a few interesting uses:
1. Obviously, to see what someone was doing (we had a break-in from a
Dave D., who now works for DEC. Hi, Dave).
2. As it accessed the type-ahead buffer, it was possible to see users
passwords shortly after they logged in.
3. A nice April Fool hack was to provide typing errors for those people
who like to quickly type ahead. Just swap two typed-ahead characters
if they arrive close together. With some randomness, it was VERY nice.
4. A competitive computer game making the rounds was Perquacky. Basically,
it shows you a bunch of letters, and you try to form words from them.
(more points for longer words, up to six words of a particular length
have any value, words could be challenged, ...). The hack ran in batch,
(process name mumbleACP, so it wouldn't provoke suspicion), watching
your terminal. You could type "% letters %", and it would search a
dictionary for words that could be formed from those letters, and
broadcast those words to your terminal. Thus, your score was limited
only by your typing speed, credibility and chutzpah.
It also caught us off guard a few times while writing Bliss programs....
- Gilbert
|
34.7 | | ADVAX::A_VESPER | | Mon Jul 30 1984 10:09 | 10 |
| re: .6:
> 3. A nice April Fool hack was to provide typing errors for those people
> who like to quickly type ahead. Just swap two typed-ahead characters
> if they arrive close together. With some randomness, it was VERY nice.
gee... I'ev bene getitng al ot of thees latley
Anyd Vespre
|
34.10 | | NY1MM::MUSLIN | | Sat Aug 04 1984 10:59 | 26 |
| Recently we had a problem in a large cosmetics company that is famous
for its ... ladies selling make-up from door to door. The president and
vice-president of a department that acquired a VAX from us and a switch from
MICOM were extremely anti-DEC. I don't know how the VAX was forced down their
throat (couldn't have been the salesmanship), but there it was that hated
object right in their department instead of another lovable three-letter word.
In the beginning everything was ok. Then, suddenly, people started getting
into another people's accounts. Someone would turn on their terminal and wind
up in someone else's account. This must've been going on quietly for some
time. Those who got someone else's line would hangup and next time get their
own line. Unfortunately, one day the vice-president decided to turn his
terminal on and try out the VAX. To his amazement, when his terminal warmed up
he discovered that he was reading the president's mail. It would be an
understatement to say that all the hell broke loose. First we didn't believe
them. Then we wondered whether people just turn off their terminals without
logging off. We told them to do SET TERM/PERM/HANGUP and such things. The
problem didn't go away no matter what we did. We called MICOM and tried to see
whether there was a timing problem between the MICOM and VAX hanging up a
line. Nothing. Finally, after two or three days, we called our F/S in and they
figured it out. The president trying to reduce his expenses wired the MICOM
and the VAX with cables that didn't have enough pins for modem control...
This is not a real "hackers" story, but I thought it might be
interesting...
- Victor -
|
34.11 | | NY1MM::YANNIOS | | Sat Aug 11 1984 13:29 | 45 |
| A few years back while I was in college where we had a Univac 1110 dual CPU
system, an unusual incident occurred that caused total havok.
Univac 1100 EXEC8 operating systems allow users to "CATALOGUE/ASSIGN"
files with all sorts of different attributes directly from the "EXEC" (DCL)
command level - including INITIAL and RESERVED disk allocations. Initial
disk allocation would reserve a guarantied amount of storage on disk for the
file and reserved would simply indicate to the system how large the user
expected his file to grow. The system did not allocate this to the user.
Normally, a user would say something like:
>@ASG,<options> F MYDIRECTORY*FILE.TYP/20/100...
if I remember the syntax correctly, which would create a file for the user
with an 10 tracks allocated and 100 tracks reserved (but not allocated).
One day, a certain individual decided to say:
>@ASG,<opts> DIRECTORY*FILE.TYP/<a rather huge #>/<another huge #>...
At the time. EXEC8 did not bother to check if the initial reserve
specification was sane. However, what the operating system would do for
the user who issued this command was go ahead and give him all the disk
space he needed. If there was not enough free disk space, the operating
system would proceed to generate "Rollout" runs. These would be special
batch jobs submitted automatically by the operating system that would
cause files from the least frequently used to the most frequently used
to be rolled out temporarily onto tape due to demands on disk storage.
Because this individual specified an initial reserve specification that
exceeded the entire disk storage capacity of the system, the system proceeded
to rollout EVERYONE's files onto tape -- including it's paging/swapping files
I/O subsystem files and other disk files required for the OS to run!!
So, after the operators spent about 5 hours processing tapes, the poor system
came to a grinding hault. As a result, Univac had to be brought in to figure
out what happened. They did.
Results: 1) A couple of bugs in the operating sytsem were fixed
2) the culprit was caught and expelled from the university
(nope, it wasn't me...)
3) Univac made lots of money convincing the computer center
staff that they should all go for lots of training because
they could not afford to learn the system on their own and
allow such silly things to keep happening.
/Nick
|
34.12 | | EKLV00::CARROLL | | Thu Jan 10 1985 14:55 | 17 |
|
When I was going to college in Galway, we had a DEC-2050 and a small band
of really dedicated hackers. Among other things, they managed to stop SPY
working, hacked SYSTAT so that instead of usernames you got XXXXXX's, and
managed to dump all the passwords on the system.
They were eventually caught, and two people were banned from using the
system.
One of the two who were banned managed to hang 'ADVENTURE' onto the end of an
engineering stress analysis program where it lives to this day. (using the
'ADVENTURE' part itself requires a lot of luck/knowledge)
Ah, them were the days.
Pat.
|
34.13 | | PRSIS4::DTL | | Sat Jan 12 1985 16:36 | 2 |
| "college in galway"? Lovely. I visited the university. Galway is one of the
most beautiful places in the world (in Summer). See a recent note in Whoareyou.
|
34.14 | | EILV00::ANDERSON | | Wed Jan 16 1985 12:55 | 6 |
| Re: -1. (Galway...Beautiful...etc.)
Nicely said....
--Martin. ("Born in Galway, Living in Galway, Working in Galway" !)
|
34.15 | | 2LITTL::RASPUZZI | Michael Raspuzzi | Thu Feb 20 1986 13:02 | 11 |
| On DECSYSTEM-20 stuff:
If a user is smart enough, he can write an effective ANTI-SPY program
that won't let you see what he is doing. You also won't be able
to TALK to the user because TALK uses the same JSYS that SPY uses.
SYSTATs while not logged in can be prevented. All you have to do
is tweek a bit in the EXEC that will shut off SYSTATs from not logged
in jobs.
Mike
|
34.16 | Roll your own | LATOUR::AMARTIN | Alan H. Martin | Thu Feb 20 1986 13:29 | 7 |
| If the system staff is smart enough, they can write a SPY program that
does not use the existing facility for spying on people and thus thwart
people who think they are secure from being spied upon. When I was
in college there was no way provided to customers to spy upon users
on our KL-based Tops-10 machine, so of course the system staff endeavoured
to write their own hack.
/AHM
|
34.17 | | 2LITTL::RASPUZZI | Michael Raspuzzi | Thu Feb 20 1986 14:49 | 7 |
| I don't believe there is another way (TOPS-20 speaking) to see the
"transactions" that are occurring on a foreign terminal without
using the TLINK% JSYS (SPY uses this and only sets up a one way
link with it). Unfortunately, an unprived user can break a one way
link. It's too bad that one way links can't just stay around until
broken by a prived user. There are other ways to see what a user
is doing besides SPYing on him.
|
34.18 | Spying the hard way | LATOUR::AMARTIN | Alan H. Martin | Thu Feb 20 1986 22:29 | 4 |
| Bear in mind I am not talking about an alternate existing system call
for getting the information. These people were peeking at the TTY chunks
as they whizzed by, by mapping the monitor's memory into user space.
/AHM
|
34.19 | Big brother *IS* watching you | MARVIN::SHAND | Mike Shand | Fri Feb 21 1986 04:36 | 13 |
|
RE .-2
Most of our hackers used to run process in a fork that did a TLINK%
clear link every few seconds, thinking that this would prevent spying. However
we had hacked the monitor to (secretly) keep the link open if it had been
initiated from one of OUR terminals!
RE .-1
We used to have a program that peeked in BIGBUF to get an estimate of the
character rates on all the lines, so we could spot lines running open etc.
|