Well, as you also might understand right now, the first example takes maybe 2 years in computer science to achieve reading the right tools, and the second example well, it took me 10 years in computer science and is probably the reason I cannot play soccer (little joke there, eheh). In fact, I have been writing and reading code in several computer languages for 10 years now and I had my fare share of kernel hacking but still I have never been able to write a fully working kernel exploit nor detect a kernel vulnerability. I believe my limit was to be able to understand a kernel exploit from top to bottom and modify it for another purpose.

I’m writing this post, because some months ago I met an allegedly computer hacker who knew everything about all the types of software used in hacking linux server, but stated he was not a programmer, so it got me thinking…! He was able to start an international profitable business teaching the fundamentals of hacking and using software made by other hackers, so may I or may I not call all that hacking?

Let’s try to map down the first and the second example so we can understand everything involved in both cases:

For example 1 (going from remote access to root), I will describe it exactly how I would do to compromise security in a server.

• The first problem is doing everything without being traced back to your home nor any of the hardware you used and get an alibi;
• Well the alibi part I don’t care (I never had to think about that because I’m not a criminal);
• About being traced, you can go out of your home town and do some wardriving until you find an open network or you can actually take the time to crack a protected one. Remember to still bounce a lot, so that the odds of getting caught get really slim (bounce means connecting to several servers that act as a proxy so that if someone would like to figure out your actual IP address, they would have to contact every provider you bounced on and trust they have reliable information about every connection in history);
• With your anonymity covered and an alibi, you can start messing with things;
• Now, the first problem is getting local access on the machine. Here you can simply purchase an account on the server if available or use google to trace if there is any web app prone to PHP injection;
• After getting in, you must be sure to avoid the system administrator, so you can track him using wtmp, lastlog, or if none is available, simply go straight to /dev/pts/ and look if the administrator is online. Now, depending on kernel protection on proc files (proc filesystem) related to process and connection viewing, you might or might not figure out the administrator’s IP address.
• Now, knowing the administrator’s IP address, you can take him down silently with one of the servers you used (bandwidth attack) or using a botnet (if you’re into mass hacking vulnerable web apps — nowadays is kind of hard)
• With the system administrator out of the way, you can start doing the actual hacking and check if he has any misconfiguration that you can escalate, or any outdated software prone to any vulnerability!
• If you can’t find anything, maybe it’s time for some social engineering, and believe me, after making some minor damage, most administrators will actually believe you already have full access to the server and they will gladly give you the actual full access you were looking for.
•  Some techniques to have administrators attention are sending wall messages, flooding syslog files with dummy content, disclosing information on the machine that supposedly would only be available to root, and many others. The main point is for the administrator to believe their server is compromised. Such simple things as fork bombing still make administrators desperate, specially if they start from web apps or cron right when the machine boots (you can even make it scary good if apache is running with a general permission and there’s nothing like suphpexec nor mod_selinux, you can use prctl() and PR_SET_NAME to httpd’s process name and they will think there is a problem with apache).
• After one of those things, you will probably have root access on the machine!

/* just too easy -- some nice library functions for reuse here though

   credits to julien tinnes/tavis ormandy for the bug

spender@www:~$ cat redhat_hehe

I bet Red Hat will wish they closed the SELinux vulnerability when they
were given the opportunity to.  Now all RHEL boxes will get owned by
leeches.c :p

fd7810e34e9856f77cba67f292ba115f33411ebd
d4b0e413ebf15d039953dfabf7f9a2d1

thanks to Dan Walsh for the great SELinux bypass even on "fixed" SELinux policies and nice work Linus on trying to silently fix an 8 year old vulnerability, leaving vendors without patched kernels for their users.

  use ./PCTipsbyAnu_emporium.sh for everything

*/

#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include

#define DOMAINS_STOP -1
#define VIDEO_SIZE 4171600
#ifndef IPPROTO_SCTP
#define IPPROTO_SCTP 132
#endif
#ifndef PF_IUCV
#define PF_IUCV 32
#endif
#ifndef PX_PROTO_OL2TP
#define PX_PROTO_OL2TP 1
#endif

const int domains[][3] = { { PF_APPLETALK, SOCK_DGRAM, 0 },
    {PF_IPX, SOCK_DGRAM, 0 }, { PF_IRDA, SOCK_DGRAM, 0 },
    {PF_X25, SOCK_DGRAM, 0 }, { PF_AX25, SOCK_DGRAM, 0 },
    {PF_BLUETOOTH, SOCK_DGRAM, 0 }, { PF_IUCV, SOCK_STREAM, 0 },
    {PF_INET6, SOCK_SEQPACKET, IPPROTO_SCTP },
    {PF_PPPOX, SOCK_DGRAM, 0 },
    {PF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP },
    {DOMAINS_STOP, 0, 0 }
    };