Firewalls and Intrusion Detection Systems (IDS) are the basic core regarding safety in any company or network infrastructure within an organization. While a simple firewall filters the traffic, taking as a basis the information of the network as the TCP/UDP ports and IP addresses, the IDS performs a much more in-depth research considering and analyzing the contents of the actual data of each package that circulates in the network.
To really evaluate the packets on the network, the IDS needs to possess an understanding at a very low level about the type of information that circulates within the specific protocol. Therefore, an Intrusion Detection System (IDS) is an active process or device that analyzes the activity of the system and the network for unauthorized entry and/or malicious activity.
There are many different brands and at different levels. In 1998, Ptecek and Newsham demonstrated how an IDS could be evaded, using various techniques such as overlapping fragments of shellcode, enveloping sequences of numbers and inserting random packages within the payload of an exploit. This was possible due to the IDS back then did not process or interpret the packages in the same way that a proprietary system of the network would. Before explaining the specific manner proposed in this paper to evade an IDS, let’s make a brief introduction to the basic operation of an IDS. Even though all IDS do not work exactly the same, follow this pattern:
- A sniffer reads all traffic through an interface in promiscuous mode connected to a mirror interface of a switch, a router, a hub, etc. In the case of flush mounted devices, directly employs the mirror interface itself.
- Some preprocessors treat the data read by the sniffer, to process then faster by the rules engine. Also, have other functions, among them try to avoid that an attacker can circumvent the rules engine, aspect that will we talk later.
- An engine rules and a set of rules. From packets treated by the preprocessors, the engine rules pass the packet treaty by each one of the rules, by looking for a pattern of attack that matches one of these. If it matches, then performs the operation indicated by the rule, usually consider it to be an attack (accept) or reject the package (drop, pass, reject…). In the case of a confirmed attack is notified to the postprocessors.
- The postprocessors are responsible for treating the attack either notifying the attack via email, storing the attack in plain text or in a database, blocking the attack (in this case the IDS would be an Intrusion Prevention System IPS), etc.
Once explained the operation from a global point of view of an IDS at network level, we will explain briefly the possible attack vectors that allow to evade these systems. Mainly there are four attack vectors and a fifth, that in spite of not being a vector of attack has to be introduced as a limitation of the IDS:
- Evasion through fragmented packets in the preprocessors. There are two possible evasions in this attack vector.
- Encoding used in the attack. Not all IDS support the same type of encoding, which supports the attacked service.
- Worms polymorphic and metamorphic (polymorphic and metamorphic worms). F 2 | P a g e
- Treatment of the input data (incorrect) parsing by the preprocessors, which can lead to a denial of service and therefore the annulment of the IDS.
- Encrypting communications. Despite the fact that this is not an attack vector, must be taken into account. As is natural, if a communication between an attacker and a server victim is encrypted, the IDS cannot recognize any pattern of attack. In fact, the reason the communications are encrypted is no intermediary element can understand the data between both of them.
The problem with the types of traditional evasion of IDS, it is precisely its base in the full knowledge and the certainty of these changes at the level of TCP/UDP. Here is where the symmetric encryption at the level of opcodes appears, i.e. the traditional polymorphism, which does not work at all times. There are companies that have as specific purpose its detection in the engine of analysis of the modules IDS. Not only are considered the methods described above, but also, as part of the main core, in the flow of execution consider aggregation of scripting in different languages, which allows the system administrator or security specialist, adding ACLS on the full flows based on the embedded API of the specific product. And if the possibility of adding a heuristic analysis, concludes in the detection of malicious attacks on the system.
It is here where the need arises for a more powerful method to help the smart evasion of an IDS. This paper focuses on how to achieve this by using an implementation of RSA for asymmetric encryption of the shellcode, which is sent via the network. Therefore, describes a new idea of implementation of polymorphic shellcodes, enabling the evasion of network security that provides an IDS once located a vulnerability. During its exploitation and that in turn can serve as a model for the protection and/or attack, for the computer security professionals that really attend development, detection and containment of exploits to low level.
RSA in its reduced form will be used as a method of encryption, which will be used to evade satisfactorily an IDS. Note as this is a new implementation, still requires improvement. Explained in detail below how to perform the encryption and decryption of the shellcode using the proposed RSA algorithm.
The basic concept of the polymorphic shellcode is that during the exploitation of a vulnerability, when the exploit is sending the shellcode through the network, this chain of opcodes is detected by the NIDS. The proposal described in this paper is to cypher this chain using RSA algorithm, as is an asymmetric algorithm, the resulting string will not have any coherence or logic, therefore the IDS will not know that is a shellcode. The string will have the next structure:
- Opcodes for deciphering string
- Opcodes cyphered by RSA algorithm
In this paper we will explain the complete idea and the executed tests, the explanation will be carry on the next order:
- How to encrypt and decrypt the opcodes of the shellcode
- How the program that decrypts the shellcode was built and how to get the opcodes
- How the program that is able encrypt the opcodes (C#.NET) was built
- Performed Local tests to verify that the all the algorithm works
- Remote test to validate the algorithm really can work with a real remote exploit.