「某些 ISP 疑似被 hijacking 攻擊」的迴響

作者：Z.k's blog - 大規模網頁綁架轉址：威脅未解除，但專家都猜錯了

Z.k's blog - 大規模網頁綁架轉址：威脅未解除，但專家都猜錯了 — Sat, 14 Mar 2009 03:25:12 +0000

[...] 網路上判斷比較接近我們的，有Blue在資安之眼所貼的「關於這兩天的轉址攻擊事件」，還有richliu所blog的「某些 ISP 疑似被 hijacking攻擊」。另外，在mobile01上，powerpcer有貼出他的pcap dump，我們看過手法跟我們錄的是一樣的。 [...]

作者：大規模網頁綁架轉址：威脅未解除，但專家都猜錯了 | 鬼仔's Blog

大規模網頁綁架轉址：威脅未解除，但專家都猜錯了 | 鬼仔's Blog — Fri, 13 Mar 2009 05:15:32 +0000

作者：richliu

richliu — Mon, 09 Mar 2009 05:58:08 +0000

從 TANET 過去的 traceroute 路徑和 hinet 有些許不一樣,

沒有大陸也有問題的 traceroute, 如果有, 可能就可以確認是 sigtel 的問題.
剛剛 trace TANET 也是從 sigtel 過去. sigtel 有些有反查, 有些沒有, 各點進入的路徑都不相同.

目前也只能猜測而己.
只是我在想, Hinet 不是有直連電路到美國嗎? 怎麼到 MSN.com 要經過新加坡呢?

作者：richliu

richliu — Mon, 09 Mar 2009 05:32:32 +0000

不會被轉址的就自己上個網站抓一下就可以了.

重點還是看得到 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 濾掉的狀況)

作者：新的網站轉址攻擊手法？ - HackerShow 駭客秀

新的網站轉址攻擊手法？ - HackerShow 駭客秀 — Sat, 07 Mar 2009 04:48:32 +0000

[...] richliu’s blog http://blog.richliu.com/2009/03/05/743/ [...]

作者：fyodor

fyodor — Fri, 06 Mar 2009 19:25:16 +0000

看一下我下面寫的問題這些想問你的

作者：fyodor

fyodor — Fri, 06 Mar 2009 19:23:37 +0000

還有. 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/

作者：fyodor

fyodor — Fri, 06 Mar 2009 17:57:03 +0000

http://o0o.nu/files/attack01.pdf – 我在這裡有解釋哪些packet dump.. 看一下

作者：fyodor

fyodor — Fri, 06 Mar 2009 16:06:51 +0000

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..?)…

等等..

如果有辦法提供這些資料, 真的很感謝

作者：Charlie

Charlie — Fri, 06 Mar 2009 15:20:39 +0000

世界之窗瀏覽器： 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的朋友並不受此影響。
希望以上資訊有助於趕緊破解此謎題！！謝謝

作者：Charlie

Charlie — Fri, 06 Mar 2009 15:16:00 +0000

世界之窗瀏覽器： http://www.ioage.com
同樣被轉址，
此外經過交叉測試，以下整理：

****
環境
****
ISP：Hinet FTTB
DNS：168.95.192.1
—–>平台：windows(會被轉址)。平台：Linux(不會被轉址)平台：windows(不會被轉址)。<——–Firefox、IE7

結論：以上經過不同區域朋友同步測試，似乎只對使用中華電信光纖網路的

Windows平台有效(會被轉址)，用Linux的朋友並不受此影響。

希望以上資訊有助於趕緊破解此謎題！！謝謝

作者：PowerOp

PowerOp — Fri, 06 Mar 2009 15:03:34 +0000

有遇到的朋友也許可以自己抓一下網路封包來看？

richliu 用的軟體是 Wireshark （以前叫 ethereal），這個自由軟體是跨平台的，也可以裝在 MS Windows 上面。（免費又合法的強大工具喔）

找一下『Wireshark 教學』就有很多資料了。

大家猜來猜去，不如實際看看你的網路卡進出的封包吧

作者：fyodor

fyodor — Fri, 06 Mar 2009 14:53:49 +0000

heya
我有在看那個東西. 我覺得不是transparent proxy, 是non-blind spoofing的問題.

1. 看TTL – 都是大概0×7x左右. 跟運來得host不同.
2. IP.id field – always 0×0100 (一般的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那邊…

作者：Charlie

Charlie — Fri, 06 Mar 2009 12:14:35 +0000

世界之窗瀏覽器 http://www.ioage.com/cn/同樣被轉址
此外發現在同一台電腦用VMware 系統是Linux DNS同樣是Hinet FTTB 的線路
卻不會被轉址，我個人懷疑是windows修改登錄檔方式去轉址，因為同一台電腦虛擬另一台電腦用撥接連線，等於可以說是兩台電腦同用一個ISP，linux去瀏覽卻不會有問題windows有問題。而或許有人說是firefox防害做的好，可也有人回報Firefox在windows上面也有相同轉址情形。希望以上資訊有助於趕緊破解此謎題！！謝謝

作者：Neo

Neo — Thu, 05 Mar 2009 06:07:22 +0000

你好

看了你的blog

看到一篇—-神奇中醫的治療

因為家中長輩有類似問題

故有些問題想請教

1.如果已經開始洗腎,這樣的治療該中醫師還有一定程度的把握嗎?一週要洗腎3次,每次半天,如果洗腎當下,發生你那些時期的一些症狀,這樣就無法即時處理了是嗎?

2.在CT大,有一些私下的個人興趣研究,關於中醫系統晶片方面,也一些同好參予,其中有中醫以及自學中醫者(包含王唯工教授的學生),都秉持著希望可以將中醫推上國際正統科學的理想,不知道我們可以拜訪那位中醫研討嗎?

3.請問那位中醫是否姓李

謝謝