Asprox殭屍網路重生

作者:Nart Villeneuve(資深威脅研究員)

雖然垃圾郵件 殭屍網路是以發送不受歡迎的廣告郵件著稱,尤其是那些賣假藥的公司,但他們同時也是散播惡意軟體不可或缺的一部分。除了發送自己的惡意軟體好提高自己殭屍網路的規模,安裝其他的惡意軟體也讓這些幕後黑手們可以通過按次付費安裝模式來賺錢。

趨勢科技已經研究過惡名昭彰的Asprox垃圾郵件殭屍網路的運作模式。Asprox以發送偽裝成來自快遞公司(像是FedEx、DHL和美國郵局)的垃圾郵件(SPAM)而著稱。雖然Asprox殭屍網路只在過去幾年間被偶爾的提到,但其他類似手法的攻擊活動,還有利用知名航空公司的假機票詐騙(像是達美航空和美國航空)都受到相當的關注。

這些攻擊活動很少跟Asprox殭屍網路相連結。甚至更少看到關於這殭屍網路運作的分析報告。這怎麼可能呢?Asprox進行了一些修改讓自己變得更有效果:

  • 它使用成套的垃圾郵件(SPAM)範本,透過多種主題和語言去誘騙使用者打開惡意附件檔或點入惡意連結。
  • 它採用模組化的框架(利用KULUOZ惡意軟體),所以殭屍網路營運商可以在有需要時輕易地添加新功能。同時還用RC4加密以對抗網路層偵測技術。
  • 它擁有多個垃圾郵件(SPAM)郵件模組,其中一個會利用被入侵的合法電子郵件帳號來對抗使用信譽評比技術的反垃圾郵件系統。
  • 它會部署掃瞄模組,命令受感染電腦掃描網站漏洞。這是為了要透過被入侵淪陷網站來散播惡意軟體,以避免被網頁過濾和信譽評比技術偵測。
  • 它會散播資料竊取模組,讓它能夠取得受害者的FTP、網站和電子郵件帳號登錄資訊。

繼續閱讀

雲端運算風險分擔模型

作者:Jonathan Gershater

我常常會覺得有些人很奇怪,會開快車衝去機場還一邊講著手機,結果坐上飛機後卻開始祈禱著不會墜機。難道他們不知道想要安全抵達目的地,自己也承擔部分的責任嗎?

趨勢科技在討論新支付卡產業資料安全標準(PCI DSS)雲端運算準則的網路研討會中提醒到,雖然雲端服務可以有效地轉移掉資料中心的負擔,但不代表你的安全責任也是。(錯過這和Amazon和Accuvant一起的熱門網路研討會?點入這裡看重播)。

 

當組織在自己的資料中心內管理應用程式,他們控制也負責實體、網路和應用程式的安全。當組織將應用程式放入雲端環境時,他們也不能完全免除對自己應用程式安全性的責任,想要兩手一攤的說:「放到雲端服務上了,雲端服務供應商要負責。」因此就有了「責任分擔」或「風險分擔」的概念出現。公共雲供應商和雲端用戶需要共同對雲端應用程式的安全負責。

AWS(亞馬遜網路服務系統)詳述了雲端供應商和客戶所必須負的責任。

公共雲供應商(如AWS),通常會提供下列服務:

  • 防護外圍網路和資料中心
  • 外圍網路防火牆
  • 備援和高可用性儲存裝置(S3),資料庫和網路基礎設施
  • 故障轉移(亞馬遜主機可用區域(Amazon availability zones))

你(雲端用戶)要負責:

  1. 身份管理和存取控制。AWS用戶可以利用AWS基於角色的存取控制來確保存取AWS虛擬主機的人只擁有符合自己角色的權限。例如,管理者可以獲得存取AWS虛擬主機的所有權限,稽核人員可能只有查看設定或日誌檔的權限。此外,使用者要保管好用來連線到AWS虛擬主機的AWS存取和秘密金鑰,只有被允許存取虛擬主機的使用者擁有適當的金鑰。
  2. 加密運輸過程和磁碟上的敏感資訊。客戶需要用SSL加密所有通訊,並且加密AWS卷宗/磁碟。這可以確保任何網路通信被截獲或卷宗/磁碟被未經授權者存取時,資料是安全的,不能被讀取。
  3. 在AWS虛擬主機上的入侵偵測和防火牆。客戶應該在AWS虛擬主機上安裝防火牆和入侵偵測。客戶可以控制防火牆和入侵偵測規則。這些規則甚至可以依照AWS虛擬主機上所安裝的作業系統和應用程式來加以自動佈署。
  4. 確保應用程式和作業系統都安裝了修補程式並且更新到最新。雖然大多數應用程式和作業系統都有自動更新服務,但往往都會造成停機時間,讓使用者和服務產生中斷。為了減少這樣的干擾,同時減少資料外洩,入侵偵測系統可以防禦想要攻擊軟體漏洞的駭客攻擊。
    繼續閱讀

黑洞漏洞攻擊包(BHEK)利用Java漏洞, 試圖竊取儲存在瀏覽器內的資訊

作者:Romeo Dela Cruz(威脅反應工程師)

趨勢科技二〇一三資安預測裡,我們提到傳統的惡意軟體會專注在加強現有的武器,而非開發新威脅。可以佐證這一預測的好例子就是黑洞漏洞攻擊包不斷地改進自己以繞過安全偵測。事實上,我們最近發現了一起黑洞漏洞攻擊包(Blackhole Exploit Kit :BHEK)會利用一漏洞攻擊碼(趨勢科技偵測為JAVA_ARCAL.A)來攻擊最近被修補的CVE-2013-0431

如果使用者還記得,這漏洞是去年一月造成Java零時差攻擊騷動的一部分。也讓甲骨文釋出非週期性安全更新以快速地解決這個問題。只是這更新程式本身也有些嚴重的問題

這特殊的BHEK(Blackhole Exploit Kit)攻擊是從偽裝成PayPal的垃圾郵件(SPAM)開始。當使用者點入這封郵件內的內容時,會被重新導向到數個網站,最終來到藏有加密過BHEK程式碼的網頁。這程式碼會檢查訪客系統是否有Adobe Reader、Flash player和Java的相關漏洞。然後決定下載哪個漏洞攻擊碼(以及後續的行為)到系統內。

BHEK(Blackhole Exploit Kit)攻擊:偽裝來自PayPal的電子郵件樣本
圖一、偽裝來自PayPal的電子郵件樣本

經過趨勢科技的測試,這BHEK程式碼會檢查某些版本的Adobe Reader,讓它下載並執行一個惡意PDF檔案(被偵測為TROJ_PIDIEF.MEX),並攻擊一個舊漏洞CVE-2010-0188。

這BHEK程式碼也會在檢查受影響系統的Java版本,接著從一特定網頁下載並執行JAVA_ARCAL.A。JAVA_ARCAL.A接著會用%user%路徑下的command.exe來從一特定網址下載並執行TSPY_FAREIT.MEX。這行為會打開另一個網頁。根據趨勢科技的分析,TSPY_FAREIT.MEX會試圖竊取儲存在瀏覽器內的資訊,包括Chrome、Mozilla Firefox和Internet Explorer。最後,這BHEK程式碼將連上下列的惡意網頁,想讓使用者認為自己只是被重新導向到非惡意網站。

BHEK(Blackhole Exploit Kit)攻擊: 會試圖竊取儲存在瀏覽器內的資訊
圖二、感染鏈的最終目標網頁

 

趨勢科技主動式雲端截毒服務  Smart Protection Network的資料中,我們可以看出這起BHEK攻擊所影響最嚴重的國家和一些有意思的結果。受影響最嚴重的國家是美國,其次是墨西哥。這很讓人驚訝,因為墨西哥在過去的BHEK攻擊裡並沒有顯著的影響。這波BHEK受影響最嚴重的國家還包括德國、拉脫維亞、日本、澳洲、英國、法國、西班牙和義大利。

繼續閱讀

十大AWS安全祕訣:第二條,密碼策略和多因子身分認證

作者:Mark Nunnikhoven

在介紹如何利用AWS身份和存取管理來保護資源的文章裡,Justin介紹了AWS身份存取管理(IAM)的基本知識。今天我們要來看看如何使用IAM來設定密碼策略和多因子身分認證。

密碼策略(Password Policies)

使用強密碼的重要性是眾所周知的。大多數組織都已經有了密碼策略。這種策略通常會定義複雜度(像是包含多少個數字、特殊字元和密碼長度等),以及變更週期(像是每九十天就必須變更密碼)。

有些策略會更進一步,對於不同的設備或角色有不同的要求。CSIS的前廿項控制裡的第12項 – 「控制管理權限的使用」裡介紹了密碼策略的強化。就是要確保具有管理存取權限的人使用複雜密碼,並且必須一年變更好幾次。

IAM目前提供了一連串的設定來強制執行密碼策略。你可以為你的AWS帳號設定密碼策略。這策略可以讓你定義密碼的複雜度,但並不能設定變更週期。

現在就開始使用密碼策略是很棒,但你需要手動要求使用者定期變更密碼,或是採取別的方法加強……或是雙管齊下!

多因子身份認證

AWS的多因子身份認證(MFA)正是我們用來加強密碼策略的方法。

那麼,到底什麼是MFA?就是使用一個以上的認證因子來驗證誰是使用者。有三個常見因子:你知道什麼東西(something you know)、你擁有什麼東西(something you have)和你的生物特徵(something you are)。

 

我們的使用者已經具備了一個因子,就是密碼(使用者知道的東西)。對於AWS,第二個因子是使用者擁有的東西。可能是硬體認證裝置(可向AWS購買)或用軟體認證裝置,安裝在智慧型手機或其他設備上。

這些認證裝置會顯示隨機生成的數字,必須在使用者輸入自己的帳號和密碼登錄AWS管理控制台時輸入。這數字每隔幾秒鐘就會變化一次,以確保使用者在登錄時有認證裝置在身上。

現在想要認證成功,就必須輸入正確的帳號密碼,加上由正確認證裝置在使用者登錄當下所產生的數字。

繼續閱讀

< 雲端運算 >十大AWS亞馬遜網路服務安全祕訣:第一條,用IAM保護你的資源

在接下來的幾個星期,我們將會探討如何防護AWS(亞馬遜網路服務)環境的最佳做法。在我們深入到防護你的虛擬機器、應用程式和資料之前,讓我們從最頂端開始。

作為AWS共享責任安全模型的一部分,AWS消費者防護好自己的服務可以發揮重要的作用。早在二〇一二年十一月的AWS re:invent大會上,Max Ramsay就將AWS與CSIS廿個關鍵安全控制對應,作為進一步了解AWS和客戶端(你)之間共同責任的框架。關鍵控制的第十二項是控制管理權限使用,負起保護責任是身為AWS用戶的你所必須加以正視的。在接下來的幾個星期,我們會聚焦在你所需要負起責任的關鍵控制。

在虛擬化或雲端世界,管理權限就好比是作業系統上的管理者帳號。不過,現在你有更多組強大的身份需要管理,好存取AWS控制台和API。

收起你的AWS管理者(root)帳號,利用IAM(身份存取管理)來啟動存取權限

當你開始使用AWS,你會獲得一組帳號和密碼。這個帳號擁有存取你所有AWS資源和帳務資訊的權限。不要跟任何人分享!我知道有某個經理跟他的團隊共享帳號,他們很快就發現可以用經理的信用卡在Amazon.com上買東西!

確認該帳號安全後,接著進到控制台上的IAM 選項,開始定義群組和使用者。

一般情況下,你會需要兩種類型的使用者:

  • 需要帳號密碼存取AWS控制台的人
  • 使用存取密鑰帳號(Access Key Id)和秘密存取金鑰(Secret Access Key)來存取API的程式

在這兩種情況中,你會想透過群組來分配所需的最低權限給使用者。AWS會幫你提供一些策略範本。例如,你可能會想提供操作人員「Power User Access」權限,而給開發人員「EC2 Full Access」權限。 繼續閱讀