Recently in Security Category

这也太不注意卫生了

| No Comments | No TrackBacks

razor 同学对于 Xcode ghost 的事情的评价是:这也太不注意卫生了。个人深以为然。

技术细节、影响等等,已经有很多大牛写过很好的文章来介绍。但是我想问的是,这事完了吗?在我看来远远没有,根据有关厂商的介绍,想要装上这个下了马的 Xcode,首先得从 App Store 以外的渠道去下载,其次还得允许运行来自 'Anywhere' 的应用程序,或者开发人员习惯于绕过系统的数字签名检查。

我看到的至少有这么两个问题:1. 开发人员常态化地使用并忽略未经签名的工具(非常不重视卫生,我认为这个事情基本上和一个厨师在上班时间去上厕所,回来工作之前不洗手是一样的性质)。2. 具有这种态度的开发人员同时拥有发布权限(管理者玩忽职守)。

我认为基本上这次出现问题的 iOS 应用开发者都应该进行特别标记,并改进其发布流程之后才允许继续发布新的应用程序。自然,每一个直接导致问题的开发者都是负有责任的,但允许这样问题出现,并在事后用公关稿文过饰非的企业及其管理者更有责任。这种攻击已经持续了数月,到底有多少不同的版本受到影响?也许只有 Apple 能够提供相关数据了。

当然,对于手机应用安全厂商来说,也许这是一次难得的商机,因为 iOS 设备用户和 Apple 之间的信任被这种攻击直接打破了。事实上,国内某前越狱团队已经制作了一款采用企业证书的扫描程序(我并不怀疑该团队提供这样的程序是出于好意,但出于谨慎,个人建议不要使用,因为我们并不知道该团队手中是否拥有更多提权漏洞,或者后续版本是否会做一些其他事情)。

对于最终用户而言,我认为现在应该做的是立即删除非必要的全部应用程序,特别是那些存疑或已经知道出现过问题,而在其公关稿中淡化问题,而没有提出对前面两个问题解决方案的开发者开发的软件,并在确认手机中没有问题应用之后重新设置全部密码。

今天搞了一个 大新闻。如果你用BIND并且今天之前没打过补丁的话,请读到这里为止,立即去补吧。

我觉得还是得提高知识水平。做 freebsd-update 补丁的时候,赫然发现修改的文件中有一个不认识的:

world|base|/usr/bin/slogin|f|0|0|0555|0|3d4103fa290ca0dcd32fc1f9775e860a4bbf4af7e2be80e835217cd560cb100e|

当时就慌了!我明明没改啥库啊?ldd看一下:

/usr/bin/slogin:
	libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800849000)
	libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800ada000)
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x800ce3000)
	libc.so.7 => /lib/libc.so.7 (0x8010da000)
	libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801482000)
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016de000)
	libz.so.6 => /lib/libz.so.6 (0x8018fe000)

还用了 Kerberos,等等,ssh?man slogin出来一个SSH的manpage,一个字没提slogin的事情。

ls -li一看才恍然大悟:

4574 -r-xr-xr-x  2 root  wheel  179000 Jul 19 00:19 /usr/bin/slogin
4574 -r-xr-xr-x  2 root  wheel  179000 Jul 19 00:19 /usr/bin/ssh

原来是马甲......

OpenBSD的spamd

| 1 Comment | No TrackBacks

许久不碰反垃圾邮件的事情了,一来前段时间垃圾邮件确实也没有那么多,加上spamassassin确实相当有效,二来也是因为犯懒。

不过,最近几天垃圾邮件明显比平时多了许多,所以决定坐下来仔细处理一下。

OpenBSD 的 spamd 是一个反垃圾邮件陷阱软件,它的主要功能是灰名单(SMTP协议要求客户端在一段时间之内重试投递),但又有一个个人很喜欢的特性:以极慢的速度回应发送垃圾邮件的服务器(默认配置为1秒一个字符,最高可以到10秒一个字符)。对发送垃圾邮件的人来说,这样做会显著地降低他们发出垃圾邮件的能力。

结构上,spamd 会修改服务器上的防火墙的转发规则中的地址,简而言之,是维持一份动态的白名单(由通过了灰名单测试的IP形成),所有不符合白名单的IP都转到 spamd 处理。如果符合白名单,则直接正常转到MTA去处理。

简单记一笔配置。

由于我的机器内存够用,所以将 spamd 配置为最大拖住1024个连接。灰名单最短等待期设置为 1 分钟,灰名单过期时间设置为 4 小时;白名单过期时间设置为 36 天。

选择的黑名单是uatraps和nixspam,各自用本地白名单做补。此外,本地另设一黑名单。

启动spamd服务并更新pf规则。接下来用:

grep 'Passed CLEAN {AcceptedInbound}' maillog* | \
cut -f3 -d[ | cut -f1 -d] | grep -v : | sort | uniq -c | \
sort -n | awk '{ if ($1 > 20) print $2; }' | sort -n | \
xargs spamdb -a

来将过去几天的 Amavisd 认为没问题的地址加入本地白名单。

最后可以用 spamdb -Ta 来添加一些陷阱地址。陷阱地址是那种故意流出,但绝不应该收到邮件的地址。

今天 John-Mark Gurney 修正了一个影响过去4个月左右的 FreeBSD -CURRENT 的随机数发生器问题,具体受影响的版本是 r273872(引入问题)到 r278907 (修正)。

由于问题只影响 -CURRENT,因此我们不会就此发表安全公告。

问题的影响:在对随机数发生器 (/dev/random)进行重构的过程中,原先为内核 arc4random(9) API 进行初始化(seeding)的部分没有正确地在新的随机数处理器上线(randomdev_init_reader)时进行配置,导致内核一直使用 dummy RNG 来生成 arc4random(9) 的种子。由于 dummy RNG 的输出范围有限(大约 2^30),导致 arc4random(9) 的输出容易预测。

由于 arc4random(9) 同时也用来在用户态代码中产生随机数种子,因此这个问题也连带影响了用户态的随机数生成(由于 arc4random(9) 在内核中被广泛使用,因此或多或少地减弱了这个问题的实际影响,但我们建议用户不要因此而产生侥幸心理)。

我们建议使用这些版本的 FreeBSD -CURRENT 的用户 立即 升级到最新的 -CURRENT,同时销毁并重新生成在这段时间内生成的全部私钥。

详情参见 Google Online Security Blog

说两个我认为比较有意思的事情:

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署,因此这类未经授权的证书本身就可以作为证据。但是,Google这样做(不公布证书)意味着签发者不得不销毁全部签发的证书,而不仅仅是被公布的那些。

第二个是 Google 在 Chrome 中限制,而不是直接删除或禁止了负有责任的根CA: India CCA 的许可范围。我认为这是远比禁止使用或删除根CA更好的做法(同样的原则也适用于几年前 Mozilla 基金会决定接纳 CNNIC 证书),原因如下:

  1. 在攻击者使用未经授权证书的同时,他们也将自己的身份(持有私钥)暴露在了阳光下,从而使检测和指证变得容易
  2. 加密通讯要比不加密好。鼓励所有人加密通讯,有助于提高攻击所需的代价。
  3. 限制使用范围削弱了CA的权力,阻止了恶意CA对用户的影响,同时对正常证书持有者的影响又不大,降低他们的迁移成本。

今天早上4点多就爬起来准备发安全公告(友商约的是早上5点发),一刷,OpenSSL官方已经正式发表了(时间大约是4点30),于是立即开始相关手续,commit修正,发公告,通知CERT,这些不表。

总体来说,这次安全公告比之前 Heartbleed 那回要有序的多,这主要归功于上回大家的声讨以及 Solar Designer 同学做的友商提前告知列表。大致时间线如下:

  1. 6月2日凌晨: OpenSSL 通知友商列表存在问题,要求同意 TLP:Amber 之后才告知具体细节。签署后约1小时得到了具体说明及补丁。
  2. 6月2日-3日:各友商各自修补,发现及反馈补丁问题。由于 TLP:Amber, FreeBSD 只有我和 des@ 及一位 OpenSSL 核心成员看到了公告草稿及补丁。
  3. 6月3日:FreeBSD 发表了本月第一批安全公告(这是更早前计划的周二批次)。此后立即开始着手联编 OpenSSL 特别更新。

本次问题可分成两类:SSL/TLS 和 DTLS。DTLS 常见于采用 UDP/SCTP 等 datagram 协议的应用,实际影响范围较小。

SSL/TLS 方面,CVE-2014-0224 CCS协议可在任意状态下使用的问题,可导致中间人攻击,后果严重,利用容易(可改变网络数据即可)但实际影响面较小,因为大部分人使用的浏览器并不是用 OpenSSL 来实现 SSL/TLS 支持的。但对邮件本身未做加密的邮件来说,基本等于是全军覆没了。这个漏洞存在了约16年,是的,十六年。发现者blog [英文]。我想,可能搞个可以形式证明的描述语言来重写SSL/TLS的实现才是正路?

另一个 CVE-2014-3470 可导致崩溃,影响较小一些。

值得一提的是,这次的一个 DTLS 问题 CVE-2014-0195 (可有任意代码执行之虞)也是上回引入 Heartbleed 的 Robin Seggelmann 引入的,呵呵。


总体来说,我觉得这批漏洞让人觉得有些绝望。 OpenSSL 有非常多的问题,但其中有很多必须对协议十分理解才能看出来,而另一方面看出来了报告给开发者也无非是得到几句赞扬而已。在现在这个年代,有能力看出来问题的人未必不会选择找个好的买家把漏洞卖掉。这种趋势十分危险,而最近几年有愈演愈烈的趋势。

Intel RDSEED指令

| No Comments | No TrackBacks

今天看到 John Baldwin commit 的这个 r266391 增加了相关支持。

RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG,而 RDSEED 则是直接从真随机数发生器中获得输出(两者并不是直接使用真随机发生器的输出,这些输出是做过 AES-CBC-MAC 处理的,防止外界通过观测输出了解内部运行的细节),较慢,后者具备 multiplicative prediction resistance 特性。

具体细节可以参考 Intel® Digital Random Number Generator (DRNG) Software Implementation GuideThe Difference Between RDRAND and RDSEED

Intel 的后一份文档中建议实现 PRNG 时使用 RDSEED,不太清楚这样做是否会同时复位 RDRAND 的状态?假如不复位的话,这样做似乎也意义不太大?(PRNG 的实现者应该从更多的地方收集 entropy 而不是假定真随机发生器的输出可信)。

此外, DRNG 用的 AES-CBC-MAC 这个事情,我认为是一把双刃剑(虽然用比不用要好),因为这样一来便很难验证来自硬件的随机数是否具有某些特性了(此外我找到的文档也没有具体描述如何 AES-CBC-MAC 是如何使用的)。

由于送修 iPad 最终没有修好,因此店家给提供了一台二手的 iPad。作为不折腾就会死星人我觉得显然应该重刷一遍固件(卖家已经重新清空了数据),因此做了一次 DFU mode 固件更新。

具体做法是先把 iPad 接在 Macbook 上,同时按住 power 和 Home。等待大约10秒后屏幕變黑,此时按住 Home,等到 iTunes 上可以看到 Recovery 为止。

然后就是刷 iOS 和恢复数据了,此前过程中在网关听包未见明显异常。

这次 Heartbleed 安全漏洞之后,阿里巴巴集团的多个产品均迅速修复了漏洞(好事),但事后的公关处理做的却有待改进。

我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博,内容如下:

关于OpenSSL某些版本存在基于基础协议的通用漏洞,阿里各网站已经在第一时间进行了修复处理,目前已经处理完毕,包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。

紧接着, 支付宝 转发了 这条微博:

大家可以放心了!

我并不是阿里巴巴/支付宝的客户,不过看到有人转发这条消息,我半开玩笑地 回了一句:

冲这句"大家可以放心了"就没法放心了......

OpenBSD fork 了 OpenSSL

| 2 Comments | No TrackBacks

OpenBSD [捐款链接] 又一次出手为民除害了! Undeadly报道: OpenBSD has started a massive strip-down and cleanup of OpenSSL

这次 Heartbleed 的事情搞的我十分不爽,这事固然不能全怪 OpenSSL 的开发者,但是整个过程非常的让人不舒服,具体的就不多说了。等过个几十年再回头看看这次这件事情再说吧。

OpenBSD 目前对 OpenSSL fork 的改进主要包括:

  • 修正了一处释放后还在使用内存的问题
  • 清理了一系列在 OpenBSD 上不需要的垃圾代码
  • 删除了绝大多数后端引擎(VIA padlock、Intel AES-NI支持除外)
  • 去掉了一系列用于移植的函数封装。
  • 使用了易读的 KNF (BSD的代码风格)取代坑爹+反人类的 GNU C 风格
  • 去掉了可能弱化随机数的代码
  • 砍掉了 Heartbeat 功能作者所写的全部代码

我个人非常希望 OpenBSD 的 fork 能够成功,那样的话我们就可以在几年以后(已经发布的版本还需要继续支持一段时间)彻底从 FreeBSD 基本系统中砍掉 OpenSSL 了。

先挖好坑,等有空了再填。

今天(2014/01/14)发了4个安全公告和2个勘误公告,其中 FreeBSD-SA-14:02.ntpd 是针对 NTP 的这种攻击的因应措施。

攻击的原理是通过发送一个小包(GET_MONLIST),得到大体积的回应。而由于 NTP 使用了 UDP 协议,因此攻击者可以伪造源 IP,从而,通过较小的流量代价,即可利用其他服务器作为杠杆来攻击受害者。

正确配置的 NTP 服务器并不受这个问题影响。所谓正确配置是指 NTP 服务器配置为只允许其他机器向其查询时间,具体做法是在 /etc/ntp.conf 中增加类似下面的设置:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0

(说明:上述配置是推荐的配置,实际上起作用的是 noquery)

还有一种解法是仅仅禁止 monitor 功能:

disable monitor

FreeBSD 安全公告提供的补丁采取的做法是将 monitor 功能默认禁用。用户不需要对配置文件进行修改,只需更新软件并重启 ntp 服务即可防止自己的服务器成为别人的攻击杠杆。

今天发现一台国内的机器流量异常,检查发现这台机器上运行的 DNS 缓存服务被人用作了攻击的放大杠杆,这里简单记一下。

发现流量异常,首先当然是检查服务器上的 TCP 会话,发现了一些不太正常的东西,关闭之后流量减少,但仍然没有回到正常水平。

于是听包。这一听发现一大片:

07:39:53.271744 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271772 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271784 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271792 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.274225 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274252 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274262 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274270 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.291822 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291850 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291860 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291869 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291877 IP 92.XX.XX.148.56278 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.11