(BEING CONTINUED FROM 18/10/10)
3.2 Cross-site profile cloning
In the cross-site profile cloning attack, our aim is to identify victims who are registered in one social network, but
not in another. Our first aim, from the attacker’s point of view, is to steal their identities and create accounts for them
in the network where they are not registered. Note that this attack is more difficult to detect by the social network service provider or the legitimate owner of the copied profile.
As far as the service provider is concerned, a new user is registering to the network.
When creating an identical account in another social network, we try to retrieve as much information as possible from
the victim’s original account in the other network. Clearly, the type of the social network is relevant when forging accounts. That is, it is much easier for an attacker to create forged accounts in social networks of the same nature. For
example, both XING and LinkedIn are focused towards business connections. Therefore, the type of information that
users provide in their profiles are of similar nature. Typically, users provide information on their education, their
previous jobs, their current jobs and the city and country they live in. The current iCloner implementation is able to
automatically compare and forge accounts from XING to LinkedIn.
Our second aim, after the stolen identity has been created,is to identify the friends of the victim in the original network
and check which of them are registered in the target network.
To determine with certainty if a friend of the cloned contact is already registered on a different social network is
not as straight-forward as it may seem. A simple search for the name of the user may return multiple accounts. As
mentioned previously, people might exist on social networks who have identical names as other people. Real names, after
all, are known not to be unique. For example, looking for a person with the name “Hans Bauer”, a common German
name, on Facebook returns 62 different user accounts.
In order to determine with a high probability if a certain user already exists on a social network, we need to look
at more information associated with that specific user. We have created a simple scoring system and use a threshold
to decide if two accounts with the same name on different networks correspond to the same person. In our comparison,
we assign 2 points if the education fields match. According to our experience, it is not very likely that two different users
have the same name and the same educational background.
If the companies where the users are employed are identical,we assign 2 more points. Finally we assign 1 point if the city
and the country where the users are living are also identical.
We sum up all the assigned points and if the total score is at least 3, we conclude that the two profiles belong to the
same user.
One question we have not discussed yet is how we determine if the information entered by a user in two social
networks is identical. In our experiments, we saw that some users may enter differing names for the same type of information. For example, a user may choose to enter “TU Wien” as the educational institution in social network A,
and enter “Vienna University of Technology” in social network B. Both entries identify the same institution, but the
comparison would fail if we simply compare the two strings.
The solution we use is to start a Google search with both terms. Then, we compare the first top three hits. If both
terms appear in the top three of the Google search hit list,we decide that both entries are equivalent. Figure 2 depicts
the process we use to identify users on two different social networking sites.
Once the contacts of a victim have been identified, our system can then start sending automated friend requests
to these identified users. As far as the contacted users are concerned, a friend request is coming from someone who is
not on their friend list yet. As a result, our expectation is that most users will accept this request without becoming
suspicious. After all, it is the nature of social networks that people get connected by receiving friend requests from time
to time from people that they know.
4. EVALUATION
In order to verify the feasibility of our attacks and tools,we conducted real-world experiments with real users. The
best way to demonstrate our attacks would have been to start large scale attacks on a large number of real users.
However, attacks of this magnitude would have been ethically questionable, and could have lead to legal consequences.
We first started and tested our crawler on two social networks with the aim of collecting large volumes of contact
lists and public user profile data. We then performed profile cloning attacks and contacted more than 700 distinct users.
In a third experiment, we launched cross-site profile cloning attacks and contacted 78 distinct users who were registered
on two different social networks.
As we performed our experiments on real user profiles,for each profile we cloned, we requested the permission of
the user who was concerned. Furthermore, we committed to making every action we performed transparent to the
rightful owners of the profiles. After the experiments, we informed the users who were contacted of our experiment,
and also disabled the cloned accounts that we had generated.
In a third experiment, we launched cross-site profile cloning attacks and contacted 78 distinct users who were registered
on two different social networks.
As we performed our experiments on real user profiles,for each profile we cloned, we requested the permission of
the user who was concerned. Furthermore, we committed to making every action we performed transparent to the
rightful owners of the profiles. After the experiments, we informed the users who were contacted of our experiment,
and also disabled the cloned accounts that we had generated.
4.1 Crawling Experiments
In our crawling experiments, we created a small number of accounts on StudiVZ, MeinVZ, and XING and ran the
crawler component of iCloner.
4.1.1 StudiVZ and MeinVZ
First, we created 16 user accounts in these social networks.
Then, in order to keep a low profile, we implemented small delays for each page request. For each CAPTCHA request
we received, we used our CAPTCHA breaking tools.
Initially, we expected the crawlers to request roughly 100,000 web pages per day, thus retrieving the complete profile
information and contact lists of roughly 15.000 accounts (as the contact lists are split and presented in groups of 15
contacts – with an average number of contacts per account being around 100).
Each crawler instance requested and parsed around 6000 web pages per day and encountered on average around 215
CAPTCHAs to break. Because of the little effort needed to break the CAPTCHAs, our crawlers were able to collect
information from 40.000 profiles per day, which by far exceeded our expectations.
We stopped the experiment after we had crawled more than 5 million public user profiles with contact information
and more than 1.2 million profiles with complete user information.
4.1.2 XING
Our experimental setup for XING was similar to the setup with StudiVZ and MeinVZ.
Interestingly, XING does not contain any CAPTCHA protection in order to prevent automated crawling. However,
the service providers were more efficient in disabling accounts that were generating a high number of requests. Nevertheless, we were able to crawl around 2000 profiles with each account that we generated before our account was disabled.
Since the target is to access protected data through cloning and an attacker in this process would constantly
create new accounts, this average of accessable profiles per forged account is still more than sufficient.
For XING, we crawled around 118,000 profiles in total,before we stopped the experiment.
(TO BE CONTINUED)
Leyla Bilge, Thorsten Strufe, Davide Balzarotti, Engin Kirda
EURECOM
Sophia Antipolis, France
AT THE SESSIONS ABOUT WEB SECURITY
SOURCE WWW 2009 MADRID
WE THE ECOUMENISTS exontes zilon FOR AN OECOUMENIC POLIS 