Posted 13 years ago
·
Author
BlueCava
Tutorial by
DeadLock Inc.
Functions
*fraud
*targeting
*device identification
*targeted advertising
*device fingerprinting
*online advertising
Identifaction
Device identification (also called “machine identification”) is widely used today by
financial organizations to reduce fraud. This system “learns” the devices each
user uses to access the website and warns when the user, or an attacker, tries to
sign into the website using an unrecognized device.
It is a common belief that device identification can be used to defeat most
clientside attacks such as phishing, pharming, and keyloggers. This paper
demonstrates three very simple attack vectors, all variants of known attacks,
which completely bypass device identification. This paper further explains why
device identification is not a real-time barrier for attackers and why online
businesses cannot rely on it to reduce fraud.
What is Device Identification?
EXAMPLES
Regular (HTTP) Cookies
This mechanism operates in the following manner: the website
places a permanent cookie on the user’s device, which uniquely
identifies the device. The website verifies the cookie each time the
user signs in. If the user signs in without the cookie or with an
invalid cookie value, the website assumes that the user is
connecting from an unrecognized device.
Cookies are commonly used to identify clients. This mechanism is
well established through web standards and practice. However
legitimate they may be, privacy-oriented users tend to erase
cookies frequently, thus diminishing the effectiveness of cookies as
a long time device identifier. There are tools which can erase
cookies automatically when closing the browser.
Bypassing Device Identification
Flash Local Shared Objects (“Flash Cookies”)
This mechanism is very similar to the cookies mechanism. Instead
of storing a cookie on the user’s computer the website stores a
unique flash file that it uses to identify the computer.
The Flash client technology (by Adobe) has its own local permanent
storage, which is comparable to HTTP cookies. Moreover, the Flash
client is ubiquitous, which makes a great deal of sense in its use.
Lastly, unlike HTTP cookies, Flash cookies are less known and as
such are much less subject to premature erasure.
Browser (and O/S) properties
The browser type, version, and related information (operating
system, patch level, supported players, screen resolution, time
zone) can be obtained either from the User-Agent HTTP request
header, or by running Javascript on a page rendered by the
browser (using the Navigator DOM object). This information is
usually always available. The website is able to store this
information in its database and validate it each time the user tries
to sign in. However, parts of this information may change (e.g.
upgrading the operating system, installing patches,
installing/removing support to various media formats), so
considerable care and attention must be paid when handling such
situations.
Negative Example: source IP address
A very naïve suggestion would be to use the source IP address as a
differentiator between machines. However, this approach is bound
to fail due to multiple reasons:
• Dynamically assigned IP addresses (by ISP's) would cause
the same device to be regarded as two different devices.
However, as long as the user connects from a single ISP,
that ISP can be identified (as a group of IP's, rather than
identifying the user by a single IP)
• A user may connect through hot-spots. The device remains
the same, but the IP's are now owned by different ISP's.
This, therefore, effectively dismisses the “group by IP” idea
above.
• Corporate/ISP Proxy server triggers all of the users from the
respective corporate/ISP to be observed as coming from a
single IP.
It seems, therefore, that source IP addresses are not a good choice
for device identification
Device Fingerprinting
Device fingerprinting works by computing a unique id for the device that you use to access a particular web application. This can be one or more of the web browser type (ie, firefox, opera), screen resolution, IP address, installed plugins on your web browser, etc. There are two ways to obtain this information. One way is to use JavaScript. But the information that you can obtain using JavaScript is limited due to the restrictions on JavaScript. Another way is to let users download a client program (eg. ActiveX control or Java applet or even an executable file) that can access the system and create a unique fingerprint.
The fingerprint itself is generated by creating a hash of all the values obtained. For example, the screen resolution, IP address and web browser user-agent can be concatenated and hashed using a hashing algorithm such as SHA. If any of the information or the even the order of the information is changed, the hash will change resulting in an authentication failure.
Once that is done, whenever the user visits the appropriate website, the fingerprint is sent by the browser as a cookie value. The web application then searches for the owner of the device fingerprint in its records and identifies the user. If this is the only thing that the website requires for authenticating a user, the site is in major trouble. That is because, anyone who can provide that device signature can impersonate the original user.
We talked about the two ways to create the signatures. The most common way is to use JavaScript to compute the signature. One of the problems mentioned earlier is the restriction that it cannot access system resources. With the things that it can access, there can be duplicate signatures.
Consider a large organization that provides laptops (or desktops) to groups of employees. Each group (Dev, QA, etc) may have a specific hard-disk image that the laptops are loaded with. The image will make sure that all the users use the same versions of all the software with the same plugins, screen resolutions, etc. Depending on what the device fingerprint is generated from all the laptops that have the same hard-disk image can end up with the same device fingerprint.
The problem with the second method that involves downloading software to generate the fingerprints can face resistance from users. Even if they downloaded the software, the signatures can be stolen and replayed by an attacker, resulting in impersonation of the original user.
Solutions
Malware
Using a malware is probably the easiest way to bypass device
identification. A malware is a piece of software that sits on the victim’s
computer. A malware that overcomes device identification would collect
device identification parameters from the victim’s computer and send
them to the attacker. The simplest way to achieve that is by copying the
JavaScript code used by websites to enforce device identification and then
run it on the victim’s machine. The JavaScript code collects all the
information required to complete a successful device identification process.
Note that since it a JavaScript code, the attacker can actually view it by
simply choosing “view source” from the browser’s menu. In addition, the
attacker needs to collect all cookies and flash objects that are associated
with the targeted website.
Here is a summary of the steps an attacker needs to perform in order to
bypass device identification using a malware:
1. Browse to a targeted website (for example IMVU) which
uses device identification Bypassing Device Identification
2. In the website’s login form, view source and look for the JavaScript
code that collects device parameters (such as OS version. See 1.2.3
for more information)
3. Copy this code and use it in the malware to collect the same
parameters from the victim’s computer
4. If the targeted website is not using a JavaScript code to collect device
parameters then it probably uses HTTP headers to collect this
information. In this scenario, include a code that copies all HTTP
headers from the victim’s computer
5. Add a simple code that collects all cookies and flash files that are
associated with the targeted website
6. Add a code that sends this information back to the attacker
7. Distribute the malware and wait for the results
Once the attacker receives this information from the malware a few
additional steps are required in order to ultimately sign into the victim’s
account:
1. place the cookies and the flash files on the attacking computer
2. install a local proxy such as Paros
which allows you to control and edit
requests your browser sends to the website
3. browser to the attacked website
4. when receiving the login form with the device identification JavaScript,
edit the next request manually and provide the collected identification
parameters as inputs, instead of the input the JavaScript collected
from your computer
5. using the same technique, change the HTTP headers to match the
headers collected from the victim’s computer
The above described attack is very simple to execute. Building the
malware requires no real expertise and can be completed in a few hours of
work, even if the attacker starts from scratch and does not use available
code. Building an environment that simulates the victim’s environment is
also very simple to do and requires only a couple of hours of work.
To sign into the victim’s account the attacker would probably use a
publicly available network such as a StarBucks WiFi network and would
avoid botnetted computers as these computers are often black-listed by
device identification solutions. A slightly more sophisticated attacker would
also collect network parameters from the victim’s computer, such as the
ISP used by the victim. The attacker can then register to the same ISP
and launch the attack while connected to the ISP network. This would
overrule any suspicion the website might have in the attacker’s IP
address.
Session Hijacking
HTTP is stateless and does not include inherent mechanisms to track
users. To bypass these problems, web applications are relying on session
identifiers that are usually in the form of cookies or HTTP parameters.
When the user accesses a website, the website generates a session
identifier (a unique number or string) and sends it to the user as a cookie
or a parameter embedded inside a form. As a result, the user’s browser
sends this session identifier back to the website with each HTTP request.
This allows the website to easily track HTTP requests originating from the
same user. When the user authenticates to the website, the website marks
the specific session as authenticated and from now on any HTTP request
that includes the specific session identifier would be considered as coming
from an already authenticated user. This means that if the attacker
manages to steal or hijack the user’s session identifier, the attacker would
be able to access the user’s account without having to authenticate.
The easiest way of executing a session hijacking attack is through a crossside-scripting (XSS) attack. This attack takes advantage of a website
vulnerability in which the website displays content that includes unsanitized user-provided data. If the website is vulnerable to XSS the
attacker can craft a URL that once clicked by the victim would send the
victim’s session identifier to the attacker.
The URL appears legit as it
points to the targeted website. However, it allows the attacker to run
arbitrary JavaScript code in the victim’s computer. This code can grab the
victim’s session identifier and send it to the attacker. More information on
XSS can be found on OWASP’s website
It is reported that about 80% of websites suffer from XSS vulnerabilities.
Overall, XSS vulnerabilities are extremely hard to mitigate but are very
easy to exploit, therefore making this particular attack vector so
compelling.
As XSS allows attackers to run arbitrary JavaScript code on the victim’s
computer and steal cookies, it is also a perfect platform to bypass device
identification. Here are the steps an attacker needs to follow to execute
this attack
1. discover an XSS vulnerability in the targeted website
2. Craft a URL to exploit the vulnerability. The URL should run a
JavaScript that directs the user to a fraudulent sign in page. It should
steal the targeted website’s cookies, flash and identification
parameters (see previous section for more information on extracting
the JavaSacript from the targeted website). It should also grab the
victim’s credentials when the victim attempts to sign in
3. Distribute the link via email or any other channel (for example IM,
search engines, advertisements)
4. Receive the collected information
5. Repeat the process described in the previous section to sign into the
victim’s account
The attack is very easy to execute. The only barrier here is finding an XSS
vulnerability in the targeted website. However, experienced hackers can
find such vulnerabilities in almost any website and in a very short
timeframe.
To fight this attack the website can use HTTP Only cookies
that prevent a JavaScript from reading the content of cookies. However this mechanism
is still not widely supported (e.g. not supported by FireFox) and there are
some attacks that bypass it completely
Another limitation of XSS attacks is the difficulty of accessing flash files
through JavaScript code. There are several implementation specific ways
to evade the above limitation, such as invoking a Flash object using an
OBJECT tag. However, device identification mechanisms would usually
accept either cookies or flash, considering that flash can be removed by
the user. Thus an attack that grabs the victim’s cookies and device
parameters would succeed.
Browser Vulnerabilities
Browser vulnerabilities are common. The SecurityFocus Vulnerability
database consists of a wealth of vulnerabilities in Mozilla Firefox,
Microsoft Internet Explorer, and even Adobe Flash Player.
Attackers can easily exploit existing browser vulnerabilities to access
cookies on the victim’s computer and use this information to bypass the
device identification mechanism. This is accomplished using existing
unpatched vulnerabilities, as many users do not patch their systems or
using newly released vulnerabilities for which a patch does not yet exist.
Such vulnerabilities are sold today by hacking communities for a few
hundred dollars.
Exploiting browser vulnerabilities does not require much expertise. It
usually involves running the exploit code on the phishing website. Further,
device identification mechanisms are completely vulnerable to this attack
vector as they totally rely on the browser’s security model for their own
security. As a result, any breach in the browser’s security model can
immediately affect this mechanism
Tutorial by
DeadLock Inc.
Functions
*fraud
*targeting
*device identification
*targeted advertising
*device fingerprinting
*online advertising
Identifaction
Device identification (also called “machine identification”) is widely used today by
financial organizations to reduce fraud. This system “learns” the devices each
user uses to access the website and warns when the user, or an attacker, tries to
sign into the website using an unrecognized device.
It is a common belief that device identification can be used to defeat most
clientside attacks such as phishing, pharming, and keyloggers. This paper
demonstrates three very simple attack vectors, all variants of known attacks,
which completely bypass device identification. This paper further explains why
device identification is not a real-time barrier for attackers and why online
businesses cannot rely on it to reduce fraud.
What is Device Identification?
EXAMPLES
Regular (HTTP) Cookies
This mechanism operates in the following manner: the website
places a permanent cookie on the user’s device, which uniquely
identifies the device. The website verifies the cookie each time the
user signs in. If the user signs in without the cookie or with an
invalid cookie value, the website assumes that the user is
connecting from an unrecognized device.
Cookies are commonly used to identify clients. This mechanism is
well established through web standards and practice. However
legitimate they may be, privacy-oriented users tend to erase
cookies frequently, thus diminishing the effectiveness of cookies as
a long time device identifier. There are tools which can erase
cookies automatically when closing the browser.
Bypassing Device Identification
Flash Local Shared Objects (“Flash Cookies”)
This mechanism is very similar to the cookies mechanism. Instead
of storing a cookie on the user’s computer the website stores a
unique flash file that it uses to identify the computer.
The Flash client technology (by Adobe) has its own local permanent
storage, which is comparable to HTTP cookies. Moreover, the Flash
client is ubiquitous, which makes a great deal of sense in its use.
Lastly, unlike HTTP cookies, Flash cookies are less known and as
such are much less subject to premature erasure.
Browser (and O/S) properties
The browser type, version, and related information (operating
system, patch level, supported players, screen resolution, time
zone) can be obtained either from the User-Agent HTTP request
header, or by running Javascript on a page rendered by the
browser (using the Navigator DOM object). This information is
usually always available. The website is able to store this
information in its database and validate it each time the user tries
to sign in. However, parts of this information may change (e.g.
upgrading the operating system, installing patches,
installing/removing support to various media formats), so
considerable care and attention must be paid when handling such
situations.
Negative Example: source IP address
A very naïve suggestion would be to use the source IP address as a
differentiator between machines. However, this approach is bound
to fail due to multiple reasons:
• Dynamically assigned IP addresses (by ISP's) would cause
the same device to be regarded as two different devices.
However, as long as the user connects from a single ISP,
that ISP can be identified (as a group of IP's, rather than
identifying the user by a single IP)
• A user may connect through hot-spots. The device remains
the same, but the IP's are now owned by different ISP's.
This, therefore, effectively dismisses the “group by IP” idea
above.
• Corporate/ISP Proxy server triggers all of the users from the
respective corporate/ISP to be observed as coming from a
single IP.
It seems, therefore, that source IP addresses are not a good choice
for device identification
Device Fingerprinting
Device fingerprinting works by computing a unique id for the device that you use to access a particular web application. This can be one or more of the web browser type (ie, firefox, opera), screen resolution, IP address, installed plugins on your web browser, etc. There are two ways to obtain this information. One way is to use JavaScript. But the information that you can obtain using JavaScript is limited due to the restrictions on JavaScript. Another way is to let users download a client program (eg. ActiveX control or Java applet or even an executable file) that can access the system and create a unique fingerprint.
The fingerprint itself is generated by creating a hash of all the values obtained. For example, the screen resolution, IP address and web browser user-agent can be concatenated and hashed using a hashing algorithm such as SHA. If any of the information or the even the order of the information is changed, the hash will change resulting in an authentication failure.
Once that is done, whenever the user visits the appropriate website, the fingerprint is sent by the browser as a cookie value. The web application then searches for the owner of the device fingerprint in its records and identifies the user. If this is the only thing that the website requires for authenticating a user, the site is in major trouble. That is because, anyone who can provide that device signature can impersonate the original user.
We talked about the two ways to create the signatures. The most common way is to use JavaScript to compute the signature. One of the problems mentioned earlier is the restriction that it cannot access system resources. With the things that it can access, there can be duplicate signatures.
Consider a large organization that provides laptops (or desktops) to groups of employees. Each group (Dev, QA, etc) may have a specific hard-disk image that the laptops are loaded with. The image will make sure that all the users use the same versions of all the software with the same plugins, screen resolutions, etc. Depending on what the device fingerprint is generated from all the laptops that have the same hard-disk image can end up with the same device fingerprint.
The problem with the second method that involves downloading software to generate the fingerprints can face resistance from users. Even if they downloaded the software, the signatures can be stolen and replayed by an attacker, resulting in impersonation of the original user.
Solutions
Malware
Using a malware is probably the easiest way to bypass device
identification. A malware is a piece of software that sits on the victim’s
computer. A malware that overcomes device identification would collect
device identification parameters from the victim’s computer and send
them to the attacker. The simplest way to achieve that is by copying the
JavaScript code used by websites to enforce device identification and then
run it on the victim’s machine. The JavaScript code collects all the
information required to complete a successful device identification process.
Note that since it a JavaScript code, the attacker can actually view it by
simply choosing “view source” from the browser’s menu. In addition, the
attacker needs to collect all cookies and flash objects that are associated
with the targeted website.
Here is a summary of the steps an attacker needs to perform in order to
bypass device identification using a malware:
1. Browse to a targeted website (for example IMVU) which
uses device identification Bypassing Device Identification
2. In the website’s login form, view source and look for the JavaScript
code that collects device parameters (such as OS version. See 1.2.3
for more information)
3. Copy this code and use it in the malware to collect the same
parameters from the victim’s computer
4. If the targeted website is not using a JavaScript code to collect device
parameters then it probably uses HTTP headers to collect this
information. In this scenario, include a code that copies all HTTP
headers from the victim’s computer
5. Add a simple code that collects all cookies and flash files that are
associated with the targeted website
6. Add a code that sends this information back to the attacker
7. Distribute the malware and wait for the results
Once the attacker receives this information from the malware a few
additional steps are required in order to ultimately sign into the victim’s
account:
1. place the cookies and the flash files on the attacking computer
2. install a local proxy such as Paros
which allows you to control and edit
requests your browser sends to the website
3. browser to the attacked website
4. when receiving the login form with the device identification JavaScript,
edit the next request manually and provide the collected identification
parameters as inputs, instead of the input the JavaScript collected
from your computer
5. using the same technique, change the HTTP headers to match the
headers collected from the victim’s computer
The above described attack is very simple to execute. Building the
malware requires no real expertise and can be completed in a few hours of
work, even if the attacker starts from scratch and does not use available
code. Building an environment that simulates the victim’s environment is
also very simple to do and requires only a couple of hours of work.
To sign into the victim’s account the attacker would probably use a
publicly available network such as a StarBucks WiFi network and would
avoid botnetted computers as these computers are often black-listed by
device identification solutions. A slightly more sophisticated attacker would
also collect network parameters from the victim’s computer, such as the
ISP used by the victim. The attacker can then register to the same ISP
and launch the attack while connected to the ISP network. This would
overrule any suspicion the website might have in the attacker’s IP
address.
Session Hijacking
HTTP is stateless and does not include inherent mechanisms to track
users. To bypass these problems, web applications are relying on session
identifiers that are usually in the form of cookies or HTTP parameters.
When the user accesses a website, the website generates a session
identifier (a unique number or string) and sends it to the user as a cookie
or a parameter embedded inside a form. As a result, the user’s browser
sends this session identifier back to the website with each HTTP request.
This allows the website to easily track HTTP requests originating from the
same user. When the user authenticates to the website, the website marks
the specific session as authenticated and from now on any HTTP request
that includes the specific session identifier would be considered as coming
from an already authenticated user. This means that if the attacker
manages to steal or hijack the user’s session identifier, the attacker would
be able to access the user’s account without having to authenticate.
The easiest way of executing a session hijacking attack is through a crossside-scripting (XSS) attack. This attack takes advantage of a website
vulnerability in which the website displays content that includes unsanitized user-provided data. If the website is vulnerable to XSS the
attacker can craft a URL that once clicked by the victim would send the
victim’s session identifier to the attacker.
The URL appears legit as it
points to the targeted website. However, it allows the attacker to run
arbitrary JavaScript code in the victim’s computer. This code can grab the
victim’s session identifier and send it to the attacker. More information on
XSS can be found on OWASP’s website
It is reported that about 80% of websites suffer from XSS vulnerabilities.
Overall, XSS vulnerabilities are extremely hard to mitigate but are very
easy to exploit, therefore making this particular attack vector so
compelling.
As XSS allows attackers to run arbitrary JavaScript code on the victim’s
computer and steal cookies, it is also a perfect platform to bypass device
identification. Here are the steps an attacker needs to follow to execute
this attack
1. discover an XSS vulnerability in the targeted website
2. Craft a URL to exploit the vulnerability. The URL should run a
JavaScript that directs the user to a fraudulent sign in page. It should
steal the targeted website’s cookies, flash and identification
parameters (see previous section for more information on extracting
the JavaSacript from the targeted website). It should also grab the
victim’s credentials when the victim attempts to sign in
3. Distribute the link via email or any other channel (for example IM,
search engines, advertisements)
4. Receive the collected information
5. Repeat the process described in the previous section to sign into the
victim’s account
The attack is very easy to execute. The only barrier here is finding an XSS
vulnerability in the targeted website. However, experienced hackers can
find such vulnerabilities in almost any website and in a very short
timeframe.
To fight this attack the website can use HTTP Only cookies
that prevent a JavaScript from reading the content of cookies. However this mechanism
is still not widely supported (e.g. not supported by FireFox) and there are
some attacks that bypass it completely
Another limitation of XSS attacks is the difficulty of accessing flash files
through JavaScript code. There are several implementation specific ways
to evade the above limitation, such as invoking a Flash object using an
OBJECT tag. However, device identification mechanisms would usually
accept either cookies or flash, considering that flash can be removed by
the user. Thus an attack that grabs the victim’s cookies and device
parameters would succeed.
Browser Vulnerabilities
Browser vulnerabilities are common. The SecurityFocus Vulnerability
database consists of a wealth of vulnerabilities in Mozilla Firefox,
Microsoft Internet Explorer, and even Adobe Flash Player.
Attackers can easily exploit existing browser vulnerabilities to access
cookies on the victim’s computer and use this information to bypass the
device identification mechanism. This is accomplished using existing
unpatched vulnerabilities, as many users do not patch their systems or
using newly released vulnerabilities for which a patch does not yet exist.
Such vulnerabilities are sold today by hacking communities for a few
hundred dollars.
Exploiting browser vulnerabilities does not require much expertise. It
usually involves running the exploit code on the phishing website. Further,
device identification mechanisms are completely vulnerable to this attack
vector as they totally rely on the browser’s security model for their own
security. As a result, any breach in the browser’s security model can
immediately affect this mechanism