駭客間的戰爭已經不只是個人對個人,而已經擴大成國家對國家。一個國家為了獲取他國的機密文件、情報、個人資料等,都會想盡各種辦法入侵帳號、寄送惡意郵件、釣魚盜取密碼等。而身為受害者的我們能做什麼呢?Google 官方提出的建議是:加強密碼安全、注意登入 IP 位址、更新自己使用的軟體、開啟二階段驗證。當然有良好的資安意識才是更重要的。
正好今天收到一個簡單的案例,提供給各位參考。
在信箱中躺著一封很像是國外客戶的信件「Company Profile / Order Details」。內容看起來也很正常,並且附上了公司的基本資料為附加檔案。
點開附件,會發現畫面先跳了 JavaScript 警告視窗後,隨即導向到 Google 登入頁面。
注意看,這個登入頁面是真的嗎?有沒有發現畫面上的「Stay signed in」前面的勾變成方框了?瀏覽器上的網址也是在本機的位址。想想看,怎麼可能點了附件之後,跳轉到 Google 登入畫面?
讓我們看一下原始碼,會發現他的 form 被改成一個奇怪的網址,看起來就是惡意網站。其餘網頁的部份都是從 Google 真實的登入頁面抓取下來修改的。因此只要一不注意,就會以為是真的 Google 登入畫面而輸入帳號密碼。
節錄部分 code 如下:
發現了嗎?其中 form 的 action 欄位被取代成「http://cantonfair.a78.org/yahoo/post.php」,而這個頁面會直接接收受害者輸入的帳號密碼,並且自動跳轉到真正的 Google 登入頁面。攻擊者從 a78.org 這個網站中直接取得所有被駭的人輸入的帳號密碼。
不隨便開啟附加檔案:附件常夾帶惡意程式、執行檔、惡意文件、釣魚網頁等,切勿隨便開啟。可使用 Google Docs 開啟附件文件防止惡意文件攻擊 Adobe PDF Reader、Microsoft Office 等程式。更常有把惡意程式加密壓縮後寄出,在信中附上密碼,借此規避防毒軟體的偵測,不可不慎。
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.
怎樣的站台會是重點目標呢?含有會員機制的網站特別如此,例如 Web Mail、社群網站等等。因此不少企業要多注意了,例如全世界最大的社群網站 Facebook、SlideShare、台灣知名電信公司網站、社交平台、網路銀行、NAS,都會在這波的攻擊範圍之內。如果沒有儘速修復,等到更有效的攻擊程式出現,就真的等著失血了。
小結
就連 OpenSSL 這種歷史悠久而且重要的函式庫,都可能犯這種基本的 C 語言程式設計錯誤,老舊的程式碼一定有不少陳年遺毒,如果沒有徹底清查,類似的心臟噴血事件會不斷上演。大家快點止血吧!
The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.
廠商的設備目前狀況特別嚴重,因為所有同個版本的設備都會受影響,而在廠商釋出更新之前,只能被動的等待更新。若沒有繼續簽訂維護約的設備,也只能繼續跟廠商簽約更新,或者是看廠商是否可以直接提供更新檔。如果有 VPN Server 等服務更要注意,如果被攻擊者取得帳號密碼,等於如入無人之境,直接使用你的帳號登入到企業內網,不可不慎。
各家系統更新的速度?
引述自好朋友 Ant 的文章,各家作業系統、網站的更新速度,代表著企業重視資安的程度以及針對資安事件緊急應變的效率,也可以作為我們挑選系統、網站、廠商的依據。
DNS 是在 1983 年由 Paul Mockapetris 所發明,相關規範分別在 RFC 1034 以及 RFC 1035。其主要作用是用來記憶 IP 位址與英文之間的對應關係,讓人類可以用較簡單的方式記得主機名稱。目前一般民眾大多使用 ISP 或國際知名公司提供的 DNS server,如中華的 168.95.1.1 或是 Google 的 8.8.8.8 等等。
然而對於企業而言,可能需要架設大量機器或內部系統,又希望以簡單的方式記憶主機名稱,因此許多企業有自行架設 DNS server 的需求。同時企業通常也會建立幾台備援 DNS server,以避免 DNS 服務忽然中斷。但是當企業有多台 DNS server 時,就必須考量 DNS 記錄的同步問題,通常會使用 zone transfer 這個功能來同步記錄。
然而若管理者未做好相關設定,使所有來源皆可對企業的 DNS 主機進行 zone transfer 查詢,則有機會讓此功能成為企業遭受攻擊的起點。用現實生活情境舉例的話,對外開放 zone transfer 就如同所有人都可以任意查詢你名下的所有房地產位在何處,假如有人要針對性的攻擊你,隨時都可以去看你某個房地產有沒有哪扇門窗沒關好,伺機入侵你的家園。一般我們對企業資訊系統進行滲透測試時,在資訊搜集的階段也會先從 domain name 下手,因此 DNS 相關資料的重要性可見一斑。
Zone transfer 的資安議題早在 1999 年就已有人提出,理應成為各企業進行資安稽核的步驟之一。然而十五年過去了,在近期我們卻發現許多國內大企業仍有此問題,令人非常驚訝!究竟企業該如何檢測自身是否存在這種安全漏洞?此問題目前在台灣網路環境佔有多大的比例?Zone transfer 會對企業造成什麼影響?讓我們繼續看下去~
如同上次 HTTP Headers 資安議題所探討的對象,我們從 TIEA 成員以及 Alexa TW top 525 觀察 zone transfer 問題分別在這些族群中佔有多少比例。
根據我們監測的結果,在目前 TIEA 的 132 名成員中,有 20 個網域存在 zone transfer 問題,佔了 15.15%。而在 Alexa TW top 525 當中,有 48 個網域存在 zone transfer 問題,佔了 9.14%。乍看之下比率似乎不高,但是在上述兩個族群的網域當中,包括:
電信商
多家電視媒體
多家網路新聞媒體
多家線上購物網站
知名團購網站
知名金流公司
知名線上音樂服務
台灣企業不夠注重資訊安全,罔顧客戶資料安全性,早已不是新聞。然而若企業不顧自身商業利益與責任,當彼此無商業往來時,我們也無法一一咎責。但若連台北市政府、教育部、多間大專院校都有此問題,就令人不太能接受了,這些政府單位與教育機構理當為我們的個人資料安全性負起全部的責任,不應該漏掉任何一個資安環節。上述結果顯示出台灣從政府到企業可能都沒有徹底落實 DNS 的資安設定,而且目前的數據僅僅是針對 TIEA 成員以及 Alexa TW top 525 進行檢測,若是對全台灣或是全世界進行大範圍的檢測,恐怕會發現更多驚人的案例!
對企業的潛在影響
洩漏網域名稱
一般企業在進行滲透測試時,通常只會挑幾個最重要、最常面對客戶的網域進行測試,但是入侵者可不會這麼乖。當有人嘗試要入侵企業時,必定是先進行全面的偵查,觀察企業哪幾個網域所執行的 service 有潛在的弱點,或是看哪幾個網域防禦力道較弱,再從該處下手。因此 zone transfer 問題所提供的完整 DNS 記錄,就為入侵者省下了許多偵查的工夫。
洩漏外網 IP 範圍
當攻擊者取得 zone transfer 所洩漏的資料後,可合理推斷哪些網段是屬於該企業,進一步對該網段進行掃描,嘗試找尋有機會入侵之標的物。
洩漏內網 IP 範圍
有些管理人員、開發者為求內部開發方便,經常會將網域名稱跟內網 IP 位址綁在一起,例如將 phpmyadmin.example.com 設定為 192.168.1.100,攻擊者就可根據此類資訊猜測內網哪些網段存在重要服務。這種設定平常也許不會造成重大損害,但是當管理者疏於建立內網防禦機制,恰好企業又被入侵至內網時,造成一連串重大損失的機率將會大幅提高。
解決方式
Linux
若使用 Linux,可在 /etc/named.conf 內加入下列選項,以限制可存取 zone transfer 的來源:
DNS 在做 zone transfer 時是使用 TCP 53 port(有別於一般 DNS query 的 UDP 53 port),因此有些人會認為將 TCP 53 port 關閉就可以對付 zone transfer,而不想修改 zone transfer 的設定。其實這個觀念只對了一半,若 zone file 的資料小於 512 byte,仍然可以透過 UDP 傳輸。即使 zone file 的資料大於 512 byte,也可以用 Incremental Zone Transfer (IXFR) 的方式取得部分資料。
結論
如果企業今天非常有自信能夠替所有網域都準備好完善的安全措施,那麼 zone transfer 所洩漏的資料對該企業就不會有太嚴重的影響。然而,在現今這個入侵手法日新月異的世界裡,又有誰能夠永遠保證自己的安全防護已經做足了呢?在前陣子火紅的 OpenSSL CVE-2014-0160 Heartbleed 問題被爆出來之後,我們就藉由許多 zone transfer 的記錄觀察到全世界有非常多企業只修復了主要網站的 OpenSSL 漏洞,卻忽略了企業內其他的服務與設備可能也有此漏洞,像是 DB、Email、VPN、NAS 等等,直到今日仍遲遲未修復。
我們可以用一個譬喻來表示:你加入了一個秘密俱樂部,填寫完會員資料後,得到了一張會員卡。之後只要憑這張會員卡,就可以進入這個俱樂部。但是隔天,你的會員卡掉了。撿走你會員卡的人,就可以用你的會員卡進入這個秘密俱樂部,因為會員卡上沒有你的照片或是其他足以辨識身分的資訊。這就像是一個會員網站,我們申請了一個帳號(填寫會員資料加入俱樂部),輸入帳號密碼登入之後,得到一組 Cookie,其中有 Session ID 來辨識你的身分(透過會員卡來辨識身分)。今天如果 Cookie 被偷走了(會員卡被撿走了),別人就可以用你的帳號來登入網站(別人用你的會員卡進入俱樂部)。
Session 攻擊手法有三種:
猜測 Session ID (Session Prediction)
竊取 Session ID (Session Hijacking)
固定 Session ID (Session Fixation)
我們以下一一介紹。
Session Prediction (猜測 Session ID)
Session ID 如同我們前面所說的,就如同是會員卡的編號。只要知道 Session ID,就可以成為這個使用者。如果 Session ID 的長度、複雜度、雜亂度不夠,就能夠被攻擊者猜測。攻擊者只要寫程式不斷暴力計算 Session ID,就有機會得到有效的 Session ID 而竊取使用者帳號。
再回頭來以這封信為例,最大的破綻除了非制式的內文之外,就屬署名了。明明是假造「Apple Customer Support」的來信,最下面卻簽署「Microsoft Privacy and cookies Developers」,有沒有搞錯?可以再用點心嗎?
連結
最後的重點就是信件中的釣魚連結了,通常這個連結會帶你前往一個長得跟官方網站一模一樣的登入頁面,騙你輸入帳號密碼登入來竊取。在點選超連結之前,一定要先看一下這個連結前往的位置是不是官方的位置,例如是 Apple 的信件通常就會是前往 Apple.com 自己的網域名稱。當然更要特別注意的是假造的網域名稱,例如使用「App1e.com」來偽裝成「Apple.com」,也是非常常見的。
在這種架構下的 WAF 看似對後端的伺服器多了一份保障,但也並非完美。其問題是後端的 Web Server 在透過 WAF 存取的情況下,無法得知來自 Client 端的來源 IP,相反的 Web Server 能看到的 IP 都將是 WAF 的 IP (REMOTE ADDR),在這種情況下可能造成 Client 端可以存取受 IP 來源限制的系統。延伸閱讀:如何正確的取得使用者 IP?。
以下圖為例,網站本身只允許 192.168.x.x 的網段連線,如果今天 Client IP 是 1.1.1.1,將無法存取該網站。
如果建置了 WAF,有關 IP 的設定必須要從 WAF 支援的 HTTP Header 中取出使用者的 IP (REMOTE_ADDR),才能讓原本網站的 IP 限制生效。在這種設定錯誤或是對 WAF 架構不瞭解的情況下,WAF 反而成為駭客繞過 Private IP 限制的跳板,就如同為駭客開了一個後門。因此在使用資安設備時,必須瞭解其架構。別讓資安設備、安全機制,反而使得伺服器更不安全。
-(void)connection:(NSURLConnection*)connectiondidReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge*)challenge{if([[[challengeprotectionSpace]authenticationMethod]isEqualToString:NSURLAuthenticationMethodServerTrust]){do{SecTrustRefserverTrust=[[challengeprotectionSpace]serverTrust];if(nil==serverTrust)break;/* failed */OSStatusstatus=SecTrustEvaluate(serverTrust,NULL);if(!(errSecSuccess==status))break;/* failed */SecCertificateRefserverCertificate=SecTrustGetCertificateAtIndex(serverTrust,0);if(nil==serverCertificate)break;/* failed */CFDataRefserverCertificateData=SecCertificateCopyData(serverCertificate);[(id)serverCertificateDataautorelease];if(nil==serverCertificateData)break;/* failed */constUInt8*constdata=CFDataGetBytePtr(serverCertificateData);constCFIndexsize=CFDataGetLength(serverCertificateData);NSData*cert1=[NSDatadataWithBytes:datalength:(NSUInteger)size];NSString*file=[[NSBundlemainBundle]pathForResource:@"random-org"ofType:@"der"];NSData*cert2=[NSDatadataWithContentsOfFile:file];if(nil==cert1||nil==cert2)break;/* failed */constBOOLequal=[cert1isEqualToData:cert2];if(!equal)break;/* failed */// The only good exit pointreturn[[challengesender]useCredential:[NSURLCredentialcredentialForTrust:serverTrust]forAuthenticationChallenge:challenge];}while(0);}// Bad dogreturn[[challengesender]cancelAuthenticationChallenge:challenge];}
對於這樣海量收集資料衍生的資安議題,我們認為最大的受害者,是物聯網的使用者!就我們的觀察,物聯網的設備通常安全防護不佳,容易遭受到駭客攻擊,前陣子 HP 也出了一份報告指出,物聯網的設備有七成存在弱點,而且每台設備平均有 25 個弱點。除此之外,物聯網的設備不易更新,少有人會定期更新,更導致物聯網設備可以被大範圍的攻擊,進而滲透家用網路,危害使用者居家隱私。這是個未來需要持續關注的重要議題。
這是一個非常經典的案例!一般攻擊者入侵攝影機最常見的就是為了偷看攝影機畫面,再進階一點的可能會控制該攝影機進一步攻擊內網。而這家廠商身為知名保全公司投資成立的安控公司,理當為客戶的監控畫面做最周全的規劃、最謹慎的防護,但是結果呢?報告各位,完全沒有任何防護!只要連到 IP 位址就可以直接看到攝影機畫面,也是屬於裸奔一族…
在物連網的時代中,各種可進行無線通訊的設備被攻擊的事件屢見不鮮,例如 2011 年知名駭客 Jay Radcliffe 在 Black Hat 展示如何攻擊胰島素注射器,2013 年已故駭客 Barnaby Jack 原本要在 Black Hat 展示如何利用藍芽通訊控制心律調整器,甚至 2014 年甫推出的可遠程變換顏色燈泡也被揭露有資安問題。在不久的未來,這些資安問題只會更多,身為民眾、企業、廠商的你,準備好面對萬物皆可駭的物連網時代了嗎?
In Rails, controller actions and views can dynamically determine which view or partial to render by calling the “render” method. If user input is used in or for the template name, an attacker could cause the application to render an arbitrary view, such as an administrative page.
Care should be taken when using user input to determine which view to render. If possible, avoid any user input in the name or path to the view.
OWASP 是說,如果你的樣板路徑是動態產生的,而且使用者可以控制那個樣板路徑,那麼使用者就可以讀取到任意樣板,包含管理介面的樣板。這樣的描述感覺還好,但就我們的發現,這其實是更嚴重的直接存取物件問題(Insecure Direct Object References),甚至有機會造成遠端命令執行(Remote Code Execution),怎麼說呢?我們直接看下去。
基本細節
一個動態樣板路徑的寫法如下:
而 index 的樣板內容是這樣:
另外建一個 demo 樣板做示意:
實際測試,如果我們連到 WelcomeController 的 index action,不帶任何參數會讀取 index 模版。