Attack Options based on Protocol Specifications

(1)

Version: 1.0

Date: September 30, 2005

Attack Options based on Protocol

Specifications

(2)

1 Introduction

This report is a survey on attack options based on protocol specifications. Most application developers are not trained specifically for security related issues. As a result, their design of communication protocols focus merely on how the applications should behave and neglect to handle situations that are not according the specifications.

Information from cases in the field1 is put together with theoretical cases to define se-curity requirements and points of special interest when designing new interaction protocols or extending existing ones.

This work is part of theAutomating Protocol Security track of the SoBeNet2 project. Within this track different formalisms are studied to analyze and improve application level communication protocols. The goal is basically first to formalize, at the application level, the interaction protocol between communicating tiers; then to enrich this protocol specification with automatically deduced security specifications and finally to validate compliance with the protocol at the syntactic and semantic level.

The remaining sections in this document group related attack options: section 2 con-tains attack options related to the processing of invalid data and section 3 describes im-proper usage of particular protocol features. Problems related to timing issues in protocol specifications are discussed in section 4 and section 5 shows the attacks options following the cross site scripting principles. Section 6 describes potential attack options based on the ignorance of the (uneducated) user, and section 7 handles the problem of information leakage. Finally, section 8 concludes.

2 Invalid data

2.1 Invalid contents

Alphabetic characters in numerical fields

In a web application, there is typically a test on data validity on the client side, imple-mented in javascript. However, it is trivially for an attacker to circumvent such tests and submit a non-numerical value where a numerical value is expected by the server.

Often a conversion of a non-numeric string to a numerical value results in the value zero or in an application exception. This may result in unexpected behavior of the web application: total price of an order may be set to zero, payment session may be skipped etc.

Values outside valid range

Consider a web application for charging prepaid GSM cards. The GSM phone number is used a sole authentication: there is no reason to assume that an attacker would charge a victims account.

However, if an attacker were to submit an order to charge the victim account with -100 euro’s? Chances are that a payment of a negative value will result in null operation. The 1_{The information which could lead to identify real-life persons or situations has been removed from the}

text.

2

The SoBeNet project is funded by the Flemish Government under the SBO program of IWT with number 030313. More details about the project can be found on the official project website http:// sobenet.cs.kuleuven.be/

(4)

web application might not be so intelligent and effectively decrement the amount available to the victim.

Change data that should not have been changed

A classic mistake made by many web application developers, is that the price of ordered goods is sent back to the browsers as hidden fields: those values are not displayed for the user, but they are submitted back to the web server.

Attackers have exploited this mechanism by changing the supposedly hidden price and thus buying goods and services for whatever they felt like paying for them.

2.2 Meta characters

Meta characters are part of the category invalid user input but they are handled in a separated group because of the their potentially large impact.

Command execution

Web application environments often use interpreted languages such as Perl or PHP or even a regular Unix shell. These languages all share a great flexibility where it comes to string manipulation and, most notably, the option to replace variable parts in otherwise fixed strings. Even worse is the capability to include arbitrary external shell commands.

As a result, incorrect handling of user input strings may lead to execution of arbitrary commands on the application server.

For example: consider this line as part of a CGI Perl script where variable $user

contains a submitted HTML form field.

open(F,"<data/$user") && die "Open Failed.\n";

In Perl, variables referenced between double quotes are replaced by their value. In the above sample line, this means that the part$useris replaced by the value of that variable.

In Perl, back quotes can be used to specify an external command to execute.

The combination of these two results in the problem that an attacker may specify an arbitrary command to execute between back quotes in variable $user. For example, if

$userhas value‘rm -rf *‘, then all files will be deleted in the current directory in which the CGI script is executed (for as much as the file protections allow so)

SQL injection Applications often build SQL query strings dynamically, based on user input, and send the resulting query strings to a database engine. The danger here is that the database command parser operates on the result of the dynamic query build. A typical problem is illustrated by a query like this:

SELECT * FROM USERTABLE WHERE USER=’<user>’ AND PASSWORD=’<pwd>’

where the portions<user>and <pwd> are replaced with whatever the user entered in the username and password fields.

The problems start when a malicious user enters a username or password that contains a quote: the database query parser will interpret those quotes. For example, assuming that an attacker entered for password the text “’ OR 1=1 OR USER=’” The actual query parsed by the database will be:

(5)

2 INVALID DATA

SELECT * FROM USERTABLE WHERE USER=’someuser’ AND PASSWORD=’’ OR 1=1 OR USER=’’

The part “OR 1=1” ensures that the condition will be true for every entry in the USERTABLE table.

Things can become much more interesting whit more complex or malicious SQL queries.

Second level attacks Many applications generate log files. Many of those files are being monitored using web based applications: they are displayed in a web browser.

That opens up a new vector of attack: attack those people who are looking at log files. Because log file reviewing is typically a task for administrators, people with higher than normal access rights, they are an interesting target group.

Consider a web based application where an administrator looks at web server logs. One of the fields that is commonly logged is the user agent string: an identifier of which browser is being used by the surfer. The idea is that the web server registers the content of the User-Agent: HTTP header for each request. Later, an administrator displays the logged information where each item is shown in a separate column in an HTML table: time, source IP address, requested page, user-agent etc.

TheUser-Agent:HTTP header is not required for normal operations of a web session. Consequently, an attacker might specify any value of her liking and still experience a normal web session. Things are not so smoothly for the administrator that is looking at the logs.

An attacker might include HTML code or even scripting in theUser-Agent: HTTP header string. That code will be rendered/executed in the context of the administrator web browser! For example, the following request header will pop up a warning message box when viewed by the administrator:

User-Agent: <script>alert(’You have been hacked!’)</script>

The idea behind such forms of attacks is not so much as to attack the application directly, but rather the people managing the application.

This type of attack is not limited to HTTP alone: recently parsing errors have been found in network sniffers. The buffer overflows allow a remote attacker to execute arbitrary code on the system where the network sniffer is executed. Given that such sniffers typically require administrator rights on the system they are being run on, this type of attack may have serious consequences.

2.3 Boundary errors

Empty or missing fields

There are any number of things that can and do go wrong when fields that are supposedly mandatory are in fact not present. Note that most of those issues can be easily avoided by proper error checking.

Consider the situation were an on-line banking application allows to transfer money between two accounts. Now imagine the situation where the source account number is left out or empty and only a destination account number is specified. Chances are that the specified amount will be added to the destination account without taking the money away from a source account.

(6)

Another issue with on-line banking might be that the signature field for a transaction is left empty. If not handled properly, the signature check might not return an error (there is nothing to check) and the transaction might go through. This schema would allow to specify any source account number to grab money from any account.

Overly long values

Buffer overflows may result in nasty situations. Buffer overflows in compiled languages, such as C or C++, usually lead to a vulnerability of the type “may execute arbitrary commands” on the target system. In plain English, this means that an attacker can do anything on the target system that the local user account that runs the software, can do on that system.

In the past there have been vulnerabilities in the OpenSSH daemon authentication code. That daemon typically runs as the super-user because it needs to listen on port 22, something that regular user accounts cannot do on unix-style systems. The first part of any SSH session is to establish the identity of the client that connects to the server. At that moment the server has no idea who is trying to connect and is therefore still running in super-user mode. Only after successful authentication does the daemon switch to the account of the user that logged on. Buffer overflows in the authentication code caused that an attacker could gain root access to the OpenSSH server system.

When too much data is entered in an input field that is later stored in a database, it may very well be possible that the database returns an error to the application server and subsequently aborts the database connection. If the application server is not able to re-establish the database connection, this may be a very effective denial-of-service attack. If the application does restore the database connection, it usually takes a considerable amount of time (expressed in seconds) In that case, a relatively small number of requests may be enough to effectively DoS the application server by having it retrying to connect to the database time and again.

Off-by-one errors

Often an application developer does not properly handle the cases where the length of an item is precisely one character over the expected limit, hence the name off-by-one. Typically, the test on the maximum length will erroneously report that the length is fine, but when actually storing all of the input a buffer overflow is triggered.

In the C programming language, this type of error is easy to make as strings are typically stored as the string contents plus one termination byte (being zero) Thus, a string of 10 characters requires 11 bytes of storage. Unfortunately, what happens in real life is that often internal storage is allocated as the maximum legal length of that field.

3 Improper usage of protocol features

3.1 Improper usage of encryption

EBC versus CBC

Symmetric encryption algorithms come in two main categories:

(7)

3 IMPROPER USAGE OF PROTOCOL FEATURES

• stream ciphers

The difference between them is that block ciphers operate on blocks of data at a time, while stream ciphers operate on one bit at a time. Encrypting data of arbitrary length with block ciphers poses a problem[11]: block ciphers operate on chunks of data that are fixed in size. If the data to crypt is less than the block size, some padding mechanism is required to provide the algorithm with a chunk of data of the correct size. If the data to crypt is longer than the block size, the data could be encrypted in chunks of data that have the same size as the algorithm block size.

As a result, all chunks of the same plain text are crypted to the same block of cipher text. An attacker could detect that several blocks of cipher text are the same and conclude from that that the input plain text at those locations had to be the same. In many cases this is not an issue, but nevertheless there is an information leak possible. Consider a web application where only two or three distinct operations are available through their respective CGI scripts. Additional parameters are given as a query string. If the names of those scripts are different in length, an attacker might be able to detect which of those scripts is being used, just by comparing the cipher blocks of the requests: the first part will remain the same.

The method of translating every plain text to the same cipher text is called Electronic CookBook (ECB). The most frequently used method for preventing that the same plain text blocks are translated to the same cipher text is Cipher Block Chaining (CBC). This method performs an XOR operation of each plain text block with the cipher text of the previous block before encrypting it. To bootstrap the process, the first block is XOR-ed with an Initial Vector (IV). As long as that IV is different for each encryption, the same plain text will be encrypted to entirely different cipher blocks. An attacker will no longer be able to map blocks of the same plain text.

WEP protocol attacks

The wireless WEP protocol uses a slightly different approach to the term “initial vector”. Here there are 3 bytes per packet (that are transmitted in plain text) that are concatenated with the secret key. The 3 bytes are called “initial vector” too. Unfortunately, there are issues with the algorithm being used in combination with parts of the secret key being known [2]. Given a sufficient amount of data, it is possible to reconstruct the secret key. Several tools (e.g. airsnort) are available to assist in the capture of data that is transmitted over a wireless connection and crack the secret key once sufficient data has been captured. RSA and encryption of long data

The public/private key algorithm RSA has a similar problem with long data chunks. The maximum size of an RSA crypt operation is limited by the key size of the key pair being used. For example, a 1024 bit key does not allow to encrypt chunks of data that are longer than 128 bytes. Even a 4096 bit key would not allow encryption of blocks of more than 512 bytes. If we combine this information with the knowledge that increasing the size of an RSA leads to significantly increased calculation times, it becomes clear that protocols using the RSA algorithm as a basis for establishing mutual trust between the partners, should come up with a more practical approach for transferring large amounts of data (e.g. upload a 1 megabyte file over SSL)

(8)

The answer is to use one of the symmetrical algorithms (such as AES) with a randomly generated key and send over the random key encrypted with RSA. This solves the problems related to long data and long keys:

• the symmetrical algorithms have a key of a fixed, well-known size

• knowing the length of the symmetrical key, we also know the maximum size of the data that will have to be encrypted with RSA

• that information allows to select an RSA key length so that there will never be an issue with lengths of the data to encrypt

For example, a 256 bit AES key is only one quarter the size of a 1024 bit RSA key, the length currently used for Belgian EID certificates.

However, sometimes people resort to creative solutions for handling long chunks of data that need to be transferred using the RSA algorithm.

During investigation for one of our customers it was found that the RSA algorithm had been used for encrypting the data. Unfortunately, the application encrypted every byte separately. As a result, only 256 different cipher text blocks were used on the network. Although the individual encryption was strong enough, it was only a matter of time to create a reasonably complete translation table so that all traffic could easily be decrypted.

3.2 Key lengths in symmetrical and asymmetrical ciphers

It is hard to compare the security for key lengths of different algorithms and sometimes people go horribly wrong. A symmetric key of 128 bits is still reasonably secure. Unfor-tunately, one of our customers had once implemented an RSA key of 128 bits! The key was cracked within seconds on a conventional desktop PC.

3.3 Filtering

It is common for network communication protocols to ignore possible changes that may occur to data in transit. One of the more common situations involves HTTP proxies. Often, on server side, information that is basically non-essential to the HTTP protocol, is handled in such a way that the information becomes crucial to the application.

A common reason would be to distinguish between different web browser types and serve web pages that are designed to be viewed on one particular web browser only. For example, Internet Explorer users might be offered a web page that refers to ActiveX components, while Netscape users might be given a page containing a Java applet.

Unfortunately, company HTTP proxies might remove the HTTP request headers that identify which browser is being used. Another issue may arise when an Internet Explorer user has accessed an URL and that a subsequent Netscape user is served the same reply from the proxy cache: the Netscape user is likely to have an unpleasant surprise.

Caching may lead to other errors. Depending on the checks by the proxy to determine if a request is present in the cache or not, the proxy may erroneously decide to return cached information. For example, a web based help desk application may return a list of open issues for the current user. Normally the submitted HTTP cookie is used by the proxy to map incoming requests to cached entries. There may be a problem if the web browser uses a bookmark to go directly to the page containing the list of open issues, but

(9)

without presenting a valid session cookie. At least one instance of one particular proxy responds with a randomly cached entry for that URL, instead of redirecting the request to the web server.

Another common problem with proxies is that the server no longer knows the real source address of client requests. For example, consider the case of a large ISP where many customers go through one single proxy to the internet. An application that checks if the same person is connected more than once, could test on source IP address. In the case of the ISP proxy that test will fail if two different ISP customers connect to the web application. If the web application uses the source IP address as unique identifier (e.g. as session ID) then the application logic will break. Some web commerce sites even log the customer source IP address for legal verification purposes (SSL through a web proxy will still hide the real source IP address), which becomes more or less meaningless in case of an intermediate proxy.

Application level firewalls may cause unexpected side effects. For example, a filtering reverse proxy could be used to protect internal web servers from attacks. For security reasons, SSL sessions are terminated on the application level firewall (otherwise the con-tents of SSL requests cannot be checked) and transfered in regular HTTP requests to the internal backend systems. Now, what is the proxy supposed to do when the backend server returns a HTML body that contains something like this:

<form method="POST" action="http://internal.site/order.pl> ...

</form>

The proxy logic will recognize the reference to the internal site and replace that address with the external site name:

<form method="POST" action="http://external.site/order.pl> ...

</form>

The problem is that the protocol was not changed by the proxy. As a result, the web browser will effectively post the form data in plain HTTP to the web server. If the server is properly configured, an error will be sent back to the browser, but the harm has already been done in that potentially confidential data has been sent over the network.

3.4 Improper usage of protocol

Using HTTP as transport mechanism for bypassing firewalls

In the early days of the Internet, there were no firewalls: the participants trusted one another. With the advent of malicious usage of the Internet (e.g. the famous Morris internet worm) the need to have perimeter defenses arose: firewalls were installed.

Firewalls are designed to stop most of the incoming traffic: only a select set of incoming connections is allowed in (e.g. incoming connections for the mail server) One of the protocols that is most likely to be allowed through firewalls is HTTP: both for incoming and for outgoing traffic.

Due to the obstacle of firewalls and the general availability of HTTP, a number of application level protocols are now implemented on top of regular HTTP. This offers a number of advantages for application developers:

(10)

• there is no need to bother the security staff to open up additional holes in the firewall

• if a client has web access, even through a proxy, she can participate in the new application

• given the wide availability of HTTP access, this means a near general availability of the application

Unfortunately, this approach brings the responsibility of security back to application developers: firewall software and rules are screened thoroughly by trained security profes-sionals. A typical application is not scrutinized so carefully.

Examples of application level protocols layered on top of HTTP are:

• WebDAV

• Instant messenger protocols

• Custom protocols such as used by Ubizens Multisecure line of products

• Reverse web shell

That last example is a typical illustration of malicious usage of the HTTP protocol. It consists of two components:

1. web server running on attackers system 2. web client running on the victim system The scenario goes something like this:

1. web client issues an HTTP request to the server

2. on the server, an attacker responds with sending a command to execute on the victim system

3. if a command was received, the web client locally executes the command that was received over the HTTP connection

4. Web client POSTs the output of the executed command to the server 5. the attacker receives the command output at the server

6. the client goes dormant for a short period of time before starting all over again In this scenario, the usual roles of client and server are reversed:

• the web client is actually a server component running on the victim system

• the web server is in reality an attacker waiting at his console to enter commands that will be executed on the victim system

(11)

For all intents and purposes, this type of network communication looks like regular HTTP traffic and bypasses firewalls and proxy systems.

Instant messenger protocols are intended to exchange short messages in real-time. Un-fortunately, those protocols are extended with additional features, such as file attachments, which complicate the basic design. From a security point of view, adding complexity usu-ally leads to more vulnerabilities. In the past, there have been cases with incorrect parsing of filenames by messenger client software. The results were that an attacker could access any local file or, even worse, overwrite files with trojaned versions.

WebDAV is intended to expose part of the local file system over the Internet. This means that errors in handling such requests can quickly compromise the local file system. Similarly to filename parsing errors in messenger clients, parsing errors can lead to disasters on the file systems. In addition to that, it is sometimes possible to access files that were never intended to be exposed to the Internet (similarly to breaking out of the document root directory on a web server)

The protocol implemented by Ubizens Multisecure product used regular HTTP re-quests with encrypted payloads. The main difference with SSL is that with SSL all traffic is encrypted, while the Multisecure protocol used regular traffic.

Many company firewalls and proxies are configured so that internal users cannot access random ports on random sites on the internet:

• HTTP and FTP are restricted to destination ports 80 and 21 respectively

• SSL is restricted to go to destination port 443

This looks good in theory: internal users seem to be restricted to use external websites (secure and non-secure) and FTP servers. There is no way to create a VPN from the intranet to an external party.

That is not the case, however. The OpenSSH product allows to use an external com-mand to create a socket connection to the remote SSH server. It does not matter how that external command establishes the connection, the important thing is to obtain a work-ing socket. Once the socket is established, OpenSSH can use it for establishwork-ing a secure channel, including the necessary port forwarding options.

The trick for creating an SSH tunnel through a proxy goes like this:

• have the SSH server listen to port 443, the standard SSL port

• use a tool like connect (bySHun-ishi Goto) to use the proxy command CONNECT to create a socket through a proxy to the SSH server on port 443

(tool available from http://zippo.taiyo.co.jp/˜ gotoh/ssh/connect.html)

• using the OpenSSH ProxyCommandoption, SSH can use the created socket to estab-lish a full blown SSH tunnel

The main reason why the OpenSSH server has to run on port 443 in this scenario is that most proxies restrict outgoing CONNECT commands to all ports except 443.

Although this is not strictly a protocol layered on top of HTTP, it is nevertheless closely related to HTTP exploits.

Finally, the infamous “Firewall Enhancement Protocol” [3] may have been intended to be a joke, there is no reason why it would not be possible to implement TCP and UDP traffic on top of HTTP. Such an implementation would effectively bypass all security measures imposed by firewalls and proxies.

(12)

Using IRC to control backdoors

The original intention of IRC is to allow people to have online discussions. The difference with messenger type of applications is that here the discussions are typically public to a large group of participants: every participant receives all the messages that are posted in the discussion group.

That original intention has been extended with additional capabilities such as file exchange as well.

IRC channels are frequently used for communication between an attacker and infected target systems. The victim computer is infected with a malicious piece of software that regularly announces its presence in a pre-defined discussion group. That same software will also accept commands issued to that group. The attacker connects to the discussion group from wherever she wants, whenever she wants and communicates with her victim systems whilst being online.

This type of abuse has the following characteristics:

• there is no need for a direct connection between attacker and victim system

• one single instruction can be sent to many target victims at once

• using the file exchange capabilities, files can be retrieved from victim systems, as well as sent to those systems (e.g. an update of the malware software)

Typical usage of this type of setup includes:

• transfer logged keystrokes

• search for patterns in local files (such as creditcard numbers)

• retrieve confidential information (such as MS-Word or MS-Excel documents)

• start a DDoS attack

• install additional malware on the victim’s system

By adding functionality to the basic setup of having an interactive discussion board, the possibility for creative abuse of the platform became possible.

4 Timing issues

4.1 No keep-alive mechanism

When dealing with a network connection, there is always the possibility that the connection is broken abruptly. This could be because of someone pulling a plug, a cable could be cut, a power outage etc. In brief, the reasons for sudden interruptions in communications are not always due to software issues. Even worse, in many cases of hardware failure, there is no chance at all to have a software signal (interrupt) to indicate something unusual has happened.

A protocol that has no built-in mechanism for detecting that the remote partner is no longer responding, is at risk of keeping connections alive that are in fact no longer existing. Such stale connections will take up resources that will never be released. If, after time,

(13)

4 TIMING ISSUES

a sufficiently large number of stale connections are kept on a system, this may result in resources becoming low.

Such resources may be buffers that are maintained by the operating system itself, but there may be applications attached to those stale connections that keep other resources locked up too (database locks, file locks, ...)

The TCP protocol itself does not provide a mechanism to detect that the remote partner is no longer available. If no data is received, the TCP stack will simply keep on waiting indefinitely for new data. If no acknowledge is received on transmitted data, the same data will be sent over and over again, with increasingly larger delays in between the transmissions.

The absence of a built-in keep-alive mechanism in TCP offers a very economic DoS exploit. Consider a small program that simply emulates a 3-way handshake for establishing a TCP connection like so:

1. construct a SYN packet with a fixed initial sequence number, a source port number that is increased with one for every new 3-way handshake and an unused source IP address

2. send the constructed SYN packet to the target system

3. target system replies with a SYN+ACK message to spoofed source IP address 4. attacker sniffs that reply off the network cable

5. attacker sends an ACK to the target (again with spoofed source IP address) 6. attacker remains silent for this connection afterwards

After the above “dialog”, the target system will have allocated resources for the “es-tablished” connection. Those resources will remain allocated until the next boot of the system or until the interface is stopped and started again.

This type of attack is particularly effective against systems with a limited number of incoming connections that they can handle. For example, the Apache web server has a configuration parameter that defines how many simultaneous connections it can handle (MaxClients). Once that number of connections has been reached, the whole Apache server is effectively unavailable for other clients.

4.2 No timeout on sell or buy offers

Many computer related interactions are done so quickly that most people don’t even stop to think about the possibility that an interaction might not happen “immediately”. That is why some implementations do not take time into account in their protocol designs.

A typical example where time is of the essence, is a stock exchange: prices may vary quickly. Now, consider a stock exchange application where buyers and traders communi-cate with one another and deals are made through the application.

Being a security sensitive environment, the application uses all the usual protection mechanisms: signed hash values to guard against unauthorized changes, strong identifica-tion of the participants etc.

(14)

So, Alice issues a buy request to Bob through the central application server. The data sent from the server to Bob includes the identity of the buyer, the stock she wants to buy, the amount to buy, the price and, just for good measure, the whole request is digitally signed by both Alice and the server application. All that is required, is that Bob responds with a signed message indicating an accept of reject of the buy request. If Bob accepts, the sale is made for the agreed upon price and quantity. If not, the deal is off.

For the sake of this discussion, let us assume that Bob somehow has the knowledge that stock of company BigBang will be going down in price. So, he puts up for sale some shares that he does not yet have in his possession and waits for a victim: Alice. Once the buy request comes in, Bob simply waits until he can obtain the requested shares at half the price and only acknowledges Alices request when he has bought the shares at a bargain price. Instant profit.

This type of attack did not involve hacking data, but simply wait at a point in the protocol where the designers never expected to be a significant delay. It may be possible that the official client software did implement a timeout mechanism ... on the client side. If so, a skilled hacker might remove any client side checks, including timeout checks.

4.3 Delay tactics

There can be any number of reasons why someone would want to slow down, or even completely stall, a communication.

At TCP level, there are tools that will use delaying tactics in case of heavy load. For example, if a monkey-in-the-middle (MITM) tool cannot keep up the traffic of a high speed link, it may send out messages to decrease the MSS or delay ACKs or only send an ACK for a small amount of data received. As a result, the throughput of the connection will go down and the MITM tool may be fast enough to keep up with the remaining traffic.

The same type of techniques could be used by IDS systems for a number of potentially

interesting connections.

The LaBrea Tarpit (http://labrea.sourceforge.net/) is specifically designed to capture and slow down incoming connections of suspected intruders. It is intended to keep incom-ing connections alive, but just barely, and at such a slow speed that nothincom-ing useful can be done with it. The tool is intended to be used as a honeypot to attract intruders and keep them where they cannot do any harm.

Similar to DoS attacks, delaying tactics could be used by attackers. There the goal is to keep resources tied up for as long as possible: as long as a web server is “returning” a reply, that connection ties up a potentially valuable slot on the web server (MaxClients). Another example of malicious delaying tactics may be a web shop application that does not properly enforce timeouts or stock checks. For example, it is rather frustrating for customers to go through a series of forms only to find out at the very end that the desired items are out of stock. In order to prevent such disappointments, the webshop application might temporarily reserve (block) the desired quantity of the desired items until the buyer either acknowledges the sale or quits from the sale process.

One easy attack against such implementations might be to initially ask for a large quantity of a certain item (for example 1000 tickets for a rock concert) and then keep on switching between forms in the application indefinitely, or until the time of the concert, at which point the 1000 unsold tickets become worthless. If the items on sale are some-thing else, say the latest Harry Potter book, keeping so many items unavailable for other

(15)

5 CROSS SITE SCRIPTING (XSS)

potential buyers may cause a large financial loss. The nice part of this type of attack, nice for the attacker, that is, is that no real money needs to be payed to keep so many items locked up for a long period of time: the attacker may eventually just cancel the intended sale.

Other applications where time is an essential part of the protocol, may be vulnerable to delay tactics as well. Consider an auction style of application. An attacker might use delaying tactics against competitors so that their bids come through when it is too late and the sale is already made.

5 Cross site scripting (XSS)

The essential parts of a cross site scripting (XSS)[4][5] [8][7] attack are:

1. an attacker delivers a malicious URL string, pointing to a trusted web site, to a potential victim

2. the victim is tricked in accessing the malicious URL and sends the payload to the trusted web site

3. the web site returns the payload back to the user without filtering out any HTML code

4. the returned HTML code is executed in the victims web browser in the context of the trusted web site: this is when the malicious payload is activated

A prototypical XSS attack might go like this:

1. attacker sends a message to the victim containing the “interesting” URL:

http://trusted.site/select.cgi?

topic=%3Cscript%3Ealert%28%22Alarm%22%29%3B%3C%2Fscript%3E

(string has been wrapped to fit the page) 2. victim clicks on the link

3. the trusted web site responds with:

<html> ...

Your selection: <script>alert("Alarm");</script> ...

</html>

4. the victim web browser reacts to this by displaying an alert message box containing the text “Alarm”

What happened here is that the trusted web site received a request that contained URL encoded Javascript code. Part of the reply is that the server returns HTML code to display what it was exactly that the user requested. In this particular case, however, the user selection string is returned to the user without any filtering at all: the web server

(16)

decoded the URL encoded string, but returned the result without encoding. The victim web browser recognizes the Javascript tags and interprets them: an alert message box is displayed.

A particular nasty variation of this type of attacks is the usage of web based mail services like Hotmail. An attacker could send an email to a victim containing the malicious payload. That alone took care of the first two steps of an XSS attack. Later, when the victim reads her mail (via a web browser) steps 3 and 4 were executed. Hotmail quickly closed this security hole when it became public, but it shows that public web based services may be vulnerable to XSS attacks.

The above example showed a pretty harmless message box as a result of the XSS attack, but more serious attacks are possible.

Delivery of XSS attacks may be done through ordinary web pages (for example on a hacked site), but may also come in the form of HTML messages (email, newsgroups, ...)

Finally, step two (user clicks on a link) may be automated such that the victim is not even aware of the XSS taking place. For example, an onload() Javascript handler may be used to automatically trigger actions when a page has been loaded.

5.1 Stealing session cookies

Cookies are often used to enhance the user experience of web sites. Unfortunately, one of the “enhancements” is often that a logon step is skipped if the proper cookie is pre-sented to the server: the web site has a database of issued cookies and corresponding “authenticated” users. On such sites, a cookie effectively replaces the knowledge of a proper username/password combination: anyone who knows the cookie can impersonate that user on the web site.

If we would replace the payload in the previous example, it may become clear how XSS may be used for stealing cookies:

topic=%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

(string has been wrapped to fit the page)

This payload will still show a message box but this time the contents will be the cookie(s) in use for the trusted site.

Another small change to the payload is sufficient to transmit the cookie data to a location chosen by the attacker:

topic=%3Cscript%3Ewindow.open%28%22crooks.r.us

%2Fregister%3Fcookie%3D%22%2Bdocument.cookie%2C%22%22%29%3B%3C%2Fscript%3E

If we remove the URL encoding from this string, things will become a bit more under-standable:

If this Javascript code is executed, the CGI script “http://crooks.r.us/register” will

be executed and the query string given to that script will be “register=<trusted-site-cookie>” That is all an attacker would need to impersonate the victim on the trusted site.

(17)

5 CROSS SITE SCRIPTING (XSS)

This attack payload assumes that the cookie string only contains none of the special delimiters such as quotes, slashes etc. To make the attack more bulletproof, the cookie text should be encoded before using it first.

Further refinements in the attack code may hide the access to the attacker site com-pletely. One of the tricks that could be used is to “show” an image of one pixel by one pixel and use the URL of the above CGI script as image source location.

The amount of damage that could be done after stealing a cookie, depends entirely on the targeted web site.

5.2 Automated attacks

The previous attack tried to obtain confidential information through an XSS attack, but that is not the only way of exploiting XSS vulnerabilities.

Sometimes, it is enough to have the victim attack herself, without her knowing it. For example, consider an online banking application. The goal of an attacker might to obtain money. So, all that really is required for a successful attack, is that somehow money is transfered to the attacker bank account.

A typical payment transaction consists of one single POST request to the bank server. If all the correct credentials are present, the server will execute the requested transaction. So, all an attacker has to do is to find out what such a POST request exactly contains and have the bank web server echo the necessary scripting code to the victim to execute the transaction.

Exploit code for this type of attacks is quite a bit more complicated than the previous samples, but suffice it to say that it not only is possible to build XSS attack code that performs such operations, this type of attacks have been found “in the wild”.

Of course, this type of attacks is restricted to the servers for which they were built and to users of those web sites.

Automated attacks do not have to be limited to attacking banking applications. A completely different type of attack might be an internal web forum in a company. An XSS attack could be used to post defamatory messages or confidential information, supposedly using somebody else’s account. The basic idea remains the same: use XSS to access one or more pages or forms on a trusted website on behalf of someone else (the victim)

5.3 Attacking the local system

Sometimes there are vulnerabilities in the web browser environment. Normally, all active code downloaded from a web server is executed in a sandbox on the local system. However, sometimes a security vulnerability allows to confuse the web browser security validating components and have untrusted code run as if it came from a trusted environment. An-other possible reason for such security breaches is the misconfiguration of the local security policies (such as allowing code from intranet systems to access the local files)

In practice, most of this type of security vulnerabilities allow code from untrusted source to access local resources, such as all files that the currently logged on user has access to.

Things become interesting when an XSS attack is used to launch an attack to the local system: confidential data may be searched for and uploaded to the attacker (credit card

(18)

data, strategic planning documents, ...), local malware may be installed (such as keystroke loggers, a reverse web shell, ...)

6 Playing the uneducated user

6.1 URL obfuscation

It is not always easy to grasp where a URL might lead to, just by looking at the URL string. For example, where would this link lead you to?

http://g.msn.com/mh_mshp/98765?http://www.microsoft.com/info/privacy.mspx&& HL=Privacy+Statement&CM=Footer&CE=h

(URL string has been wrapped to fit the page)

This link has been copied from the Microsoft home page and supposedly points to the “Privacy Statement”.

The reason for bringing this up is to illustrate that many innocent URLs are not only long, they contain a whole bunch of “weird looking” characters, at least in the eyes of non-technical users.

So, what is a regular user to think of this link:

http://[email protected]/

Surely this must point to a page on the Microsoft website?

Unfortunately: no, it does not. Even worse, it points to a site with name “attacker.net” (note: at the time of writing, this domain was not awarded to anyone)

A URL can contain a whole set of fields, many of them optional and some can appear in multiple formats. The best known of those is the name or address of the destination system. That can be any one of the following:

• DNS name (e.g. www.microsoft.com)

• the dotted IP address of the system (e.g. 207.46.19.60)

• the IP address as one unsigned 32-bit integer (e.g. 3475903292)

The HTTP protocol has not much usage for usernames and passwords, but the FTP protocol does and that is why a URL can contain a username and a password. The syntax thus becomes:

protocol://user:password@host:port/path/path-info?query-string

So, if we look back at the URL “http://[email protected]/” it becomes clear that the part “www.microsoft.com” is actually the username part of the URL, not the hostname.

Whenever an attacker wants to lure a potential victim to a fishy location, URLs can be encoded in such a way that most people blindly follow the links.

At one point in time, there was a vulnerability in Internet Explorer where it was possible that the location shown by hovering over a click-able link with the mouse, was

(19)

6 PLAYING THE UNEDUCATED USER

under an attackers control and did not have to bear any resemblance to the location where the link actually pointed to. The Microsoft suggested workaround was to enter all links manually in the location text field. From the obfuscation examples above, it may be clear that such a workaround probably did nothing significantly for increasing an ordinary users security.

(see also http://pc-help.org/obscure.htm)

With the advent of unicode domain names, a different type of attack became possible. In unicode, there are a number of similarly looking glyphs that have completely dif-ferent unicode values. In the past, such attacks were limited to encoding slash characters with unicode characters that have similarly looking glyphs, in the hope that one or other web server would mistakenly interpret them as real slash characters.

The new attack vectors come from domains that contain characters thatlooksimilar to the characters known from the ASCII table, but have a completely different unicode value. The result is that the web browser may indicate that the user is on “www.microsoft.com” while in reality, she is at a site under control of an attacker, but with a name that looks almost the same as regular“www.microsoft.com”.

6.2 SSL attacks

The SSL/TLS protocols are designed to be secure over an untrusted network. They also provide features so that both partners in a connection can be sure about the identity of the other partner.

That trust relationship is a vital part in most SSL based applications, such as web shops. The server certificate ensures to the client that the server really is the server she intended to use. When client side certificates are used, the server knows the identity of the client. The problem is that this trust is actually based on a number of things:

• proper validation of the certificate contents

• proper validation of a chain of CA’s all the way up to a trusted root CA

If either one of these conditions is not met, there is no guaranteed trust. Unfortunately, in most real life situations there are not many users who are willing to abort an SSL connection because of a warning message from their browser: they are “conditioned” to click whatever button looks to be the one that lets the user continue with whatever she intended to do. It also does not help security one bit that the browser messages do not clearly state that a certificate is basically worthless. Even worse, Internet Explorer, the most popular web browser, adds a warning to the effect that by refusing to accept a server certificate, some parts of the site may not work properly.

The result of all that is that in practice, it is not too difficult for an attacker to setup an SSL web server that pretends to be a web server of a legitimate business. Or, if the attacker does not want to replicate an entire site, he could setup a MITM server between a victim and the real merchant web server that the victim wants to do business with. Sure, there will be a number of annoying message boxes on the client side, but most users will simply ignore the warning signs. A clever attacker might even include some warning message on the MITM web site apologizing for the inconvenience caused by the pop ups but that the site is in a transition phase at that moment. Other social engineering tricks

(20)

could be used as well, all to increase the possibility that a potential victim falls for the scam.

Daring attackers may even choose to buy real certificates from generally trusted CA’s such as Verisign. The trick here is to register domains, and obtain real certificates for servers in those domains, that clearly intended for fraudulent purposes only. For example, let us take a small startup company that legally obtains the domain name ezloans.r.us

The company then proceeds to acquire a valid SSL server certificate forwww.ezloans.r.us

The checks that are typically done by a CA do not include tests to verify that the name of the site corresponds to the business activities by the domain owner. For a regular customer, however, that SSL server will look like a legitimate financial institution web site: it has a valid SSL certificate from a trusted CA.

6.3 Phishing attacks

A Phishing attack aims at obtaining confidential information from an unsuspecting victim. The potential target is tricked into visiting a web site under control of the attacker, but the site has the look and feel of a trusted web site (for example a bank web site)

The actions taken by the scammers once the victim clicks on the wrong link, may vary. A common trick is to present the victim with a fake logon form, so that the user reveals her username and password if she tries to login on the fake web site. If done cleverly, the fake web site may even perform a logon on behalf of the victim on the real web site and redirect the victim to the real site afterwards: there will be no visible indication that the username and password have been compromised.

Recent phishing attempts have become very difficult to detect, even for experienced users. For example, a recent attempt consisted of an HTML email, supposedly coming from Ebay. The HTML code contained an anchor with a link to a real Ebay address. Furthermore, the HTML contained an image of a rendered HTML mail message. In that fake message, there was a “click-able link” to the same address as the one specified in the HTML anchor. As a result, that link would be shown when the mouse hovers over the image (not just the rendered link image) The snag was that the HTML also specified a MAP area covering the entire rendered image. In that MAP area there was a different destination URL address: the address of a site under control of the phisher. To an unsuspecting user, this mail message would be shown as a rendered HTML mail, supposedly coming from Ebay. When hovering with the mouse over the click-able link, the correct Ebay address will be shown. Only when actually clicking on the “link” would the user be taken to a completely different web site. Without looking at the actual HTML code, it is almost impossible to detect such scams ... unless, of course, the user has no Ebay account.

7 Information leaks

7.1 Revealing error messages

Error messages serve two different purposes:

• inform the user of an error situation

(21)

7 INFORMATION LEAKS

There is no need to bother a user with detailed information regarding to what exactly went wrong in the application. On the other hand, administrators and developers will want to know exactly what went wrong, in case of problems. In most applications, unfortunately, there is no distinction between the two different flows of error information.

The classic example of overly detailed error messages is to have one message indicating that the user is unknown and another explaining that the password was invalid. This distinction allows an attacker to determine with certainty if a given username exists or not. Once that certainty has been obtained by an attacker, he can try to guess or brute force the password.

Equally classic is the case where a (partial) SQL statement is returned as part of an error message. For example, consider an error message containing something like this:

syntax error after: SELECT * FROM USERS WHERE USERNAME=’’ OR 1=1’ AND ...

This is a dead giveaway that an attacker attempted a username with value “’ OR 1=1” (note the leading quote in the username string) The error message not only revealed that SQL injection is possible, it also reveals the name of the table containing all valid users (USERS) and at least one columname of that table (USERNAME) Based on this information, the name of the password column is very likelyPASSWORD.

A safer course of action would have been to simply return a generic message stating that the system could not logon the user.

When an error message contains (part of) filenames, things can become interesting as well. For example, let us assume that the new userjanedoereceives an error message like this:

Directory /remote-users/janedoe/ does not exist on this server.

Such a message makes you wonder what goodies could be up for grabs in directory

/remote-users/admin/ ...

Program stack traces often reveal far too much information about the server appli-cation. They are very useful for developers, but should never be shown to potential hostile users. For example, if a user sees a Java stack trace with classnames containing

...mssql.connector...then the user knows that the backend database runs on MS-SQL and specific vulnerabilities may be tried out. Another example is the Apache Struts frame-work. If a Java stack trace reveals that Strust is being used, typical weaknesses for that framework might be tried out by an attacker. One of the nice things about Struts is that if a HTML form is posted, the framework will look for methods of the form “set< html-formfield-name>()” and execute them with the data specified in the submitted HTML form. That is fine and well for expected form fields, but sometimes the implementations contain get/set methods intended solely for internal purposes. Struts does not know if a set-method is intended for internal or external usage.

7.2 Secret information on client side

Similarly like performing security checks on client side, a false sense of security may result in having confidential data sent to the client side. A common example is javascript that constructs asecret path on a web server that is otherwise insufficiently protected against

(22)

malicious access. One indicator that sensitive information is hidden in Javascript code is that the code is obfuscated so that analysis of that code is made more difficult.

The same applies to other forms of code that is sent to the web browser: java applets or flash presentations ...

7.3 Information leaks in crypto systems

As explained in [10] and [1] there was once a vulnerability in OpenSSL related to a timing attack. The basic idea of the attack is that OpenSSL basically performs the following operations on incoming chunks of encrypted data:

• decrypt the data and check the padding so that it reasonably certain that the de-cryption was done with the correct key

• perform a MAC verification (message authentication check)

In earlier versions of OpenSSL, the second step was not done if the padding check failed. The result is that an attacker might insert data in the SSL stream and determine whether the padding check failed or succeeded, based on the response times by the server. That information alone could be used to find out the corresponding plain text version for any given cipher text. This attack is known as the “Klima-Pokorny-Rosa attack”[6].

8 Conclusion

This document describes six categories of attack options that need to be taken into account when designing new protocols or validating existing ones.

The examples provided illustrate how even just a tiny crack can lead to subtle, totally unexpected attacks. It is clear that most attackers think differently than application developers who’s first concern is getting things to work. This reinforces the importance of this work as a first step towards automatic protocol enrichment and verification w.r.t. security requirements.

(23)

REFERENCES

References

[1] OpenSSL Security Advisory. Timing-based attacks on ssl/tls with cbc encryption.

http://www.openssl.org/news/secadv_2003219.txt.

[2] Scott Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the key scheduling algorithm of rc4. Presented at the Eighth Annual Workshop on Selected Areas in Cryptography, aug 2001.

[3] Mark Gaynor and Scott Bradner. Rfc3093 firewall enhancement protocol (fep). http: //www.ietf.org/rfc/rfc3093.txt, apr 2001.

[4] Michael Howard. Some bad news and some good news. http://msdn.microsoft. com/library/default.asp?url=/library/en-us/dncode/html/secure10102002. asp.

[5] Michael Howard. When output turns bad: Cross-site scripting explained.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dncode/html/secure07152002.asp.

[6] Vlastimil Klima, Ondrej Pokorny, and Tomas Rosa. Attacking rsa-based sessions in ssl/tls. Cryptology ePrint Archive, Report 2003/052, 2003. http://eprint.iacr. org/.

[7] Nate Mook. Cross-site scripting worm hits myspace. http://www.betanews.com/ article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391.

[8] N|ghtHawk Thijs Bosschert (nighthawk at hackers4hackers.org). Xss/cookie prob-lems at major (webmail) sites.http://packetstormsecurity.org/0211-exploits/ XSS-Cookie-Advisory.txt.

[9] The Open Web Application Security Project. The open web application security project. http://www.owasp.org/index.jsp.

[10] National Cyber-Alert System. Vulnerability summary can-2003-0131. http://nvd. nist.gov/nvd.cfm?cvename=CAN-2003-0131.

[11] Serge Vaudenay. Security flaws induced by cbc padding - applications to ssl, ipsec, wtls .... InAdvances in Cryptology - EUROCRYPT 2002, International Conference on the Theory and Applications of Cryptographic Techniques, Amsterdam, The Netherlands, proceedings, volume 2332 ofLNCS, pages 534–546. Springer, 2002.

Attack Options based on Protocol Specifications

Version: 1.0

Date: September 30, 2005