Memcache未授权访问漏洞利用及bug修复详解

memcached是一套分布式的高速缓存系统。它以Key-Value(键值对)形式将数据存储在内存中,这些数据通常是应用读取频繁的。正因为内存中数据的读取远远大于硬盘,因此可以用来加速应用的访问。

漏洞成因:

由于memcached安全设计缺陷,客户端连接memcached服务器后 无需认证就 可读取、修改服务器缓存内容。 漏洞影响:

除memcached中数据可被直接读取泄漏和恶意修改外,由于memcached中的数据像正常网站用户访问提交变量一样会被后端代码处理,当处理代码存在缺陷时会再次导致不同类型的安全问题。

不同的是,在处理 前端用户直接输入的数据时一般会接受更多的安全校验,而从memcached中读取的数据则更容易被开发者认为是可信的,或者是已经通过安全校验的,因此更容易导致安全问题。

由此可见,导致的二次安全漏洞类型一般 由memcached数据使用的位置(XSS通常称之为sink)的不同而不同, 如:

(1)缓存数据未经过滤直接输出可导致XSS;

(2) 缓存数据 未经过滤代入拼接的SQL注入查询语句可导致SQL注入;

(3) 缓存数据 存储敏感信息(如:用户名、密码),可以通过读取操作直接泄漏;

(4) 缓存数据 未经过滤直接通过system()、eval()等函数处理可导致命令执行;

(5) 缓存数据 未经过滤直接在header()函数中输出,可导致CRLF漏洞(HTTP响应拆分)。

… …

漏洞利用:

漏洞的利用根据所造成二次漏洞的不同,可在缓存变量中构造相应的payload。

针对memcached未授权访问漏洞缓存数据的抓取,可使用 go-derper工具。

注: memcached服务器基本操作及go-derper工具使用方法参见链接。

漏洞攻击DEMO:

http://niiconsulting.com/checkmate/2013/05/memcache-exploit/

漏洞检测:

       1、登录机器执行netstat -an | more命令查看端口监听情况。回显0.0.0.0:11211表示在所有网卡进行监听,存在 memcached 未授权访问漏洞。

       2、telnet  <target>  11211, 或 nc -vv  <target>  11211,提示连接成功表示漏洞存在。

    TELNET:
 
        ------------------------------------------------------------
 
        local% telnet x.x.x.x 11211
 
        Trying x.x.x.x...
 
        Connectedto x.x.x.x.
 
        Escapecharacteris '^]'.
 
       
 
        NC:
 
        ------------------------------------------------------------
 
        local% nc -vv x.x.x.x 11211
 
        found 0 associations
 
        found 1 connections:
 
            1: flags=82<CONNECTED,PREFERRED>
 
        outifen7
 
        src x.x.x.x port 55001
 
        dst x.x.x.x port 11211
 
        rankinfonot available
 
        TCPauxinfoavailable
 
       
 
        Connectionto x.x.x.x port 11211 [tcp/*] succeeded!
 
        statsitems
 
        memcachedagentv0.4
 
        matrix 1 -> x.x.x.x:12000, poolsize 1
 
        matrix 2 -> x.x.x.x:12001, poolsize 1
 
        END
3、使用端口扫描工具nmap进行远程扫描:nmap -sV -p 11211 –script memcached-info <target>。

        11211/tcpopen  memcached
 
        | memcached-info:
 
        |  ProcessID          18568
 
        |  Uptime              6950 seconds
 
        |  Servertime          SatDec 31 14:16:10 2011
 
        |  Architecture        64 bit
 
        |  UsedCPU (user)      0.172010
 
        |  UsedCPU (system)    0.200012
 
        |  Currentconnections  10
 
        |  Totalconnections    78
 
        |  Maximumconnections  1024
 
        |  TCPPort            11211
 
        |  UDPPort            11211
 
        |_  Authentication      no
漏洞修复:

1、配置memcached监听本地回环地址127.0.0.1。

        [root@local ~]# vim /etc/sysconfig/memcached
        OPTIONS="-l 127.0.0.1"  #设置本地为监听
 
        [root@local ~]# /etc/init.d/memcached restart #重启服务
2、当memcached 配置为监听内网IP或公网IP时, 使用主机防火墙(iptalbes、 firewalld等)和 网络防火墙对memcached服务端口 进行过滤。

时间: 2024-11-01 07:14:55

Memcache未授权访问漏洞利用及bug修复详解的相关文章

阿里云CentOS+PHP+Nginx+Redis未授权访问漏洞

在阿里云上挂了一个网站,运行CentOS+PHP+Nginx,服务器装了redis,端口是6379,打开阿里云后台云盾报一个安全漏洞,漏洞类型是Redis未授权访问漏洞,漏洞地址是xx.xx.xx.xx:6379,也提供了解决方案. 记录如下: 一.漏洞描述和危害 Redis因配置不当可以未授权访问,被攻击者恶意利用. 攻击者无需认证访问到内部数据,可能导致敏感信息泄露,黑客也可以恶意执行flushall来清空所有数据. 攻击者可通过EVAL执行lua代码,或通过数据备份功能往磁盘写入后门文件,

Redis3未授权访问漏洞导致服务器被入侵

今天在腾讯云上搭的开发环境里的一台机器cpu load飚升老高,然后还能登陆上去,top后发现两个可疑进程./root/目录下有修改过的文件./opt目录被干掉了, 后经分析,这台机器上有redis外网服务,/root目录下还有个READ_ME.txt,  内容如下: 中招了,,两个可疑进程 在腾讯云上找到篇处理步骤: Redis 默认情况下,会绑定在 0.0.0.0:6379,这样会将 Redis 服务暴露到公网上,在Redis服务器没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的

memcache 端口11211 未授权访问漏洞

漏洞描述:memcache是一套常用的key-value缓存系统,由于它本身没有权限控制模块,所以开放在外网的memcache服务很容易被攻击者扫描发现,通过命令交互可直接读取memcache中的敏感信息. 修复方案:因memcache无权限控制功能,所以需要用户对访问来源进行限制. 方案一: 如果memcache没有在外网开放的必要,可在memcached启动的时候指定绑定的ip地址为 127.0.0.1.例如: memcached -d -m 1024 -u root -l 127.0.0.

Memcache内存缓存的未授权访问漏洞解决办法

漏洞描述   Memcache是一套常用的key-value缓存系统,由于它本身没有权限控制模块,所以开放在外网的Memcache服务很容易被攻击者扫描发现,通过命令交互可直接读取Memcache中的敏感信息.   修复方案   因Memcache无权限控制功能,所以需要用户对访问来源进行限制,下面分享4中有效的解决方法.   1.绑定IP   如果Memcache没有在外网开放的必要,可在Memcache启动的时候指定绑定的IP地址为 127.0.0.1.例如:  memcached -d -

所谓的&quot;新姿势之Docker Remote API未授权访问漏洞分析和利用&quot;

最近乌云上出现了一篇文章 http://drops.wooyun.org/papers/15892.这种作者就一个好,写文章比谁都快,可惜从来不愿意踏踏实实的分析,非得搞个大新闻,把Docker/Swarm批判一番. 先说结论,Docker采用C/S结构,但是它的client和server用的是同一个binary文件: docker,根据参数不同执行不同的代码分支,所以很多人可能都不清楚Docker是C/S结构的.Docker的Server端,也叫作Docker Daemon,运行命令/path

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

Sebug 网站公布了 Redis 未授权访问缺陷的详细漏洞信息,这个 Redis 未授权访问缺陷可轻易导致系统被黑.详细内容请看下文: 漏洞概要 Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将Redis服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访 问Redis以及读取Redis的数据.攻击者在未授权访问Redis的情况下可以利用Redis的相关方法,可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的

SSLC0008E: 无法初始化 SSL 连接。未授权访问被拒绝,或者安全性设置已到期。

问题描述 [12-6-2914:34:37:936CST]0000001aSSLHandshakeEESSLC0008E:无法初始化SSL连接.未授权访问被拒绝,或者安全性设置已到期.异常:javax.net.ssl.SSLHandshakeException:ClientrequestedprotocolUnknown-0.2notenabledornotsupportedatcom.ibm.jsse2.gb.t(gb.java:444)atcom.ibm.jsse2.qc.b(qc.java

JavaScript注入漏洞的原理及防范(详解)_javascript技巧

初次接触: 初次接触JavaScript注入漏洞后,如果不对这种漏洞的作用机理仔细分析并提取出其发生的某种模式,你就不能做到快速的发现项目中可能存在的所有注入风险并在代码中防范. 发生模式: JavaScript注入漏洞能发生作用主要依赖两个关键的动作,一个是用户要能从界面中注入JavaScript到系统的内存或者后台存储系统中:二是系统中存在一些UI会展示用户注入的数据. 比如注入漏洞最常见的就是发生在各种类型的名字中,比如系统中的人名等等,因为名字往往会在各种系统上显示,如果在某个用户输入名

Yii2框架RESTful API 格式化响应,授权认证和速率限制三部分详解

之前写过一篇Yii2框架制作RESTful风格的API快速入门教程,今天接着来探究一下Yii2 RESTful的格式化响应,授权认证和速率限制三个部分 一.目录结构 先列出需要改动的文件.目录如下: web ├─ common │ └─ models │ └ User.php └─ frontend ├─ config │ └ main.php └─ controllers └ BookController.php 二.格式化响应 Yii2 RESTful支持JSON和XML格式,如果想指定返回