« 上一篇下一篇 »

任意服务器root密码可被重置?阿里云辟谣,相关零日漏洞0day的防范

  近日,有人发布安全警示称,阿里云存在未知0day,可重置任意服务器root密码。

在黑客文化中,0day也被称为零日漏洞,表示大规模、致命性、高威胁性、能够造成巨大破坏的漏洞。

阿里云回应

对此,阿里云安全专家确认:网络传闻“可重置任意阿里云服务器root密码”为虚假信息。真实情况为某客户自身的管理员AK(access key)泄露所导致的独立事件,目前阿里云已经联系该客户进行处理。

阿里云同时提醒:AK为核心密钥,务必按照最佳实践合理使用

  还记得4年前的CodeSpaces是怎样破产的吗?就是因为上云之后AK泄露了,黑客勒索未遂,结果彻底删除CodeSpaces的所有数据以及数据备份。

阿里云安全专家确认:网络传闻“可重置任意阿里云服务器root密码”为虚假信息。真实情况为某客户自身的管理员AK(access key)泄露所导致的独立事件,目前我们已经联系该客户进行处理。借此提醒:AK为核心密钥,务必按照最佳实践合理使用: 上云,你需要了解的AK使用姿势

附链接原文:

云,你需要了解的AK使用姿势

看了小编君的漏洞报告,“ 假如你娶了云存储,这些姿势以后就别用了 ”,有些震惊。企业要安全上云,还需提高自身的安全修养呀,否则可能都不知道是怎么死的。报告里提到的几个上云的“受害者”,我猜都是“豪”。在Code里硬编码AccessKey,也就算了;还把Code放在公开的Github上,也算是醉了。这无异于,把取款密码写在银行卡上,然后再把银行卡扔在大街上。

认识AccessKey(简称AK)

企业上云时,云平台会为企业提供一个仓库,企业在云上的资源(比如云存储、云虚拟机、云数据库、……)都会放在这个仓库里。AK是给企业应用程序开启这个仓库的门钥匙,它和人类用的密码是类似的。保管好AK不被泄露是客户必需的责任。还记得两年前的CodeSpaces是怎样破产的吗?就是因为上云之后AK泄露了,黑客勒索未遂,结果彻底删除CodeSpaces的所有数据以及数据备份。

为了安全地上云,企业客户需要了解一些正确的使用姿势。

姿势1:正确保护AK 

密钥保护非常有挑战。最简单的一种保护方法是使用操作系统的访问控制机制来保护AK文件,比如: $ chmod 400 ~/.aliyuncli/credentials 。其次,使用密钥管理系统(KMS)来保管AK也是不错的选择,KMS通常会验证应用程序是否有正确的授权码以及源IP地址,在严格检查授权有效性之后才允许使用。最严格的保护方法要算银行类企业,它们通常会使用硬件安全模块(HSM)来保护AK,保存在这个模块里的密钥是只进不出,当模块感知到有人拿刀“切”芯片时就会冒烟自毁,所以不管多牛逼的“厨子”也是无能为力的。

姿势2:杜绝使用“大AK

AK是有“大”、“小”之分的。如果你还不知道,说明你使用的就是“大AK”。大AK,就是与云账号直接关联的AK,它代表的是云账号的所有权限。如果你在使用大AK —— 一旦这个大AK泄露,后果很严重,CodeSpaces的破产就是前车之鉴。

为了让企业应用程序能安全地工作,阿里云 访问控制服务 (RAM)允许云账号为应用程序创建一种“小AK”,这个小AK代表应用程序的身份,其访问权限可以被定制。根据最小权限原则,企业应该为应用程序提供刚好满足其功能所需的最小权限。

举个例子,如果应用程序只需要读取阿里云OSS的mybucket空间中hangzhou目录下的所有对象文件,那么就可以为小AK精确定制这一 授权策略 ,如下:

{     "Version": "1",     "Statement": [         {             "Effect": "Allow",             "Action": "oss:GetObject",             "Resource": "acs:oss:*:*:mybucket/hangzhou/*"         }     ] }

使用这种方法后,假若企业应用程序的“小AK”被泄露,最糟糕的情况就是黑客也能读取OSS目录mybucket/hangzhou/下的所有对象文件,而仓库里的其它资产仍然安全无恙。

姿势3:限制应用程序的访问源IP

为了彻底防止因AK泄露所导致的风险,阿里云提供了针对应用程序的访问源IP限制。企业可以根据需要来设定访问云上仓库的源IP地址列表,应用程序发送操作请求的源IP地址如果不符合要求,那么就会被拒绝。只有源IP地址正确时,权限检查才会通过。

还是接着上面的例子,假设企业应用程序部署在一个确定的IP地址范围,如 42.120.99.0/24,那么带IP限制条件的授权策略如下:

{     "Version": "1",     "Statement": [         {             "Effect": "Allow",             "Action": "oss:GetObject",             "Resource": "acs:oss:*:*:mybucket/hangzhou/*",             "Condition": {                 "IpAddress": {                     "acs:SourceIp": "42.120.88.0/24"                 }             }         }     ] }

这样的话,即使黑客盗取了应用程序的“小AK”,然并卵。。。

姿势4:为iOS或Android应用颁发临时访问令牌(Token)

永远不要将AK写到iOS或Android应用里。虽然App应用是企业开发的,但安装App的iOS或Android设备并不受企业的控制,记住永远不要将秘密放在不受控制的地方。如果AK写到了App里,控制App设备的人总是可能猎取到AK,并且可能任意传播猎取的AK。一旦出现这种情况,开启源IP限制也于事无补,因为App用户的IP地址一般是无法确定的,开启源IP限制还会误伤其他正常用户。

对于这种场景,从安全角度看,只能给iOS或Android应用做临时授权,如5分钟自动失效;而且必须授予最小权限,如每一App用户能访问的子目录都是不一样的。只有做到“最小权限+最短时效”,数据安全风险才能得到有效的控制。

为此,阿里云提供了 安全令牌服务 (STS)来解决这类问题,基本思路如下图所示

eE3eqqi

0. AppServer使用“小AK”,为“小AK”配置最小权限以及源IP限制。比如,AppServer的最小权限可能是这样 —— “不允许直接访问仓库里的OSS数据,只能访问STS来颁发Token,而且颁发出来的Token权限只能访问oss://mybucket/hangzhou/这个目录”。

1. 为每个App用户颁发满足“最小权限+最短时效”的Token。比如,App用户厨子只需访问oss://mybucket/hangzhou/<厨子>/ 这个目录,只需要访问1次,那么就为厨子的App颁发满足这一权限和最短时效的Token。

2. AppServer获取Token后,通过安全链路(如HTTPS)将Token传递给App。

3. App使用Token访问云上仓库(如OSS)。

下面我们来简单分析下安全性:

(1) 如果AppServer被攻击,黑客获取小AK,然并卵。首先,这个小AK不具备直接访问OSS数据的权限,它只能被用于调用STS获取Token。其次,黑客如果先通过STS获取Token再用Token访问OSS的话,也不可行的,因为小AK是受源IP限制的,无法在公网上任意使用;即使黑客知道这个受信的IP列表,实施ip spoofing攻击的难度也很大,因为公网路由器基本上都会做reverse path filter。

(2) 如果App用户厨子是个Geek,她能猎取到的所有秘密也就是一个“最小权限+最短时效”的Token,然并卵。因为这个小Token只能访问厨子自己应该访问的数据,猎取到这个Token并不能进行提权攻击。如果她故意把这个Token泄露出去,那就是搬石头砸自己的脚。

所以,建议乌云君报告里提到的“敢聊”,可以试试阿里云的OSS + STS解决方案,绝对可以确保App用户的照片和语音等隐私数据不会泄露。

欲知更多安全姿势,请移步云产品安全最佳实践。

结语

有云的地方就有恩怨,有恩怨的地方就有江湖,云就是江湖。上云,还是要多备些安全锦囊,以防患于未然。