Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I would like to know if there is any way to demonstrate how an attacker may attack the integrity of a website due to an unencrypted connection and how SSL will avoid this.

For the aspect of confidentiality, the following example explains: When an unencrypted connection is made to a website, an attacker use a packet sniffer such as wireshark to sniff unencrypted wireless connections and obtain passwords that are sent on the unencrypted wifi. With SSL, the data (and thus passwords) would be encrypted.

What would be a similar example, but for data integrity?

share|improve this question
add comment

3 Answers

If integrity was not maintained, an attacker could alter Web pages in transit, and, for instance, modify Javascript code contained in these pages. Encryption, by itself, does not prevent relatively precise alterations, provided that the attacker has some idea about what the encrypted data is. In most Web contexts, the attacker can also register as a normal user, so he can see the structure of Web pages that normal users obtain.

When the connection uses RC4, then a key-dependent pseudorandom stream is generated and XORed, bit by bit, with the data to encrypt. Therefore, if the attacker "guesses" that a given byte is the encryption of a 'A' (ASCII code 0x41) and wants to make it the encryption of a 'm' (ASCII code 0x6D), then he just has to XOR the encrypted byte with 0x2C (that's the XOR of 0x41 with 0x6D) to obtain another encrypted byte which, upon decryption, will yield a 'm' instead of an 'A'. Nothing else would be impacted; thus, with RC4 encryption, surgical alterations are easy.

With a block cipher in CBC mode, things are less easy for the attacker, but he can still enact some evil: if he wants to modify a specific byte, he can, but this will mangle the previous block. Specifically, with a block cipher, the data is a sequence of blocks of 8 or 16 bytes (depending on the cipher: 8 bytes for 3DES, 16 bytes for AES). The attacker can modify at will a block, with surgical precision, provided that he knows the initial value of that block and does not mind changing the previous block into some uncontrollable random junk.

Let's take an example. Suppose that a Web site has a login page, with an HTML form, which looks like this:

<form action="https://www.example.com/authenticate.php">
Login: <input type="text" name="login" /><br />
Password: <input type="password" name="password" /></br />
<input type="submit" name="Submit" />
</form>

I know it is ugly; it is just an example. When the user clicks on the "submit" button, the browser sends a POST request to the https://www.example.com/authenticate.php page.

Now suppose that this page is CBC-encrypted with 3DES (8-byte blocks) and that the '.' of '.com' happens to be at the start of a block. The attacker can then XOR the previous 8 encrypted bytes (the bytes corresponding to .example) with the following:

 00 01 0E 09 01 07 0D 5B

On the victim's browser, the form will decrypt as:

<form action="https://www########.bad.fx/henticate.php">
Login: <input type="text" name="login" /><br />
Password: <input type="password" name="password" /></br />
<input type="submit" name="Submit" />
</form>

Where the "########" will be some random bytes. Provided that none of them is a zero or a double-quote (chances that this happens are low), then the browser will consider them as part of the target URL. The bad.fx domain is controlled by the attacker (the "fx" TLD does not really exist; feel free to replace with your favourite "TLD for Evil people"); the attacker's DNS gleefully redirects all requests for anything.bad.fx to his server's IP address; and the attacker bought (completely legally) a wildcard certificate for "*.bad.fx". When the user enters his password, his browser connects to the attacker-controlled Web site, does the SSL, is perfectly content with the attacker's certificate (assuming that none of the '#' is a dot; again, this is probable), and sends the password.

Fortunately, SSL includes strong integrity protection, which prevents such attacks. With stream ciphers like RC4, and block ciphers in CBC mode, the integrity protection uses HMAC; newer versions of TLS can also use block ciphers in GCM mode, which integrates an equally good integrity protection. If the attacker attempted any of the stunts described above, the client (Web browser) would detect the alteration and protest and refuse to use the decrypted page. See the standard, section 6.2.3.

share|improve this answer
    
In CBC mode, an attacker can modify a specific byte at the cost of mangling the preceding block. –  Seth Sep 15 '13 at 17:31
    
Dammit, I knew I got it wrong somewhere. Now I must edit the whole example... –  Tom Leek Sep 15 '13 at 17:39
    
Example fixed. Indeed, with CBC, a block is decrypted with the block cipher, and then XORed with the previous encrypted block, so surgical alteration works by flipping the corresponding bits in the said previous encrypted block. –  Tom Leek Sep 15 '13 at 18:07
add comment

I wrote a blog post about data integrity and why loading login forms over HTTP and then using a POST to HTTPS is a security risk.

As the login form is loaded over HTTP it's vulnerable to modification by a man in the middle. In the example I show how I can alter the form action to steal a user's credentials and then redirect them to the target site. Because the form is loaded over HTTP you can't be sure of the integrity of the form.

Feel free to check out my blog: http://scotthel.me/tlsintegrity

share|improve this answer
add comment

A simple example of data integrity would be that if an attacker is able to intercept your data (MITM attack), he/she will be able to change it on the fly and send altered data as it was from you. lets say you are connected to your bank and send a request to transfer some amount X to an account Y. The attacker would change the command you sent (attack on integrity) and make the transaction of amount X to a different account and not the account Y you intended to.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.