2017-百度-安全崗筆試

2017_baidu_spring_1

請回答如下端口默認對應的服務,以及在滲透測試過程中我們可以從哪些角度考慮其安全問題。
端口:21、22、873、1433、3306、6379、11211
端口服務說明
21FTP匿名訪問\弱口令
22SSH弱口令
873rsync未授權訪問\弱口令
1433mssql弱口令
3306mysql弱口令
6379redis一般無驗證,直接訪問
11211memcache內存泄露\未授權訪問

2017_baidu_spring_2

你所知道的網絡抓包工具有哪些?對android或者ios設備怎麼進行抓包。

tcpdump, Wireshark, Fiddler, Burp Suite, Charles
基於 WireShark 的方案:

  1. 電腦開放熱點,手機端進行連接
  2. 使用 WireShark 捕獲手機 IP 地址的流量

基於 tcpdump 的方案:

  1. 將 androidtcpdump 上傳至 android 設備中(注:需要 root 權限)
  2. 使用 adb shell (遠程 SSH 亦可)啓動 tcpdump 開始捕獲

基於 Fiddler/Burp Suite/Charles 的方案:

  1. 手機與電腦處於同一局域網中
  2. 手機代理填寫爲 Fiddler/Burp Suite/Charles 的端口
  3. 若需要捕獲 HTTPS 流量包則安裝軟件的安全證書即可

Burp Suite 是其中唯一支持交互式操作的軟件
tcpdump 需要 root 權限,其他方案都不需要
wireshark 操作最簡單,分析功能最強大,可以捕獲數據包後配合進行分析
Burp Suite/Charles 跨平臺性最好,也足夠輕量級

另外的方式是使用專門的軟件,如:AndroidHttpCapture、XCode 調試器中自帶的 rvictl 命令等

2017_baidu_spring_3

請說明黑客常用的清除痕跡的方式及對應的監控方法(linux和windows系統)

wtmp/wtmpx 記錄每次用戶登錄的信息,時間\終端\IP地址(last命令)
utmp/utmpx 記錄以前登錄到系統中的所有用戶(who命令)
lastlog 記錄每個用戶最近一次的時間和登錄點
acct 記錄用戶執行的所有命令

應用服務日誌 記錄了應用程序和系統產生的事件
系統日誌 系統自身包括驅動程序等組件產生的時間
安全日誌 與安全事件相關的信息
Elsave CLearLogs LogKiller 等程序

2017_baidu_spring_4

羅列最近幾年影響較大的安全漏洞並請大概介紹其原理、危害(請列舉3個)
  1. XcodeGhost
    簡述 2015 年 9 月,應用程序開發工具 Xcode 被篡改從而引發的安全事件稱爲 XcodeGhost,該事件影響近一億 iPhone 用戶,超過 800 個不同版本的 iOS App 被感染
    原理 攻擊者通過向官方 Xcode 集成開發工具中加入惡意庫文件,與正常庫文件混在一起。同時,修改控制編譯器鏈接行爲的配置文件,致使任何 App 的編譯過程都需要鏈接惡意庫文件,從而實現經該編譯器生成的 App 中均含有惡意代碼。之後攻擊者將被篡改的 Xcode 打包二次發佈
    危害 已經確認的是可以上傳基本系統信息和 APP 數據,可能造成的危害包括彈窗攻擊、通過 OpenURL 操作其他應用程序等
    參考資料
  2. Mirai
    簡述 2016年10月21 日晚間,北美地區大量反饋若干重要的互聯網網站無法正常訪問。這是一次 DDoS 網絡攻擊事件,攻擊目標主要 是Dynamic Network Services(dyn) 公司,twitter、paypal、github 等網站作爲 dyn 公司的客戶,在本次攻擊中不幸被波及。
    原理 攻擊者的攻擊手段是混合使用 DNSflood 和 synflood,本次攻擊中的Syn flood部分,特徵符合Mirai的流量特點,有Mirai或者其變種參與。而原始版本的mirai 在發起dns flood攻擊的時候不會僞造源IP地址,本次攻擊中參與 dns flood 的部分,要麼這些IP地址是僞造的,那麼一定不是原始版本的mirai;要麼這些IP地址是真實的,那就與mirai的關係更遠。
    危害 北美地區大量反饋若干重要的互聯網網站無法正常訪問。涉及到的網站包括 twitter, paypal,github等等
    參考資料
  3. WannaCry
    簡述 2017年5月12日,WannaCry 蠕蟲通過 MS17-010 漏洞在全球範圍大爆發,感染了大量的計算機,該蠕蟲感染計算機後會向計算機中植入敲詐者病毒,導致電腦大量文件被加密
    原理 MS17-010 漏洞利用 srv.sys 在處理 SrvOs2FeaListSizeToNt 的時候邏輯不正確導致越界拷貝。
    危害 大量計算機中招,文件被加密,勒索者要求以比特幣的形式支付贖金

2017_baidu_spring_5

介紹你所知道的加密算法,都屬於什麼類型的加密算法?怎麼保證加密的安全性?

對稱加密:DES 3DES AES
DES: DES 加密算法是一種分組密碼,以64位爲分組對數據加密,它的密鑰長度是56位,加密解密用同一算法。DES加密算法是對密鑰進行保密,而公開算法,包括加密和解密算法。這樣,只有掌握了和發送方相同密鑰的人才能解讀由DES加密算法加密的密文數據。因此,破譯DES加密算法實際上就是搜索密鑰的編碼。對於56位長度的密鑰來說,如果用窮舉法來進行搜索的話,其運算次數爲256。
非對稱加密:RSA ECC
RSA : RSA 加密算法基於一個十分簡單的數論事實:將兩個大素數相乘十分容易,但那時想要,但那時想要對其乘積進行因式分解卻極其困難,因此可以將乘積公開作爲加密密鑰。

2017_baidu_spring_6

```
PHP中瞭解有哪些容易導致漏洞的危險函數?並且簡述會造成什麼類型的風險
```

★ 命令注入
PHP 執行系統命令可以使用以下幾個函數:system、exec、passthru、“、shell_exec、popen、proc_open、pcntl_exec,確定函數的參數是否會因爲外部提交而改變,檢查這些參數是否有經過安全處理
防範方法:
1. 使用自定義函數或函數庫來替代外部命令的功能
2. 使用escapeshellarg 函數來處理命令參數
3. 使用safe_mode_exec_dir 指定可執行文件的路徑

★ 跨站腳本
輸出函數經常使用:echo、print、printf、vprintf、<%=$test%>
對於反射型跨站,因爲是立即輸出顯示給客戶端,所以應該在當前的 php 頁面檢查變量被客戶提交之後有無立即顯示,在這個過程中變量是否有經過安全檢查。
對於存儲型跨站,檢查變量在輸入後入庫,又輸出顯示的這個過程中,變量是否有經過安全檢查。
防範方法:
1. 如果輸入數據只包含字母和數字,那麼任何特殊字符都應當阻止
2. 對輸入的數據經行嚴格匹配,比如郵件格式,用戶名只包含英文或者中文、下劃線、連字符
3. 對輸出進行 HTML 編碼

★ 文件包含
PHP 可能出現文件包含的函數:include、include_once、require、require_once、show_source、highlight_file、readfile、file_get_contents、fopen、 nt>file
防範方法:
1. 對輸入數據進行精確匹配,比如根據變量的值確定語言 en.php、cn.php,那麼這兩個文件放在同一個目錄下’language/’.$_POST[‘lang’].’.php’,那麼檢查提交的數據是否是en 或者cn 是最嚴格的,檢查是否只包含字母也不錯
2. 通過過濾參數中的/、..等字符

★ 代碼注入
PHP 可能出現代碼注入的函數:eval、preg_replace+/e、assert、call_user_func、call_user_func_array、create_function
防範方法:
1. 輸入數據精確匹配
2. 白名單方式過濾可執行的函數

★ SQL注入
insert、delete、update、select
防範方法:
使用參數化查詢

★ XPath注入
Xpath 用於操作xml,警惕提交給 xpath 函數的參數是否有經過安全處理
防範方法:
對於數據進行精確匹配

★ HTTP響應拆分
PHP 中可導致HTTP 響應拆分的情況爲:使用header 函數和使用$_SERVER 變量。
防範方法:
1. 精確匹配輸入數據
2. 檢測輸入輸入中如果有\r 或\n,直接拒絕

★ 文件管理
PHP 的用於文件管理的函數,如果輸入變量可由用戶提交,程序中也沒有做數據驗證,可能成爲高危漏洞。如下函數:copy、rmdir、unlink、delete、fwrite、chmod、fgetc、fgetcsv、fgets、fgetss、file、file_get_contents、fread、readfile、ftruncate、file_put_contents、fputcsv、fputs,但通常PHP 中每一個文件操作函數都可能是危險的。
防範方法:
1. 對提交數據進行嚴格匹配
2. 限定文件可操作的目錄

★ 文件上傳
PHP 文件上傳通常會使用 move_uploaded_file
防範方法:
1. 使用白名單方式檢測文件後綴
2. 上傳之後按時間能算法生成文件名稱
3. 上傳目錄腳本文件不可執行
4. 注意%00 截斷

參考資料
拓展網站:PHP-Security

2017_baidu_spring_7

文件包含漏洞的常見WAF繞過方式(以讀取/etc/passwd爲例)

★ 利用phar://協議特性可以繞過一些waf檢測,phar:// 數據流包裝器自 PHP 5.3.0 起開始有效。
新建shell.php代碼內容:

<?php
include 'phar://test.rar/test.txt';
?>

新建test.txt裏的內容:

<?php
phpinfo();
?>

壓縮test.txt文件,可以重命名壓縮文件爲zip,phar,rar等格式,之後訪問shell.php文件後,會出現phpinfo內容。

★ 本地包含
新建一個phpinfo.txt,然後新建一個shell.php,寫入:

<?php
    Include("phpinfo.txt");
?>

訪問shell.php會輸出phpinfo頁面內容,無論將擴展名改爲什麼,都將以php代碼執行。如果文件不是符合php規則的(即沒有寫<?php ?>等),則通過include可以直接輸出源碼

★ 遠程包含
新建php.txt:

<?php
   echo "hello world";
?>

新建index.php:

<?php
    Include($_GET['page']);
?>

訪問http://www.xxxx.com/page=http://www.xxxx.com/php.txt執行結果將輸出hello world。

文件包含漏洞(繞過)
文件上傳漏洞(繞過)

2017_baidu_spring_8

現有一個需要註冊才能使用的Android APP,打開APP時,
顯示:請輸入正確的序列號。如序列號不正確,提示:你輸入的序列號錯誤。
問:如何對該APP進行分析破解,用最簡單的,使之輸入任意序列號即可使用。
請描述分析方法、使用工具

smali 和 baksmali 可以看做是 Android 的 assembler 和 disassembler

首先使用 JEB 打開 APP 的 APK 文件,反編譯查看代碼一步步跟進,靜態分析吃力後使用 apktool 解開該 app 然後修改 AndroidManifest.xml 允許調試,再使用 apktool 再打包、signapk.jar 簽名、baksmali 反編譯,最後使用 Android Studio 進行動態調試
定位到需要更改的代碼位置,代碼更改後,重複上面的重新打包再簽名的過程就能成功繞過序列號的判斷

可以參考綠盟科技在烏雲知識庫上的文章《一次app抓包引發的Android分析記錄》

2017_baidu_spring_9

請描述PE文件加殼、脫殼步驟?

加殼

  1. 增加殼的代碼段
  2. 修改程序入口點(OEP)爲殼的代碼段

脫殼

  1. 判斷殼的類型
  2. 尋找程序入口點(OEP)

    A. 根據跨段指令尋找
    IDA Pro中有靜態的跨段指令的視圖(Segment),這裏是動態的,基本的辦法是單步跟蹤。
    B. 設置內存斷點
    在代碼段釋放完畢後,在代碼段首部設置內存斷點,中斷後就是OEP
    C. 根據堆棧平衡原理
    D. 根據編譯語言的特點(常見的初始化函數)找OEP

  3. Dump 內存

  4. 修復 PE 文件頭和輸入表 IAT

參考資料

2017_baidu_spring_10

TCP三次握手的原理,並簡單描述下端口掃描的幾種實現方式及優缺點

三次握手原理
(1)第一次握手:Client將標誌位SYN置爲1,隨機產生一個值seq=J,並將該數據包發送給Server,Client進入SYN_SENT狀態,等待Server確認。
(2)第二次握手:Server收到數據包後由標誌位SYN=1知道Client請求建立連接,Server將標誌位SYN和ACK都置爲1,ack=J+1,隨機產生一個值seq=K,並將該數據包發送給Client以確認連接請求,Server進入SYN_RCVD狀態。
(3)第三次握手:Client收到確認後,檢查ack是否爲J+1,ACK是否爲1,如果正確則將標誌位ACK置爲1,ack=K+1,並將該數據包發送給Server,Server檢查ack是否爲K+1,ACK是否爲1,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態,完成三次握手,隨後Client與Server之間可以開始傳輸數據了。

PING 掃描
向目標主機發送 ICMP 請求,如果收到了返回數據包則可以判斷目標存活.但是 ICMP Ping 越來越多地被防火牆與路由器阻止.

TCP 半開放掃描
半開放掃描速度很快,可以達到每秒數千個端口.只發送一個設置 SYN 標誌的數據包,等待來自目標主機的 SYN-ACK 返回數據包,而不會完成 TCP 握手過程.
收到 SYN-ACK 數據包之後可以判斷端口可用/正在監聽,如果收到 RST 數據包就可以判斷目標存活但端口關閉了.如果你可以判斷主機存活但沒有得到響應,端口就應該是被過濾了.

TCP 全連接掃描
與半開放掃描相比,最後需要發送 ACK 數據包來建立連接,所以掃描速度被拖慢很多.

UDP 掃描
UDP 掃描最常見用來檢測 DNS\SNMP\DHCP 服務,UDP 掃描通常是發送一個空包,也可以設置隨機載荷填充.
如果目標主機返回類型3\代碼3的 ICMP 無法訪問錯誤,則可以判斷端口是關閉的.如果是其他無法訪問錯誤代碼的數據包,則可以判斷端口是被過濾的,如果沒有收到響應數據包,則可以判斷端口是打開或者被過濾的.
和任何使用 UDP 通信存在的問題一致,其不可靠.UDP 掃描都很慢,可能需要發送大量的數據包才能確認一個端口的開放性.

隱蔽掃描
NULL\FIN\X-MAS
FIN 掃描會發送一個不會真實產生的數據包,發送一個包含 FIN 標誌的數據包但不先建立連接,如果收到 RST 數據包則端口是關閉的,如果沒有收到數據包則端口是開放的
X-MAS 掃描設置 URG\PUSH\FIN 標誌,如果沒有收到數據包,端口是開放的,如果收到 RST 數據包,端口是關閉的
NULL 掃描也會發送一個不會真實產生的數據包,不設置 TCP 數據包的任何標誌,如果收到 RST 數據包,端口是關閉的,如果沒有收到相應數據包,是一個開放的端口.
這些掃描都嘗試讓目標主機產生某種類型的響應而不通過握手來建立連接,隱身掃描也意味着它們不會出現在日誌中

SCTP INIT 掃描
SCTP INIT 掃描是 TCP SYN 掃描在 SCTP 上的等價物,同樣可以快速執行,在不受防火牆限制的情況下每秒掃描數千個端口,只發送一個 INIT 塊,等待一個響應

nmap 官網上有關於 nmap 實現很棒的闡述

2017_baidu_spring_11

N個大小不等的自然數(1N),亂序存於數組從1到n下標的空間中,請將它們由小到大排序,不能直接賦值或輸出。
要求程序算法:時間複雜度爲O(n),空間複雜度爲O(1)。

數據結構中常用的排序算法如下:
排序算法
可見並沒有滿足條件的算法

void sort(int e[], int n)
{
    int i;
    int t; /*臨時變量:空間複雜度O(1)*/
    for (i=1; i<n+1; i++) /*時間複雜度O(n)*/
    {
        while(e[i]!=i)
        {
            j++;
            t = e[e[i]]; /*下標爲e[i]的元素,排序後其值就是e[i]*/
            e[e[i]] = e[i];
            e[i] = t;
            }
    }
}

2017_baidu_spring_12

對任意輸入的正整數N,編寫C程序求N!的尾部連續0的個數,並指出計算複雜度。
如:17!=355687428096000,尾部連續0的個數是3。
(不用考慮數值超出計算機整數界限的問題

2*5即可得到0,則N!可以表示爲k*(2^m)(5^n),由於在N!中m>>n,因此N!=k’(2*5)^n,即n爲尾部爲0的個數。
由此,我們只要考慮N!中包含多少個5的倍數就可以了,如25,含有5,10,15,20,25,包含6個5的倍數,即25!尾部有6個0。
n=N/5+N/(5^2)+N/(5^3)….+N/(5^k) (k<=N/5)

時間複雜度:O(log5N)

#include <iostream>

using namespace std;

long long NumOfZero(long long n)
{
    long long count=0;
    while(n>0)
    {
        count+=n/5;
        n=n/5;
    }
    return count;
}

long long factorial(long long n)
{
    if(n==1)
        return 1;
    return n*factorial(n-1);
}

int main()
{
    long long n=20;

    cout<<NumOfZero(n)<<endl;
    cout<<factorial(n)<<endl;
    return 0;
}

參考資料

2017_baidu_spring_13

從其他渠道獲知A站被黑,同時黑客上傳了webshell(是否被黑客刪除未知),
該服務器上沒有任何安全防禦措施,只有web訪問日誌。
假如你是安全工程師小王,請你說明如何排查快速定位問題點,
同時設計有效的安全防禦系統,防範類似情況發生,
防禦系統至少包括sql注入、上傳webshell等高危漏洞的防禦措施。

溯源

  1. 首先用開源web漏掃工具檢查一遍,看是否有典型的 SQL 注入等 OWSAP10 漏洞
  2. 對於 web 網站查看是否採用主流的框架或者一些第三方框架,判斷是否是框架本身帶來的漏洞
  3. 對 web 日誌進行分析,篩選出可疑的訪問頁面,一般來說這樣的 webshell 的大小、名稱都很小,且它的出度僅爲 1,也就是主控端跟它聯繫,所以經過對比完全可以發現可疑的文件;

防禦
可以在網站前加一層軟 WAF,資金允許的話,可以買一些 WAF 設備,也可以手工進行一些簡單的防禦,包括參數化語句、轉義、設置白名單等,控制各級目錄的讀寫權限,密碼的複雜化,添加驗證碼等,時刻關注網站所用框架的通用漏洞,及時打補丁等等

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章