October 24, 2002
The Evolution of Computer Security - Part II
The Evolution of Computer Security - Part II
A historical perspective of security, hackers, and threats since 1988
The Remediator Journal interviews David Barnhill, University of Kansas
Academic Computing Technical Services
Imagine a time without viruses, back before 1988: when "security" wasn’t muttered in the same breath as "computers;" when security was more of a problem for mainframes at high security organizations. Since that time, much has changed.
The Remediator Journal continues the two-part interview with David Barnhill, Senior System Specialist of University of Kansas Academic Computing Technical Services, who discusses the history of viruses and worms and how hacking and security has evolved since 1988.
The Remediator: You've been involved with computers before the Web became a hot property in the early to mid-'90s. How has Internet security evolved from before the '90s to present day?
David Barnhill: Before 1988, there was little or no security on the Internet. Even after the "Morris worm" of 1988, security was not a watchword. Guest logins were enabled, anonymous access for uploading files was the norm, and few understood the steamy underside of BITNET as it became the Internet. In the rush to establish networking across the nation’s universities, people tried to put as much information out there as possible. We needed security; we just didn’t know we needed it, yet. We hadn’t had any incidents and CERT (Computer Emergency Response Team) was but a newly formed organization.
In the winter of 1989, I received an email from Japan, which was quite exciting, since I had never gotten an email from Japan before. It was an interesting note, and luckily in excellent English. It was adamant that I should stop stealing documents and code from computers at a prestigious Japanese engineering institution. This information had economic value; there were patents involved, not just someone’s thesis being pilfered.
I, of course, protested my innocence and began trying to figure out what had happened. The trail led the fellow from Japan and me through several equally famous engineering research institutions here in the US, and back to Switzerland. We were proud of how clever we were back then: he and I lurked and posed as hackers. We were able to initiate talk sessions with the cracker. I caught some log entries before the cracker could erase them, but he quickly saw through us to realize his cover was blown and vanished forever into the ether(net).
The Remediator: How did he do it?
DB : He used a guest account with no password. It was an academic system intended as an open sandbox for staff to gain UNIX experience. Yes, we were that open and trusting once.
At that proto-Internet stage, professional industrial espionage over the Internet was what I saw only once. There weren’t spammers and script kiddies or worms (of any real significance) yet. You had local and occasional remote breaches from bored engineering students, but they were of little consequence unless they broke something.
Attacks usually involved a guessed or swiped password; few people had the resources to try brute force. In general, attacks through the network from beyond the border were rare. The Internet was a gentle place with a lot of dreams for new information exchange and the advancement of science.
Attacks were mainly local until 1993
Local attacks continued to be the norm until about 1993. Students with accounts on a box would hack into a friend’s account, in the rare instance of an attempt to change a grade with a stolen password. In response, measures such as shadow passwords and directory permissions were instituted, under the rubric of C2 security. The big boys with Department of Defense (DOD) contracts used TEMPEST-hardened machines (such machines are difficult for others to pick up electronic signals through emissions unless within one meter, meaning it was difficult to steal the information from such machines), but they were rarely connected to the backbone. At this time, the first generation of script kiddies appeared. When you caught them, the kid did not know much, manipulated by a chat room acquaintance into the activity.
People still gave out login information so a new friend could "put a neat file in his directory." From the administration standpoint, this was a local exploit of a local user. Even though the hack had come from the net, you were left with a kid holding the bag and nothing to go on. The student was spanked and sent to sit in the corner. I still wonder how many of these breaches were a cover for industrial espionage, once a box had been compromised, but of course the logs were the first thing to go. In response to this issue, which was too rare to be remarkable (I don’t know of any incidents on the campus), centralized logging began to develop.
Very few of the "Well Known Service Ports" were closed, so the vectors for discovering and attack were broad, and if you could get authenticated as a user, you could do lots of things, beginning with pulling passwords and spending a leisurely day of brute force cracking. In a matter of hours, you had rooted through the whole system. The credulous kid not only multiplied the number of attempts and potential for success for the bright lad who wrote the code, he or she doubled as a mark who would take the fall if the compromise was discovered. Bots, very mild spam traffic, and perhaps a virus every week, were the biggest concerns.
"Security through obscurity" was fashionable. Outside the military installations, any security was an afterthought as everyone was rushing to establish, not restrict, the scope of their networked computing.
In the late ‘90s, external attacks accelerated
As we hit the great explosion of the mid-to-late 1990s, changes accelerated. For example, in 1997, I was whacked hard by an early script kiddie/pro combination, again a UNIX system pre-shadow passwords. I got "zero day’d" (a Trojan) with a Linux box. Lucky me. Wrappers were a real advance, and used to try to create an audit trail of connections from external sources. Remote logging facilities using centralized servers like Polycenter Console from DEC emerged. Ports began to be closed off — talk, finger, UUCP — but everyone still had anonymous FTP servers, gopher servers and the like, the intent was to make everything available all the time. By the time the decade ended, things had changed dramatically. FTP, Sendmail and other servers became locked down services, Chrooted (UNIX command to make the root directory) into lock boxes to limit the damage on the UNIX side. Bless its heart; the VMS operating system remained secure, and not just through obscurity.
By 2003, Microsoft monopolized the desktop
Another change was the advent of the Microsoft monopoly on the desktop. Universities were heterogeneous in the early days of the net. Due to an okay TCP/IP stack for the Mac, there were more Macs online than Microsoft boxes. Microsoft was just beginning to make real servers, but already they were targets. Security got worse and worse every few months, a kind of Moore’s law corollary, though the predicted collapse of the Internet still doesn’t happen for Bob Metcalf (developed Ethernet for connecting computers in a local network). By the fall of 2003, networks began to be so inundated by spam and worm traffic that services actually buckled under the strain of packet loss, and the effect of these worms was cumulative.
Following a year of chaotic patching, the focus shifted to protecting the Microsoft infrastructure at the desktop and server levels. Patch management became a huge issue, because organizations didn’t know if the vendor had tested their configurations, or what would break if they hadn’t. While doing a triage on the patch system, the question was asked, "Is there an exploit in the wild? Is it confirmed? Or do we have time to test it?"
This last year, the Wintel RPC and buffer overflow combo has been the most exploited and problematic. With these new mailbots, the impact of one unpatched 2.4 GHz machine on a network can be staggering.
The proliferation of computers in dorm rooms has had a huge impact. Labs of computers have been replaced by individual machines in students’ rooms. Five years ago, we would have discussed "WAREZ," (cracked game or application) and the virus threats and improprieties of software piracy. Now, there are whole sub-genres of piracy for video, audio, and software, with new sub-genres of keyloggers and other spyware masquerading as user-friendly software for P2P (peer-to-peer). Couple this with machines of unknown provenance, peer pressure to download the latest cool thing and users of unknown skills, and you’ve got a whole new frontier. Plugging these unpatched Windows machines into your network systems can be a very real problem, and hard to address without administrative policy decisions to provide direction. In many institutions, dorms are being segregated beyond the border firewalls (which is a different discussion altogether).
The Remediator: How has security at the organization level changed?
DB : Most schools now have a division within the IT department dedicated to security policy formulation and implementation. In part, this is a compliance with federal mandates, because of some enlightening experiences. The approach taken varies widely within the different models they have developed for computing. Universities are not monolithic, standardized hierarchies, like the Scarecrow said, "You can go this way, or you can go that way." State schools create a hierarchical structure, but many older institutions act like a confederation of smaller estates. Often the schools or departments have their own IT people who answer to the Dean, Director or Chair of their unit. A central office serves as a clearinghouse for authoritative information. Coordination of efforts has been a significant help, particularly for smaller units. Nationwide, administrations recognize the role played by information services and that a threat to the stability of services is a priority problem to be treated proactively rather than reactively, as it was in the past.
The whole landscape of the university computer center has changed. Once, the only real ‘public utility model’ services were those that calculated pay, tuition and grades. Those systems had downtime that could be scheduled with relative ease. Today, email and Web-enabled applications are viewed as ‘enterprise’ services just as their analogues in the "real world" are, with an expectation of "five nines" (five days a week at nine hours per day) availability. Universities function today on an operational scale like that of large business enterprises. This scaling of expectation and number of users has changed the dynamic of operations dramatically.
In 1988, there were roughly a few-hundred email accounts at the University of Kansas. Little critical information was sent via that channel, mostly between IT professionals. Downtime was not unexpected; it was just mail, nobody would miss it for a few hours. Today, we host about 33,500 email accounts with a majority of services for students and faculty being accessed online. Once a downed email server was an inconvenience, now it is a critical part of the university’s infrastructure that must be up 24 hours, seven days a week, 365 days a year. Services such as mail can’t be down for forensic examination for two hours, let alone two or three days; Web services such as enrollment, payroll, and computer-assisted teaching are on the "A" list of services that cannot be down at any time of day or night. They are dependent on authentication and authorization systems that likewise need to boast "five nines." You don’t get that anytime access if you aren’t secure, no matter how nice your hardware is or how well provisioned your data center. Middleware opens holes, period. We have to get used to it and figure out ways to secure it effectively and efficiently.
Into this new, not just "corporate" but "enterprise" university environment is also mixed script kiddies, crackers, real criminals and spammers, along with the bored and inquisitive freshmen engineering students. Add a touch of NIMDA, a bit of Slammer, spambots, chatbots, and the criminal enticement of online fee payment, employee IDs and social security numbers, and salary and banking information — carry the one and it equals a disaster. Organizations need a cogent security direction being defined and refined daily, based on the rapidly changing nature of the threats. Intrusion detection, traffic analysis — these were topics of interest in 1990 for people with big DOD grants. Today, they are part of the daily routine for administrators in liberal arts departmental roles.
Using concepts thought intrusive ten years ago, such as requiring a client machine to authenticate and be scanned for patches and known malware signatures before it is allowed to connect to the network, may be the only way to keep a campus network secure today.
In 1990, work was more likely to be done via the telephone or with paper memos than on the network, even in a university computer center. The worst thing you’d typically encounter was an egotistical flame war on USENET or BITNET lists, whereas today you find real criminals looking to swipe your identity. It is far easier to fence items acquired using your stolen credit card than to sell industrial secrets.
Although security measures have changed drastically since the open-door policies of 1988, hackers and security threats will continue evolve in the coming years. In 2010, it’s exciting to think we can look forward to a whole new set of circumstances, policies and ways to avoid downtime.
David Barnhill, Senior System Specialist of University of Kansas Academic Computing Technical Services, was born in 1956, a child of two professors who was first exposed to network computing working for NAPA (the parts house) in the 1970s, then in the legal business in San Francisco in the late ‘70s early ‘80s. After that, he segued into computing at the University of Kansas while also founding a computing-based "word processing" company. David worked as an evangelist and technology analyst at the university and then left to found a couple of ISPs and has been on the board of some non-profit organizations. He works at the university as an Exchange, Windows, and Unix system administrator for academic computing and is a consultant. He has three children and three cats and not nearly enough old sports cars. He adds a disclaimer that he isn’t speaking for the University of Kansas, but as someone who has been in the university community most of his life.
|
|
|