A recent experience with intermittent network failure started me thinking about how I could read data from a server without the NOC knowing about it. I could do this with a virus that replaces "netstat" and "syslog" and "ps" so that it never shows itself running. That's just too simple and blunt, a child could do that. No, what I wanted to do is create a method that goes undetected because it looks like a common attack that is easily thwarted and often ignored.
First, there is the ICMP ping relay attack. One way to communicate with a 3rd party covertly is to send ping packets to a server and spoof the source IP so that they are bounced to the 3rd party by the server. This way you never directly communicate with the 3rd party.
Secondly, you need to take advantage of subliminal channels [1] in network protocols. This is the super-secret spy stuff that makes this idea a reality. By utilizing a subliminal channel, I am able to send secret messages to the 3rd party, and have the message go undetected.
So now I have established a covert method of communication that can be exploited to communicate securely using some novel security methods. You can expect to make use of about 64 [2] bytes of data in the subliminal channel. You could get away with any size of data, but very large payloads would be conspicuous, so we need to limit the size of our covert channel.
The next step requires compromising the host computer. We want to subvert the NIC driver so that it handles the special ICMP packets that we are relaying through the server. The NIC driver is a special case because we can write relatively innocuous code in there that will run in kernel mode and gain access to the internal memory image. Network cards all take advantage of DMA (direct memory access), which gives them privileged access to the RAM state of the OS. A specially crafted ICMP packet would trigger our covert driver code and begin the process of relaying the RAM image of the compromised computer to a 3rd party.
For our sake, the ICMP packet is 92 bytes total. On a 1.5 Mbps channel, we can push 655360 bytes of data per second, or 7123 packets per second max. That gives us 455872 bytes of covert data per second. To image a full 1GB of RAM we have to transmit packets for 2355 seconds. Since we have to push packets to the server first, our throughput is halved, so we need 4710 seconds, or 1 hour and 18 minutes. On a 10 Mbps network, you can do the imaging in about 11 minutes. If you compromised the LAN and it was 1 Gbps, then you could image the server in 6.7 seconds.
By imaging the RAM space of the server, you could quickly gain access to passwords that have been decrypted or kept in memory. If you compromised a secure server, then you could gain access to decrypted intelligence. The vulnerability is nearly limitless because in the RAM space of the hardware, the data must be decrypted so that it is usable by the human user.
To make the exploit "real time" the imaging process would have to run in at least 1 second. To do that, a 10 Gbps network connection would be required for every 1 GB of RAM. Another approach to "real time" imaging is to use selective searching of the RAM image. The compromised NIC driver could actively search the RAM space during idle time to look for keywords that identify passwords, key intelligence information, or other opportunistic information. Once the key address spaces are known, quick imaging can ensue. Most kernel memory management do not move around data often, so tracking the location of the key data become relatively trivial.
Counterfeiting the network drivers would be trivial. The network driver engineer would only have to insert their code in the driver code and release it to the bundled disc for deployment. Once in the code base, it would be in the download as well, and would quickly disseminate to the production world. Since there would not be any way to detect such a compromise, it could easily go undetected until a thorough review of the network driver source was performed.
An open-source network driver would likely not be more secure. It was my experience that the open-source community respects the ownership of driver source and often leaves maintenance and review in the hands of the author. Hardware drivers are implicitly complex and hard to debug, and so any non-expert device driver engineer would have nearly zero chance of detecting any anomalous code.
[1] http://www.springerlink.com/content/qu26013256884354
[2] http://www.iv2-technologies.com/CovertChannels.pdf, pg 7.
Additional reading
http://archives.ece.iastate.edu/archive/00000154/01/mcpthesis.pdf
http://www.gray-world.net/cn/papers/acs2003-hiccups.pdf
http://www.nersc.gov/~scottc/papers/ICMP_Backdoor_Detection.html
http://www.s0ftpj.org/docs/covert_shells.htm
http://www.sans.org/resources/idfaq/traffic.php
http://en.wikipedia.org/wiki/Ping
First, there is the ICMP ping relay attack. One way to communicate with a 3rd party covertly is to send ping packets to a server and spoof the source IP so that they are bounced to the 3rd party by the server. This way you never directly communicate with the 3rd party.
Secondly, you need to take advantage of subliminal channels [1] in network protocols. This is the super-secret spy stuff that makes this idea a reality. By utilizing a subliminal channel, I am able to send secret messages to the 3rd party, and have the message go undetected.
So now I have established a covert method of communication that can be exploited to communicate securely using some novel security methods. You can expect to make use of about 64 [2] bytes of data in the subliminal channel. You could get away with any size of data, but very large payloads would be conspicuous, so we need to limit the size of our covert channel.
The next step requires compromising the host computer. We want to subvert the NIC driver so that it handles the special ICMP packets that we are relaying through the server. The NIC driver is a special case because we can write relatively innocuous code in there that will run in kernel mode and gain access to the internal memory image. Network cards all take advantage of DMA (direct memory access), which gives them privileged access to the RAM state of the OS. A specially crafted ICMP packet would trigger our covert driver code and begin the process of relaying the RAM image of the compromised computer to a 3rd party.
For our sake, the ICMP packet is 92 bytes total. On a 1.5 Mbps channel, we can push 655360 bytes of data per second, or 7123 packets per second max. That gives us 455872 bytes of covert data per second. To image a full 1GB of RAM we have to transmit packets for 2355 seconds. Since we have to push packets to the server first, our throughput is halved, so we need 4710 seconds, or 1 hour and 18 minutes. On a 10 Mbps network, you can do the imaging in about 11 minutes. If you compromised the LAN and it was 1 Gbps, then you could image the server in 6.7 seconds.
By imaging the RAM space of the server, you could quickly gain access to passwords that have been decrypted or kept in memory. If you compromised a secure server, then you could gain access to decrypted intelligence. The vulnerability is nearly limitless because in the RAM space of the hardware, the data must be decrypted so that it is usable by the human user.
To make the exploit "real time" the imaging process would have to run in at least 1 second. To do that, a 10 Gbps network connection would be required for every 1 GB of RAM. Another approach to "real time" imaging is to use selective searching of the RAM image. The compromised NIC driver could actively search the RAM space during idle time to look for keywords that identify passwords, key intelligence information, or other opportunistic information. Once the key address spaces are known, quick imaging can ensue. Most kernel memory management do not move around data often, so tracking the location of the key data become relatively trivial.
Counterfeiting the network drivers would be trivial. The network driver engineer would only have to insert their code in the driver code and release it to the bundled disc for deployment. Once in the code base, it would be in the download as well, and would quickly disseminate to the production world. Since there would not be any way to detect such a compromise, it could easily go undetected until a thorough review of the network driver source was performed.
An open-source network driver would likely not be more secure. It was my experience that the open-source community respects the ownership of driver source and often leaves maintenance and review in the hands of the author. Hardware drivers are implicitly complex and hard to debug, and so any non-expert device driver engineer would have nearly zero chance of detecting any anomalous code.
[1] http://www.springerlink.com/content/qu26013256884354
[2] http://www.iv2-technologies.com/CovertChannels.pdf, pg 7.
Additional reading
http://archives.ece.iastate.edu/archive/00000154/01/mcpthesis.pdf
http://www.gray-world.net/cn/papers/acs2003-hiccups.pdf
http://www.nersc.gov/~scottc/papers/ICMP_Backdoor_Detection.html
http://www.s0ftpj.org/docs/covert_shells.htm
http://www.sans.org/resources/idfaq/traffic.php
http://en.wikipedia.org/wiki/Ping