Shellcode与加密流量之间的那些事儿

前言

在这篇文章中，我们将简单介绍如何在通过TCP通信的位置无关代码（PIC）中实现数据加密。

我将以Linux下的同步Shell作为演示样例，因此我建议大家在阅读本文之前先阅读下面这几篇关于Shellcode的细节文章。

Shellcode: Linuxx86同步Shell汇编

Shellcode:Linux AMD64同步Shell汇编

Shellcode:Linux ARM同步Shell汇编

可能还需要查看关于加密算法的内容：Shellcode：ARM汇编中的加密算法介绍。

协议和代码库

当我们在思考加密协议时，第一个想到的很可能是安全传输层协议（TLS），因为它是针对Web安全的工业级标准。有的人可能还会想到SSH或IPSec等等，但是考虑到这些协议所采用的底层算法，它们其实都不适用于资源受限环境。而类似SHA-2和分组密码（例如Blowfish）这样加密哈希函数也并不是为类似RFID芯片这样的占用资源较少的电子设备设计的。

在2018年4月份，NIST曾为物联网行业的轻量级加密算法推行过一个标准化进程，整个过程需要好几年的时间才可以完成，但毫无疑问的是，整个行业并不会一直等待，因为这样会导致不安全的产品暴露在互联网中。某些密码学家选择采取主动的方式，通过自己的努力将他们设计的协议采用到这些低资源消耗的设备上，其中有两个典型的算法就是BLINKER和STROBE，而相应的适用于资源受限环境的代码库有LibHydrogen和MonoCypher。

分组密码

分组密码有很多种，但AES 128可能是目前最适合对在线流量进行加密的算法了，下面给出的是我们对不同种类分组密码的测试结果：

虽然这些加密算法都非常优秀，但是他们仍需要类似计数器（CTR）和基于认证的加密模块，其中最适合消息认证码（MAC）的加密算法就是LightMAC了，因为它在实现加密的过程中使用的是相同的分组密码。

流密码

另外两种针对认证加密的热门算法（AES-GCM的替换）就是ChaCha20和Poly1305了，但是ChaCha20采用的是200字节，而Poly1305为330字节。虽然跟HMAC-SHA2相比，Poly1305已经压缩得非常小了，但仍然占用资源过多。

置换函数

如果你花了很多时间去测试各种加密算法的话，你最终会发现在构造流密码、分组密码、加密认证模型、加密哈希函数和随机数生成器时，你需要的仅仅只是一个置换函数。下面这个表格给出的是我们针对三种函数的测试结果：

这里我们选择使用Gimli，因为它占用资源最少，并且可以用来构造针对通信流量的加密算法。

异或密码

接下来，我们实现一个针对数据流的简单异或操作（Just For Fun！）。下面的截图中显示的是一台Windows虚拟机发送给Linux虚拟机的部分命令，其中Linux平台运行的Shellcode是没有采用任何加密的。

捕捉到两台主机间的通信数据之后，我们可以看到如下所示的TCP流数据：

给Shellcode x86汇编代码中添加部分命令后，我们就可以进行8位异或运算了：

通过在新的会话中执行相同的命令，通信数据将无法直接可读，我这里使用了haxdump来查看发送的命令以及接收到的结果：

当然了，长度为8位的密钥是无法有效阻止攻击者恢复出通信明文的，下图给出的是Cyberchef爆破密钥的过程：

Speck和LightMAC

一开始，我使用的是下面这段代码来对数据包的加密进行验证，它使用了Encrypt-then-MAC (EtM)，而且这种方法比其他的方法要更安全，比如说MAC-then-Encrypt (MtE) 或Encrypt-and-MAC(E&M)：

需要注意的是，这里还得用到一个协议，接收方在对数据有效性进行验证之前需要知道发送方到底发送了多少数据过来，因此加密长度需要首先发送，接下来才是加密数据。但是请等一下，这里明明应该是Shellcode，为什么现在搞得那么复杂呢？试一下RC4？不，请大家往下看！

Gimli

为了使用Gimli来代替RC4，我编写了下面这段代码，这里的置换函数本质上就是Gimli：

在Linux Shell中使用这段代码之前，我们需要声明两个单独的加密上下文来处理输入、输出和128位的静态密钥：

在进入主输出循环之前，我们还需要对每一个上下文初始化文件读取和写入描述符，这样可以减少代码的行数：

总结

对shellcode进行恢复之后，将能够得到明文数据，因为我在这里加密所采用的是一个静态密钥，为了防止这种情况出现，大家可以尝试使用类似Diffie-Hellman这样的密钥交换协议来实现，这个就留给大家自己动手尝试啦！

* 参考来源：securelist，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM