Geekly Articles each Day
📜 ⬆️ ⬇️

Interproject Interaction Security

Introduction


Today, many Internet services interact with each other through the Internet. A special class of interactions is those in which the transfer of confidential information (personal data, secret messages) or commands that must be clearly confirmed by someone (for example, money transfer or publication of a message on behalf of someone else). It is obvious that such services should be reliably protected from intruders.

Unfortunately, not all developers think about the degree of security of their applications. The problem is somewhat aggravated by the fact that many e-business representatives are developing protocols that, when implemented in end services, can create serious vulnerabilities if used without proper understanding.

The objective of this article is to briefly describe the possible types of attacks in case of inter-project (i.e. server-to-server) interaction and means of protection against them in order to use ready-made protocols more thoughtfully and develop your own. The basics of information security will be preliminarily considered, since often the knowledge of end-developers in this area is somewhat fragmentary.
')
Protection (or lack of protection) against various types of attacks is demonstrated on the example of the protocols of today's popular systems: Assist , Cyberplat , WebMoney , ChronoPay , Robokassa and PayPal (payment systems), as well as OpenID , OpenAuth , OAuth (decentralized authentication).

Secure communication


So let's define what we mean by the words " secure interaction ".

1. Authentication . Let server A want to send a message to server B. B. should be able to verify that the message was sent from A. This verification is called server A authentication on server B.

2. Data integrity . We want to be sure that the message was not changed during the transfer (for example, $ 50 was paid, and confirmation was received at $ 500).

3. Confidentiality of interaction . This clause implies that only those parties are entitled to receive the message. As a rule, this item implies encryption of information during transmission.

In some cases, two more points can be considered: access control and the impossibility of non-repudiation, but for now we will leave it aside.

Cryptographic primitives


Here it is necessary to make some digression to the theory. I will not describe in detail the basics of cryptography (otherwise the volume of the article will go beyond the reasonable), but briefly mention the basic " cryptographic primitives " to denote the knowledge necessary to understand the rest of the article. Those interested can follow the links to Wikipedia and learn more.

SSL / TLS and HTTPS


Speaking about “security of interaction”, you can ask a reasonable (in some way) question: all this: authentication, integrity support, encryption, is in SSL / TLS (HTTPS). Why do you need something else?

Therefore, the second insight into the theory will be a brief reminder of what SSL / TLS and HTTPS are .

The SSL protocol ( Secure Socket Layer ) and its “descendant» TLS ( Transport Layer Security ) was developed in response to the need for secure client-server communication. The protocol works at the transport level of the OSI model . With proper use, it allows you to establish an encrypted connection between the client and the server. The protocol is protected from modification and reading of messages sent in both directions. The protocol also allows the client (I repeat: with proper use) to make sure that he has established a connection with the correct server, and not with the rogue server (in other words, the client can authenticate the server). There are modifications that allow authentication to the client, i.e., provide two-way authentication.

HTTPS ( HTTP Secure ) is the same HTTP, but sent over a channel protected by SSL / TLS.

It is very important to understand that having an SSL / TLS channel in an incomplete implementation means only that the connection between your point and the remote server goes through a protocol that is well protected from the point of view of listening and changing information. But it doesn’t mean anything until you are convinced that the remote side is the one you wanted to contact. You can make sure of this only if you know the certificate of the remote side in advance, and you trust it, or if you receive the same certificate via an unprotected channel, but signed by a “third party”, the so-called Certification Authority (CA). At the same time, the public key of the CA used to verify the signature must again be known to you in advance so that you do not have to transmit it over an unprotected channel. For example, how is this security ensured in browsers? Certificates of major CA (the most famous - COMODO, VeriSign, Go Daddy, Thawte, etc., there are only a few dozen of them), are embedded in your browser in advance.

How to verify the certificate in the code of your service? If you have a certificate in advance, it is quite simple to do this (for example, PHP programmers can look in the direction of curl_setopt (), options CURLOPT_CAINFO and CURLOPT_CAPATH). In this way, the security of the connection is ensured in the code of interaction with the WebMoney server. If you don’t know the CA server in advance, it’s somewhat harder to do such a check in practice, because you’ll have to select and maintain a collection of certificates from various CAs yourself.

In practice, certificate verification in code is often not performed, which can lead to one of two attacks : server substitution or Man in the Middle (MITM) attack. The latter means that there is another server (M) between you (A) and the destination server (B). You (A) establish an absolutely secure connection with M, thinking that you have established a connection with B. After that, M establishes a secure connection with B and starts transmitting your requests to him, and you - his answers. Thus, M can listen to the interaction A - B and even modify the transmitted messages.

The logical question is whether the server substitution and Man-in-the-middle attacks are feasible in practice.

Most likely, if both interacting servers are located in serious data centers (and if the servers themselves, of course, are not hacked), then the implementation of such an attack is very difficult. If the server is located in your corporate, university or home network (not designed in the best way), then, say, an ARP attack will completely allow an attacker to send all the traffic entering and leaving the network through himself, and then all these attacks become very just feasible.

So why we are not always satisfied with SSL / TLS.

Implementing safety in practice


So now let us briefly return to the “ safe interaction ” and see how the points we have identified are implemented in practice.

1. For authentication , they usually use either a “login-password” pair or a digital signature generated by one or another method.

2. To verify the integrity of the data using SSL / TLS and generated by the application digital signatures.

3. To encrypt data, that is, to ensure confidentiality, most systems use SSL / TLS (there are examples of self-encrypting keys, however, data is encrypted with “its own” methods relatively rarely).

Speaking of web services, SSL / TLS is most often used as HTTPS.

Types of protected applications


Before finally moving on to attacks on protocols, it is necessary to say about the limitations in which the designed system works. I would like to mention three main types of applications for which you can consider secure communication issues.

1. Two interacting parties have the opportunity to exchange in advance a guaranteed channel with the necessary information : a public key, certificates, passwords, and so on. Such a channel can be the internal transfer of necessary information between people (best of all), an alternative communication channel (cellular, telephone) or even the Internet - if both parties are sure that there is no “Man in the middle” or another way to intercept or modify the message.

2. Centralized architecture . Every 2 parties do not have the opportunity to agree with each other in advance, but any network participant trusts some third party who signs the certificates of the interacting parties and ensures their validity. An example is the public key infrastructure (Public Key Infrastructure, PKI) or, with some reservations, the same Internet in which browsers trust a finite number of certification authorities (CA), and on the basis of this can make sure that they interact with the desired site .

3. Decentralized architecture . In such applications there is no single third party. It is important to understand that in such architectures the main task is to make sure that the second time the same person came to you that came earlier. That is, the first time you allow anyone to authenticate (for example, on sites that support OpenID, anyone can authenticate). Suppose further that you have made some contribution to the system : for example, you wrote a message. The next time you come here, the site will have to give you (and only you) access to editing this message. Examples of infusions: OpenID, OAuth, Peer-to-Peer protocols.

Attacks and methods of protection


And finally, let's consider the main types of attacks carried out on protocols - and how they are protected from them.

1. Lack of verification of the authorship or authenticity of the message

Let me remember the old joke. In programming, there are two types of errors: the lack of validation of input data - and all other errors.

If you received a message M from side A, then you need to make sure that: a) the message really came from A; b) that A sent exactly the message M, and it was not changed along the way.

An example of an illiterately designed protocol is the protocol for the interaction of the payment system Assist with an online store. After paying for the purchase on the Assist server, the user returns to some URL_RETURN_OK address, which is transmitted in the clear and can be modified by the user-buyer himself. That is, the user returns after paying for the purchase to our online store, they say to him: “Thank you, you have just paid a payment of $ 1000,” but the store has absolutely no way to make sure that this is true. Only later, with the hands of a manager or automated (but not more often than once in 10 minutes!), You can check that the payment has really passed. The Assist protocol, by the way, has not been modified for more than 4 years. All you need is to add a digital signature.

So, how to verify the authorship and integrity of the message.

2. Hope for HTTPS reliability.

As mentioned above, the implementation within the HTTPS protocol of authenticating an arbitrary server to which your application connects is a rather complicated task. Above, we looked at the details, the brief conclusion of which is simple: without authentication of the server certificate, the meaning of HTTPS can be reduced to zero.

None of the decentralized authentication protocols, be it OpenID, OpenAuth, OAuth, is protected from server spoofing or Man-in-the-Middle. In some cases, payment systems (PayPal, Assist) can be attacked in a similar way. In the end, you can convince the online store application that payment occurred, although in fact it was not.

I emphasize once again that you can defend against this attack if the server that establishes an HTTPS connection has a sufficient number of certificates from the main CA of the Internet (VeriSign, COMODO, etc.), but in practice it is sometimes difficult to implement.

And I stress that for decentralized systems this is a fundamentally unsolvable problem . While for commercial payment systems belonging to our classification (see above) to systems whose parties can “ agree in advance, ” this attack is warned by competent protocol design. An example of such an implementation is WebMoney , which provides a certificate for authenticating an HTTPS connection. ( Chronopay seems to do that too - correct me).

3. Attack "Man in the middle" (Man in the Middle, MITM).

We looked at the MITM attack for the HTTPS protocol. However, other protocols may also be vulnerable to this type of attack.

An example of this is Diffie-Hellman , used in OpenID. As mentioned above, its essence is in generating a shared key K by two parties: A and B. But if we have someone “in the middle” (M) who can change traffic, then it may turn out that A generated a common key with M K1, and B - common with M key K2. As a result, “Man in the Middle” M can sign and read any data going in any direction.

Of course, such an attack will not work in OpenID if the client and the server (OpenID Provider and Relying Party) interact via HTTPS with full certificate validation.

4. The transfer of the secret key over an open channel.

Many developers do not understand the essence of the secret key. All security in the infrastructure using the public key is based on the fact that the interacting parties can unconditionally trust someone. The second server, the third party is not important. As a rule, the question of "trust" rests on the verification of a digital signature using the public key of the message subscriber. All security can fail if this public key (certificate) is transmitted over an insecure channel and can be modified along the way.

In the "serious" companies there are special people responsible for the transfer, storage, updating of this key. Transmission usually occurs offline through reliable couriers.

If you are creating a protocol for the payment system, it is ideal to transfer the public key of your server personally to the owner of an online store (on a floppy disk or flash drive) when signing a contract in the office. Yes, for one reason or another, this is not always realistic. Therefore, the certificate is often distributed via the Internet. But in this case it is necessary to take all possible measures to prevent the substitution of the key. You can not send the key by e-mail. You can not give it to download via HTTP - only HTTPS. The site should contain information on verification of downloaded information (for example, a hash from the key to verify its authenticity).

5. Re-send the request.

This type of attack we will look at two examples.

Example 1: payment system. Let me, a respectable server, want to send $ 10 through the payment system. At the same time, I use HTTP or “bad” HTTPS (without checking the certificate) to connect to the server of the payment system. I honestly form a request and sign it with my certificate. The other side receives the request, and my $ 10 leaves to the addressee. But since I used an open protocol, the attacker was able to read my request to the server. If this intruder wants to ruin me, he takes and sends the same request to the server of the payment system again. The server verifies the signature (it is correct, since it is formed by the “correct” server), and the other $ 10 is debited from my account.

Example 2: OpenID protocol. The OpenID Authentication 1.1 protocol had the following vulnerability. If an attacker tapped an interaction between an OpenID client (Relying Party) and an end user, he could, after some time, initiate the re-authentication of that user to the Relying Party using his OpenID. In this case in the logs of the Relying Party would appear a record that the person went to the site. In particularly mindless cases of implementation, the attacker could even authenticate as this user. Yes, there are ways to protect this, but they were not stated as mandatory in the protocol.

This vulnerability was eliminated in the OpenID Authentication 2.0 version by introducing changes in the behavior of both the server (OpenID Provider) and the client (Relying Party). Readers familiar with the protocol OpenID Authentication, I offer a puzzle to understand: how to implement such protection in the client OpenID version 1.1, if the server can not be modified?

To protect against this type of attack, there are several ways.

6. For completeness of description (and also because it is sometimes forgotten), it is worth mentioning platitudes as well. If the system is built on the secrecy of a password or key, then this data must be reliably protected. Setting UNIX privileges 07 to access all files on a shared hosting may result in the fact that the certificate file or password to the database where the “secrets” are stored reads the “server neighbor”. Do not forget to set passwords, privileges, to restrict access. However, I will not be spread for a long time, since everyone knows this (although not everyone does).

7. Another type of vulnerabilities are those created by programmers when implementing a protocol. Let me give you one simple example (fortunately, not being a serious vulnerability): 2 years ago, in two of the five most popular implementations of the OpenID server, developers confused the concepts of life_time (key lifetime in seconds) and expires_time (key expiration time in seconds from January 1, 1970). Particularly critical parts of the code should be viewed by other participants of the project (OK, is this also a commonplace? - then we move on to the conclusion).

findings


The main idea that I wanted to convey in the article is that you shouldn’t rely on the developers of this or that protocol, even if the authors are companies with a big name. Think for yourself, decide for yourself.

A little about the practice, as well as what went beyond the article.

Source: https://habr.com/ru/post/77689/

More articles:


All Articles