從對一個安全產品的測試看產品架構安全
博文作者：xti9er[TSRC]
發佈日期：2012-07-03
博文內容：
轉載請註明出處及作者 http://security.tencent.com/index.php/blog/msg/2 xti9er [TSRC]
前言
由於之前工作需要，筆者經常接觸一些業界安全產品，對其性能、安全性等等的分析自然是關注的重點。好的地方自然要學習，如果有缺陷的地方則值得我們自省，看自己的系統和產品是否也會有這些問題呢？
鑑於商業產品的保密性，將隱去部分敏感內容。
產品分析
產品簡介
某安全產品
產品架構
程序：Web管理界面+後臺服務。
網絡：可串聯或並聯於網絡中，管理通過web接口或自定義的console
探測分析
通過簡單的掃描分析，其web前端採用的是Apache+php+DB 架構。
安全性測試
帳戶安全
雖然此產品我們能見到的只是一個‘鐵盒子’，但通常能猜測到，它其實就是一個linux系統加自研的安全產品的形式。
它提供了console模式的管理，web管理用戶和console賬戶是同一個，我們發現如果添加的賬戶名爲root會失敗，基本上能證明他是linux系統。
除root之外的普通用戶登陸後，出現的是一個自定義的console界面，不是bash。
在這裏給大家提個醒：類似的鐵盒子(安全產品)，root賬戶和密碼是沒有提供給用戶的，也就是說開發商知道你的產品的root密碼，如果將其架設在一個外部用戶能訪問的地方，可能會導致開發商有機會登陸你的系統。就算開發商很有良知，員工不會違反職業道德，也不排除它同類產品root密碼可能一致，此商家的其他用戶獲知此密碼用於嘗試您的系統的可能性。所以此產品或管理端口，必須設置爲外網不能訪問，且內部員工僅有有限的訪問權限。
web安全
此產品提供web管理界面，web類安全問題常見的是2種：1、注入；2、xss跨站。
Sql注入自不必說，可修改DB 數據。一個依賴DB數據進行運轉的系統來說，sql注入的危害已經是非常大了。
命令注入是指某些需要將用戶輸入的數據作爲命令的一部分時，未對數據的合法性作校驗，導致惡意用戶可以隨意構造命令執行。
Xss跨站問題，大家覺得在一個後臺維護類系統上問題不大。其實不然，如果一個低端用戶(來賓訪問、廠商例行查驗)利用XSS 的ajax方式，可將自身的權限提升至受害者用戶一樣的權限。
通過簡單的測試，發現一處很明顯的sqlinject漏洞：
GET /server/ip_edit.php?id=1;select version();
從架構缺陷到系統權限
如果僅停留在web漏洞上，大家顯然覺得不過癮。下一步我們來看如何得到整個系統的權限。顯然用linux系統exploit不太可能，廠商的補丁齊全，且無gcc環境。只能改由其他途徑。
對於架構的思考：一個web系統，通過添加web賬戶，能使其賬戶也添加到系統賬戶中去，他是如何做到的呢？
我們暫且作2個假設，然後做相應的嘗試和探索，或許能繞過安全防範獲得root權限：
a) webserver 是root 權限
b) 通過db數據或其他媒介，讓一個具有root 權限的後臺程序來自動完成添加操作。
前面的sql注入漏洞，使我們已經能訪問其文件系統和執行系統命令。通過讀取此產品的後臺系統代碼。發現了確實是上述的第二個猜想。
我們在後臺系統代碼中發現命令注入漏洞，而後臺進程是root權限啓動的，通過sql注入漏洞結合某來至db的參數的命令注入漏洞，繼承了後臺進程的root權限。
So，一切都結束了。
總結與思考
對於以上產品的分析，我們總結一下它的問題。
利用sql注入漏洞，***者獲得繼承了webserver權限
利用後臺系統命令注入漏洞，***者獲得繼承了後臺系統的root權限
由此可看出，要想建設一個安全的產品和系統，權限的隔離是關鍵。但如何能做到權限隔離呢，從以下幾個方面：
網絡隔離。再NB的系統他都或多或少有些毛病，更何況是一些運維類高敏感系統。做好隔離，可以最大限度的將可能存在的風險降低到最小。
嚴格校驗數據輸入。嚴格校驗數據輸入應該是開發人員的常識，對任意一條數據來源都要假設他是‘不可靠’的，即使它來至內部系統。
最小權限原則 。最小權限原則也是一種隔離的思想，假設你的系統也不是完美了，可能會出現瑕疵和漏洞。如果它運行在較低權限，就算出現任何安全問題，也不會導致系統最高權限被***者拿到。
相信從網絡、主機、代碼三個層面的縱深防禦，您的系統將更加安全可靠。