分析与思考：电商网站中木马

自腾讯与京东建立战略合作关系以来，作者首选京东进行网上购物。有一天，当我在家里访问京东主页时，我突然惊讶地发现浏览器突然跳到第三方网站，然后回到京东。我心中的第一反应是中木马。有这样的事，一定要把木马大卸八块。原因排查首先是在重现的情况下抓包，JavaScript确实返回了JavaScript，让浏览器跳转到yiqifa.com。下图为应用层的抓包。服务器返回的代码导致跳转，基本上可以排除本地木马，推测是网络或服务器的问题。根据作者的经验，这种情况很可能是链路上的流量劫持攻击。当然，也不能排除京东服务器被黑客攻击。继续排查。应用层不再工作，我们要用Wireshark抓取网络层的包。从Wireshark的结果可以看出，两个JD.COM的HTTP响应出现在网络上。第一个先到，所以JavaScript代码在浏览器执行中转移到yiqifa.com；由于迟到，第二个HTTP响应被系统忽略了(Wireshark识别为outt)-of-order）。JD.COM的两个HTTP响应包一定是真的，一个是假的。真相即将揭晓。再来看看HTTP响应的两个IP头。第一包TTL值为252，第二包TTL值为56，TCP三次握手时JD.COM服务器TTL值为56。因此，可以判断先到的包是伪造的，包真的很晚，被系统忽略了。到目前为止，确认是链路上的劫持。继续分析伪造的数据包进行攻击。伪造包的TTL值为252，即其原始TTL值为255（默认TTL值为255，一般不修改），表明攻击者设备离我有3条路由；京东网站正常HTTP响应TTL值为56，路由8条。物理上的假设备离我很近，所以伪造的HTTP响应会先到——更有趣的是，在实际监控中，作者发现伪造包太晚，导致劫持失败。推测是旁路设备对所有数据包进行调查，发现京东主页上的HTTP请求立即返回定制的HTTP响应。一般攻击示意图如下。当时，作者推测攻击者不应该只针对一个网站，所以他访问了易迅、淘宝、天猫等电子商务网站，发现易迅也受到了同样的攻击。流量劫持的目的似乎是将电子商务网站的流量导向返利联盟，并通过返利联盟获得当前用户交易金额的返利。基本确认运营商有问题，但无法确认运营商是官方故意还是被黑客攻击或者内部人士偷偷搞的。攻击源定位看当时的路由结果:如果按原TTL值为255计算，HTTP包到达本机后为252，计算出3(255-252)路由后，问题在第四路由附近，即119.145.220.86(属于深圳电信)。当然，虽然基本上可以确认这是第四个路由附近的问题（作者连续几天抓住包，伪造的HTTP响应包TTL值为252），但不排除设备故意构建初始TTL值（如设置为254）来增加追踪难度，为了严格的学术态度，避免被攻击者混淆，所以证据应该是真实的。定位相对简单，由于攻击设备是旁路侦听数据包，可以推测它是基于包而不是状态，我们构建侦听数据包（即直接访问京东主页HTTP请求TCP包，不需要三次握手）多次发送，TTL值从1开始增加，准确地将数据包传输到每条路径，直到伪造响应——没有问题的位置没有响应，伪造反应的第一个位置是有问题的位置。此时需要一个基于Python的Scapy或Windows下的XCAP的数据包结构工具。此时，需要一个基于Python的Scapy或Windows下的XCAP的数据包结构工具。所以一路上，当TTL值等于4时，伪造的响应包出现——确认第四跳路由有问题，119.145.55.14回复Time-to-ICMP包liveexceeded。凭借充分的证据，通过腾讯安全应急响应中心向深圳电信整理了一份图文并茂的文件。一天后，我得到了运营商的回复：“经核实，深圳本地没有推送，网上查询木马或病毒会导致这种现象，非电信网络问题，请在测试前杀毒，谢谢”。然而，从那天晚上开始，我在ADSL环境测试中没有发现这种流量劫持。攻防之路的链路劫持对企业和用户来说都是非常麻烦的，影响用户体验，泄露敏感信息，分区域，检测和防御相对困难。 链路劫持已经被一些人利用了。比如最近业内发现百度联盟广告脚本植入恶意JavaScript到DDOS攻击GitHub。腾讯历史上也遇到过很多链路劫持攻击，目的性很强，大部分都是插广告(少数是钓鱼和挂马)，攻击手法多种多样，包括运营商区域DNS劫持和链路劫持，运营商区域DNSServer被缓存投毒攻击(CVE-2007-2926，非常经典）、在路由软件中植入劫持代码，CDN和源通信遭到ARP攻击，用户PC本地木马。当然，这些问题目前已经解决，并且正在持续监控中。当然，这些问题目前已经解决，并且正在持续监控中。  为了对抗链路劫持，腾讯的许多业务也使用了HTTPS或私人协议，如QQWeb登录、QQ邮箱、金融通信、Web微信、微信公共平台等。DNS劫持攻击相对容易检测和保护。在检测方面，用分布点进行DNS查询即可，发现运营商DNS结果不对可促进修复。在防护方面，使用DNSSEC是一种方案（DNSSecurityExtensions）；腾讯和114DNS也开发了自己的方案——HttpDNS。HTTPDNS通过HTTP协议从HTTPDNS后端服务器获取域名对应的IP，而不使用DNS协议。当然，我们可以实现一堆类似的想法：HTTPSDNS、TCPDNS、UDPDNS、ICMPDNS...链路劫持相对复杂。  在检测方面，如果有客户端，可以依靠客户端进行检测；如果没有客户端，可以用JavaScript在网页上检测页面元素，甚至在全国重要城市租用ADSL进行检测。此外，在机房的流量监控设备中会发现异常：例如，在这种情况下，用户在收到HTTP响应后不会回应，然后在URL中带来yiqifa.com的关键字重新访问主页；另一个例子是，某些设备的HTTP阻断器将向服务器发送特定的RST包（我见过8*送IPID的案例）。在保护方面，本案只是伪造数据包，没有被阻止。因此，只要客户端安全软件拦截疑似问题包（TTL值在TCP会话中差异很大或IPID突然跳转），就可以进行防御。如果没有相同的数据包，可以拦截并休眠1秒，以免误杀。如果你有自己的客户端，你可以采取自己的私人协议。网站类别比较困难。部署HTTPS。百度主页最近使用了HTTPS，但大多数用户仍然不习惯在浏览器中输入“https:/”，因此仍有被劫持的风险(类似的工具有SSLStrip)。当然，对抗也会升级，比如GMail证书伪造事件。  当HTTPS不能大规模普及时，能否为用户或终端软件提供避免链路劫持的安全服务？好像可以。下图是一个简单的解决方案，可以通过本地代理软件和云服务来避免不安全的ADSL链路。一些浏览器的云加速也客观地实现了这一功能。对于安全性不确定的公共WiFi，也可以使用类似的方法来规避风险。后记希望这篇文章对你有帮助。