COEN 351 E-Commerce Security

1. COEN 351 E-Commerce Security Web Security

2. Table of Contents • Web languages overview • Example: Web shopping carts and payment gateways • HTTP • URL • User input validation • Standard Attacks • Buffer overflow • String format bug • Heap overflow attack • Database input attacks

3. Web Security • Web Languages Overview • Hyper-Text Markup Language • Derived from Standard Generalized Markup Language. • Absolutely fundamental. • Security Implications: • Static web-pages do not pose a security risk. • But hosting them might. • User input, active contents, integration of code into documents are issues.

4. Web Security • Web Languages Overview: • Dynamic HTML • “Object-oriented extension of HTML” • Similar security implications. • XML • More flexible than HTML: XHTML • Very new, little tried • Not enough experience with breaking XHTML

5. Web Security • Web Languages Overview • Perl • Great server side scripting language • Easy to make mistakes, that create security holes. • I will show some examples later. • (Hint: Learn a little bit of Perl.) • PHP: Personal Home Page • Great server side scripting language • Similar problems.

6. Web Security • Web Languages Overview • Cold-Fusion • ASP: Active Server Pages • MS server side and client side scripting environment. • Easy to learn • Active X • Internet portion of COM • Active X controls are embedded in other objects. • Can be very powerful program. • Allowing Active X to run gives control of the system away! • Active X has to give out the location of the .CAB file, in which the control resides.

7. Web Security • Web Languages Overview • Common Gateway Interface (CGI) • Old, mature standard for server-side, dynamic content: • Passing data from Web server to program / script (e.g. Perl) and back to the web browser. • Numerous languages can be used to create CGI programs. • Uses environment variables that reflect system. • This can be a security risk.

8. Web Security • Web Languages Overview • Java: • General purpose OO language. • Ambitions to be secure: • Untrusted java code can run on a system securely. • Platform independent. • Uses intermediate Java Byte Code.

9. Web Security • Web Languages Overview • Java: • General purpose OO language. • Ambitions to be secure: • Untrusted java code can run on a system securely. • Platform independent. • Uses intermediate Java Byte Code.

10. Web Security • Web Languages Overview • Java: • Client-based Java. • Java applet called from html document. • Java applet runs in a “sandbox”. • Byte code is checked for safety. • Cannot access system resources, e.g. no file access. • Server-side Java. • Java Server Pages • History of exploits. • JHTML

11. Web Security • Web Languages Overview • Javascript • Client-side scripting language embedded in html.

12. Web Security • Top Vulnerabilities: • Server-side: • User input can be malicious. • We learn how to do this. • Gaining shell • Gaining access to source code, arbitrary files, … • Get arbitrary commands executed in a database. • Client-side: • Malicious code breaks out of sandbox.

13. Example: Web shopping carts and payment gateways. • E-business model:

14. Example: Web shopping carts and payment gateways. • Shopping Carts: • Buyer interacts with web-pages. • Places items in shopping cart. • Can modify shopping cart. • Delete items • Update item number • Checks out. • Purchase is processed.

15. Example: Web shopping carts and payment gateways.

16. Example: Web shopping carts and payment gateways. • Carello shopping cart (2001): • Remote command executing through crafty use of URL Carello Shopping Cart Lets Remote Users Execute Arbitrary Commands on the Commerce ServerDate:  May 14 2001 13:48 (UTC/GMT) Impact:Denial of service via network, Execution of arbitrary code via networkFix Available:  Yes   Exploit Included:  Yes   Vendor Confirmed:  Yes   Advisory:Defcom LabsVersion(s): V1.2.1 for Windows NT Description:  Defcom Labs issued a vulnerability advisory for the Carello shopping cart, warning that a remote user can execute arbitrary commands on the server with the privileges of the web server. Defcom reports that the Carello.dll uses full physical path to execute Carello scripts instead of paths relative to the webroot directory. The program performs insufficient input validation in processing user-supplied paths.A demonstration exploit URL (shown below) will cause INETINFO.EXE to spike at 100% CPU utilization and the web server will no longer respond to HTTP requests. The webservice cannot be stopped or restarted. The host must be rebooted to regain functionality. (The following URL has been wrapped for readability)http://foo.org/scripts/Carello/Carello.dll?CARELLOCODE=SITE2&VBEXE=C:\..\winnt\system32\cmd.exe%20/c%20echo%20test>c:\defcom.txtThe command will reportedly be executed with the privileges of the web server. For IIS, this is usually LocalSystem Access.Defcom indicates that their vulnerability testing was performed on a Windows NT 4.0 Server with SP 6a. Impact:  A remote user can execute arbitrary commands on the server with the privileges of the web server. The remote user can also cause the server to crash, requiring a reboot to continue functioning.Solution:  The vendor has released version 1.3 to correct the problem.Vendor URL:www.carelloweb.com/(Links to External Site)Cause:Input validation errorUnderlying OS:Windows (NT)Reported By:Peter Gr ndl <peter.grundl@defcom.com>Message History:   None.

17. Example: Web shopping carts and payment gateways. • DCShop-Beta 2001 • Web-based user can execute scripts within cgi-bin directory • Any script, if wrongly configured. • Web-based user can obtain a text file with recent orders. • Can obtain administrator’s name and password.

18. Example: Web shopping carts and payment gateways. • Hassan Consulting (2001) • Arbitrary command execution on server. • Shopping cart runs on Unix and uses Perl. • Script does not filter user input.

19. Example: Web shopping carts and payment gateways. • Cart32 … (2000) • Hidden form fields within html source code. • Attacker can save webpage of particular item, edit html source, change price etc. • Uses “referer” field.

20. Example: Web shopping carts and payment gateways. • Payment Processing System • Vulnerable to stealing of credit card information • On server • In transit. • SSL (against eavesdropping). • Secure Electronic Transaction (SET) • One-Time-Use Credit Cards

21. SET • No reusable credit card information changes hands: • Customer needs digital certificate. • Transaction processing: • Customer (computer) sends transaction details and customer’s digital certificate. • Merchant sends request to her financial institution. • Merchant’s institution requests authorization from customer’s financial institution (based on certificate) • After approval, payment takes place. • Relied on PKI, browser software, and did not catch on.

22. One-Time-Use Credit Card • Customer accesses credit card company’s website and authenticates. • Customer enters transaction details. • Credit card company generates virtual credit card (number). • Linked to actual credit card account. • Customer uses virtual credit card. • Merchant’s side of processing same as for real credit card.

23. Example: Web shopping carts and payment gateways. • Miva Merchant – VeriSign’s Payflow Link Integration • Shopping cart accepts invalid credit card transactions as valid. • Method 1 • Save HTML contents of final checkout page. • Change page to not invoke PayFlow URL • Instead, invoke final payment acceptance URL.

24. Example: Web shopping carts and payment gateways. • Miva Merchant – VeriSign’s Payflow Link Integration • Method 2 • Sign up for a free demo PayFlow Link account at Verisign. • While in demo mode, this account will "validate" almost any credit card info submitted • Then perform HTML edit of the final checkout page • Change the hidden form tag to direct the payment to the demo PayFlow Link account. • Save the HTML, reload in your browser, and submit bogus credit card info.

25. Hyper Text Transfer Protocol • HTTP 1.1 released 2001 • IETF RFC 2616 • Client sends an HTTP request using TCP • You could do this by telneting to a website. • telnet www.scu.edu 80. • Type in http request. • Finish with a blank line.

26. Hyper Text Transfer Protocol • Or use netcat. • Freeware. • Powerful tool for good and bad. • Virus scanners don’t like it.

27. Hyper Text Transfer Protocol • HTTP uses simple, formatted blocks of data. • Client requests or server responses. • Request message • <GET, HEAD, POST …> URL <version> • <headers> • <entity body>

28. Hyper Text Transfer Protocol Captured session with Ethereal. Ethereal is a nifty, free package capturing tool. Allows to follow a TCP stream. You should get it.

29. Hyper Text Transfer Protocol • Response Message • <version> <status> <reason phrase> • <headers> • <entity body>

30. Hyper Text Transfer Protocol

31. Hyper Text Transfer Protocol • Notice how much the response tell us. • Includes the version of the web server, …

32. Hyper Text Transfer Protocol • HTTP 1.0 Methods • GET • HEAD • Does not return the actual web-page, only the head of the response. • Includes server response code, date header, server header, … • POST • Requests that server accepts the enclosed information and acts on it. • Used with CGI or server-side scripting.

33. Hyper Text Transfer Protocol • Common Response Codes • 2xx: Success • 200 OK • 3xx: Redirection • 301 Moved permanently • 302 Moved temporarily • 4xx: Client Error • 400 Bad request • 401 Unauthorized • 403 Forbidden • 404 Requested resource not found • Common Response Codes • 5xx: Server Error • 500 Internal server error • 501 Not implemented • 502 Bad gateway • 504 Service unavailable.

34. Hyper Text Transfer Protocol • HTTPS • HTTP over SSL • Entire message is encrypted.

35. Hyper Text Transfer Protocol

36. Hyper Text Transfer Protocol • HTTPS should be standard for any transmission of sensitive data. • Passwords • Credit cards • …

37. URL Basics URL consists of three main parts: • Service • Address of server • Location of resource. Followed by optional parameters http://www.cse.scu.edu/~tschwarz/coen252_03/Lectures/URLObscuring.html

38. URL Basics • Scheme, colon double forward slash. • An optional user name and password. • The internet domain name • RCF1037 format • IP address as a set of four decimal digits. • Port number in decimal notation. (Optional) • Path + communication data. http://tschwarz:fiddlesticks@www.cse.scu.edu/~tschwarz/coen252_03/Lectures/URLObscuring.html http://www.google.com/search?hl=en&ie=UTF-8&q=phishing

39. URL Basics http://cart2.barnesandnoble.com/Shop/op.asp?path_state=1&step=itemAdded&UIAction=addToCart&opt=consumer&OpCode=Add&ProductCode=BK&ContShopPage=%2Fbooksearch%2FisbnInquiry.asp%3Fisbn%3D1593270070%26itm%3D10%26ATL_lid%3D3r0cWLIARU%26ATL_sid%3Dex1SDEqApk&Host=search&selection=9781593270070&userid=3r0cWLIARU&AddToCart.x=32&AddToCart.y=9 • Resource is named op.asp • Active server page • Usually runs on IIS • The parameters could contain additional data.

40. URL Basics • Search to a site using asp, too. • Try to write the search string into the URL. http://search.msn.com/results.asp?FORM=sCPN&RS=CHECKED&un=doc&v=1&q=hacking%20exploit

41. URL Basics • Everything after the “?” is passed to the web server, e.g. to a script as a command line argument. • There is some translation. • White spaces are encoded as +

42. URL Encoding • URL string consists of • Alphanumeric characters a-z, A-Z, 0-9 • Reserved symbols • ; / : @ & = + $ , < > # % • ? Query string separator • & parameter delimiter • = separates parameter name from value • + translated to space • : protocol separator • # anchor point in webpage • % escape character for hex characters • @ used in mailto • ~ used for home directory on a multiuser system • Other special characters.

43. URL Encoding • Why is this so important? • 90% of all web-app vulnerabilities are caused by lack of proper input validation. • Input URL needs to be verified. • Input verification is much harder than people think.

44. URL Encoding • Use the % escape character to place control characters into stream. • %20 Space • %0d Carriage return • Use %uXXYY to place unicode character XXYY into the stream.

45. URL Encoding • Attackers use a buffer overflow to place executable code in server internal memory and then get it executed. • Use unicode to place the code into the URL. • Code Red worm uses an http request: /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858 %ucbd3 …

46. URL Encoding • When passing a parameter such as a file name, input validation checks for characters such as “../” • Otherwise: • http://192.241.1.45/scripts/..%c0%af../winntsystem32/cmd.exe?/c+dir+d:\ • Calls the command shell to display directory d: • Unicode exploit based on UTF-8 encoding: • %c0%af is the UTF-8 double-byte representation of “/”. • IIS did not implement the translation rules correctly.

47. URL Encoding • Double-Decode Exploit • Represent bad character with hex escape. • Then represent the hex escape with hex escapes. • Input validator does not translate twice. • But the script does. • “/”  %5c  %25%35%63

48. User Input Validation • URL based attacks are only one type of attack based on user input. • URL parameters • User-names, passwords, form-fields • Principal countermeasure: • Define a trust boundary. • Create a chokepoint for any source of user provided data. • Check validity of any input passing through a choke-point.

49. User Input Validation • Trust relationship within the boundary. • Might violate the principle of defense in depth.

50. User Input Validation • Security Principles (Howard, Leblanc) • Secure by Design • Build in security concerns in the design process, develop threat model, … • Secure by Default • Features and capabilities should not be installed by default. • Allow least privilege • Protect resources. • Secure in Deployment • Security administration should be easy. • Fast patching • Good documentation