Extended Validation Certificate

The extensions defined for the x.509 v3 certificates provide methods to as- sociate additional attributes with users or public keys and for managing relationships between CAs [21]. The certificates that use such extensions are called Extended Validation (EV) Certificates or High Assurance (HA) certificates. The primary purpose of this certificates is to identify the legal entity that controls a Website and to enable an encrypted communication with it. The secondary goals of such certificates are to fight phising, to help

organizations against fraud and to help law enforcement. Each of these ex- tensions are designated as critical or non-critical. In case critical extensions cannot be processed or are not recognized, the certificate should be rejected. Non-critical extensions should be processed if recognized, otherwise may be ignored. There are many extensions that can be applied to an EV certifi- cate, some of those are: Authority Key Identifier, Subject Key Identifier, Key Usage, Certificate Policies, Subject Alternative Names, Issuer Alterna- tive Names, Basic Constraints, Policy Constraints, CRL Distribution Points, and others. For the scope of this thesis we are interested in the extension calledSubjectAlternativeNames. This extension allows identities to be bound to the subject of the certificate. This extension allows a company to have a single certificate for several activities, instead of a single certificate for a single activity. Therefore, the certificate with such extension is valid not only for the identity described in the subject field but also for all the identities listed in the field of such extension.

Our Approach

In this chapter we explain the core of this project: our assumptions and the SSL features used for detection. As explained in Section 1.2, in literature there is no reference to botnets, that are using SSL as a C&C communication channel. This had a lot of impact on our approach. The main question that raised was:

How can we detect something that perhaps does not even exist?

Analyzing the literature it is possible to see how botmasters are evolving their infrastructures in order to make them more complex and reliable. As we have seen in Section 2.5, in the past years they are moving towards encrypted solutions. Therefore, it is possible that they will also try in the near future to exploit SSL for data exfiltration. For data exfiltration we mean the process of data transmission from the bot to the server, through the communication channel.

If we have a deeper look at the state of the art, we can see that most of the intrusion detection systems have been built by researchers upon existing malware or solutions that were proposed before by researchers. Therefore, they could analyze the behavior of that malicious software, and create a detection system based on that behavior. In our situation this is not possible, because, since it is not known if there are botnet with this specific protocol, there are no malware to analyze. Therefore, we tried a different approach.

So, we decided to take a preventive approach. In this case, we do not mean prevent the infection of the machine, since the data exfiltration starts post-infection. Forpreventive approach we mean an intrusion detection solu- tion that is built without the analysis of malware, that exploits just apriori knowledge like typical botnet behaviors and SSL protocol characteristics. We tried to define some potential protocol features that could be helpful in order to detect possible botnet behaviors within SSL traffic. Needless to say, the goal of the project is to build ananomaly based intrusion detection

system based on those features, and notsignature based since it would not even be possible due to the lack of malware.

4.1

Assumptions and Features Selected

Before starting the selection of potential features we made two fundamental assumptions. As it has been shown in the previous section (Section 3), the SSL protocol is mainly divided in two parts: the handshake, which isplaintext

and aims to exchange the security parameters for the connection, and the application data, which is theencrypted part of the protocol where the peers communicate and exchange data. Our assumption is that the encrypted part cannot be attacked, due to capability reasons. Since it does not reveal any information, it is not considered in our approach. Our focus in on theplaintext part, which mainly involves the handshake protocol. This part reveals some information that could be useful in order to detect malicious connections.

There are two main benefits of our assumption: it is aprivacy-preserving

solution, because the payload, which is in the encrypted part, is not analyzed at all, and it is lightweight, because we are concentrating on a small part of the SSL traffic, which is the initialization of the connection.

The other key assumption that has been done is that the malware au- thor has complete control over the client and server applications, because he spreads and builds his own malware. Therefore, he can easily avoid following the standards of the protocol and make its "own rules". In case the criminal would correctly follow the rules of the protocol, our solution would not be able to detect the malicious behavior, because the data exfiltration of the botnet would camouflage within the benign SSL traffic. However, due to the characteristics of botnets (e.g. short lifetime of servers domains), in our opinion it is unlikely the criminal would pay a lot of money for SSL certifi- cates for each of those websites. Every time a web-server would be taken down, they would lose the money of the certificate (i.e. it would considered invalid), therefore it would be non-convenient.

Some controls on SSL connections, are made by browsers. For example they check if the certificate of the server is valid for the domain requested by the client (Figure 4.1). These controls have been introduced in order to avoid phising attacks and to warn the user about possible untrusted connections. However, this is not true for background SSL applications (e.g. malware). Therefore, malware authors can communicate through broken SSL connec- tions. In this project we will bring these checks at network level, because would allow us to check more SSL connections at the same time. Doing this we can spot possible SSL misbehaviors and eventually detect malicious connections.

Figure 4.1: Green bar represents a trusted SSL connection