字节跳动安全中心

1、背景

2020年12月13日，网络安全公司FireEye发布分析报告，称全球知名网络安全软件供应商SolarWinds旗下产品遭受供应链攻击并被植入木马后门，影响版本为2019.4 HF 5 - 2020.2.1，使用该产品的机器可被攻击者完全操控。根据SolarWinds在其官网发布安全通告显示，约有18000名客户下载了受影响的软件产品，影响超过250家企事业单位，其中包括北美、欧洲、亚洲、和中东的政府部门、关键基础设施和一些关系国计民生的部门。

2021年2月国外安全媒体发文称一名安全研究人员在一次关于供应链投毒的安全研究中成功突破并入侵了超过35家大型公司的内网，其中包括微软、苹果、PayPal、Shopify、网飞、Yelp、特斯拉和优步等众多全球知名企业。本次事件的根因是内部第三方依赖包管理混乱的问题，一般各大公司都会在内部维护一个私有镜像源，存储一些内部开发的第三方包，如果开发人员在安装这些包时没有指定私有源，那么包管理工具便会在公有源上搜索并下载依赖包，当恶意攻击者在公有源上传包名相同，版本号较大的恶意包后，包依赖工具就会自动拉取这些恶意包，从而造成恶意代码的执行。

目前，供应链攻击的频率和成熟度在不断提高。根据行业估计，供应链攻击现在占所有网络攻击的50％，与去年同比激增了78％。多达三分之二的公司经历了至少一次供应链攻击事件。同时，80%的IT专业人士认为软件供应链攻击将是企业在未来三年面临的最大网络威胁之一。

2、软件供应链攻击

2.1 软件供应链

传统的供应链是指产品生产和流通过程中所涉及的原材料供应商、生产商、分销商、零售商以及最终消费者等成员通过与上游、下游成员的连接组成的网络结构。也即是由物料获取、物料加工、并将成品送到用户手中这一过程所涉及的企业和企业部门组成的一个网络。

传统供应链的模型可以完全套用到计算机软硬件中，这样就衍生出了软件供应链的概念：软件在开发、交付以及使用过程中所涉及一系列行为、工具所共同组成的软件体系结构。

2.2 软件供应链攻击

顾名思义软件供应链的攻击就是针对开发、交付以及使用三个环节的针对性攻击行为，如背景中介绍的网络安全软件供应商SolarWinds的攻击，就是针对软件使用环节的攻击，而对Python请求库requests的攻击则是软件开发阶段的攻击。

在所有软件供应链攻击的行为中，针对开发环节第三方库的攻击是其中破坏性最强、影响范围最广的攻击方式，因为当前软件基本都是有各式各样的第三方库堆叠而成，其中任何一个第三方库受到攻击，整个软件也必然会受到影响。针对第三方库的攻击方式一般有以下两种方式：

攻击者通过攻击知名软件官方的服务器、篡改软件源代码加入恶意代码，然后提供给前往官方下载的用户使用。这种攻击方式的攻击难度比较大，但是影响范围极其广阔，所有使用该软件的用户都会受影响。比如：PHP官方代码投毒事件，在今年3月份git.php.net(原PHP官方代码服务器)服务器疑似被攻击，攻击者向PHP源代码中进行了两次后门代码提交。该后门通过判断HTTP请求头中的User-Agent（不是User-Agent）是否包含zerodium关键词来触发后门，理论上是能够影响所有使用PHP的开发的站点。
攻击者向开源软件包存储库比如：npm、PyPI、RubyGems、Godoc、Maven等上传带有恶意代码的软件包，这些软件包在名称上通常与一些知名的第三方包极其相似，比如上文提到的request与requests，因为包名上的迷惑性，用户极易下载恶意软件包并安装使用，从而触发恶意代码。这种攻击方式成本极低，而且很容易泛滥，因此针对这种相似恶意软件包的检测治理是我们接下来要介绍的重点，也是主要的治理对象。

3、第三方软件包的攻与防

3.1 第三方软件包的攻击方式

开发者为了开发效率往往会采用外部的服务或开源的代码或代码段，但大多数开发者都对外部代码有着迷之信任，一般不会对需要使用的代码作细致的代码审核，这就给外部风险带入软件系统提供了机会。那么这些恶意的第三方软件包是怎么被引入的呢？下面将对目前常见的引入方式进行说明。

依赖包导入错误

在Python中，导入的包名和代码中使用的包名会有些许不同，例如 pwntools 库中在代码的引入方式为：

from pwn import *

研发在遇到相应代码有可能习惯性的输入pip install pwn 。

而非正确的安装方式 pip install pwntools 。这就会安装到其他非预期内的恶意包。

同名包

多数公司内部会维护一个自己镜像源，会存储仅限于公司内部使用的库文件，往往包名会加入一些特殊字符例如xx-redis用来保持与外部源独立，对于一些粗心的开发者在下载包时忘记指定内部源。包管理工具就会在公有源进行搜索，如果在公有源中也存在同名的恶意包，攻击者就可以成功进入内网之中。

尤其要注意pip的管理方式，某些开发会指定--extra-index-url=参数到私有源，但是该参数会自动的在原始pypi.org和私有源中查找，会选择较新版本号进行下载。使用--index-url=则不会出现上述问题。

Typo攻击

类似于同名攻击，不过更加需要运气，因为这需要用户误输入错包名，所以整体攻击成功概率相对较低，比如PyPI官方仓库中的request恶意包投毒。

直接引入存在风险的代码段

攻击者有意或无意上传存在风险的代码块，经过互联网中的扩散，使得在搜索引擎中存在较大优先级，开发在搜索相应功能的实现时，很容易直接将代码贴入项目，这就带来了风险的引进。最有代表为PHP中getip函数，该函数可以很轻易的通过修改请求头来修改用户IP，结合其他代码逻辑也可能引入SQLi及XSS问题。

<?php
function getip() {
    if($HTTP_SERVER_VARS["HTTP_X_FORWARDED_FOR"]){
        $ip = $HTTP_SERVER_VARS["HTTP_X_FORWARDED_FOR"];
    }
    elseif($HTTP_SERVER_VARS["HTTP_CLIENT_IP"]){
        $ip = $HTTP_SERVER_VARS["HTTP_CLIENT_IP"];
    }
    elseif ($HTTP_SERVER_VARS["REMOTE_ADDR"]){
        $ip = $HTTP_SERVER_VARS["REMOTE_ADDR"];
    }
    elseif (getenv("HTTP_X_FORWARDED_FOR")){
        $ip = getenv("HTTP_X_FORWARDED_FOR");
    }
    elseif (getenv("HTTP_CLIENT_IP")){
        $ip = getenv("HTTP_CLIENT_IP");
    }
    elseif (getenv("REMOTE_ADDR")){
        $ip = getenv("REMOTE_ADDR");
    }
    else{
        $ip = "Unknown";
    }
    return $ip;
}

3.2 如何防御第三方恶意软件包

企业内部应自建各种软件源(比如：PyPI、npm、Godoc)，软件同步必须来自官方源。通过自建内部源可以收敛源头，一旦发生供应链攻击事件，可以快速从内部源上删除第三方恶意包，切断恶意包的传播。并且通过内部源的各种日志、打点可以得知有哪些服务使用了恶意包，从而可以快速溯源止损。
实时监控各个官方源，利用相似度算法计算有没有与内部私有包名相似或相同的包，当发现这类包时，使用代码分析、机器学习等方法确定该包是否存在恶意行为。
从各种软件源同步包时，要进行实时扫描，扫描方式可以是静态扫描或动态沙箱扫描。
加强对漏洞危害的分享，养成内部代码review的习惯，避免直接粘贴存在恶意行为的代码。

4、独家披露：开源软件包存储库存在1000+恶意包

今年5月，无恒实验室使用自研第三方恶意软件包检测工具WolfHunter对开源软件包存储库进行检测时，发现PyPi官方源上存在1000+的恶意包，npm官方源上存在200+的恶意包，这些包主要获取各种敏感信息、反弹shell、远程下载木马等。

说明：WolfHunter（猎狼人），无恒实验室自研第三方恶意软件包检测工具，一款融合了静态代码扫描、动态沙箱扫描(基于字节已开源瑶光Elkeid HIDS：https://github.com/bytedance/Elkeid/）、机器学习等多项技术的恶意代码检测工具。

下面对发现的典型恶意软件包Rbperf的溯源流程进行说明。

5月14日，无恒实验室检测到PyPi上传了一个Rbperf包，属于反弹shell的恶意包。

通过对Rbperf包进行溯源并持续监控发现，该包作者id是：ch13fd357r0y3r 。

PyPI homepage：https://pypi.org/user/ch13fd357r0y3r/

twitter 主页：https://twitter.com/Shanmuga_2002

Reddit 主页：https://www.reddit.com/user/ch13fd357r0y3r/，而且疑似在PHP也上传了恶意包，但已删除

攻击者从2021年5月14日到2021年6月16日共上传恶意包7个，涉及8个版本，4个IOC，下载量超过1000+，影响30多个国家及地区。

恶意包名：qlib_server、Proxy65、py-fbzmq、dspltools、rbperf、OSXFrameworks、CalDAVTester

IOC：13.233.214.229、65.1.120.255、3.108.43.183、13.235.23.90

具体信息如下：


包名	日期	版本号	ioc	下载地址
qlib_server	20210606	99.99.99	13.233.214.229	https://pypi.org/simple/qlib-server/
Proxy65	20210607	12.0.1	65.1.120.255	http://mirrors.tencent.com/pypi/simple/Proxy65/
py-fbzmq	20210513	1.5	3.108.43.183	https://mirrors.tencent.com/pypi/simple/py-fbzmq/
20210515	1.9	3.108.43.183	https://pypi.tuna.tsinghua.edu.cn/simple/py-fbzmq/
dspltools	20210515	0.5.5	3.108.43.183	https://mirrors.tencent.com/pypi/simple/py-fbzmq/
rbperf	20210514	0.1.2	3.108.43.183	http://mirrors.tencent.com/pypi/simple/rbperf/
OSXFrameworks	20210516	0.1.7	3.108.43.183	https://mirrors.tencent.com/pypi/simple/OSXFrameworks/
CalDAVTester	20210616	99.99.99	13.235.23.90	https://mirrors.tencent.com/pypi/simple/CalDAVTester/

通过对这7个恶意包分析后发现，攻击者都可以进行远程命令下发。这些包都是通过伪造一些大厂开源软件包来进行钓鱼，从而诱导更多人安装。比如qlib_server是微软的下的一款数据服务系统 microsoft/qlib-server，具体伪造详情如下：


包名	厂商	项目主页
qlib_server	微软	https://github.com/microsoft/qlib-server
py-fbzmq	facebook	https://github.com/facebook/fbzmq
dspltools	google	https://github.com/google/dspl/tree/master/tools/dspltools
rbperf	facebook	https://github.com/facebookexperimental/rbperf
OSXFrameworks	apple	https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemFrameworks/SystemFrameworks.html
CalDAVTester	calendarserver	https://www.calendarserver.org/CalDAVTester.html

下面详细描述qlibserver包如何触发恶意行为，qlibserver包安装过程中会加载setup.py中的载恶意代码，连接远端C2，循环等待远端下发命令并执行（其他包类似，在此不再赘述）。

5、恶意组件包列表

下面将截止到目前发现的恶意软件包罗列在此，希望大家能够根据该列表对内部公司使用依赖库进行筛查，以避免公司内部使用了这些恶意软件包，给公司造成损失。部分恶意包已联系PYPI官方删除，想了解更多详情，可到其他源下载恶意包。

https://bytedance.feishu.cn/sheets/shtcnMIXEYzkTkmruPS9NwMl3ie

（请复制链接到浏览器中查看）

6、后续计划

目前主要支持PYPI、NPM源上组件的扫描，后续会逐步支持RubyGems、Godoc、Maven等开源软件库的扫描。
秉承共建安全生态的原则，后续我们会定期公布已发现的恶意软件包具体信息，读者可以根据这些信息进行自查，保护自身信息资产安全。

7、结语

开源对于软件的发展具有重大的意义，许多企业的业务中或多或少都引入了开源的第三方依赖，使企业可以更关注于业务的发展。但是在引入第三方依赖的同时，也不可避免地引入开源代码中的安全漏洞，这些安全漏洞往往能对业务造成致命的打击。随着越来越多的第三方依赖漏洞被披露，越来越多的企业也开始重视第三方依赖的安全性。

无恒实验室致力于为公司与全行业业务保驾护航，亦极为重视第三方依赖对业务安全的影响，在检测公司引入的第三方依赖安全性的同时，无恒实验室也着力于挖掘第三方依赖中未曾被披露的漏洞与安全隐患，并将持续与业界共享研究成果，协助企业业务避免遭受安全风险，亦望能与业内同行共同合作，为网络安全行业的发展做出贡献。

参考链接：

https://www.freebuf.com/news/257865.html

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

https://www.aqniu.com/news-views/61332.html

https://www.secrss.com/articles/28205