STATION ID - 7047/3.12 9x Datakit Network FOR OFFICIAL USE ONLY This is a 9x system, restricted to authorized persons and for official 9x business only. Anyone using this system, network or data is subject to being monitored at any time for system administration and for identifying unauthorized users or system misuse. Anyone using this system expressly consents to such monitoring and is advised that any evidence of criminal activity revealed through such monitoring may be provided to law enforcement for prosecution. SECURITY FLAWS AND FIXES by: Nino Please visit Efnet #9x or connect to irc.bitchx.org #9x, would be greatly appriciated (Note: efnet is the main 9x area). Greets: All of the 9x krew -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Spreading HP in the new millenium =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This Article was written by Nino- aka Nino from Irc.bitchx.org #9x. (other: #conf) Thankyou. Security flaws and fixes Volume 1. releases by Nino soon to come are (**8oo**. Everything to know about Novell a nd Security Volume 2 'Sunos security flaws') Also drop by #9x and say hi to (Substance). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=- Introduction: This Article is a security volume, i hope to bring 100 articles to fullfull the Security Volume novell. ALL RELEASED BY 9x. This article will Explain the procedures used by various corps and companies to secure there security flaws, Its will also Explain in detail, wich ones Are still accessible, and what to do about the security flaws. If you work for a company that may use one of these Os's Networks or anything along that lines please feel free to use the information i have listen above to secure your system,. Thankyou and please enjoy this article and do NOT forget to read all of 9x's articles old and new. Informataion is never to old. use it! -(Nino)- -=-=-=-=-=-=-=-==-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=- Contents 1) SEND MAIL SECURITY FLAW 2) Berkeley systems Has a Security problem 3) NEW - TELNET SECURITY AND HOW THEY ARE FIXING THE FLAWS **MUST READ** 4) NEW - IRIX SECURITY FLAW. 5) security flaw in major corps running Ultrix. 6) AT&T NETWORK SECURITY FLAW **MUST READ** 7) Ftp bounce. security and what they plan to do about it. 8) Conclusion. !))- Sendmail Flaw Is Fixed -((! -------------------------------- I will Now go over the procedures that were used To fix The Senmail Flaw. Networker Admins Were Using outdated Versions of Sendmail wich allowed Computer Hackers to Enter and Exploit Private .. Information to themselves and other hackers on the Net. This is a brief Visualation on what was done to Stop this Flaw immediatly after they reconized hackers Penatrating the network systems Sendmail Program. Steps that were used to Fix Sendmail by admins are as followed. 1) Check that you are using version 5.59 of sendmail with the debug option DISABLED. To verify the version try the following commands. Use the telnet program to connect to your mail server. Telnet to your hostname or localhost with 25 following the host. The sendmail program will print a banner which will have the version number in it. You need to be running version 5.59. Version 5.61 will be released on Monday 12/12/1988. Any version less than 5.59 is a security problem. The following is a sample of the telnet command. % telnet localhost 25 Trying... Connected to localhost.SEI.CMU.EDU. 220 ed.sei.cmu.edu Sendmail 5.59 ready at Wed, 7 Dec 88 15:45:55 EST Quit 221 ed.sei.cmu.edu closing connection Connection closed by foreign host. % 2) Verify with your systems support staff that the ftpd program patches have been installed. Removing anonymous ftp is now known to NOT plug all security holes. If you are not sure, ftp to ucbarpa.berkeley.edu, login as anonymous password ftp and get ftpd.shar. This file contains the sources to the latest BSD release of the ftpd program. 3) Check your /etc/passwd file for bogus entries. Look for unauthorized accounts with the uid field set to zero (only the root account should have uid=0). Remove any unauthorized entries. The following is an example of what you might find. install::0:1::/: To check your /etc/passwd files for spurious accounts with uid 0, you can use the following awk program: % awk -F: '$3 == 0 {print $0}' /etc/passwd If you are running YP on your machine, do: % ypcat passwd | awk [...as above] 4) Look for modified /bin/login and /usr/ucb/telnet files. Several sites have found these programs with new "backdoors" added. Use the strings program to search /bin/login for the strings OURPW, knaobj, and knaboj. If in doubt, reload the /bin/login and /usr/ucb/telnet executables from your distribution tape. % strings /bin/login | egrep '(OURPW|knaboj|knaobj)' 5) Educate your users to create hard to guess passwords. Account codes, first or last names, and common words are not very secure passwords. A few examples of common words are words that refer to your town, location, or company and words that are found in /usr/dict/words. Be especially careful of accounts where the password is the account name (easy to check, easy to guess. 6) In general, before you allow a user access to the Internet, you must be sure you know who they are. In other words, all users should be forced through a login/password sequence (no unpassworded accounts and preferably someplace which logs connections) before you let them get outside your local network. Be especially careful with TCP/IP terminal servers. 7) check the last logs for normal logins as accounts which normally run utility programs (sync, who, etc), watch for unreasonable times.. watch for ftp's with funny logins (who, etc). -(Nino)- "The creative And intelegant Group of studiests who exploited the way to stop hackers from entering the sendmail diagnostics was a team of security experts known as (CERT)." - -------------------------------------------------------------------------------------- Berkeley systems Has a Security problem: There's a security problem associated with the passwd(1) program in all known Berkeley systems. This problem is also in most Berkeley derived systems. They came up with A patch to fix this problem. I will brifly show you the Exact steps they used to fix the security flaw in the sys. They Applied the following patch to the file src/bin/passwd.c and they then, recompile/reinstall it. *** passwd.c.orig Wed Dec 21 08:57:41 1988 - --- passwd.c Wed Dec 21 09:00:25 1988 *************** *** 332,337 **** - --- 332,339 ---- return (crypt(pwbuf, saltc)); } + #define STRSIZE 100 + char * getloginshell(pwd, u, arg) struct passwd *pwd; *************** *** 338,344 **** int u; char *arg; { ! static char newshell[BUFSIZ]; char *cp, *valid, *getusershell(); if (pwd->pw_shell == 0 || *pwd->pw_shell == '\0') - --- 340,346 ---- int u; char *arg; { ! static char newshell[STRSIZE]; char *cp, *valid, *getusershell(); if (pwd->pw_shell == 0 || *pwd->pw_shell == '\0') *************** *** 415,423 **** getfingerinfo(pwd) struct passwd *pwd; { ! char in_str[BUFSIZ]; struct default_values *defaults, *get_defaults(); ! static char answer[4*BUFSIZ]; answer[0] = '\0'; defaults = get_defaults(pwd->pw_gecos); - --- 417,425 ---- getfingerinfo(pwd) struct passwd *pwd; { ! char in_str[STRSIZE]; struct default_values *defaults, *get_defaults(); ! static char answer[4*STRSIZE]; answer[0] = '\0'; defaults = get_defaults(pwd->pw_gecos); *************** *** 429,435 **** */ do { printf("\nName [%s]: ", defaults->name); ! (void) fgets(in_str, BUFSIZ, stdin); if (special_case(in_str, defaults->name)) break; } while (illegal_input(in_str)); - --- 431,437 ---- */ do { printf("\nName [%s]: ", defaults->name); ! (void) fgets(in_str, STRSIZE, stdin); if (special_case(in_str, defaults->name)) break; } while (illegal_input(in_str)); *************** *** 440,446 **** do { printf("Room number (Exs: 597E or 197C) [%s]: ", defaults->office_num); ! (void) fgets(in_str, BUFSIZ, stdin); if (special_case(in_str, defaults->office_num)) break; } while (illegal_input(in_str) || illegal_building(in_str)); - --- 442,448 ---- do { printf("Room number (Exs: 597E or 197C) [%s]: ", defaults->office_num); ! (void) fgets(in_str, STRSIZE, stdin); if (special_case(in_str, defaults->office_num)) break; } while (illegal_input(in_str) || illegal_building(in_str)); *************** *** 452,458 **** do { printf("Office Phone (Ex: 6426000) [%s]: ", defaults->office_phone); ! (void) fgets(in_str, BUFSIZ, stdin); if (special_case(in_str, defaults->office_phone)) break; remove_hyphens(in_str); - --- 454,460 ---- do { printf("Office Phone (Ex: 6426000) [%s]: ", defaults->office_phone); ! (void) fgets(in_str, STRSIZE, stdin); if (special_case(in_str, defaults->office_phone)) break; remove_hyphens(in_str); *************** *** 464,470 **** */ do { printf("Home Phone (Ex: 9875432) [%s]: ", defaults->home_phone); ! (void) fgets(in_str, BUFSIZ, stdin); if (special_case(in_str, defaults->home_phone)) break; remove_hyphens(in_str); - --- 466,472 ---- */ do { printf("Home Phone (Ex: 9875432) [%s]: ", defaults->home_phone); ! (void) fgets(in_str, STRSIZE, stdin); if (special_case(in_str, defaults->home_phone)) break; remove_hyphens(in_str); *************** *** 501,507 **** if (input_str[length-1] != '\n') { /* the newline and the '\0' eat up two characters */ printf("Maximum number of characters allowed is %d\n", ! BUFSIZ-2); /* flush the rest of the input line */ while (getchar() != '\n') /* void */; - --- 503,509 ---- if (input_str[length-1] != '\n') { /* the newline and the '\0' eat up two characters */ printf("Maximum number of characters allowed is %d\n", ! STRSIZE-2); /* flush the rest of the input line */ while (getchar() != '\n') /* void */; " If you are experienced with the berkeley systems you will know that this flaw has yet to be fixed, Hackers can still root there way into the system and change the passwd.c file back to the version with no patch and reinstall it within seconds. this will then allow them to view the passwd(1 files and exploit there way into yet another problem Berkeley systems has to fix." ---------------------------------------------------------------------------------------------- TELNET SECURITY (SHELLS) You know what suxx ? when allover the world telnet security admins are securing there systems so that people like us who exploit and Trade shells for botnets and lame shit like that cannot have access to there shells. They have done alot of Changes in security lately that will probaly begin effect within a month or so. So if u have a Shell that you love with all your heart i advise you to read this session and learn how they are securing there boxes so we cannot do as we are now. There are Several UNIX computers That have had their "telnet" programs replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs. (As a first step, frequent telnet users Will change their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators Will do to detect whether the security on their machines has been compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators Will do the following So please listen close and learn how they are solving these Problems. and maybe you will get an idea on how to get around this ordeal. o They will Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail". This will also help us hackers understand now what and how they are begining to bust us. o Admins Are going to Start to : Test authenticity of critical programs -This means that Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords *WILL* be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on-line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes. <- This tells us That If we think like an admin, and feel like an admin on the time of a hack We might be able to better ourselves with hacking "Unix networks and shells". o There are also =Privileged programs - These Are Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) They can be exploited to gain unrestricted access to systems.(SMile)-=] .System administrators Are going to start to watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems).(SO BE CAREFUL WHERE YOU SET YOUR SHIT AT ON SHELLS). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access. <-- this "back door" technique still werkz I would personaly set the setuid shell (sh - csh) in a 'old' unreconisable dir in /tmp dir. When you gain access to the shell using the backdoor PORT that u setup in the 'old' Dir in /tmp you can connect directly withought login and passwd (common sence) o Box Owners Will Start to Monitor system logs - System access logs will be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. - So when you are in the system I would advise you to make youself look as legit as they come because things are going to become quite Difficult to oprehend. o Terminal servers - Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts. So Make Sure you spoof or bounce when In doubt connecting to a Terminal Server. -you should spoof or cover your Tracks on Everything- o Passwords - Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets for us. System administrators Are now making sure that all accounts are password protected and they will encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. <-- i got Alot of information there. o Anonymous file transfer - Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol - which requires no username/password authentication) Will now always be configured to run as a non-privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, will shortly not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure. - this will block us from getting ftp /etc/passwd files from ftp's. We will have to obtain root or a admin level user host and access to get these files. but if u got root why the fuck would you want that file anyways ?. - Many of the old "holes" in UNIX have been closed.- "So within in doubt we will have to create or discover new ones" -(Nino)- ---------------------------------------------------------------------------- IRIX SECURITY FLAW -Who says irix is secure?. Well guess what, there is a vulnerability in /usr/sbin/Mail, present only in IRIX 3.3 and 3.3.1. I hope most of you e-mail hackers know this because if you dont well its almost to late to start discovering it now. here let me show you the security flaw and what is being done to fix it. If you want to hack an irix mail box, You better do it quick before its to late. /usr/sbin/Mail can fail to reset its group id to the group id of the caller. IMPACT: Can allow any user logged onto the system to read any other user's (including root's) mail. SOLUTION: A fixed /usr/sbin/Mail binary has been made available for anonymous ftp from SGI.COM ([192.48.153.1]). The correct binary can be found at: sgi/Mail/Mail under the ftp directory. Note that this binary must be installed with the same group (mail) and permissions (2755) as your existing 3.3 or 3.3.1 /usr/sbin/Mail. "Iadvise you to go peepin tommin somewhere else . either that or find another security flaw in IRIX mail baoxes." -(Nino)- ----------------------------------------------------------------------------- Security flaw in Ultrix There is a Security Flaw in: Digital Equipment Corporation's (DEC) Ultrix operating system versions 4.0 and 4.1 for all DEC architectures. This is a BIG security flaw to Major corps using this system, This flaw allows unauthorized access to root or any level user. The reason for this is because in Versions 4.0 and 4.1 of Ultrix The default instalation (wich most companies use with Ultrix) of /usr/bin/chroot is wrong and installs wrong. (blame it on the makers of Ultrix) Now there is a new version that has a fix but not all companies changed to this versin because it was made for personal use and not networkable for company satisfaction. those companies that do know about this security flaw have changed the permission on the file /usr/bin/chroot. #chmod 700 /usr/bin/chroot If you find a company that uses this version of Ultrix Be sure to check /usr/bin/chroot and see if there permission file was changed. if it wasnt then have fun with your new hack. -(Nino)- ------------------------------------------------------------------------- AT&T SECURITY FLAW ( A MUST READ )! AT&T TCP/IP Release 4.0 running on SVR4 systems for both the 386/486 and 3B2 RISC platforms. The existing error, in the remote execution server /usr/etc/rexecd, has been corrected, and a new executable for rexecd is available from AT&T by calling *800-543-9935*. Patches may be obtained outside the U.S. by calling your local technical support. The numbers associated with the fix are 5127 (3.5" media) and 5128 (5.25" media). The problem does not exist in TCP/IP release 3.2 for SVR3, or any earlier versions of the TCP/IP product running on either the 3B2 or 386 platforms. The version of TCP/IP distributed with SVR4 by UNIX System Laboratories, Inc. (a subsidiary of AT&T) does not contain this vulnerability. A vulnerability has been identified where root privileges may be accessed through the use of /usr/etc/rexecd. A user on a remote machine may be able to run commands as root on the target host (the host running the affected /usr/etc/rexecd). 1. Administrators of affected systems Will execute, as root, the following command will be used immediately turn off access to rexecd until the new binary can be obtained. # chmod 400 /usr/etc/rexecd 2. They will obtain and install the new patch. The fix will be supplied as one diskette, and it comes with one page of instructions documenting the procedure to replace the existing /usr/etc/rexecd binary. "This security flaw by my testings have not been 100% secure. when you gain access to the system you can go to /usr/etc/rexecd and find your root information there, its a unique security flaw but it works. I unfortanatly didnt stick around long enough to gain root. I do not know enough about these systems yet to make my way into there privacy." -(Nino)- ------------------------------------------------------------------------- FTP BOUNCE Relevant to the topic, in some implementations of FTP daemons, the 'port' command can be misused to open a connection to a port of the hacker choosing on a machine that the hacker could not have access directly (duh! ya think?) - There have been on going discussions about this problem (they call it FTP Bounce) for Several years, and some vendors have developed solutions for this problem. now listen close because these fixes like all the other fixes can give us ideas on how to move around the security updates and patches. "Because the core element of the attack (the FTP server can establish connections to arbitrary machines and arbitrary ports) is also a required component for RFC compliance, there is no clear-cut solution. With this in mind, we urge you to carefully consider the type of service that your site offers. The best solution solely from a security perspective is to ensure that your FTP server software cannot establish connections to arbitrary machines. However, sites that rely on the RFC-compliant behavior may find that implementing this solution will affect applications that they use. (We have not received any first-hand reports of such cases.) Consequently, many vendors offer solutions that allow sites offering the FTP service to make the choice that best suits them. You should check to see what type of behavior your vendor's FTP daemon adopts (Section A). If you wish to implement an FTP service that does not allow this attack and your vendor does not offer a daemon with this functionality, consider using the wu-ftpd package described in Section B. Other steps you can take are described in Section C. A. Vendor Information It is our experience that vendor implementations fall into one of these groups: 1. strict conformance with RFC functionality: The PORT command may be used to connect directly to a third-party machine, and this is the only functionality allowed. Some vendors who choose to maintain strict conformance have addressed this problem by modifying all other network services to reject connections originating from the FTP data port (port 20). 2. strict suppression of the PORT command: The PORT command may be used to connect to the originating client, and this is the only functionality allowed. 3. variable PORT command behavior: The PORT command may be used in either of the above two ways, with one way being the default. Switching between them is usually achieved with a command line parameter. You should be careful to verify which is the default." "this was a fix by an unknown vendor a few days ago. not all systems are capable of this fix yet, but i posted this just as a fair warning of what u might be held up against in the near future while trying to hack an ftp daemeon." -(Nino)- --------------------------------------------------------------------------------------------- CONCLUSION Well thats it for now folks i will have another security volume 2 article out the day after This one is released so be looking for it and all other new releases by 9x. i hope you enjoy this article and i hope it does come to some use to you. if not. well at least you learned a few new things and that never hurts. 9x will be releasing a new 8oo txt written by me. a Security volume 2 *sunOS security* article by me. and a Everything you need to know about Novell security and how to run it on a network <-- that was a request. Please get on your K-rad Net boards and surf on over to www2.dope.org/9x or ftp.phunc.com /pub/9x. support the hp world and come on over to efnet #9x. and or irc.bitchx.org #9x. thankyou. - Nino (the new 9x pimp)