tag:blogger.com,1999:blog-1441759431140700676.post928457482226720161..comments2023-06-30T15:40:42.068+08:00Comments on 阿碼外傳-阿碼科技非官方中文 Blog: 大規模網頁綁架轉址之水落石出篇Unknownnoreply@blogger.comBlogger9125tag:blogger.com,1999:blog-1441759431140700676.post-86539402409934187742009-03-16T14:55:00.000+08:002009-03-16T14:55:00.000+08:00[TTL] 恩,很謝謝兩位的留言!所以我們整篇沒有提是誰的問題。這邊順便抱歉一點,有人問為何有時說T...[TTL] 恩,很謝謝兩位的留言!所以我們整篇沒有提是誰的問題。這邊順便抱歉一點,有人問為何有時說TTL=6有時說TTL=7,因為fyodor那裡tunnel經過我這邊,所以他跟我差1,以後通通以他那裡為基準。我們一直是說 route 中出問題,沒有說 route"r" 出問題。至於 route 中哪裡出問題,route中環境我們沒有資料,故我們只能說,TTL=7以下出問題--這個對我們重要,但是哪一個單位出問題,我們沒有興趣研究,整篇 blog也從未提及哪個單位出問題。況且我們也都只是某家ISP用戶,其他家我們也沒錄過,怎能說是誰的問題?。至於TTL=7範圍有多大,我們不清楚,所以我們沒有說「幾個node以下」或甚至「幾個hop以下」,避免混淆,而是說「TTL=7以下」,故並沒有錯(經過某些設備TTL不會減少的話,那都算TTL=7以下)。<BR/><BR/>雖然誰出問題我們沒有興趣,但是TTL=7對我們的研究來說是有意義的,因為這表示不論server farm是否同時也有問題,至少在路徑中就已經有攻擊程式。這資訊對我們研究究竟是何種攻擊也很有用。而錄到的封包對我們也很有意義,因為這表示,不是DNS的問題,也不是ARP掛馬(至少錄到的部分不是),而確定有none-blind IP spoofing。<BR/><BR/>最後,真的很感謝大家的留言,但我們別一直討論是哪家的問題了,wayne與fyodor剛好都是某家的用戶,所以只有錄了這家的流量,這樣對他們不公平...我們多focus在技術方面就好 :)Wayne Huanghttps://www.blogger.com/profile/16812934095135423880noreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-53247592290079154072009-03-16T14:21:00.000+08:002009-03-16T14:21:00.000+08:00回答前一位匿名關於 TTL 的問題的確有可能會有一些設備去作流量攔截 - 但是在 ISP 的環境內我...回答前一位匿名關於 TTL 的問題<BR/><BR/>的確有可能會有一些設備去作流量攔截 - 但是在 ISP 的環境內我沒有見過有人擺 Inline 的 AV/AntiSpam Gateway, 在 backbone 擺這樣的設備一則容易造成 single point of failure, 二則沒有幫 ISP 賺錢 (撐 backbone 的設備很貴的) 這種吃力不討好的事中華電信應該不會幹才是<BR/><BR/>實際上也沒有看 ISP 會在這邊放 inline IPS (理由同上)<BR/>Inline IPS 也不應該回 TCP session - 基本上 IPS 檢查封包沒問題後只會放行封包 並不實際攔截這樣的 session<BR/><BR/>至於是什麼設備攔截封包 是不是駭客攻擊<BR/>這邊的人大概都沒辦法存取實體設備 只有中華電信能說明了<BR/><BR/>-W4yAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-2665319316274108812009-03-16T12:54:00.000+08:002009-03-16T12:54:00.000+08:00恩,你講的沒錯,這就是我們用的方法:1. 設定 TCP payload TTL,然後產生定期的流量。...恩,你講的沒錯,這就是我們用的方法:1. 設定 TCP payload TTL,然後產生定期的流量。謝謝你幫我們說清初,當初本來不想講太清楚,怕之後測不出來了,因為這樣的測試是可以被破解的。Wayne Huanghttps://www.blogger.com/profile/16812934095135423880noreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-74691331224090740862009-03-15T20:35:00.000+08:002009-03-15T20:35:00.000+08:00如果這個結論是由改TTL去測試來判斷的,仍然太武斷。像是L4 Switch, Transparent...如果這個結論是由改TTL去測試來判斷的,仍然太武斷。像是L4 Switch, Transparent proxy, 某些 AntiVirus/AntiSPAM gateway, 或某些IDP都是用session hijacking來實作過濾。亦即,只要在TTL=6的地方有這些設備,仍然會將遠端機房的資料抓給你。因此問題點並不是絕對在TTL=6底下。<BR/><BR/>而以受害端地域分布這麼廣的狀況,以及中華電信的性質,問題點在TTL=6底下的機率,遠比在TTL=6有這類設備的可能性來的低。<BR/><BR/>當然,這些設備被打進去的可能性也不是沒有,但跟在遠端機房內其他任一機器被打再作ARP spoofing的可能性還比,顯然又低更多。Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-56937065560202966742009-03-15T14:18:00.000+08:002009-03-15T14:18:00.000+08:00Wayne 這邊有可能省略了測試的一些步驟這邊之所以能確定 TTL=7 的節點下出問題 是因為測試...Wayne 這邊有可能省略了測試的一些步驟<BR/>這邊之所以能確定 TTL=7 的節點下出問題 是因為測試用的 tcptraceroute 上可以設定 TCP payload 的 TTL<BR/><BR/>簡單的說可以控制這條魚線可以跑多遠<BR/>而當 TTL=7 的時候 開始發現有回傳的封包<BR/>這代表七個網路節點內有設備作怪<BR/>如果不是 ISP 佈署了特殊的設備 就是駭客的程式放在這<BR/><BR/>更詳細的作法是可以大量的產生這樣的流量定錨<BR/>如果駭客是玩骰子決定要不要丟回應的 可以用大量的流量去找出有問題的節點到底是哪一個Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-31296447580158517432009-03-14T15:11:00.000+08:002009-03-14T15:11:00.000+08:00恩,謝謝!(1) 是否能公佈您在做 tcptraceroute 時的 tcpdump?可以,請寄信來...恩,謝謝!<BR/>(1) 是否能公佈您在做 tcptraceroute 時的 tcpdump?<BR/>可以,請寄信來,我們寄給您:wayne鼠armorize點c-o-m,不想讓這種偵測方法一下子就失效。另外這個traceroute是我們改過的,發的是跟IE一樣的HTTP GET封包。攻擊程式很挑封包。<BR/>(2) 您最後收到的 FIN 封包內容或過程中有看到轉址封包嗎?FIN的封包內容就是meta refresh轉址到那個惡意網站,當這個假封包先到時,轉址會成功。您寄信給我我把dump寄給您。Wayne Huanghttps://www.blogger.com/profile/16812934095135423880noreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-59544770060259150272009-03-14T15:02:00.000+08:002009-03-14T15:02:00.000+08:00恩,不是這樣子。推論攻擊在TTL=6或以下,是因為TTL=6時,出現IP spoofing,回來的T...恩,不是這樣子。推論攻擊在TTL=6或以下,是因為TTL=6時,出現IP spoofing,回來的TCP s/n也對,故判定攻擊點一定在TTL=6或以下的route上,這跟另一個route有被攻擊或沒被攻擊,沒有關係。另一個route只是畫出我們實際上的測試環境--兩條route,一條一直有spoofed封包,一條則沒有。這個測試的方法(原本不想講太明,因為攻擊者很容易破解),是我們修改traceroute程式,變成發出不同TTL的HTTP GET封包,而封包跟IE發出的GET封包長得一樣。因為在TTL=5時,不會收到假封包,但是在TTL=6時會,故判斷有攻擊點位於從我到TTL=6的這段route上。不論另一條有沒有被攻擊,都不會影響我們的判定--攻擊的方式是none-blind IP spoofing,而攻擊程式位於離我TTL=6以下的route上。如果如你所說的,攻擊程式在更上方,而利用來源地區選擇攻擊與否,那麼就不會TTL只等於6時,我們就收到了假封包(s/n正確)--因為TTL只等於6,封包根本不會再往上走。<BR/><BR/>最後關於您說,「如果不是man-in-the-middle...」這段,簡單回應如下,等等另寫一篇回您好了。如果是像zxarps這種把TCP session hijacking實做得很完整,會改TCP seq/ack,那麼網路上幾乎看不到異常的封包,也不會有現在我們看到的spoofed IP packet。那麼如果不是MITM,就一定會有大量的假封包嗎?不一定,看攻擊程式想如何做。一開始,我們看到只有一個封包,並帶FIN把連線中斷。這樣優點是乾淨俐落,比較不會被監控程式發現,但是缺點是,因為沒有含原內容,故使用者很容易發現。<BR/><BR/>我們來想一想,根據我們收到的封包,確定:1.攻擊者在route中間(你要說這是MITM也可以),2. 攻擊者可以監聽到封包,3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到,為何不直接使用類似zxarps這種完整的TCP session hijacking呢?因為如果使用zxarps的話,我們在家裡根本不會收到真假封包,這個攻擊就更隱密了。<BR/><BR/>原因是,zxarps的使用,需要很多環境的配合,譬如要在ethernet上(ARP spoofing只能在ethernet類的網路上用),要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包,那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路會癱瘓。另一方面,很多路由器周邊並沒有接ethernet,ARP spoofing派不上用場。<BR/><BR/>所以依我們的經驗,在以上三個條件都滿足下,還是有很多攻擊者會選擇用none-blind IP spoofing而不用zxarps這種ARP spoofing+TCP session hijacking,因為後者需更多條件,也因此後者比較常見於使用者端或Web伺服器端,而非route中間。<BR/><BR/>None-blind IP spoofing被攻擊者喜愛的另一個原因,就是因為他需要的封包少。例如在一開始的案例中,只用一個封包就可以達到轉址的目的了,而不用實做整個複雜的TCP session hijacking。Wayne Huanghttps://www.blogger.com/profile/16812934095135423880noreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-46992990379738446972009-03-14T11:45:00.000+08:002009-03-14T11:45:00.000+08:00Hi! Wayne,很高興看到國內有你們這樣的專家,全力地追蹤這個事件!對於您追蹤的方法,個人有以下...Hi! Wayne,<BR/><BR/>很高興看到國內有你們這樣的專家,全力地追蹤這個事件!對於您追蹤的方法,個人有以下幾點建議:<BR/>(1) 是否能公佈您在做 tcptraceroute 時的 tcpdump?<BR/>(2) 您最後收到的 FIN 封包內容或過程中有看到轉址封包嗎?<BR/>謝謝!!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1441759431140700676.post-29495150756340340422009-03-13T23:56:00.000+08:002009-03-13T23:56:00.000+08:00那個210.65.255.241的推論其實看不太懂,該不會因為兩者匯流於211.22.33.225,...那個210.65.255.241的推論其實看不太懂,該不會因為兩者匯流於211.22.33.225,所以直接推斷前一個hop,或TTL=6以下的hop必定是問題點吧?<BR/><BR/>這樣的推論好像太武斷了,因為B支會收到spoofed封包,只代表B支符合被spoofed條件,而非一定是發生在A支與B支不同的子路徑上。<BR/><BR/>例如,攻擊條件可能是以來源地區作判別條件,或針對機房中數台分流主機的其中一台作arp spoofed,都會有B支被 spoofed但A支沒事的情況。<BR/><BR/>另,如果不是man-in-the-middle,則應該會收到大量失效的真封包,包含真正的首頁內容,亦即GET / 後會收到兩個頁面,一個為spoofed host回的,一個為real server回的。但是似乎後者的封包量在測試時出現太少了些。Anonymousnoreply@blogger.com