Discussion:
Free PDF from the ACM (Assn of Computing Machinery): Who Must You Trust
(too old to reply)
Thad Floryan
2014-06-08 02:38:10 UTC
Permalink
Raw Message
This was cited in today's 7-June-2014 Slashdot Newsletter:

http://queue.acm.org/detail.cfm?id=2630691

And a 14-page 184kB PDF of the article is available here:

http://portal.acm.org/ft_gateway.cfm?id=2630691&type=pdf

Excerpt from the l-o-n-g article:

[...]

TRUST ON THE INTERNET

Walking around a physical neighborhood, you can gather a lot of
information if you are open to it. On the Internet, it can be a very
different story. Imagine an office with a single PC, used in the
morning by Albert and in the afternoon by Betty. Each has a different
account and logs out at the end of the shift. Albert and Betty work
from the same physical place, and from the same IP address, but they may
have very different experiences on the Internet, depending on what they
do.

Extend that to a data center hosting many companies. Each company's
servers may be separated by only a few feet, but how they experience the
Internet, and how the Internet experiences them, can vary widely. The
physical distance between the servers is irrelevant. What matters is
the hardware they are composed of, the operating systems that run on
them, the application server software, and the configuration data for
each of those things, plus all of the utility and ancillary software
needed to support and maintain them. The quality and quantity of users,
as well as administrators, also matter a great deal.

HEARTBLEED

In spring 2014, a bug in the open-source package OpenSSL became widely
known. The bug, now known as Heartbleed (http://heartbleed.com), had
been present for some time, and may have been known by some, but the
full disclosure of the problem in the OpenSSL package came to the
public's attention only recently. OpenSSL had been reviewed by many
experts and had been a well-used and trusted part of the Internet
ecosystem until that point. As of this writing, there is no evidence
suggesting any cause other than a programming error on the part of an
OpenSSL contributor.

On the morning before the Heartbleed bug was made public, few people
were familiar with OpenSSL and they hardly gave the functions it
provided a second thought. Those who knew of it often had a strong
level of trust in it. By the end of the day, that had all changed.
Systems administrators and companies of all sizes were scrambling to
contain the problem. Within just a few days, this obscure piece of
specialized software was at the top of the news cycle, and
strangers—perhaps sitting in outdoor cafes at tables they had reserved
with their house and car keys—were discussing it in the same tones with
which they might have discussed other catastrophes.

SYSTEMS ADMINISTRATORS

At the heart of everything that works on the Internet are systems
administrators. Sometimes they are skilled experts, sometimes low paid
and poorly trained, sometimes volunteers of known or unknown provenance.
Often they work long, unappreciated hours fixing problems behind the
scenes or ones that are all too visible. They have access to systems
that goes beyond that of regular users.

One such systems administrator worked for the NSA (National Security
Agency). His name is Edward Snowden. You probably know more about him
now than you ever expected to know about any sysadmin, even if you are
one yourself.

Another less familiar name is Terry Childs, a network administrator for
the city of San Francisco, who was arrested in 2008 for refusing to
divulge the administrative passwords for the city's FiberWAN network.
This network formed the core of many city services. According to
reports, Childs, a highly qualified and certified network engineer who
designed and implemented much of the city's network himself, was very
possessive of it—perhaps too possessive, as he became the sole
administrator of the network, claiming not to trust his colleagues'
abilities. He allowed himself to be on-call 24/7, year-round, rather
than delegate access to those he considered less qualified.

After an argument with a new boss who wanted to audit the network
against Childs's wishes, the city's CIO demanded that Childs provide the
administrative credentials to the FiberWAN. Childs refused, which led
to his arrest. Even after his arrest, Childs would not provide
administrative access to the network. Finally he relented and gave the
mayor of San Francisco the access credentials, ending the standoff.

His supervisors claimed he was crazy and wanted to damage the network.
Childs claimed he did not want to provide sensitive access credentials
to unqualified individuals who might damage "his" network.

In 2010, Childs was found guilty of felony network tampering and
sentenced to four years in prison and $1.5 million in restitution for
the costs the city incurred in regaining control of the network. An
appeals court upheld the verdict.

[...]
sms
2014-06-08 13:59:00 UTC
Permalink
Raw Message
Post by Thad Floryan
Another less familiar name is Terry Childs, a network administrator
for the city of San Francisco, who was arrested in 2008 for refusing
to divulge the administrative passwords for the city's FiberWAN
network. This network formed the core of many city services.
According to reports, Childs, a highly qualified and certified
network engineer who designed and implemented much of the city's
network himself, was very possessive of it—perhaps too possessive, as
he became the sole administrator of the network, claiming not to
trust his colleagues' abilities. He allowed himself to be on-call
24/7, year-round, rather than delegate access to those he considered
less qualified.
At one company I worked at, they laid off the network administrator of a
Novell Netware network. She wanted to debrief them on how to do things
and provide them with the administrative passwords but they insisted
that they didn't need her to do that and walked her out of the building.

Then they started calling her about how to get into the network. She
explained that she was no longer employed by the company and thus she
was unable to provide any service but offered to come back as a
consultant for a few hours and provide them with the credentials. They
refused. They rebuilt their network from scratch somehow.

The password was "layoff."
Jeff Liebermann
2014-06-08 23:27:56 UTC
Permalink
Raw Message
Post by Thad Floryan
Another less familiar name is Terry Childs, a network administrator for
the city of San Francisco, who was arrested in 2008 for refusing to
divulge the administrative passwords for the city's FiberWAN network.
This network formed the core of many city services. According to
reports, Childs, a highly qualified and certified network engineer who
designed and implemented much of the city's network himself, was very
possessive of it—perhaps too possessive, as he became the sole
administrator of the network, claiming not to trust his colleagues'
abilities. He allowed himself to be on-call 24/7, year-round, rather
than delegate access to those he considered less qualified.
All that shows that he didn't give a damn for "his" network and that
he only cared about himself.

At about the same time, my health was not in the best condition. There
was a very real possibility that I might be indisposed. I would
gladly have passed responsibility for the various networks I
maintained to a backup admin, except that there was none. To insure
continuity, I placed all the important information, including topology
maps, security info, passwords, kludges, and potential pitfalls in two
sealed envelopes. One went to the company CEO. The other went to a
trusted friend (who knew nothing about computers).

Roll forward about 2 years, and much of the information had become
obsolete and erroneous. I asked for the envelopes back, to be
replaced by a later version. I demanded the old envelopes back before
I replaced it with a later version. That went fairly smoothly except
at one company.

Inside the envelopes, I had placed a sheet of sensitized photo paper
as part of a "stiffener". With a few darkroom chemicals, I could
determine if the envelope had been opened. I would have used paper
sensitized with UV copier detection ink, but I couldn't find any at
the time. At this company, not only had the envelope been steamed
open, the contents copied, and resealed, but a document vaguely
resembling a badly written last will and testament was added. It
pronounced one of the clerks to be my heir apparent and to be given a
trusted position. Syslog, utmp, and wtmp showed that some of the
passwords had been tested, but apparently nothing was changed. I
don't want to divulge what happened after that.

Incidentally, the worst security problem I had to deal with was a
company IT admin, who found it necessary to delegate root passwords to
contractors, such as myself, and then conscientiously changed the
password after it was no longer needed. The problem was that he often
did it in my presence, immediately after the job was done. I recorded
a video of him typing in the new password (twice), and played it back
to reveal the password. Finger hacking at its best. I also produced
a report of when someone logged in as root, and from which vterm,
which showed that I wasn't the only person who knew the trick. Despite
my warnings, this IT admin continued the practice. They mercifully
transferred to another department, where it was no longer my problem.

Being trusted also has its downsides. One of my customers from the
mid 1990's had me listed on an insurance audit as the "security
administrator". The problem was that I hadn't done work for them
since about 2002, when they stupidly outsourced all their IT to a
company based on the east coast with tech support in India. While
security was no longer my responsibility, I continued to be listed as
the responsible person. I treated it as a joke until they had a major
security breach and the investigators phoned me shopping for a
culprit. Since I could potentially be incriminating myself, I refused
to say anything useful until I talked to my attorney and to the
current IT people. That put me at the top of the suspect list. The
problem was that the outsourced IT company didn't bother to change any
of the server or router passwords, and that my ancient list of
passwords was still mostly valid. Even added, replacement, and
upgraded servers and routers used the same old passwords. I managed
to convince both the police and the insurance company that I wasn't
involved, but it wasn't easy.

After that incident, I planned to adopt a scorched earth policy, where
after leaving a company, I would threaten to publicly publish the
passwords on the internet if they didn't change them. That would
probably be a bad idea, but it sure is tempting.

Of course, I'm no paragon of virtue or security. I'm the keeper of
the passwords and LAN for the local radio club. Due to temporary
insanity, I placed the unencrypted password file (named passwords.txt)
in the root directory of my publicly accessible web pile and forgot
about it. That was long enough for someone in Nigeria to find it,
play with a few logins, change the Skype password, and then engage in
a Skype chat demanding money for the new password. Oops. It took me
a day to change all the other passwords, recover a few accounts, and
get Google cache to delete it. It could have been much worse. Now, I
don't even trust myself.
--
Jeff Liebermann ***@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Mike Stump
2014-06-09 19:03:35 UTC
Permalink
Raw Message
At this company, not only had the envelope been steamed open, the
contents copied, and resealed, but a document vaguely resembling a
badly written last will and testament was added. It pronounced one
of the clerks to be my heir apparent and to be given a trusted
position.
I hope the initials were DA... Society is better off if people like
that have a record, as a warning signpost for the future employers,
that the person maybe not should be put in a position were trust is
required.
Incidentally, the worst security problem I had to deal with was a
company IT admin, who found it necessary to delegate root passwords to
contractors, such as myself, and then conscientiously changed the
password after it was no longer needed. The problem was that he often
did it in my presence, immediately after the job was done. I recorded
a video of him typing in the new password (twice), and played it back
to reveal the password.
Gosh, I was brought up with a different set of ethics, and they are,
someone types a password, you turn your head physically. At times I
might not, but, then I don't put into memory anything I see. I'm the
sort of person that you can remote hands me and use a root password
and I still won't know it. Just etiquette in my book.
After that incident, I planned to adopt a scorched earth policy, where
after leaving a company, I would threaten to publicly publish the
passwords on the internet if they didn't change them. That would
probably be a bad idea, but it sure is tempting.
Yes, very bad idea. I'd do this instead, rotate the passwords such
that you just don't know or have the new passwords. Brownie points if
the system to do the rotation is secure and locks you out by design
when you press the rotate now button. Or, two factor, design the
system so that it is secure even when the passwords are known by all.
For example, that password only works in this locked room that is only
openable by current IT staff or only works when a current IT staff
authenticates to the system first. Better if you can design a system
that requires a per user and then securly log that and have that
associated with the root password use. Then, when you leave, the
defense is, but I no long have the key to the room, or, did you check
the auth log to see which user typed the root password yet; I can tell
you where it is. The usual auditor will accept that, and to prove
there is an insecurity in _that_ system, they then need to pull in a
much higher priced security auditor, that one can then determine that
what you said is true, and that you could not have done it. Yes, this
means, no back doors, no secret ways in. You want that, put it in a
open in case of emergency and put in CEOs safe. Someone gets locked
out, they call you, tell them to go to CEO.

Also, for a cold call on the phone, I would say, I'm sorry, but I am a
security minded professional and I can't talk to you at all without
first validating who you are and what amount of data the company will
allow me to divulge to you. Heck, I don't even allow people I do
business with to social engineer data out of me, they call me, and
then they want me to prove who I am. No dice, I tell them, they
called me, and they have to prove to me who they are, before I will
prove who I am. I find it amazing that people just expect to be able
to call me any get sensitive info out of me.
Now, I don't even trust myself.
:-) The reality is that computers can and will be hacked, and as time
goes on, more and more will get hacked. The insanity is to assume
that any computers or networks are secure. One danger in life is
someone thinking or assuming they are secure. I see a hacking attempt
came from you; you explain, no, it came from my computer.

For example, I bought a LG smart TV recently, not cause I wanted it,
but because it is what the store sold. It wanted to be on the
network, so I let it. I know enough to know the TV spys on us, and is
insecure and will always remain so unless a hacker secures it, usually
they don't. The danger is, people doing bad things from from my IP
address (thanks NAT), and me somehow having to pay the price for
having bought the TV. Oh well, life goes on.
David Kaye
2014-06-10 03:57:18 UTC
Permalink
Raw Message
Post by Mike Stump
Gosh, I was brought up with a different set of ethics, and they are,
someone types a password, you turn your head physically. At times I
might not, but, then I don't put into memory anything I see. I'm the
sort of person that you can remote hands me and use a root password
and I still won't know it. Just etiquette in my book.
I'm that way myself. Even within a customer's presence, if I have to use a
password once I promptly forget it, and if I need it again, I ask again. As
a rule I do not write down customer passwords, unless they've specifically
told me to do so. More than once I've had a customer call me frantic that
they didn't know their password for something. Well, if it's Windows, I
have password removal tools, and for a simple router I can reset, both of
which I charge for. But beyond that, well, they're SOL.




---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

Loading...