译者:飞龙
Tor
注意: 这些讲座笔记是从 2014 年 6.858 课程网站上发布的笔记中稍作修改的。
论文的目标是什么(或 Tor 的目标是什么)?
-
为了客户端的匿名性,他们想要连接到互联网上的服务器。
-
对于希望为用户提供服务的服务器的匿名性。
-
什么是匿名性?
-
对手无法确定哪些用户正在与哪些服务器通信。
-
对手(最有可能)知道用户,服务器是通过 Tor 进行通信的。
-
换句话说,Tor 并不是为了防止对手找到 Tor 用户而设计的。
-
如何实现匿名性?
-
必须加密要匿名的人的流量。
- 否则,对手会查看数据包并弄清楚发生了什么。
-
但加密并不足够:仍然可以追踪加密数据包的去向。
-
将一个用户的流量与其他用户的流量混合(或“掩盖流量”)。
-
一个用户的匿名性需要有许多其他像第一个用户一样的用户。
-
如果所有其他用户只运行 BitTorrent,那么维基百科用户很容易被发现。
-
如果所有其他用户使用 Firefox,那么 Chrome 用户很容易被发现。
-
…
-
-
对手将无法确定哪个用户发起了什么连接。
-
混合组件必须更改数据包(例如,加密/解密)。
- 否则,可以查找相同数据包稍后出现的位置。
-
因此,方法是:通过加密/解密的中间人中继流量。
为什么我们需要多个节点?
-
可扩展性:处理比单个节点更多的流量。
-
妥协:攻击者了解有关受损节点的直接客户端的信息。
-
有许多独立节点,这只影响了一小部分流量。
-
使用洋葱路由,攻击者必须妥协链中的所有节点。
-
-
流量分析:攻击者可以相关联传入/传出的流量。
-
可以查看数据包之间的时间间隔或数据包的数量。
-
链接使时间/数据量分析攻击更难实施。
-
-
攻击者仍然能够成功吗?
-
是的,如果他们观察或者妥协足够多的节点。
-
例如,可能足以观察第一个和最后一个节点。
-
攻击者还可以注入时间信息(通过延迟数据包)进行分析。
-
主要思想:洋葱路由
-
网络中的洋葱路由器(ORs)的网格。
-
假设:客户端知道所有 ORs 的公钥。
-
客户端选择通过这个网络的某条路径。
-
洋葱路由的天真草人(不完全是 Tor):
-
客户端依次在路径中的每个 OR 的公钥中加密消息。
-
将消息发送到路径中的第一个 OR,该 OR 解密并中继,依此类推。
-
“出口节点”(路径中的最后一个 OR)将数据发送到真实网络中。
-
-
为什么这是一个好的设计?
-
每个 OR 都知道前一个和下一个跳跃,而不知道最终源或目的地。
-
通过两个 ORs,妥协一个 OR 并不会破坏匿名性。
-
在哪个级别应该中继事物?
-
可以在任何级别进行–IP 数据包,TCP 连接,应用级别(HTTP)
-
优势/劣势是什么?
-
低级别(IP):更一般,更少的应用程序更改,适用于更多应用程序。
-
更高级别(TCP,HTTP):更高效(单个 TCP 帧的开销,而不是存储单个 TCP 帧的多个 IP 帧的开销),更匿名。
-
-
Tor 做了什么?
-
使用 SOCKS 进行 TCP 级中继,拦截 libc 调用。
-
效率的例子:不需要 TCP 流量控制,Tor 进行重传
-
丢失通用性的例子:UDP 无法工作,无法进行路由跟踪,…
-
Tor 如何处理 DNS,如果不支持 UDP?
-
SOCKS 可以捕获目的地的主机名,而不仅仅是 IP 地址
-
出口节点执行 DNS 查找,建立 TCP 连接
-
-
-
丢失在较低层的匿名性的例子?
-
如果我们使用 IP,将泄漏大量 TCP 信息(序列号,时间戳)
-
如果我们使用 TCP,将泄漏各种 HTTP 头和 cookie。
-
如果我们使用 HTTP,可以通过 Javascript,Flash 等违反匿名性。
-
Javascript 环境中有许多可识别的特征。
-
浏览器版本,历史嗅探,本地网络地址/服务器…
-
-
“协议规范化”:在更高级别协议中修复所有自由度。
-
在实践中很难做到;特定于应用程序的代理很有用(例如,Privoxy)。
-
浏览器“识别”的演示:https://panopticlick.eff.org/
-
-
Tor 设计
-
OR 的网格:每个 OR 通过 SSL/TLS 连接到其他每个 OR。
-
不需要 CA 签名的 SSL/TLS 证书。
-
Tor 有自己的公钥检查计划,使用目录服务器。
-
OR 主要由志愿者运行:例如,MIT 运行几个。
-
-
终端用户运行实现 SOCKS 的洋葱代理(OP)。
-
OR 有两个公钥:身份密钥和洋葱密钥。
-
身份密钥在目录中注册,签署 OR 状态。
-
Onion 密钥由 OP 用于连接 OR,建立电路。
-
客户端从目录下载 OR 列表。
-
选择一系列 OR 形成电路,依次联系每个 OR。
-
-
客户端建立电路是昂贵的。- 为什么要这样做?
-
任何单个服务器可能被 compromise,无法信任它。
-
无法避免信任客户端机器。
-
-
为什么我们需要洋葱密钥以及身份密钥?
-
可能能够保护身份密钥免受长期损害。
-
每个 OR 使用身份密钥签署其当前的洋葱密钥。
-
-
Tor 为什么需要目录?
-
需要有人批准 OR。
- 否则攻击者可以创建许多 OR,监视流量。
-
目录是否会损害匿名性?
- 不,不需要在线查询。
-
如果一个目录被 compromise 了怎么办?
- 客户端需要大多数目录同意。
-
如果许多目录被 compromise 了怎么办?
- 攻击者可以注入许多 OR,监视流量。
-
如果目录不同步怎么办?
-
攻击者可能根据目录信息缩小用户身份范围。
-
看到一组目录消息的用户将使用特定的 OR。
-
-
术语:电路和流。
-
电路:客户端建立的通过 OR 列表的路径。
-
电路存在一段时间(也许几分钟)。
-
定期打开新的电路以防止攻击。
-
-
流实际上是一个 TCP 连接。
-
许多流在同一电路上运行(每个具有单独的流 ID)。
-
流是一个重要的优化:无需重建电路。
-
-
Tor 为什么需要电路?
-
如果电路存在时间很长会出现什么问题?
-
对手可能将多个流关联到一个电路中。
-
将单个用户的连接与不同站点联系起来,破坏匿名性。
-
Tor 电路
-
电路是 OR 序列,以及共享的(对称 AES)密钥。
-
ORs
c_1, c_2, .., c_n
-
键
k_1, k_2, .., k_n
-
-
单元格格式:
-
+---------+---------------+-----------+
-
| 电路 | 控制/中继 | - 数据 |
-
+---------+---------------+-----------+
-
2 字节 + 1 字节 + 509 字节
-
-
将"Circuit"和"Control/Relay"字段视为链路层头部。
-
电路 ID 是每对 OR 之间的。
-
用于在 OR 之间的同一 TLS 连接上多路复用许多电路。
-
控制消息是"链路本地的":仅发送给直接邻居。
-
中继消息是"端到端的":沿着电路中继。
-
-
为什么所有流量都是固定大小的单元格?
- 使流量分析更加困难。
-
控制命令是什么?
-
填充:保持活动或链路填充。
-
create/created/destroy:创建和销毁电路。
-
-
中继数据包中有哪些中继命令(DATA 中有什么)?
-
如果中继数据包目标是当前节点:
-
+----------+--------+-----+-----+-----------+
-
| StreamID | Digest | Len | CMD | RelayData |
-
+----------+--------+-----+-----+-----------+
-
2 字节 + 6 字节+ 2 + 1 + 498 字节
-
如果中继数据包目标是另一个节点:
-
+-------------------------------------------+
-
| 加密的、不透明的数据 + + + + + |
-
+-------------------------------------------+
-
+ + + + 509 字节
-
-
TCP 数据的 CMD 字段是"中继数据"。
-
其他值如"relay begin"等用于建立流。
OP 如何通过电路发送数据?
-
如上所述组成中继数据包(尚未加密)。
-
计算有效的校验和(摘要)。
-
摘要基于应解密数据包的目标 OR。
-
哈希是通过某个键的函数和与该 OR 交换的所有消息进行的。
- 防止重放攻击和主动攻击
-
摘要的前 2 个字节为零,其他 4 个字节来自哈希。
-
-
使用
AES(k_n)
加密,然后使用AES(k_{n-1}), .., AES(k_1)
加密。 -
发送加密单元格到第一个 OR(
c_1
)。- (OP 通过电路接收数据的逆过程。)
OR 如何处理中继数据包?
-
如果来自 OP 的方向,解密并远离 OP 转发。
-
如果不是来自 OP 的方向,加密并转发至 OP
OR 如何知道中继数据包是否适用于它?
-
验证校验和:如果匹配,则很可能适用于当前 OR。
-
优化:摘要的前 2 个字节应为零。
- 如果前两个字节不为零,则可以跳过哈希:不是我们的数据包。
-
如果校验和不匹配,则不适用于此 OR,继续中继。
-
美好的特性:
-
数据包大小与路径长度无关。
-
只有最后一个 OR 知道目的地。
-
如何建立一个新的流?
-
OP 通过电路发送"relay begin"。- 包含目标主机名、端口。
-
谁选择流 ID?- OP 可以在其电路中选择任意流 ID。
什么是"漏水管"拓扑?
-
OP 可以向其电路中的任何 OR 发送中继消息(不仅仅是最后一个 OR)。
-
可以通过任何 OR 构建流(即,TCP 连接),以防止流量分析。
初始化电路
-
OP 选择要用于其电路的 OR 序列。
- 为什么要让 OP 这样做?- 抵抗其他 OR“转移”电路。
-
连接到第一个 OR,发出“创建”操作以创建电路。
-
创建包括 DH 密钥交换消息。
-
创建响应包括 DH 密钥交换回复。
-
-
密钥交换协议:
-
[OP,OR 同意素数 p,生成器 g]
-
OP 选择随机 x。
-
OP 发送
E_{PK_OR}(g^x)
。 -
OR 选择随机 y。
-
OR 计算
K=g^xy
。 -
OR 回复
g^y, H(K || "handshake")
。 -
OP 计算
K=g^xy
。
-
-
我们如何在这里验证各方身份?
-
第一个 DH 消息使用 OR 的洋葱密钥加密。
-
DH 响应中密钥的哈希证明向客户端证明正确的 OR 解密了消息。
-
服务器不验证客户端-匿名性!
-
-
前向保密:是什么?如何实现?
-
密钥新鲜度:为什么?如何实现?
-
谁选择电路 ID?
-
TLS 连接的客户端端点(而不是整个电路的 OP)。
-
每个电路对于其穿越的每个链接具有不同的电路 ID。
-
-
控制数据包中的数据是什么?
-
控制操作(创建,销毁)或响应(例如,已创建)。
-
参数(例如,DH 密钥交换数据)。
-
-
对于每个后续 OR,OP 通过电路发送“中继扩展”消息。
-
在“中继扩展”单元中包含相同的 DH 密钥交换消息。
-
在电路结束时,“中继扩展”转变为“创建”。
-
客户端最终获得每个电路中每个 OR 的共享(对称 AES)密钥。
-
-
Tor 为什么有单独的控制单元和中继单元?
-
确保单元始终具有固定大小。
-
旧电路中的最后一个 OR 需要知道新 OR 和电路 ID。
-
每个通过 OR 的电路保留哪些状态?
-
电路中两个方向(从 OP 到 OR)的电路 ID 和相邻 OR。
-
与此电路和此 OR 的 OP 共享密钥。
-
每个电路的 SHA-1 状态。
我们能否避免在网络中存储所有这些状态?
-
没有每个单元中的可变长度路径描述符。
-
出口节点同样需要路径描述符才能知道如何发送回去。
-
中间节点需要执行公钥加密(昂贵)。
Tor 为什么需要出口策略?
-
防止滥用(例如,匿名发送垃圾邮件)。
-
出口策略类似于防火墙规则(例如,不能连接到端口 25)。
- 每个出口节点在打开新连接时检查出口策略。
-
为什么在目录中发布出口策略,以及其他节点信息?
-
不用于强制执行。
-
OP 需要知道哪些出口节点可能有效。
-
如果 Tor 不进行完整性检查会怎样?
-
需要完整性以防止标记攻击。
-
攻击者入侵内部节点,损坏数据包。
-
损坏的数据包最终会被发送出去,可以观察它们的去向。
Tor 如何防止重放攻击?
-
每个校验和实际上是 OP 和 OR 之间所有先前单元的校验和。
-
再次发送相同数据的校验和将不同。
-
运行良好,因为底层传输是可靠的(SSL/TLS 在 TCP 上)。
匿名服务
-
隐藏服务由公钥命名(伪 DNS 名称“publickey.onion”)。
-
为什么要在介绍点和会面点之间分开?
-
避免在介绍点上放置流量负载。
-
避免介绍点传输已知非法数据。
-
-
分割可以防止这两个问题。
-
Bob(服务)有一个介绍点(IP)。
-
Alice 选择一个会面点(RP),告诉 Bob 的 IP 关于 RP。
-
介绍点不中继数据。
-
会面点不知道它正在中继的数据是什么
-
-
为什么 Bob 要连接回 Alice?
- 准入控制,将负载分散到许多会面点。
-
什么是会面点 cookie?-让 Bob 向 Alice 的 RP 证明它是 Bob。
-
什么是授权 cookie?
-
一些可能会促使 Bob 回复的东西,否则他不会回复。
-
或许是大多数人不知道的秘密词语。
-
限制对 Bob 服务器的 DoS 攻击(只需发送许多 cookie)。
-
存储在主机名中:cookie.pubkey.onion。
-
-
最终状态:两个电路连接到 RP,之间有一个流连接。
-
RP 从一个电路的流中获取中继单元,并
-
将它们发送到另一个电路中的流中。
-
使用 Alice 和 Bob 之间共享的密钥(DH)加密桥接数据。
-
每个人都可以控制自己的匿名级别。
-
两个电路的完整路径都不知道。
-
使用 Tor 时可能会遇到的潜在问题?
-
应用层泄漏(Javascript,HTTP 头,DNS,…)
- 使用应用级代理(例如,Privoxy 剥离许多 HTTP 头)。
-
基于 Tor 客户端行为的指纹识别(新电路打开的频率)。
-
时间/量分析(部分防御是运行自己的 Tor OR)。
-
对网站进行指纹识别:流行网站的请求次数和文件大小。
- 固定大小单元的量化有所帮助。
-
恶意 OR:加入网络,广告大量带宽,开放出口政策。
运行 OR 的好处/风险?
好处:
- 更多的匿名性
风险:
-
资源使用
-
在线攻击(DoS,入侵,…)
-
离线攻击(例如,机器被执法部门扣押)
阻止 Tor 有多难?
-
从目录中找到 OR IP 列表,阻止所有流量到它们。
-
如何防御这种攻击?
-
向不同的客户端透露不同的 OR?
- 允许基于使用的 OR 对客户端进行指纹识别。
-
保持一些未列出的 OR?
-
只将未列出的 OR 用作第一跳,以避免指纹识别。
-
Tor 有“桥接”节点的概念,这是一个未列出的 OR。
-
-
如何找到这些未列出的“桥接”OR?
-
希望合法用户找到它们,但不让对手枚举它们。
-
Tor 采取的方法:特殊的桥接目录。
-
向每个 IP(通过 HTTP)或电子邮件地址(通过电子邮件)透露 3 个桥接。
-
仅在 24 小时后向相同客户端地址透露新的桥接。
-
可以按 IP 限制速率,找到尝试枚举桥接数据库的尝试等。
-
对于电子邮件,对手更容易创建虚假身份(电子邮件地址)。
-
Tor 信任 3 个邮件提供商来限制注册(gmail,yahoo,mit)。
-
你会使用 Tor 吗?它适用于哪些应用程序?
-
可能对所有流量使用速度太慢(高延迟)。
-
但不幸的是,这意味着只有敏感流量会通过 Tor 传输。
-
可能存在可信攻击,因此对抗非常强大的对手不是很好。
-
或许是避免拒绝服务攻击的好方法(即,转移到 Tor 上)。
-
据说,谷歌使用 Tor 来检查服务器是否特殊处理谷歌的 IP 地址。
Tor 有多活跃?
-
现在比论文描述的使用更加活跃。
-
~3000 个公共 ORs,~1000 个出口节点,~1000 个桥接节点,~2GB/s 的 OR 带宽。
-
8-9 (?) 个目录服务器,约 1600 个目录镜像。
-
-
困难问题:分发入口点 IP 地址,批准 ORs,…
-
有些 BitTorrent 使用,但并不压倒性:主要是因为对于大文件来说太慢了。
另一种方法:DC-nets(“用餐密码学家网络”)。
-
N 个参与者,但假设只有一个发送者(不知道是谁)。
-
每对参与者共享一个秘密比特位。
-
要传输“0”比特位,发送所有秘密的异或值。- 否则,发送相反的值。
-
所有传输都是公开的:为了恢复比特位,对所有人的传输进行异或运算。
-
可以建立发送多个比特位,使用冲突检测协议等。
-
在性能方面代价高昂,但提供比 Tor 更强大的安全性。
-
查看 Dissent OSDI 2012 论文,了解基于 DCnet 的系统的更多细节。
参考:
Android 安全
注意: 这些讲座笔记略有修改,来自 2014 年 6.858 课程网站上发布的内容。
为什么选择这篇论文?
-
真实系统,被广泛使用。
-
谨慎的安全设计(比 Web 或桌面应用程序更重要)。
-
原则=应用程序(而不是用户)
-
策略与代码(清单)分离
-
-
一些问题是不可避免的,并且看到问题出现的地方是有启发性的。
-
但也有趣的是看如何设计一个合理的安全计划。
威胁模型
-
目标: 任何人都可以编写任何人都可以安装的应用程序
-
威胁:
-
应用程序可能存在错误
-
应用程序可能是恶意的
-
CVE 数据库
-
www.cvedetails.com/vulnerability-list/vendor*id-1224/product*id-19997/Google-Android.html
-
一些错误但不是压倒性的—安全计划有效吗?
- 缓冲区溢出(仍然发生…)
-
当然,Android 运行在 Linux 上,这也包括 Linux 内核问题
总体计划
-
首先了解 Android 应用程序的外观和工作原理。
-
然后讨论安全机制和策略。
Android 应用程序是什么样子的?
-
四种组件类型:
-
活动: 应用程序的 UI 组件,通常每个“屏幕”一个活动。
-
服务: 后台处理,可以被其他组件调用。
-
内容提供程序: 可被其他组件访问的 SQL 数据库。
-
广播接收器: 接收来自其他组件的广播通知。
-
-
每个应用程序还有私有文件存储。
-
应用程序通常用 Java 编写。
-
运行在 Linux 内核+Android“平台”上(稍后会介绍)。
-
应用程序还有一个声明其权限的清单(稍后)。
-
整个应用程序由开发者签名。
活动:可以在屏幕上绘制,获取用户输入等。
-
一次只有一个活动在运行。
-
帮助用户推理输入的安全性。
-
如果用户正在运行银行应用程序(活动),则没有其他活动获取用户的输入。
意图:Android 中的基本消息原语。
- 代表应用程序意图做某事/与另一个组件交互。
意图字段:
-
组件:将请求路由到的组件名称(只是一个字符串)。
- 例如,
com.google.someapp/ComponentName
- 例如,
-
操作:此消息的操作码(只是一个字符串)。
- 例如,
android.intent.action.MAIN
,android.intent.action.DIAL
,…
- 例如,
-
数据:用于动作的数据的 URI(只是一个字符串)。
-
例如,
tel:16172536005
,content://contacts/people/1
(用于拨号)。 -
还包括数据的 MIME 类型。
-
-
类别:用于查找发送意图的过滤机制。
- 例如,
android.intent.category.BROWSABLE
表示可以从浏览器调用,用于动作android.intent.action.VIEW
,该动作查看数据中的 URI。
- 例如,
-
显式意图:指定组件名称。
-
隐式意图:没有组件名称,因此系统必须找出。
-
查看动作,数据,类别。
-
如果有多个组件匹配,也可以询问用户要使用哪个应用程序。
-
例如,用户点击地址 - 要打开哪个地图应用程序?
-
对服务的 RPC
-
初始与服务的通信通过发送意图进行。
-
服务还可以为客户端定义一个 RPC 协议。
-
比每次发送意图更有效。
-
客户端将连接“绑定”到服务。
-
网络 - 访问互联网。
-
与任何其他 Linux 系统中一样工作。
-
应用程序可以直接使用套接字,也可以通过 Java 的网络库。
为什么我们需要一个新的应用程序模型?(或者,现有模型有什么问题?)
-
桌面应用程序:
-
– 应用程序之间的隔离不够。
-
– 每个应用程序都拥有完整的特权,任何一个恶意应用程序都可以接管。
-
++ 应用程序可以轻松互相交互,共享文件。
-
++ 用户可以为每个任务选择应用程序(电子邮件应用程序、图像查看器等)。
-
-
基于 Web/浏览器的应用程序:
-
++ 无需安装应用程序或担心本地状态。
-
– 在典型模型中需要服务器(离线使用困难)。
-
– 应用程序之间的互动有限。
-
– 存在的互动通常是硬编码到特定的 URL。
-
例如,链接到联系管理器应用程序的 URL:用户无法选择新的。
-
越来越好:尝试解决此问题的“Web 意图”。
-
-
– 纯客户端应用程序的功能有些受限。
- 越来越好:相机、位置信息、本地存储、工作线程等。
-
Android 访问控制
Android 的应用程序模型如何处理应用程序互动、用户选择应用程序?
-
主要基于意图。
-
如果多个应用程序可以执行一个操作,发送隐式意图。
-
Android 框架决定哪个应用程序获得意图;可以询问用户。
Android 的应用程序模型如何处理应用程序隔离?
-
每个应用程序的进程在 Linux 中运行在单独的 UID 下。
- 例外:一个开发者可以将多个应用程序捆绑到一个 UID 中。
-
每个应用程序都有自己的 Java 运行时(但这主要是按照惯例)。
-
Java 解释器不受信任,甚至不是必需的;内核强制执行隔离。
每个应用程序 UID 有什么好处?
-
一个应用程序不能直接操作另一个应用程序的进程、文件。
-
每个应用程序都有私有目录(
/data/data/appname
)。- 存储首选项、内容提供程序的 sqlite 数据库、缓存文件等。
UID 隔离缺少什么:对共享资源的访问控制。
-
网络访问。
-
可移动的 sd 卡。
-
设备(相机、指南针等)。
-
意图:谁可以发送,什么意图,发送给谁?
-
我们还需要以某种方式确定所有这些的策略。
首先,机制:Android 如何控制对上述所有内容的访问?
-
网络访问:GIDs。
-
特殊的组 ID 定义了应用程序可以与网络通信的内容。
-
GID
AID_NET_BT_ADMIN (3001)
: 可以创建低级蓝牙套接字 -
GID
AID_NET_BT (3002)
: 可以创建蓝牙套接字 -
GID
AID_INET (3003)
: 可以创建 IP 套接字 -
GID
AID_NET_RAW (3004)
: 可以创建原始套接字 -
GID
AID_NET_ADMIN (3005)
: 可以更改网络配置(ifconfig,…)
-
-
需要内核更改才能实现这一点。
-
每个应用程序根据其特权获得这些组 ID 的子集。
-
没有对网络通信进行更精细的控制。
- 例如,可以想象按 IP 地址或按来源类似的策略。
-
-
访问可移动 SD 卡。
-
为什么不使用文件系统权限?
-
希望在 SD 卡上使用 FAT 文件系统,以允许在其他设备上访问。
-
FAT 文件系统没有文件所有权、权限等概念。
-
-
内核将所有 SD 卡文件视为特殊组 sdcard_rw(1015)拥有。
-
应该访问 SD 卡的应用程序在其组列表中具有此 GID。
-
在整个 SD 卡内没有更精细的隔离。
-
-
设备。
-
设备文件(
/dev/camera
、/dev/compass
等)由特殊组拥有。 -
应用程序在其组列表中以适当的组运行。
-
-
意图。
-
所有意图都经过单个可信的“参考监视器”路由。
-
运行在 system_server 进程中。
-
参考监视器执行意图解析(将意图发送到哪里?),
- 用于隐式意图。
[ref: ActivityStack.startActivityMayWait]
- 用于隐式意图。
-
参考监视器检查权限,基于意图和发送者。
[ref: ActivityStack.startActivityLocked]
-
将意图路由到适当的应用程序进程,或启动一个新的进程。
-
-
为什么不只使用意图来处理一切,而不是使用特殊组?
-
效率:希望直接访问相机、网络、SD 卡文件。
-
通过意图发送所有内容可能会带来重大开销。
-
参考监视器如何决定是否允许一个意图?
-
分配给应用程序和组件的“标签”。
-
每个标签都是一个自由格式的字符串。
-
通常以 Java 风格的包名称编写,以确保唯一性。
-
例如,
com.android.phone.DIALPERM
。
-
-
每个组件都有一个保护它的单个标签。
-
对该组件的任何意图必须由具有该标签的应用程序发送。
-
例如,电话拨号服务标记为
...DIALPERM
。 -
对于内容提供程序,有两个标签:一个用于读取,一个用于写入。
-
-
应用程序有一个授权使用的标签列表。
- 例如,如果应用程序可以拨打电话,则
...DIALPERM
在其标签集中。
- 例如,如果应用程序可以拨打电话,则
-
其他权限(网络、设备、SD 卡)映射到特殊的标签字符串。
- 例如,android.permission.INTERNET 被翻译为应用程序在 GID 3003 下运行。
应用程序如何获得一组特定标签的权限?
-
每个应用程序都有一个声明其所需权限(标签)的清单。
-
还声明了应该保护每个组件的标签。
-
当应用程序安装时,Android 系统会询问用户是否允许安装应用程序。
-
提供应用程序正在请求的权限列表。
曾经,Android 允许用户设置细粒度的权限选择。
-
Android 4.3 引入了“权限管理器”。
-
显然,这在 Android 4.4 中被移除了。
-
可能的原因:开发人员希望对事物有可预测的访问。
谁定义权限?
-
应用程序自己定义权限(回想:只是自由格式的字符串)。
-
Android 系统为内置资源(相机、网络等)定义权限。
- 可以使用 ‘adb shell pm list permissions -g’ 列出。
-
内置应用程序为其提供的服务定义权限。
- 例如,读取/写入联系人、发送短信等。
-
定义权限意味着指定:
-
权限的用户可见名称。
-
用户的权限描述。
-
将权限分组到一些类别中(花费、私人数据等)。
-
权限类型:“正常”、“危险”和“签名”。
-
三种权限类型的含义是什么?
-
正常:
-
可能会让应用程序烦扰用户,但不会造成严重后果的良性权限。
-
例如,
SET_WALLPAPER
。 -
比较 $(pm list permissions -g -d) 和 $(pm list permissions -g)
-
-
系统不会询问用户有关“正常”权限。
-
为什么要有这些权限?
-
可以在真正感兴趣时进行审查。
-
最小权限原则,如果应用程序以后被破坏。
-
-
-
危险:
-
可能允许应用程序执行危险操作。
-
例如,访问互联网、访问联系信息等。
-
-
签名:
-
只能授予由同一开发人员签名的应用程序。
-
想要强制使用 HTTPS:希望防止用户意外泄露。
-
为什么在引用监视器中进行此检查,而不是在每个应用程序中?
-
便利性,以防程序员忘记。
- 可以在应用程序端的库中执行。
-
根据权限可能将意图路由到不同的组件。
- 不想发送一个意图给组件 A,而另一个组件 B 却愿意接受它。
-
强制访问控制(MAC):权限与代码分开指定。
-
附注:烦恼,MAC 是一个多义词缩写。
-
媒体访问控制 – 以太网中的 MAC 地址。
-
消息认证码 – Kerberos v4 缺少的东西。
-
-
希望了解系统的安全属性而不查看代码。
-
-
对比:Unix 中的自主访问控制(DAC)。
-
每个应用程序都可以在文件上设置自己的权限。
-
权限可以随时间由应用程序更改。
-
看当前文件权限无法准确预测会发生什么。
-
-
应用程序也可以执行自己的检查。
[ref: checkCallingPermission()]
-
有点破坏了 MAC 模型:不能只看清单。
-
有必要,因为一个服务可能导出不同的 RPC 函数,
- 想要为每个权限设置不同级别的保护。
-
引用监视器只检查客户端是否可以访问整个服务。
-
谁可以注册接收意图?
-
任何应用程序都可以指定要接收具有任意参数的意图。
-
例如,可以在意图过滤器中创建活动(在清单中):
示例:
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="http" android:host="web.mit.edu" />
</intent-filter>
-
这是一个问题吗?
- 为什么或为什么不?
-
每当用户点击链接到 http://web.mit.edu/ 时,系统会提示用户。
- 只有“顶层”用户点击转换为意图,而不是网页组件。
-
如果提示用户可能会没问题。
- 即使如此,如果您唯一的地图应用程序是“不好的”:窃取发送给它的地址?
-
对于广播意图来说并不是很好,因为会发送给所有可能的接收者。
控制广播意图的分发。
-
在文档的示例中,希望
FRIEND_NEAR
意图不被所有人披露。 -
解决方案:发送方在发送广播意图时可以指定额外的权限标签。
-
参考监视器只将此意图发送给具有该标签的接收方。
如何验证意图的来源?
-
通常在接收组件上使用权限标签。
- 只要发送方具有正确的权限,就不一定关心发送方是谁。
-
结果应用程序经常忘记在广播接收器上设置权限限制。
-
2011 年 Usenix 安全论文:“权限再委托攻击”。
-
例如,可以创建一个永远响铃和震动的闹钟。
-
例如,可以向设置广播接收器发送消息以切换 wifi 等。
-
-
安卓中的一个解决方案:“受保护的广播”(不完整,但是…)
-
参考监视器特殊处理一些意图操作(例如,系统启动)。
-
只有系统进程可以发送那些广播意图。
-
发送方是否可以依赖名称将意图路由到特定组件?
-
更广泛地说,安卓如何验证名称?(应用程序名称,权限名称。)
-
没有一般计划,只是先到先得。
-
系统名称(应用程序,权限等)在这个模型中获胜。
-
其他应用程序可能会被先到的恶意应用程序抢占。
-
可以通过使用应用程序的名称向恶意应用程序发送敏感数据。
-
可以通过查看发送者名称信任恶意应用程序的意图。
-
可以通过使用恶意应用程序的权限名称设置宽松权限。
如果两个应用程序定义了相同的权限名称会发生什么?
-
先到先得。
-
恶意应用程序可以将一些重要权限名称注册为"正常"。
-
任何应用程序(包括恶意应用程序)现在都可以获得此权限。
-
其他依赖此权限的应用程序将容易受到恶意应用程序的攻击。
- 即使受害应用程序定义了自己的权限并且是唯一使用它的应用程序。(例如,签名权限。)
-
可能更好的做法:如果权限已经定义,则拒绝安装应用程序。
-
允许应用程序假设其自己的权限已经正确定义。
-
仍然不允许应用程序假设其他应用程序/权限名称的任何内容。
-
如果应用程序名称没有经过验证,为什么应用程序需要签名?
-
代表开发者。
-
对 CA 没有真正的要求。
-
帮助安卓回答三个问题:
-
这个新版本的应用程序是否来自与旧版本相同的开发者?(如果是,可以升级。)
-
这两个应用程序是否来自同一开发者?(如果是,可以请求相同 UID。)
-
应用程序是否来自定义权限的相同开发者?(如果是,可以获得访问签名级别权限。)
-
如何给另一个应用程序临时权限?
-
URI 委托。
-
URI 读/写访问的能力式委托。
-
系统通过文字字符串 URI 跟踪委托访问。
- 例如,
content://gmail/attachment/7
- 例如,
-
必须记得撤销委托访问!
- 例如,URI 可能表示稍后的另一条记录…
[ref: grantUriPermission(), revokeUriPermission()]
- 例如,URI 可能表示稍后的另一条记录…
-
参考监视器将授予的 URI 保留在内存中。
[ref: ActivityManagerService.mGrantedUriPermissions]
-
授权是短暂的,只持续到重新启动。
-
-
待定意图。
-
用例:从闹钟/时间服务回调到您的应用程序。
-
system_server 在内存中跟踪挂起的意图;短暂的。[参考:PendingIntentRecord.java]
-
撤销问题,与 URI 委托一样。“破坏”了 MAC 模型:无法完全从清单中推理出所有安全性。
-
应用程序存储在哪里?
-
两个选项:内部手机存储器或 SD 卡。
-
内部存储器始终由 Android 控制,因此可以假设它是安全的。
-
在 SD 卡上安装应用程序更加复杂,但由于空间原因更可取。
-
威胁模型:
-
担心恶意应用程序修改 SD 卡数据。
-
担心恶意用户复制付费应用程序。
-
-
SD 卡使用 FAT 文件系统,没有文件权限。
-
方法:使用每部手机的随机密钥对应用代码进行加密/认证。
-
密钥存储在手机的内部闪存中,对应手机唯一。
-
Android“平台”的安全性有多高?
-
TCB:内核+任何以 root 身份运行的东西。
-
优于桌面应用程序:
-
大多数应用程序不属于 TCB 的一部分。
-
作为 root 运行的东西要少得多。
-
-
一些漏洞在实践中显现。
-
Linux 内核或 setuid-root 二进制文件中的错误允许应用程序获取 root 权限。
-
如何做得更好?
-
系统调用过滤/ seccomp 使利用内核漏洞变得更加困难?
-
不清楚。
-
-
用户无意中安装具有危险权限的恶意软件应用程序。
-
实际常见的恶意软件:向高价号码发送短信。
-
攻击者通过部署此类恶意软件直接获得金钱。
-
用户为什么会犯这样的错误?
-
一个原因:某些权限对于平凡任务和敏感任务都是必要的。
-
例如,访问电话状态/身份需要获取唯一设备 ID。
-
导致不必要请求危险权限,使用户麻木不仁。
-
另一个原因:应用程序提前要求权限“以防万一”。
-
例如,可能以后需要它们,但更改权限需要手动更新。
-
另一个原因:无法拒绝某些权限。
-
另一个原因:包含恶意软件的现有 Android 应用程序的副本。
-
-
如何修复?
-
找到允许更多“非危险”权限而无需询问用户的方法。
-
允许用户有选择地禁用某些权限。(有关此方面的一些研究工作,请参见下面的参考资料。)
-
静态/运行时分析和审计–现在由 Google 实施。
-
寻找现有热门应用程序的几乎相同的克隆。
-
运行应用程序一小段时间以确定它们的功能。
-
安全研究人员在 Google 的应用程序扫描程序上获得了(非 root)shell。
-
事后合理预期:应用程序扫描程序只运行应用程序。
-
-
Android 的应用市场(Google Play)允许 Google 远程停用应用程序。
-
-
移动电话应用程序中的安全性的另一种模型:iOS/iPhone。
-
安全机制:所有应用程序运行两个可能的 UID。
-
苹果应用程序一个 UID,其他所有应用程序另一个 UID。
-
从历史上看是有道理的:一次只有一个应用程序处于活动状态。
-
随着多任务应用程序的切换,未更改 UID 模型。
-
反而,使用苹果的沙盒隔离应用程序(“Seatbelt”?)。
-
最初苹果应用程序之间没有隔离(现在不清楚?)。
-
因此,浏览器中的漏洞利用使所有苹果应用程序“暴露”。
-
-
在使用时提示权限。
-
用户可以运行应用程序而不授予权限(不像安卓)。
-
在这个模型中,“普通”权限并不是很有意义。
-
-
苹果在其应用商店中批准应用程序,部分基于安全评估。
- “基于声誉”的系统:难以利用许多手机并避免被检测。
参考资料
污点跟踪
注意: 这些讲座笔记是从 2014 年 6.858 课程网站上发布的笔记上稍作修改的。
安卓安全策略
这篇论文试图解决什么问题?
-
应用程序可以外泄用户的私人数据并发送到某个服务器。
-
高层次方法:跟踪哪些数据是敏感的,并防止其离开设备!
-
为什么安卓权限不够用?
-
安卓权限控制应用程序是否可以读取/写入数据,或访问设备或资源(例如,互联网)。
-
使用安卓权限,很难指定关于特定类型数据的策略。 (例子: “即使应用程序有网络访问权限,也不应该能够通过网络发送用户数据”)。
-
Q: 啊哈!如果我们从不安装既读取数据又具有网络访问权限的应用程序呢?
-
A: 这将阻止一些明显的泄漏,但也会破坏许多合法的应用程序! (例子: 电子邮件应用程序)
-
信息仍然可以通过侧信道泄漏。 (例子: 浏览器缓存泄漏了一个对象是否在过去被获取过)
-
应用程序可以勾结! (例子: 没有网络权限的应用程序可以将数据传递给具有网络权限的应用程序。)
-
恶意应用程序可能会欺骗另一个应用程序发送数据。 (例子: 发送一个意图到 Gmail 应用程序?)
-
-
安卓恶意软件实际上做了什么?
-
用位置或 IMEI 进行广告。 (IMEI 是每台设备的唯一标识符。)
-
窃取凭据:将您的联系人列表、IMEI、电话号码发送到远程服务器。
-
将您的手机变成一个僵尸,使用您的联系人列表发送垃圾邮件/短信! ‘Sophisticated’ Android malware hits phones
-
防止数据外泄是有用的,但仅靠污点跟踪是不足以防止设备被黑客攻击的!
TaintDroid 概述
TaintDroid 跟踪敏感信息在系统中传播的过程。
-
TaintDroid 区分信息源和信息汇
-
源生成敏感数据:例子: 传感器、联系人、IMEI
-
汇点暴露敏感数据:例子: 网络。
-
-
TaintDroid 使用 32 位位向量表示污点,因此最多可以有 32 个不同的污点来源。
-
大致上,污点从赋值的右手边流向左手边。
例子:
int lat = gps.getLatitude();
// The lat variable is now
// tainted!
Dalvik VM is a register-based machine,
so taint assignment happens during the
execution of Dalvik opcodes [see Table 1].
move_op dst src // dst receives src's taint
binary_op dst src0 src1 // dst receives union of src0
// and src1's taint
有趣的特殊情况,数组:
char c = //. . . get c somehow.
char uppercase[] = ['A', 'B', 'C', . . .];
char upperC = uppercase[c];
// upperC's taint is the
// union of c and uppercase's
// taint.
-
为了最小化存储开销,一个数组接收一个单一的污点标记,其所有元素都具有相同的污点标记。
-
Q: 为什么将数组或 IPC 消息仅关联一个标签是安全的?
-
A: 估计污点应该是安全的。 这可能会导致误报,但不会导致漏报。
-
另一个特殊情况:本地方法(即,内部 VM 方法如
System.arraycopy()
,以及通过 JNI 公开的本地代码)。-
问题: 本地代码不经过 Dalvik 解释器,所以 TaintDroid 无法自动传播污点!
-
**解决方案:**手动分析本机代码,提供其污点行为的摘要。
-
实际上,需要指定如何将参数的污点复制到返回值。
-
**问:**这种扩展效果如何?
-
**答:**作者认为这对内部 VM 函数(例如,
arraycopy
)效果不错。对于“简单”调用,分析可以自动化—如果只传递整数或字符串,则将输入污点的并集分配给返回值。
-
-
-
IPC 消息类似于数组:每个消息与一个污点相关联,该污点是组成部分的污点的并集。
- 从传入消息中提取的数据被分配为该消息的污点。
-
每个文件都与一个存储在文件元数据中的单个污点标志相关联。
- 与数组和 IPC 消息一样,这是一个保守的方案,可能会导致误报。
污点标记在内存中是如何表示的?
-
五种东西需要有污点标记:
-
方法中的局部变量
-
方法参数
-
对象实例字段
-
静态类字段
-
数组
-
-
基本思想:将变量的标志存储在变量附近。
-
**问:**为什么?
-
**答:**保留空间局部性—这有望改善缓存行为。
-
对于生活在堆栈上的方法参数和局部变量,立即在变量旁边分配污点标志。
-
例子:
.
.
| . |
+------------------+
| local0 |
+------------------+
| local0 taint tag |
+------------------+
| local1 |
+------------------+
| local1 taint tag |
+------------------+
.
.
.
_TaintDroid_ uses a similar approach
for class fields, object fields,
and arrays -- put the taint tag
next to the associated data.
因此,鉴于所有这些,TaintDroid中的基本思想很简单:当敏感数据通过系统流动时标记污点,并在数据试图通过网络离开时发出警报!
作者发现应用程序的各种不当行为:
-
将位置数据发送给广告商
-
将用户的电话号码发送到应用服务器
TaintDroid的信息流规则可能导致反直觉/有趣的结果。想象一个应用程序实现自己的链表类。
class ListNode{
Object data;
ListNode next;
}
假设应用程序将受污染的值分配给“data”字段。如果我们计算列表的长度,长度值是否受污染?
向链表添加元素涉及:
-
分配一个
ListNode
-
分配给
data
字段 -
修补
next
指针
请注意,步骤 3不涉及受污染的数据!因此,“next”指针是受污染的,这意味着计算列表中元素数量不会生成受污染的长度值。
TaintDroid的性能开销是多少?
-
用于存储污点标记的额外内存。
-
分配额外的 CPU 成本来分配、传播、检查污点标记。
-
开销似乎适中:内存开销约为 3–5%,CPU 开销为 3–29%
- 然而,在手机上,用户非常关心电池寿命:29% 的 CPU 性能下降可能是可以接受的,但电池寿命下降 29% 是不好的。
问题和答案
**问:**为什么不在 x86 指令或 ARM 指令级别跟踪污点?
**答:**这太昂贵了,而且误报太多。
-
例子: 如果内核数据结构被错误地分配了污点,那么污点将错误地流向用户模式进程。这会导致污点爆炸:无法确定哪个状态真正受到敏感数据的影响。
-
这可能发生的一种方式是如果堆栈指针或断点指针被错误地标记。一旦发生这种情况,污点会迅速扩散:
-
本地变量访问被指定为相对于断点指针的偏移量。
-
pop
等堆栈指令使用堆栈指针。
-
Q: 污点跟踪似乎很昂贵—我们不能只检查输入和输出以查找已知敏感值吗?
A: 这可能作为一种启发式方法,但对于对手来说很容易绕过它。
- 有许多编码数据的方式,例如,URL 编码、二进制与文本格式等。
隐式流
如描述的,污点跟踪无法检测隐式流。
隐式流发生在一个受污染的值影响另一个变量而不直接分配给该变量时。
if (imei > 42) {
x = 0;
} else {
x = 1;
}
我们可以尝试通过网络泄露 IMEI 的信息,而不是分配给x
!
隐式流通常是由于受污染的值影响控制流而产生的。
可以尝试通过给程序计数器(PC)分配一个污点标记来捕捉隐式流,更新它与分支测试的污点,并将 PC 的污点分配给 if-else 子句内的值,但这可能会导致很多误报。
例子:
if (imei > 42) {
x = 0;
} else {
x = 0;
}
// The taint tracker thinks that
// x should be tagged with imei's
// taint, but there is no information
// flow!
应用程序
污点跟踪的有趣应用:跟踪数据副本。
-
通常希望确保敏感数据(密钥、密码)及时擦除。
-
如果我们不担心性能,我们可以使用 x86 级别的污点跟踪来查看敏感信息如何在机器中流动。参考
-
基本思想:创建一个 x86 模拟器,解释完整系统(操作系统+应用程序)中的每个 x86 指令。
-
您会发现软件通常会保存比必要时间更长的数据。例如,按键数据会保留在:
-
键盘设备驱动程序的缓冲区
-
内核的随机数生成器
-
X 服务器的事件队列
-
用于传递包含按键消息的消息的内核套接字/管道缓冲区
-
终端应用程序的
tty
缓冲区 -
等等…
-
Tightlip
TaintDroid检测敏感数据泄漏,但需要 Java VM 的语言支持–VM 必须实现污点标记。我们能否在没有受管运行时支持的情况下跟踪敏感信息泄漏?如果我们想要检测遗留的 C 或 C++应用程序中的泄漏怎么办?
-
一种方法:使用TightLip 系统中引入的双重进程
-
步骤 1: 定期,Tightlip运行一个守护进程,扫描用户的文件系统,并查找类似邮件文件、文字处理文档等敏感信息。
-
对于这些文件中的每一个,Tightlip 生成文件的影子版本。影子版本是非敏感的,并包含清洁后的数据。
-
Tightlip 将每种类型的敏感文件与专门的清洁器相关联。 示例: 电子邮件清洁器用等量的虚拟字符覆盖 to: 和 from: 字段。
-
-
第二步:在稍后的某个时刻,一个进程开始执行。最初,它不接触任何敏感数据。如果它接触到敏感数据,那么 Tightlip 会生成一个复制者进程。
-
复制者是原始进程的沙盒版本。
-
继承大部分状态从原始进程…
-
…但读取清洁后的数据而不是敏感数据
-
-
Tightlip 让两个进程并行运行,并观察这两个进程所做的系统调用。
-
如果复制者与原始进程做出相同的系统调用并带有相同的参数,那么很可能输出不依赖于敏感数据。
-
-
第三步:如果系统调用发散,复制者试图进行网络调用,Tightlip 将标记潜在的敏感数据泄漏。
- 在这一点上,Tightlip 或用户可以终止进程,失败网络写入,或执行其他操作。
-
Tightlip 的优点:
-
适用于传统应用程序
-
需要对标准操作系统进行轻微更改,以比较系统调用的顺序及其参数
-
低开销(基本上是运行额外进程的开销)
-
-
Tightlip 的局限性
-
清洁器位于受信任的计算基础上。
-
他们必须捕捉所有敏感数据的实例。
-
他们还必须生成合理的虚拟数据–否则,复制者可能会在格式不正确的输入上崩溃!
-
-
如果复制者从多个来源读取敏感数据,并且发生系统调用分歧,Tightlip 无法判断原因。
-
分散式信息流控制
TaintDroid 和 Tightlip 假设开发人员不提供任何帮助…但如果开发人员愿意在其代码中明确添加污点标签呢?
int {Alice --> Bob} x; // Means that x is controlled
// by the principal Alice, who
// allows that data to be seen
// by Bob.
输入通道: 读取值获取通道的标签。
输出通道: 通道上的标签必须与写入值上的标签匹配。
-
静态(即编译时)检查可以捕捉许多涉及不当数据流的错误。
-
粗略地说,标签就像编译器可以推理的强类型。
-
静态检查比动态检查要好得多:运行时失败(或其缺失)可能是一种隐蔽通道!
-
-
更多细节,请参阅Jif paper
垃圾邮件的经济学
注意: 这些讲座笔记略有修改,来自 2014 年 6.858 课程网站。
网络攻击的经济学
到目前为止,我们已经处理了安全性的技术方面(缓冲区溢出,同源策略,Tor 等)。
-
主要关注点: 对手如何破坏系统?我们制定威胁模型,然后尝试使我们的系统对抗该威胁模型。
-
另一种观点: 为什么攻击者试图破坏我们的安全政策?
-
一些类型的攻击出于意识形态原因(例如,公民政治抗议;政府审查,Stuxnet)。对于这些类型的攻击,金钱不是主要动机。
-
让这些攻击变得更困难很难,除了通常“使计算机更安全”。
-
经济处罚可能涉及威慑,即在犯罪被发现后的处罚。然而,计算机和网络目前的问责制很差。 例子: Stuxnet 是从哪里来的?我们有一些好主意,但我们能在法庭上打赢官司吗?我们应该去哪个法庭?
-
-
然而,许多种类的计算机犯罪受到经济动机的驱使(例如,国家支持的工业间谍活动;垃圾邮件)。
-
-
要赚钱就得花钱!
-
攻击者需要建立基础设施来支持攻击。 例子: 用于发动攻击的机器,用于处理非法金融交易的银行。
-
或许我们可以通过使攻击者的基础设施成本过高来阻止他们? 例子: 如果发送垃圾邮件变得不赚钱,垃圾邮件发送者将停止发送垃圾邮件!
-
今天的讲座,我们将专注于涉及重要经济因素的攻击。
-
例子: 在赛里斯,垃圾邮件发送者经常雇用“短信车”。这些车辆拦截手机和手机基站之间的通信。车辆发现电话号码,然后向这些号码发送垃圾短信。一辆车每天可以发送 20 万条短信!
-
拦截设备成本:
~$1,600
-
每天利润:
~$1,600
-
被抓到罚款:< $5,000`
-
由于很少被抓到,垃圾车是一项利润丰厚的生意。
-
此外,赛里斯移动运营商每条垃圾短信都能赚钱,因此运营商有动机继续允许垃圾短信传播。
-
运营商定义特殊的“106 前缀”号码,这些号码不受一天可以发送多少条短信的正常限制。106 号码应该用于非商业目的(例如,公司与员工联系),但 55%的赛里斯短信垃圾邮件来自 106 号码。
-
-
-
有许多公司交易“网络武器”。 例子: Endgame。
-
$1.5 百万美元:Endgame 将为您提供数百万台未打补丁机器的 IP 地址和物理位置。
-
250 万美元:终极目标将向您出售一个“零日订阅包”,每年提供 25 个漏洞利用。
-
谁从网络武器交易商那里购买漏洞利用?政府?公司(例如,“反击”计划)?……?
有一个市场可以购买和出售攻击者可以用于恶意目的的各种资源。
-
被入侵的系统
-
整个被入侵的机器。
-
访问被入侵的网站(例如,发布垃圾邮件、链接、重定向、恶意软件)。
-
被入侵的电子邮件帐户(例如,Gmail)。
-
在现有僵尸网络上运行服务(垃圾邮件,DoS)。
-
-
工具
-
恶意软件套件
-
漏洞、利用
-
-
被盗信息
- 社会保障号、信用卡号、电子邮件地址等。
垃圾邮件生态系统
本文重点讨论垃圾邮件生态系统(特别是药品、仿冒商品和软件的销售)。主要有三个步骤:
-
广告:以某种方式让用户点击链接。
-
点击支持:展示一个将成为点击目标的网站。
-
认识到:允许用户购买东西、发送货款,然后收到产品。
最终,资金来自这个链条中的最后一部分,当用户购买东西时。
-
许多组件是外包的或通过联盟计划支持的:垃圾邮件发送者充当广告商,但联盟处理大部分/全部后端工作(例如,与银行合作)。
-
垃圾邮件发送者通常按佣金工作,获得他们带来的资金的 30%–50%。
接下来,我们将详细讨论这三个步骤,并探讨可能的干扰方式。
广告:如何让用户点击链接?
-
典型方法: 发送电子邮件垃圾邮件。(其他方法也有效:博客/评论垃圾邮件,在社交网络中发送垃圾邮件,……)
-
发送垃圾邮件的成本: 每百万封垃圾邮件的零售价为 60 美元。
-
直接操作垃圾邮件僵尸网络的实际成本要低得多。
-
垃圾邮件电子邮件的投递和点击率非常低,因此发送垃圾邮件必须非常便宜才能盈利。
-
一些相同人员之前的研究:
-
发送了约 3.5 亿封垃圾邮件
-
约 10,000 次点击,28 次购买尝试
-
-
-
我们如何让发送垃圾邮件变得更加昂贵?
-
IP 级别黑名单: 一段时间内有效,但只有对手拥有少量 IP 时才有效。
-
发送电子邮件收费?
-
旧想法,以各种形式存在:金钱、计算、验证码。
-
这可能有效吗?我们如何让每个人立即采用这种方法?
-
即使每个人同时采用这种方法,这也会起作用吗?如果用户设备被入侵怎么办?(但即使桌面设备被入侵,按照每条消息收费可能是一个很高的门槛,可以大大减少垃圾邮件,因为生成垃圾邮件需要非常便宜才能盈利!)
-
-
-
对手的三种解决方案:
-
大规模僵尸网络提供许多 IP 地址。
-
被入侵的网络邮件帐户提供特殊 IP 地址访问。
- 雅虎、Gmail、Hotmail 无法被列入黑名单。
-
劫持 IP 地址(使用 BGP 公告)。
-
-
然而,解决方法并非免费,对垃圾邮件发送者会产生一些成本。
- 发送垃圾邮件的成本在 IP 级别黑名单出现之前甚至更低。
僵尸网络通常用于发送垃圾邮件。
-
典型架构
-
许多运行僵尸网络软件的被入侵终端用户机器。
-
用于向僵尸发送命令的命令和控制(C&C)服务器/基础设施。
-
机器人定期从 C&C 基础设施获取新任务。
-
-
单个僵尸机器具有各种有用资源:
-
物理:IP 地址(用于发送垃圾邮件),网络带宽,CPU 周期。
-
数据:电子邮件联系人(用于发送垃圾邮件),信用卡号码,…
-
-
防止僵尸机器发送垃圾邮件很困难–可能有数百万个僵尸 IP!
将您的恶意软件安装在终端主机上需要多少费用?
-
每个主机的价格:美国主机约为$0.10,亚洲主机约为$0.01。
-
似乎难以防止;许多用户将乐意运行任意可执行文件。
命令和控制架构是什么样的?
-
集中式 C&C 基础设施:对手需要“防弹”主机(即,拒绝来自银行、法律机构的关闭请求)。
- 防弹主机收取风险溢价。
-
如果托管服务被关闭怎么办?
-
对手可以使用 DNS 进行重定向。此外,使用“快速流动”技术,攻击者可以快速更改与主机名关联的 IP 地址。
- 攻击者创建一个服务器 IP 地址列表(可能有数百或数千个 IP);攻击者将每个 IP 绑定到主机名上,持续时间很短(例如,300 秒)。
-
摧毁僵尸网络的 DNS 域名有多难?
-
可以关闭域名的注册,也可以关闭域名的 DNS 服务器。
-
对手可以使用域名流动,跨越许多独立的注册商。
-
更难摧毁:需要注册商之间的协调!
-
Conficker 发生了:它足够重要/重要…
-
-
-
-
分散的 C&C 基础设施:点对点网络。
- 允许僵尸网络主控操作更少或不需要服务器;难以摧毁。
被入侵的 Webmail 帐户也可以用于发送垃圾邮件。
-
非常有效的交付机制:每个人都接受来自 Yahoo、Gmail 等的电子邮件。
-
Webmail 提供商有动机防止帐户被盗。
-
如果供应商不阻止垃圾邮件,那么所有来自该供应商的邮件可能会被标记为垃圾邮件!
-
供应商通过广告赚取服务费,因此供应商需要真实用户点击广告。
-
-
供应商如何检测垃圾邮件?
-
监视每个帐户发送的消息,检测可疑模式。
-
对于可疑消息和初始注册/最初几条消息,使用验证码:向用户呈现图像/声音,要求用户转录–这对人类来说应该很容易,但对计算机来说很难。
-
-
获取被入侵的 Webmail 帐户有多难?
- 每个帐户的价格:在 Yahoo、Gmail、Hotmail 等上大约为$0.01-0.05。
为什么 Webmail 帐户如此便宜?验证码发生了什么?
-
对手构建服务来解决验证码;这只是一个金钱问题。
-
结果相当便宜:每个验证码约为$0.001,延迟低。
-
令人惊讶的是,这主要是由人类完成的:攻击者可以将工作外包给任何廉价劳动力的国家。[也可以使用亚马逊的 Mechanical Turk:这是一个众包网络服务,允许人类处理计算机难以执行的任务。]
-
-
攻击者可以重复使用验证码在另一个站点上,要求正常访客解决它,而不是雇佣某人来解决攻击者。
-
供应商可以对垃圾邮件发送者实施更频繁的检查,但如果检查太频繁,普通用户可能会感到恼火。
- 示例: Gmail 允许您启用双因素身份验证。在这种方案中,当您从之前未知的计算机上打开 Gmail 时,Google 会通过短信向您发送验证代码。
点击支持:用户联系 DNS 将主机名转换为 IP 地址
然后,用户联系相关的网络服务器。因此,垃圾邮件发送者需要:
-
注册一个域名。
-
运行一个 DNS 服务器。
-
运行一个网络服务器。
Q: 为什么垃圾邮件发送者要费心使用域名?为什么不直接使用原始 IP 地址来提供内容?
-
A1: 用户可能不太可能点击包含原始 IP 地址的链接?
-
A2: 更强的原因是,使用一层间接性使得保持内容服务器活跃变得更容易。
- 如果执法机构注销域名或禁用 DNS 服务器,但服务器仍然活跃,垃圾邮件发送者可以注册一个新的域名并创建一个新的 DNS 服务器。
重定向站点:
-
垃圾邮件 URL 通常指向重定向站点。
-
免费的重定向服务如 bit.ly 或其他 URL 缩短服务。
-
受损站点也可以执行重定向到垃圾邮件服务器。
-
-
重定向站点很有用,因为垃圾邮件过滤系统可能会将 URL 列入黑名单。
- 一个受欢迎的站点作为重定向平台非常有用:要阻止垃圾邮件,过滤软件必须将受欢迎的网站列入黑名单!
-
垃圾邮件发送者有时会将僵尸网络用作网络服务器或代理。
- 这隐藏了真实网络服务器的 IP 地址;再次间接!
在某些情况下,单个联盟提供商将运行一些或所有这些服务。
Q: 执法机构不能只是关闭联盟计划吗?
- A: 理论上是的,但要关闭整个组织可能会很困难。此外,还有相当数量的联盟计划。
Q: 关闭单个域名或网络服务器有多困难?
-
A: 取决于注册商或托管提供商[请参见论文中的图 3、4、5]。
-
只有少数几个注册商为许多联盟提供域名托管;同样,只有少数几个 AS 为许多联盟提供网络服务器托管。
-
只有少数几个联盟商将他们的域名、域名服务器和网络服务器分布在许多注册商和 AS 之间。
-
防弹主机提供商更昂贵,但数量众多;即使它们被关闭,相对容易替换。
-
实现阶段发生了什么?
-
用户支付商品费用。
-
用户通过邮件收到商品(或下载软件)。
付款协议:几乎总是信用卡。信用卡信息沿着这个流程传输:
Customer
|---->Merchant
|----> Payment processor (helps the
| merchant deal with the
| payment protocol)
|
|-->Acquiring bank (merchant's)
|-->Association network
| (e.g., Visa)
|
|---> Issuing bank
(customer's)
-
发卡银行决定交易是否看起来合法,如果是,就会发送批准回来。
-
PharmaLeaks 论文:一些计划每年收入超过 1000 万美元!
对于实物商品,供应商通常会直接将商品运送给购买者(这被称为*“drop shipping”*)。
-
Drop shipping 意味着联盟计划不需要自己储存实物产品。
-
作者推测供应商很多,因此没有供应端瓶颈。
Q: 为什么垃圾邮件发送者正确分类他们的信用卡交易?
- A: 协会网络(例如 Visa 或 Mastercard)对错误编码的交易收取高额罚款!可以推测,协会网络不希望因掩盖金融交易的真实目的而惹上麻烦。
Q: 为什么垃圾邮件发送者实际上会发货?
-
A: 信用卡公司跟踪"退单"请求的数量(即客户要求信用卡公司退还涉及破损交易的资金的次数)。
-
如果退单交易数量过高(>1%),信用卡公司会对此进行处罚。
-
因此,对于垃圾邮件发送者频繁向客户收费但不发货是不可持续的,特别是如果. . .
-
只有少数几家银行愿意与垃圾邮件发送者互动!(论文中的表格 V,图 5)
-
CCS’12 论文:在 2 年内只见过 30 家收单银行!
-
因此,一个有效的垃圾邮件预防技术是专注于那些少数几家银行。为什么呢?
-
切换银行的成本很高。
-
切换的财务风险。
-
-
但我们实际上能做些什么呢?
-
说服发卡银行将这些收单银行列入黑名单?
-
试图说服这些银行停止与垃圾邮件发送者打交道?这可能有些棘手:“由于知识产权保护存在不一致性,甚至在这些银行所在的国家,像药品这样的商品的销售是否违法都不清楚。”(第四部分.D)
-
垃圾邮件是令人反感的,但并非总是犯罪。
-
例如,一些联盟客户可能不是来自垃圾邮件,而是来自合法的谷歌搜索!
-
-
-
-
自这篇论文发表以来,信用卡网络已经采取了一些行动。
-
论文发表后,一些药房和软件供应商对 Visa 提出了投诉(作者使用 Visa 卡进行垃圾邮件购买)。
-
作为回应,Visa 进行了一些政策变更:
-
所有药品销售现在被标记为高风险;如果一家银行作为高风险商户的收单行,那么该银行将受到更严格的监管(例如,银行需要参与风险管理计划)。
-
Visa 的运营指南现在明确列举并禁止非法销售药品和侵权商品。
-
新语言使得 Visa 可以积极对收单银行进行罚款。
-
一些联盟计划的回应是要求客户提交身份证明(目的是过滤掉安全研究人员的测试购买)。然而,这会损害销售,因为客户不愿提供他们的身份信息。
-
-
伦理
这篇论文是否引起了道德关注?作者是否通过购买他们的商品支持了垃圾邮件发送者?
一些公司发起了“反击”活动,以报复知识产权盗窃,或阻止涉及其机器的僵尸网络。
-
示例: 2013 年,微软、美国运通、PayPal 和其他一些公司关闭了一个大型僵尸网络。微软随后告知受影响用户应该修补他们的机器。
-
微软的法律推理:僵尸网络正在侵犯微软商标。越来越多的公司正在使用新颖的法律论点采取行动对抗僵尸网络… 这是一个好主意吗?
参考文献
-
无价:支付在滥用广告商品中的作用 [CCS’12]
一些问题可能已经在这里
2011 年测验 2
Q8: 一个“占领北桥”抗议者建立了一个 Twitter 账户以假名广播消息。为了保持匿名,他决定使用 Tor 登录该账户。他从可信来源安装了 Tor 并启用了它,启动 Firefox,输入 www.twitter.com 到浏览器中,然后继续登录。由于他使用 Tor,现在可能有哪些对手能够以某种方式危害抗议者?忽略 Tor 客户端本身的安全漏洞。
A8: 抗议者容易受到恶意出口节点拦截他的非 HTTPS 保护连接的影响。(由于 Tor 明确涉及通过出口节点代理,这比拦截公共互联网上的 HTTP 更容易。)
Q9: 抗议者现在使用相同的 Firefox 浏览器连接到另一个托管讨论论坛的网站,也通过 Tor 连接(但只在建立新的 Tor 电路后)。他的目标是确保 Twitter 和论坛不能勾结以确定同一人访问了 Twitter 和论坛。为了避免第三方跟踪,他在访问不同网站之间从浏览器中删除所有 cookie、HTML5 客户端存储、历史记录等。在没有软件漏洞和大量其他流量的情况下,对手如何能够相关他最初访问 Twitter 和他访问论坛,假设没有软件漏洞,以及大量其他流量到两个网站?
A9: 对手可以通过用户代理字符串、浏览器上安装的插件、窗口尺寸等对抗议者的浏览器进行指纹识别,这可能足以强烈相关这两次访问。
2012 年测验 2
Q2:Alyssa 想要了解在 Tor 上运行的隐藏服务的身份。她计划设置一个恶意的 Tor OR,设置一个在该恶意 Tor OR 上的会合点,并将这个会合点的地址发送给隐藏服务的介绍点。然后,当隐藏服务连接到恶意的会合点时,恶意的 Tor OR 将记录连接来自何处。
Alyssa 的计划会奏效吗?为什么会或者为什么不会?
A2:不会奏效。一个新的 Tor 电路被构建在
6.858 测验 2 复习
医疗设备安全
FDA 标准:如 Semmelweis 所说 =>
应该洗手
除颤器:
-
2003 年:植入式除颤器使用 WiFi。可能出现什么问题?
-
内部:电池,无线电,密封
为什么无线?
- 旧方法:在手臂上插入针来扭转拨号,感染风险 😦
Q: 无线安全风险是什么?
-
不安全的做法 - 实施错误。
-
制造商和用户设备体验(MAUDE)数据库
-
死因:输液泵缓冲区溢出。
-
检测到错误,但进入安全模式,关闭泵。
-
患者因脑压增加而死亡,因为没有泵,因为缓冲区溢出。
-
人为因素和软件
为什么独特?
500 多人死亡
例如,用于向患者提供剂量的用户界面未正确指示它是期望小时还是分钟作为输入(hh:mm:ss)。导致数量级错误:20 分钟与预期的 20 小时相比。
管理问题
医疗设备也需要进行软件更新。
例如,McAffee 将 DLL 分类为恶意,隔离,搞乱了医院服务。
例如,使用 Windows XP 的医院:- Microsoft 不再为 XP 提供安全更新,但仍然有新的医疗产品使用 Windows XP。
FDA 网络安全指南
制造商预期看到什么?他们如何考虑安全问题/风险/缓解策略/残余风险?
对手的东西
除颤器和植入物
这节笔记部分涉及 Kevin Fu 讲座中对植入式除颤器攻击的讨论。在他给出的一个例子中,植入式设备通过另一个称为“魔杖”的设备进行无线编程,该设备使用专有(非公开,非标准化)协议。此外,魔杖在特许的电磁频谱上传输(设备侦听),而不是 WiFI 或蓝牙。接下来的两行描述了除颤器如何植入患者的手术过程。
-
设备通过魔杖编程,使用专有协议在特许频谱上进行通信。(就安全性而言是个好主意吗?)
-
患者清醒但麻木和镇静
-
六个人通过血管穿过电极…
-
患者被给予一个基站,看起来像 AP,与植入物进行专有 RF 通信,数据通过互联网发送到医疗公司
-
设备和程序员之间的通信:没有加密/认证,数据以明文发送
-
设备存储:患者姓名,出生日期,制造和型号,序列号,更多…
-
??? 使用软件无线电(USRP/GNU Radio Software)
Q: 你能通过无线方式诱发致命的心律吗?
A: 是的。设备在 1 毫秒内发出 500V 的电击。例如,被马踢在胸部。
设备通过软件更新修复?
医疗保健提供者
“被困在 Windows XP 的医院”截图:医院中有 600 台 Service Pack 0 Windows XP 设备!
医疗设备感染的平均时间:- 无保护 12 天 - 有防病毒软件 1 年
供应商是感染的常见来源
USB 驱动器是感染的常见途径。
下载上的医疗设备签名。
“点击这里下载软件更新”
-
网站似乎包含恶意软件。
-
Chrome:安全的网络浏览服务检测到"呼吸机"恶意软件。
"药物混合器"示例:
-
运行 Windows XP 嵌入式。
-
FDA 期望制造商保持软件更新。
-
制造商声称无法更新是因为 FDA
- double you tea f?
有意的恶意软件故障有多重要?
例如 1:芝加哥 1982 年:有人在泰诺中投入氰化物 例如 2:有人在癫痫支持小组网站上发布了闪烁图像。
为什么要相信传感器?
例如智能手机。无电池传感器演示。在 MSP430 上运行。微控制器认为来自 ADC 到微控制器的任何东西都是真实的。可能与导线的谐振频率有关的事情?
将干扰注入基带。
-
在模拟中很难过滤。
-
=>
有干扰的高质量音频比麦克风更好。
发送与导线的谐振频率匹配的信号。
将电路视为无意的解调器。
-
可以使用高频信号欺骗微控制器以为。
-
由于知道微控制器的中断频率和相关属性,存在低频信号。
心脏设备容易受到基带电磁干扰的影响。
- 在基带中插入有意的电磁干扰。
发送脉冲正弦波以欺骗除颤器以为心脏正常跳动。
-
??? 在体外有效。
-
在体内或盐水溶液中难以复制。
有任何防御措施吗?
-
在一个心跳之后发送额外的起搏脉冲。
- 一个真实的心脏不应该发送响应。
在电源插座上检测恶意软件。
嵌入式系统 <-->
WattsUpDoc <-->
电源插座。
比安全性更大的问题?
Q: 真或假:黑客入侵医疗设备是目前最大的风险。
A: 错误。患者护理和医疗传感器的广泛不可用性更为重要。
安全性不能被简单添加。
-
例如在 Windows 95 上进行 MRI。
-
例如运行在 OS/2 上的起搏器程序员。
在医疗设备等上检查 gmail。
在医疗设备上运行 pandora。
保持临床工作流程可预测。
Tor
资源
概述
-
目标
-
机制
-
流 / 电路
-
会合点 & 隐藏服务
-
-
目录服务器
-
攻击 & 防御
-
练习问题
目标
-
匿名通信
-
响应者匿名性
- 如果我运行像 “mylittleponey.com” 这样的服务,我不希望任何人将我与该服务关联起来
-
部署性 / 可用性
-
为什么是安全目标?
-
因为它增加了使用 Tor 的人数,即 匿名集
-
…从而增加安全性
- (对手有更多人可以区分你)
-
-
-
TCP 层 (为什么? 请参见上面的讲座笔记中的解释)
-
不是 P2P (因为更容易受攻击?)
电路创建
TODO: 定义电路
Alice 将许多 TCP 流多路复用到几个 电路 上。为什么? 低延迟系统,制作新电路昂贵。
TODO: 定义洋葱路由器 (OR)
目录服务器: 网络状态, OR 公钥, OR IPs
ORs:
-
所有通过 TLS 连接在一起
-
参见博客文章 1: 权威机构对共识目录文档进行投票
例子:
[ Draw example of Alice building a new circuit ]
[ and connecting to Twitter. ]
会合点 & 隐藏服务
例子:
[ Add an example of Alice connecting to Bob's ]
[ hidden service on Tor ]
Bob 运行隐藏服务 (HS):
-
决定长期 PK/SK 对
-
发布介绍点,广告在查找服务上
-
构建到 介绍点 的电路,等待消息
Alice 想要连接到 Bob 的 HS:
-
构建到新的 会合点 (RP) 的电路 (任何 OR)
- 给 RP cookie
-
构建到 Bob 的一个介绍点的电路并发送消息
- with
{RP, Cookie, g^x}_PK(Bob)
- with
-
Bob 构建到 RP 的电路,发送
{ cookie, g^y, H(K)}
-
RP 连接 Alice 和 Bob