Sie sind auf Seite 1von 77

Web & Desktop

Application Security

Rafel Ivgi

Security-Art

1 Web & Desktop Application Security


Who am I?

• Over 12 years in development, technology and information


security.

• Published more than 100 articles in the field of information


security including MS04-025, MS05-005 .

• Was Head of information security research team “MCRC” at


“Finjan” in 2004.

• Graduate of 8200 technological unit, two times winning


partner of the “Israel Defense Award”.

2 Web & Desktop Application Security


Who am I?

3 Web & Desktop Application Security


Who am I?

4 Web & Desktop Application Security


Who am I?

5 Web & Desktop Application Security


Table Of Contents
• XSS – Introduction (Reflected XSS)
– XSS – Introduction (Stored XSS)
– XSS-Shell

• XSS Worms – Introduction


– XSS Worms - the future of SPAM
– XSS Worms - D.o.S attacks
– XSS Worms - Automated exploiting bots

• Request Validation

• White-list vs. Black-list filtering

• SQL Injection – Introduction


– SQL Injection – The Practice
– SQL Injection – Taking over the
– SQL injection as a lead to other vulnerabilities
– SQL injection Harvesting tools
– SQL injection Prevention

6 Web & Desktop Application Security


Table Of Contents
• CSRF - Introduction
– CSRF – The risks and common uses
– Tokens vs. Personal Information as a solution for CSRF

• Un-validated Redirects and Forwards - Introduction


– Un-validated Redirects and Forwards – Common uses and
Risks
– Validating Redirects and Forwards

• Introduction to browser security


– History stealing using CSS
– IE 8 anti XSS, is it really safe?
– Exploiting the Browser
– Exploiting the Browser – Logical exploits
– Exploiting the Browser – 3rd party extensions

• Smart D.o.S

• 0-day, Hotmail – Stored XSS


7 Web & Desktop Application Security
Penetration Test Methods

• Black box – In this type of penetration test, the attacker


have no information regarding the system under
observation.

• Gray box – in this type of penetration test, the attacker have


some initial information regarding the system, such as:

– User and password combination to access inner parts of the


system.

– Network architecture scheme.

8 Web & Desktop Application Security


Penetration Test Methods

• White box – in this type of penetration test, the attacker has


all the information regarding the system, such as:

– Source code.

– DB access.

– Network architecture scheme.

– Admin user and password combination.

9 Web & Desktop Application Security


XSS – Introduction
(Reflected XSS)
• XSS is a vulnerability which exists on the server side, but
poses a risk only for the server’s clients

• The “attack” occurs when a web server replies the user with
the exact raw data received from the user.

• In order to exploit the vulnerability:


– the attacker supplies the user with a link
– once clicked, the user sends data to the server
– the server replies it
– the browser executes it

10 Web & Desktop Application Security


XSS – Introduction
(Reflected XSS)
• The attacker may send malicious JS code that will execute in
the context of the given site.

• This code is able to:


– Exploit the browser
– Steal cookies
– Perform GET and POST requests using the user`s credentials
– Perform content spoofing attacks
– Deface the site

11 Web & Desktop Application Security


XSS – Introduction
(Stored XSS)
• Another vector of this attack is called “Stored XSS”, unlike
the previous vector, in this attack there is no need to
navigate the user to a specially crafted URL.

• This attack requires the attacker to find a permanent place


within the application that can store his code, for example:
– blog`s comments
– user`s profile settings
– etc…

12 Web & Desktop Application Security


XSS-Shell

• XSS-Shell is an attack platform designed to be launched


from an XSS vector.

• The usage of this platform is as following:


– The attacker sends the user a link referring to a vulnerable site
– Upon clicking this link the client`s browser runs the JS code of
the XSS-Shell platform
– This code hijacks the browser and starts receiving commands
from the server
– The attacker can send new commands that will be evaluated in
the client`s browser as long as this attack is active
– The client can stop the attack in two ways:
• Manually navigate to the different site using the navigation bar
• Closing the browser completely

13 Web & Desktop Application Security


XSS Worms

• In the age of social networks and mash web sites, a single


XSS attack in a major site can be turned into an army of
computers, just waiting for commands from the attacker.

• Using the power of JS code there is even no need to try and


exploit the browser, most uses of Bot-nets today are D.O.S
and SPAM attacks.

14 Web & Desktop Application Security


XSS Worms
The Future of SPAM
• While SPAM attacks are still hard to launch using JS, there
are several ways attackers use to achieve this goal.

• Mime injections is an uprising attack that allows an attacker


to inject text into the mime headers of an outgoing mail and
change the values of those headers before being sent.

• The vulnerability is mostly common in “Contact Us” forms


which lack input validation on fields such as:
– From
– To
– Subject
– Date and so on…

15 Web & Desktop Application Security


XSS Worms
the future of SPAM
• Correct usage of this vulnerability will allow the attacker to
craft their own email and send it to their victims using the
vulnerable third party site.

• This method of SPAM will also bypass the “Secure Domain


Tokens” that validates the senders domain.

• The attacker can use a XSS worm to take advantage of such


Inject-able sites in order to produce a SPAM network with no
Trojan Horses or any kind of backdoor tools.

16 Web & Desktop Application Security


XSS Worms
the future of SPAM

Original message

Manipulated message – old


email headers becomes hidden
text

17 Web & Desktop Application Security


XSS Worms
D.o.S attacks
• D.o.S attacks are fairly easy to deploy.

• Consider a XSS worm on Facebook.com

• Every user that logs in will get a command from the server.

• This command will cause the browser to send a Post request


to CNN.com

• Considering the amount of users Facebook has


simultaneously, CNN will be down within a few minutes.

18 Web & Desktop Application Security


XSS Worms
Information Gathering
• Beyond malicious attacks on third party sites, the attacker
may use their worm to gather sensitive information from their
victims

• The attacker can harvest the following details using the XSS
alone:
– Password (using a perfect phishing attack)
– Name
– Age
– Email
– Friend list (that will also be attacked to become future victims)

19 Web & Desktop Application Security


XSS Worms
Automated exploiting bots
• Another usage of an XSS worm is to automatically scan and
exploit other vulnerabilities.

• In order to achieve this goal the attacker needs to exploit


one of the victim`s browser and execute a backdoor that will
act as the server.

• The server will then be used by all the other victims or,
“Fetchers”.

20 Web & Desktop Application Security


XSS Worms
Automated exploiting bots
• The Fetchers will send a request to the server asking for a
new list to attack.

• The server will then use Google or any other search engine
to get a list of sites that suit the attack and return it to the
fetcher.

• The fetcher now asks the server for the content of a certain
site on the list.

• Once the value returns, the fetcher parse out the inner link
from this page.

21 Web & Desktop Application Security


XSS Worms
Automated exploiting bots
• The fetcher checks for patterns on those links for known
vulnerabilities such as SQL Injections.

• For each pattern found, the fetcher tries to exploit the


machine using preset values.

• Successful exploitations will cause the attacked machine to


report itself to the attacker thus entering to the attack circle.

• This may have a low ratio of success but when talking about
an XSS Worm in the sufficient magnitude and considering
the fact that this process is fully automatic the result is highly
satisfying for the attacker

22 Web & Desktop Application Security


Request Validation

• One way of preventing these attacks is to use automated


tools like Request Validation from Microsoft.

• This tool blocks HTML characters on every GET and POST


request to the server.

• While such tools seemingly pose a good solution, the


attacker only has to break them once.

23 Web & Desktop Application Security


Request Validation

• By Googling “how to break .NET request validation” one


solution using inline CSS to run JS pops up.

• However, in most cases the attacker cannot get to the stage


where they write inline CSS because the input is not
reflected within a HTML tag.

24 Web & Desktop Application Security


White-list vs. Black-list filtering

• Automated tools cannot be trusted on their own, the


application must have a built in inner filtering mechanism.

• There are two concepts when talking about filtering


mechanisms:
– Black list
– White list

25 Web & Desktop Application Security


White-list vs. Black-list filtering

• Black-list filtering goes over the input and checks to see if


any preset “Bad Keywords” appear.

• If so, the application either removes them from the input or


throws an exception saying the input is invalid.

• The problem with this mechanism is that it`s not 100% proof.
The application will never cover all types of encoding the
methods of attacks.

26 Web & Desktop Application Security


White-list vs. Black-list filtering

• White list filtering on the other hand sets a template for each
type of field in the system.

• Every input is then compared to the template using regular


expression.

• The incompatible parts of the input are removed and the


application is left with a clean value that is known to be safe.

27 Web & Desktop Application Security


White-list vs. Black-list filtering

• Vulnerable

• Secure

28 Web & Desktop Application Security


SQL Injection – Introduction

• SQL Injection is a vulnerability which exists on the server


side and poses a risk to the Database server of the
application.

• The attack occurs when a web server passes the exact raw
data received from the user to the Database server.

• In order to exploit the vulnerability:


– The attacker must identify an input to the application that is
involved in a database query
– Once found, the attacker can manipulate this argument in order
to change the nature of the original query

29 Web & Desktop Application Security


SQL Injection – Introduction
• The following VB code generates a SQL statement using a
parameter from the user
Dim SSN as String
Dim SqlQuery as String
SSN = Request.QueryString(“ID")
SqlQuery = "SELECT lname, fname FROM users WHERE id = '" + ID + "'"
• In case the value is in the correct template, the application will
work as planned
Selectlname,
Select lname,fname
fnameFROM
FROMusers
usersWHERE
WHEREid=‘1’
id=‘1’

30 Web & Desktop Application Security


SQL Injection – Introduction
• On the other hand, the following input will completely
change the nature of this query:
1’ or ‘1’=‘1

• The statement will appear as following:


Select lname, fname FROM users WHERE id=‘1’ or ‘1’=‘1’

• The outcome of the last statement will always result in the


value: “true”.

• An attacker does the same manipulation in the login SQL


statement.

• By making sure the statement will always result in “true”, the


attacker is able to instantly log in to the system.

31 Web & Desktop Application Security


SQL Injection – The Practice

• In addition to login credentials the attacker can also go after


the information within the Database itself, for example Credit
Cards.

• The attacker can use several vectors when trying to read


data from the SQL server.

32 Web & Desktop Application Security


SQL Injection – The Practice
Error Based SQL Injection
• When comparing columns of different types, the SQL server
throws an exception.
• In this exception it explains exactly why the statement failed,
for example:
– the attacker can compare the value of the @@version
parameter, which is string, to an integer value

• the server in response will say the value of @@version (and


the value itself!) cannot be treated as an integer.

33 Web & Desktop Application Security


SQL Injection – The Practice
Error Based SQL Injection

34 Web & Desktop Application Security


SQL Injection – The Practice
Union Based SQL Injection
• In case the server does not output errors or if the attacker
would like a faster way to get the data out of the server the
SQL Union statement comes to hand
• The following query will act as the test case:
select name from users where user_id=‘100’
• the attacker can control the value of user_id and may
manipulate the query as following:
select name from users where user_id=‘-1’ union all select
password from users where user_name=‘admin’
• instead of the name of the current user logged in, the
application will output the password of the admin user.

35 Web & Desktop Application Security


SQL Injection – Taking Over the
Machine
• An attacker can do more than just read, insert and modify
records into the Database.

• With the right permissions, an attacker is able to run binary


code on the actual server running the SQL engine.

• For example, in MSSQL the procedure xp_cmdshell can be


used to run the code it gets as a parameter with the
permissions of the user running the SQL Server.

36 Web & Desktop Application Security


SQL Injection – Taking over the machine
• In SQL Server 2005 the function was disabled for security
issues, but of course Microsoft left a Reconfigure function
that can turn it back on.

• The SQL query will look as following:

; EXEC sp_configure 'xp_cmdshell',1;


RECONFIGURE;
EXEC master.dbo.xp_cmdshell 'cmd.exe dir c:';

37 Web & Desktop Application Security


SQL Injection – Taking over the machine

• Another form of action is to use the msiexec function that


downloads a MSI package and installs it using system
privileges.

• Once the attacker has control over the machine they can
then use it as a “Bot” in order to automatically exploit other
vulnerable sites.

38 Web & Desktop Application Security


SQL injection as a lead to other
vulnerabilities
• Once the attacker has control over the Database server they
can with great ease manipulate the system and create
additional security holes.

• For example, the attacker can change data in the SQL


Server to bypass all of the input validations against XSS
attacks.

• This is why the application must always filter the input it gets,
and should not consider certain sources as safe.

39 Web & Desktop Application Security


SQL injection Harvesting tools

• There are a few key applications that make the usage of


SQL injections practically automated.

• The number one application will be Pangolin.

• Pangolin is designed to extract data from almost every type


of SQL server:
– MSSQL
– MySQL
– Oracle
– DB2 and more…

40 Web & Desktop Application Security


SQL injection Harvesting tools

• In addition to data extraction Pangolin has the ability to:


– Execute code on the remote machine
– Write files to the remote host
– Directory and file manager
– Registry editor
– Custom SQL statements and more…

41 Web & Desktop Application Security


SQL injection Harvesting tools

42 Web & Desktop Application Security


SQL injection Prevention

• Just like with XSS, there are plug-ins that attempt to prevent
these attacks, along with many WAF products in the market.
• The problem with these products remains the same, it
cannot be a single line of defense. These products get
broken.
• The application must have a filtering module that prevents
these attacks on its own.
• In the case of SQL Injection the most important part is to
encode the parameter before sending it to the SQL Server
so that characters like ‘ will have no affect.

43 Web & Desktop Application Security


SQL injection Prevention

• A common problem is the parameters that are not bound by


quotes, like integers, these parameters must be validated as
an integer before sent further on in the application.
• Another vector of prevention is the use of parameterized
queries inside stored procedures.
• This way the variables cannot be treated as SQL CODE but
only as values of those variables.
• Once this is done, no matter what the attacker sends as an
input, it could never be parsed as a part of the SQL
statement.

44 Web & Desktop Application Security


SQL injection Prevention

• To add another layer of security, it is recommended to break


down the stored procedures into smaller units of code.

• Each with its own permissions, to avoid a scenario of one


stored procedure having both read and write permissions.

• In addition, the parameters should be sanitized inside the


stored procedures as a last line of defense.

45 Web & Desktop Application Security


CSRF - Introduction

• Cross Site Request Forgery (CSRF) is a client side attack


that takes advantage of insecure web applications.

• To understand this vulnerability let us take a website that


has a user management section:
– The credentials for the site are saved in the cookie.
– The site has a Change Password form.

46 Web & Desktop Application Security


CSRF - Introduction

47 Web & Desktop Application Security


CSRF – The risks and common uses

• The form has one input, the new desired password.

• The attacker also discovered an XSS vulnerability in a high


traffic third party site.

• The attacker can use this XSS and cause the victim to
generate a post to the original form on the first site.

• The browser will then send an HTTP POST request to the


first server, it will automatically include the cookie that it had
saved and the password will change as the attacker desired.

48 Web & Desktop Application Security


CSRF – The risks and common uses
• The attacker can make the user post any form (rather GET
or POST method) without the user having any way of
controlling the event.

• The user has no way of knowing about the event occurring


(without the use of sniffing or analysis tools).

49 Web & Desktop Application Security


CSRF – The risks and common uses

• Most attackers choose the obvious forms to exploit:


– Password change
– Password reminder question change
– Email change
– Money transfer

50 Web & Desktop Application Security


Tokens vs. Personal Information as a
solution for CSRF
• Tokens work in the following way:
– The user requests a page.
– The server generates a random token and appends it as a
hidden field to the form.
– The user fills out the form and submits it back to the server.
– The server can now compare the token it has saved and the
one received by the user in order to verify the submit process
was legitimate.

51 Web & Desktop Application Security


Tokens vs. Personal Information as a
solution for CSRF
• Personal Information is used to validate the request is
legitimate and human generated.

• Two ways are generally used in this method:


– Old password
– Security question

• The problem with this method of action is that it is not 100%


secure, personal information can be found out by the
attacker and then the security mechanism has no meaning.

• Combining both methods and adding a Captcha mechanism


is the best way to defend against this type of attacks.

52 Web & Desktop Application Security


Unvalidated Redirects and
Forwards - Introduction
• Many sites today use redirections and forwards to third party
sites.

• Each unvalidated redirection or forward to third party sites


are potentially an attack vector waiting to be exploited.

• There are a few risks


– when talking about
– unvalidated referrals.

53 Web & Desktop Application Security


Unvalidated Redirects and Forwards –
Common uses and Risks
• The number one use of this unvalidated feature will be to
implement an XSS attack on a third party site.

• This XSS cannot affect the referring site, it still uses that
site`s credibility to unleash the attack.

54 Web & Desktop Application Security


Unvalidated Redirects and Forwards –
Common uses and Risks
• For example, the following link bypasses the Facebook
redirect checks:

• Or coded to the more practical way:


http://www.facebook.com/l.php?u=http://attacker_site.com&
h=781d3
• In a more unobvious way:
http://www.facebook.com/l.php?u=%68%74%74%70%3a%
2f%2f%61%74%74%61%63%6b%65%72%5f%73%69%74
%65%2e%63%6f%6d&h=781d3

55 Web & Desktop Application Security


Unvalidated Redirects and Forwards –
Common uses and Risks
• Another vector of attack is Content Spoofing.

• If the attacker can control the content of a frame inside a


major news web server, they could then create false posts of
information that will endanger the credibility of the site in
addition to the profit generated to the attacker.

56 Web & Desktop Application Security


Validating Redirects and Forwards
• The application must validate the URL before forwarding the
user thus assuring the link is safe.

• In case the application cannot validate the URL it should


prompt the user of the redirection before forwarding it.

57 Web & Desktop Application Security


Introduction to browser security
• These days many attackers have realized that owning a
BotNet that can be used to send Spam or to Perform Credit
Card frauds and Identity theft is highly profitable.

• In order to create these BotNets the attacker uses a number


of methods to get the most off of the users they catch in their
webs.

58 Web & Desktop Application Security


History stealing using CSS

• One of the most sophisticated logical ways to focus your


attack and gather information on a victim is to steal the
browser`s history.
• This can be done quite easily by any Trojan Horse or
Spyware software but what if the attacker does not want to
infect every user with his backdoor?
• A good private 0-day vulnerability should not be “wasted” on
random victims.
• What if the attacker could know in advance if the potential
victim has a specific online bank account and only then use
the exploit and infect the machine…

59 Web & Desktop Application Security


History stealing using CSS

• Stealing the entire history without running code on the


machine is currently not possible.

• However it is possible to determine whether a user did or did


not visit a specific URL.

• All the attacker needs to do is to generate a list of specific


“interesting URLs” such as:
– Bank login pages
– Social network login pages
– Common search engines and search values

60 Web & Desktop Application Security


History stealing using CSS

• Once the list is prepared the attacker can dynamically add a


new HREF html tag referring to a link on the list.

• It is known that once you click a link it changes color.

• What is unknown is the fact that the color of the link can be
checked using CSS.

• Then the attacker can simply define a JS loop that checks


for each link if the color is set to the default color or not, in
other words - has it been visited or not.

61 Web & Desktop Application Security


History stealing using CSS

62 Web & Desktop Application Security


IE 8 anti XSS, is it really safe?

• Microsoft created a mechanism that should protect the users


from class-1 XSS vulnerabilities.

• The feature was broken in IE8 beta 2, by Mr. Rafel Ivgi, in


several different ways.

• The most critical method was fixed in the final release of the
product but there are still ways to bypass this defense.

63 Web & Desktop Application Security


IE 8 anti XSS, is it really safe?

• One of these ways is CRLF.


• CRLF (Carriage Return and Line Feed) is a very significant
sequence of characters for programmers.
• These two special characters represent the End Of Header
marker (EOH) for many Internet protocols.
• In the HTTP protocol, two sequences of these characters are
used as a separation between the headers and message
content.

64 Web & Desktop Application Security


IE 8 anti XSS, is it really safe?
• CRLF is considered class-1 XSS.
• The difference is that in CRLF you can manipulate the HTTP
headers in additions to the HTML page.
• This means that the attacker can override the encoding
header of the original page and set it to UTF-7
• Once this is done, the XSS can be encoded using UTF-7
and the XSS-filter does not block the request.
• The browser of course renders the page and runs the XSS
as it should.

65 Web & Desktop Application Security


IE 8 anti XSS, is it really safe?

66 Web & Desktop Application Security


Exploiting the Browser

• Attackers have found that exploiting the browser is the most


effective way to achieve a wide spread of computers under
their control (Botnet).

• All the attacker needs is one high traffic website with a


stored XSS or SQL Injection vulnerability.

• The attacker will then use this vulnerability to append some


code that will exploit a private vulnerability in the browser
and install a backdoor application.

67 Web & Desktop Application Security


Exploiting the Browser – Logical exploits
• Logical exploits take advantage of insecure design rather
then exploiting a classic overflow vulnerabilities.

• An example to a logical weakness would be the use of


NetBIOS through Internet Explorer

• Allows reading files on the local machine, bypassing all the


domain restrictions and browser protections.

• This was vulnerable up until 6 months ago on all windows


operating systems from 9x to windows 7 using any version of
Internet Explorer.

68 Web & Desktop Application Security


Exploiting the Browser – 3rd party
extensions
• Browser vendors are in an ongoing battle with security
researchers to keep the browser secure and unexploitable:
– Flash
– Adobe acrobat reader
– Automated download acceleration software
– Network sniffing and analysis tools

69 Web & Desktop Application Security


Smart D.o.S

• A new kind of D.o.S has started to spread.

• This method uses a feature in the current web browsers that


is made to prevent users from surfing to malicious websites.

• Firefox for example checks using Google's Safe Browsing


whether the site currently requested is safe or not.

• In case the result determines that the site is malicious the


browser automatically blocks the connection to the site.

70 Web & Desktop Application Security


Smart D.o.S

• An attacker can find a vulnerability in a competitive website


for example and plant a public malicious code within the
site’s pages.

• Within a short time, Google will index the site in question and
discover the exploiting code.

• It will then automatically update the Google Safe Browsing


database

• From now on every attempt to view the site will result with
the following sight:

71 Web & Desktop Application Security


Smart D.o.S

72 Web & Desktop Application Security


Smart D.o.S

• After the site has been indexed as malicious it is highly


difficult to undo the process:
– The webmaster must find all the instances of the appended
code and remove it.
– The vulnerability that was used must be blocked or fixing the
problem will only be affective for a short period of time.
– Contact Google and demand another indexation of the site.

• Most webmasters don’t have the skills to do the above which


then requires the hiring of a specialist.

• All in all the company under attack has lost a few days of
internet activity and spent a lot of money dealing with the
outcome of the attack.

73 Web & Desktop Application Security


0-Day Exploit, Hotmail – Stored XSS

74 Web & Desktop Application Security


0-Day Technique, Bypassing Microsoft
Request Validation
• Extensive research leads us to another solution, apparently
in the Unicode table the Characters ‘<‘ and ‘>’ appear twice:
– u001C and uFF1C for <
– u001E and uFF1E for >

• The ones starting with FF are not filtered by Microsoft`s tool.


• Meaning this line of defense is broken and every site using it
is now vulnerable to the same attack.

75 Web & Desktop Application Security


Questions?

76 Web & Desktop Application Security


Contact Information:

• Jody Keyser
• jkeyser@aliadocorp.com
• www.aliadocorp.com
• 1-888-373-0680

Thank You

77 Web & Desktop Application Security

Das könnte Ihnen auch gefallen