事情應該就是最近發生的, 只要你連到下列網站,
http://www.msn.com.tw
http://tw.msn.com
http://taiwan.cnet.com
即有可能會被導到
http://www.dachengkeji.com/aritcle/index.htm
經過分析, 問題出在 Client 傳出 GET HTTP/1.1 之後, 馬上就會回傳一個帶有其他網址的封包, 而這個封包是帶有 FIN Flag.
這是第五個封包.
正常的封包是第八個
所以不論你用的是 IE/Firefox 還是 Windows XP/Vista or Linux
不管 Server 是 IIS 或是 Apache
統統都有可能被導向到新的網站.
從有限的資料
1) Hinet 3IP/ADSL
2) 大陸
有可能被導向
TANET 似乎沒有問題.
有網友猜測是
1) 被種木馬
2) ROOT DNS 攻擊
3) DNS Cache 攻擊
個人看法統統都不是, 因為我連的 IP 仍然是 taiwan.cnet.com 和 tw.msn.com 的 IP. 而有問題的封包是搶在 SERVER 回應之前送來的.
從 Packet 回傳的 delta time 來看, 個人猜測可能狀況為下
1. Hinet 和大陸到 taiwan.cnet.com 和 tw.msn.com 的 ISP 被 mirror port, 偵側到 GET HTTP/1.1 隨機送出網址
2. Abovenet 被破台了, 木馬是種在 Abovenet Transparent proxy 內. (會猜 Abovenet 是因為這二家都是很大家的入口網站)
3. IDC 被 ARP Spoofing, 流量被導到某些被破台的機器.
後續發展就需要再觀察了, 這段期間請大家小心,
尤其是 hinet 的用戶. cnet.com 和 msn.com 暫時就不要去了, 到 Google 多好, 沒事.
儘量不要用主流的瀏覽器, 像是 IE. 可以省掉不少潛在的風險.
網路是很危險的, 也是很脆弱, Internet 不如我們想像中安全呀~~~
Ref.
連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm
Update:
小小修正一些內容, 放個假回來好像變得更精彩, 大家也愈寫愈詳細.
這邊補充一下使用的工具是 Wireshark, 這是一套跨平台功能強大的 Packet Logger. 配合發展的 libpcap 也是一個強大的 Packet capture library.
再補二個相關的 URL
Neo
你好
看了你的blog
看到一篇—-神奇中醫的治療
因為家中長輩有類似問題
故有些問題想請教
1.如果已經開始洗腎,這樣的治療該中醫師還有一定程度的把握嗎?一週要洗腎3次,每次半天,如果洗腎當下,發生你那些時期的一些症狀,這樣就無法即時處理了是嗎?
2.在CT大,有一些私下的個人興趣研究,關於中醫系統晶片方面,也一些同好參予,其中有中醫以及自學中醫者(包含王唯工教授的學生),都秉持著希望可以將中醫推上國際正統科學的理想,不知道我們可以拜訪那位中醫研討嗎?
3.請問那位中醫是否姓李
謝謝
Charlie
世界之窗瀏覽器 http://www.ioage.com/cn/同樣被轉址
此外發現在同一台電腦用VMware 系統是Linux DNS同樣是Hinet FTTB 的線路
卻不會被轉址，我個人懷疑是windows修改登錄檔方式去轉址，因為同一台電腦虛擬另一台電腦用撥接連線，等於可以說是兩台電腦同用一個ISP，linux去瀏覽卻不會有問題windows有問題。而或許有人說是firefox防害做的好，可也有人回報Firefox在windows上面也有相同轉址情形。希望以上資訊有助於趕緊破解此謎題！！謝謝
fyodor
heya
我有在看那個東西. 我覺得不是transparent proxy, 是non-blind spoofing的問題.
1. 看TTL – 都是大概0x7x左右. 跟運來得host不同.
2. IP.id field – always 0x0100 (一般的TCP stack IP.id can’t be the same value.)
http://seclists.org/bugtraq/2001/May/0044.html
3. the packet always FIN,ACK. 所以他只要方以個就達到了!
問題是 – SEQ/ACK號碼他怎麼才?
1. 有可能他們正的波一些router然後sniff + spoof
2. route injection(?)(我覺得不太可能)..
3. 有malware在座sniffing的通做….
這個沒有問題的route:
4 tp-e4-c12r2.router.hinet.net (211.22.36.178) 47.944 ms 46.822 ms 45.940 ms
5 tp-crs11.router.hinet.net (220.128.1.110) 47.940 ms 47.508 ms 47.073 ms
6 r33-s2.tp.hinet.net (220.128.1.161) 46.076 ms r33-s2.tp.hinet.net (220.128.2.161) 44.964 ms 45.806 ms
7 203.208.146.121 (203.208.146.121) 175.835 ms 175.031 ms 175.941 ms
8 ge-4-0-3-0.sngc3-cr1.ix.singtel.com (203.208.183.45) 173.381 ms 173.017 ms 175.353 ms
9 ge-1-0-0-0.sngc3-ar2.ix.singtel.com (203.208.172.158) 176.429 ms 181.907 ms 175.861 ms
10 203.208.145.246 (203.208.145.246) 173.151 ms 174.289 ms 175.456 ms
11 203.208.255.238 (203.208.255.238) 173.136 ms 176.060 ms 173.922 ms
12 202.176.193.220 (202.176.193.220) 176.502 ms 176.775 ms 176.353 ms
13 202.176.193.220 (202.176.193.220) 176.685 ms !A * 177.411 ms !A
這個是有問題的route:
4 36 ms 36 ms 36 ms 168.95.90.194 [hc-c76r1.router.hinet.net]
5 36 ms 36 ms 36 ms 211.22.38.82 [hc-c12r1.router.hinet.net]
6 38 ms 38 ms 36 ms 220.128.1.34 [tp-crs11.router.hinet.net]
7 36 ms 37 ms 37 ms 220.128.1.161 [r33-s2.tp.hinet.net]
8 131 ms 131 ms 129 ms 203.208.186.1
9 129 ms 129 ms 129 ms 203.208.183.53 [ge-4-0-3-0.sngc3-cr2.ix.singte
.com]
10 129 ms 129 ms 129 ms 203.208.172.166 [ge-0-0-0-0.sngc3-ar2.ix.singte
.com]
11 129 ms 129 ms 129 ms 203.208.145.246
12 131 ms 131 ms 131 ms 203.208.255.238
13 131 ms 131 ms 131 ms 202.176.193.220
14 Destination Reached in 130 ms. Connection established to 202.176.217.17
Trace Complete.
如果我們可以trust hinet跟singtel, 那就是這個host 有問題
8 131 ms 131 ms 129 ms 203.208.186.1
還有一個特色, 每個被redirect的host都是在singtel那邊…
richliu
從 TANET 過去的 traceroute 路徑和 hinet 有些許不一樣,
沒有大陸也有問題的 traceroute, 如果有, 可能就可以 確認是 sigtel 的問題.
剛剛 trace TANET 也是從 sigtel 過去. sigtel 有些有反查, 有些沒有, 各點進入的路徑都不相同.
目前也只能猜測而己.
只是我在想, Hinet 不是有直連電路到美國嗎? 怎麼到 MSN.com 要經過新加坡呢?
PowerOp
有遇到的朋友也許可以自己抓一下網路封包來看？
richliu 用的軟體是 Wireshark （以前叫 ethereal），這個自由軟體是跨平台的，也可以裝在 MS Windows 上面。（免費又合法的強大工具喔）
找一下 “Wireshark 教學” 就有很多資料了。
大家猜來猜去，不如實際看看你的網路卡進出的封包吧 😀
Charlie
世界之窗瀏覽器： http://www.ioage.com
同樣被轉址，
此外經過交叉測試，以下整理：
****
環境
****
ISP：Hinet FTTB
DNS：168.95.192.1
—–>平台：windows(會被轉址)。平台：Linux(不會被轉址)平台：windows(不會被轉址)。<——–Firefox、IE7
結論：以上經過不同區域朋友同步測試，似乎只對使用中華電信光纖網路的
Windows平台有效(會被轉址)，用Linux的朋友並不受此影響。
希望以上資訊有助於趕緊破解此謎題！！謝謝
Charlie
世界之窗瀏覽器： http://www.ioage.com，同樣被轉址，此外經過交叉測試，以下整理：
****
環境
****
ISP：Hinet FTTB、DNS：168.95.192.1—–>平台：windows(會被轉址)(Firefox、IE7)。—–>平台：Linux(不會被轉址)(Firefox)。
****
環境
****
ISP：學校學術網路、DNS：168.95.192.1—–>平台：windows(不會被轉址)(Firefox、IE7)
結論：以上經過不同區域朋友同步測試，似乎只對使用中華電信光纖網路的
Windows平台有效(會被轉址)，用Linux的朋友並不受此影響。
希望以上資訊有助於趕緊破解此謎題！！謝謝
fyodor
Charlie: 這個很有趨. 可以看一些detail嗎?
1. 你的traceroute的 output. 我建議用tcp traceroute tool. 象http://tracetcp.sourceforge.net/, 或者
http://michael.toren.net/code/tcptraceroute/beta.html (windows版 http://www.bgnett.no/~giva/misc/tcptraceroute-win.zip, python http://www.thomas-guettler.de/scripts/tcptraceroute.py.txt)
直接trace tcp port 80. initial hop可以設定 -h 4, 應該safe…
2. 如果方便的畫, 我想看 “不會被轉址” 跟 “會被轉址” tcpdump/wireshark dump. 如果不方便寄檔案給我的畫 我想看想如上的screenshot(我是 fygrave at gmail dot com dotNospam.. )
應為如果想你說的”linux”沒有影響. 代表 windows tcp stack有問題. 我想了解以下是什麼問題.. 是timing, 或者他們可以預算 windows的 syn/ack號碼 (或者enforce windows to use particular SYN/ACK numbers..?)…
等等..
如果有辦法提供這些資料, 真的很感謝
fyodor
http://o0o.nu/files/attack01.pdf – 我在這裡有解釋哪些packet dump.. 看一下
fyodor
還有. linux沒有被攻擊的原因:
我們看得到的traffic大概是這樣的
syn ->
ack
->data (“GET / “)
ack
->RST/ACk (the same seq numbers)
rst (connection was already closed)
按照 TCP RFC, FIN/ACK packets 不可能有data payload. 但是這個spoofed的attack – 有. However windows for some reason first answers with ack (but it shouldn’t), then I think it passes the data to the application (browser) and then sends RST.
On Linux it simply sends RST and the deal is over..
Microsoft is acting smart again 😉
這樣的是應該就沒有問題了..
最後一個問題 – 他們怎麼可以看得到syn/ack?!
Router compromise?
Router traffic mirroring?
Router trojaned IOS?
…?
還有 – 如果再windows 把MTU設定很小 (這樣的你的get request會變成2個 packet)會不會就沒有redirect的問題?
改MTU的說明: http://www.pctools.com/guides/registry/detail/280/
richliu
不會被轉址的就自己上個網站抓一下就可以了.
重點還是看得到 syn/ack. 可能是 switch 被下 mirror port 的手腳了. route 上也有可能.
而且這個路徑絕對不可能太長, 所以我會猜是 Transparent Proxy(因為一定要經過), 而且 Transparent Proxy 比較容易植入程式, mirror router 之後還是要放一台機器進去, 難度比較高.
前面有一個有寫 Traceroute 的路徑. 我個人是用固定 IP 的 ADSL, 所以影響我認為應該是全部的 Hinet.
Linux 有人回報也有問題, 當時我沒有再試下去(寫這篇文章太晚了).
在 packet 中加 FIN 應該是強制讓 Browser 直接往這個網站連.
如果 MTU 設很小, 理論上應該會抓到, 要是我寫這樣的程式, 我只要針對某些特定的 Packet : Sequence number : 1, Port 80, 前面是 GET 開頭的 Packet, 直接回傳, 應該就可以達到這樣的效果.
只是回傳的 URL 會不會小於你設的 MTU(大概要小於 240), 如果大於設定的 MTU, 應該就可以擋住(這不考慮這種 MTU 也有可能被其他 Firewall 濾掉的狀況)
fyodor
看一下我下面寫的問題 🙂 這些想問你的