- Email: [email protected]
Covert Channels: Covering ‘Malicious’ Traffic
issue.qxd
10/04/2003
16:23
Page 16
grid computing really taking place on the resources I think it is being executed on? •Can I guarantee that resources will be available when I need them? •What recovery procedures are in place to cope with failures while my computation is taking place? In the case of external grids not managed by a single third party, there is also whole issue of identity management and security policy mapping to contend with. The computers within the grid may be under the jurisdiction of different policies with varying levels of access control, so that some users might be barred from some of the resources, leading to varying experiences of the grid. The greatest challenge in making a loose multi-domain grid work lies in the middleware software that co-ordinates all the processes, and a major part of this is the mapping of identities and reconciliation of policies. The key requirement is identity mapping, so that the grid can support single sign-on while maintaining local IDs and legacy access control mechanisms on the hosts within the grid. This means that users will need a separate local account on any host machine they want to use, which is not ideal. It also requires a degree of mutual trust between the user’s
local access control and the grid’s gateway server. It might prove easier to administer a system based on specification of trust relations between sites, rather than requiring direct mapping of IDs. Thought also needs to be given to the type of applications for which external grids will be used. The principle distinction is between jobs that need to be executed almost immediately, and those that can be, and indeed may need to be, scheduled in advance. The latter would apply for jobs involving large amounts of data and bandwidth, particularly where there is real time processing involved, which would fail if the required resources were not available exactly when required. Obvious requirements include an assurance that reservations will be honoured accurately, and this requires a sophisticated booking system allied to access control to ensure that users have permission to use the specified resources at a given time. For both categories of application there are some general requirements, which can be summarised under six headings: 1 A set of suitable target hosts for the work must be identified. 2 The grid scheduler must ensure that the user is allowed access to the specified hosts and will be granted a
Covert Channels: Covering ‘Malicious’ Traffic Dario Forte There are tools that can hide the real intentions of an attacker. Here we discuss attacks and countermeasures for a problem that is by no means new.
Covert channels: general background Some time ago, during work to update the new Common Intrusion Detection Framework (CIDF) some members of the technical community mentioned the fact that so far no solution has been found to the problem of covert channels.
16
In practice, actually, covert channels do not exist. Or rather, they are not part of any specific protocol, but exploit existing protocols to transfer otherwise forbidden information and/or programs to other users. The suite of protocols that naturally gets exploited in this case is TCP/IP.
sufficient level of resource on them. 3 Mutual authentication needs to take place between the user and grid gateway. 4 The grid gateway must map the global grid ID to local IDs on each host, and then submit the resource request for that host so that the work appears to be performed on behalf of a local user (remember the host may also serve as an internal machine to a particular participating organization). 5 The executing jobs may need to be given permission to read and write remote files on behalf of the user. 6 The overall grid scheduler will need information about availability and local accounts on the member machines of the grid, and so must be capable of being trusted not to leak this, providing only necessary details to grid users. Despite all the security hurdles, use of grids is growing fast within the biosciences community, and others will be watching progress closely. A lot mush to done though before computing cycles can be traded like electricity on a spot market, given that the ultimate ambition is to make computing power just another utility available from a national grid.
With its current conformation, this suite can be used to bypass controls ranging from simple packet filtering and non granularly configured network sniffers, all the way to password perimeter controls. The activity dubbed “Covert Channel Encapsulation” via TCP/IP is also known in the underground as TCP/IP Steganography and involves inserting into certain packets portions of semi encrypted information that get reassembled by the legitimate receiver upon reaching their destination. Attackers usually use opportunely modified TCP/IP packet headers as covert channels (normally with the help of encoding techniques) or, in other cases, using ICMP, routing
issue.qxd
10/04/2003
16:23
Page 17
covert channel control information and UDP datagrams. According to the thinking in certain underground circles, this last possibility would not cause the same effects because of the least privilege approach exercised by a number of firewall administrators.
Covert channels: how encapsulation is done A properly executed covert channel generally does not exploit the various optional fields left ‘free’ in a packet, since a firewall administrator could easily set up a filter for the purpose. Instead the tools most commonly used by malicious hackers handle this operation in two steps: • Identification of the type of field to affect. • Encoding of the field contents. The underground identifies the following as being appropriate for the operations in question: the IP packet identification field; the TCP initial sequence number field; and the TCP acknowledged sequence number field. In practical terms, the exploitation consists of encoding an ASCII value of the range 0-255 into the above fields. This way the engine thinks it is reading an address or, in any case, a perfectly kosher piece of information and lets it by the filter. Of course the encoded information is linked to the real address, which may also contain the forced attribution of a port through which the communication is intended to be passed. Depending on the type of field used, an almost certain result should be attainable. On the basis of experiments it seems that the use of the sequence number fields is the most fruitful in this regard, partially because the tools available can handle the encoding much more efficiently.
Covert channels: the tools used Everything depends on the type of protocol used. Nevertheless the payload of the covert channels is usually encapsulated in rootkits of varying power. I
personally have had direct experiences with Trojans that used ICMP as covert channels. In any case, practical experiments in covert channels have successfully used the techniques described above with the channelling going on at the kernel level (LKM, to be precise). The loadable kernel modules were then dynamically loaded and performed the operation in a completely transparent manner: a ‘fine touch’.
“Q” when a letter may represent danger Recently, attention has been raised regarding the combination of more or less esoteric Trojan horses and the covert channels themselves. On this premise, the technical community has lately been oriented towards the analysis of certain backdoor tools used by malicious hackers to ensure that compromised machines will remain so for the long term. Q is one of those tools. • To tell the truth, Q has been “on the crest of the wave” for a number of years, along the lines of products such as LOKI and its ilk, with which it shares general operational characteristics. It is obviously UNIX-based and has the prerogative of using Stealth techniques to make it even less recognizable. The latest versions of this attack tool can be compiled even on Windows 32 platforms, which opens up the world of covert channeling to platforms until recently held in relative disdain by attackers. • Q consists of a client/server architecture. This principal characteristic may, indirectly, constitute a limit to its spread, whenever attempts are made to contact a server module following a scan from a non-original client (for example belonging to an occasional attacker who is doing portscanning). This is an operation that gets carried out rather habitually and falls into the category of random scans now known at all levels. Obviously, unless one operates in a targeted manner on the server source
code, this is not a problem that can be so easily resolved. The basic components of Q’s architecture are the following: • Qd: Actually this is the daemon that gets activated following the compromise. It thus constitutes the true server portion of the backdoor. It is contacted by the client (the attacker’s module) in order to receive and execute instructions. • Qs: This is used to handle the covert channel-based transactions towards the server. The message elements handled by Qs deal essentially with the execution of privileged commands, encrypted single remote shell processes, and more or less advanced port redirection functions. • Q: Also known as Q client, Q is used to handle the encrypted or nonencrypted workstation of the malicious hacker and daemons that are listening at a certain port. The operation has to have been previously started with “Qs”. • Ql: This is a listener that gets activated by Qs and keeps listening for instructions given by Q. • transd: An element used as a tunneling service for sessions mainly in plaintext (telnet, for example) in encrypted mode. The interesting thing about this daemon is its traffic redirection feature. This provides, basically, the possibility to link up a long chain of stepping stones. Considering that, as we have said, Q has been undergoing significant development lately, the low level analyses of this and other similar ‘zombies’ have highlighted a certain similarity between the malicious tools in question and tools such as Trinoo and Tfn2k. In particular, the stealth capacity of this last one seems to have been improved, no longer being limited to the ‘simple’ use of ICMP but also being able to use messages based on TCP and UDP. Taken together, the characteristics indicated above contribute to making Q and its kin a new generation of tools that places the accent on two fundamental problems:
17
issue.qxd
10/04/2003
16:23
Page 18
covert channels • The use of covert channels as anti-detection tools. Obviously we are looking at the problem from a pure hacking prospective. The attackers, using Qlike tools, can handle the concatenated transactions (for example, multiple stepping stones) in an extremely granular fashion. • The use of cryptography united with traffic redirection. This way it will become increasingly complex to make an exact determination of the payload of the packets and their flow through networks of compromised machines.
Covert Channels: the defenses A “fine touch” done so well that normal filtering, even if done at the stateful inspection level (thus lower than simple header control) has never been able to guarantee 100% protection. For this reason, controls using application proxy gateway firewalls, or Network Address
Translation (NAT) are recommended. In the first scenario, it has not been possible to make a direct connection from the LAN to the outside without the intervention of the AP control engine, any attempt at encapsulation will be much more difficult. With NAT, on the other hand, since the information obviously gets ‘rewritten’ by the firewall before contact is made with the outside, even the part hidden in the fields may turn out to be ineffective.
Conclusions For reasons of space we did not go very deeply into the technique known as bouncing used by some tools that handle this particular type of ‘steganography’. If it is used, bouncing could cause more serious problems that would make detection more complicated. Nevertheless, the filtering techniques described above should at least provide some preventive medicine. That aside, it is nevertheless
recommended that you do an integrity check on the machines at risk (with tools like tripwire, for instance) in order at least to prevent the presence of components capable of exploiting this phenomenon, which would already be a little step ahead. The need for a concrete correlation among the various points in the acquisition log is still a priority. The only way to handle such complex attack transactions is to unite IDS operations at the Integrity check level to those of log correlation. Only this way can we dampen the escalation in distribution and metastasis that was announced in the underground about three years ago. Covert channels, hence, remain one of the security engineer’s archest enemies, especially if used in conjunction with dynamic components such as LKM and advanced backdoors like Q. Perhaps this is the reason why the topic is often glossed over by security vendors.
MANAGING NETWORK SECURITY
Documenting Security Fred Cohen Series Introduction Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection programme success depends more on prudent management decisions than on the selection of technical safeguards. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.
Boring! OK so security documentation is not the most exciting subject but on the other hand, it is necessary and often critical to an effective protection programme over time. It is required by standards, prudence, and in some cases legal mandate. And of course without adequate and usable documentation, there is a high tendency toward protection failures.
18
As a manager, you naturally have the responsibility for documentation along with everything else, perhaps more so than anyone else. When your documentation is put to the test it is generally too late to do anything about it, and of course until then, it may seem like more of a waste of time. To understand just how important documentation is, I should really
explain my consulting rates. I get paid by the hour for consulting. I charge a lot and I'm worth it, and one of the reasons I am worth it is because I seem to end up working on lots of networks that have absolutely no documentation. I can assure you that it is not easy to walk into a company where the top network engineers have been dismissed and you have the task of ensuring the organization is not vulnerable to them or others who might choose this weak time for an attack.
A case scenario I was called into a local company for an 'emergency'. No details about the emergency were provided ahead of time but I was asked if I knew a lot about networking. I indicated that I could probably handle anything they needed for the
10/04/2003
16:23
Page 16
grid computing really taking place on the resources I think it is being executed on? •Can I guarantee that resources will be available when I need them? •What recovery procedures are in place to cope with failures while my computation is taking place? In the case of external grids not managed by a single third party, there is also whole issue of identity management and security policy mapping to contend with. The computers within the grid may be under the jurisdiction of different policies with varying levels of access control, so that some users might be barred from some of the resources, leading to varying experiences of the grid. The greatest challenge in making a loose multi-domain grid work lies in the middleware software that co-ordinates all the processes, and a major part of this is the mapping of identities and reconciliation of policies. The key requirement is identity mapping, so that the grid can support single sign-on while maintaining local IDs and legacy access control mechanisms on the hosts within the grid. This means that users will need a separate local account on any host machine they want to use, which is not ideal. It also requires a degree of mutual trust between the user’s
local access control and the grid’s gateway server. It might prove easier to administer a system based on specification of trust relations between sites, rather than requiring direct mapping of IDs. Thought also needs to be given to the type of applications for which external grids will be used. The principle distinction is between jobs that need to be executed almost immediately, and those that can be, and indeed may need to be, scheduled in advance. The latter would apply for jobs involving large amounts of data and bandwidth, particularly where there is real time processing involved, which would fail if the required resources were not available exactly when required. Obvious requirements include an assurance that reservations will be honoured accurately, and this requires a sophisticated booking system allied to access control to ensure that users have permission to use the specified resources at a given time. For both categories of application there are some general requirements, which can be summarised under six headings: 1 A set of suitable target hosts for the work must be identified. 2 The grid scheduler must ensure that the user is allowed access to the specified hosts and will be granted a
Covert Channels: Covering ‘Malicious’ Traffic Dario Forte There are tools that can hide the real intentions of an attacker. Here we discuss attacks and countermeasures for a problem that is by no means new.
Covert channels: general background Some time ago, during work to update the new Common Intrusion Detection Framework (CIDF) some members of the technical community mentioned the fact that so far no solution has been found to the problem of covert channels.
16
In practice, actually, covert channels do not exist. Or rather, they are not part of any specific protocol, but exploit existing protocols to transfer otherwise forbidden information and/or programs to other users. The suite of protocols that naturally gets exploited in this case is TCP/IP.
sufficient level of resource on them. 3 Mutual authentication needs to take place between the user and grid gateway. 4 The grid gateway must map the global grid ID to local IDs on each host, and then submit the resource request for that host so that the work appears to be performed on behalf of a local user (remember the host may also serve as an internal machine to a particular participating organization). 5 The executing jobs may need to be given permission to read and write remote files on behalf of the user. 6 The overall grid scheduler will need information about availability and local accounts on the member machines of the grid, and so must be capable of being trusted not to leak this, providing only necessary details to grid users. Despite all the security hurdles, use of grids is growing fast within the biosciences community, and others will be watching progress closely. A lot mush to done though before computing cycles can be traded like electricity on a spot market, given that the ultimate ambition is to make computing power just another utility available from a national grid.
With its current conformation, this suite can be used to bypass controls ranging from simple packet filtering and non granularly configured network sniffers, all the way to password perimeter controls. The activity dubbed “Covert Channel Encapsulation” via TCP/IP is also known in the underground as TCP/IP Steganography and involves inserting into certain packets portions of semi encrypted information that get reassembled by the legitimate receiver upon reaching their destination. Attackers usually use opportunely modified TCP/IP packet headers as covert channels (normally with the help of encoding techniques) or, in other cases, using ICMP, routing
issue.qxd
10/04/2003
16:23
Page 17
covert channel control information and UDP datagrams. According to the thinking in certain underground circles, this last possibility would not cause the same effects because of the least privilege approach exercised by a number of firewall administrators.
Covert channels: how encapsulation is done A properly executed covert channel generally does not exploit the various optional fields left ‘free’ in a packet, since a firewall administrator could easily set up a filter for the purpose. Instead the tools most commonly used by malicious hackers handle this operation in two steps: • Identification of the type of field to affect. • Encoding of the field contents. The underground identifies the following as being appropriate for the operations in question: the IP packet identification field; the TCP initial sequence number field; and the TCP acknowledged sequence number field. In practical terms, the exploitation consists of encoding an ASCII value of the range 0-255 into the above fields. This way the engine thinks it is reading an address or, in any case, a perfectly kosher piece of information and lets it by the filter. Of course the encoded information is linked to the real address, which may also contain the forced attribution of a port through which the communication is intended to be passed. Depending on the type of field used, an almost certain result should be attainable. On the basis of experiments it seems that the use of the sequence number fields is the most fruitful in this regard, partially because the tools available can handle the encoding much more efficiently.
Covert channels: the tools used Everything depends on the type of protocol used. Nevertheless the payload of the covert channels is usually encapsulated in rootkits of varying power. I
personally have had direct experiences with Trojans that used ICMP as covert channels. In any case, practical experiments in covert channels have successfully used the techniques described above with the channelling going on at the kernel level (LKM, to be precise). The loadable kernel modules were then dynamically loaded and performed the operation in a completely transparent manner: a ‘fine touch’.
“Q” when a letter may represent danger Recently, attention has been raised regarding the combination of more or less esoteric Trojan horses and the covert channels themselves. On this premise, the technical community has lately been oriented towards the analysis of certain backdoor tools used by malicious hackers to ensure that compromised machines will remain so for the long term. Q is one of those tools. • To tell the truth, Q has been “on the crest of the wave” for a number of years, along the lines of products such as LOKI and its ilk, with which it shares general operational characteristics. It is obviously UNIX-based and has the prerogative of using Stealth techniques to make it even less recognizable. The latest versions of this attack tool can be compiled even on Windows 32 platforms, which opens up the world of covert channeling to platforms until recently held in relative disdain by attackers. • Q consists of a client/server architecture. This principal characteristic may, indirectly, constitute a limit to its spread, whenever attempts are made to contact a server module following a scan from a non-original client (for example belonging to an occasional attacker who is doing portscanning). This is an operation that gets carried out rather habitually and falls into the category of random scans now known at all levels. Obviously, unless one operates in a targeted manner on the server source
code, this is not a problem that can be so easily resolved. The basic components of Q’s architecture are the following: • Qd: Actually this is the daemon that gets activated following the compromise. It thus constitutes the true server portion of the backdoor. It is contacted by the client (the attacker’s module) in order to receive and execute instructions. • Qs: This is used to handle the covert channel-based transactions towards the server. The message elements handled by Qs deal essentially with the execution of privileged commands, encrypted single remote shell processes, and more or less advanced port redirection functions. • Q: Also known as Q client, Q is used to handle the encrypted or nonencrypted workstation of the malicious hacker and daemons that are listening at a certain port. The operation has to have been previously started with “Qs”. • Ql: This is a listener that gets activated by Qs and keeps listening for instructions given by Q. • transd: An element used as a tunneling service for sessions mainly in plaintext (telnet, for example) in encrypted mode. The interesting thing about this daemon is its traffic redirection feature. This provides, basically, the possibility to link up a long chain of stepping stones. Considering that, as we have said, Q has been undergoing significant development lately, the low level analyses of this and other similar ‘zombies’ have highlighted a certain similarity between the malicious tools in question and tools such as Trinoo and Tfn2k. In particular, the stealth capacity of this last one seems to have been improved, no longer being limited to the ‘simple’ use of ICMP but also being able to use messages based on TCP and UDP. Taken together, the characteristics indicated above contribute to making Q and its kin a new generation of tools that places the accent on two fundamental problems:
17
issue.qxd
10/04/2003
16:23
Page 18
covert channels • The use of covert channels as anti-detection tools. Obviously we are looking at the problem from a pure hacking prospective. The attackers, using Qlike tools, can handle the concatenated transactions (for example, multiple stepping stones) in an extremely granular fashion. • The use of cryptography united with traffic redirection. This way it will become increasingly complex to make an exact determination of the payload of the packets and their flow through networks of compromised machines.
Covert Channels: the defenses A “fine touch” done so well that normal filtering, even if done at the stateful inspection level (thus lower than simple header control) has never been able to guarantee 100% protection. For this reason, controls using application proxy gateway firewalls, or Network Address
Translation (NAT) are recommended. In the first scenario, it has not been possible to make a direct connection from the LAN to the outside without the intervention of the AP control engine, any attempt at encapsulation will be much more difficult. With NAT, on the other hand, since the information obviously gets ‘rewritten’ by the firewall before contact is made with the outside, even the part hidden in the fields may turn out to be ineffective.
Conclusions For reasons of space we did not go very deeply into the technique known as bouncing used by some tools that handle this particular type of ‘steganography’. If it is used, bouncing could cause more serious problems that would make detection more complicated. Nevertheless, the filtering techniques described above should at least provide some preventive medicine. That aside, it is nevertheless
recommended that you do an integrity check on the machines at risk (with tools like tripwire, for instance) in order at least to prevent the presence of components capable of exploiting this phenomenon, which would already be a little step ahead. The need for a concrete correlation among the various points in the acquisition log is still a priority. The only way to handle such complex attack transactions is to unite IDS operations at the Integrity check level to those of log correlation. Only this way can we dampen the escalation in distribution and metastasis that was announced in the underground about three years ago. Covert channels, hence, remain one of the security engineer’s archest enemies, especially if used in conjunction with dynamic components such as LKM and advanced backdoors like Q. Perhaps this is the reason why the topic is often glossed over by security vendors.
MANAGING NETWORK SECURITY
Documenting Security Fred Cohen Series Introduction Networks dominate today's computing landscape and commercial technical protection is lagging behind attack technology. As a result, protection programme success depends more on prudent management decisions than on the selection of technical safeguards. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.
Boring! OK so security documentation is not the most exciting subject but on the other hand, it is necessary and often critical to an effective protection programme over time. It is required by standards, prudence, and in some cases legal mandate. And of course without adequate and usable documentation, there is a high tendency toward protection failures.
18
As a manager, you naturally have the responsibility for documentation along with everything else, perhaps more so than anyone else. When your documentation is put to the test it is generally too late to do anything about it, and of course until then, it may seem like more of a waste of time. To understand just how important documentation is, I should really
explain my consulting rates. I get paid by the hour for consulting. I charge a lot and I'm worth it, and one of the reasons I am worth it is because I seem to end up working on lots of networks that have absolutely no documentation. I can assure you that it is not easy to walk into a company where the top network engineers have been dismissed and you have the task of ensuring the organization is not vulnerable to them or others who might choose this weak time for an attack.
A case scenario I was called into a local company for an 'emergency'. No details about the emergency were provided ahead of time but I was asked if I knew a lot about networking. I indicated that I could probably handle anything they needed for the