We already know that the RAFC standard describes a TCAP session establishment as a process that requires
sending four packets.
Please note that having received the second H.K. packet the server should be silent.
In practice computer systems and we're not talking here only about the TCAP implementation and operating
systems but also in network devices would behave differently.
The initiator would send a packet with its own initial sequence number.
The server would respond with an AC K packet increasing the acknowledgement number.
The client would silently accept the UK packet up to this point everything would happen normally at
this point the server would send to the initiator the third packet.
That is its own send packet with a pseudo random sequence number and a valid acknowledgement number.
Instead of sending the AC K packet to end the whole process as is described in the RAFC standard éclat
would now send this in a S.K. packet.
The sequence number would get sent once again and the acknowledgement number would be increased by 1.
The server would respond to a sin k packet in accordance with the standard by sending in a UK packet
with the TCAP session would already have been established.
The problem was however that from this moment the direction of the session would be reversed.
So it would look as if the server had connected to the client and not the other way around.
The direction of the TCAP session would change.
Please remember that modern firewalls and as we'll see in a while intrusion detection systems to are
stateful and that they take into account session direction.
From that moment on it looked as if a trusted computer from inside connected to an untrusted computer
from outside.
In reality it was exactly the opposite.
We have yet to mention that the acknowledgement does not affect the way the process unfolds.
You can establish a TCAP session by sending packets in the following sequence sin.
Sin Sin.
AC K and AC K.
Let's summarize.
Now the results of the research conducted by Break Point Systems and SS lab.
It turns out that only one intrusion detection system out of every three.
Tested by the company detected the attacks carried out by the means of reverse TCAP session if the session
was established through or through a handshake all systems tested were able to detect the attack reversing
the session direction for two out of the three systems.
You'd think that the ratio is not bad but the problem was that the system which passed the test successfully
was stateless it didn't analyze session state other high end stateful systems were deceived.
The built in system firewalls of Windows Vista Linux and Apple systems were tested to none of these
firewalls were able to stop the attack.
All of them detected and blocked the hostile activity in a regular session.
A year later the NSA slapped company tested six professional firewalls all of them top of the range
for effectiveness of filtering the data sent in the reverse TCAP sessions.
At that time this problem was already known for more than a year.
Five of the six firewalls.
Theoretically the best ones available did not block the attack by means of the reverse TCAP session.
Although they managed to block it when it happened during a regular session statement summarizing the
tests were quite pessimistic.
They said that the producers of this type of hardware and software perhaps unwittingly misled their
clients.
The products were tested for known threats which was a comfortable situation.
If you produce software designed to detect threats and you would test the software using only known
threats it would probably seem that your software was effective.
The problem is that manufacturers of firewalls and intrusion detection systems cannot know all threats
because every now and then new threats surface
and only recently someone has read the section 3.3 of the RAFC document.
This shows very strongly the computer system administrators should analyze the data that passes through
their systems on their own but it does not mean that they need to on their own resemble and review data
previously divided into many pieces and packets such a solution would be inefficient.
You just have to use a program such as wireshark will examine this program in the remaining part of
this lecture from both the theoretical and practical perspective.