目录
会话令牌生成过程中的薄弱环节
1.3、令牌可预测
简述：
1、一些会话令牌并不包含与某个特定用户有关的任何有意义的数据，但由于它们包含某种顺序或模式，允许攻击者通过几个令牌样本即可推断出应用程序最近发布的其他有效令牌， 因此具有可预测性。即使推断过程需要做出大量尝试，并且成功率极低， 自动攻击工具也仍然能够利用这种缺陷在很短的时间内确定大社有效令牌
2、与定制应用程序相比， 会话管理的商业应用（如Web服务器或Web应用程序平台）中的令牌可预测漏洞更容易被发现。当向一个定制会话管理机制实施远程攻击时，攻击者所能获得的已发布令牌样本的数量可能受到服务器容量、其他用户的活动、带宽、网络延时等因素的限制。在实验室环境中，渗透测试员可以迅速建立数百万个令牌样本， 所有样本都紧密相连， 并使用了时间戳，而且可以降低其他用户造成的干扰
3、在最简单也是最容易受到攻击的情况下， 应用程序使用一个简单的连续数字作为会话令牌。这时， 攻击者只需获得两个或三个令牌样本就可以实施攻击， 并立即截获当前有效的所有令牌。
4、使用Bp lntruder循环访问一个连续会话令牌的最后两位数字， 以查找会话仍处于活动状态可被劫持的令牌值，服务器响应的长度是发现有效会话的可靠指标
示例：
应用程序令牌中可能包含更加复杂的序列，序列的变化形式可能多种多样， 可侦测的会话令牌通常来自3个方面：隐含序列、时间依赖、生成的数字随机性不强
隐含序列
对会话令牌的原始形式进行分析可能无法预测它们，但对其进行适当解码或解译就可以揭示其中包含的序列
（对多组序列进行分析）
1、除大小写混合的字母和数字字符外， 其中还有一个＋字符，可能是一个打效的Base64字符串
2、若得到字符串是乱码， 并且其中包含非打印字符（一般表示处理的是二进制数据， 而非ASCII文本）将解码后的数据以十六进制表示
3、若现在没有乱码了，但仍然没有看出明显的规律模式
4、现在就要动脑筋发现它算法了（比如，多组序列间做差等）
5、如果出现明显的规律模式，则生成令牌的算法：用前一个值加上……, 把结果截短成一个……位的数字，并对这个二进制数据进行Base64编码， 使其能够通过基于文本的HTTP协议传输。了解到这一点， 就能编写出一段脚本，生成服务器接下来产生的令牌，以及它在被截获的样本之前产生的令牌
时间依赖
一些Web服务器和应用程序使用时间作为令牌值的输入， 通过某种算法生成会话令牌。如果没有在算法中合并足够的熵，攻击者就可能推测出其他用户的令牌。虽然任何特定的令牌序列本身是完全随机的， 但如果组合生成每个令牌的时间信息，也许可以发现某种可以辨别的模式。一个忙碌的应用程序每秒会生成大量的会话， 因此实施一次自定义攻击就可以成功确定其他用户的大量令牌。
num组-num组1
num组-num组2
num组-num组3
2222222-1000000000090（举例而已）
……
每个令牌由前后两个独立的数字组成前一个数字的递增模式非常简单， 很容易推测，后一个数字的递增值每次都有所变化，计算出每个连续令牌的递增值
一般，增量都是随机的，并不包含可预测的模式。但攻击者可以通过自动攻击确定相关的数
字的一个范围， 通过蛮力攻击发现序列中的有效值等待一段时间后可截取另一组令牌序列
2222222-1000000200000（举例而已）
2222222-1000000020200
……
发现第二组之间只隔几百（可能是被他人使用）
而第二组与上面第一组截取的最后一个令牌序列，隔几万（可以猜测是否为时间依赖）
利用：
攻击者可以直接构造一个自定义攻击， 获得应用程序向其他用户发布的会话令牌
1、继续从服务器中提取紧密相连的新会话令牌
2、监控第一个数字的递增情况，如果递增值大于1 ，可知道应用程序向其他用户发布了一个令牌
3、向其他用户发布一个令牌时， 可立即知道发布时间的秒上限和下限， 因为攻击者拥有在这个令牌之前和之后发布的令牌。由于不断获得新会话令牌， 这些界限之间通常只包含几百个值
4、应用程序每次向其他用户发布一个令牌，攻击者就实施一次蛮力攻击遍历这个范围内的每个数字， 并把这个数字附加到已经发布给其他用户的第一个数字序列后面。攻击者尝试使用建立的每个令牌访问一个受保护的页面， 直到尝试取得成功， 攻破该用户的会话
5、继续运行这个自定义攻击即可截获其他所有应用程序用户的令牌。一名管理用户登录后，整个应用程序将被完全攻破
随机性不强
计算机中的数据极少完全随机。如果由于某种原因需要随机数据，一般通过软件使用各种技巧生成伪随机数字。所使用的一些算法生成行似随机并且在可能的数值范围内平均分布的序列， 但有些人只需要少数几个样本， 仍然能够准确推导出整个序列
如果使用一个可预测的伪随机数字发生器生成会话令牌， 那么得到的令牌就易于受到攻击者的攻击
Jetty是一种完全以Java编写的常用Web服务器，它为在其上运行的应用程序提供一种会话管理机制。曾经，发现这种机制易于受到会话令牌预测攻击。该服务器使用Java API java.util.Random生成会话令牌。它执行一个线性同余发生器” ，通过以下算法生成序列中的下一个数字
synchronized protected int next(int bits){
seed={seed * 0x5DEECE66DL + 0xBL) & (( 1L<< 48) - 1);
return(int)(seed >>> (48 - bits));}
这种算法实际上是用生成的最后一个数字乘以一个常数，再加上另一个常数，生成下一个数字。得到的数字被截短至48位，然后， 算法再将结果进行转换， 返回请求方要求的位数
知道算法和由它生成的一个数字后，就可以轻易推算出接下来将要生成的数字， 并且（利用一点数论知识）推导出它之前生成的数字。这意味着攻击者只需从服务器获得一个会话令牌，就可推测出所有当前和将来的会话令牌
其他非定制应用程序框架在生成会话令牌时使用极其简单或可预测的熵源， 其中许多熵源甚至可以确定。例如， PHP框架5.3.2及早期版本基于客户端的IP地址、生成令牌时的纪元时间、生成令牌时的微秒，以及线性同余发生器来生成会话令牌。虽然其中有几个未知值，但一些应用程序可以披露相关信息，从而推断出这些值。
社交网络站点可能会记录用户的登录时间和IP地址。发生器使用的种子是PHP进程启动的时间，如果攻击者对服务器进行监视， 就可以将这个位缩定在一个很小的范围内
测试随机性强度
(1)假设令牌是随机生成的。
(2)进行一系列测试， 通过每个测试观察可能具有某些特征的令牌样本（如果令牌是随机生成的）的特定属性。
(3)对于每个测试，假定以上假设是正确的， 计算观察到的特征发生的机率
(4)如果该几率在某一水平之下， 则否定上述假设， 并得出结论令牌不是随机生成的
要使用Bp Sequencer, 需要从发布希望进行测试的令牌的应用程序中找到一个响应， 如应用程序对发布包含会话令牌的新cookie的登录请求做出的响应。然后， 从Bp上下文菜单中选择“发送至sequencer”， 并在 Sequencer配置中设置令牌在响应中的位置，还可以配置各种确定如何收集令牌的选项， 然后单击“开始捕获“ (start capture)按钮， 开始收集令牌。如果已经通过其他方法（如， 通过保存某次Bp攻击的结果）获得适当的令牌样本， 则可以使用“手动加载“ (manual load)选项卡跳过令牌收集过程， 直接进入统计分析阶段
过程：
1、从第一个应用程序页面到任何登录功能，遍历应用程序， 确定其何时以及如何发布会话令牌。两种行为较为常见：只要收到未提交令牌的请求， 应用程序就会创建新会话；应用程序在成功登录后创建新会话
要想自动收集大量令牌， 最好的办法是确定一个让应用程序发布新令牌的请求（通常为GET或登录请求）
2、在Bp中， 向Bp Sequencer发送创建新会话的请求， 并配置令牌的位置。然后启动实时捕获， 收集尽可能多的令牌。如果应用程序采用了定制会话管理机制， 则只能远程访问该应用程序，可以尽可能迅速地收集令牌， 以尽量防止丢失发布给其他用户的令牌，并降低时间依赖造成的影响
3、如果应用程序采用商业会话管理机制并且或者你可以本地访问该应用程序， 则可以在受控条件下获得无数会话令牌
4、在Bp Sequencer收集令牌的同时， 启动“自动分析＂ 设置， 使Bp定期自动执行统计分析。至少收集500个令牌， 然后详细审查分析结果。如果令牌中有足够的数据位通过了测试， 继续尽可能长时间地收集令牌， 并在收集其他令牌时审查分析结果
5、如果令牌未通过随机性测试， 并且似乎包含可用于预测将来令牌的模式， 则可以从另一个IP地址、使用不同的用户名重新开始收集令牌的操作。这有助于确定是否能够发现相同的模式， 以及是否能够根据前一次操作获得的令牌进行推断， 确定后一次操作得到的令牌。
（另一个分析工具Stompy）
428
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
