A common aspect of most client-server network designs is the login script. A set of commands executed upon provision of correct username and password, the login script provides the means for corporate system administrators to centrally manage their flock of clients. Unfortunately what´s seemingly good for the business turns out to be a disastrous security hole in the University environment, where students logging into the network from their dorm rooms now find the network logging into them. This hole provides a single, uniform point of access to any number of previously uncompromised clients, and is a severe liability that must be dealt with with the highest urgency. Even those in the corporate environment should take note of their uncomfortable exposure and demand a number of security procedures described herein to protect their networks. One possible solution for some may be the DoxPrint system designed by this author; it allows users to print to Novell Print Queues over the Network Neighborhood without requiring any Novell code on the client. Affected universities should consider switching to systems that do not require full logins, until more stable and secure systems are available.

What if I told you that every time you turned on your computer, the government could control exactly what would load? What if, every time you entered your username and password, your ISP gained the ability to specify exactly what software should load, what files to send, maybe even what data to erase? What if, merely by accessing a web page, your system came under the full control of the page's author, or more accurately any possible author of that page, authorized or not?

In each case, the security violation is quite obvious. Merely drawing electricity, connecting to the Internet, or accessing a web page does not constitute an open license to fully control a computer. In legal terms, each action by the user is an ongoing communication under contractural obligations--for example, the user agrees to pay a fee and provide authentication material in the form of username and password, and in return the ISP agrees to provide Internet access. Never does the user agree to a "remote root access contract"! Whether this access is, in fact, used or abused is irrelevant. None of the user's actions constitutes acceptance of "handing over the keys of the computer" to an external agent.

Of course, sometimes the issue of what, exactly, the term "user" means becomes muddled. In a corporate environment, the user of the computing environment is not necessarily its owner, nor is he or she the highest authority regarding what should or shouldn't run on the machine. Login scripts, composed of lists of commands to be executed on the client machines upon the correct provision of username and password, provide a means for the central administrators of corporate computers to automatically connect to network drives and printers. They also allow the administrators to load any software they choose upon the client computers as if the user himself had run it. Anything from Censorware to remote control software is within the power of the administrator to load. This freedom to centrally manage systems is extremely powerful. Some would argue that it's an intrinsic capability of any client-server architecture that claims to be "ready for the enterprise", as the prospect of physically handling each client machine is extraordinarily expensive in terms of funds and manpower. With every major client-server networking architecture automatically executing the commands contained within login scripts *by default*, it would appear that networking engineers are serving the perceived requirements of the corporate mentality quite well.

Small problem: University dorm networks aren't corporate.

The authentication procedures built into Windows NT Domains and Novell Netware are often used by Universities as a means for controlling access to file and print resources. Both the University and the student are in an advanced version of an Internet Service contract, but it's an ISP contract nonetheless. The user(student) agrees to pay a fee(tuition) and provide authentication material in the form of username and password, and in return the ISP(University) agrees to provide access to network resources. Unfortunately, to provide access to file and print resources, Windows(the predominate computing environment on the desktop) cannot generally delay the login procedure until the time of actual usage. Indeed, just as in the corporate world, the system is presumed to be the property of the institution and the student/employee must thus authenticate him or herself upon startup of the machine. Also, just as in the corporate world, the system will by default execute any commands the system administrators have deemed appropriate.

The school does not own the hardware, nor does it own the operating system running upon it. Even if it did both, it would not own the data on those systems; students do not generally relinquish ownership of their own labor to their educational institution. It is of the highest inappropriateness, then, that University Information Technology departments receive full access to that which is plainly not theirs. It's not their faults, really. They just want to track use and prevent abuse of pseudo-public resources. The only way to do this lies with the corporate authentication mechanisms within Netware and NT Domains. That the default setting in both environments is to load any login script provided is the fault of their respective designers, not of the accidental victims in IT. Ironically, not a bug but a long standing design decision is responsible for what is likely the greatest single computer security vulnerability at many universities.

Saying that Login Scripts--something which, for so long, have been considered as innocuous as an ugly background--are indeed such a powerfully damaging technology is a strong statement that needs to be backed up. Login Scripts are so dangerous because they eliminate the most effective element of the security design behind Windows 95 and Windows 98: Security Through Impossibility. By default, Windows runs almost no services. You can't telnet in, you can't view the screen remotely, and there is no sendmail or ftp server with buffers to overflow. The only common service run is the infamous NetBIOS. The result of this restrictive environment is interesting: While it's not particularly difficult to remotely crash a 95/98 machine, it's surprisingly hard to remotely compromise this erstwhile insecure operating system without at least some interaction from the user. It's the difference between a locked door and a brick wall.

Some arguably overzealous administrators will use this facet of security to ban any and all services not explicitly authorized(by an Act of God, usually). This can be excessive, and often prevents significant educational and productivity benefits. It's not that services are necessarily worrisome so much as the universal deployment of identically insecure services with significant value compromisable by unauthorized access--dedicated servers, unfortunately, have a tendancy to fit very nicely into this category. Sysadmins understand well that since both their servers are at risk and downtime is expensive, it is necessary to have recent backups of servers at all times. Sometimes, client desktops are also backed up. But, in an educational institution, it is grossly improper for the university to have copies of student/client data. Worse, as most computers ship with no system-scale tape backup, very few students are able to back up their data. This means that gigabytes of student data are protected only by the security built into their operating system. This actually isn´t too awful--no default remote access has its advantages--until the login scripts are compromised. Since the login scripts reside on servers that in general are never considered fully secure by nature of the services they run, and which are further targeted due to the high value gained by a successful penetration, we see the heretofore impossible compromisation of every single networked Windows station nearly simultaneously as being only a matter of changing a few commands in a login script. Crack one server, and you crack a thousand clients whose only "crime" was stating their identity. That's one tough lesson.

Sadly, some university administrators have responded to this observed threat by claiming that 1) they'd never maliciously enter anything into the login scripts and 2) they're pretty much the only ones with access to the login scripts, so "nothing would ever happen." If there was ever a set of famous last words for a system administrator, these would be them. They've got the keys to systems they don't own, and it's probable that their users don't even know it. Their intentions are irrelevant; they're not generally the ones to worry about. As I told one admin, "It's not you I distrust. It's your computer. Maybe you'll accidentally share the wrong directory. Maybe you´ll be forwarded to a web site that will use a backdoor to initiate a remote LANMAN authentication. Perhaps a 95/98 machine you logged into as Administrator for the domain will have its .PWL files cracked. Or maybe somebody will sneak in in the middle of the night and install a keylogger. With one hack providing access to *everybody*'s machine, it's worth it for a cracker to attack; isn't it worth it for you to defend?"

If this is making sysadmins in the corporate sector nervous...it should. Yes, the downside to centralized management is indeed single point of massive failure. More than ever, businesses are just one disgruntled system adminstrator away from a task-scheduled mass virus infection--or worse. While indeed there are methods for disabling the loading of login scripts, their all-or-nothing nature makes them unrealistic in many environments. Businesses should not need to choose between tremendous risk and necessary functionality. Microsoft and Novell need to implement the following functionality in their login script code:

• Script Capabiltiies. Login scripts allow drives to be mounted, printers to be connected, applications to be loaded from remote drives, and so on. System administrators need the ability to specify exactly which commands a client machine should honor. This provides a barrier to abuse--a site that only uses login scripts to mount network drives should be able to restrict clients to the degree of functionality the site requires. There are going to be issues, of course, with executable code on remote drives. To address this, we require...
• Data Signatures. Cryptographic signatures on executable content, most commonly used by Microsoft's Authenticode system, provide a means for insecure systems to verify the appropriateness of remotely executed code. Sysadmins should be able to "sign" login scripts, as well as commonly executed remote code, and then specify that unless the client detects a signature from a "trusted" list, the content should be considered unauthorized. Sysadmins should also be able to sign actual executables(and maybe even data files) as acceptable for remote execution.
• Executable hash checking. A slightly different tact might be to have clients cache hash values of specific files commonly run. Given a change from one session to another in the file hash, a trap could be sent to the administrator noting him or her that a system breach may have occurred. It´s one thing to replace the contents of a file, but it´s another to have to operate against the memory of every client that accessed the old file. This is a useful way to flip the disadvantage of large numbers of dumb machines into an advantage of intelligent agents with configurable responses to non-matching hashes.

Of course, the ultimate solution to this issue is to emulate a an alternate login paradigm that Win95/98 implements to some degree. As Russ Cooper, editor of NTBugTraq, writes:

There is *no need* for a client machine (be it Win9x or NT) to logon in to a domain in a way that would invoke a login script in order to gain access to its resources. You log into the machine itself (the client machine), and then connect to the resource and supply a userID and password. This will establish the connection, without invoking the login script. Bingo, problem solved, no?

Novell and many other systems need to emulate this usage paradigm post-haste, and institutions still using full Domain logins must cease as soon as possible.

Universities should consider implementing systems that do not require any form of login procedure for the user to access his or her own computer. The reasoning for this is a matter of ownership--what right does a university have to deny a user access to his or her own computer? Password security is notoriously bad anyway, and is far too insecure for any degree of non-repudiability. I´m working on a solution for switched hubs involving using MAC Caches to allow trustable two-way communication traces.

Those who insist upon using login procedures need to be disable them immediately for dorm-room computers. Students who need to connect to specific shares should be given a batch script to load--this will, incidentally, eliminate nasty situations where login scripts appropriate for one environment(say, the capturing of LPT1 to a printer port) are completely inappropriate in another(say, when that same user is in their dorm room).

For those administrators running Novell Netware all the way to your student´s desktop, I implore you to evaluate DoxPrint. DoxPrint allows sysadmins to enjoy most of the advantages of running Netware servers on the backend while sparing Windows clients the hardship of installing and maintaining the Novell client code. All access occurs over the Network Neighborhood, and is quite flexible in its programmability and authentication. It´s been tested and proven as a powerful solution to some of the problems Netware creates.

It´s a strange thing, that such a common function would turn out so open for abuse. System designers who create new functionality need to include security considerations at every phase of the design process. Any time network access to a system is introduced, there is a significant burden of functionality upon the system to verify that the actions executed on behalf of the remote agent are appropriate. Failure to meet this burden is technical irresponsibility and must be prevented at all costs.

I am immensely curious as to the reactions of Microsoft, Novell, and any other administrator who is reading this now. Please, send me your opinions; I´ll publish the best of the replies.