[[Image] [Image] [Image] [Image] [DoxPara Research] DoxPara Research seeks to advance user interfaces and usage architectures, as well as to provide a unique [rasterbation_top] perspective upon issues facing the world around us. Insecurity By Design: The Unforseen Consequences of Login Scripts Available At DoxPara By Dan Kaminsky The latest news 24-May-1998 regarding DoxPara Executive Summary can be found here. Dan Kaminsky DoxPara Research is A common aspect of most client-server network designs is the testing WebTips, login script. A set of commands executed upon provision of which apply correct username and password, the login script provides the ToolTips to web means for corporate system administrators to centrally pages. By holding manage their flock of clients. Unfortunately whatīs your mouse over the seemingly good for the business turns out to be a disastrous the icons next to security hole in the University environment, where students each entry in this logging into the network from their dorm rooms now find the launchbar, you can network logging into them. This hole provides a single, read a detailed uniform point of access to any number of previously description of the uncompromised clients, and is a severe liability that must contents that lie be dealt with with the highest urgency. Even those in the within. corporate environment should take note of their uncomfortable exposure and demand a number of security procedures described herein to protect their networks. One Security and possible solution for some may be the DoxPrint system Networking designed by this author; it allows users to print to Novell [Analogous Key Arrays, or AKAīs, are command arrays with keyboard hotkeys that correspond t Print Queues over the Network Neighborhood without requiring any Novell code on the client. Affected universities should Design: consider switching to systems that do not require full The Unforseen logins, until more stable and secure systems are available. Consequences of Login Scripts ...The effect of the bug is to cause the number of ACKnowledgement packets sent to be equal to that of the number of loaded and bound TCP/IP stacks Access Rights in the Windows9x What if I told you that every time you turned on your TCP/IP Stack 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 User Interface what software should load, what files to send, maybe even Proposals what data to erase? What if, merely by accessing a web [Analogous Key Arrays, or AKAīs, are command arrays with keyboard hotkeys that correspond page, your system came under the full control of the page's author, or more accurately any possible author of that page, Arrays authorized or not? Cluehunting describes an advanced Expansion Agent, defined as a system that allows the computer to search possi Minbars are advanced taskbars that group applications by their types instead of by birthtimes and that s 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 Architectural the user is an ongoing communication under contractural Proposals Vectorcast breaks down the artificial divisions between Clients and Servers and converts them into Vectors and Directors. A sociological mode of data distribution, Vectors both recieve data provide authentication material in the form of username and SILC proposes a new windowing architecture for 2D Graphical User Interfaces. The present situation is that the computer either completely trashes all information behind the present window, forcing it to be redrawn if the window is ever moved, or the computer keeps in memory as much as possible in whatīs called a backing store. SILC is essentially an intelligent backing s access. Never does the user agree to a "remote root access contract"! Whether this access is, in fact, used or abused Software DoxSTAR 1.0 greatly simplifies keyboard control of Starcraft by making hotkeys match their onscreen location. In addition, DoxSTAR adds descriptive and immersive popups to each c acceptance of "handing over the keys of the computer" to an external agent. [Windows perceives the Linux machine as just another NT Server, while Novell perceives th Editorials Power To Control [Support Monopolies, Payment In-Kind with Stability, and more.]Core Of course, sometimes the issue of what, exactly, the term Competencies: "user" means becomes muddled. In a corporate environment, Why Open Source Is The Optimum Economic Paradigm for Software ...The box stated that if I did not provide my personal information to Caere within 25 uses of the applicat owner, nor is he or she the highest authority regarding what should or shouldn't run on the machine. Login scripts, Registration: Bad Business composed of lists of commands to be executed on the client machines upon the correct provision of username and [Informal and spur-of-the-moment observations on whatever I'm thinking about lately.]Sidel password, provide a means for the central administrators of Ad Ho corporate computers to automatically connect to network Commentary drives and printers. They also allow the administrators to Updated 16-May-1999 load any software they choose upon the client computers as if the user himself had run it. Anything from Censorware to Miscellaneous ...Maybe the damn thing doesn't even usually work. Maybe the machine was bought for a couple grand and sits in the administrator to load. This freedom to centrally manage systems is extremely powerful. Some would argue that it's an User: System Failures In The Information Age intrinsic capability of any client-server architecture that In conclusion, more detail can be displayed to the user by using a semi-transparent(translucent) overlay just as physically handling each client machine is extraordinarily expensive in terms of funds and manpower. With every major Colorspace client-server networking architecture automatically executing the commands contained within login scripts *by Personal default*, it would appear that networking engineers are serving the perceived requirements of the corporate [About Dan Kaminsky]Biographical mentality quite well. Information [Resume of Dan Kaminsky]Resume Small problem: University dorm networks aren't corporate. of Dan Kaminsky [Dan Kaminsky's Music]Music Learning Disorders Iīve The authentication procedures built into Windows NT Domains Composed and Novell Netware are often used by Universities as a means for controlling access to file and print resources. Both CONTACT ME the University and the student are in an advanced version of an Internet Service contract, but it's an ISP contract I welcome your nonetheless. The user(student) agrees to pay a fee(tuition) email on any topic and provide authentication material in the form of username I write about, or and password, and in return the ISP(University) agrees to any topic in provide access to network resources. Unfortunately, to general really. provide access to file and print resources, Windows(the Please be aware predominate computing environment on the desktop) cannot that I reserve the generally delay the login procedure until the time of actual right to think your usage. Indeed, just as in the corporate world, the system point is excellent is presumed to be the property of the institution and the enough to use student/employee must thus authenticate him or herself upon unless you request startup of the machine. Also, just as in the corporate otherwise. world, the system will by default execute any commands the system administrators have deemed appropriate. Think thereīs a book I should The school does not own the hardware, nor does it own the read? Email me operating system running upon it. Even if it did both, it enough information would not own the data on those systems; students do not about it and I just generally relinquish ownership of their own labor to their might. educational institution. It is of the highest inappropriateness, then, that University Information Technology departments receive full access to that which is Get Hosted plainly not theirs. It's not their faults, really. They just want to track use and prevent abuse of pseudo-public Netpedia.com, a resources. The only way to do this lies with the corporate wonderful resource authentication mechanisms within Netware and NT Domains. in and of itself, That the default setting in both environments is to load any will graciously and login script provided is the fault of their respective generously host any designers, not of the accidental victims in IT. Ironically, open source project not a bug but a long standing design decision is responsible that requests for what is likely the greatest single computer security space. To sign up, vulnerability at many universities. go to www.netpedia.net. 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: 1) 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... 2) 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. 3) 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. [rasterbation_bottom]