零信任

零信任是近幾年流行的資安話題,你可能已經看過關於介紹零信任的文章,今天就讓三甲科技再帶你重新簡單地溫習這個名詞吧!

在傳統的企業網路架構上,以往我們都是透過防火牆區隔內部與外部網路,將外部網路視為威脅進行阻隔,而內部網路則視為安全區域,不做過多的防護或認證機制。然而,倘若內部網路任何一台設備遭受惡意入侵,攻擊者很有可能藉此在內部網路橫向擴散,整個內部資料遭竊取、設備遭加密勒索或是網路癱瘓。再者,技術的發展與疫情的爆發,伴隨的是網路使用習慣或基礎架構的轉變,例如雲端服務、BYOD或是居家辦公等。在這些轉變下,內部網路存在的設備已不像以前那麼單純,過往的安全架構未必仍可達到足夠的防護。

        基於上述的問題,零信任便是為了解決這些問題而發展的一個概念。單從字面上來看,或許能猜出它的大意,但所謂的「信任」指的又是什麼?在前面所描述的情境,內部資料遭受竊取的首要條件是內部網路其中一台設備被入侵,但為何僅僅一台設備被入侵就能取得整個內部的資料?就是因為內部其他的服務「信任」這台被入侵的設備,而沒有做任何驗證或限制,導致駭客可隨心所欲,想去哪就去哪。因此,零信任便是提倡即使在內部網路中,也不輕易信任任何設備,需要先經過一些驗證才可存取或提供資料。如此一來,就算有惡意人士可以入侵企業的內部網路,想存取其他的服務或設備也會變得更加困難,進而降低影響的範圍與損失。

        前兩段我們說明了零信任想解決的問題與它的概念,而到底要做哪些事才能邁向零信任?NIST在2020年8月發佈SP 800-207標準文件,內容針對零信任架構進行說明,並提供導入零信任架構的建議步驟。其中第一步即為「評估」,應先針對企業資產、資料流、系統、人員、工作流程等細節進行盤點調查。在完整了解組織的營運狀況後,便可擬定適當的零信任架構調整計畫或政策方針,接下來則包含風險評估與政策發展、佈署與作業。

By Mike

【參考資料】

[1] 【Wired 硬塞】到底什麼叫「零信任」?答案其實取決於你想聽到什麼,https://www.inside.com.tw/article/24908-what-is-zero-trust,2021-09-22

[2] 【搞懂零信任,從理解NIST SP 800-207著手】打造以零信任原則的企業網路安全環境,https://www.ithome.com.tw/news/145709,2021-07-21

[3] Zero Trust Architecture https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf, 2020-08

自動化滲透測試工具初探

  1. 為什麼需要自動化的滲透測試工具
  2. 自動化滲透測試與弱點掃描比較
  3. 結語

By Howard

按個開始按鈕,喝杯咖啡等待一小段時間,所有的檢測任務全都自動完成,包含偵查網路端口開了哪些port、系統版本比對是不是過舊,甚至系統網路設定有哪些弱點全部都檢測出來,只需要觀看結果報告就可以確切知道當前設備有哪些已知弱點漏洞,是所有資安工程師的夢想,不僅大幅降低資訊安全檢測花費的時間,更是減少執行工作的人力成本。查看結果、驗證仍須有專業資安知識有利於資安檢測的執行以及普及化。

自動化滲透測試 V.S. 弱點掃描:

目前市面上是否已經有資安檢測模式達到自動化的的情境呢?有的,弱點掃描已經發展到接近全自動的程度,按個開始按鈕一掃描下去,便可以檢測出已知的常見資安漏洞,甚至非資安專業的人員照著步驟也有機會能在短時間內學會使用弱點掃描工具,是一個簡易化的檢測方案。但弱點掃描的檢測深度卻難以與滲透測試相比,其中的原因是弱點掃描工具多數僅能將每個弱點單獨檢視,較難針對弱點進一步挖掘是不是存在其他連帶的漏洞,並梳理每個漏洞可能的關聯性。如果做個簡單的比喻,有個網頁登入口,在帳號密碼未知的情況下,弱掃僅能檢視登入口的安全性,難以進一步檢測出登入口的驗證碼機制是否不妥,因此這時候就會需要進行滲透測試。滲透測試一般會由具有豐富經驗的資安專家進行技術檢測,深度挖掘漏洞的連帶關係以及可能產生的危害,甚至會使用盲測的方式找出新的資安漏洞。但擁有如此資安技術的專家不多,除了從頭開始培養相關人才外,難到沒有其他方法嗎?有的,假如可以結合弱點掃描的自動化特性,在滲透測試的檢測面上即可大幅降低專家的依賴程度,也可進一步節省大量的檢測時間,降低資安工程師的門檻。

那麼市面上除了自動化的弱點掃描、滲透測試之外,還有沒有其他自動化的檢測項目解決方案呢?當!然!有!三甲科技推出自動化的資安健診平台,針對個人電腦、伺服器進行自動化資安健診,只需簡單的幾個步驟,即使不是資訊人員,沒有電腦背景、透過簡單介面使用學習,動動手將資料上傳至雲端,即可針對電腦、伺服器環境進行健康檢查,而且也不需耗費寶貴的電腦運算資源。太棒了,爸爸媽媽再也不用擔心我的電腦、伺服器不健康了。心動不如馬上行動,三甲科技全新推出接近全自動化的資安健診平台~您值得擁有!

Reference

[1]、2021/07/30,關於自動化滲透測試的理念,W3C學習教程https://www.w3study.wiki/a/202107/455158.html

[2]、淺析滲透測試之手動和自動的優缺點,每日頭條

https://read01.com/jNg7AMD.html#.YhSxGuhBxPY

[3]、滲透測試與自動化安全測試工具比較,IT人

https://iter01.com/653450.html

網站的上傳功能可以怎麼利用?

By Jay

  1. 說明網站可能會有任意檔案上傳弱點
  2. 可能利用的手法
  3. 如何防範

  在這個資訊普及的時代,網路上的網站越來越多,很多企業都喜歡透過網站來宣傳產品,甚至是架設電子商務網站,讓產品可以直接在網站上進行販售,但往往開發人員只注重開發流程而忽略的安全性問題,也導致很多網站型的資安弱點出現,例如Cross-site scripting(簡稱XSS)、SQL Injection及Cross-Site Request Forgery (CSRF)等弱點時常被提起探討,這次小編要介紹的就是一種常見在網站的弱點,我們團隊時常稱它「任意檔案上傳弱點」,也就是CWE於2021年列出前25名常出現的軟體弱點之「CWE-434: Unrestricted Upload of File with Dangerous Type」。

那為何網站會出現這樣的弱點?其實是因為現在許多網站需要提供使用者上傳檔案至網站上,例如大頭貼、身分證圖片及附件等,一開始是為了讓使用者方便,但這個功能在駭客的眼裡就是一個很好利用的地方,網站請使用者上傳圖檔,一般人僅會上傳對應的檔案,但駭客的思維就會想這個網站是如果沒好好限制,那我是不是可以上傳一個PHP程式碼檔案,看會不會執行?如果這時網站沒有進行安全驗證的話,通常是會上傳成功的。由上面的說明可以知道,該問題通常是,網站沒有驗證使用者上傳的檔案是否為指定的檔案格式,例如大頭貼就讓限制上傳的檔案必須為png、jpg等,那當上傳上傳能被網站伺服器端執行的檔案後,再次訪問檔案路徑時,就可以執行上傳的惡意程式碼甚至可能讓攻擊者操控主機,常這種惡意程式碼也有許多別人寫好的開源版本,例如b374k就是常見的WebShell。

根據我們的經驗只要網站出現這個弱點,時常會造成網站的重大危害,常見手法就是利用這個功能去上傳Webshell,藉此取得主機權限將網站程式碼下載下來,甚至進一步提高權限取得主機的系統權限,以佔領整台主機都是常見駭客會做的事情,因此網站出現這種類型的弱點都不可忽視,必須特別注意。如果網站不知道該怎麼確認有沒有這個弱點該怎麼辦?建議可以參考我們三甲科技的滲透測試服務!!

參考連結:

https://ithelp.ithome.com.tw/articles/10245814

N-Stalker Web Application Security Scanner X

By Mike

先前我們介紹「OWASP Zed Attack Proxy」網頁掃描工具,在文章裡我們提到檢測工具林林總總,市面上有很多工具可以選擇。那除了OWASP ZAP以外,還有哪些工具可以使用呢?各位客官有福了,今天小編再跟大家介紹另一套網頁掃描工具「N-Stalker Web Application Security Scanner X」(以下簡稱 N-Stalker X)。

N-Stalker X從名字上來看,大概可以猜出它的開發商。沒錯,就是N-Stalker。這套軟體是用於評估網頁的安全性,其結合了HTTP掃描器N-Stealth與包含39,000個網頁攻擊特徵的資料庫,以及Web應用程式的安全性評估技術可為開發者、檢測人員、IT人員進行許多不同的檢測項目。你可能會好奇到底有哪些檢測內容?N-Stalker的檢測項目遵照了許多國際標準,如OWASP Top10、PCI及SANS Top10/20。檢測內容則包含不同面向,如程式碼撰寫錯誤所衍生的漏洞、伺服器的敏感資訊外洩、備份或設定檔外洩等。

從前面的說明我們可以知道,N-Stalker X能協助執行網頁安全性評估,那什麼時候可以用到呢?N-Stalker提出了在系統發展生命週期(System Development Life Cycle, SDLC)中加入N-Stalker X以確保網頁的安全性,在設計與開發階段評估執行環境,同時檢查程式碼中的漏洞;而在測試與佈署階段,則透過工具輔助進行滲透測試,以驗證其安全性;最後於維護檢查階段,則持續並定期執行安全性評估,以管理網站的漏洞與風險。

而既然N-Stalker X和之前介紹的OWASP ZAP都是網頁安全性檢測工具,那你可能會想到底哪一套工具比較好,應該要選擇哪一個?套一句公道話「小孩子才做選擇」,每一種都試試看就知道哪一種工具比較適合你囉!


《現代加密技術 ─ 進階加密法AES》下篇

前言

在上一篇AES加密法的介紹中,我們認識到他的歷史及應用,也瀏覽在無線網路、電子商務或是軟硬體實現上的應用。而現在這一篇則是要來談談AES的元件以及其操作的原理,進一步探索該怎麼實現。

(延伸閱讀:《現代加密技術 ─ 進階加密法AES》上篇

AES加密流程

在介紹AES加密法怎麼運作之前,我們必須先了解他對於明文區塊和金鑰的長度的規範。在上篇中有提到的Rijndael演算法支援128、192或是256個位元的明文區塊,雖然原理相同,但為了方便使用,AES加密法每組只提供了128位元的區塊來存放明文資料。而金鑰長度就不一樣,由於有128、192、256三個位元長度可以選擇,因此密碼的系統有AES-128、AES-192及AES-256三種。下表可以看出三種不同長度金鑰所需要加密的輪數也有不同。

AES金鑰長度: 可分為幾個32bits區段分組長度: 128bits / 32bits加密重複次數: 6 + max(金鑰, 分組)
AES-1284410
AES-1926412
AES-2568414

那有明文跟金鑰,我們該怎麼加密呢?我們將他放在一個4*4的位元組矩陣(也稱為state)來運算,而state中的每一個元素就是明文中的一個byte,每一次加密就會進行以下四個步驟:

  1. AddRoundKey—state中的每個位元組都和金鑰做XOR運算,目的是為了混淆密文、明文和密鑰之間的關係。
  2. SubBytes—將每個位元組透過一個8位元的Substitution-box進行查找和替換輸入狀態的操作,以實現可逆的非線性變換。
  3. ShiftRows—這一步驟是讓state中每一行都偏移一些,用來提供此演算法擴散性
  4. MixColumns—將state與一個固定矩陣C相乘,使列也有擴散性。

以AES-128為例,我們已經知道總共會有10輪的加密次數,因此前面9輪其實都是重複進行上述的四個步驟,但在最後一輪中進行了特殊處理,少掉了MixColumns這一步驟,下圖簡單描述了AES-128加密的流程:

其他AES系統的做法也是依照此模型去實作,而因為加密過程有一定的規律,因此若要解密時只要照著步驟逆轉換就能得出原本的明文。或許這個加密法看似簡單、很容易就能理解,但其實它設計結構和密鑰的長度上已經達到可以保護機密資料的標準,甚至美國也已經批准將其運用在最高及國家安全機密的傳遞上。

結語

AES加密法這種被用在國家等級安全防護上的演算法,其實也可以運用在我們的日常生活中,很容易就能找到資源並利用。如果有興趣,不妨也自己嘗試使用看看這個簡單又有效的加密法吧!


HTTPS相關機制

現在許多網站為了安全性會透過HTTPS來連線,那在使用HTTPS之後,還有什麼設定能再提升網站連線安全呢?本文將會介紹HTTP強制安全傳輸技術(HTTP Strict-Transport-Security),簡稱HSTS。就算使用者是透過HTTP訪問網站,也會強制改用HTTPS,避免HTTP可能出現的風險。

HTTP vs. HTTPS

HTTP和HTTPS只差了一個「S」,而「S」指的是安全(Secure)。HTTP與HTTPS的不同,在於HTTPS傳輸時還會利用TLS/SSL來加密封包,避免被監聽造成資料外洩或是中間人攻擊等風險。

HSTS

大家可能會好奇,我的網站已經是HTTPS,就算訪客是透過HTTP來連線也會自動跳轉,那有HSTS跟沒有HSTS有什麼差別呢?

若訪客透過HTTP來訪問HTTPS網站,雖然網站可能設有自動跳轉機制,第一個連線封包仍會是未加密的。若訪問使用HSTS的網站,首次存取時瀏覽器會一併記憶,之後再訪問會自動將HTTP轉為HTTPS。

HSTS設定

Strict-Transport-Security: max-age=31536000

不同網站伺服器需有不同的設定方式,而指令意義如下:

  • max-age=<expire-time>:表示啟用的持續時間,以秒為單位。
  • includeSubDomains:(選擇性設定)瀏覽器將強制使用HTTPS的狀態套用至所有子網域。
  • preload:(選擇性設定)非HSTS規範的一部份。在訪問網站前直接使用HTTPS作為傳輸協議,能讓速度稍微加快。

Preload設定

HSTS預先載入服務由Google維護,Chrome瀏覽器中存在HSTS Preload List,會把支援HSTS網域名稱寫進去,一些主流瀏覽器(Firefox、Opera、Safari、IE 11、Edge)中也有基於Chrome清單的HSTS Preload List。

若網站確認會永久使用HTTPS協議,可主動提交網域名稱至HSTS Preload List Submission網站。不過要注意的是,將網域名稱從Preload List中移除是需要花費一段時間。Chrome可能需要幾個月的時間才能透過更新進行修改,而其他瀏覽器的狀況則無法保證。因此在新增Preload設定前,建議先評估並進行多階段的測試,確保網站沒發生問題再新增Preload設定。

在設定好HTTS後,如果還想再提升網站安全性,也許可以考慮HSTS設定。但在添加或調整任何設定前,都應該先進行評估,並確認了解所有設定的意義與影響。避免發生網站無法使用的情況。

參考資料