Apache源码改造之SSL中间人攻击

     Apache是世界排名第一的WEB服务器，它的高效、灵活、程序结构的高度模块化在我的博客中已经讲了很多，这篇文章主要来讲讲通过对Apache源码的小小改动来实现SSL中间人攻击并给出防范策略。
      首先先来看看什么是SSL。
      SSL协议是Netscape公司提出的一种安全通信协议，该协议采用公开密钥技术，能使客户端与服务器之间的通信不被攻击者窃听，保证了通讯的两个应用程序间数据的保密性、可靠性和完整性。SSL协议要求建立在可靠的传输层协议（TCP）与应用层协议之间，高层的应用层协议能透明地建立于SSL协议之上。 简单地讲，通过应用程序发出的明文数据都可以通过OPENSSL加密后传送到服务器，再由服务器解密后访问资源文件。
      但是，任何事物都不是完美，SSL也一样，它自身也存在着很多漏洞。首先，SSL都是用HASH函数来进行签名，一旦找到两个文件可以产生相同的压缩值，就可以伪造签名，给网络安全领域带来巨大隐患。如王小云教授成功破解MD5，证明了它在通信安全领域的不安全性。其次，SSL协议并不是默认地要求进行客户端认证，这样会存在客户端假冒的安全漏洞，使中间人攻击有机可乘，有悖于安全策略。再次，当检测出证书与网站域名不符时，没有强制的断开连接，对于缺乏安全常识的上网用户仍处于易受攻击的危险网络。
有了前面知识的铺垫，我们来看看中间人攻击。中间人攻击是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，利用这台计算机模拟通信双方的会话，使中间人能够与原始计算机建立活动连接并允许其读取或篡改传递的信息。
      中间人攻击有很多种，如防火墙端口重定向、DNS欺骗、ARP欺骗、代理欺骗等，它们通过各种手段使原本发送到目标主机的数据流重新定向到中间人主机，实施对数据进行读取或篡改，最后再将截取到的请求发送到目标主机。两个原始计算机用户却认为他们是在互相通信，因而这种攻击方式不容易被发现。本文以现在流行的代理欺骗为例对中间人攻击原理进行分析。
      代理服务器原本是一种重要的安全功能，它的工作主要在开放系统互联(OSI)模型的对话层，从而起到防火墙的作用。它截获/受理用户服务的请求，代替用户访问目标主机，接受目标主机的响应，并传送给用户。而代理服务器的这种工作模式，正是典型的“中间人攻击”模型。代理服务器在其中充当了一个“中间人”的角色，通讯双方计算机的数据都要通过它。这对于用户来讲是毁灭性的，它不仅可以通过Http传输协议获取你的明文密码或其他敏感信息，而且甚至可以通过欺骗的手段来截获、解密经SSL加密过的数据流信息。
      代理欺骗就是应用各种欺骗手段如利用病毒、恶意代码修改系统文件等，使源主机用户在不知情的情况下通过代理访问目标服务器，从而达到获取个人信息的目的。
      前面说了Apache作为世界使用排名第一的Web服务器软件，可以运行在几乎所有广泛使用的计算机平台上。它通过灵活的模块配置使各个拓展功能与Apache核心实现松耦合关系，其中就包括代理服务器模块（mod_proxy）和安全Socket层的SSL模块（mod_ssl）。
      我的思路是：为了截获Apache代理过程中的敏感数据，就应该将这些数据包从Apache的数据结构中提取出来并显示在后台。过滤器是Apache2.0开始引入的新概念，它使我们能够更加灵活地控制输入输出的内容。在Apache中生成或从网络中获得的数据很少会一成不变地写入网络或读入Apache核心，当数据从网络到核心或从核心到网络的过程中，如果数据需要修改，那么可以通过过滤器来实现。
      Apache中的过滤器可分为两大类，输出过滤器和输入过滤器。输出过滤器是将核心生成的内容封装并输出到网络中。而输入过滤器通常用于对输入的请求进行更改。包括对使用Openssl加密过的输入数据流就要使用SSL过滤器对数据内容进行解密，这也正是Apache作为中间人需要利用的功能。
      只需将Ssl_in过滤器处理过的解密数据的存储结构以某种形式输出到文本文件中，并对文本中的内容进行裁剪与分析就能得到中间人想要得到的敏感数据，如加过密的密码、交易细节相关信息等。这就需要修改Apache中的Core_filters.c文件，在整行读取模式下（AP_MODE_GETLINE）修改代码如下：
/*-------------------------------中间人攻击-------------------------------------*/
    apr_off_t readbytes111 = 0;
    while (!APR_BRIGADE_EMPTY(ctx->b)) {
        const char *pos;
        apr_bucket *e;
        e = APR_BRIGADE_FIRST(ctx->b);
        rv = apr_bucket_read(e, &str, &len, block);
  ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,str, "MITM");
   if (rv != APR_SUCCESS) {
            break;
        }
        pos = memchr(str, APR_ASCII_LF, len);
        if (pos != NULL) {
            apr_bucket_split(e, pos - str + 1);
            APR_BUCKET_REMOVE(e);
            APR_BRIGADE_INSERT_TAIL(b, e);
            rv = APR_SUCCESS;
   break;
        }
        APR_BUCKET_REMOVE(e);
        APR_BRIGADE_INSERT_TAIL(b, e);
        readbytes111 += len;
        if (readbytes111 >= HUGE_STRING_LEN) {
   rv = APR_SUCCESS;
            break;
        }
    }
  /*-------------------------------中间人攻击-------------------------------------*/
      将上述代码进行编译、安装。其功能是将所有处理过的输入流在不影响正常数据流向的情况下以日志的形式输出到文件。这样，通过日志文件就可以获取经Openssl解密过的双方通信的内容。
     接下来我们来看看整个攻击的网络结构。SSL中间人可分为Apache代理服务器和中间人Stunnel两部分。
     Apache代理服务器：通过欺骗将用户发出的正常请求进行拦截，让用户以为该Apache服务器就是要访问的目标服务器并与之进行Openssl三次握手，在之后的通信过程中，用户所有的敏感数据都是在客户端浏览器进行加密，在Apache代理端进行解密的。
     中间人Stunnel:它是针对本身无法进行TLS或SSL通信的客户端及服务器而设计的一种小型开源软件，Stunnel可提供安全的加密连接。它的作用是接受Apache代理解密后的数据并将这些数据再次加密，冒充原客户端去与目标服务器进行Openssl正常通信，达到欺骗目标服务器的作用。
      在这里需要补充的是，之所以能够产生SSL中间人攻击，是因为用户在进行网上操作时往往忽略了验证服务器端证书的过程。而X.509服务器端证书的伪造使SSL中间人攻击更具威胁性，这些也都是该攻击模型必须具备的前提。
      具体攻击实现：通过对上述攻击模型的分析，可归纳其具体实现为：
      欺骗终端用户：中间人通过病毒、人工修改等手段修改windows系统中的Hosts文件，该文件主要用于对特定网站/IP地址进行重定向。也就是说，当用户访问某一特定带有Openssl协议加密保护的网站时，该文件可以自动将该请求重定向到中间人已经精心布置好的代理服务器，从而达到欺骗的目的。 
      配置Apache代理服务器： 将Apache配置成反向代理，让其成为Stunnel客户端程序的代理服务器。配置如下：
ProxyRequests off
ProxyPass / http://Stunnel的IP地址：端口号
ProxyPassReverse / http://Stunnel的IP地址：端口号
      配置中间人Stunnel:Stunnel软件分为客户端程序和服务器端程序，两者间可以进行Openssl加密通讯。由于SSL为各个软件提供统一的应用标准（握手协议和记录协议），经测试过的Stunnel客户端与Apache有很好的兼容性。作为接收Apache代理服务数据的加密软件，配置如下：
[http2ssl]
accept = 监听端口号
connect = 需要连接的目标服务器的IP地址：端口号
      通过以上对基于Apache代理欺骗的SSL中间人攻击的分析，可总结以下防范策略：
1、从个人主机安全防护的角度，防范恶意插件、病毒，安装实时监控的杀毒软件保护系统，防止中间人程序对计算机系统文件进行篡改。
2、对于代理服务器，如无必要尽量不要使用。如果一定要用也要确定此服务器绝对可信，否则尽量不要再使用代理服务器时进行保密操作。
3、对于服务器证书的认证，用户除了要仔细查看证书是否有可疑外，如果之前与服务器通信时安装过证书或未要求验证证书，之后再通信仍要求验证证书，那么此证书很有可能是假的或者你之前安装的证书可能是假的，用户可以用其他可信方式向服务器求证是否更换了证书。