家用路由器被入侵了

某天上网浏览网页,半天都返回不了结果,OS X 虽然不怎么样,Firefox/Chrome 浏览个网页应该没什么大问题。
最初以为是浏览器的问题,直接重启,无效;重启 Mac,继续无效。好吧,既然重启都不生效,索性咱们从专业的角度来分析分析问题。
抓包。结果令人惊讶。

我的机器主动给路由器(192.168.2.1)发送了大量的 RST 包,在没有任何主动 SYN 的情况下。第一反应就是受到中间人攻击了。
登到路由器后台一看,果真有几个不认识的客户加到了这个 SSID 里面。
后续的重启改密码就不说了,虽然用的是 WPA2 的加密方式,但是密码太弱智了,花几分钟暴力破解一下应该都能出来,引以为戒。

后续留几个连接大家可以参考参考。
如何通过 Sequence Number Predictionl 的方式来进行 MITM 攻击,手法跟我遇到的类似。

出现 TCP rst 的几种可能:
1.1. Where do resets come from? (No, the stork does not bring them.)
1.2. RST flag at end of TCP transmission 
1.3. What causes a TCP/IP reset (RST) flag to be sent? 

2.1. Why TCP Reset sent after receive [FIN,ACK] Packet? 
2.2. TCP option SO_LINGER (zero) – when it's required

3.1. Windows sends RST after SYN-ACK on a TCP connection
3.2. RST after SYN-ACK
3.3. Why on receiving SYN/ACK, a RST packet is sent with certain sites
3.4. why kernel sent RST to a remote TCP server after the machine receiving a SYN/ACK packet?
3.5. why do Client send a RST packet during TCP handshake? [closed]
3.6. Why would a client send a RST packet as reply to a SYN,ACK? 

4.1. TCP: Server sends [RST, ACK] immediately after receiving [SYN] from Client
4.2. Why do I see a RST, ACK packet instead of a RST packet? 

通过 execv(snoopy) 来做用户行为 audit

github 有个叫 snoopy 的项目,专门用来做 audit,比系统原生的 auditd 好用的多,思路很好,关键的就是执行任何的命令之前确保第一调用的是 /etc/ld.so/preload 里面的 snoopy.so 这个动态库文件,而他调用的则是 exec()。
* execl
* execlp
* execle
* execv
* execvp
* execve
上面 6 个 sys call 的区别仅仅在于 arg 是 list 还是 array,是否使用了当前的环境变量已经 PATH 的使用。详细的区别请看这里(1, 2)。  
顺便提下 fork 跟 exec 的区别

当然,该服务并不是那么的完全,最少有下面几个问题:
1. 默认只接受 4096 长度的 argv,超过的或直接 trunk,这个不是什么大问题,可以在源码里面直接修改其 MACRO SNOOPY_MAX_ARG_LENGTH,增大到你需要的长度就好了
2. 对于 pipe 的处理,snoopy 会分别记录每一个 pipe 下的命令,然后分别打到 syslog 里面
3. 性能,网上有说会对性能产生一定的影响,目前来看,当然会有影响,毕竟多调用 sys call,但是从我们线上使用的情况来看,微乎其微,不管什么方案,最终都是 tradeoff 的结果

有人想做 audit 就有人想 bypass,结果还真有人想出了一套方案,简单的说就是在加载 snoopy.so 之前通过 dlopen() 加载这段 bypass 的代码。这仅仅是从技术的角度来分析,实际的线上是通过制度保证绝对不允许有任何人突破这道红线的。

startup 的安全问题

安全这个问题好像离绝大多数的 startup 比较遥远,好像谈到安全只有 BAT 这类规模的才会重视。
绝大多数的 startup 起家都是短糙快,怎么好搞怎么搞,怎么方便怎么搞,怎么省事怎么搞。再加上「绝大多数的创业公司都喜欢宣称自己是「平均年龄25 的年轻团队。」,正面理解起来是有活力的团队,反面理解起来,其实代表的是「招不到人,只能忽悠年轻人,组建的一只没经验靠人力时间堆砌的弱逼团队」」,其整体的安全性可想而知。
这或许在初期并没有什么问题,因为本来知道你的人就不多嘛,cracker 们也没兴趣花时间在只有几千几百用户的上团体上。
但是如果你很幸运,成为了那百分之几甚至千分之几的存活下来的,那就是另外一回事了,你们的产品会在短期内被很多的用户知道,得到了不少用户的认可,用户数量逐渐变多,接下来可能要经过一段爆发性的增长,一方面来说是好事,但是,另外一方面,对公司整体的技术也是一个非常大的挑战,再加上很多都是没什么经验的工程师,真的就是摸着石头过河了,在这期间,会经历若干次的宕机服务不可用事故,为了尽快的 available,不得不牺牲很多方面,正所谓 tradeoff,比如牺牲了安全。
然后名气慢慢大了,积累的用户数量在圈子里面也数一数二了,白帽子也好黑帽子也罢,都对其产生了很大的兴趣,随便扫扫,就发现了不少有价值的信息,至于什么信息大家自己补脑吧。
好在有类似 wooyun 这样的平台,突然有一天 startup 在 wooyun 上收到了一封「弱口令」(关于弱密码的危害,请看这里)的漏洞提交,至此,公司开始对安全有了一定的认识,发现原来弱口令还是导致直接渗透到内网,于是上上下下一顿整改,但这毕竟只是冰山一角,前几年为了方便留下的祸患太多了,接下来,不停的收到若口令、权限绕过、设计缺陷等等各种各样的漏洞报告。虽然大多数人都很重视这类问题,积极的配合整改,但总会有那么些人不以为然,认为这些事情不值一提,根据 2/8 原则,80% 的漏洞都是由 20% 的人造成的,直到某一天,发现公司的用户信息、代码被拖库了,傻眼了。
上面可能是很多 startup 都要经历的过程:为了方便随便上线,携带敏感信息的配置文件不加任何处理,无任何限制的开放对内服务的访问权限,弱密码,以上还仅仅是技术层面的因素,如果遇到叼炸天的工程师自以为是等人为非技术因素,后期需要改进沟通的更是难上加难。
出几次事故也未必是坏事,最起码让我们明白,不好好对待这个问题,迟早是要出大事的,用户信息泄漏了导致公司陷入危机的不在少数,那些处在风华正茂认为老子(或许有老娘这么一说)天下第一无人能敌写代码如行云流水天马行空 bug free 的也是会出些非常低级的错误的。很多东西,尤其是安全,仅仅是从技术层面加以控制是完全不够的,更多的是需要从行政手段上加以干预,有奖有惩,才能从根源控制。当然,上面说的这些尤其是最后一点在一个仅仅发展了两三年,连基本的工程师制度惩处措施都没有,没有强大的执行力或者说是重视此问题的有话语权工程师的干预下,是不可能做到的。

OpenSSL(CVE-2014-0160)漏洞修复速度

OpenSSL 不是第一次出现这类影响非常严重的漏洞了,12 年 4 月的 CVE-2012-2110 这个漏洞当时就让我忙活了好一阵子
今天早上扫 feedly 的时候发现了这个漏洞,迅速确认了我们线上的服务器不受影响之后就开始围观了。  
OpenSSL 官方最先挂了通知
几个主要的发行版本都在当天(4 月 8 日)发出了 Heartbleed bug 影响以及修复方式:USN(1, 2) , DSA, Bugzilla

要说影响,基本可以确定包含 taobao 在内的绝大多数的都受到影响了,其他的小电商小网站就不计其数了,wooyun 上有截图为证:

话说这漏洞出来也好长时间了(相对于互联网的速度),到我写这篇博客的时候(08-21-04-08-2014),最少也有五六个小时了。很不幸的是,我跑了一遍,发现还有下面这些网站没有及时的升级打补丁:
1. kyfw.12306.cn,这个证书本来就有问题
2. 126.com/163.com 旗下的各种邮箱
3. login.yahoo.com,  www.flickr.com 这两个一起的,www.tumblr.com 虽然被收购了,估计还没整合好,这次修复的还蛮迅速的
4. www.quora.com 没想到反应这么慢
5. 京东的蛮有意思的,海外、国内登录两套标准,passport.en.jd.com 这个没有 ssl 证书,passport.jd.com 则有证书
6. fitbit.com,毕竟不是专业搞互联网的,速度慢可以理解

上面的在没有确认升级完毕之前,务必不要再登录,要检验是否安全很简单,可以去 github 上跑个脚本或者直接用这个。其他的比如 amazon.com, coursera.org, dropbox.com, evernote.com, facebook, twitter.com, foursquare.com, github.com, instagram.com, vimeo.com, wikipedia.org 我扫的时候发现已经没有问题了(或许原来就没遇到这个漏洞)。

其实这个漏洞保守估计在一周之前就已经发现,但是并没有公开,所以 cloudflare 有足够的时间去升级,今天发布的这个博客绝对是个绝妙的加分项,完爆 ali。

如何修复?
对于服务商,抓紧时间升级。
对于用户,最好修改一遍密码,因为可以确认包括 taobao 在内已经有部分用户的信息泄漏了,如果你是所有网站公用一套登录名密码,连夜修改吧。


update: 07-15-04-09-2014,上面提到的 6 个网站已经全部完成修复,速度还算可以接受。

update: 04-09-2014,Cisco 官方发出了受影响设备的列表,IOS 以及 Nexus 的不在影响之列。

遭受了 NTP 放大攻击

某台开放了公网的服务器流量从某时刻起突然暴涨了,登陆上去排查,ibmonitor&iftop&iptraf 三个工具结合跑一遍,直接定位到了问题的根源,遭受了 ntp amplification,现象以及细节可以看下面五张图。

整个过程中我们的带宽变化

攻击进行时通过 iftop 观察到的现象

攻击进行时通过 iptraf 观察到的现象

停止了 ntp 之后通过 iftop 观察到的

停止了 ntp 之后通过 iptraf 观察到的

关注 cloudflare 官方博客的可以发现,时间跟这次全球性的 400G DDoS 非常吻合,之后通过跟官方联系,确认我们的机器是受害者之一。
除了 NTP 之外,DNS 以及 SNMP 也是易受攻击做 AMP 的协议之一,二者都是 UDP,很容易通过很小的投入产生巨大的流量,根据监控可以发现,机器的进流量在受攻击的这段时间内几乎没有变化,而出去的流量净增 400M+。按照这个量,攻击十台这样的服务器,基本可以搞定一个中型网站的一个或者多个出口。

如何防御?OpenNTPProject 这个项目上写的很详尽

弱密码的危害

前段时间,我收到 wooyun 上白帽子发来的一条消息,大致意思是我们的博客(wordpress)的后台被 crack 了,然后成功的拿到了 shell,最终登陆到我们的内网,由于目前我们测试跟生产环境是通过 VPN 联通的,危害可想而知。被 crack 的缘由说来好笑,由于 wordpress 同时有很多的作者,有的作者为了方便记忆,设置了非常简单的密码,简单到都不需要暴力破解。
暂时解决问题的办法也很简单,最少有如下的几种:
1. 加强密码强度,这个也是首要改进的。但是理论上没有不能暴力破解的密码,尤其在 CSDN 事件之后,基本是人手一个非常高效的字典。
2. 设置一些访问权限也可以从一定程度上缓解此类问题。但是有能力的完全可以伪造 IP 突破限制。
3. 通过虚拟机完全隔离,如果遇到一名社工非常强大的黑客他依然会找到蛛丝马迹

但上,上面说的这些方式都无法从根本解决问题。
wordpress 作为一款非常的流行的 CMS,包括我自身的博客在内,被很多的个人以及企业所青睐,用的人多了,自然的,被盯上的概率也就大了。很多创业公司为了省事,很有可能把公司的博客跟生产环境放到一起,而写博客的作者们通常是一群搞市场搞运营的技术小白,这就大大方便作案了。
除了像 wordpress 这类很火的 CMS,一些运维管理平台同样会由于开放了公网环境,而登陆者的弱密码会造成整个内网沦陷的悲剧。

要真正解决这类问题,至少可以从使用者以及服务提供者两方面入手。
对于使用者来说,自己首先需要意识到这类问题的严重性,掌握一些基础的知识,比如如何设置一个比较健壮的密码,如何设置邮箱等,这少不了安全人员对其教化。有趣的是,有的时候,教化的再多,不如自己的敏感信息被泄漏一次来的更有教训,虽然很无奈但事实就是这样。
而对于服务体提供者来说,除了上面说到的一些简单通用的方式,还可以通过下面的一些方式来加强:
1. 创建用户期间就应该主动检测密码强度,只有达到一定强度的密码才可以注册,目前,不少网站都做的不错。并且,目前很多的系统(Linux, Nexus 等)都可以实现这类最基础也是最有效的功能
2. 频繁登陆出错触发一些规则,比如一天之内登陆错误 3 次不允许访问,10min 钟内登陆错误 3 次禁止访问,具体可以参见不少电商以及金融体系的做法