Tuesday, October 30, 2012

Hack A Facebook Account With ARP Poisoning


This article is a revised and a more advanced version of what we learned in the post "Facebook Cookie Stealing And Session Hijacking", before i get started, i would like to share that i have just passed my CCNP route examination with 95.3 percent and i am preparing for my CCNP switch examination therefore i would not be able to post for a while, however our Cheif Editor "Dr Sindhiya Junjeo" will continue to update you with latest hacking news until i return. So Let's get back to the tutorial.

In our previous post, "Facebook Cookie Stealing And Session Hijacking" i used a packet sniffer called "Wireshark" to capture packets on a wireless network and finally captured facebook's authentication cookie and replaced the victims authentication cookie with our own authentication cookie allowing us to hack the facebook account. However this post would be more related to hacking a facebook account on a LAN with ARP Poisoning or Man in the middle attack.

Lan Sniffing - Core Concepts

  • If you are sniffing on a local area network (LAN), first of all you should make sure that your Network card is in the promiscuous mode. 
  • Next up you should know the difference between a hub and a switch based network, in case of a hub based network a normal packet sniffer would do the job, however in case of a switch based network we would need to launch an attack called "ARP Poisoning attack" or "Man in the Middle attack" in order to route the victims traffic through us. 
Before reading this tutorial I would recommend you to  part1, part2 and part 3 of my Gmail Session Hijacking and Cookie stealing series, So you could have better understanding of what I am doing here.

Logic And Methodology:

The tutorial is divided in to three main steps:

Step 1

First of all we would use "ARP Poisoning" or "Man In the Middle Attack" in order to poison victims "ARP CACHE" and route all the traffic through our computer.

Step 2

Since all the traffic would be rotued through our computer, we would simply launch a packet sniffer (Wireshark) and capture the authentication cookies for facebook.

Step 3

Finally we would replace the victims authentication cookie with our cookies and therefore hacking into victims Facebook account. 

Tools

Hack A Facebook Account [ARP Poisoning] {STEP 1 }

I have wrote lots of tutorials on ARP Poisoning, therefore i won't got into much details on how it works. We would use a tool named "Cain And Abel" to accomplish this task. So here is how we will use "Cain And Abel" to carry out a Man in the Middle attack to hack a facebook account.

Step 1 - Download "Cain and Abel" from the link above and launch it.
Step 2 - Turn on the sniffer by clicking on the Green button at the top, Next scan for the Mac Addresses by clicking on the plus sign (+) at the top. 


Step 3 - Once you have scanned all the Mac Addresses and IP addresses, it's time to perform the Man In the middle attack. For that, Click on the APR tab at the bottom and then click on the white area in the top frame. This will turn the "+" sign into blue color.


Step 4 - Next click on the "+" sign, lists of hosts will appear, select the hosts which you want to intercept the traffic between. In my case at the left side would be my default gateway and on the right would be my victim hosts. 

Step 5 - Click ok and then finally click the "Yellow Button" just under the file menu of  "Cain and abel", Now it will start poisoning the routes in a short span of time and you would start to see traffic being captured by cain and abel. 



Monitor a Facebook Account from any where in the world

Hack A Facebook Account [Packet Sniffing Wireshark] {STEP 2}

So, since we have already poisoned victim's ARP Cache, all the traffic going from the victim to the router will be captured by our packet sniffer (Wireshark). But before we capture the cookie, i would like to explain briefly regarding "Facebook Authentication Cookies".

Facebook Authentication Cookies

Well, at the time i wrote the tutorial "Facebook Cookie Stealing And Session Hijacking" Facebook used "Datr" as their authentication cookie, Now facebook uses two cookies instead of one, namely "c_user" and "xs" for authenticating a user. Therefore we would need to capture both of these cookies and replace them with our cookie to hack a facebook account.  So here is how you would capture authentication cookies with facebook. 

Step 1 - First of all download wireshark from the official website and install it.


Step 2 - Next open up wireshark click on analyze and then click on interfaces.


Step 3 - Next choose the appropriate interface and click on start.


Step 4 - Continue sniffing for around 10 minutes.

Step 5 - After 10minutes stop the packet sniffing by going to the capture menu and clicking on Stop.

Step 6 - Next set the filter to http.cookie contains “datr” at top left, This filter will search for all the http cookies with the name datr, And datr as we know is the name of the facebook authentication cookie.



Step 7 -  Next right click on it and goto Copy - Bytes - Printable Text only.


Step 8 - Now you would see lots of cookie values, however c_user and xs would be the only ones of our interest. Copy both of the values in a notepad. 

Hack A Facebook Account [Cookie Editing] {Step 3}

Now, finally it's time to hack a facebook account by using the cookie values we captured, for this purpose you would need a cookie editor, I will use a firefox addon called "Cookie Manager" to replace the cookies.

Step 1 

First of all open up firefox and browse to http://facebook.com.

Step 2  

Next open up the cookie manger (Tools - CookieManager+)



Step 3  

Next click the "add" button.  Fill in the following values: (Take a look at the screenshots below for more clarification)

For Authentication Cookie: c_user

Name: c_user
Value: The value of the cookie that was captured.
Host: .facebook.com

For Authentication Cookie: xs

Name: xs
Value: The value of the cookie that was captured.
Host: .facebook.com


Step 4 -

Next click on the save button, Finally you just need to refresh your page and you would be logged in to the victims account, thus you have hacked a facebook account by session hijacking attack. 



Note: This Attack will only work if victim is on a http:// connection and even on https:// if end to end encryption is not enabled.

I hope you have enjoyed the tutorial as much as i have enjoyed while making it, if you have any questions feel free to ask, Feel free to share it with your friends so they can know the dangers of browsing over a http connection. 

P.S: If you would like to learn more methods to hack in to facebook account, kindly refer my Facebook Hacking Course

Sunday, October 28, 2012

How to exploit CSRF vulnerability(CSRF tutorial)?

Today, I'm going to explain you about WEB vulnerability that not everyone knows...but it very popular.This vulnerability is very dangerous and effective.Usually, the vulnerability exploiting never leave evidences.This vulnerability called: Cross Site Request Forgery(CSRF).CSRF and the way to exploit it is extremely easy; Much easier then all the complicated injections.

How does it works?

It works by forcing the slave's browser to run HTTP requests in order to implement a range of actions, for example :
  • Permission faking\stealing.
  • Transfer of funds from the Bank
  • Disruption of the normal sequence of the site
And much more.
Requirements to exploiting CSRF.
  • Make sure that the slave have SESSION \ COOKIE on the target site.
  • slave must be identified by the network protocol verification (HTTP Authentication)                                                                                                  
Actually, In order to cause the slave to perform unwanted actions he is not aware of, the slave must be logged to the target site with cookies and verified by the browser \ server.

Common uses CSRF attacks.

Common attack is using the image tag (img src) in the HTML document. I mean, in the SRC of the image tag must be inserted malicious link should send HTTP requests to the target, such as a GET request can be excellent. The benefits of using an image tag on the normal link tag (a href) are :
  1. Image tag does not require clicking the link compared Tag-A requires clicking on the link to activate the HTTP request.
  2. Nature of browsers is to send HTTP requests to visual objects such as picture or remote files (CSS, JS, etc.) even while loading the page without the user's permissions. This means the user does not need to perform any action in order to see the image on the page, all he has to do is go to a certain site specific browser sends HTTP requests have to load the image. In this case, since the browser recognizes the HTML code of the image tag, it sends HTTP requests to load the image even if the SRC of the image is not really a picture, but a malicious link ...

For those of you that uses Fire-Bug(Firefox add-on) can see in the next snapshot example of sending an HTTP request from the browser to the server to load an image during the login of the user:
csrf-tutorial

Also, CSRF attacks can be implemented not only through websites but through email messages. Since the mail boxes allow sending data to HTML format, the attached image perfectly legal. In this case I can send a malicious email message to huge amount of recipients, put a photo tag email body when the SRC contain a malicious link, when the slave opens the email, the desired action done.


Exploiting code examples: 


HTML
Using img tag:
PHP Code:
<img style="display:none;" src="http://targetsite.com/change_password.php?new_password=123456">

Using iframe tag:
PHP Code:
<iframe src="http://targetsite.com/change_password.php?new_password=123456"></iframe>

Java Script
using image object.
PHP Code:
<script>
var poniz = new Image();
test.poniz = "http://targetsite.com/change_password.php?new_password=123456";
</script>

Exploiting sequence

Here a cool example that actually belong to Black-SEO.
What I want to check in my user control panel is the parameters are sent as a request to HTTP server when I'm updating my home page via the user control panel.
There are a variety of fields that can be updated, such as address, phone, email, name, content, and most importantly for this example: The favorite website\home page address.
These parameters are sent to the server when updating my website address. So it seems to Firebug: 
csrf-tutorial

 
These parameters are sent to the server using POST method. So we do not see the parameters in the URL address. But, if the parameters will be written via GET method, the data will sent? Let's see.
Code:
http://targetsite.com?users.php?db[webaddress]=http://www.PonizSite.com&action=save
It works! (Actually...in the server-side code(php), the variable was in REQUEST method...but it's not matter)

Now ... Imagine that Dork like this one:
Quote:
site:targetsite.com & intext:"Homepage" & intext:"email: "

Now, I've got all the emails of users and I can send them an emails with img tag, and when they will open it, their home page\website addressfield in their profile will change(To http://www.ponizSite.com) Oui

How to prevent?

There are not many hermetical familiar solutions to prevent CSRF attacks.
Except from one: Tokens.
What are actually tokens? This is a hidden random ID responsible for sending structured data, such as logging into forms, forms that allow registered users to update data or home page(in our case Evilgrin)


<input type="hidden" name="8pssf18ssdmf8s7p80fodi" value='1' id="token" />

Since the tokens are defined, the attacker can not know what is the token of the slave, because every loading of the page the token will change to other random number\string.

Tips :
  • Don't forget to delete your cookies.
  • Use tokens(Captcha is safer).
  • When you built your php site, don't use GET \ REQUEST super-global variables.

Saturday, October 27, 2012

Online Hacking tools

Here are some online hacking tools. If your internet connection is slow then you don`t want to download some security software for just information gathering & exploit searching. So you can use online website for this purpose, although big advantage is your i.p is not directly flashing to victim. If you use proxy then it`s more secure because website don`t have your i.p also.

http://www.novirusthanks.org/(Online File Scanner)
http://www.virustotal.com(Online File Scanner)
http://anubis.iseclab.org/(Online File Scanner)
http://www.ipvoid.com/(IP Address scanner)
http://www.threatlog.com/(HoneyPot Database)
http://www.idoproxy.com(proxy)
http://whois.domaintools.com/(Whois lookup)
http://www.robtex.com/(swiss army knife internet tool)
http://www.netirk.com/(Pinger)
http://www.ahbl.org/lktool(IP Lookup)

http://www.blocklist.de/
http://www.cirt.net/passwords(Default password list)
http://www.cirt.net/ports(Default Ports List)
http://www.urlvoid.com/extract-url/(URL Shortener extractor)
http://www.urlvoid.com/http-headers/(Show the HTTP headers of a link)
http://www.urlvoid.com/find-parasites/(Find Parasites)
http://www.urlvoid.com/url-dump/(URL Dump)
http://www.fail2ban.org/wiki/index.php/Main_Page( For your website)
http://www.nmap.org(port scanner)

Exploit Search:

Acknowledged By Adobe Security Team


About three months back I reported an XSS (Cross Site Scripting) vulnerability in Adobe, Recently i came to know that Adobe has finally managed to fix the vulnerability after three long months. XSS for those of you who don't know is a web application vulnerability which enables the attacker to inject your own javascript inside the webapplication. XSS, at times can become so dangerous that it could enable an attacker to compromise your entire computer system apart from stealing your cookies and redirecting you to phishing pages.
You can find my name under the "Adobe Security Researchers Acknowledgement Page":

http://www.adobe.com/support/security/bulletins/securityacknowledgments.html

PROOF OF CONCEPT



Pass the comments!

Automatically Bypass XSS Filter With Snuck


Snuck is a Selenium based automated tool programmed, which is different from typical web security scanners, to help discovered XSS vulnerabilities in web applications. It's approach is related to the inspection of the injection's reflection context, specialising them in order to increase the success rate of breaking a given XSS filter. The attack vectors are chosen on the basis of the reflection context (the pinpointed location where the injection falls in the reflection web page's DOM). This is possible through Selenium web driver that allows to duplicate operations in web browsers. It requires an XML configuration file to be filled in order to make snuck a wiz at what it needs to do with respect to the test web application. It supports Mozilla Firefox, Google Chrome and Internet Explorer and the XSS testing in performed on a real web browser to mirror the attacker's and (possibly) the victim's behaviour.


Snuck is a Java-based open-source software and is released under the Apache 2.0 license. To download you can use the following source using snv:

svn checkout http://snuck.googlecode.com/svn/trunk/ snuck-read-only

Once done, you can use the build.xml for Ant to compile the source files and generate the jar file
cd snuck-read-only
ant jar

Then you will be able to generate an executable jar file which is ready to run.

You can also download it via a ready-to-run executable jar by click here.

We would like to mention here that you just need a working JVM and Firefox to run this software. To run a test with Google Chrome/Chromium, you must download and use the appropriate server which is a bridge between the web browser and the driver.

To run the software on Internet Explorer and its appropriate server please refer to the following link.

You will also need to familiarise yourself with the command line options. Below you can find the available arguments and the correspondent description:

>java -jar snuck.jarUsage: snuck [-start xmlconfigfile ] -config xmlconfigfile -report htmlreportfile [-d # ms_delay] 
[-proxy IP:port] [-chrome chromedriver ] [-ie iedriver] [-remotevectors URL] [-stop-first]
[-reflected targetURL -p parameter_toTest] [-no-multi]
Options :

 
-start         path to login use case (XML file)
 
-config        path to injection use case (XML file)
 
-report        report file name (html extension is required)
 
-d             delay (ms) between each injection
 
-proxy         proxy server (IP: port)
 
-chrome        perform a test with Google Chrome, instead of Firefox. It needs the path to the chromedriver
 
-ie            perform a test with Internet Explorer, instead of Firefox.
                 
Disable the built in XSS filter in advance
 
-remotevectors use an up-to-date online attack vectors source instead of the local one
 
-stop-first    stop the test upon a successful vector is detected
 
-no-multi      deactivate multithreading for the reverse engineering process - a sequential approach will be adopted
 
-reflected     perform a reflected XSS test (without writing the XML config file)
 
-p             HTTP GET parameter to inject (useful if -reflected is setted)
 
-help          show this help menu

Sample Scenarios and How-Tos According to Google:

  • Scenario I: Stored XSS
     Let us assume to have an e-commerce web site, which allows sellers to modify the description of their items. Items' descriptions are publicly accessible, thus leading to stored XSS in the case of XSS filter bugs. Testing the XSS filter needs three steps to be performed before landing in the reflection page. Since the injection is reflected within a P html element, the tool will reverse the fi lter and report the allowed tags and attributes in the final report. Obviously detected XSS are reported as well. See the following image for better understanding the context.



    In the aforementioned case snuck need to know which operations are required to connect the injection page, that is the web page in which the malicious payload is supplied, to the reflection one, that is the web page in which the payload is reflected. This task can be done by passing an XML configuration file, such as the following. In particular every <command> reports a tuple in the form of Selenium commands, refer to Selenium selectors for further information. 
<?xml version="1.0" encoding="UTF-8"?>
<root>
 
<post>
       
<commands>
           
<command>
               
<name>open</name>
               
<target>http://wtfbay.com/modify.php?id=90</target>
               
<value></value>
           
</command>
           
<command>
               
<name>type</name>
               
<target>name=name</target>
               
<value>${RANDOM}</value>
         
</command>                                                                    
         
<command>
               
<name>type</name>
               
<target>id=description</target>
               
<value>${INJECTION}</value>
           
</command>
           
<command>
               
<name>click</name>
               
<target>name=submit</target>
               
<value></value>
           
</command>
         
<command>
               
<name>select</name>
               
<target>id=cat</target>
               
<value>Bike</value>
           
</command>
           
<command>
               
<name>click</name>
               
<target>name=submit</target>
               
<value></value>
           
</command>
       
</commands>
   
</post>
</root>
In addition, since it is obvious that a login operation is required for managing our items, then another XML configuration file is needed.
<?xml version="1.0" encoding="UTF-8"?>
<root>
   
<post>
       
<commands>
           
<command>
               
<name>open</name>
               
<target>http://wtfbay.com/login.php</target>
               
<value></value>
           
</command>
           
<command>
               
<name>type</name>
               
<target>name=user</target>
               
<value>admin</value>
           
</command>                                                                                                  
           
<command>
               
<name>type</name>
               
<target>name=pwd</target>
               
<value>admin</value>
           
</command>
           
<command>
               
<name>click</name>
               
<target>name=submit</target>
               
<value></value>
           
</command>
       
</commands>
   
</post>
</root>
So far so good, now, how can we start the tool? By assuming that we want an HTML report named report.html and the aforepresented XML files are named usecase.xml and login.xml, then:

> java -jar snuck.jar -config usecase.xml -report report.html -start login.xml


What will the tool do? Basically the tool will firstly reverse engineer the HTML filter used against the user-supplied description, then it will start injecting multiple attack vectors and check whether an XSS is triggered - the important point here is that alert dialog windows are grabbed in order to decide whether an injection is successful; this means that false positive rate is equal to 0 as a vulnerability is reported just in case an alert dialog window is grabbed by the used web browser (note that this is automatically performed).
  • Scenario II: Stored XSS
  •  Let us assume to have a blog, which allows visitors to leave comments. As in the previous case, our goal is to bypass the filter the web application is using against user generated content. Since the tool just need to fill some field and perform the attack, this is actually comparable to a fuzzy approach. See the following image for better understanding the context:.

The XML configuration file (use case) and the necessary parameters for starting snuck are reported below.
<?xml version="1.0" encoding="UTF-8"?>
<root>              
   
<post>                                                                                                      
         
<parameters>
           
<parameter>
               
<name>username</name>
               
<value>hal9001</value>
           
</parameter>
       
</parameters>
       
<commands>
           
<command>
               
<name>open</name>
               
<target>http://examplecom/post.php?id=90</target>
               
<value></value>
           
</command>
           
<command>
               
<name>type</name>
               
<target>name=name</target>
               
<value>${USERNAME}</value>
           
</command>                                                                                      
           
<command>
               
<name>type</name>
               
<target>id=comment</target>
               
<value>${INJECTION}</value>
           
</command>
           
<command>
               
<name>click</name>
               
<target>name=submit</target>
               
<value></value>
           
</command>
       
</commands>
   
</post>
</root>
java -jar snuck.jar -config usecase.xml -report report.html
 The remarkable points here are that variables can be defined through the <parameter> tags and referenced by using strings in the form of ${variable_name}. In addition you can use ${RANDOM} or ${RANDOM_EMAIL} within <value> tags for asking the tool to supply a random alphanumeric string or a random email.

  • Scenario III: Reflected XSS
  •  Here we present a basic scenario in which the value of an HTTP GET parameter is reflected in a web page, in particular in the attribute value of an input element, whose type is setted to hidden. As usual, we want to test whether injecting this parameter could result in a reflected XSS vulnerability - see below for the XML configuration file and how it is possible to start snuck - in this case we have two different opportunities.


<?xml version="1.0" encoding="UTF-8"?>
<root>
   
<get>
       
<parameters>
           
<targeturl>http://example.com/xss.php</targeturl>
           
<reflectionurl></reflectionurl>
           
<paramtoinject>param</paramtoinject>
           
<parameter>foo=bar</parameter>
       
</parameters>
   
</get>
</root>
> java -jar snuck.jar -config config.xml -report report.html 
# faster mode (no XML file required)
> java -jar snuck.jar -report report.html -reflected "http://example.com/xss.php?foo=bar" -p param
 Note that the <reflectionurl> can be used for asking the tool to make the injections at <targeturl> and to look for reflections at the URL defined with <reflectionurl>.

Further information Sometimes it might be useful to discover the first successful injection without realizing a complete test. This task could be achieved through the argument -stop-first, which makes the tool stop at the first positive, it will find. In addition, you could obviously stop the test through CTRL+C, if so, then the tool will print in stdout the successful injections that it found so far.

Click on this link to download Snuck.

Cheers!

About The Author

This article is written by Sindhia Javed Junejo. She is one of the core members of RHA team.