Pikachu-PHP deserialization, XXE, SSRF

PHP deserialization　　　　　　　　　　　　　　　　

General PHP deserialized vulnerabilities are found by code audit, the general black box testing and scanning are hard to find PHP deserialization vulnerability!

Before understanding the vulnerability ,, you need to find out the php serialize (), unserialize () these two functions.

Serialization serialize ()
sequence of said popular point is the string may be transmitted into an object, such as the following is an object:

S {class
public Test $ = "Pikachu";
}
$ S = S new new (); // create an object
serialize ($ s); // this object is serialized

Results obtained are serialized like this ->　　　　O:. 1: "S":. 1: {S:. 4: "Test"; S:. 7: "Pikachu";}
O: Representative Object
. 1: represents the object name a length of a character
S: name of the object
1: representing an object which has a variable
s: data type
4: the length of the variable name
test: variable name
s: data type
length value of the variable:. 7
Pikachu: variable value

In parentheses is written: variable corresponding data

Deserialization to unserialize ()

It is to be serialized string is reduced to the object, and then continue to use the following code.

    U $ = to unserialize ( "O:. 1:" S ":. 1: {S:. 4:" Test "; S:. 7:" Pikachu ";}" );
     echo  $ U -> Test; // result is obtained pikachu

Serialization and de-serialization itself is no problem, but if the content is deserialized user can control , and the background improper use of PHP magic function , can lead to security problems

        Several common magic function: 
        __construct () When an object is created is called 

        __destruct () When an object is destroyed is called 

        when an object is treated as a string using the __toString () 

        before the object being serialized in __sleep () run 

        __wakeup will immediately be called after serialization

Vulnerability For example:

        漏洞举例:

        class S{
            var $test = "pikachu";
            function __destruct(){
                echo $this->test;
            }
        }
        $s = $_GET['test'];
        @$unser = unserialize($a);

        payload:O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

漏洞利用　　payload:

O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}

XXE　XXE -"xml external entity injection"既"xml外部实体注入漏洞"　　　　　　　　

概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"
也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。

现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。
以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。

漏洞利用：

1、payload：

<?xml version = "1.0"?>
<!DOCTYPE note [
<!ENTITY hacker "ESHLkangi">
]>
<name>&hacker;</name>

可以看到直接把我们定义的变量值返回了，这算是一个正常的提交，

也就是说存在XXE漏洞。

2、构造一个读取敏感文件的payload：

<?xml version = "1.0"?>
<!DOCTYPE ANY [
<!ENTITY f SYSTEM "file:///C:/PhpStudy2018/PHPTutorial/WWW/pikachu/assets/css/ace.min.css">
]>
<x>&f;</x>

或者如果是linux系统的话是etc下的password文件，从而造成危害。

SSRF　　服务端请求伪造　　　　　　

(Server-Side Request Forgery:服务器端请求伪造)

其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据。

数据流:攻击者----->服务器---->目标地址

根据后台使用的函数的不同,对应的影响和利用方法又有不一样

PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。

漏洞利用：

SSRF（curl）　　　　　　　　　　　　　　

我们进入平台发现是一个链接，里面是一首诗。

观察 url 发现它传递了一个 url 给后台，

查看后台源码：

首先接收到前台的URL，然后没有进行过滤就直接进行初始化，然后用curl_exec()，进行解析返回给了前端。

如果你在你的远端服务器上搭建的pikuchu，在这里你可以将URL地址改为内网的其他服务器上地址和端口，探测其他信息，比如端口开放情况，我这里测试机器没有联网就不演示了。

SSRF(file_get_content)　　　　　　　　　　　　

们先来观察一下源代码，file_get_content 可以对本地和远程的文件进行读取

还可以使用 filter 取得页面源码：http://192.168.43.116/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php

再进行 base64 解码就能得到页面源码：

https://tool.oschina.net/encrypt?type=3

Pikachu-PHP deserialization, XXE, SSRF

Guess you like