深入学习PHP反序列化漏洞-绕过_wakeup()函数

题目代码

代码如下，要求利用php反序列化漏洞去读取flag.php文件中的内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

 <?php
 class SoFun{ 
    protected $file='index.php';
    function __destruct(){ 
      if(!empty($this->file)) {
       if(strchr($this-> file,"\\")===false &&  strchr($this->file, '/')===false)
          show_source(dirname (__FILE__).'/'.$this ->file);
       else      die('Wrong filename.');
      }}  
    function __wakeup(){ $this-> file='index.php'; } 
    public function __toString(){return '' ;}}     
    if (!isset($_GET['file'])){ show_source('index.php'); } 
    else{ 
       $file=base64_decode( $_GET['file']); 
       echo unserialize($file ); } 
?>   #<!--key in flag.php-->

测试一下Markdown xss

记一次ctf极限利用-不包含数字字母的webshell

序

问题来自于同事给我一道安恒的ctf赛题，题目代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
include 'flag.php';
if(isset($_GET['code'])){
    $code = $_GET['code'];
    if(strlen($code)>35){
        die("Long.");
    }
    if(preg_match("/[A-Za-z0-9_$]+/",$code)){
        die("NO.");
    }
    @eval($code);
}else{
    highlight_file(__FILE__);
}
//$hint =  "php function getFlag() to get flag";
?>

Ecshop2.x注入漏洞&代码执行漏洞分析

序

Ecshop最近爆出了两个高危漏洞，分别是SQL注入漏洞和代码执行漏洞，刚好自己在学代码审计方面的知识，于是自己针对两个漏洞的成因分析了一波，发现这是一个很有意思的二次漏洞，在这将整个学习过程做个记录

记一次有意思的XSS绕过之奇葩的中文尖括号

记录一个我实战中遇到的比较有意思的XSS绕过，过滤方式比较奇葩，把>变为了中文的尖括号＞，导致插入页面的xss payload不能被浏览器解析，但是经过一番测试无意间发现了一种绕过方式，构造方法比较特殊，在这分享一下~

ssrf漏洞原理以及利用方法

ssrf漏洞，全称为服务端请求伪造漏洞，由于有的web应用需要实现从其它服务器上获取资源的功能，但是没有对url进行限制，导致可以构造非本意的url对内网或者其它服务器发起恶意请求。ssrf漏洞的危害可以通过ssrf漏洞可以对内网或本地机器进行主机发现，服务版本探测或者针对内网或本地一些薄弱的应用进行攻击，同时利用ssrf漏洞还可以时服务器主动发起请求，从而做为一个攻击跳板或者绕过CDN找到其服务器的真实ip

Centos6 更新curl版本

由于自己的Centos6.5 curl版本为7.19.7，版本太低，所以要升级curl的版本，之前自己直接采取了源码安装最新版本的方式去升级，结果导致安装完毕后自己电脑的curl版本和php-curl版本不一致的问题


于是自己上网查了好久，终于找到了解决办法，在这里记录一下

centos环境下的redis未授权访问漏洞的几种利用方式

这篇文章记录一下redis未授权访问漏洞的几种利用方式,包括如何利用redis未授权访问漏洞通过任务计划反弹shell，向网站根目录写webshell以及利用redis未授权访问向服务器写入ssh公钥

记一次失败漏洞利用的经历–ubuntu下的redis未授权访问漏洞复现

由于redis的配置不当导致攻击者可以利用该未授权访问漏洞去对服务器进行攻击，redis服务默认端口为6379端口，在利用该漏洞的时候，由于服务器是ubuntu的原因，遇到了不少坑导致最终并没有利用成功，不像之前在centos环境下利用该漏洞时那样顺利，所以在这里记录一下。在理解这篇文章之前，可以先参考一下之前的解决ubuntu任务计划写shell失败的问题和关于ubuntu和centos cron的一些区别这两篇文章

关于ubuntu和centos cron的一些区别

写这篇文章的目的，源自解决ubuntu任务计划写shell失败的问题这篇文章遗留下来的一个问题：就是在向ubuntu的/var/spool/cron/crontabs目录下创建任务计划文件时，需要修改该文件的权限为600,也就是r------，该任务计划文件才能执行，否则就会报错不能执行，报出(root) INSECURE MODE (mode 0600 expected)这个错误，这个问题当时没有太注意，以为是umask不同的问题。直到今天再次利用ubuntu环境下的redis未授权访问漏洞反弹shell时才发现这样一个问题，就是我们并不能直接利用未授权访问漏洞去修改/var/spool/cron/crontabs目录下我们创建的任务计划文件的权限，所以导致任务计划文件不能执行，于是又研究了一番，偶然发现ubuntu和centos的umask是相同的，都是0022，说明之前自己的想法是错误的，并不是umask不同的问题，而是centos和ubuntu cron的区别，下面就来总结一下其cron的区别