Article: 44480 of comp.sys.mac.comm >From: crawford@scipp.UCSC.EDU (Mike Crawford) Subject: Re: U WANT PASSWORDS? Easy! Date: 27 Feb 1994 22:03:29 GMT Organization: Santa Cruz Institute for Particle Physics In article psadri@sdcc13.ucsd.edu (Pasha Sadri) writes: >Say I write this program that uses your username and password (eg Some mail >programs out there). I could easily write a little routine into it that >takes your password and sends it to me by e-mail (specially easy if you are >talking about a mail program). All I have to do is put my little program on >the net. After a couple of days I'll have all these usernames along with >their respective passwords. It would be relatively transparent to a >non-suspecting user. The program is called "telnet", and it is a standard program on all computers that use the TCP/IP protocols. It is used to make a terminal-like connection to another computer over the Internet. On Unix machines, the standard telnet has a global variable that is a debugging flag. It is initialized to 0 when the program is compiled for a shipping product. If you can become "root" on a Unix machine, (that is, acquire administrative privileges) you can use a debugger such as adb to set this debugging flag to 1 in the binary disk image. After that, anything that any one types is saved to disk. You need not become root ever again - you just have to log in to get the file. Becoming root at least used to be simple on many Unix machines. The one way I know is to take advantage of a security hole that was created by Sun to allow each Sunview window to appear to be a logged in terminal. The file /etc/utmp is normally writable only to "root-privilege" processes. Sun made the file writable to everyone. Unix implementations that are derived from Sun, such as Apple's A/UX, inherited this hole. I raised hell about it when I was at Apple, but the A/UX team refused to fix it (more about this later). The Unix program rwall broadcasts announcements to all logged-in terminals. This is used to notify users of impending shutdowns. Any user can use rwall, and the "rwall daemon" runs as a root privilege process. Thus rwall has the privilege to write into _any_ file. To break root, log into an A/UX machine as "guest" (they are, or at least used to be, shipped with a guest account that required no password) You will need to write a little C program that will create a new /etc/utmp file in which /etc/passwd appears to be a logged in terminal. Save the old utmp file to restore it later. Use rwall to broadcast a message to all logged in users. The message will look something like this: root::0:0::/:/bin/csh Now type "su", and you have root privileges. Put the old utmp file back. If you want to use some finesse, you can remove any trace of your login from the /etc/utmp and /etc/wtmp files. Now uses adb to patch the telnet binary, and log out. Wait a week or so, log back in, and get the debugging output. You will have user names and passwords for any computer that has been logged in to from the computer you hacked. If any of them are Suns or A/UX machines, log into them and hack them as well. I expect you could get accounts on a substantial fraction of the Internet this way. The utmp hole is present mostly on Suns and A/UX machines, but the telnet hole is present on almost all Unix machines. You'll just need to find a different way to break root. One way will be to record someone's password if they log in as root from an A/UX machine. This it is important to understand that if you manage a machine on the Internet, and you allow remote logins from any other machines at all, then all of those machines had better be secure or they will compromise _your_ security. Those machines are vulnerable if they allow logins from any other machine. I log into machines all over the world via telnet. My colleagues in Switzerland have little influence over the machine I use here - but they are vulnerable if my machine gets hacked. The newspapers have been reporting a rash of break-ins on the Internet lately. I believe this is one of the ways that hackers are doing this. The telnet and utmp holes are both very old and well-known holes (I learned of them in a computer security lecture at the Interop conference in 1989), but many vendors have been slow to fix them, and many sysadmins have been slow to install such fixes as are available. The Computer Emergency Response Team sends advisories about how to patch holes as they are discovered. Usually these instructions are quite oblique, as they do not want to tip off potential hackers about new back doors. They would just say something like "A security hole has been discovered on Sun systems. To fix it, type the command chmod 644 /etc/utmp". At best this slows down hackers - it took me only two days to figure out how to hack an A/UX machine after I heard this about Suns. It is very important for anyone who administrates computers on the Internet to pay careful attention to the CERT advisories. If you haven't been getting them, you should obtain them via anonymous FTP from cert.org. (Info at end). Regarding my experience at Apple - I was beta testing A/UX 2.0 while I was the MacTCP test engineer. When I discovered the utmp hole, I called up the A/UX team and asked to speak to their security manager. The A/UX folks were baffled by this - they did not have one, which is quite peculiar as they were writing A/UX mainly to compete for an enormous Air Force contract. I reported bugs through the usual channels, which were basically ignored (perhaps filed away for fixing in a future release). At first I just said "You should chmod 644 /etc/utmp" in your build of A/UX". Finally I got frustrated and figured out how to hack A/UX machines in detail, and posted this all over Apple's internal Usenet News. This resulted in some conversations with some really irate A/UX managers, who explained that A/UX had to ship soon to meet the Air Force requirements, and they did not have time to fix it. I pointed out that this was a well known bug from Sun, and that the fix could be done quite quickly. The A/UX folks said that if the utmp file was writable on a Sun, there was probably some good reason it had not been fixed and they did not have time to consider the question properly. A/UX shipped with the hole intact and no-password guest logins enabled by default. Apple didn't get the contract in the end. I understand that the actual Air Force version of A/UX was provided by Honeywell, which would install some sort of "secure" Unix, so our nations nuclear secrets wouldn't be accessible to junior high kids, but A/UX is popular among academics, so there are lots of these machine on the Internet compromising your security and mine. Consider this: an ethernet card can be purchased for about $100. A single-card IBM PC that boots entirely from ROM can be made easily or probably purchased from stock. This it is straightforward to make a really inexpensive ethernet sniffer, one that is cheap enough to throw away. ($500 tops) Make such a sniffer and tap it into an ethernet cable in an inaccessible place at your favorite internet site. Program the sniffer to watch for things that look like passwords, and to periodically send reports of usernames, IP addreses, and passwords to some preset IP address via a UDP packet. It would be best if the sniffer acquired the IP address of some host on the same branch of ethernet, but only used it when sending these report packets (it should not respond to pings, broadcasts, etc.). The only way to find this sniffer would be to use a Time Domain Reflectometer, is an expensive and difficult device to use, to find the radio reflections caused by your sniffer's ethernet tap. The only solution I see for this is to require the use of encrypted passwords on the internet. The "two-way scrambled" passwords you see sometimes on AppleShare use this. When you log in to some machine, it sends you an encryption key. You encrypt your password with that key, and sends it back. The encryption scheme is designed to have no method of decryption - instead the host you log into also encrypts your password and compares it with what you sent. The kerberos system works something like this. The problem is that this requires every machine on the internet to change its software. This requires every vendor to spend money to develop, support and market this software. Even though one can obtain it for free from MIT, there still is expense involved in getting it to the customer so it has not been widely adopted. Also, if you log into a kerberos host from a non-kerberos host, your password goes unencrypted over the internet. Also, if you telnet from machine A to machine B, then from machine B to machine C, then your password will go unencrypted from A to B, where B will encrypt it and forward it to C. It is not clear that there is any way to prevent this. The Internet is like a small town in which no one locks their doors at night. The bulldozers of the Information Superhighway have already broken the ground for the new road. The security systems of Unix IBM PC, Macintosh, VMS and others only provide for casual security, much as picket fences only keep children from straying from their yard, and the neighbor's dog from soiling the lawn. As our small frontier town becomes a booming city, a center of commerce and industry, we will also face electronic pickpockets, theives, reckless youths and psychopaths bent on destruction. We are in the information age. Those who possess the information, and understand how to wield their knowledge, will be the rulers. Those who are uninformed will be the peasants, and will ever be at the mercy of those who possess the knowledge. Get informed. Mike Crawford | Author of the Word Services Apple Event Suite. crawford@scipp.ucsc.edu | Free Mac Source Code: ftp sumex-aim.stanford.edu | get /info-mac/dev/src/writeswell-jr-102-c.hqx