沃通(WoSign)数字证书
EmailGoogleTwitterFacebook

http和https有什么不同?

什么是 HTTPS? HTTPS (是 HTTP over SSL,表示基于安全套接字层的超文本传输协议 ) 是一个 Netscape 开发的 Web 加密传输协议。 你也可以说:HTTPS = HTTP + SSL HTTPS 在 HTTP 应用层的基础上使用安全套接字层作为子层。   为什么需要 HTTPS : 超文本传输协议 (HTTP) 是一个用来通过互联网传输和接收信息的协议。HTTP 使用请求/响应的过程,因此信息可在服务器间快速、轻松而且精确的进行传输。当你访问 Web 页面的时候你就是在使用 HTTP 协议,但 HTTP 是不安全的,因其采用明文传输方式,黑客可以轻松窃听你跟 Web 服务器之间的数据传输。在很多情况下,客户和服务器之间传输的是敏感信息,需要防止未经授权的访问。为了满足这个要求,网景公司(Netscape)推出了 HTTPS协议。   HTTP 和 HTTPS 的相同点: 大多数情况下,HTTP 和 HTTPS 是相同的,因为都是采用同一个基础的协议,作为 HTTP 或 HTTPS 客户端——浏览器,设立一个连接到 Web 服务器指定的端口。当服务器接收到请求,它会返回一个状态码以及消息,这个回应可能是请求信息、或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式,因此资源可以被唯一指定。   HTTP 和 HTTPS 的不同之处: 1. HTTP 的 URL 以 http:// 开头,而 HTTPS 的 URL 以 https:// 开头 2. HTTP 是不安全的,而 HTTPS 是安全的 3. HTTP 标准端口是 80 ,而 HTTPS 的标准端口是 443 4. 在 OSI 网络模型中,HTTP 工作于应用层,而 HTTPS 工作在传输层 5. HTTP 无法加密,而 HTTPS 对传输的数据进行加密 6. HTTP 无需证书,而 HTTPS 需要认证证书(SSL证书)   HTTPS 如何工作? 如果要使用 HTTPS 连接,那服务器必须有公钥和签名的证书(SSL证书)。 当使用 https 连接,服务器响应初始连接,并提供它所支持的加密方法。作为回应,客户端选择一个连接方法,并且客户端和服务器端交换证书验证彼此身份。完成之后,在确保使用相同密钥的情况下传输加密信息,然后关闭连接。为了提供 https 连接支持,服务器必须有一个SSL证书,该证书包含经过第三方权威CA机构认证的密钥信息,通过CA认证保证证书是安全的。   HTTP 包含如下动作: 1. 浏览器打开一个 TCP 连接 2. 浏览器发送 HTTP

Read More…

SSL 3.0 Poodle漏洞修复方法

谷歌今天披露了一个存在于 SSL 3.0 版本当中的安全漏洞。 详细信息请访问: https://www.openssl.org/~bodo/ssl-poodle.pdf   什么是SSL3.0 Poodle漏洞? SSL协议由美国 NetScape公司开发的, 1996年发布了V3.0版本。SSL 3.0 已经存在 15 年之久,目前绝大多数浏览器都支持该版本。通常用户的浏览器都使用新版本的安全协议与服务器进行连接,为了保持兼容性,当浏览器安全协议连接失败的时候,就会转而尝试老版本的安全协议进行连接,其中就包括SSL 3.0。 Poodle攻击的原理,就是黑客故意制造安全协议连接失败的情况,触发浏览器的降级使用 SSL 3.0,然后使用特殊的手段,从 SSL 3.0 覆盖的安全连接下提取到一定字节长度的隐私信息。 如何防范SSL3.0-Poodle漏洞? 建议您手动关闭客户端SSLv3支持;或者关闭服务器SSLv3支持;或者两者全部关闭,即可有效防范Poodle漏洞对您造成的影响。   关闭服务器SSLv3支持:   Nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256 SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE RSA-AES128-SHA:RC4-SHA:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!DSS:!PKS; ssl_session_timeout 5m; ssl_session_cache builtin:1000 shared:SSL:10m;   Apache: SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256 SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE RSA-AES128-SHA:RC4-SHA:!aNULL:!MD5:!DSS   关闭客户端SSLv3支持:   谷歌已表示chorme浏览器已经通过技术手段屏蔽浏览器自动降级至SSL3.0链接。手动关闭掉 SSL 3.0 支持的方法。 Windows 用户: 1)完全关闭 Chrome 浏览器 2)复制一个平时打开 Chrome 浏览器的快捷方式 3)在新的快捷方式上右键点击,进入属性 4)在「目标」后面的空格中字段的末尾输入以下命令 –ssl-version-min=tls1 Mac OS X 用户: 1)完全关闭 Chrome 浏览器 2)找到本机自带的终端(Terminal) 3)输入以下命令:/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome –ssl-version-min=tls1 Linux 用户: 1)完全关闭 Chrome 浏览器 2)在终端中输入以下命令:google-chrome—ssl-version-min=tls1 Firefox 浏览器用户可以进入关于:设置,方法是在地址栏输入 about:config,然后将 security.tls.version.min 调至 1。   设置方法引用自http://www.wosign.com/news/SSLv3-Poodle.htm  

SSL 3.0 Poodle漏洞修复方法

  我们刚刚从 OpenSSL官网了解一个存在于 SSL 3.0 版本当中的安全漏洞,请广大用户注意!详细信息请访问: https://www.openssl.org/~bodo/ssl-poodle.pdf   什么是SSL3.0 Poodle漏洞? SSL协议由美国 NetScape公司开发的, 1996年发布了V3.0版本。SSL 3.0 已经存在 15 年之久,目前绝大多数浏览器都支持该版本。通常用户的浏览器都使用新版本的安全协议与服务器进行连接,但如果遇到 bug 导致连接失败,就会转而尝试更老版本的安全协议进行连接,「更老版本」就包括SSL 3.0。 Poodle攻击的原理,就是黑客故意制造安全协议连接失败的情况,触发浏览器的降级使用 SSL 3.0,然后使用特殊的手段,从 SSL 3.0 覆盖的安全连接下提取到一定字节长度的隐私信息。 沃通的SSL证书和SSL3.0漏洞有关系吗? 沃通(WoSign) SSL证书产品非常安全,和SSL3.0漏洞毫无关系。   如何防范SSL3.0-Poodle漏洞? 沃通(WoSign)建议您手动关闭客户端SSLv3支持;或者关闭服务器SSLv3支持;或者两者全部关闭,即可有效防范Poodle漏洞对您造成的影响。   关闭服务器SSLv3支持:   Nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256 SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE RSA-AES128-SHA:RC4-SHA:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!DSS:!PKS; ssl_session_timeout 5m; ssl_session_cache builtin:1000 shared:SSL:10m;   Apache: SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256 SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE RSA-AES128-SHA:RC4-SHA:!aNULL:!MD5:!DSS   关闭客户端SSLv3支持:   谷歌已表示chorme浏览器已经通过技术手段屏蔽浏览器自动降级至SSL3.0链接。手动关闭掉 SSL 3.0 支持的方法。 Windows 用户: 1)完全关闭 Chrome 浏览器 2)复制一个平时打开 Chrome 浏览器的快捷方式 3)在新的快捷方式上右键点击,进入属性 4)在「目标」后面的空格中字段的末尾输入以下命令 –ssl-version-min=tls1 Mac OS X 用户: 1)完全关闭 Chrome 浏览器 2)找到本机自带的终端(Terminal) 3)输入以下命令:/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome –ssl-version-min=tls1 Linux 用户: 1)完全关闭 Chrome 浏览器 2)在终端中输入以下命令:google-chrome—ssl-version-min=tls1 Firefox 浏览器用户可以进入关于:设置,方法是在地址栏输入 about:config,然后将 security.tls.version.min 调至 1。        

HTTPS 能否避免流量劫持?

近日,看了一篇关于流量劫持的文章《安全科普:流量劫持能有多大危害?》,作者EtherDream以图文并茂的形式详细讲解了流量劫持及相关知识。“在如今这个讲究跨平台、体验好,并有云端支持的年代,WebApp 越来越火热。各种应用纷纷移植成网页版,一些甚至替代了客户端。同时,也造就了流量劫持前所未有的势头。”小编总结,这里提到的流量劫持危害,大多跟Http明文传输协议的薄弱有关系。   我们来看看流量劫持会带来什么危害? 不同的劫持方式,获得的流量也有所差异。DNS 劫持,只能截获通过域名发起的流量,直接使用 IP 地址的通信则不受影响;CDN 入侵,只有浏览网页或下载时才有风险,其他场合则毫无问题;而网关被劫持,用户所有流量都难逃魔掌。   1、http易致在线应用被劫持 网页技术在近些年里有了很大的发展,但其底层协议始终没有太大的改进 —— HTTP,一种使用了 20 多年古老协议。在 HTTP 里,一切都是明文传输的,流量在途中可随心所欲的被控制。而在线使用的 WebApp,流量里既有通信数据,又有程序的界面和代码,劫持简直轻而易举。因此,劫持网页流量成了各路黑客们的钟爱,一种可在任意网页发起 XSS 的入侵方式。 2、公共场合使用http,不登陆也会被劫持 在自己的设备上,大家都会记住各种账号的登录状态,反正只有自己用,也没什么大不了的。然而,在被劫持的网络里,即使浏览再平常不过的网页,或许一个悄无声息的间谍脚本已暗藏其中,正偷偷访问你那登录着的网页,操控起你的账号了。 3、http状态下,Cookie 记录或浏览器自动填表单,都会导致账号密码被截获 http状态下,cookie记录的都是明文的账号密码,被劫持泄露后,即使数量不多,也能通过社工获取到用户的更多信息,最终导致更严重的泄露。 4、HTTP 缓存投毒 HTTP这种简单的纯文本协议,几乎没有一种签名机制,来验证内容的真实性。即使页面被篡改了,浏览器也完全无法得知,甚至连同注入的脚本也一块缓存起来。但凡具备可执行的资源,都可以通过预加载带毒的版本,将其提前缓存起来。 5、Https能避免劫持吗? 能!但前提是必须用受信任的SSL证书。 不同于简单的Http代理,HTTPS 服务需要权威CA机构颁发的SSL证书才算有效。自签证书浏览器不认,而且会给予严重的警告提示。而遇到“此网站安全证书存在问题”的警告时,大多用户不明白是什么情况,就点了继续,导致允许了黑客的伪证书,HTTPS 流量因此遭到劫持。 如果重要的账户网站遇到这种情况,无论如何都不该点击继续,否则大门钥匙或许就落入黑客之手。 偷换证书 这里所说的权威CA机构是指已经通过WebTrust国际认证,根证书由微软预置,受微软等各类操作系统、主流移动设备和浏览器信任的CA机构;在中国还要附加一项,就是要拿到工信部许可的CA牌照;这样的CA机构,才有权利签发各类数字证书。 自签证书是指不受信任的任意机构或个人,自己随意签发的证书,容易被黑客伪造替换。   6、全站Https的重要性 情况一:从http页面跳转访问https页面 事实上,在 PC 端上网很少有直接进入 HTTPS 网站的。例如支付宝网站,大多是从淘宝跳转过来,而淘宝使用的仍是不安全的 HTTP 协议。如果在淘宝网的页面里注入 XSS,屏蔽跳转到 HTTPS 的页面访问,用 HTTP 取而代之,那么用户也就永远无法进入安全站点了。 尽管地址栏里没有出现 HTTPS 的字样,但域名看起来也是正确的,大多用户都会认为不是钓鱼网站,因此也就忽视了。 因此,只要入口页是不安全的,那么之后的页面再安全也无济于事。   情况二:http页面重定向到https页面 有一些用户通过输网址访问的,他们输入了 www.alipaly.com 就敲回车进入了。然而,浏览器并不知道这是一个 HTTPS 的站点,于是使用默认的 HTTP 去访问。不过这个 HTTP 版的支付宝的确也存在,其唯一功能就是重定向到自己 HTTPS 站点上。 劫持流量的中间人一旦发现有重定向到 HTTPS 站点的,于是拦下重定向的命令,自己去获取重定向后的站点内容,然后再回复给用户。于是,用户始终都是在 HTTP 站点上访问,自然就可以无限劫持了。 国外各大知名网站(PayPal,Twitter,Facebook,Gmail,Hotmail等)技术措施来保证用户机密信息和交易安全,防止会话攻击和中间人攻击。   7、搜索引擎劫持 事实上,HTTPS 站点还有个很大的来源 —— 搜索引擎。遗憾的是,国产搜索引擎几乎都不提供 HTTPS 服务。 谷歌已开始提供https加密搜索方式。Google在官方博客介绍说,普通的HTTP浏览是不安全的,用户和服务器之间的通讯会被第三方监听和干扰,对于Google来说,你在Google搜索的词语会被第三方截获,如果第三方不希望你在Google搜索这个词语,还可以通过技术手段阻止用户的搜索行为。使用HTTPS的Google搜索中,用户搜索的信息将无法被第三方获取,也不会出现数据泄漏的问题,搜索结果页面也不会被干扰或篡改。     结语 从上面的各类劫持案例中,我们可以看出,Https是很有效的流量劫持防范措施,无论是网络服务提供商还是广大网民,为咱自己的帐户安全和权益,都要形成使用https访问网站的习惯和意识,重要的网站必定使用 HTTPS 协议,登陆时需格外留意!

安全科普:浮窗登录框的隐患

传统的登录框 在之前的文章流量劫持危害详细讲解了 HTTP 的高危性,以至于重要的操作都使用 HTTPS 协议,来保障流量在途中的安全。 这是最经典的登录模式。尽管主页面并没有开启 HTTPS,但登录时会跳转到一个安全页面来进行,所以整个过程仍是比较安全的 —— 至少在登录页面是安全的。 对于这种安全页面的登录模式,黑客硬要下手仍是有办法的。在之前的文章里也列举了几种最常用的方法:拦截 HTTPS 向下转型、伪造证书、跳转钓鱼网站。 其中转型 HTTPS 的手段最为先进,甚至一些安全意识较强的用户也时有疏忽。 然而,用户的意识和知识总是在不断提升的。尤其在如今各种网上交易的时代,安全常识广泛普及,用户在账号登录时会格外留心,就像过马路时那样变得小心翼翼。 久而久之,用户的火眼金睛一扫地址栏即可识别破绽。 因此,这种传统的登录模式,仍具备一定的安全性,至少能给用户提供识别真假的机会。 华丽的登录框 不知从何时起,人们开始热衷在网页里模仿传统应用程序的界面。无论控件、窗口还是交互体验,纷纷向着本地程序靠拢,效果越做越绚。 然而华丽的背后,其本质仍是一个网页,自然掩盖不了网页的安全缺陷。 当网页特效蔓延到一些重要数据的交互 —— 例如账号登录时,风险也随之产生。因为它改变了用户的使用习惯,同时也彻底颠覆了传统的意识。 乍一看,似乎也没什么问题。虽然未使用登录页跳转,但数据仍通过 HTTPS 传输,途中还是无法被截获。 HTTP 页面用 HTTPS 有意义吗? 如果认为这类登录框没什么大问题,显然还没领悟到『流量劫持』的精髓 —— 流量不是单向的,而是有进也有出。 能捕获你『出流量』的黑客,大多也有办法控制你的『入流量』。这在流量劫持第一篇里也详细列举了。 使用 HTTPS 确实能保障通信的安全。但在这个场合里,它只能保障『发送』的数据,对于『接收』的流量,则完全不在其保护范围内。 因为整个登录框都当作『虚拟窗口』嵌套在主页面里的,因此其中的一切都在同个页面环境里。而主页面使用的仍是不安全的 HTTP 协议,所以注入的 XSS 代码能轻而易举的控制登录框。 当然,或许你会说这只是设计缺陷。若是直接嵌入 HTTPS 登录页的 iframe 框架,那就会因同源策略而无法被 XSS 控制了。 这样的改进确实能提高一些安全性,但也只是略微的。既然我们能控制主页面,里面显示什么内容完全可以由 XSS 说了算。不论什么登录框、框架页,甚至安全插件,我们都可以将其删除,用看起来完全相同的文本框代替。得到账号后,通过后台反向代理实现登录,然后通知前端脚本伪造一个登录成功的界面。 所以,HTTPS 被用在 HTTP 页面里,意义就大幅下降了。 和『缓存投毒』配合出击 在流量劫持第二篇里提到『HTTP 缓存投毒』这一概念,只要流量暂时性的被劫持,都可导致缓存长期感染。但这种攻击有个前提,必须事先找到站点下较稳定的脚本资源,做投毒的对象。 传统登录 在传统的登录模式里,缓存投毒非常难以利用: HTTPS 资源显然无法被感染。 而使用 HTTPS 向下转型的方案,也会因为离开劫持环境,而无法访问中间人的 HTTP 版登陆页面,导致缓存失效;或者这个真实的 HTTP 版的登录页面根本就不接受你的本地缓存,直接重定向到正常的 HTTPS 页面。 因此只有在主页面上,修改链接地址,让用户跳转到钓鱼网站去登录,才能勉强利用。 浮层登录 制作一个精良的浮层登录框,需要不少的界面代码,所以经常引用 jQuery 这类通用脚本库。而这些脚本往往是长久不会修改的,因此是缓存投毒的绝好原料。 所以,浮层登录框的存在,让『缓存投毒』有了绝佳的用武之地。 再之前的文章 WiFi流量劫持 —— JS脚本缓存投毒,演示了如何利用 www.163.com 下的某个长缓存脚本进行投毒,最终利用网易的浮层登录框获取账号。尽管网易也使用 HTTPS 传输账号数据,但在流量攻击面前不堪一击。 尽管这种登录模式风险重重,但最近百度也升级成浮层登录框,并且还是所有产品。所以,我们再次尝试那套的古老方法,看看在如今是否仍能发起攻击。 我们选几个最常用的产品线,进行一次缓存扫描: 果然,每个产品线里都有长期未修改、并且缓存很久的脚本库。 接着开启我们的钓鱼热点,让前来连接的用户,访问任何一个页面都能中毒。 为了让钓鱼热点更隐蔽,这次我们不再使用路由器,而是利用报废的安卓手机(下一篇文章详细讲解如何实现)。 为了不影响附近办公,本文就不演示同名热点钓鱼了,所以随便取了个名字。 接着让『受害者』来连一下我们的热点: 之前正好开着网页,所以很快收到了 HTTP 请求。我们在任何网页里注入 XSS,进行缓存投毒。 (由于原理和之前讲一样,所以这里就省略步骤了) 然后重启电脑,连上正常的 WiFi(模拟用户回到安全的场合)。 打开 tiebai.baidu.com,一切正常。 开始登录了 看看这种浮层登录框,能否躲避我们的从沉睡中唤起的 XSS 脚本: 奇迹依然发生! 由于之前有过详细的原理讲解,因此这里就不再累述了。不过在实战中,缓存投毒+非安全页面登录框,是批量获取明文账号的最理想手段。 不可逆的记忆 如果现在再将登录模式换回传统的,还来得及吗?显然,为时已晚。 当网站第一次从传统登录,升级到浮层登录时,用户大多不会立即输入,而是『欣赏』下这个新版本的创意。确认不是病毒广告弹出的窗口,而是真的官方设计的,才开始登录。 当用户多次使用浮层登录框之后,慢慢也就接受了这种新模式。 即使未来,网站取消了浮层登录,黑客使用 XSS 创建一个类似的浮层,用户仍会毫不犹豫的输入账号。因为在他们的记忆里,官方就曾使用过,仍然对其保留着对其信任度。 安全性升级 既然这个过程是不可逆的,撤回传统模式意义也不大。事实上,使用浮层的用户体验还是不错的,对于不了解安全性的用户来说,还是喜欢华丽的界面。 要保留体验,又得考虑安全性,最好的解决方案就是将所有的页面都使用 HTTPS,将站点武装到牙齿,不留一丝安全缝隙。这也是未来网站的趋势。 参考信息来源:traffic-hijack-danger-dialog

安全科普:流量劫持的方式和途径

流量劫持,这种古老的攻击沉寂了一段时间后,最近又开始闹的沸沸扬扬。众多知名品牌的路由器相继爆出存在安全漏洞,引来国内媒体纷纷报道。只要用户没改默认密码,打开一个网页甚至帖子,路由器配置就会被暗中修改。互联网一夜间变得岌岌可危。 攻击还是那几种攻击,报道仍是那千篇一律的砖家提醒,以至于大家都麻木了。早已见惯运营商的各种劫持,频繁的广告弹窗,大家也无可奈何。这么多年也没出现过什么损失,也就睁只眼闭只眼。 事实上,仅仅被运营商劫持算是比较幸运了。相比隐匿在暗中的神秘黑客,运营商作为公众企业还是得守法的,广告劫持虽无节操但还是有底线的。这不,能让你看见广告了,也算是在提醒你,当前网络存在被劫持的风险,得留点神;相反,一切看似风平浪静毫无异常,或许已有一个天大的间谍潜伏在网络里,随时等你上钩 —— 这可不是弹广告那样简单,而是要谋财盗号了! 我会被劫持吗? 不少人存在一个错误的观点:只有那些安全意识薄弱的才会被入侵。只要装了各种专业的防火墙,系统补丁及时更新,所有的密码都很复杂,劫持肯定是轮不到我了。 的确,安全意识强的自然不容易被入侵,但那只对传统的病毒木马而已。而在流量劫持面前,几乎是人人平等的。网络安全与传统的系统安全不同,网络是各种硬件设备组合的整体,木桶效应尤为明显。即使有神一样的系统,但遇到猪一样的设备,你的安全等级瞬间就被拉低了。现在越来越流行便宜的小路由,它们可是承载着各种网上交易的流量,你能放心使用吗? 即使你相信系统和设备都绝对可靠,就能高枕无忧了吗?事实上有问题的设备并不多,但出问题的事却不少,难道其中还存在什么缺陷?没错,还遗漏了最重要的一点:网络环境。 如果网络环境里有黑客潜伏着,即使有足够专业的技术,是在所难逃了,敌暗我明,稍不留神就会落入圈套。 当然,苍蝇不叮无缝的蛋。有哪些隐患导致你的网络环境出现了裂缝?太多了,从古到今流行过的攻击方式数不胜数。甚至可以根据实际环境,自己创造一种。 现在回忆下尝试过的劫持案例。 上古时代: Hub 嗅探 MAC 欺骗 MAC 冲刷 ARP 攻击 DHCP 钓鱼 DNS 劫持 CDN 入侵 中世纪: 路由器弱口令路由器 CSRF PPPoE 钓鱼蜜罐代理 工业时代: WiFi 弱口令WiFi 伪热点WiFi 强制断线 WLAN 基站钓鱼 Hub 嗅探 集线器(Hub)这种设备如今早已销声匿迹了,即使在十年前也少有人用。作为早期的网络设备,它唯一的功能就是广播数据包:把一个接口的收到的数据包群发到所有接口上。且不吐槽那小得惊人的带宽,光是这转发规则就是多么的不合理。任何人能收到整个网络环境的数据,隐私安全可想而知。 嗅探器成了那个时代的顶尖利器。只要配置好过滤器,不多久就能捕捉到各种明文数据,用户却没有任何防御对策。 防范措施:还在用的赶紧扔了吧。 这种设备目前唯一可用之处就是旁路嗅探。利用广播的特性,可以非常方便分析其他设备的通信,例如抓取机顶盒的数据包而不影响正常通信。 MAC 欺骗 交换机的出现逐渐淘汰了集线器。交换机会绑定 MAC 地址和接口,数据包最终只发往一个终端。因此只要事先配置好 MAC 对应的接口,理论上非常安全了。 不过,很少有人会那么做,大多为了偷懒,直接使用了设备默认的模式 —— 自动学习。设备根据某个接口发出的包,自动关联该包的源地址到此接口。 然而这种学习并不智能,甚至太过死板,任何一个道听途说都会当作真理。用户发送一个自定义源 MAC 地址的包是非常容易的,因此交换机成了非常容易被忽悠的对象。只要伪造一个源地址,就能将这个地址关联到自己的接口上,以此获得受害者的流量。 不过,受害者接着再发出一个包,绑定关系又恢复原先正常的。因此只要比谁发的频繁,谁就能竞争到这个 MAC 地址的接收权。如果伪造的是网关地址,交换机就误以为网关电缆插到你接口上,网络环境里的出站流量瞬间都到了你这里。 当然,除非你有其他出站渠道,可以将窃取的数据代理出去;否则就别想再转发给被你打垮的真网关了,被劫持的用户也就没法上外网。所以这招危害性不是很大,但破坏性很强,可以瞬间集体断网。 防范措施:机器固定的网络尽量绑定 MAC 和接口吧。貌似大多数网吧都绑定了 MAC 和接口,极大增强了链路层的安全性。同时,独立的子网段尽可能划分 VLAN,避免过大的广播环境。大学里见过千人以上还不划分 VLAN 的,用一根短路网线就可以毁掉整个网络。 MAC 冲刷 之前说了集线器和交换机的转发区别。如果交换机发现一个暂时还未学习到的 MAC 地址,将会把数据包送往何处呢?为了不丢包,只能是广播到所有接口。 如果能让交换机的学习功能失效,那就退化成一个集线器了。由于交换机的硬件配置有限,显然不可能无限多的记录地址对应条目。我们不停伪造不重复的源地址,交换机里的记录表很快就会填满,甚至覆盖原有的学习记录,用户的数据包无法正常转发,只能广播到所有接口上了。 防范措施:还是 MAC 和接口绑定。一旦绑定,该接口只允许固定的源地址,伪造的自然就失效了。当然,好一点的交换机都有些策略,不会让一个接口关联过多的 MAC 地址。 曾经在家试过一次,捕捉到小区内用户上网的流量。不过伪造包发的太快,~15万包/秒,更致命的是发错目标地址,发到城域网准入服务器上,导致工作人员切断了整个小区半天的网络… 所以必须得选一个 VLAN 内的、并且实际存在的地址做为目标 MAC,以免产生大量的数据风暴。 ARP 攻击 这种攻击大家几乎都听出老茧了,即使不懂电脑的人也知道装个 ARP 防火墙保平安,其危害之大可想而知。 简单的说,ARP 就是广播查询某个 IP 对应的 MAC 地址,在用这个 IP 的人回个声。知道这个 IP 对应的 MAC 地址,就可以链路通信了(链路层只能通过MAC地址通信)。如果有人冒充回复,并抢在正常人之前,伪造的答案也就先入为主。IP 被解析到错误的地址上,之后所有的通信都被劫持了。 事实上,早期的系统还有个更严重的BUG:直接给用户发送一个 ARP 回复包,即使对方从没请求过,系统也会接受这个回复,并提前保存里面的记录。这种基于缓存的投毒,让劫持成功率更上一层楼。 防范措施:由于这种攻击太过泛滥,以至大部分路由器都带了防 ARP 攻击的功能。客户端的 ARP 防火墙也数不胜数,似乎成了安全软件的标配。当然,系统也支持强制绑定 IP 与 MAC 的对应,必要时可以使用。 很多教程都是用 Wireshark 来演示,事实上当年有一款叫 Iris 的软件非常好用,可以修改封包再次发送,用它可以很容易搞明白各种攻击的原理。不过N年没更新了还不支持64位的。 DHCP 钓鱼 现实中,并不是每个人都会配置网络参数,或者出于方便,让网络系统自动配置。出于这个目的,DHCP 服务诞生了。 由于没有配置IP地址、网关、DNS 等,在网络上是寸步难行的,因此首先需要从 DHCP 那获得这些。然而,既然连 IP 地址都没有,那又是如何通信的?显然,只能发到广播地址(255.255.255.255)上,而自己则暂时使用无效的IP地址(0.0.0.0)。(事实上,链路层的通信只要有 MAC 地址就行,IP 地址已属于网络层了,但 DHCP 由于某些特殊需要使用的是 UDP 协议)

Read More…

安全科普:流量劫持能有多大危害?

上一篇文章,介绍了常见的流量劫持途径。然而无论用何种方式获得流量,只有加以利用才能发挥作用。 不同的劫持方式,获得的流量也有所差异。DNS 劫持,只能截获通过域名发起的流量,直接使用 IP 地址的通信则不受影响;CDN 入侵,只有浏览网页或下载时才有风险,其他场合则毫无问题;而网关被劫持,用户所有流量都难逃魔掌。 在本文中,我们通过技术原理,讲解如下问题:   – 为什么喜欢劫持网页?   – 只浏览不登陆就没事吗?   – 自动填写表单有风险吗?   – 离开劫持环境还受影响吗?   – 使用 HTTPS 能否避免劫持?   – 流量劫持能否控制我电脑? 为什么喜欢劫持网页? 理论上说,劫持到用户的流量数据,也就获得相应程序的网络通信。但在现实中,数据并不代表真实内容。一些重要的网络程序,都是私有的二进制协议,以及各种加密方式。想通过流量来还原出用户的聊天信息、支付密码,几乎是不可能的。即使花费各种手段,破解出某个程序的通信协议,然而一旦程序升级改变了协议格式,或许就前功尽弃了。因此,很难找到种一劳永逸的客户端劫持方案。 然而,并非所有程序都是客户端的。一种新兴的应用模式 —— WebApp,发展是如此之快,以至于超越客户端之势。在如今这个讲究跨平台、体验好,并有云端支持的年代,WebApp 越来越火热。各种应用纷纷移植成网页版,一些甚至替代了客户端。同时,也造就了流量劫持前所未有的势头。 WebApp,其本质仍是普通的网页而已。尽管网页技术在近些年里有了很大的发展,各种新功能一再增加,但其底层协议始终没有太大的改进 —— HTTP,一种使用了 20 多年古老协议。 在 HTTP 里,一切都是明文传输的,流量在途中可随心所欲的被控制。传统程序事先已下至本地,运行时只有通信流量;而在线使用的 WebApp,流量里既有通信数据,又有程序的界面和代码,劫持简直轻而易举。 上一篇也提到,如果在户外没有 3G 信号的地方钓鱼,无法将获得的流量转发到外网。然而,使用网页这一切就迎刃而解。我们完全可以在自己的设备上搭建一个站点,留住用户发起离线攻击。对于那些连上 WiFi 能自动弹网页的设备,那就更容易入侵了。 因此,劫持网页流量成了各路黑客们的钟爱,一种可在任意网页发起 XSS 的入侵方式。 下面,开始我们的攻防之旅。 只浏览不登陆就没事吗? 每当砖家出来提醒时,总免不了这么一句:公共场合尽量不登录账号。于是,大家就认为只看网页不登陆就平安无事了。 如果是公共的电脑,那也就无所谓;否则,自己的一些账号可能就倒霉了。 在自己的设备上,大家都会记住各种账号的登录状态,反正只有自己用,也没什么大不了的。然而,在被劫持的网络里,一切皆有可能发生。即使浏览再平常不过的网页,或许一个悄无声息的间谍脚本已暗藏其中,正偷偷访问你那登录着的网页,操控起你的账号了。 听起来似乎很玄乎吧,砖家似乎也没说已登录的账号会怎么样。难道随便一个网页,就能让各种账号被控制吗? 大家都知道,HTTP 是无状态的,不像传统协议有个『会话』之类的概念。各种账号的登录状态,只能依靠浏览器的 Cookie 来实现。因此,只要有了的 Cookie 也就获得了用户账号的使用权。 和传统 XSS 攻击不同,流量劫持可以得到任何通信数据,当然也包括那些受 HttpOnly 保护的 Cookie。攻击脚本只需对某个站点发起请求,黑客即可在中途劫持到传输的 Cookie 数据。如果同时发起众多站点,就能覆盖相当一部分目标了。 这种请求未必要真正访问一次页面,仅仅将 URL 作为图片加载,将目标站点的 Cookie 送出即可。 黑客得到 Cookie,即可在自己浏览器里还原出登录状态。尽管你确实没有登录操作,但那些已登录的却能出卖你。 防范措施: 访问一些重要的网站,尽量不要记住登录状态,以免 Cookie 被泄露。不过,只要网站绑定了 Cookie 和 IP 段,这招的危害程度就大幅降低了,仅凭 HttpOnly 还是很不靠谱的。 自动填写表单有风险吗? 使用上面的方法获得 Cookie,即使能控制账号,但其密码仍无法得知,随时都有可能失去控制权。 不过,一些用户有让浏览器自动保存密码的习惯。通过这点,我们是否能套出记住的密码来呢? 分析下浏览器是如何自动填写页面表单的。其实很简单,浏览器发现页面 URL 和表单名匹配记录里的,就自动填上了。 要是在流量可控的网络里,剥离页面所有内容只剩表单,又会如何? 保存着的密码仍能自动填上,并且可被脚本访问到! 如果我们在用户访问的页面里,创建大量的隐藏框架页,即可尝试获取各种网站保存着的账号了。(不过如今 Chrome 框架页已经不会自动填写了。具体实现和浏览器有关)。 不过,即使框架页不自动填写,但主页面总得保留该功能吧。如果发现用户某个打开着的网页很久没有交互了,可悄悄跳转到如上那样的纯表单页,无论能否获取数据,都将继续跳转,一个接一个的尝试。。。直到用户切回窗口,再恢复到原先那个页面。 由于泄露的是明文的账号和密码,即使数量不多,也能通过社工获取到用户的更多信息,最终导致更严重的泄露。 防范措施: 所以无论是 Cookie 记住登录,还是浏览器自动填表,重要的账号都应慎用。 浏览器的自动填表也应增加些安全策略,例如必须有用户的交互才开始填写,规定的时间里只能填有限次。 离开劫持环境还受影响吗? 或许你在想,网络再怎么不安全,离开之后就应该没事了吧。 有时在公共场合赶上免费的 WiFi,打开网页看一会新闻,是常有的事。这么短的时间里能有多大的事。不过在入侵脚本面前,一小会和长久并没太大区别。机会只要出现了,无论多么短暂都能渗透。 如果只看重眼前利益,这种短暂的入侵并没多少利用价值;但若放远目光,能让攻击在今后发起,那就不再局限于时间和空间了。因此,我们需要一个时光机,让入侵脚本穿越到用户未来的时空运行。 若用传统 XSS 的思维,这几乎无法实现。但在流量劫持面前,一切皆有可能 —— 因为我们能控制任意流量! HTTP 缓存投毒 上一篇文章提到,但凡有缓存的地方都是大有可为的。显然,对于有着复杂的 HTTP 缓存系统来说,存在缺陷是在所难免了。这种简单的纯文本协议,几乎没有一种签名机制,来验证内容的真实性。即使页面被篡改了,浏览器也完全无法得知,甚至连同注入的脚本也一块缓存起来。 于是,我们可以将『缓存投毒』的概念,引入 HTTP 协议里。但凡具备可执行的资源,都可以通过预加载带毒的版本,将其提前缓存起来。 为了将缓存的有效期发挥到极致,我们事先在各大网站上,找出一些过期时间长、很久没有修改的资源,评估其未来变化不大的可能。 当用户打开任意一个 HTTP 网页时,注入的 XSS 代码开始预加载这些资源。由于一切流量都在控制之中,我们可以完全不走代理,而是返回自己的攻击脚本。 用户浏览器收到回复后,就将其一一缓存起来了。我们可以事先收集大量的资源地址,让用户在线的时间里,尽可能多的缓存受到感染。 未来,用户访问引用了这些资源的网站时,入侵脚本将穿越时空,从沉睡中唤醒。 只要用户不清空缓存,这些被感染的脚本始终附着在浏览器缓存里,直到用户强制刷新页面时或许才能解脱。更多细节可参考这里。 离线储存投毒 不过,有些网站使用的都是很短的缓存,上述的入侵方式似乎就无能为力了。不过,HTML5 时代带来了一项新的缓存技术 —— 离线储存。由于它没有过期时间,因此适用于任意网页的投毒! 类似的,当用户触发了我们的注入脚本之后,我们创建一个隐形的框架页,加载被感染的网页。同样,通过流量劫持,我们返回一个简单的页面,里面包含一个带有 manifest 属性的 HTML 文档,以及后期运行的脚本。 由于通过隐藏框架访问了这个页面,用户并不知情,但尽职的浏览器却将其缓存起来。 未来,用户打开被感染的网页时,浏览器直接从离线储存里取出,其中布置的脚本因此触发。 由于是个空白页面,因此需要填充上真实的网站内容。最简单的方法,就是嵌套一个原页面的框架,并在 URL 里加上随机数,确保是最新的在线内容。 因为嵌套的是同域框架,最终仍能被入侵脚本所控制。

Read More…