Dan Kaminsky's Blog

Executive Summary

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.

Access Rights

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.

Power To Control

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.

Learning Disorders

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.

Surprising Security

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?”

Not Ready For Business

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.

Immediate Responses

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.

Conclusion

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.