发现一个利用MHTML 0day漏洞盗取gmail账户的案例，请大家注意

最近看到有人声称说MHTML 0day漏洞被利用盗取gmail账户，并给出了地址，我大概看了一下。

http[危险]://www.solidaritycenter.org/files/India.html就是钓鱼页面的地址，这么网页里面有一段javascript代码，利用漏洞劫持cookie，还有一段使用base64加密的javascript文件地址，解码后是http://www.solidaritycenter.org/files/India.js，India.js会把你的Gmail邮件转发给tk9652320@gmail.com并在浏览器中建立一个iframe，iframe内容的中文版在这里http[危险]://www.solidaritycenter.org/files/Indo-cn.html，里面是一个gmail的登录页面，这就是钓鱼页面，会把你的gmail账号密码以post方式发给http://www.solidaritycenter.org/files/IndoTraffickingAppendices.asp，然后再把你转向真正的Gmail页面。

目前微软还没有给出补丁，建议大家暂时不要使用IE浏览器以及IE内核浏览器（如360、TT、遨游等）登录Gmail。

我把相关页面打包起来了，点击下载。不建议使用使用浏览器直接打开，否则后果自负。出于安全性考虑我给压缩包加了密码，密码是virus

近期Gmail访问不稳定的临时解决办法

Gmail最近访问不稳定的原因是电信运营商在随机丢弃和Gmail服务器通信的数据包，手法和阻止https://www.google.com/的访问是一样的。好在Google的服务器很多，通过Google的任意一个服务器就能访问到Google几乎所有的服务。最近观察发现，不是所有的Google服务器都遭到了被随机丢弃数据包的待遇，我们可以通过这些服务器来访问Gmail等Google提供的服务。解决的方法还是老办法，修改hosts。

向hosts加入以下内容：
#一般hosts文件在Windows下位于c:\windows\system32\drivers\etc\hosts。Linux下位于/etc/hosts
66.249.89.91 mail.google.com
74.125.79.109 pop.gmail.com
74.125.79.109 smtp.gmail.com
66.249.89.91 encrypted.google.com
66.249.89.91 www.google.com
66.249.89.46 www.google.com.hk
72.14.203.91 docs.google.com
72.14.203.93 encrypted-tbn0.google.com
72.14.203.93 encrypted-tbn1.google.com
72.14.203.93 encrypted-tbn2.google.com
72.14.203.93 encrypted-tbn3.google.com


2010.06.04更新hosts（建议只在中国大陆使用）
2012.07.31测试仍可用


203.208.46.146 www.google.com
203.208.46.147 www.google.com.hk
203.208.46.132 clients1.google.com
203.208.46.149 mail.google.com
203.208.46.161 chatenabled.mail.google.com
203.208.46.161 mail-attachment.googleusercontent.com   #XP下的IE可能会有错误证书提示，Vista以上或Firefox浏览器不会出现此现象
203.208.46.146 id.google.com
203.208.46.146 encrypted.google.com
203.208.46.161 encrypted-tbn0.google.com
203.208.46.162 encrypted-tbn1.google.com
203.208.46.163 encrypted-tbn2.google.com
203.208.46.164 encrypted-tbn3.google.com
203.208.46.132 webcache.googleusercontent.com #XP下IE https连接可能会有证书错误提示
203.208.46.191 ssl.gstatic.com
203.208.46.161 docs.google.com
203.208.46.157 0.docs.google.com
203.208.46.157 1.docs.google.com

Google https无法访问的暂时解决办法

        这几天Google的https服务总是被封锁，例如Google Reader，封锁手法好像是443端口的TCP数据包被丢弃。有网友说丢弃数据包是分时间段的，位于韩国(74.125.153.113)的Google IP服务器的SSL规律是每个小时的00-19，30-49分可用，20-29，50-59分不可用。如果是GFW干的，这种封锁方法GFW以前从没有用过的，这意味着GFW进行了升级。

        现在对抗这种封锁手法只能是换用Google的其他没有被墙IP地址了，大家可以试试把别的Google ip地址（如66.249.89.93）和www.google.com在hosts文件里绑定在一起。

题外话：如果GFW开始丢弃特定端口的数据包，那么就意味着GFW对我们来说不再隐形，很容易探测出他在网络中所处的位置。另外发现一个很有意思的现象，当某个google的ip地址443端口（https）数据包被丢弃时，tracert有17调，没有丢弃数据包现象时tracert有16跳。

如何选择适合自己ipv6隧道

        现在Google的大部分服务已经支持ipv6来访问了。如果我们的isp没有给我们提供ipv6原生支持，我们也可以通过建立隧道来访问ipv6资源，一般还会加上hosts文件的配合。如何建立隧道我就不多说了，网上的教程也很多，但是如何选择隧道的种类，有些网友还是不太明白，这里我简要说一下。

        现在主流的ipv6隧道技术有这么几种：isatap、6to4、teredo。6to4的一大缺点是运行隧道客户端的主机必须有合法的ip地址，如果你在路由器（NAT设备）或防火墙后面一般就无法使用6to4隧道了，但6to4的优点是运行稳定，不需要你自己手动找relay服务器；isatap和6to4类似；Teredo不需要客户端有合法的ip地址，在路由器或防火墙后也能运行，但由于是把ipv6数据包放在udp包中通过ipv4网络和中继服务器通信，有时网络会不太稳定，而且Windows默认的在只有teredo来连接ipv6网络时dns解析不查询AAAA类型，会造成解析不到ipv6地址，由于windows xp的hosts文件不支持ipv6，所以xp用户使用teredo隧道很麻烦。

建议：有合法ip地址的用户尽量使用6to4和isatap；使用teredo隧道的用户尽量使用Vista、Win7一类的新系统，Linux用户建议使用软件miredo来建立teredo隧道。

下面公布几个隧道服务器的地址：
isatap router：
202.112.26.254 上海交大
59.66.4.50 清华大学
6to4 relay：
tserv15.lax1.ipv6.he.net Los Angeles, CA, US
tserv3.fmt2.ipv6.he.net Fremont, CA, US

Google实时搜索遭到GFW认证

这周末这么一折腾，Google实时搜索现在已经被墙。

2011.02.22update：已经解封

最简单的对抗DNS污染的方法

GFW的DNS污染只对UDP协议的DNS查询有效，对TCP协议的DNS查询无效，我们只需要使用TCP协议来查询DNS就可以了。

在Windows下，使用nslookup命令时加上-vc参数就可以强制使用TCP协议而不是UDP协议进行DNS查询。例如查询encrypted.google.com，输入命令nslookup -vc encrypted.google.com 8.8.8.8进行DNS查询就可以得到正确的查询结果，下一步就是把结果加入hosts文件。nslookup命令的用法我在这里就不多说了,唯一要多说的是不要使用中国的DNS服务器查询就行，推荐Google DNS和OPEN DNS。

至于如何让强制让系统使用TCP协议来查询DNS，我就不知道了，如果哪位大侠知道该怎么做，请指点一下。

更新：已经有高手找到怎么让系统强制使用TCP协议来查询DNS了。
http://www.bingtech.net/wordpress/?p=233

更新：有兴趣的童鞋可以试试这个东东
http://code.google.com/p/pwx-dns-proxy/

提供一组不用翻墙就能上twitter的ip地址（2012年1月28日更新）

把下面的内容加入hosts文件，重启浏览器，访问https://twitter.com，注意必须是以https://开头


2011年2月17日测试以下ip地址失效
65.49.26.99 twitter.com
65.49.26.98 si0.twimg.com
65.49.26.98 si1.twimg.com
65.49.26.98 si2.twimg.com
65.49.26.98 si3.twimg.com
65.49.26.98 si4.twimg.com
65.49.26.98 si5.twimg.com
65.49.26.97 api.twitter.com
72.246.94.33 platform.twitter.com



2012年1月15日更新ip地址：（已失效）
199.59.148.105 oauth.twitter.com
199.59.148.104 twitter.com
199.59.148.104 www.twitter.com
199.59.148.105 m.twitter.com
199.59.148.203 mobile.twitter.com
199.59.148.15 api.twitter.com
199.59.148.105 search.twitter.com
199.59.148.105 userstream.twitter.com
199.59.148.105 ssl.twitter.com
199.59.148.105 status.twitter.com
199.59.148.206 support.twitter.com
199.59.148.223 upload.twitter.com



2012年1月28日更新ip地址：
199.59.148.202 oauth.twitter.com
199.59.148.202 twitter.com
199.59.148.202 www.twitter.com
199.59.148.202 m.twitter.com
199.59.148.203 mobile.twitter.com
199.59.148.202 api.twitter.com
199.59.148.202 search.twitter.com
199.59.148.202 userstream.twitter.com
199.59.148.202 ssl.twitter.com
199.59.148.202 status.twitter.com
199.59.148.206 support.twitter.com
199.59.148.223 upload.twitter.com