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.

• Gmail Cookie Stealing And Session Hijacking Part 1
• Gmail Cookie Stealing And Session Hijacking Part 2
• Gmail Cookie Stealing And Session Hijacking Part 3

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

• Cain And Abel
• Wireshark
• Cookie Manager Plus (FIREFOX ADDON)

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

Read More

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!

Read More

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.

Read More

Blogger Blogs Redirecting To "blogspot - ping . com"

Today, we see the latest in the never ending saga of blog owners, who previously (maybe / maybe not recently) installed some deviously created software - whether intentionally or not - and who now find their readers unable to view their blogs, and themselves even unable to access the template editor to remove the malicious code.

My blogs are redirecting auto to ping . blogspot - ping . com", can anybody tell me how to fix this?

The malicious redirecting appears to be cause by a small snippet of JavaScript code - which has been installed, in most cases, as template HTML. Alternatively, some blog owners have added separate HTML / JavaScript gadgets, to host this code.

It's easy enough to identify - not so easy to remove, as some owners have found. In many cases, we are seeing reports that even when directly accessing the Layout wizard or Template Editor, the malicious code activates, and redirects the blog owner's browser.

Since the redirect is running from a snippet of JavaScript code, blocking the malicious code will prevent the redirection, and allow corrective access to the Layout wizard or Template Editor.

<script src='http : // ping . blogspot - ping . com / ping . js' type='text/javascript'></script>

Whichever GUI wizard you use to remove the code, remember to clear cache and restart the browser after removal and before testing for success.

Since I routinely - and consistently - use Firefox with NoScript to browse, I was able to access one victim blog without the redirection occurring, view the blog source, and extract the above code. If you use NoScript, you (the blog owner) should be likewise able to access your dashboard, and the Template Editor, and remove the bogie.

Please note that the code snippet, excerpted above, has extra spaces inserted into the URLs, to prevent advertising of the actual hijacking domain.

Anybody who knows where this bogie originated, and how it was deviously conned upon the blog owners, can help a lot of people by identifying the origin. Only when this is done, can we try to prevent the problem - rather than advise how to remove the problem.

First, install the popular Mozilla browser, Firefox. Having added Firefox, install the add-on NoScript. NoScript uses a Unix level security policy.

Deny by default, permit by exception.

Keep in mind the different trust levels of Blogger and BlogSpot - with NoScript, you will have to allow Blogger, yet forbid BlogSpot. Code from unknown domains, such as "blogspot - ping . com", will not run on any NoScript protected computer - unless you, intentionally, enable it. Knowing the threat from this bogie, you will hopefully choose to not enable this domain.

>> Top

Read More

What Is Project Tyler? Anonymous Reveals

Wikileaks is known worldwide for providing a common man with many delicate information about his/her country’s government. It had caused several troubles in the past compromising scandalous information. Being inspired by it, the anonymous group had decided to do create a similar portal to slip out information regarding sensitive matters to the public without any censorship. They are naming this project as “Tyler”.

What sounded surprising was that anonymous group decided to build another portal instead of working together with Wikileaks. One of the members representing the group spoke to the Voice of Russia about their rift with Wikileaks and their “Tyler” project.

He said that “Tyler” would be way more transparent to the public in matters of funding techniques. “Tyler” will be available to public on the doomsday this year. Although, not working together, anonymous still shows that it supports the efforts of Julian Assange and has even helped to acquire millions of emails.

This collection has been called the Syrian file. Being the cyber geeks they are, anonymous have found out an ingenious way to lower the costs and prevent any attacks on “Tyler”. The solution-no website! This may sound imbecile but is actually quite smart. All the information will be shared with peer to peer network. In this manner, the files will be seeded by millions of people always and there is no rational method of stopping these transfers. Since no files will be uploaded on the servers, it would be senseless to attack “Tyler” once the damage has been done! 

On being asked about Julian  Assange, the hacker said- “Julian has threatened on at least one previous occasion to pull the plug on the project because the fundraising was not meeting his expectations. It was at that time that Anonymous began planning to field our own alternative disclosure platforms. Julian desperately needs WikiLeaks, and he is the only one that can pull the plug on the project. I rather think that so long as he is in dire straits, he will not do so despite any threats from him to the contrary.” Let’s hope he shares the view of the entire anonymous organization and benefit everyone.

Read More

Ethical Hacking Vs Penetration Testing

Recently a reader posted a comment on our previous post "jSQL Injection - Java GUI for Database Injection.", where he asked about the difference between Ethical hacking And Penetration testing, As i said in the reply of that comment that it has been highly debatable topic among security researchers and hackers. According to some people "Hacking" cannot be Ethical in any way and lots of people do not like to associate the term "Ethical hacker" with them. According to some people both of them have same meaning and the term "hacker" is used to attract people for their courses and training programs.


However, the opinion of the people on the other side is that "Ethical hacking" should not be confused with Penetration testing and both of them are different terminologies and have different goals.

According to Ec-Council:

Penetration Testing: 
A goal-oriented project of which the goal is the trophy and includes gaining privileged access by pre-conditional means. 

Ethical Hacking: 
A penetration test of which the goal is to discover trophies throughout the network within the predetermined project time limit.

I found a more better explanations for both of these terms on likedln group discussion:

A penetration test is a formal set of procedures that measure an organizations security, are sanctioned by the organizations business and seek to improve the organizations security. 

Hacking is a very broad term. It's original meaning was simply to program or create devices as creative outleta and for pleasure. It has now acquired a darker meaning though among practioners, both meanings are used and context defines the sense of it. 

A hacking approach, to Pen testing can be useful because it would seek to find novel means of penetration before an attacker does. It still needs to be sanctioned and it should be done with a view to maintaining the clients operational reliability. In short, the person doing the hacking should have real professional mastery and control of what they are doing. 

According to Pen-test.com:

Penetration testing is a more narrowly focused phrase, it deals with the process of finding flaws in a target environment with the goal of penetration systems, taking control of them. Penetration testing, as the name implies, is focused on penetration the target organization’s defenses, compromising systems and getting access to information.

Ethical hacking is an expansive term encompassing all hacking techniques, and computer attack techniques to find security flaws with the permission of the target owner and the goal of improving the target’s security while penetration testing is more focused on the process of finding vulnerabilities in a target environment. In short, penetration testing is a subset of ethical hacking.



I hope the above clears the difference between Ethical hacking and Penetration Testing.

Read More

jSQL Injection - Java GUI for Database Injection.

jSQL is an easy-to-use SQL injection tool that enables the user to retrieve database informations from a distant server.


jSQL injection consists of the following features:

• Get, Post, header, cookie methods
• Normal, error based, blind, time-based algorithms
• Automatic best algorithms detection
• Data retrieving progression
• Proxy setting
• Evasion

For now jSQL injection supports MySQL. And it requires the name of the parameter to inject and the distant server URL.

If you want to test drive the jSQL injection, you can save the following PHP code in a script (for example: simulate_get.php, and continue using the URL http://127.0.0.1/simulate_get.php?lib= in the first field of the tool, then click Connect to access the database:

<?php
    mysql_connect("localhost", "root", "");
    mysql_select_db("my_own_database");

    $result = mysql_query("SELECT * FROM my_own_table where my_own_field = {$_GET['lib']}") # time based
    or die( mysql_error() ); # error based

    if(mysql_num_rows($result)!==0) echo" true "; # blind

    while ($row = mysql_fetch_array($result, MYSQL_NUM))
        echo join(',',$row); # normal
?>

To download, please click on this link.

Cheers!

About The Author

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

Read More

HSBC Recovers from the DDoS Attack, Anonymous Claims to Have 20,000 Debit Card Details.

Many HSBC customers were unable to log in to their internet banking accounts on Thursday, 18th of October. It has been stated that the problem started a little before 20:00 BST and lasted for around seven hours.



Later, an Anonymous hacker group named 'FawkesSecurity' took the liberty to announce that they were responsible for the problem that halted many HSBC account holders from accessing their accounts. The problem was a DDoS attack on the website itself. Which enabled them to steal details of 20,000 debit cards. To find out how you can use DDoS to attack a system, please follow this link.

HSBC soon recovered from the attack and the security researchers came to the conclusion that the attack largely resulted from botnet networks of malware-infected PCs.

HSBC was quick to come out with an statement to reassure their clients that their sensitive data had not been exploited in the attack.

"On 18 October 2012 HSBC servers came under a denial of service attack which affected a number of HSBC websites around the world.This denial of service attack did not affect any customer data, but did prevent customers using HSBC online services, including internet banking.
We are taking appropriate action, working hard to restore service. We are pleased to say that some sites are now back up and running.
We are cooperating with the relevant authorities and will cooperate with other organisations that have been similarly affected by such criminal acts.
We apologise for any inconvenience caused to our customers throughout the world."

In response to this statement, Anonymous tweeted that:

When HSBC said ''user data had not been compromised'' This isn't entirely correct. We also managed to log 20,000 debit card details.

It seems like Anonymous is bewildered on whether to prove to the world that they in fact do have the sensitive information that HSBC denies.

"Were debating whether to release them or not, HSBC knows debit details were intercepted, They probz won't admit it tho."

Darren Anstee, EMEA solutions architect team lead at Arbor Networks, said in reference to the attack:

“Recent attacks have used what we call multi-vector attacks, attacks which utilise a combination of volumetric, and application layer attack vectors. What we are seeing here are TCP, UDP and ICMP packet floods combined HTTP, HTTPS and DNS application layer attacks. Attackers are doing this because they know it makes the attacks more difficult to deal with, but not impossible if we have the right services and solutions in place." ®

HSBC has fully recovered from the attack and its websites are working perfectly now after being restored, according to their statement on their official website.

On the other hand, there have been unconfirmed reports of a group known as Izz ad-Din Al Qassam being behind the attack. They have been responsible for over 9 attacks on various banks in the US of A as a part of their current campaign which is to have the Innocence of Muslims video removed from YouTube and the Web all over.

A part of Izz ad-Din Al Qassam's statement reads:

With a little searching, we still found the anti-Islamic offensive film on the Internet. Thus the chain of cyber attacks on U.S. banks will continue this week. These attacks will be done since Tuesday, 16 October until Thursday, 18 October 2012 in midday hours. We know that banks officials are concerned and waiting to see this time it is the turn of which banks. For making variation in operation, this time we give them the opportunity to understand whether they are listed or not.

We aren't sure who the real attackers are but according to the reports being received, RBS, Llyods TSB and Barclays banks are going to be next.

For a read on the DDoS attacks for the year of 2012, DDOS Attacks In 2012

Cheers!

About The Author

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

Read More