【FreeBuf字幕组】HackerOne优秀白帽黑客采访系列-Tanner
willhuang 2019-3-20 8:59 转存

人物介绍

Tanner,@itscachemoney,来自旧金山的安全工程师,在工作之余积极参与漏洞众测,目前在HackerOne提交的有效漏洞为357个,在实时榜单上排名第36位。Tanner近期的高光时刻要数两个月以前价值$20,000的Github漏洞,和一年前$15,250的Shopify漏洞,当然,他发现的从GitHub app提权至组织管理者的$10,000美金漏洞也同样精彩。

Tanner上报漏洞的正确率和影响力百分比都是比较高的,每隔一两个月总会发现一些价值四位数赏金的漏洞,他发现了Uber、Quora和GitHub等多家知名厂商的多个高危漏洞,获得了多次致谢和好评。工作和众测之余,Tanner喜欢滑雪和旅行。

观看视频

看不到视频点这里

*本课程翻译自Youtube精选系列教程,喜欢的点一波关注(每周更新)!

* 本文作者:willhuang,FreeBuf视频组荣誉出品,转载须注明来自FreeBuf.COM

原文阅读

IoT-Implant-Toolkit:一款针对IoT设备的木马测试工具
Alpha_h4ck 2019-3-20 7:0 转存

今天给大家介绍是一款名叫IoT-Implant-Toolkit的开源工具,这款工具专门针对物联网设备而设计,可直接向目标IoT设备植入木马,广大研究人员可利用这款工具来测试IoT设备的安全性。

一款针对IoT设备的木马植入工具

IoT-Implant-Toolkit

IoT-Implant-Toolkit是一个整合了多种实用工具的木马植入框架,其中涉及到固件修改、串口调试、软件分析和间谍客户端植入等等,可帮助研究人员对IoT设备进行恶意软件注入研究。该工具简单易用,且提供了类Shell环境的可扩展能力。在IoT-Implant-Toolkit的帮助下,复杂的IoT恶意软件植入操作也可以变得轻松简单。

在我们的研究过程中,我们利用IoT-Implant-Toolkit成功在八台设备上植入了木马,其中包括智能扬声器、摄像头、行车记录仪和移动翻译器等等。

工具操作演示

一款针对IoT设备的木马植入工具

如何使用IoT-Implant-Toolkit

工具安装

确保你已经安装好了git、Python3和setuptools。

如果你需要处理/播放音频信息的话,你还需要安装alsa、sox和ffplay。在Ubuntu 18.04上你可以运行下列命令:

$sudo apt install sox ffmpeg

从项目的GitHub代码库上下载源代码:

$ git clone https://github.com/arthastang/IoT-Implant-Toolkit.git

配置环境并安装依赖组件:

$ cd IoT-Implant-Toolkit/
$ python3 setup.py install

工具运行

一款针对IoT设备的木马植入工具

工具支持下列三种命令:

list:显示所有可用插件;

run:运行指定插件,命令样本:”run [插件名] [参数]“;

exit:退出;

功能介绍

该框架中的每一款软件都以插件的形式运行,因此该工具的可扩展性非常高,而且使用起来也非常方便。

目前该工具自带了11款插件,主要分类四大类,其中包括串口调试、固件封装/解封装、软件分析和间谍软件植入。

插件列表

分类 工具名 描述 资源引用
串口调试 pyserial Modem控制和终端模拟工具 https://github.com/pyserial/pyserial
串口调试 baudrate.py 寻找正确的baudrate https://github.com/devttys0/baudrate
固件封装/解封装 mksquashfs 可创建和提取Squashfs文件系统 https://github.com/plougher/squashfs-tools
固件封装/解封装 mkbootimg_tools 针对Android平台boot.img的解封装&封装工具 https://github.com/xiaolu/mkbootimg_tools
固件封装/解封装 cramfs 制作cramfs 文件系统 https://sourceforge.net/projects/cramfs/files/cramfs/1.1/
固件封装/解封装 mountimg 针对Android system.img&data.img ext4 文件系统处理工具 https://github.com/arthastang/IoT-Implant-Toolkit
软件分析 setools-android 针对Android应用的分析工具 https://github.com/xmikos/setools-android
软件分析 crosscomplie 针对ARMcrosscompile工具集 https://github.com/arthastang/IoT-Implant-Toolkit
软件分析 odex unpack Android 应用:Odexsmali https://github.com/arthastang/IoT-Implant-Toolkit
代码植入 spy client&server 稳定的间谍客户端+服务器 https://github.com/arthastang/IoT-Implant-Toolkit
代码植入 denoise tool 用于音频处理 https://github.com/arthastang/IoT-Implant-Toolkit

创建新插件

代码结构:

--IoT-Implant_toolkit.py         #Startup script
--outputs/                       #Default folder ofoutputs
--toolkit/                      
  |---core/                     
      |---basic/                 #Basic plugin class defination
      |---cli/                   #Shell-like cli defination
      |---toollist/              #Auto updating toollist ofplugins
  |---plugins/                  
      |---firmware/              #Plugins for firmwaremodification
      |---implant/               #Plugins for generate spy programs
      |---serialport/            #Plugins for serial port debugging
      |---software/              #Plugins for software analysisespecially for Android
  |---tools/                     #Other tools

在相应分类目录中创建[newplugin].py,并定义init属性来添加新的插件,IoT-Implant-Toolkit将会自动配置并加载目录中的新插件。

其他工具

硬件工具

项目的HardwareTools/目录中还提供了很多针对恶意软件植入研究的硬件工具。

工具名 描述
Soldering Iron Solder 工具
Solder Wire Solder 工具
Solder Paste Solder 工具
Solder Wick Solder 工具
Hot Air Gun Solder 工具
Reballing Tool Reballing 工具
usb to ttl 调试/ 控制台线缆
Dupont Wire 电线
EPROM Burner Programmer Burner 编程器

其他实用软件工具

由于时间问题,我们现在还没有添加太多的功能插件,下面这个列表中的工具虽然现在不适用于我们这款框架,但也许会对大家有用。

分类 工具名 描述 资源引用
固件分析 binwalk 简单易用的固件镜像分析、逆向分析和提取工具 https://github.com/ReFirmLabs/binwalk
固件分析 firmware mod kit 用于提取和重建Linux固件镜像的工具 https://github.com/rampageX/firmware-mod-kit
交叉编译 buildroot 针对arm mips powerpc的交叉编译工具 https://buildroot.org/

项目地址

IoT-Implant-Toolkit:【GitHub传送门

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

原文阅读

被CrazyCrypt2.1勒索病毒加密了?已有一键解密工具!
千里目安全实验室 2019-3-20 6:0 转存

背景概述

近日,国外分析人员报出CrazyCrypt 2.1勒索病毒,该勒索病毒集加解密模块于一体,通过AES加密算法对文件进行加密,并弹出交互窗口,受害用户通过支付赎金获取解密密钥后可通过该窗口自行解密。深信服安全团队密切关注该勒索病毒家族的最新动向,对捕获的样本进行了详细分析,并向广大用户提供免费的密钥获取工具。

免费密钥工具下载连接:

http://edr.sangfor.com.cn/tool/CrazyCrypt_2.1_Password_Generator.zip

病毒信息

1. 病毒运行流程:

2. 加密文件类型:

".doc"".docx"".xls"".xlsx"".ppt"".pptx"".jpg"".jpeg"".png"".psd"".txt"".zip"".rar"".html"".php"".asp"".aspx"".mp4"".avi"".3gp"".wmv"".MOV"".mp3"".wav"".flac"".wma"".mov"".raw"".doc"".apk"".encrypt""crypted"".ahok"".cs"".vb"".ppt"".pptx"".docx"".xlsx"".mdf"".ldf"".bak"".max"

3. 加密后文件:

“原文件名 + id.主机id.[crazydecrypt@horsefucker.org].crazy”

4. 勒索信息:

详细分析

CrazyCrypt_Encrypt加密模块

1. 创建互斥体”SINGLE_INSTANCE_APP_MUTEX”:

2. 修改WindowsDefender和系统策略:

3. 从A到Z遍历磁盘,排除包含以下字符的目录:

“Bin” “indows”"tings” “System Volume Information” “cache”"very” “rogram Files (x86)” “rogram Files”"boot” “efi” “.old”

4. 排除已加密过的文件,筛选指定后缀名的文件:

5. 生成密钥和IV,使用AES算法对文件进行加密,重命名文件:

CrazyCrypt_Aviso勒索信息模块

1. 弹出勒索信息窗口:

2. 替换加密主机ID:

3. 向C&C端发送失陷主机信息:

4. 等待输入密码,连接C&C端获取key进行对比:

CrazyCrypt_Decrypt模块

1. 排除未加密的文件目录:

2. 解密文件,自删除:

解决方案

针对已经出现勒索现象的用户,建议尽快对感染主机进行断网隔离,下载深信服提供的免费密钥获取工具生成密钥,解密文件。深信服提醒广大用户尽快做好病毒检测与防御措施,防范该病毒家族的勒索攻击。

病毒检测查杀

1、深信服为广大用户免费提供查杀工具,可下载如下工具,进行检测查杀。

64位系统下载链接:

http://edr.sangfor.com.cn/tool/SfabAntiBot_X64.7z

32位系统下载链接:

http://edr.sangfor.com.cn/tool/SfabAntiBot_X86.7z

病毒防御

深信服安全团队再次提醒广大用户,勒索病毒以防为主,目前大部分勒索病毒加密后的文件都无法解密,注意日常防范措施:

1、及时给电脑打补丁,修复漏洞。

2、对重要的数据文件定期进行非本地备份。

3、不要点击来源不明的邮件附件,不从不明网站下载软件。

4、尽量关闭不必要的文件共享权限。

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

6、如果业务上无需使用RDP的,建议关闭RDP。

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

原文阅读

如何检测Pass-the-Hash攻击?
secist 2019-3-20 5:0 转存

横向渗透技术是攻击者用来渗透目标网络,获取凭据和数据特权访问的最常见方法之一。在最近发现的勒索软件(如Samsam和Ryuk)中,就说明了这一点。

最近我们研究了如何通过蜜罐检测pass-the-hash攻击,在研究检测此类攻击的最有效方法时,我发现了其它几种有趣的方法。我认为非常有必要对它们进行测试,并进一步的研究pass-the-hash行为。

本文我将教大家如何使用本机Windows事件日志检测pass-the-hash,以及一些关于如何实现的实用建议。在这里我不会讨论有关什么是pass-the-hash的问题,如果你愿意你可以阅读这篇文章以及观看它的演示视频

基线正常事件

Pass-the-Hash依赖于NTLM身份验证。为了可靠地创建NTLM身份验证,我使用Sqlcmd实用程序通过其IP地址连接到Microsoft服务器。此命令将为SQL数据库生成NTLM身份验证:

Sqlcmd –S [IP ADDRESS]

在查看如何检测pass-the-hash攻击之前,让我们先来获取执行NTLM登录活动时通常会生成的事件基线。要从我的PC工作站执行此操作,我将首先使用管理用户的实际密码启动一个新的命令提示符:

如何检测Pass-the-Hash攻击?

现在,在新的命令提示符下,我将使用Sqlcmd连接到SQL主机,并运行SELECT SYSTEM_USER命令查看我被认证为的用户:

如何检测Pass-the-Hash攻击?

很好,一切正常!现在让我们看看生成的日志。

工作站日志

在我的本地工作站上我看到以下事件。

4648事件:试图使用显式凭据登录(A logon was attempted usingexplicit credentials)

如何检测Pass-the-Hash攻击?

4624事件:成功登录帐户(An account was successfully logged on)

4624事件显示登录类型为2,这意味着交互式登录。这符合我使用runas的方式,我以交互方式输入凭据。

如何检测Pass-the-Hash攻击?

4672事件:分配给新的登录特权

由于我使用的Franklin Bluth帐户是一个管理帐户,因此会记录4672显示正在分配的权限。这是跟踪管理帐户活动的非常实用的方法。

如何检测Pass-the-Hash攻击?

目标服务器日志

在我的SQL服务器上我看到以下事件:

4624事件:成功登录帐户(An account was successfully logged on)

现在,在SQL Server上你会看到4624事件,此事件的登录类型为3,即网络登录。

如何检测Pass-the-Hash攻击?

更重要的是,这表明使用的身份验证包( Authentication Package)是NTLM。也证实了我们正在使用此方法执行NTLM身份验证。

如何检测Pass-the-Hash攻击?

我们还将看到4672事件,因为我们利用的用户帐户是一个特权帐户。

域控日志

在域控制器上,我将看到用户Franklin Bluth被验证的迹象。在本例中,我将看到Kerberos和NTLM身份验证。首先发生Kerberos身份验证,这是Active Directory的默认身份验证方式。这将生成两个事件:

4768事件:Kerberos 身份验证票证 (TGT) 请求

如何检测Pass-the-Hash攻击?

以上显示了我们模拟的用户对域控制器的TGT请求。

4769事件:Kerberos 服务票证请求

一旦我们有了TGT,我们就会为我们模拟用户的主机请求TGS。有了这个,我们的用户Franklin现在可以与PC交互并启动命令提示符。

如何检测Pass-the-Hash攻击?

4776事件:域控试图验证帐户凭据

4776事件特定于NTLM,并将在最后。 当我们使用强制NTLM身份验证的Sqlcmd执行命令时会发生这种情况。

如何检测Pass-the-Hash攻击?

以下是我们在不使用pass-the-hash执行NTLM身份验证时看到的日志摘要。这为我们提供了正常行为的基线。

源主机 目标主机 域控制器
4648事件:试图使用显式凭据登录 4624 – 帐户已成功登录。登录类型为3,NTLM 4768 – Kerberos 身份验证票证 (TGT) 请求。
4624 – 帐户已成功登录。登录类型为2 4672 – 分配给新的登录特权。 4769 – Kerberos 服务票证请求。
4672 – 分配给新的登录特权。   4776 – 计算机试图验证帐户的凭据。

现在,让我们来看看我们在Pass-the-Hash时看到的内容。

Pass-the-Hash 事件

为了执行pass-the-hash测试,我们将做同样的练习,只是这次我们将使用mimikatz和pass the hash命令,而不是使用runas作为用户启动进程。

我可以使用mimikatz命令,从内存中轻松获取用户Franklin的NTLM哈希值:

获取哈希后,我将使用以下命令执行pass-the-hash攻击:

sekurlsa::logonpasswords
Sekurlsa::pth /user:Franklin.Bluth /ntlm:[ntlm] /domain:jefflab.local

这将打开一个新的命令窗口,如果我使用相同的Sqlcmd命令连接到我的SQL Server的IP地址,你可以看到我现在被验证为Franklin Bluth:

如何检测Pass-the-Hash攻击?

那么,让我们看看在执行pass-the-hash之后会生成什么事件:

工作站日志

在我的本地工作站上,我看到了事件4648,4624和4672与我正在进行合法的NTLM身份验证相同,但有一些关键的区别。

首先,4624事件的登录类型为9。这是一种NewCredential登录类型,是识别pass-the-hash的非常有用的方法。这是由安全研究人员确定的,我在我的测试中再现了它。

如何检测Pass-the-Hash攻击?

登录类型9非常罕见。但是,我能够生成一些运行使用模拟的应用程序的误报。关键的主要区别是登录进程对于pass-the-hash(来自我的测试)始终是“seclogo”,所以你可以过滤掉它以减少误报率。你可以在这里看到我能够让StealthAUDIT生成Logon Type 9事件,但它使用了Advapi登录进程。

如何检测Pass-the-Hash攻击?

另外,我注意到了4672事件的不同之处。此前,这确定了我模拟帐户Franklin Bluth的特权登录。这将为我登录到我的工作站的用户注册。

如何检测Pass-the-Hash攻击?

除此之外,SQL服务器上的日志是相同的。在域控制器上,关键区别在于你不会看到Kerberos身份验证。但是,这不是检测pass-the-hash的可靠方法,例如源自非受信任域的身份验证也会发生这种情况。

以下是我们在执行hash-hash时所看到的内容摘要。

源主机 目标主机 域控制器
4648事件:试图使用显式凭据登录 4624 – 帐户已成功登录。登录类型为3,NTLM 474776 – 计算机试图验证帐户的凭据。
4624 – 帐户已成功登录。 (Logon type = 9 Logon Process = Seclogo) 4672 – 分配给新的登录特权。  
4672 – 分配给新的登录特权。 (登录用户,而不是模拟用户)  

Sysmon

为了最终检测pass-the-hash我使用了Sysmon,这有助于监视进程访问事件。我们在蜜罐检测中使用了它,你可以阅读这篇文章了解如何对它进行设置

当发生pass-the-hash时,你将看到事件ID 10显示从Mimikatz或你选择使用的pass-the-hash工具访问LSASS进程。

如何检测Pass-the-Hash攻击?

构建 Pass-the-Hash 检测

现在,我们已经查看了所有有关pass-the-hash攻击的证据,构建检测pass the hash攻击的最简单方法是查找:

你工作站上的4624个事件

Logon Type = 9

Authentication Package = Negotiate

Logon Process = seclogo

LSASS进程访问关联Sysmon 10事件

通过自定义事件日志过滤器,当这两件事同时发生时,你可以很容易地看到你网络上的pass-the-hash活动!

16image-18.png

以下是一个自定义事件过滤器,可用于显示特定信息。

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
     *[System[(EventID='4624')]
      and
     EventData[Data[@Name='LogonType']='9']
      and
     EventData[Data[@Name='LogonProcessName']='seclogo']
     and
     EventData[Data[@Name='AuthenticationPackageName']='Negotiate']
     ]
     </Select>
  </Query>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
    *[System[(EventID=10)]]
    and
    *[EventData[Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038')]]
</Select>
  </Query>
</QueryList>

希望通过本文的学习,能让你掌握学到如何通过事件日志检测pass-the-hash攻击。这需要在所有端点上启用日志记录。为了更简单地检测使用更高级技术的pass-the-hash攻击,你可能需要借助第三方威胁检测产品,如StealthDEFEND

在下一篇有关横向渗透的文章中,我将介绍pass-the-ticket的攻击及相关检测方法。欢迎大家阅读!谢谢!

参考文献

在撰写这篇文章时,我对该主题进行了大量的研究。以下内容可进一步的为你提供,有关如何理解和检测pass-the-hash的更多信息:

www.cyberark.com/threat-research-blog/detecting-pass-the-hash-with-windows-event-viewer/

https://www.optiv.com/blog/pass-the-hash

https://cyberwardog.blogspot.com/2017/04/chronicles-of-threat-hunter-hunting-for.html

jblog.javelin-networks.com/blog/detecting-pass-ticket-pass-hash-attack-using-simple-wmi-commands/

silentbreaksecurity.com/windows-events-sysmon-elk-part-2/

https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1536265369.pdf

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

原文阅读

AFL漏洞挖掘技术漫谈(二):Fuzz结果分析和代码覆盖率
alphalab 2019-3-20 2:0 转存

一、前言

阿尔法实验在上一篇文章中向大家介绍了使用AFL开始模糊测试前要做的一些准备工作,以及AFL的几种工作方式,但是并没有提到何时结束测试过程,以及测试完成后又需要做些什么。本文中就继续介绍这些内容,并开始逐步介绍一些AFL相关原理,以下是本文中主要讨论的问题:

1.何时结束Fuzzing工作

2.afl-fuzz生成了哪些文件

3.如何对产生的crash进行验证和分类

4.用什么来评估Fuzzing的结果

5.代码覆盖率及相关概念

6.AFL是如何记录代码覆盖率的

二、Fuzzer工作状态

因为afl-fuzz永远不会停止,所以何时停止测试很多时候就是依靠afl-fuzz提供的状态来决定的。除了前面提到过的通过状态窗口、afl-whatsup查看afl-fuzz状态外,这里再补充几种方法。

1. afl-stat

afl-stat是afl-utils这套工具AFL辅助工具中的一个(这套工具中还有其他更好用的程序,后面用到时会做介绍),该工具类似于afl-whatsup的输出结果。

使用前需要一个配置文件,设置每个afl-fuzz实例的输出目录:

{
    "fuzz_dirs": [
        "/root/syncdir/SESSION000",
        "/root/syncdir/SESSION001",
   ...
   "/root/syncdir/SESSION00x"
    ]
}

然后指定配置文件运行即可:

$ afl-stats -c afl-stats.conf
[SESSION000 on fuzzer1]
 Alive:   1/1
 Execs:   64 m
 Speed:   0.3 x/s
 Pend:    6588/249
 Crashes: 101
[SESSION001 on fuzzer1]
 Alive:   1/1
 Execs:   105 m
 Speed:   576.6 x/s
 Pend:    417/0
 Crashes: 291
...

2. 定制afl-whatsup

afl-whatsup是依靠读afl-fuzz输出目录中的fuzzer_stats文件来显示状态的,每次查看都要需要手动执行,十分麻烦。因此可以对其进行修改,让其实时显示fuzzer的状态。方法也很简答,基本思路就是在所有代码外面加个循环就好,还可以根据自己的喜好做些调整:
1.jpg

3. afl-plot

前面提到的都是基于命令行的工具,如果还想要更直观的结果,可以用afl-plot绘制各种状态指标的直观变化趋势。

#安装依赖工具gnuplot
$ apt-get install gnuplot
$ afl-plot afl_state_dir graph_output_dir

以测试libtiff的情况为例,进入afl-plot输出目录,打开index.html,会看到下面三张图:

首先是路径覆盖的变化,当pending fav的数量变为零并且total paths数量基本上没有再增长时,说明fuzzer有新发现的可能性就很小了。

2.jpg

接着是崩溃和超时的变化

3.jpg

最后是执行速度的变化,这里要注意的是,如果随着时间的推移,执行速度越来越慢,有一种可能是因为fuzzer耗尽一些共享资源。

4.jpg

4. pythia

笔者在查阅资料的过程中,还发现了pythia这个AFL的扩展项目,虽然不知道效果如何,但这里还是顺便提一提。其特色在于可以估算发现新crash和path概率,其运行界面相比原版的AFL多出了下面几个字段:
5.jpg

correctness: 在没有发现crash时,发现一个导致crash输入的概率。

fuzzability: 表示在该程序中发现新路径的难度,该数值越高代表程序越容易Fuzz。

current paths: 显示当前发现的路径数。

path coverag: 路径覆盖率。

三、结束测试

1.何时结束

检查afl-fuzz工作状态的目的是为何时停止测试提供依据,通常来说符合下面几种情况时就可以停掉了。

(1)状态窗口中”cycles done”字段颜色变为绿色该字段的颜色可以作为何时停止测试的参考,随着周期数不断增大,其颜色也会由洋红色,逐步变为黄色、蓝色、绿色。当其变为绿色时,继续Fuzzing下去也很难有新的发现了,这时便可以通过Ctrl-C停止afl-fuzz。

6.jpg

(2)距上一次发现新路径(或者崩溃)已经过去很长时间了,至于具体多少时间还是需要自己把握,比如长达一个星期或者更久估计大家也都没啥耐心了吧。

7.jpg

(3)目标程序的代码几乎被测试用例完全覆盖,这种情况好像很少见,但是对于某些小型程序应该还是可能的,至于如何计算覆盖率将在下面介绍。

(4)上面提到的pythia提供的各种数据中,一旦path covera达到99%(通常来说不太可能),如果不期望再跑出更多crash的话就可以中止fuzz了,因为很多crash可能是因为相同的原因导致的;还有一点就是correctness的值达到1e-08,根据pythia开发者的说法,这时从上次发现path/uniq crash到下一次发现之间大约需要1亿次执行,这一点也可以作为衡量依据。

2. 输出结果

afl-fuzz的输出目录中存在很多文件,有时想要写一个辅助工具可能就要用到其中的文件。下面以多个fuzz实例并行测试时的同步目录为例:

$ tree -L 3
.
├── fuzzer1
│   ├── crashes
│   │   ├── id:000000,sig:06,src:000019+000074,op:splice,rep:2
│   │   ├── ...
│   │   ├── id:000002,sig:06,src:000038+000125,op:splice,rep:4
│   │   └── README.txt
│   ├── fuzz_bitmap
│   ├── fuzzer_stats
│   ├── hangs
│   │   └── id:000000,src:000007,op:flip1,pos:55595
│   ├── plot_data
│   └── queue
│       ├── id:000000,orig:1.png
│ ├── ....
│       └── id:000101,sync:fuzzer10,src:000102
└── fuzzer2
    ├── crashes
    ├── ...

queue:存放所有具有独特执行路径的测试用例。

crashes:导致目标接收致命signal而崩溃的独特测试用例。

crashes/README.txt:保存了目标执行这些crash文件的命令行参数。

hangs:导致目标超时的独特测试用例。

fuzzer_stats:afl-fuzz的运行状态。

plot_data:用于afl-plot绘图。

四、处理测试结果

到了这里,我们可能已经跑出了一大堆的crashes,那么接下来的步骤,自然是确定造成这些crashes的bug是否可以利用,怎么利用?这是另一个重要方面。当然,个人觉得这比前面提到的内容都要困难得多,这需要对常见的二进制漏洞类型、操作系统的安全机制、代码审计和调试等内容都有一定深度的了解。但如果只是对crash做简单的分析和分类,那么下面介绍的几种方法都可以给我们提供一些帮助。

1. crash exploration mode

这是afl-fuzz的一种运行模式,也称为peruvian rabbit mode,用于确定bug的可利用性,具体细节可以参考lcamtuf的博客。

$ afl-fuzz -m none -C -i poc -o peruvian-were-rabbit_out -- ~/src/LuPng/a.out @@ out.png

8.jpg

举个例子,当你发现目标程序尝试写入\跳转到一个明显来自输入文件的内存地址,那么就可以猜测这个bug应该是可以利用的;然而遇到例如NULL pointer dereferences这样的漏洞就没那么容易判断了。

将一个导致crash测试用例作为afl-fuzz的输入,使用-C选项开启crash exploration模式后,可以快速地产生很多和输入crash相关、但稍有些不同的crashes,从而判断能够控制某块内存地址的长度。这里笔者在实践中没有找到适合的例子,但在一篇文章中发现了一个很不错的例子——tcpdump栈溢出漏洞,crash exploration模式从一个crash产生了42个新的crash,并读取不同大小的相邻内存。

10.jpg

2. triage_crashes

AFL源码的experimental目录中有一个名为triage_crashes.sh的脚本,可以帮助我们触发收集到的crashes。例如下面的例子中,11代表了SIGSEGV信号,有可能是因为缓冲区溢出导致进程引用了无效的内存;06代表了SIGABRT信号,可能是执行了abort\assert函数或double free导致,这些结果可以作为简单的参考。

$ ~/afl-2.52b/experimental/crash_triage/triage_crashes.sh fuzz_out ~/src/LuPng/a.out @@ out.png 2>&1 | grep SIGNAL
   +++ ID 000000, SIGNAL 11 +++
   +++ ID 000001, SIGNAL 06 +++
   +++ ID 000002, SIGNAL 06 +++
   +++ ID 000003, SIGNAL 06 +++
   +++ ID 000004, SIGNAL 11 +++
   +++ ID 000005, SIGNAL 11 +++
   +++ ID 000006, SIGNAL 11 +++
   ...

3. crashwalk

当然上面的两种方式都过于鸡肋了,如果你想得到更细致的crashes分类结果,以及导致crashes的具体原因,那么crashwalk就是不错的选择之一。这个工具基于gdb的exploitable插件,安装也相对简单,在ubuntu上,只需要如下几步即可:

$ apt-get install gdb golang
$ mkdir tools
$ cd tools
$ git clone https://github.com/jfoote/exploitable.git
$ mkdir go
$ export GOPATH=~/tools/go
$ export CW_EXPLOITABLE=~/tools/exploitable/exploitable/exploitable.py
$ go get -u github.com/bnagy/crashwalk/cmd/...

crashwalk支持AFL/Manual两种模式。前者通过读取crashes/README.txt文件获得目标的执行命令(前面第三节中提到的),后者则可以手动指定一些参数。两种使用方式如下:

#Manual Mode
$ ~/tools/go/bin/cwtriage -root syncdir/fuzzer1/crashes/ -match id -- ~/parse @@
#AFL Mode
$ ~/tools/go/bin/cwtriage -root syncdir -afl

11.jpg

两种模式的输出结果都一样,如上图所示。这个工具比前面几种方法要详细多了,但当有大量crashes时结果显得还是十分混乱。

4. afl-collect

最后重磅推荐的工具便是afl-collect,它也是afl-utils套件中的一个工具,同样也是基于exploitable来检查crashes的可利用性。它可以自动删除无效的crash样本、删除重复样本以及自动化样本分类。使用起来命令稍微长一点,如下所示:

$ afl-collect -j 8 -d crashes.db -e gdb_script ./afl_sync_dir ./collection_dir --  /path/to/target --target-opts

但是结果就像下面这样非常直观:

11-1.jpg

五、代码覆盖率及其相关概念

代码覆盖率是模糊测试中一个极其重要的概念,使用代码覆盖率可以评估和改进测试过程,执行到的代码越多,找到bug的可能性就越大,毕竟,在覆盖的代码中并不能100%发现bug,在未覆盖的代码中却是100%找不到任何bug的,所以本节中就将详细介绍代码覆盖率的相关概念。

1. 代码覆盖率(Code Coverage)

代码覆盖率是一种度量代码的覆盖程度的方式,也就是指源代码中的某行代码是否已执行;对二进制程序,还可将此概念理解为汇编代码中的某条指令是否已执行。其计量方式很多,但无论是GCC的GCOV还是LLVM的SanitizerCoverage,都提供函数(function)、基本块(basic-block)、边界(edge)三种级别的覆盖率检测,更具体的细节可以参考LLVM的官方文档

2. 基本块(Basic Block)

缩写为BB,指一组顺序执行的指令,BB中第一条指令被执行后,后续的指令也会被全部执行,每个BB中所有指令的执行次数是相同的,也就是说一个BB必须满足以下特征:

只有一个入口点,BB中的指令不是任何跳转指令的目标。

只有一个退出点,只有最后一条指令使执行流程转移到另一个BB

13.jpg

将上面的程序拖进IDA,可以看到同样被划分出了4个基本块:

12.jpg

3. 边(edge)

AFL的技术白皮书中提到fuzzer通过插桩代码捕获边(edge)覆盖率。那么什么是edge呢?我们可以将程序看成一个控制流图(CFG),图的每个节点表示一个基本块,而edge就被用来表示在基本块之间的转跳。知道了每个基本块和跳转的执行次数,就可以知道程序中的每个语句和分支的执行次数,从而获得比记录BB更细粒度的覆盖率信息。

15.jpg

4. 元组(tuple)

具体到AFL的实现中,使用二元组(branch_src, branch_dst)来记录当前基本块 + 前一基本块 的信息,从而获取目标的执行流程和代码覆盖情况,伪代码如下:

cur_location = <COMPILE_TIME_RANDOM>;//用一个随机数标记当前基本块
shared_mem[cur_location ^ prev_location]++;//将当前块和前一块异或保存到shared_mem[]
prev_location = cur_location >> 1;//cur_location右移1位区分从当前块到当前块的转跳

实际插入的汇编代码,如下图所示,首先保存各种寄存器的值并设置ecx/rcx,然后调用__afl_maybe_log,这个方法的内容相当复杂,这里就不展开讲了,但其主要功能就和上面的伪代码相似,用于记录覆盖率,放入一块共享内存中。

16.jpg

六、计算代码覆盖率

了解了代码覆盖率相关的概念后,接下来看看如何计算我们的测试用例对前面测试目标的代码覆盖率。

这里需要用到的工具之一是GCOV,它随gcc一起发布,所以不需要再单独安装,和afl-gcc插桩编译的原理一样,gcc编译时生成插桩的程序,用于在执行时生成代码覆盖率信息。

另外一个工具是LCOV,它是GCOV的图形前端,可以收集多个源文件的gcov数据,并创建包含使用覆盖率信息注释的源代码HTML页面。

最后一个工具是afl-cov,可以快速帮助我们调用前面两个工具处理来自afl-fuzz测试用例的代码覆盖率结果。在ubuntu中可以使用apt-get install afl-cov安装afl-cov,但这个版本似乎不支持分支覆盖率统计,所以还是从Github下载最新版本为好,下载完无需安装直接运行目录中的Python脚本即可使用:

$ apt-get install lcov
$ git clone https://github.com/mrash/afl-cov.git
$ ./afl-cov/afl-cov -V
afl-cov-0.6.2

还是以Fuzz libtiff为例,计算Fuzzing过程的代码覆盖率流程如下:

第一步,使用gcov重新编译源码,在CFLAGS中添加"-fprofile-arcs""-ftest-coverage"选项,可以在--prefix中重新指定一个新的目录以免覆盖之前alf插桩的二进制文件。

$ make clean
$ ./configure --prefix=/root/tiff-4.0.10/build-cov CC="gcc" CXX="g++" CFLAGS="-fprofile-arcs -ftest-coverage" --disable-shared
$ make
$ make install

第二步,执行afl-cov。其中-d选项指定afl-fuzz输出目录;—live用于处理一个还在实时更新的AFL目录,当afl-fuzz停止时,afl-cov将退出;–enable-branch-coverage用于开启边缘覆盖率(分支覆盖率)统计;-c用于指定源码目录;最后一个-e选项用来设置要执行的程序和参数,其中的AFL_FILE和afl中的”@@”类似,会被替换为测试用例,LD_LIBRARY_PATH则用来指定程序的库文件。

$ cd ~/tiff-4.0.10
$ afl-cov -d ~/syncdir --live --enable-branch-coverage -c . -e "cat AFL_FILE | LD_LIBRARY_PATH=./build-cov/lib ./build-cov/bin/tiff2pdf AFL_FILE"

成功执行的结果如下所示:

14.jpg

我们可以通过—live选择,在fuzzer运行的同时计算覆盖率,也可以在测试结束以后再进行计算,最后会得到一个像下面这样的html文件。它既提供了概述页面,显示各个目录的覆盖率;也可以在点击进入某个目录查看某个具体文件的覆盖率。

17.jpg

点击进入每个文件,还有更详细的数据。每行代码前的数字代表这行代码被执行的次数,没有执行过的代码会被红色标注出来。

18.jpg

参考资料

[1] Fuzzing with AFL

[2] INTRO TO AMERICAN FUZZY LOP – FUZZING WITH ASAN AND BEYOND

[3] Clang 9 documentation – SanitizerCoverage

[4] honggfuzz漏洞挖掘技术深究系列

[5]How Much Test Coverage Is Enough For Your Testing Strategy?

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

原文阅读

个人蜜罐Cowrie的运营分析
si1ence 2019-3-20 1:0 转存

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

0×0 背景

前段时间自己买了台VPS学习一下如何使用liunx顺便部署了一个Cowrie蜜罐系统准备收集点弱密码和一些病毒文件分析一下,最近运营了一下蜜罐的效果感觉收获还是挺多的,最近恰好Pandazhengzheng也有空说要手把手教我走向逆向大佬之路。

0×1 蜜罐配置

Cowrie是一个具有中等交互的SSH蜜罐,安装在Linux中,它可以获取攻击者用于暴力破解的字典、输入的命令以及上传或下载的恶意文件,具体的介绍和部署方式度娘还是有不少,这里就不凑字数赘述了。

主要使用了Cowrie的默认配置本地监听了2222端口转发蜜罐的22端口的流量,本机的ssh已经修改为28726端口:

特地用nmap扫描了一下可以发现22端口是打开状态的:

这边主要设置了2个蜜罐的ssh户,root密码难一点用于获取更多的密码,admin简答一些用户关注登录成功后的行为,配置文件主要位于cowrie主目录下的/etc/userdb.txt:

然后大致看了一下cowrie.log的日志有6W+行的事件日志:

为了统计数据方便记录的数据,都统一存放到本地的mysql数据库,默认有以下几个数据表:

0×2 SSH暴力破解

系统记录了2个月前到现在的日志,累计被爆破了73032次,差不多一天1000多次。

统计了常见的Top20 的爆破的用户,主要还是admin、root:

统计了常见的Top20 的爆破的密码,主要还是password,123456这种:

统计了一下爆破次数最多的一些IP地址:

分别对第一和第二这2个IP进行威胁情报查询都能被识别出恶意IP:

0×3 恶意下载

查询input数据表记录了攻击登录后执行的命令,由于内容比较多这里只选取了部分关注一下:

简单的过了一下抽取3种比较典型案例简单的看了看分别是:

1.Linux.Lady

2.XorDDos

3.DDG挖矿套件

Linux Lady下载连接:http://45.61.136.193/mi3307 

病毒哈希:e25c7aa18ee7c622cbd38ac0d27828c245de0fc0ee08e06bb11ac94fbe841471

本来还拖进IDA看了一下,结果居然搞不出来,此刻再一次流下了没有技术的泪水。

威胁情报检出:

Linux XorDDos 下载连接:http://45.61.136.193/s443ls

病毒哈希:2409fb21fe377f7e12dda392f26d7c93b7715239169d362dd907fe499ab38ee9

详细分析报告如下:熊猫正正的XorDDos详细分析

Linux DDGMiner这个最近已经遇见好几起了还算比较热门就不多扯淡了。下载连接:http://104.248.181.42:8000/i.sh

这个主要是一个Downloader主要功能就3个一目了然的那种:

1.根据系统版本下载对于的DDG挖矿病毒样本

2.加入定时任务做持久化

3.排除异己干掉其他挖矿的程序

通过对这个104.248.181.42这个IP进行威胁情报分析可以发现这个上面能关联较多的病毒的样本主要都几种在2019年2月-3月份还比较新鲜,更新迭代的速度还是很快的很多连接都已经失效了。

0×4 总结

通过蜜罐这种主动防御技术记录攻击者的一些交互行为与命令,对于收集一些威胁情报与流行的攻击手法应对僵尸网络等方面还是具有积极的作用。Cowrie这种轻量级功能也是有限兴趣爱好者玩玩还好真搞大事情还是有点cover不住,T-Pot多蜜罐平台在企业实践的过程当中应该会更具有竞争力一些。

虽然是已知的,还是贴一下IOC:

http://45.61.136.193/mi3307

http://23.247.54.36/i3306m

http://45.61.136.193/isu80

http://45.61.136.193/s443ls

http://45.61.136.193/ys53a

http://23.247.54.36/ys808e

http://45.61.136.193/g3308l

http://104.248.181.42:8000/i.sh

IP:

104.236.156.211

206.189.94.170

218.206.107.34

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

原文阅读

Facebook数据造假,竟涉及多家中国公司
GEETEST极验 2019-3-20 0:30 转存

一个创立十五年的社交网站,全球用户量超过20亿。但是却屡屡遭遇隐私问题争议,最近还出现相关报告发布称其20亿用户或超半数都为“虚假账户”……

1.jpg

多年来的“私人恩怨”

在Facebook不断发展的过程中,似乎从来不缺人气与争议。

除了隐私之外,还存在“私人恩怨”。扎克伯格哈佛校友的艾伦·格林斯潘,曾宣称拥有facebook商标的所有权,并且多年来坚持同facebook公司“斗争”。

2.jpg

格林斯潘说自己在Facebook上线前三个月就提出了类似的创意,名字叫「the Face Book」,他甚至还主动联系过扎克伯格希望合作。为此,他对外公布了一些早期的通讯记录,甚至还专门写了本书,描述自己创造HouseSYSTEM网站的过程,并宣称它是facebook的始祖。

“有好几次,在路上碰到、从我的门前经过、在帕罗阿托的餐厅吃墨西哥餐,我示以微笑,或者向他招招手,他都可以走过来,道个歉的。但是,他从来都没这样做过。他一点都不感觉愧疚。”

但是硬气如扎克伯格,格林斯潘始终没有等来Facebook的“解释”。于是格林斯潘坚持“斗争”,在各个方面找扎克伯格茬,越来越“柠檬”了,并且2012年的时候就直接状告Facebook盗用其商标。

4、.jpg

跨国官司的导火索

没想到上诉也没得到道歉,一气之下格林斯潘憋了一个大招。

2019年1月底,格林斯潘公布了一个关于Facebook的报告,长达70多页的报告直接指出Facebook的20亿月活用户中有超过一半都是虚假账户。

3.jpg

报告一出就引起轩然大波,沸沸扬扬的隐私安问题还没有解决,就又出现了“虚假账号”的负面新闻。Facebook官方也赶紧出来澄清,说:“有关虚假账户的报告是明显错误的,并且是不负责任的。”之后就直接起诉了四家中国公司和三位个人。

就这样,跨国官司的序幕打开。

被状告的四家中国公司主要贩卖Facebook、twitter等国外社交账号。Facebook指控这些企业和个人创建及销售虚假网络账号、点赞和关注者,用于传播虚假消息或其他欺诈行为。从2017年开始,这些公司通过myfacebook.cc和9xiufacebook.com等六个与Facebook有相似域名的网站行销和出售了大量虚假账号。

纠缠数年的噩梦——虚假账户

回过头来看,虚假账户并非新伤,而是Facebook的一个纠缠了数年的噩梦:

2012年9月,Facebook开始严打僵尸粉,删除虚假账号;

2013年3月,Facebook可能有8300万个“僵尸账号”;

2015年3月,Facebook清理僵尸粉导致名人点赞量下降10%;

2018年8月,Facebook删除试图干预美国中期选举的虚假账号;

2018年11月,Facebook公布有害内容清理报告:清理15亿虚假账号;

2019年2月,有报告称:Facebook 20亿月活用户一半都是假账号;

2019年2月,Facebook状告4家中国公司和3位个人推销虚假账号、点赞和用户好友;

……

除了官方公布虚假账号情况之外,早在2014年在YouTube就出现过一个名为《Facebook Fraud》的视频,里面主要介绍一位博主参与Facebook的推广计划之后,出现了粉丝量增加但推文关注、互动情况不变甚至减少的情况,怀疑Facebook用户中存在着大量“机器用户”。

Facebook Fraud

而这次格林斯潘的报告中,指出Facebook的系统性欺诈“不容小觑”。根据Statista的数据,Facebook在2018年的广告收入高达338亿美元。 也就是说,如果说10亿的“虚假账号”数量是真实的,那么就意味着Facebook从广告主那里获得的收益是“不义之财”。

5.jpg

图片来自新浪财经

不仅如此,除了Facebook这次上诉的几家中国企业,全球售卖虚假账号的灰产链条也早就野蛮生长、遍地开花了。

比如美国,类似Devumi、SocialBoss等营销推广网站,内容点赞、涨粉、视频播放刷量都应有尽有,价格多从1到20美元不等,还有一些网站直接售卖相关账号。

6.jpg

而国内相关的灰产就更多了,根据带不带cookie、注册年限、好友多少,账号价格不等。

8.jpg

有意思的是,通过灰产的宣传,发现其实国内外购买这些虚假账号的目的也有些许的差别。美国购买账号的大部分主要用于涨粉、增加点赞量等,而中国购买账号还涉及到不少跨境电商推广等商业目的。

在上述博主的视频中通过统计,发现他的“虚假粉丝”主要来源于发展中国家。Facebook在2017年的观察报告中也指出,大部分虚假帐户来自孟加拉国、印度、埃及和巴基斯坦等国。而这背后也反映出整个虚假账号、虚假流量市场不同地域的犯罪成本差距。与发达国家比较,发展中国家的确存在相关法律不健全、监管不到位、惩戒体系不完善、意识很欠缺等问题,甚至在斯里兰卡、埃及、印尼等地区还存在“机器工厂”,点击1000次只需要1美金。总体来说犯罪成本都远远低于发达国家,所以也就出现下图的情况。

9.jpg

机器之争,如何掌握主动权

而如今困扰各大社交平台的“虚假账号”、“虚假流量”其实在发展初期并没有受到过多的关注与打击,甚至还成为当时用户量、活跃度统计中重要的一部分。遗憾的是,水能载舟亦能覆舟。当初各平台所追求的“数字”如今却成为难以摆脱的梦魇。

当然,从2012年到今天,其实我们也看到了Facebook在面对“虚假账号”、“虚假流量”之下在不断作出努力。甚至还想过请FBI调查…

10.jpg

但是就目前来看还是存在许多问题:

一是误杀较多,影响用户体验;

二是对于异常账户检测技术方面还有许多进步空间。

第一个误杀的情况,由于Facebook的封禁是从设备硬件、账号登录情况、运营内容等多维度进行的。Facebook主管分析的副总裁Alex Schultz之前在采访中透露,平台已经在使用机器学习判定假账号。通常来说,一个被批量制造出来的帐号会在几分钟内被移除。

这样一来,如果出现IP、账号反复登录等异常情况,很可能就会被封禁,误杀率就这样被提高了。

11.jpg

第二点是从2012年到现在,Facebook多次大面积封禁虚假账号,但是这“野草烧不尽”般的势头背后反映出其在防御策略和技术方面还是有很多进步空间。

而目前对于异常账户的检测主要有以下几种方式:

基于行为特征的检测方案;

基于内容的检测方案;

基于图的检测方案;

无监督学习。

目前很多平台主要使用的还是基于内容的检测方案,辅之基于行为特征的检测方案。但是随着AI的不断发展,“机器账号”的伪装能力越来越强,这场机器之战之下,我们必须采用更为精细、科学的处理方式。比如从注册审核环节、使用轨迹等维度建立多维度、多环节、长周期的分析模型,尽力提高对于异常账户的检测精度。

而目前随着图学习、社交网络等研究的不断发展,我们也可以采用基于图的检测方案。这种方式的关键是构造一个图,在图中异常帐号与正常帐号具有不同的结构或者连接方式,然后利用图挖掘的相关算法找到图中具体的异常结构或者异常节点。从一个“异常账号”找到相类似的更多机器账号。

12.jpg

对于异常账户的检测,一直是做安全、做风控的研究重点。随着机器学习的发展,这两年复杂网络、GCN逐渐崛起,新技术的创新将近在咫尺。

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

原文阅读

一次命中可疑威胁情报的分析探索
si1ence 2019-3-20 0:0 转存

0×0 背景

由于最近一段时间里”驱动人生”这个病毒还挺热门,最近发现通过一些安全厂商的设备发现内网里面有大量的主机都中了这个病毒瞬间吓哭了。后续通过对主机进行检查,居然没有发现什么问题,后续发现是安全设备命中了一个威胁情报的IP,通过对IP的分析发现这还有这种操作。

0×1 过程

然后我登录上了安全设备去查看IP地址,安全设备提示为:120.52.51.13,作为安全小白通过各种收集定位到了freebuf的一篇文章结尾公布出来的IOC里面,同样的也有大佬在质疑这个IP是否真的有问题了。

然后这边直接访问这个IP返回如下界面,看起来是缺了某一个参数感觉也没有什么大问题,看起来也没有什么应用,就先借助于威胁情报查询一下了。

通过对该IP的查询,提示为联通的IDC机房使用位于河北廊坊,威胁情报提示为僵尸主机。

通过对微步在线的威胁情报进行查询提示未知。

再一次通过VT进行一下分析,这里面的内容就要丰富一些了,可以看到关联到了很多奇奇怪怪的URL和一些病毒样本,大多数时间点还是2019年2月到3月之间的信息。

在这些奇奇怪怪的URL当中可以还发现很多知名大公司的域名看着想是iqiyi的cdn,还是adobe的msp文件,看起来应该是的的确确的白域名才对。

在白域名的同时也发现了一些黑的域名比如a46.bluehero.in/download.exe。

该样本为蠕虫病毒bulehero详细分析结果可以参考:https://s.tencent.com/research/report/514.html

0×3 测试

仔细看了这些url发现有个特点跟在这个域名后的根目录的,都是网页路径于是大胆的猜想这个应该是实现了一个基础的跳转功能,原理应该类似URL的Redirect这种操作。

大概的原理可能是这样至于为什么要这样玩,猜测原因可能如下:

1. 绕过一些威胁情报的检测

2. CDN的一些多节点加速下载访问之类的优化

3. 流量代理或者劫持之类的

鉴于很多知名厂商都有这种行为,猜测CDN优化或者流量代理的可能性大一些。但是这些对于很多安全来说的也的确存在一些绕过的可能。毕竟这个IP服务器自己是没有什么问题的。

大致原理如下:

后续找了一台主机自己测试一下访问,结果的确是直接返回类似与Redirect,直接在浏览器当中返回了后续的网址的路径。输入www.baidu.com当前界面就直接跳转到百度。

本地抓包也看了一下发现本主机也是仅只与120.52.51.19建立了HTTP连接。

通过对同网段的IP进行测试发现都是存在同样的情况:

120.52.51.13----- 120.52.51.20

0×4 抓包检查

由于没有拿到此web的具体实现的一些源码很多猜想也无法得到证实,于是在网关处进行抓包想看一下具体请求的URL定位到如下2个:

120.52.51.13:80/osce11-ilspn30-p.activeupdate.trendmicro.com:80/activeupdate/pattern/itbldiff_1914201800_1914201900.zip

120.52.51.13:80/osce11-ilspn30-p.activeupdate.trendmicro.com:80/activeupdate/pattern/crczdiff_1914002000_1914200400.zip

通过对内存进行检查最后定位到趋势科技的产品的进程,看起来应该是升级包一类的操作吧。

0×5 总结

通过一些查询发现还是不少这样的IP服务器因为安全经验不足一时间也搞不清楚背后的套路,始终觉得有点诡异或者是什么新姿势,但是对主机进行检查又没有发现其他异常初步认为此次行为这就是个误报就算结案了还好是虚惊一场,不然又得加班几点搞了最近已经快吃不消了,祝愿各位IT大佬们少加班吧。

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

原文阅读

BUF早餐铺 | 欧盟政府网站被发现使用来自 Google 等公司的跟踪器;记者耗时3个月测试,美团饿了么是否在“偷听”;9款违规App曝光,涉及恶意扣费、隐私窃取、赌博
shidongqi 2019-3-19 23:0 转存

各位Buffer早上好,今天是2019年3月20日星期三。今天的早餐铺内容主要有:欧盟政府网站被发现使用来自 Google 等公司的跟踪器;新的Mirai僵尸网络变种涉及27个漏洞,瞄准企业设备;疑似APT-C-27(黄金鼠)利用WinRAR漏洞针对中东地区的定向攻击;记者耗时3个月测试,美团饿了么是否在“偷听”;9款违规App曝光:涉及恶意扣费、隐私窃取、赌博。

DanishBakery.BreakfastTreats.jpg

欧盟政府网站被发现使用来自 Google 等公司的跟踪器

Cookiebot 扫描了(PDF) 184,683 个欧盟政府网站网页,发现 82% 的欧盟政府网站使用了来自 Google 的广告跟踪器,只有西班牙、德国和荷兰的政府网站没有嵌入商业跟踪器。五个使用率最高的跟踪器中,三家来自搜索巨人:YouTube、DoubleClick 和 Google。报告作者对此表达了担忧,因为 Google 可以将第三方网站的跟踪器与它的第一方服务的跟踪器互相参照。研究还评估了公共健康服务网站的跟踪器,发现测试的 52% 的网页有商业跟踪器,五个使用率最高的跟踪器中 Google 占两家,另外三家是 Adobe 的 eversttech.net、AppNexus 的 adnxs.com 和 Mediamath 的 Mathtag.com。[来源:Solidot]

新的Mirai僵尸网络变种涉及27个漏洞,瞄准企业设备

一个新的Mirai变种带来了11个新的漏洞攻击,企业WePresent WiPG-1000无线演示系统和LG Supersign TV是最显眼的目标。由于其创造者增加了11个新的漏洞用于攻击,总数现已达到27。正如Unit 42进一步发现的那样,僵尸网络的恶意利用代码托管在哥伦比亚公司的服务器上,具有讽刺意味的是, 该服务器提供“电子安全,集成和警报监控”服务。[来源:NOSEC]

疑似APT-C-27(黄金鼠)利用WinRAR漏洞针对中东地区的定向攻击

2019年3月17日,360威胁情报中心截获了一例疑似“黄金鼠”APT组织(APT-C-27)利用WinRAR漏洞(CVE-2018-20250[6])针对中东地区的定向攻击样本。该恶意ACE压缩包内包含一个以恐怖袭击事件为诱饵的Office Word文档,诱使受害者解压文件,当受害者在本地计算机上通过WinRAR解压该文件后便会触发漏洞,漏洞利用成功后将内置的后门程序(Telegram Desktop.exe)释放到用户计算机启动项目录中,当用户重启或登录系统都会执行该远控木马,从而控制受害者计算机。[来源:360威胁情报中心]

记者耗时3个月测试,美团饿了么是否在“偷听”?

你遇到过这样的情况吗?刚说了想吃什么,手机就蹦出了它的推荐;刚说了要买什么,就出现了广告。可是,手机怎么知道你刚刚说了什么呢?一位读者2018年11月的投诉,他怀疑外卖App在“偷听”自己说话。记者耗时3个多月,通过模拟用户使用场景,对安卓手机、苹果手机、苹果平板电脑上的饿了么和美团外卖进行多轮测试。在随后数分钟到数小时的时间里,出现相关推荐的概率高达60%-70%。对此,饿了么和美团回应:不存在“偷听”!近日,记者更新了最新iOS版美团外卖、饿了么,它们都不再索取麦克风权限,不过安卓版里的录音权限依然存在。[来源:澎湃新闻]

9款违规App曝光:涉及恶意扣费、隐私窃取、赌博

据网信广东消息,国家计算机病毒应急处理中心近期在净网行动中通过互联网监测发现,9款违法有害移动应用存在于移动应用发布平台中,其主要危害涉及恶意扣费、隐私窃取、赌博三类。

这些违法有害移动应用具体如下:

1、《PhotoLoop》(版本20.4)、《快对答案》(版本7.9.0)这两款应用存在扣费恶意代码,通过隐蔽等手段,导致用户经济损失。

2、《蓝贷》(版本1.0)、《吃鸡神助攻》(版本2.2.0)这两款应用存在危险行为代码,警惕该应用私自下载安装软件,窃取用户隐私信息,造成用户隐私泄露、资费消耗。

3、《Remember Everything-数字记忆》(版本1.1.0)、《大菠萝-线上平台》(版本1.0)、《炸金花-全民真人炸金花欢乐版》(版本1.0)、《Cuncaoxin Education》(版本1.0.6)、《银河娱乐》(版本1.1)这五款移动应用涉及赌博,通过押点数、斗牌、博彩等形式进行含有赌资往来的赌博活动,涉及违法并存在财产风险。[来源:IT之家]

原文阅读

探针盒子?不用怕!手把手教你打造专属隐私保护工具
知道创宇KCSC 2019-3-19 7:20 转存

今年的 315 晚会上曝光了智能骚扰电话,其中提到了一个叫 WIFI 探针的东西。它能够获取周围用户的手机 Mac 地址,转换成 IMEI 号,最后再转换成手机号码。这是一种非常恐怖信息窃取方式,不同于以往的「主动」泄露,这种泄露方式完完全全是被动的,且受害者被窃取信息后毫不知情。   

1552897235_5c8f54d3133dc.png!small

WIFI 探针工作原理(图片来自某售卖 WIFI 探针的官网    

于是我便想着要来跟大家分享一个我自己倒腾出来的一个小小「黑科技」。虽说是一个小东西,但是里面涉及到了 lOT 控制的相关内容。下面我就把我做这个东西的思路和具体的制作方法(包括代码)分享出来,希望能在隐私疯狂泄露的当下,能给大家提供一种保护自己的办法。

故事前提

大概是 6 年前,一次酒店数据泄露事件使得我的个人隐私被彻底曝光。那次数据泄露在业内造成了很大的轰动,当时在网上也有很多网友对此展开了激烈的讨论。   

1552897435_5c8f559b1a7ac.png!small

知乎提问截图,提问时间为 2013 年 10 月

在那之后,我开始接到大量的骚扰电话。并且,电话一接通就开始直呼我的名字。作为一个网络安全行业从业者,怎么能忍?

1552897475_5c8f55c30a188.png!small

插播一句:时至今日,信息泄露事件是越来越多,几乎每天都有各种泄露事件的报道…相信陌生人拨打你的电话并直呼你名字的这种事,很多人都遇到过。

个人隐私对我来说是非常重要的信息(对于大家来说也是,所以一定要重视!),这样被泄露后给我照成了很大的安全风险,因此我开始寻找解决办法。

想法初步形成

其实最简单的解决办法就是定期更换手机号码。但是!现在手机号码绑定的东西实在是太多了…各种银行卡、各种账号…每换一次我至少得花几天时间去跑上跑下…并且还要挨个通知身边人…解决办法一 pass

那我就用两个手机号不就行了?

1552897514_5c8f55ea9d00a.png!small

一个手机号不常用,但是很重要。我不会随意给外人提供,这个号码用来绑定银行账号等重要信息,在一些重要的账户开启两步验证的时候作为验证手机来接收验证短信。

另一个手机号常用,但相对不重要。我就用来绑定比如某宝的收货地址啥的,等用了一年的时候,就可以直接换掉。任性!

然后我再准备一个双卡双待手机!哈哈哈完美!

等一下!

1552897533_5c8f55fd4cc2b.png!small

那我这篇文章岂不是写完了?不行…绝对不能这么简单…

如果哪天我带着我的双卡双待手机去逛一个有 WIFI 探针的商场,我的信息不是一样被抓取了…

作为一个网络安全从业者,我一定要严谨…

所以我便开始考虑另一种方式——转发。

这样我就能将那不常用且非常重要的手机号放家里,不随身携带。(我放家里除了有人上门给我偷了应该没有什么风险了吧!!!)但是又能远程在我随身使用的手机上接收到发送到家里手机上的一些重要信息,如银行验证码啥的。

当时我给自己找了几个解决方案:

1. 直接使用手机转发短信——经过运营商短信会有费用产生。方案 pass…

2. 用苹果的 message 来转发短信。——我是安卓用户。方案 pass….

3. 走谷歌和 IFTTT 的方式。——被墙了而且需要绕大圈。方案 pass…

怎么都行不通呢!!!

1552897551_5c8f560f86aa3.png!small

最后再三思索下,我决定打造属于我自己的通信方式。说人话就是:我自己做一个硬件短信转发小工具。

正是这个小工具,让我很好的避免了骚扰电话和信息泄露。

开始动手制作

在正式介绍制作方法之前,我先来说说我的这个别致的小东西的原理是什么。

其实它就是一个由树莓派和通信模块组成的小工具,能插上电话卡接收短信息,并且能自动把短信转发到我随身使用的手机上。(原理是不是很简单!)

并且这个装置使用了最原始的 AT 指令通过串口进行控制。像 WIFI、蓝牙、手机与基站的通信对话,还有老早以前的 Modem,这些最基本的通信对话就是使用的是 AT 指令。

下面我们就来看看,制作这个工具需要的材料有些啥。

树莓派 某宝价格:220 RMB

1552897653_5c8f5675d2a0d.png!small

通信模块:GSM900A 某宝价格:40-50 RMB

1552897708_5c8f56ace44cc.png!small

通信模块:移远 EC20 淘宝价格:150-200 RMB    

1552897672_5c8f5688cead9.png!small

看到这里你肯定会有疑问了,为什么会有两种不同通信模块,他们的区别是什么?该使用哪个?

GSM900A 是一个 2G 模块,能接收短信。而 EC20 是 4G 模块,相对来说要高级一些。(可以脑补 2G 手机和 4G 手机的区别)其实最开始我使用的就是 GSM900A,因为对于我的需求来说(接收短信),这个 2G 模块已经足够了。(而且还要便宜一些,感觉省了一大笔呢!)

1552897733_5c8f56c59cfde.png!small

但是最后我还是换成了 EC20 的 4G 模块,最重要的原因是在 4G 环境下能够防范一些在 2G 情况下被嗅探攻击的情形。(作为一个网络安全从业者,我一定要严谨…)

相信大家对嗅探攻击这个新闻一定不陌生。

1552897749_5c8f56d592496.png!small

嗅探攻击新闻截图,新闻发布于 2018 年 8 月

并且从我使用后的角度来说,EC20 的速度和稳定性要明显高于 GSM900A。所以还是跟大家推荐 EC20。

除了树莓派和通信模块 EC20 之外,我还给我的小东西增加了两个装置:

乌⾦甲外壳 铝合⾦外壳带双风扇 某宝价格:60 RMB

1552897796_5c8f5704a75e6.png!small

直插三极管 NPN SS8050 某宝价格:0.05 RMB(四舍五入不要钱!)

1552897812_5c8f571410688.png!small

原因是…. 树莓派在夏天发热特别厉害,所以我就给它加一个风扇来降温。(当然家里有矿可以 24 小时开空调的同学这部分你就不用看了)

但是我又不想让风扇持续转,(一直转好傻嘛,当然要智能一点!)所以我又在代码里面加了 CPU 温度检测,对风扇进行控制。当温度达到指定高度时,小风扇才会旋转起来~

这部分的制作我参考了这个:    

树莓派用开关三极管控制散热风扇

杨仕航 http://yshblog.com/blog/55    

1552897838_5c8f572eef28f.png!small

博客页面截图

最终组合成功,就是这个样子!

image.png树莓派+EC20+小风扇(我心爱的小工具)

悄悄告诉大家,其实这个小东西不单单能代替手机,还能通过微信小程序来控制家里想控制的东西。(类似自制智能家居?)这部分内容,我后面有机会可以跟大家分享~

最后一步

一个能接收短信的小工具已经组装完成!最后需要做的就是让它自动把收到的短信发给我。

我这里总结了两条免费接收远程短信的通信途径。

1.注册一个免费的企业微信,在其中建立专门用于接收短信的小程序 ;

2. 在微信当中开通QQ邮箱提醒。

最后就来给大家看看它的效果吧!

image.png我让朋友给我发的测试短信

image.png我在手机上通过小程序推送收到的短信

image.png我手机上通过邮箱推送收到的短信

大家可以注意看时间,几乎是没有延迟的。所以说,这个装置不会影响到接收速度。特别是在等验证码的时候,多等几秒钟都会觉得很漫长。而这个装置不会影响。

总结

一个能避免信息泄露和骚扰电话的小工具就此制作完成~详细的调试代码还请大家移步我的GitHub,里面有非常详细内容。

我的GitHub地址:https://github.com/rungobier/gsm

话说自从我开始使用这个小工具后,我就没有再接到过骚扰电话了。在一定程度上,我认为我的信息还是得到了保护。今天在这里把这个工具分享给大家,喜欢研究的技术宅们完全可以自己搞一个,不会的同学们可以找一个技术宅朋友来帮你们搞一个…

最后,希望在数据泄露十分疯狂的今天,每个人都能保护好自己的隐私。我们希望让互联网更好更安全!

*本文作者:rungobier&芝士,转载请注明来自FreeBuf.COM

原文阅读

用来组流的网络数据包嗅探器:Streamdump
scu-igroup 2019-3-19 7:0 转存

前言

在平时需要对数据包进行分析和统计,亦或是进行抓包时,通常会使用 Wireshark 或者 tcpdump 等工具。这两个工具以及 tshark(wireshark 的命令行),基本上已经涵盖了绝大部分的需求场景,但是如果需要大规模地拆分单个流,进行分析、特征提取时,似乎这些工具都没有能够提供很方便的切流解决方案。

更常见的做法是,通过一个比较抽象的过滤规则,将符合该规则的所有数据包通通记录在一个 pcap 包里,接着再编写一个 Python 脚本或者通过 tshark 与 shell 脚本来实现切流的操作。这似乎没有是么难度,而且也已经解决了问题,应该现成的方案也不少。

Wireshark 与 Tshark 切流的方案

在 Wireshark 中,我们通常是在过滤条件中,输入tcp.stream == ?,?表示某个流在整个包中的编号,而 Wireshark 会根据该编号的 packet 的四元组找出所有符合条件的流进行组装。

但是使用这样需要一个个手动地操作,效率不得不说实在是太低下了,而使用 tshark 来进行切流会快得多,命令:

>tshark -r $LINE -T fields -e tcp.stream|sort -n | uniq -c | awk -F ' ' '{if ($2>=0)print $2 }' >tcp_stream_number.txt

$LINE 代表 pcap 文件名,-T 和 -e 组合使用表示打印 Wireshark 中相应的字段,本例中表示输出 tcp.stream 字段,即流号。因为是针对每一个报文都要输出该报文对应的流号,因此需要做排序,去重的工作。将最后的所有的流号按照大小顺序输入到 tcp_stream_number.txt 文件中。

最后,再将输入的流提取出来:

tshark -r $LINE -Y "tcp.stream == $(($tcpnumber)) " -w $filedic/$streamname.pcap

$LINE 代表pcap文件名,$tcpnumber 表示从 tcp_stream_number.txt 文件中读出的每一行的内容,$(($tcpnumber))转换成数字,$filedic,$streamname 分别表示文件目录和文件名,上述的命令表示从 $LINE 报文中提取流。

如此,就可以进行切流操作了。但是总的来说,虽然 tshark 比起 Wireshark 手动单个操作的方式效率高得多,但是,tshark 是一次性将整个数据包读入内存,分析好后再统一输出的,针对超大文件进行分析时,对资源的需求十分巨大。

换句话说,如果你不是有庞大的内存资源,使用 tshark 来对大文件进行切流操作,是很难进行下去的!另外值得注意的是,当流文件个数过多的时候,由于产生的文件句柄过多,会出现错误,没法继续进行下去。

更重要的一点,切分单个流,我们通常通过四元组进行确定,这只能确定单个方向的流,而更多情况下,我们需要对双向的流进行分析。

StreamDump

所以为了满足前文说的大规模的单个流的组装与分析,本次要介绍的是一个我们小组里一直在使用的一个小工具 —— StreamDump,根据 TCP 流的四元组来将每个 TCP 重新组装还原,并分别保存成一个单独的 pcap 文件。为了运行效率和编译方便,程序使用 Golang 来实现。

程序的几个特点:

支持 BPF 过滤规则,可根据需求来进行自定义过滤

支持捕获双向数据流,保存的文件根据四元组来进行命名:IP[Port]-IP[Port].pcap,在保存双向数据流的情况下,以捕获到的第一个 packet 中的四元组参数进行命名

不仅支持从网卡中实时捕获流量,还支持从 pcap 文件中读取分析,过滤出自己需要的单个的流文件

功能虽然不多,但是却可以做很多的事情!特别当需要解析一个 10G 或者 20G pcap 文件的时候,使用 Python 来解析是效率十分低下的!

分拆出来的 TCP 流有什么用?如果你需要对某个特定的流,或者某组,或者某个特定应用的流进行分析,我想这个工具对你一定十分有用,会让你节省很多时间!

废话少说,下面简单说说如何使用这个小工具:

编译

编译就十分轻松了,go 自带了编译工具,只需要将包里的依赖库取回本地,直接编译就可以了

>go get github.com/google/gopacket
>go build -o streamdump streamdump.go

用例

Usage: streamdump [-hv] [-i interface]
Options:
  -b    Capture bidirectional data flow
  -d string
        The domain name of the packet to be captured
  -f string
        BPF filter rules for pcap (default "tcp")
  -h    print this help message and exit
  -i string
        Interface to get packets from (default "en0")
  -l int
        SnapLen for pcap packet capture (default 1600)
  -promisc
        Set promiscuous mode (default true)
  -r string
        Filename to read from, overrides -i
  -s string
        Filepath to save pcap files (default "./pcap_s")
  -v    Logs every packet in great detail

程序会将两分钟内没有数据传输的连接视为无效

从默认网卡(en0)捕获 baidu.com 对应 ip 以及 443 端口的 tcp 流量:

命令:./streamdump -f 'tcp and port 443' -s './stream/' -d '[www.baidu.com](http://www.baidu.com)'

程序会主动查询[www.baidu.com](http://www.baidu.com)这个域名对应的 ip,并根据过滤条件进行过滤,将符合这个过滤条件的 TCP 流保存下来,如图:

从 pcap 文件中过滤出单个 TCP 流量:

命令:./streamdump -r './file.pcap' -f 'tcp' -s './stream/'

还有很多自定义的组合,需要大家自己动手操作了!比如使用-b选项进行双向数据保存!

好了,简要的介绍就到这里了,希望这个小工具能够为大家稍稍提升一些效率!

重要地方来了!!!我们已经对程序进行了开源,更详细的用例在 Github 上已有说明,需要的同学自行阅读!

开源地址

可执行程序下载地址

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

原文阅读

SIEM中心日志节点WEF搭建说明
mr.anderson 2019-3-19 6:0 转存

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

背景介绍

在 SIEM (安全应急事件管理) 搭建中,日志是及其重要的一环。对于黑客掌上的明珠——域控, 它的日志监控是非常重要的,本文将介绍如何通过 WEF(Windows Event Forwarding) 将windows 主机日志汇总到一台中心节点,并输入到ElasticSearch ,最后通过Kibana 的展示。

此架构的优点:

查询快速;

通过调用ES可以实现安全事件实时监控。

Windows WEF 环境配置

Windows Event Forwarding 在windows 2008时就已经启用,主要用于日志中心化收集和转储,好处很多。

运行必要条件

一台在域控中的日志收集节点 (server 端);

任意一台需要发送到日志中心节点的域内主机 (client 端);

一个域控管理员权限用户;

Client 端的日志读取账户权限需要开启network services 权限;

防火墙对域内的5985/5986端口白名单,用于日志传输。

架构介绍

windows 的日志转发有两种方式:

收集器已启动;

源计算机已启动。

考虑到安全性,可以选择源计算机已启动,好处是只需要开启域控到收集端的访问,无需在域控中添加账户。一旦收集端出现安全风险,在防火墙配置正确的前提下,也不会影响任何域控,

此文将按照源计算机已启动为方法做介绍,其中角色:

client 日志发送方;

server 日志收集方。

Client 端配置

Client 的 security log 权限查询和添加

使用管理员权限打开 powershell ,运行如下命令:

wevtutil gl security

该命令是用于检查security 日志读取权限是否允许network service 读取。

返回应该是如下内容则配置成功:

PS C:\Windows\system32>  wevtutil gl security
...
channelAccess: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS

如果缺少 (A;;0×1;;;NS) 表示network service 权限没有加到security 日志项中。需要单独添加,添加前记得先将结果保存后,然后追加 network service权限。

Client 的 security 日志的 network 权限添加

组策略-> 计算机配置 -> 管理模板 -> windows 组件 -> 事件日志服务器 -> 安全-> 配置日志访问

然后双击后,选择已启用,将 wevtutil gl security 中的值和(A;;0×1;;;NS)加入到配置项中 ,如

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

Client 的发送目标配置

组策略-> 计算机配置 -> 管理模板 -> windows 组件 -> 事件转发 -> 配置目标订阅管理器(即就是我们的server端地址)

选择已启用,并输入:

Server=http://logcentra.domain.com:5985/wsman/SubscriptionManager/WEC

Server 端配置

打开日志收集项

使用管理员权限打开powershell 或cmd ,运行winrm qcWinRM 服务,并激活日志收集项:

运行成功后你会看到5985 5986端口打开。

配置日志接收项和接收的计算机

打开事件查看器,并选择左侧订阅:

选择右侧的创建订阅,并选择你感兴趣的item项。

选择添加刚刚配置的域计算机,并输入计算机名即完成日志接收端配置。

转发错误的日志查看

上述已经将整个日志转发流程配置完成了,但是肯定有疏漏的地方,如果想要排错,建议在 client 端的日志发起方查看日志,查看位置在:

事件管理器 -> 应用程序和服务日志 -> Microsoft -> windows -> Eventlog-forwardingPlugin

其他命令

命令行导入自定义订阅日志规则:

wecutil cs DomainComputers.xml

wecutil cs DomainControllers.xml

Windows 下的 nxlog 转发配置

nxlog [https://nxlog.co/ ] 是用于将windows 日志json 化以后转发到 ES 或者 Logstash 的开源工具。

其中的关键配置分为输入端和输出端,输入端当然是windows 的事件日志,由于我们是转发日志,所以需要在 Select Path 输入 ForwardedEvents。

输入端:

<Input in>
  Module      im_msvistalog
	Exec 	to_json();
	Query	<QueryList>\
                    	<Query Id="0">\
					Select Path="ForwardedEvents">*</Select>\
                	</Query>\
		</QueryList>
</Input>

输出端用于将日志输出到制定服务,该实例是将日志输出到 logstash。

输出端配置:

<Output out>
  Module om_ssl
  Host IP_Address
  Port Port_Number
  CaFile %ROOT%\cert\ca.pem
  OutputType LineBased
</Output>

<Output out_debug>
    Module	om_file
    File	"C:\\nxlog_debug.log"
</Output>

可以看到日志传输是使用自签发证书加密的,保证了日志传输安全性。

logstash 日志配置

input {
  tcp {
        port => Port
        type => "nxlogs"
        ssl_cert => "/etc/logstash/conf.d/ssl/logstash.crt"
        ssl_key => "/etc/logstash/conf.d/ssl/logstash.key"
        ssl_extra_chain_certs => ["/etc/logstash/conf.d/ssl/ca.pem"]
        ssl_verify => false
        ssl_enable => true
        codec => 'json'
    }
}
filter
{
        if [type] == "nxlogs" {
          date {
              match => ["[EventTime]", "YYYY-MM-dd HH:mm:ss"]
          }
        }

}

output
{
        #stdout{}
 elasticsearch
 {
        hosts => ["IP:PORT"]
        index => "ad-monitor-%{+YYYY.MM.dd}"
        user => "name"
        password => "password"
 }
}

Nxlog 和 Logstash 的加密证书配置命令

ca 私钥生成

openssl genrsa -out ca.key 2048

签发个人 CA

openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.pem

创建 logstash 的私钥

openssl genrsa -out logstash.key 2048

创建 logstash 的证书申请

openssl req -new -key logstash.key -out logstash.csr

使用 ca 证书去前方刚刚创建的logstash 证书申请并生成证书,过期时间为10年(不安全,但是方便)

openssl x509 -req -in logstash.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out logstash.crt -days 3650 -sha256

Kibana 展示结果

参考

基础搭建指南和规则文件的命令行导入:

https://blogs.technet.microsoft.com/jepayne/2015/11/23/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem/

介绍在日志收集端常见的规则导入脚本:

https://hackernoon.com/the-windows-event-forwarding-survival-guide-2010db7a68c4

日志转发收集内容基线

https://github.com/nsacyber/Event-Forwarding-Guidance

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

原文阅读

委内瑞拉大规模停电事件的初步分析与思考启示
antiylab 2019-3-19 5:30 转存

本文由安天研究院与广东省电力系统网络安全企业重点实验室联合分析发布。

说明

2019年3月7日,委内瑞拉发生大规模停电事件。安天科技集团组织研究院、安天CERT等内部力量进行跟踪研判,并于3月9日、3月10日,向国家相关主管、职能部门报送了两期研判简报;广东省电力系统网络安全企业重点实验室积极跟进分析研判,于第一时间向主管部门报送了《委内瑞拉停电事件分析》,并于3月12日通过“南方电网技术情报中心”公众号发布《“3·7”委内瑞拉大停电事件快报》。为进一步加强分析研判力量,双方决定成立联合分析研判组,继续推动该事件的持续跟进分析。基于双方已调研了解的情况和初步判断整合形成此份初步分析。

一、概述

(一)事件发生及进展

2019年3月7日傍晚(当地时间)开始,委内瑞拉国内包括首都加拉加斯在内的大部分地区停电超过24小时[1],在委内瑞拉23个州中,一度有20个州全面停电,停电导致加拉加斯地铁无法运行,造成大规模交通拥堵,学校、医院、工厂、机场等都受到严重影响,手机和网络也无法正常使用。8日凌晨,加拉加斯部分地区开始恢复供电,随后其他地区电力供应也逐步恢复,但是9日中午、10日的再次停电,给人们带来巨大恐慌。长时间大范围的电力故障给委内瑞拉造成严重损失,包括连续多日停工停学,部分网站无法访问,甚至部分地区出现严重的哄抢商场超市情况[2]。此次停电是委内瑞拉自2012年以来时间最长、影响地区最广的停电。

据媒体报道,初次停电是因为南部玻利瓦尔州的一座主要水电站发生故障,这个水电站属于古里(Embalse de Guri)水电站[3]。古里水电站位于奥里诺科河卡罗尼河口上游约100公里的Necuima峡谷处,一期建设于1963年,二期建设于1976年。水电站大坝高约162米,长度为7426米,总蓄水容量达1350亿立方米。水电站共计装设21台水轮机组共计10235MW,分别为:10×730MW,4×180MW,3×400MW,3×225MW,年发电量约为47,000GWh,约占委内瑞拉用电量的近四成。古里水电站外观及地理位置如图1所示。

20190316t1.png

                                                                                                           图 1古里水电站外观及地理位置

(二)委内瑞拉政府反应

事件发生后,委内瑞拉政府立刻组织人力调拨资源全力恢复,与此同时,总统马杜罗指出,大规模停电 “是美国方面的攻击行为造成的”。3月11日晚,马杜罗表示,对该国电力系统发起的攻击分为三个阶段,包括网络攻击、电磁攻击、燃烧爆炸。3月12日,马杜罗在一次电视直播的活动中再次透露[4],攻击是在五角大楼的命令下由美军南方司令部直接执行的。同时,马杜罗请求俄罗斯、中国、伊朗和古巴协助调查。   

较早前,委内瑞拉新闻通讯部长罗德里格斯曾表示,马杜罗政府计划将证据提交给联合国人权事务高级专员。委国防部长称,军方已在该国的电力线上引入了空中监视系统。委军方还计划进行旨在保护电力系统的军事演习[5]。

二、委内瑞拉电力系统相关情况

(一)委内瑞拉电力系统现状

委内瑞拉全国发电量约为117,000GWh,其中水电占64%,天然气发电占19%,石油发电占17%[6]。水力发电集中在瓜亚纳地区的卡罗尼河上,位于该国东部,共有4座水电站,其余分别是古里(Embalse de Guri)水电站、卡鲁阿奇(Caruachi)水电站、马卡瓜(Macagua)水电站、卡罗尼(Caroní)水电站。其中,最大的古里水电站位列世界第四大水电站[7]。因水力发电厂所发出的电力电压较低,要输送给距离较远的用户,就必须将电压经过变压器增高,再由空架输电线路输送到用户集中区的变电所,最后降低为适合家庭用户、工厂用电设备的电压,并由配电线输送到各个工厂及家庭。EDELCA公司是委内瑞拉国内最大的一家电力公司,公司目前拥有两个已投产水电厂,即古里电厂和马卡瓜电厂,EDELCA公司两厂各机组电力外送示意图如图3所示。

20190316t2.png

                                                                                                         图 2古里水电站安装容量排名

20190316t3.png

图 3 EDELCA公司两厂和各机组外送示意图[8]

委内瑞拉自主工业体系相对薄弱,在发电机组、高压输变电等设备上基本依赖进口,在较长一段历史时期,其供应商和承包商均为欧美电器巨头。如委内瑞拉中央电厂共有6个机组,1、2号机组建成于上世纪70年代,均为40万千瓦,是引进意大利与德国的设备;3、4、5号机组建于上世纪80年代初,是德国与日本的设备,彼时单体40万千瓦的装机容量均属世界领先技术。但随着设备的老化,目前这5个发电机组均已退役。近几年,中国公司开始参与到委内瑞拉重要电力基础设施的建设工作中,包括发电厂的升级改造、新建大型水利和火力发电厂,承担输变电工程建设等。委内瑞拉中央电厂6号机组发电项目,由中国机械设备工程股份有限公司(CMEC)于2016年完成,装机容量60万千瓦,能为委内瑞拉全国电网提供约3%的发电量[9]。

由于主力发电能力分布在东部地区,委内瑞拉主网电力流呈现“东电西送”格局。从图4委内瑞拉主网架结构可以看出,委内瑞拉输电网由765kV、400kV、230kV三个电压等级构成,其中古里水电站输送给负荷中心的电力是通过765kV和400kV输送的。

20190316t4.png

图 4委内瑞拉电力系统主网架结构

(二)委内瑞拉的电力安全运维能力

关于委内瑞拉在电力系统安全运维能力上缺少足够的资料分析。从目前了解的有限信息来看,其运维能力和人员水平和我国相比,相对偏弱。但从少量公开资料来看,委内瑞拉电力相关产品选型和工程实施的标准起点,基本向欧美标准靠拢,其起点并不低,部分要求甚至高于我国。表1是委内瑞拉变电站系统相关建设要求与我国的对比。不过需要指出的是,绝大多数国家电力安全运维的措施,都是从应对事故的角度所建立,而这些措施对于应对物理攻击和破坏是远远不够的。

表 1委内瑞拉变电站系统相关建设要求及与中国的对比

    中国 委内瑞拉
控制 系统 测控装置 每台断路器配备一套测控装置 每台断路器配备一用一备两套测控装置,可靠性增加,但成本翻倍
断路器重合闸配置 配置在保护装置中 配置在I/O测控单元中
保护 装置 母线差动保护 集中式配置 分布式配置(主单元+子单元),成本较高
变压器保护 双套保护(为2套完整独立的主后备一体化保护装置,测量电流回路一般从断路器CT引接,无独立的方向过流保护装置做后备) 双套保护(需要按3个保护装置配置,置一套采用套管 CT做小差动,一套采用串内断路器的CT做大差动,并另配置一个方向过流保护装置做后备保护),成本较高
230kV、138kV线路保护 专用芯或通道复用接口装置 光纤电流差动保护和一套光纤纵联距离保护。光纤差动保护通信接口为专用芯,而光纤纵联距离保护通信节点为干节点,与对侧变电站的通信必须通过专用的通信转换装置完成
24kV开关柜弧光保护 默认不配置弧光保护(因该保护机制易误动) 必须配置弧光保护
安稳装置 并非标配,默认配置单相电压互感器即可 三相母线均配置电压互感器
故障录波系统 用变电站内的统一对时 求每台故障录波器配置独立的GPS天线和对时系统
系统 通信 变电站通信 在变电站主控室配置一套光传输设备,各就地继电器室是不配置光传输设备的,保护室的信息均由控制、保护设备汇总后在主控制室内与光传输设备进行接口,从而上传调度 主控室配置一套光传输设备之外,在每个就地继电器室里也均配置了一套光传输设备,并要求要求在变电站内形成一个简单的通信网络

注:表格内容系分析人员从公开文献《委内瑞拉变电站控制和保护设计研究》[10]一文中提炼整理。

三、各方对停电事件的原因表态和相关信息

(一)委内瑞拉政府方面宣布遭遇三个阶段攻击

3月11日晚,马杜罗表示电力系统遭遇了三阶段攻击。第一阶段是发动网络攻击,主要针对西蒙·玻利瓦尔水电站,即国家电力公司(CORPOELEC)位于玻利瓦尔州(南部)古里水电站的计算机系统中枢,以及连接到加拉加斯(首都)控制中枢发动网络攻击。第二阶段是发动电磁攻击,“通过移动设备中断和逆转恢复过程”。第三阶段是“通过燃烧和爆炸”对Alto Prado变电站(米兰达州)进行破坏,进一步瘫痪了加拉加斯的所有电力。随后,马杜罗3月12日在一次电视直播的活动中再次透露,攻击来自休斯顿和芝加哥,是在五角大楼的命令下由美军南方司令部直接执行。马杜罗没有公布上述指控的证据,称已下令设立了一个总统特别调查委员会对网络攻击事件展开调查,并请求俄罗斯、中国、伊朗和古巴协助调查。较早前委内瑞拉新闻通讯部长罗德里格斯曾表示,马杜罗政府计划将“美国参与停电”的证据提交给12日到访的联合国人权事务高级专员米歇尔·巴切莱特。

同时在3月11日,委内瑞拉方面宣布,已经逮捕两名纵火破坏电力系统嫌疑人。

20190316t5.png

图 5委内瑞拉南方电视台报道马杜罗就电力系统遭受三阶段攻击发表讲话所配示意图

(二)反对派声称火灾导致停电

委内瑞拉反对派领导人胡安·瓜伊多表示,根据委内瑞拉Corpoelec输电公司内部人员透露,当地时间7日16:42分左右,古里水电站送出线路路径发生火灾,导致联络Guri~Malena~SanGerónimoB变电站三回765kV线路跳闸。值得注意的是,委内瑞拉765kV的线路是国家输电主干线,负责该国85%的电力传输。由于三回765kV跳闸,SanGerónimoB国家中心失去电源,该站全站失电导致送入国家负荷中心的主干线也全部失电。该中心站系统接线图如图6所示[11]。

20190316t6.png

图 6 SanGerónimoB系统接线示意图

(三)技术人员分析恢复系统困难重重

本次大停电事故发展演化过程暂不明确。但是,据后续媒体报道,由于送出线路跳闸,送端古里水电站15、17、19三台机组被切除,水电站12号机组因系统频率超过62Hz被切除。随后,周边卡鲁阿奇水电站1号、4号机组,以及马卡瓜水电站全部机组也受到影响,陆续被切机。

委内瑞拉工程师MiguelLara解释长时间停电原因时称,恢复古里电力系统的操作很复杂,为了投入使用Guri~ Malena~SanGerónimo三回765kV线路,要求三座变电站具备合格的操作人员,但是该国电力系统发展滞后十年,并未有过预案处理经验,缺乏合格的操作人员,使得很难在48小时内解决复电问题。据报道,该国试图通过400kV网架重新构建电力系统,但是也失败了,导致3月9日第二次全国范围内大停电。该国输电专家米格尔拉拉说:大停电最大的问题是电力传输,即使他们在古里水电站发出电力,如果没有765kV系统,他们也无法把它送出,该国负荷中心85%的电力依靠这条输电线路。

四、综合研判

联合研判组在事件跟进分析中,整合和事件相关的所有信息,并尝试与多方取得联系,但均未获得进一步更直接的信息。

委内瑞拉停电事件很容易被与“震网事件”[12]和“乌克兰电网遭遇攻击停电事件”[13]对比看待,而后两者都是已经被多方详细分析,并充分论证为网空攻击行动。安天此前对这两起事件都发布了详细的分析报告,但这些分析工作都是在能够部分获取到攻击载荷的情况下,基于深入的样本分析支撑攻击过程复盘的结果。“震网”攻击成功后,可能出于掩盖攻击意图或其他考虑,攻击方一度激活USB传播开关,使病毒样本出现一条从中东到东南亚的传播感染带,但也使攻击载荷相对容易被获取到;乌克兰停电事件则是基于长期建立的僵尸网络进行活动,加之使用了易于留下痕迹的邮件投放等手段,其在最终目标机的自毁也并不彻底,使之较为容易找到可供分析的对象与资源。

在是否存在高级网空攻击活动的分析中,依赖于采集面、环境勘察与提取、人员访谈、及第三方威胁情报导入作为输入,以驱动分析团队依托分析工具、威胁大数据平台进行基础分析,形成研判。对高度定向化的攻击,尤其依赖于被攻击目标防御体系的纵深性和能力留下有价值的痕迹,以及深入的环境提取。

而本事件基于目前事件特殊地缘特点限制,难以进行深入场景的提取分析,也无间接的样本、日志、系统环境镜像和其他数据资源情报,因此该事件尚不具备是否存在网空攻击层面的基础技术研判条件,目前仍只能从能力、动机等方面,基于相关消息进行研判。

联合研判组分析认为:

(一)基于委内瑞拉不稳定的社会局面,人为攻击破坏的可能性极大[M1] 

鉴于委内瑞拉当前之局面,及相关国际形势,委内瑞拉基础设施崩溃及连带影响有比较明显的获益方,客观存在实施攻击获利的动机,因此有较大的人为破坏的可能性。但从目前线索来看,除纵火行为有更多相关信息外。关于网络攻击和电磁攻击尚无更多信息支撑。

在针对关键基础设施的攻击中,电力系统极易被当作首选目标,除了电力对现代社会运行起到关键支撑作用,被攻击可能引起连锁反映外。电力系统高度复杂,暴露面多也是一个原因。电站、输变电设备、线路层面均可能遭到物理、电磁和网空层面的攻击。而电力系统的空间特点则决定了,只有电厂和关键变电站能获得相对封闭的物理空间保障。大量无人变电站和线路均处在自然开放空间之中。而从电力系统的机理来看,局部的攻击很容易造成大面积影响。从委内瑞拉相关事件中,可以判断出发生了多次电网解列,电网解列的可能原因是关键节点注入功率不足,导致电网潮流异常或者过载,引发保护,局部停电到电网解列,最终就会引发大面积停电事件。

(二)美方有主导或参与的动机与可能性,但尚无技术层面的实证

威胁是能力和意图的乘积。从能力上看,美方具有全球最强的体系化网络攻击能力。在复杂的组织机构、庞大的人员规模和充沛的预算保障下,美方建设了一系列大型的信号情报获取和作业的工程系统、研发了制式化装备体系,建立支撑网空情报活动和攻击活动的框架,将情报获取、进攻作业、积极防御等网空能力整合成整体国家能力。可参见安天此前系列的相关分析【14-18】[G2] 。

20190316t7.png

图7 美方NSA/CSS网空威胁框架与其部分工程和装备体系的映射

从意图上看,美国一直背后支持委反对派反对马杜罗政府,此前还曾威胁直接军事干预。美国此前有利用“震网”攻击主权国家关键基础设施的先例。美方在攻击电力系统方面有长期的准备,早在2007年,美国爱达荷国家实验室就是实施了一项非机密的政府内部实验——即“极光漏洞”试验,针对一台225万瓦功率的柴油发电机,通过计算机程序以异常的方式反复高速关闭和重启此发电机,在短短的三分钟时间内,发电机被彻底摧毁,部分组件因为压力的反复变动导致炸裂,部分碎片被崩裂到80英尺之外。上述资料于2014年7月3日,被美国国土安全部根据信息公开法公布。根据《Division Cyber Operations》[19]等文献,美方已经将政治、军事、经济、社会、基础设施等宽频目标,纳入到目标打击规划工具的目标列表中,其中基础设施目标中就包括电力系统。美军目标打击规划工具(PMESII Crosswalk)考虑事项和可攻击侧面如图8所示。

1.png

图 8 美方PMESII的可攻击面清单

从行为模式的角度来看,瓜伊多所声称如他上台执政就能马上恢复电力,而美方恰恰将“重建”作为网络武器参与的作战阶段之一,美国陆军参谋长前高级顾问Maren Leed曾在《Offensive Cyber Capabilities at the Operation Level》[20]一文中指出,“网络武器具有无与伦比的多功能性,它们可用于从参与到高端作战的所有军事行动。因为它们的影响是可逆的,所以非常适合于作战的所有阶段,包括环境塑造、高烈度对抗 以及目标重建”。

(三)委内瑞拉部分电力设施陈旧,在社会动荡背景下故障频发,亦不能排除自身发生故障所致

乔治华盛顿大学网络与国土安全中心高级研究员Kalev Leetaru认为[21],“由于电网经年累月管理不善,停电在委内瑞拉已是司空见惯,不需要美国国家安全局的帮助”,“该国电网自己就可以引起下一次停电事件。大多数国家,包括美国,都对其老化和日益超载的公共基础设施感到担忧。因设备故障或输电线路过载而停工的发电厂更可能被归咎于投资不足,而非外国网络攻击。引起大规模山火的电力线故障很可能是预防维护工作不力导致,而非蓄意的外国破坏。”

2013年1月至6月期间,委内瑞拉国家电力系统发生了10,647次失败事故;2013年9月3日,19个州和加拉加斯经历了由于输电线路故障导致的4小时停电,该国70%的面积停电;2018年8月31日,苏利亚州首府马拉开波的一个变电站发生爆炸,导致城市大片区域停电;2018年10月16日,卡拉沃沃州La Arenosa发电站发生爆炸事故,导致本国西南部电力供应中断,12个州出现电力短缺,至少1000万名用户可能受到停电的影响。当然也不能排除这些事件的背后同样可能存在人为因素的影响。

20190316t9.png

图 9 委内瑞拉电力系统历史事故图

(四)网络空间安全、关键基础设施安全需要相应的基础支撑条件

如果将“震网事件”和“乌克兰电网遭遇攻击停电事件”与委内瑞拉停电事件对比,前两起事件都是在被攻击设施拥有国社会基本稳定、主权与安全有基本自我保障的能力下所发生的,在基础设施的物理安全有一定的保障基础上,攻击方往往会优先选择采用网空攻击这种相对更隐蔽、具有穿透性手段进行攻击。以在达成攻击效果的同时,限定影响后果,同时其成本也比物理域军事打击更低廉。[M3] 而物理手段和网络手段叠加往往能达成更大的攻击效果。在委内瑞拉社会动荡的背景下,内部破坏、里应外合等各种可能性都急剧增加,物理、电磁、网空多个领域风险相互叠加,而被削弱的社会应急能力、和基础设施运维水平,又增加了恢复难度和成本。 国家的主权与安全是关键基础设施安全的基本屏障,社会治理能力是关键基础设施安全的前提基础。当前委内瑞拉政府虽然能维持政府的基本运行,但在巨大的外部颠覆、干预压力以及内部反对派的干扰下,主权与安全遭到严峻挑战,治理能力就已经高度削弱。在这种情况下,如果遭遇入侵攻击,很大可能是带有网络空间和实体空间的复合性因素,而非单纯的网络攻击问题。而多起事件间,既有可能是强关联组合打击,也可能是弱关联的多源并发。

此次委内瑞拉政府多次发声中,包括 “电力系统已成为美国最新一轮网络攻击”、“国内渗透者从内部攻击了电力公司”、“抓获纵火破坏电力系统嫌疑人”等,同时网络上也出现了西部变电站发生爆炸的相关信息,如果这些都属实,这就是一个里应外合、多域交织的结果,是国家政权受到挑战的情况下集中爆发出的基础设施安全问题。而也正是由于政权管控能力下降,导致攻击事件发生后,政府没有足够资源和能力有效应对,进而接连受到的攻击令损失进一步扩大化。

 五、几点启示

启示一

必须从总体国家安全观来统领关键基础设施安全防护工作。关键基础设施是各种威胁行为体所觊觎的目标,而其攻击往往是跨域组合的。因此不能简单的将基础设施防御视为技术对抗,而要视为综合对抗。

在常规防护中,要将物理安全、人员安全因素与技术安全因素都充分考虑在内,对可能发生的紧急情况,制定更为全面的预案。目前国内在网络空间安全领域,存在缺少总体国家安全视角,不以结果/后果角度分析威胁,而以攻击的“技术含量”高低看待威胁的倾向,认为“非技术层面的攻击,就不是事儿,不是‘高技术含量’的攻击,都不是大事儿”。但网络空间安全和关键基础设施安全都具有非对称性的特点,决定了攻击中是组合拳打击薄弱点的特点。并非只采用技术手段或高技术手段。威胁行为体在攻击中并不关心“技术含量”,而更多考虑目标价值、攻击成功率、攻击成本、攻击隐蔽性等“作战指标”。一些针对关键目标的简单技术或人为操作在与其相适应的时间点爆发,一样可以造成重大损害。

启示二

能力导向建设模式,提升关键信息基础设施安全防护能力。

当前,我国面临着复杂严峻的内外部形势,在众多的风险挑战中,“网络安全防控能力薄弱,难以有效应对国家级、有组织的高强度网络攻击”是一项突出的风险。防控能力建设及以国家大型工程为主干,也以各政企机构建设管理的每一个重要信息系统和信息基础设施的安全为基石。基石不稳,则大厦难安。重要信息系统和关键信息基础设施处于“低水平防护”,甚至“无效防护”的状态中,是国家安全与稳定的严重隐患,影响到国家的战略主动性。

目前政企网络安全防护中规划能力不够、预算保障不足、问责机制没有落地等问题十分明显,在安全规划建设工作中往往是在满足一般性合规要求的基础上,再简单堆砌部分产品应对各类单点威胁,未形成动态综合的网络安全防御体系,缺少实战化安全运行机制保障。面对既有安全环节单点失效、面临新的威胁类型,疲于应付,顾此失彼。对隐蔽性更强的高级网空威胁行为体的持续性威胁,缺少足够的发现和防御能力。在预算保障上,受经济下行压力影响,安全投入纷纷削减或延迟。

但越是在面临复杂严峻挑战下,越应优先建设安全支撑能力,建议主管部门通过系统规划指引、保障预算投入、加强问责落实,全面提升政府、央企网络安全防护水平。

政企机构、关键信息基础设施建设运维方,面对复杂的敌情,需要将“敌已在内,敌将在内”作为驱动防御的前提设定,并根据自身网络与信息系统的国家安全、社会安全和业务安全属性,客观判断必须能够有效对抗哪些层级的网络空间威胁行为体,并据此深入分析安全需求,建立安全规划,保障预算投入。

采用叠加演进能力导向的网络安全建设模式指引规划设计,科学合理地分阶段扎实开展网络安全建设实施工作,实现从基础结构安全、纵深防御、态势感知与积极防御到威胁情报的网络安[F4] 全能力【22】[G5] ,构建动态综合的网络安全防御体系

针对电力等基础设施和工业系统,在落实能力导向建设模式构建动态综合防御体系的工作中,必须以保障业务运行的连续性和可靠性要求为基本前提,这就对基础结构安全能力、纵深防御层面安全能力的规划、建设和安全运行提出了更高的要求,对于现网系统,针对各种等可能对业务连续性产生潜在影响的安全动作,需要极为慎重,综合采用合理规划、分区分域、收窄暴露面等方式,有效布防,并通过完备的应急响应预案制定、演训式威胁评估等相关措施,最大限度避免或减少对业务系统可能产生的影响,确保系统业务的弹性恢复能力。

参考资料

[1]     Telesur English:Venezuela Denounces US Participation in Electric Sabotage:https://www.telesurenglish.net/news/Venezuela-Denounces-US-Participation-in-Electric-Sabotage-20190308-0021.html 

[2]     Lapatilla.com:Fedecámaras Zulia ofrece balance desaqueos en la región por crisis eléctrica:https://www.lapatilla.com/2019/03/12/fedecamaras-zulia-ofrece-balance-de-saqueos-en-la-region-por-crisis-electrica/?tdsourcetag=s_pcqq_aiomsg 

[3] Telesur English:Venezuelan Gov’t Denounces Latest Attack on Electric System:https://www.telesurenglish.net/news/Venezuelan-Government-Denounce-New-Attack-On-Electric-System-20190307-0033.html 

[4] https://www.voacna-help-investigate-alleged-us-cyber-attack-20190313/4826828.htmlhinese.com/a/venezuela-asks-chi

[5] Twitter:https://twitter.com/teleSURtv/status/1105964204023050241

[6] IEA:https://www.iea.org/countries/Venezuela/

[7] 维基百科:https://en.wikipedia.org/wiki/List_of_largest_power_stations_in_the_world

[8] 委内瑞拉EDELCA 电力公司梯级与三峡-葛洲坝梯级AGC比较,李晖,《华中电力》,2003年第1期

[9] 国机集团:http://www.cmec.com/xwzx/mtbd/201809/t20180903_192153.html

[10] 委内瑞拉变电站控制和保护设计研究,赵焱、张庆伟,《国际工程与劳务》 2015年01期

[11]  北极星电力网:“3·7”委内瑞拉大停电事件快报:http://m.bjx.com.cn/mnews/20190312/968255.shtml

[12]  安天:对Stuxnet蠕虫攻击工业控制系统事件的综合分析报告:https://www.antiy.com/response/stuxnet/Report_on_the_Worm_Stuxnet_Attack.html

[13]  安天:乌克兰电力系统遭受攻击事件综合分析报告:https://www.antiy.com/response/A_Comprehensive_Analysis_Report_on_Ukraine_Power_Grid_Outage/A_Comprehensive_Analysis_Report_on_Ukraine_Power_Grid_Outage.html

[14] 安天:修改硬盘固件的木马 探索方程式(EQUATION)组织的攻击组件:https://www.antiy.com/response/EQUATION_ANTIY_REPORT.html

[15] 安天:方程式(EQUATION)部分组件中的加密技巧分析:https://www.antiy.com/response/Equation_part_of_the_component_analysis_of_cryptographic_techniques.html

[16]  安天:从“方程式”到“方程组”EQUATION攻击组织高级恶意代码的全平台能力解析:https://www.antiy.com/response/EQUATIONS/EQUATIONS.html

[17] 安天:方程式组织EQUATION DRUG平台解析—方程式组织系列分析报告之四:https://www.antiy.com/response/EQUATION_DRUG/EQUATION_DRUG.html

[18] 美国网络空间攻击与主动防御能力解析(连载),网信军民融合杂志,安天研究院

[19]《DivisionCyber Operations》:https://cyberdefensereview.army.mil/CDR-Content/Articles/Article-View/Article/1136080/division-cyber-operations/

[20]《Offensive Cyber Capabilities at theOperation Level》:https://csis-prod.s3.amazonaws.com/s3fs-public/legacy_files/files/publication/130916_Leed_OffensiveCyberCapabilities_Web.pdf

[21]Forbes:Could Venezuela’s Power Outage Really Be A Cyber Attack? https://www.forbes.com/sites/kalevleetaru/2019/03/09/could-venezuelas-power-outage-really-be-a-cyber-attack/

[22] 网络安全滑动标尺模型—从架构安全到超越威胁情报的叠加演进(安天译本)

委内瑞拉电力-能源危机与其国内局势历史时间记录表[M6]

(截至2019年3月12日)

注释:黑色字体为能源危机,蓝色字体为局势动向

l 2010年2月8日,委内瑞拉发生电力系统紧急事故。

l 2012年10月,查韦斯再次赢得连任。

l 2013年1月至6月期间,SEN(国家电力系统)发生了10,647次失败事故。

201335日,查韦斯逝世。

l 2013年4月,政府宣布能源紧急情况。

2013414日,马杜罗成为委内瑞拉总统。

l 2013年9月3日,根据官方报告,19个州和加拉加斯经历了由于输电线路故障导致的4小时停电。该国70%的面积停电。

l 2016年4月初,委内瑞拉政府“60天计划”,“60天计划”包括4月和5月的每个周五,委内瑞拉公共服务部门放假,学校停课,并且工作日也相应减少上班时间,目的是为了节约用电。

l 2016年5月1日,委内瑞拉政府实施公务员每周工作2天,休息5天的临时措施,还将时钟回拨半小时以充分利用日间时光,全国每天轮流断电4小时,委内瑞拉所使用的时间称为“委内瑞拉标准时”。委内瑞拉标准时为UTC-4:30,是唯一一个使用该时间的国家。

2017731日,美国财政部宣布对委内瑞拉总统马杜罗实施制裁。根据制裁措施,马杜罗在美国境内的资产将被冻结,同时美国人将被禁止与其进行交易往来。

2018520日,委内瑞拉国家选举委员会宣布,现任总统马杜罗赢得本次总统选举。

l 2018年8月31日,苏利亚州首府马拉开波的一个变电站发生爆炸,导致城市大片区域停电。

l 2018年10月16日,卡拉沃沃州LaArenosa发电站发生爆炸事故,导致本国西南部电力供应中断。”12个州出现电力短缺。据消息,至少1000万名用户可能受到停电的影响。

2019123日,委内瑞拉议会主席、反对党人士瓜伊多在一场反对党支持者集会活动中自封为“临时总统”,要求重新举行总统大选,完成政府权力过渡。

2019123日,委内瑞拉加拉加斯,委内瑞拉总统马杜罗对千名支持者说:“我已决定,将切断与美帝国主义政府的外交与政治关系。”

2019128日,美国宣布对委内瑞拉国家石油公司——PDVSA实施制裁,该公司无法出售石油至美国。

2019130日,委内瑞拉最高法院29日宣布,决定对委议会主席、反对党人士瓜伊多采取限制措施。

l 2019年3月7日下午5时左右,包括首都加拉加斯在内的委内瑞拉全国发生大规模停电。多数地区的供水和通信网络受到影响。

2019312日,美国务卿蓬佩奥在社交网站“推特”上宣布,将从美国驻委内瑞拉使馆中撤出所有剩余美国外交人员。

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

原文阅读

修改Empire绕过Windows Defender
secist 2019-3-19 5:0 转存

防病毒规避技术一直以来是我最感兴趣的研究方向之一。多年前,当我开始研究计算机科学时,我向我的顾问提出了一个主题,即通过映射二进制文件中的执行流,来改进防病毒引擎以检测多态病毒。但随着研究的深入,这个设想最终还是被否决了,所以我选择了另一个研究课题。

如果你的工作是渗透测试或在红队中,那么防病毒绕过技术将是你必备的一项技能。但不得不说这也是一个令人沮丧的领域 – 虽说“基于签名的”防病毒软件在阻止威胁方面并没有太大的作用,但有时却会给我们带来极大的麻烦。

我们知道想要逃避防病毒软件最好的办法就是“编写自己的工具”。例如编写一个自己的简单反向shell,或是如果你有足够的资金预算和时间,那么也可以尝试从头开发一个完善的C2架构。然而,大多数人还是依赖于安全社区中其他人开发的开源(和商业)工具。

说到这,我不得不提Empire。Empire是一款后渗透利用代理工具,其中包含了各种的攻击性工具。这是一款非常强大的工具,如果在执行的过程中没有被防病毒程序标记,那么它完全可以作为攻击性操作的一部分使用。有一段时间,Empire对于逃避像Windows Defender这样的程序非常有用。但现在已经不行了,如果你创建一个通用的http listener agent payload并在内存中执行,甚至还没有触及磁盘,你可能就会看到如下所示内容。

修改Empire绕过Windows Defender

可以看到,Windows Defender检测并阻止了我们的行为。

但别忘了Empire是一款免费且开源的工具,我们可以通过修改一些关键区域来尝试绕过客户端防病毒软件。

在我们的测试开始之前,我们先来关闭Windows Defender中的“Cloud-delivered Protection”,尤其是“自动样本提交(Automatic sample submission)”。我们不希望我们的任何测试接入互联网,并进入Windows Defender的分布式签名当中。另外,请保持“实时保护(Real-time protection)”,以便我们测试执行的情况。

windows-defender-settings.png

记住!无论你做什么,都不要将病毒上传到VIRUS TOTAL!否则你的一切努力都将白费!正如下面你将学到的,即使初始payload通过防病毒检查,Windows Defender也可以检测到Empire。

现在我们的测试实验环境已准备就绪,是时候开始使用Empire了。

在前几次绕过Windows Defender的尝试中,我设置了Empire launcher payload内的misc选项,但最终都以失败告终。

3empire-http-listener-defaults.png

4empire-http-stager-defaults.png

接着,我尝试通过混淆的办法来进行绕过。我尝试使用powershell混淆工具来运行有效载荷。通过Unicorn运行它…?失败。通过Veil Framework运行它…?失败。通过Empire自己的原生Invoke-Obfuscation运行它…?还是失败。

但我注意到一点,通过使用混淆工具我能够将payload写入磁盘,基本上是绕过了防病毒签名,但在执行时会被检测并阻止。

剖析 Empire

Empire生成的初始payload即所谓的“stager”,确切地说应该是stage0 payload。stager是一些代码,用于远程下载和执行另一个stager或实际payload。在我们的示例中,我们将使用multi/launcher powershell stager来获取http listener。

测试stage0 payload实际上非常简单。生成payload,将其写入文件,然后传输到Windows机器。如果它在命中磁盘时触发防病毒警告,则表示你还有许多其它工作需要做。如果它成功传送并正常执行,则表示你获取到了一个可用的stager。

一个非常重要的说明!在我的测试期间我遇到了一个问题,就是在反复进行payload测试后,Windows Defender很可能会将所有的powershell文件标记为病毒,甚至是空文件!如果发生这种情况,请重启VM或计算机。我的看法是,Windows Defender可能知道我正在传输文件的主机是恶意的,因此无论文件是什么,PowerShell都会被禁止执行。

你可能会感到震惊,生成绕过Windows Defender的multi/launcher stager,只需使用Empire中显示的选项即可实现。但我不会告诉你我所使用的确切选项,因为我知道有人会立即使用它们,并忽略我的警告将它们上传到Virus Total。但我会向你们展示我建议修改的选项。

建议修改的 Empire http listener 选项

选项 描述 默认
默认配置文件 Empire将在不同时间调用的三个URL以及User-Agent字符串。 /admin/get.php,/news.php,/login/process.php|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
服务器版本 Web服务器版本标识符 Microsoft-IIS/7.5
主机 你的主机(或IP)和端口号。  
端口 应与指定的主机端口相同  
用户代理 Empire为模拟真实的Web浏览器流量而发送的用户代理。 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
StagerURI 向Stager提供的URI。必须包括/download才能工作,而不需要进行额外的修改。  
证书路径 设置Empire时默认的自签名证书位于./Empire/Data。根据环境的复杂程度,自签名证书可能不起作用。Windows Defender不介意自签名证书。  
默认Jitter 向Empire服务器发送信标呼叫时的随机延迟。 0.0
Launcher 用于执行stager的命令。 powershell -noP -sta -w 1 -enc

建议修改的 Empire multi/launcher 选项

选项 描述 默认
Listener 此项为必设项  
UserAgent 用户代理字符串  
SafeChecks 尝试检测launcher是否在沙箱中运行。 True
混淆 混淆自动生成的launcher代码。 False
混淆命令 使用的混淆命令。 Token\All\1,Launcher\STDIN++\12467

这里给大家一个提示。将SafeChecks设置为false。SafeChecks试图确定stager是否在防病毒沙箱中运行。此外,这也会减少大量生成的代码,但由于我们被防病毒软件检测到了,因此显然无法正常工作。

有了这样一个被我们“武器化”的payload,是不是意味着我们就一定能够运行Empire?如下所示payload将执行,并且你会看到一个初始连接Sending stage 1!接着便出现了问题。

5empire-http-stage1-fails.png

在测试期间,我决定关闭防病毒保护,在Windows主机上启动Empire,然后重启防病毒软件。令我兴奋的是,我的Empire beacon并没有死!只要我们能让Empire启动就行。但为什么无法启动呢?

深入挖掘Empire代码库会生成stage1代码。这段代码建立了加密安全环境以躲避检测,但它本身并没有以任何方式进行编码。经过一些测试和错误之后,编辑了文件和某些部分,我确定应该问题应该出在invokeEmpire函数名。正如Black Hills Information Security文章中所建议的那样,将函数名更改为invoke randomstringhere是阻止检测的必要手段。尽管我们要做的只是修改invokeEmpire函数名,但如果你能进一步的更改stage1代码,那无疑将是巨大的加分项。

Edit: ./Empire/data/agent/stagers/http.ps1:

Invoke-Empire -Servers @(($s -split "/")[0..2] -join "/") -StagingKey $SK -SessionKey $key -SessionID $ID -WorkingHours "WORKING_HOURS_REPLACE" -KillDate "REPLACE_KILLDATE" -ProxySettings $Script:Proxy;

Edit: ./Empire/data/agent/agent.ps1

function Invoke-Empire {

让我们再次尝试运行我们的Empire stager。

6empire-http-av-bypass.png

可以看到我们成功绕过了Windows Defender!

由于是在完全修补的Win10主机上运行测试,因此提权的方法并不多。所以,让我们尝试一下powershell/privesc/ask模块,它会弹出一个对话框,询问用户是否要以管理员身份运行powershell。漏洞利用成功弹出了对话框,这是一个好兆头!我点击是!然而什么也没发生。

我承认这让我感到有些困惑。如果我的stagers在初始利用时工作,那么为什么不能提权呢?经过一些调试之后,我能够捕获使用privesc/ask模块发送的stager。虽然它包含了我在multi/launcher配置中设置的一些修改,但有一个明显的区别。它还包含了我们之前设置为False的SafeChecks代码!

7empire-launcher-safe-checks.png

我不确定这里包含的SafeChecks,是否是由于Empire中存在的bug导致的。但是,SafeChecks代码当前存在问题,似乎已被该Empire bug所证实。只需将选项设置始终保持为 False,就可以解决我们的问题。

Edit: ./Empire/lib/listeners/http.py:

def generate_launcher(self, encode=True, obfuscate=False, obfuscationCommand="", userAgent='default', proxy='default', proxyCreds='default', stagerRetries='0', language=None, safeChecks='', listenerName=None):
        """
        Generate a basic launcher for the specified listener.
        """

        # Add this line to override SafeChecks
        safeChecks='False'

运行`python -m compileall`并重启Empire。然后启动powershell/privesc/ask。

8empire-http-privesc-av-bypass.png

*参考来源:mike-gualtieri,FB小编secist编译,转载请注明来自FreeBuf.COM

原文阅读

.NET高级代码审计(第四课)JavaScriptSerializer反序列化漏洞
360云影实验室 2019-3-19 3:30 转存

一、前言

在.NET处理 Ajax应用的时候,通常序列化功能由JavaScriptSerializer类提供,它是.NET2.0之后内部实现的序列化功能的类,位于命名空间System.Web.Script.Serialization、通过System.Web.Extensions引用,让开发者轻松实现.Net中所有类型和Json数据之间的转换,但在某些场景下开发者使用Deserialize 或DeserializeObject方法处理不安全的Json数据时会造成反序列化攻击从而实现远程RCE漏洞。本文笔者从原理和代码审计的视角做了相关介绍和复现。

前文回顾:

.NET高级代码审计之XmlSerializer反序列化漏洞

.NET高级代码审计(第二课) Json.Net反序列化漏洞

.NET高级代码审计(第三课)Fastjson反序列化漏洞

微信图片_20190320102612.png

二、JavaScriptSerializer序列化

下面先来看这个系列课程中经典的一段代码:

JavaScriptSerializer反序列化漏洞

TestClass类定义了三个成员,并实现了一个静态方法ClassMethod启动进程。序列化通过创建对象实例分别给成员赋值

JavaScriptSerializer反序列化漏洞

使用JavaScriptSerializer类中的Serialize方法非常方便的实现.NET对象与Json数据之间的转化,笔者定义TestClass对象,常规下使用Serialize得到序列化后的Json

JavaScriptSerializer反序列化漏洞

从之前介绍过其它组件反序列化漏洞原理得知需要__type这个Key的值,要得到这个Value就必须得到程序集全标识(包括程序集名称、版本、语言文化和公钥),那么在JavaScriptSerializer中可以通过实例化SimpleTypeResolver类,作用是为托管类型提供类型解析器,可在序列化字符串中自定义类型的元数据程序集限定名称。笔者将代码改写添加类型解析器 

JavaScriptSerializer反序列化漏洞

这次序列化输出程序集的完整标识,如下

JavaScriptSerializer反序列化漏洞

三、JavaScriptSerializer反序列化

3.1 反序列化用法

反序列化过程就是将Json数据转换为对象,在JavaScriptSerializer类中创建对象然后调用DeserializeObject或Deserialize方法实现的。

JavaScriptSerializer反序列化漏洞

JavaScriptSerializer反序列化漏洞在BasicDeserialize内部又调用了DeserializeInternal方法,当需要转换为对象的时候会判断字典集合中是否包含了ServerTypeFieldName常量的Key,

JavaScriptSerializer反序列化漏洞ServerTypeFieldName常量在JavaScriptSerializer类中定义的值为“__type”,

JavaScriptSerializer反序列化漏洞

剥茧抽丝,忽略掉非核心方法块ConvertObjectToType、ConvertObjectToTypeMain 、ConvertObjectToTypeInternal,最后定位到ConvertDictionaryToObject方法内

JavaScriptSerializer反序列化漏洞

这段代码首先判断ServerTypeFieldName存在值的话就输出赋值给对象s,第二步将对象s强制转换为字符串变量serverTypeName,第三部获取解析器中的实际类型,并且通过System.Activator的CreateInstance构造类型的实例

JavaScriptSerializer反序列化漏洞

Activator类提供了静态CreateInstance方法的几个重载版本,调用方法的时候既可以传递一个Type对象引用,也可以传递标识了类型的String,方法返回对新对象的引用。下图Demo展示了序列化和反序列化前后的效果:

JavaScriptSerializer反序列化漏洞

反序列化后得到对象的属性,打印输出当前的成员Name的值

3.2 打造Poc

默认情况下JavaScriptSerializer不会使用类型解析器,所以它是一个安全的序列化处理类,漏洞的触发点也是在于初始化JavaScriptSerializer类的实例的时候是否创建了SimpleTypeResolver类,如果创建了,并且反序列化的Json数据在可控的情况下就可以触发反序列化漏洞,借图来说明调用链过程

JavaScriptSerializer反序列化漏洞

笔者还是选择ObjectDataProvider类方便调用任意被引用类中的方法,具体有关此类的用法可以看一下《.NET高级代码审计(第一课) XmlSerializer反序列化漏洞》,因为Process.Start方法启动一个线程需要配置ProcessStartInfo类相关的属性,例如指定文件名、指定启动参数,所以首先得考虑序列化ProcessStartInfo,这块可参考《.NET高级代码审计(第三课) Fastjson反序列化漏洞》 ,之后对生成的数据做减法,去掉无关的System.RuntimeType、System.IntPtr数据,最终得到反序列化Poc

JavaScriptSerializer反序列化漏洞

笔者编写了触发代码,用Deserialize<Object>反序列化Json成功弹出计算器

JavaScriptSerializer反序列化漏洞

JavaScriptSerializer反序列化漏洞

四、代码审计视角

4.1 Deserialize

从代码审计的角度其实很容易找到漏洞的污染点,通过前面几个小节的知识能发现需要满足一个关键条件new SimpleTypeResolver() ,再传入Json数据,就可被反序列化,例如下面的JsonHelper类

JavaScriptSerializer反序列化漏洞攻击者只需要控制传入字符串参数input便可轻松实现反序列化漏洞攻击。Github上也存在大量的不安全案例代码
JavaScriptSerializer反序列化漏洞

4.2 DeserializeObject

JavaScriptSerializer还有一个反序列化方法DeserializeObject,这个方法同样可以触发漏洞,具体污染代码如下

JavaScriptSerializer反序列化漏洞

五、案例复盘

最后再通过下面案例来复盘整个过程,全程展示在VS里调试里通过反序列化漏洞弹出计算器。

1.    输入http://localhost:5651/Default Post加载value值

JavaScriptSerializer反序列化漏洞

2.   通过DeserializeObject 反序列化 ,并弹出计算器

JavaScriptSerializer反序列化漏洞

最后附个动态图:

JavaScriptSerializer反序列化漏洞

六、总结

JavaScriptSerializer凭借微软自身提供的优势,在实际开发中使用率还是比较高的,只要没有使用类型解析器或者将类型解析器配置为白名单中的有效类型就可以防止反序列化攻击(默认就是安全的序列化器),对于攻击者来说实际场景下估计利用概率不算高,毕竟很多开发者不会使用SimpleTypeResolver类去处理数据。最后.NET反序列化系列课程笔者会同步到https://github.com/Ivan1ee/https://ivan1ee.gitbook.io/ ,后续笔者将陆续推出高质量的.NET反序列化漏洞文章,欢迎大伙持续关注,交流,更多的.NET安全和技巧可关注实验室公众号。

*本文作者:Ivan1ee@360云影实验室,转载请注明来自FreeBuf.COM

原文阅读

Kthrotlds挖矿病毒详细分析报告
影武者实验室 2019-3-19 1:0 转存

2019年3月1日,默安科技应急响应中心接到某合作伙伴的求助电话,有主机被病毒感染,经默安科技安全研究员郑斯碟研究分析发现,该病毒为之前的watchdogs的变种,通过Redis未授权访问漏洞及ssh弱口令进行突破植入,随后释放挖矿木马进行挖矿操作,并对内外网主机进行redis漏洞攻击及ssh暴力破解攻击。

0×1 病毒特征

要判断是否感染此病毒,可从以下几个方面入手:

1、查看root/.ssh/中的密钥信息是否被清空。

2、查看计划任务中是否存在以下任务信息

Kthrotlds挖矿病毒详细分析报告3、查看是否有以下进程信息

Kthrotlds挖矿病毒详细分析报告

4、查看/usr/sbin目录下是否有kthrotlds文件

Kthrotlds挖矿病毒详细分析报告

5、查看/etc/init.d/下是否有netdns文件

Kthrotlds挖矿病毒详细分析报告6、病毒程序执行后会消耗大量的主机cpu资源。

7、查看/usr/local/lib/下是否存在libcset.so文件

Kthrotlds挖矿病毒详细分析报告

请各位系统维护人员检查各自机子是否有以上特征,如果有以上特征,可联系默安科技安全应急响应中心获取病毒清除工具。

以下是对该病毒的分析过程:

0×2 针对kthrotlds的分析:

通过分析发现,该病毒文件还是采用了upx壳,只是对其中的魔数进行了修改:

Kthrotlds挖矿病毒详细分析报告

该病毒文件的魔数

Kthrotlds挖矿病毒详细分析报告

只要将模数修改一下即可,修改如下:

Kthrotlds挖矿病毒详细分析报告

修复后,使用upx-d 进行脱壳

Kthrotlds挖矿病毒详细分析报告

可以看到,已经脱壳成功。

下面使用ida进行反编译

Kthrotlds挖矿病毒详细分析报告

函数名都是随机字符串,看下字符串,推断程序应该是使用golang写的,和之前的差不多。

Kthrotlds挖矿病毒详细分析报告

所以这里还是要使用之前的那个符号还原脚本对程序中的符号进行还原,脚本地址是:

https://rednaga.io/2016/09/21/reversing_go_binaries_like_a_pro

还原后:

Kthrotlds挖矿病毒详细分析报告

下面开始分析main函数

0×1 向/etc/init.d/中写入kthrotlds的守护进程netdns,并将netdns设置为开机启动

0×2 删除之前版本病毒的残留信息

0×3 编译libcset.c,并将其设置为预加载动态链接库

0×4 写入定时任务,远程下载挖矿文件

0×5 启动ksoftirqds进程进行挖矿操作

0×6 删除tmp下ksoftirqds,kthrotlds,config.json,.lsdpid等文件

0×7 更新病毒程序

0×8 redis未授权攻击及ssh暴力破解攻击

Kthrotlds挖矿病毒详细分析报告

下面是将kthrotlds通过github_com_hippies_LSD_LSDC_CopyFile函数将/tmp/kthrotlds拷贝到/usr/sbin/kthrotlds中。然后往/etc/init.d/中写入一个名叫netdns的文件,并通过chkconfig命令将netdns添加为开启启动项。

Kthrotlds挖矿病毒详细分析报告

可以发现在etc/init.d目录下确实存在netdns文件。

Kthrotlds挖矿病毒详细分析报告

通过文本查看工具打开这个文件,发现其是一个bash脚本,具体如下:

   大致的意思是查看进程列表,如果发现进程kthrotlds被kill掉了,则将其启动。

下面回到kthrolds源码的分析:

紧接着是一些清除操作,这里应该是清除之前版本残留的一些文件:

Kthrotlds挖矿病毒详细分析报告

然后往/usr/local/lib写入licset.c文件,并将其编译为/usr/local/lib/licset.so文件,并将这个so文件设置为预加载动态链接库。

Kthrotlds挖矿病毒详细分析报告

具体的关于libcset.so的分析在文章的后半部分,下面继续分析main函数。

接着是进行计划任务的写入操作,释放挖矿木马ksoftirqds,及更新操作。

Kthrotlds挖矿病毒详细分析报告

以下是其计划任务中写入的命令:

Kthrotlds挖矿病毒详细分析报告

访问:https://pastebin.com/raw/D8E71JBJ即可获得病毒执行脚本

通过解密其中的base64编码的数据:
发现其和之前的脚本没有太多区别,这里主要将curl获取的图片文件重命名为了kthrotlds(原来是watchdogs)。

如需对脚本内容进行进行进一步的了解,请参考上一篇分析文章,这里就不做过多分析了:
https://www.anquanke.com/post/id/171692

0×3 横向传播

下面我们看下病毒式如何进行横向传播的:

Readis攻击

遍历内网ip及外网ip攻击redis服务器:

测试机上通过wireshark抓取到的redis攻击行为

Kthrotlds挖矿病毒详细分析报告

Main_main

->main_attack

->github_com_hippies_LSD_LSDA_Ago

->github_com_hippies_LSD_LSDA_Ago_func1

->github_com_hippies_LSD_LSDA_runtwo

->github_com_hippies_LSD_LSDA_run

->github_com_gomodule_redigo_redis_DiaTimeout

->github_com_gomodule_redigo_redis_Dial

->github_com_gomodule_redigo_redis__conn_Do

->github_com_gomodule_redigo_redis__conn_DoWithTimeout

->github_com_gomodule_redigo_redis__conn_writeCommand

相关代码:

Kthrotlds挖矿病毒详细分析报告

ssh爆破

测试机上通过wireshark抓取到的ssh爆破行为:

image.png

攻击程序调用过程

Main_main

->main_attack

->github_com_hippies_LSD_LSDA_Bbgo

->github_com_hippies_LSD_LSDA_bgo_func1

->github_com_hippies_LSD_LSDA_cmdtwo

->github_com_hippies_LSD_LSDA_cmd

->Golang_org_x_crpyto_ssh_Client_NewSession

相关代码

Kthrotlds挖矿病毒详细分析报告

这里是攻击程序的入口(main_attack)主要有两个攻击模块,一个是ssh爆破,另一个式redis未授权攻击,与上一个版本一样。

Kthrotlds挖矿病毒详细分析报告

0×4 针对ksoftirqds的分析

下面我们来看下ksoftirqds这个文件。

通过分析发现其使用的还是xmr-stak这个挖矿系统

Kthrotlds挖矿病毒详细分析报告

该项目地址是:

https://github.com/fireice-uk/xmr-stak

通过字符串检索找到其矿池地址,发现矿池已经改变

Kthrotlds挖矿病毒详细分析报告

这里矿池地址为:

sg.minexmr.com:5555

进一步跟入找到其钱包地址

Kthrotlds挖矿病毒详细分析报告

其钱包id为:

47eCpELDZBiVoxDT1tBxCX7fFU4kcSTDLTW2FzYTuB1H3yzrKTtXLAVRsBWcsYpfQzfHjHKtQAJshNyTU88LwNY4Q3rHFYA

以下是该钱包账户的收益情况

Kthrotlds挖矿病毒详细分析报告

0×5 针对libcset.c的分析

在kthrotlds中,对libcset.c进行了编译,并将编译生成后的/usr/local/lib/libcset.so设置为预加载动态链接库。

Kthrotlds挖矿病毒详细分析报告

以下是libcset.c的函数列表

Kthrotlds挖矿病毒详细分析报告

很明显病毒是通过hook libc.so中的函数的方式将与病毒相关的信息进行了隐藏。

如readdir函数

这里是对readdir函数进行了hook,对其中的进程名(病毒进程名,kthrotlds),病毒配置文件名,动态链接库名(libcset.so)进行了检查,隐藏查询结果中包含这三者的信息。其他的函数这里就不做过多分析了。

0×6 分析总结

1、相对于之前的watchdogs,其加壳方案并没有什么太大的改变,只是对于病毒程序的加固方面进行了一些修改,即将原本的upx壳的magic number改为了:4c53 44 21。那么相应的应对措施就是,在脱壳之前,将其复原为55 50 58 21。

2、进行ssh爆破及redis攻击,目的是进行横向病毒传播,扩大挖矿僵尸网络的势力

3、通过inotify监控/bin文件目录,发现其并没有删除netstat命令,这是与watchdogs的区别之一。

4、ksofttirqds程序主要是使用xmr-stak挖矿程序挖掘门罗币

5、编译libcset.c并将libcset.so设置为预加载动态链接库,隐藏病毒相关。

6、之前版本是将watchdog程序设置为开机启动项,而当前版本是编写了一个名叫netdns的脚本将其设置为开机启动项,并作为kthrotlds的守护进程。

7、矿池及钱包地址:

矿池:sg.minexmr.com:5555

钱包地址:

47eCpELDZBiVoxDT1tBxCX7fFU4kcSTDLTW2FzYTuB1H3yzrKTtXLAVRsBWcsYpfQzfHjHKtQAJshNyTU88LwNY4Q3rHFYA

8、域名:https://pastebin.com(未改变)

对应ip:104.20.209.21(未改变)

9、相关Md5特征:

da7ee5683fb870bae61e9c4088a661e4

66613e2e4210dce89b562635b769bc21

83e651497c59a14ca8d5abab85565955

4c62c53ae69d8e9290aaccb5ee694716

f1bdc8b12f2ef0279cd265c79bd6fd9e

c7560dd3933774185ce19ddbee5e526c

0×6 加固建议

病毒程序可能是通过利用redis未授权漏洞植入,所以请做好redis方面的加固。

Redis未授权漏洞简介:Redis在默认配置下,会将服务绑定在0.0.0.0:6379上,即暴露在公网上。如果同时又没有开启相关的认证,就会导致任意用户访问redis服务,进行数据库操作,并且通过进一步利用,还可以获得系统权限。

以下是redis方面的加固建议:

1. 将修改redis配置文件,将服务绑定在本机127.0.0.1上。

2.修改redis.conf,设置访问认证,启用密码认证。
3. 在防火墙处指定可访问redis服务的ip 。

4. 修改修改redis默认端口。

5. 禁用config指令防止恶意操作,这样即使存在未授权访问,也能够给攻击者使用config 指令加大难度。

6. 使用普通权限运行redis服务,这样即使攻击者获得了服务器权限也只是普通用户权限。

0×7 病毒处置办法

1)默安科技已针对病毒开发自动化清理脚本,脚本地址:

https://github.com/MoreSecLab/DDG_MalWare_Clean_Tool

3)建议使用合适工具对全网服务器进行排查Redis未授权访问漏洞并进行安全加固,从源头上避免感染病毒。

4)紧急情况下,为避免内网大量传播,可以临时对被感染机器先进行断网隔离处理。

5)不影响业务的情况下,建议临时删除机器上.ssh/known_hosts和登录密钥文件。

 *本文作者: 默安科技影武者实验室(郑斯碟),转载请注明来自FreeBuf.COM

原文阅读

Selenium初探之自动备份设备配置文件及上传
hackerbaba 2019-3-19 1:0 转存

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

一、背景介绍   

在传统的网络安全架构中,难免会有一些重要的安全设备或是软件配置需要定期备份,统一归档。一是为了满足合规,二是在设备变更出现问题的时候,能够快速回滚。手工定期备份难免会有遗漏,且浪费大量人力。

为了满足这一需求,我利用Selenium (浏览器自动化测试框架)实现这个自动备份功能,当然其他的python爬虫模块(比如request)也能实现这个功能(大体步骤都差不多),这个后续会继续分享给大家,这次就不在这里讨论。实现自动备份后,再利用python  FTP模块实现统一归档到FTP服务器。备份周期直接利用cron命令即可。既然有脚本自然少不了是否备份成功告警,利用logging模块记录日志,然后再通过rsyslog或第三方转发器传至日志分析平台即可实现告警,我们公司由于使用的splunk,利用splunk forward传输日志即可。有些人可能对Selenium不是太了解,下面我稍微简单介绍一下Selenium。

二、Selenium+Chrome配置及功能说明

Selenium是一个浏览器自动化测试框架。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。Selenium在爬虫中的运用主要就是查找html相应元素并进行元素交互操作,常见的8种元素定位的方法如下:

find_element_by_name

find_element_by_id

find_element_by_xpath

find_element_by_link_text

find_element_by_partial_link_text

find_element_by_tag_name

find_element_by_class_name

find_element_by_css_selector

其中最常用的就是find_element_by_name/id/xpath/link_text,其中xpath推荐使用浏览器插件定位元素。火狐浏览器一般使用 firebug 和 firepath 定位元素;谷歌浏览器一般使用xpath helper插件定位元素。

Windows/linux除了安装Selenium模块外,一般需要下载浏览器对应的webdriver驱动到相应文件夹声明并调用浏览器,一个简单的示例如下:

from selenium import webdriver

browser = webdriver.Chrome() 或 browser =webdriver.Firefox()   #调用谷歌或者火狐浏览器

browser.get(“http://www.baidu.com“)  #浏览器打开百度

print(browser.page_source)  #打印百度首页的源码

browser.close()  #关闭浏览器

在linux系统中,还需要声明一些“无头”配置,具体见实现见脚本。

三、python+selenium+无头Chrome具体实现脚本

Python环境:3.7.0  selenium:3.141.0  chrome:72.0.3626.119

Webdriver下载地址  https://chromedriver.storage.googleapis.com/index.html

自动备份对象:某品牌WAF设备,其他设备更改IP地址、定位相关html元素即可。

#coding=utf-8

import os

import time

import logging

import ftplib

from ftplib import FTP

from selenium import webdriver

from selenium.webdriver.common.by import By

from selenium.webdriver.common.keys importKeys

from selenium.webdriver.support.ui import Select

from selenium.webdriver importDesiredCapabilities

from selenium.webdriver.chrome.optionsimport Options

 

Device = 'WAF'    #定义设备类型

IP = 'x.x.x.x'         #目标IP

dir_time = time.strftime('%Y-%m-%d',time.localtime())

#输出当前"年-月-日"时间

dir_backup =f'/opt/sec_backup/{IP}_{Device}/{dir_time}'

#chrome下载的地址备份文件的路径

log_name =f'/opt/sec_backup/log/{IP}/{dir_time}.log'

#存放日志文件的路径

if os.path.exists(dir_backup):

   pass

else:

   os.mkdir(f'/opt/sec_backup/{IP}_{Device}/{dir_time}')

#创建dir_backup路径

 

host = 'X.X.X.X'

port = 21

user = 'XXXX'

pwd = 'XXXXX'

#以上定义FTP服务器相关信息

logging.basicConfig(filename=log_name,level=logging.INFO,format='%(asctime)s - %(name)s - %(levelname)s - %(message)s')

logger = logging.getLogger(__name__)

#定义日志输出格式

try:

   opts = Options()

   opts.headless=True

   opts.add_argument('--no-sandbox')

   opts.add_argument('--disable-gpu')

   capabilities = DesiredCapabilities.CHROME.copy()

   capabilities['acceptSslCerts'] = True

   capabilities['acceptInsecureCerts'] = True

   prefs = {'download.prompt_for_download': False,

            'download.directory_upgrade': True,

            'safebrowsing.enabled': False,

            'safebrowsing.disable_download_protection': True}

   opts.add_experimental_option('prefs', prefs)

   driver = webdriver.Chrome(options=opts,desired_capabilities=capabilities)

#以上是“无头”的一些配置,具体就不一一展开

driver.implicitly_wait(10) 

#设置超时时间10秒钟

   driver.command_executor._commands["send_command"] =("POST",'/session/$sessionId/chromium/send_command')

   driver.desired_capabilities['browserName'] = 'ur mum'

   params = {'cmd': 'Page.setDownloadBehavior', 'params': {'behavior':'allow', 'downloadPath': '%s' %dir_backup }}

   driver.execute("send_command", params)

#Chrome下载备份文件到dir_backup目录

   driver.get(f"https://{IP}/login/requireLogin")

   driver.find_element_by_id("username").send_keys("xxx")

   driver.find_element_by_id("password").send_keys("xxx")

   driver.find_element_by_id("loginButton").click()

    driver.find_element_by_id("one3").click()

   driver.find_element_by_id("two32").click()

   driver.switch_to.frame("mainFrame")

   driver.find_element_by_link_text("配置同步").click()

   driver.find_element_by_xpath("(//input[@id='tmp'])[2]").click()

   time.sleep(30)

   driver.switch_to.alert.accept()

   driver.find_element_by_xpath("//*[@id='backpointtable']/tbody/tr[2]/td[5]/img[3]").click()

   while True:

       if os.listdir(dir_backup) andos.listdir(dir_backup)[0].endswith('.wafc'):

#备份周期是天,一天只生成一个固定目录,里面只有一个备份文件,故判断是否有文件即可

           logger.info('备份成功')

           break

       else:

           continue

   

   driver.find_element_by_link_text("配置同步").click()

   driver.find_element_by_xpath("//*[@id='backpointtable']/tbody/tr[2]/td[5]/img[4]").click()

   confirm2 = driver.switch_to.alert

   confirm2.accept()

   driver.quit()

   #logger.info('删除旧备份成功')

except Exception as e:

   logger.info(f"自动备份出现异常,异常内容:{e}")

   

def ftpconnect():

   ftp_server = host

   username = user

    password = pwd

   ftp = FTP()

   ftp.set_debuglevel(0)

   ftp.connect(ftp_server, 21)

   ftp.login(username, password)

   return ftp

 

def uploadfile():

   try:

       ftp = ftpconnect()

       remotepath = ftp.mkd(f'/{IP}-{Device}/{dir_time}')

   except:

       pass

   ftp.cwd(remotepath)

   bufsize = 1024

   localfile = dir_backup + '/' + os.listdir(dir_backup)[0]

   remotefile = os.listdir(dir_backup)[0]

   print(localfile)

   fp = open(localfile, 'rb')

   ftp.storbinary('STOR ' + remotefile, fp, bufsize)

#上传本地localfile,至remotepath,并命名remotefile

   ftp.set_debuglevel(0)

#关闭ftp的调试模式,如果设置为2,则输出详细信息

   fp.close() 

 

if __name__ == '__main__':

   try:

       uploadfile()

   except Exception as e:

       logger.info(f"文件上传出现异常,异常内容:{e}")

   else:

       logger.info('文件上传成功')

四、效果图

image.pngimage.png image.pngimage.png

关于告警:log文件出现“异常”字样即可告警。

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

原文阅读

等保到底是个啥(二):网络安全部分
lywhiz 2019-3-19 0:30 转存

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

【序】

本篇将会重点讨论一下等保中对网络安全的要求,这里说明一下,文中内容全是本人个人观点,如有不对的地方欢迎纠正。文章已等保三级系统为基础,从合规角度解读要求。看到有同学吐槽等保没用,其实换个角度去思考,等保是国家对信息安全的基线,不保证做到了系统就不会被黑,但是做不到必然会被黑,各位还是不要在政策层面过于纠结。

timg.jpg

【正文】

本部分从网络安全方向解读一下标准的要求点。相比物理安全部分,网络可扩展的地方不多,广度缩小,深度增加。

前序文章:传送门 

7.1.2 网络安全

7.1.2.1 结构安全(G3)

a)应保证主要网络设备的业务处理能力具备冗余空间,满足业务高峰期需要;

b)应保证网络各个部分的带宽满足业务高峰期需要 ;

c)应在业务终端与业务服务器之间进行路由控制建立安全的访问路径;

d)应绘制与当前运行情况相符的网络拓扑结构图;

e)应根据各部门的工作职能、重要性和所涉及信息的重要程度等因素,划分不同的子网或网段,并按照方便管理和控制的原则为各子网、网段分配地址段;

f)应避免将重要网段部署在网络边界处且直接连接外部信息系统,重要网段与其他网段之间采取可靠的技术隔离手段;

g)应按照对业务服务的重要次序来指定带宽分配优先级别,保证在网络发生拥堵的时候优先保护重要主机。

结构安全层面列出了7条要求,主要涉及的都是网络工程方向,一条条解释一下:

a)这里指网络中关键设备(比如核心交换、汇聚交换,出口防火墙、串联接入的IPS和WAF),设备的处理能力必须要远大于系统实际业务的流量,比如A系统1分钟(高峰期)会有1Gb的流量,那么关键节点的设备至少要有1.3Gb(或者1.5Gb)的处理能力,这点理解起来不难,目前除非很大的平台,不然一般设备性能都是过剩的。

b)上边将的是整个网络,这里是指内部不同系统或部门线路的带宽,不难理解,所以不再重复解释了。

c)这里说的其实有些模糊。个人理解是网络中的ACL,业务系统中终端访问服务器要建立安全通道,像VPN或TLS这类的加密传输。

d)这个不用说了,大家都懂的。另外提一句题外话,就是等保2.0的云计算扩展要求中要绘制云上的网络拓扑图,有的企业就懵了,这个要怎么画。其实也一样的,云上不过就是虚拟化的vSwitch、vRouter、vFW等等的,和传统物理结构一样照着画就好了。

e)就是安全域的划分,说的再简介一点就是划vlan,划VPC,然后分网段。当然大型生产环境没这么简单,就是为了大家便于理解,举个简单的例子。

f)本条说了2点要求,1是重要系统不能没有任何策略或限制直接访问外网(相当于直连,防护设备未设置访问规则一类的情况),无论是直连还是通过其他网络;2是重要系统要限制访问,与其他系统隔离。有些系统(比如涉密)会做物理隔离,但目前采用较多的还是使用逻辑隔离的方式,通过策略进行隔离。

g)这里说的是SLA,也是目前没多少企业做到的,按照业务系统重要程度设置优先级,高峰时按照优先级分配资源(同样也适用于系统中的主机),算是比较费时费力的一项工作,大多企业都是选择放弃。

PS:补充一下,标准里没明确提出,但是字里行间也有些关系的再提一下。

1.外部接入线路至少要有2家(电信、联通、移动)且要做出入口网络负载均衡;

2.网络结构中的主要线路要做冗余双线;

3.关键节点设备要做热冗余(HSRP、VRRP这种)。

7.1.2.2 访问控制(G3)

a)应在网络边界部署访问控制设备,启用访问控制功能;

b)应能根据会话状态信息为数据流提供明确的允许/拒绝访问的能力 ,控制粒度为端口级;

c)应对进出网络的信息内容进行过滤,实现对应用层 HTTP、FTP、TELNET、SMTP、POP3等协议命令级的控制;

d)应在会话处于非活跃一定时间或会话结束后终止网络连接;

e)应限制网络最大流量数及网络连接数;

f)重要网段应采取技术手段防止地址欺骗;

g)应按用户和系统之间的允许访问规则,决定允许或拒绝用户对受控系统进行资源访问,控制粒度为单个用户;

h)应限制具有拨号访问权限的用户数量。

访问控制层面共8点要求,都是比较繁琐的部分。

a)这里要求说的是边界,不是内部,就是要边界部署防火墙,注意,不是部了,加了策略就OK,还要配置必须生效。可能有人觉得这话说的很白痴,但实际环境中就有不少这种情况,墙和策略都很完善,但是没启用。

b)ACL策略且细致度达到端口的级别,没什么说的。

举个例子:R1(config)#access-list101 permit udp 10.10.2.0 0.0.0.255 host 172.16.5.1 eq 69

c)现在的NGFW基本没压力,这是当年标准刚出时候的要求,另外提到了一点对内容过滤,被一些人关联到了敏感信息审核过滤上,按照当年的要求应该没涉及到这方面,不过描述上这么解释也说得通,毕竟现在网络媒体上的敏感词过滤还是一项大事,据了解有些平台光内容过滤团队就几百人,而且要倒班,先机审后人审。

de)这两点放在一起,其实要求都是很基础的,但是认真去做的不多。d是说,设备建立连接后,一段时间要自动断开连接。比如管理员通过跳板机先登堡垒机,然后登录交换机要开放一个端口,操作期间接了个电话,20分钟后回来继续操作。这期间如果有其他人用这台跳板机做一些非计划的操作,可能造成严重影响。当然,这里只是一个常见的情况,还有很多其他利用方式。e是说,要设置设备的最大流量和连接数,一方面是防止一些简单攻击,再一方面避免业务请求过多把设备搞崩了。

f)该项要求从当年的角度来看就是为了防ARP欺骗,那个年代一旦中招主机一摊一大片,放在今天已经不算什么了。

g)这项就是用户权限管理,放在现在用高大上的叫法:IAM或者PAM。当前环境要注意的就是越权问题。

h)这项要求一直没理解,查了一些资料也问了几个老专家,还是没给我说明白。当年检查的时候老的防火墙之类设备中有关于拨号用户的设置,这里就不乱说了,有了解的可以帮忙留言解释一下。(个人理解,就是可以远程登录的账户,不能设置过多此类账户)

7.1.2.3 安全审计(G3)

a)应对网络系统中的网络设备运行状况、网络流量、用户行为等进行日志记录;

b)审计记录应包括:事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息;

c)应能够根据记录数据进行分析,并生成审计报表;

d)应对审计记录进行保护,避免受到未预期的删除、修改或覆盖等。

这部分是测评时的重点,有时候可以一票否决,所以说比较关键。

不分别解释了,放在一起说,简单概括:企业要对网络中的网络流量(业务、访问、攻击等)、操作(登录、退出、创建、删除、变更等)进行记录,且要保存至少6个月;同时要对网络设备(包括安全设备)的运行状况进行监控,并形成周报或月报留存,同样至少6个月;此外对于网络日志至少要包括b)中要求的信息,系统中要有日志审计系统能够分析和统计日志,并且生成审计报表以供检查用;对于保存的日志要场外备份,有专人管理,保证日志的完整性,不能有未预期的删除、更改、覆盖情况。这是等保三对安全审计的要求。(对于流量很大的企业,这项要求是很坑的,比如每天几个TB流量的平台,网络日志要保存6个月,呵呵,都是泪)

7.1.2.4 边界完整性检查(S3)

a)应能够对非授权设备私自联到内部网络的行为进行检查,准确定出位置,并对其进行有效阻断;

b)应能够对内部网络用户私自联到外部网络的行为进行检查,准确定出位置,并对其进行有效阻断。

这部分要求当年理解起来挺困难的,结合现在的一些技术来看,才理解标准的前瞻性。要求简单来说就是,系统功能自动检测和发现不符合策略和规则的外联内和内联外行为。当前的态势感知、蜜罐都可以搞定外联内的情况,对于内联外的检测,个人认为更多的还是管理层面的事情,技术手段解决起来难度较大。比如私接无线网卡,办公笔记本网线接公司网,无线接热点,这种情况想第一时间发现和阻断都很难。

timg (1).jpg

7.1.2.5 入侵防范(G3)

a)应在网络边界处监视以下攻击行为:端口扫描、强力攻击、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP 碎片攻击和网络蠕虫攻击等;

b)当检测到 攻击行为源 时,记录攻击源 IP 、攻击类型、攻击目的、攻击时间, 在发生严重入侵事件时应提供报警。

简单点,IPS和WAF就好了。当年能配备这些设备的企业不多,现在不配备的不多。(这里是符合要求,不是给各位的建议,举例是便于大家理解)

7.1.2.6 恶意代码防范(G3)

a)应在网络边界处对恶意代码进行检测和清除;

b)应维护恶意代码库的升级和检测系统的更新。

算是历史遗留问题了,当年的时候有专门的防毒墙,防火墙会恶意代码防护模块。但是针对当前来说,恶意代码已经不是威胁,最大的威胁是系统自身的漏洞。这里如果是被检查,记得开启设备中的恶意代码防范功能就好,一般NGFW和IPS都具备这种防护能力。 

7.1.2.7 网络设备防护(G3)

a)应对登录网络设备的用户进行身份鉴别;

b)应对网络设备的管理员登录地址进行限制;

c)网络设备用户的标识应唯一;

d)主要网络设备应对同一用户选择两种或两种以上组合的鉴别技术来进行身份鉴别;

e)身份鉴别信息应具有不易被冒用的特点,口令应有复杂度要求并定期更换;

f)应具有登录失败处理功能,可采取结束会话、限制非法登录次数和当网络登录连接超时自动退出等措施;

g) 当对网络设备进行远程管理时,应采取必要措施防止鉴别信息在网络传输过程中被窃听;

h) 应实现设备特权用户的权限分离。

网络设备防护也算是检查的一个重点了,这里不逐条解释,统一总结一下:

1.网络中要有堡垒机,所有关键设备必须要通过堡垒机访问和登录;

2.系统中要有3A或4A认证,保证对登录管理用户进行认证和审计。(3A就是认证、授权、审计;4A在此基础上增加了可追溯/可问责性)

3.重要设备要限制登录地址(一般就是堡垒机,如特殊情况要远程登录,可在堡垒机开放远程登录功能,采用VPN方式登录),有的环境下可能会设置几台跳板机的IP。

4.网络设备的标识要简单易懂,运维人员一看就知道是什么设备,且标识不能重复。

5.采用两种以上登录方式,一般有堡垒机开启双因素认证就OK了,什么虹膜、指纹、声控都是扯淡。目前比较多的还是用户名密码配合3A认证。

6.登录失败设置,要求(1)密码输入超过N此后,自动锁定该账户M分钟(通常是N=5,M>15,只是建议,不是要求);(2)登陆后无操作,S分钟后要自动断开(一般是S<5)。

7.重要设备不要多人使用一个超级管理员账户,按照不同的人,不同的部分设置不同的账户,根据需要设定权限,采用最小权限原则;如果有能力,对于超级用户一般使用前会先申请,审批后方可由专人发放账户,并规定操作内容和操作时间。

【结尾】

以上是网络安全部分的解释和说明。最近各种工作还没开始,所有有空写点东西。关于网络部分除了上述描述外,检查中还会涉及到网络设备和安全设备的上机检查,具体内容有兴趣的可以看看这两个标准《YD/T 2698-2014》、《YD/T 2699-2014》。里边具体的检查点和检查方法都是配合等保要求来的。后续会陆续更新,谢谢各位支持。

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

原文阅读

BUF早餐铺丨一家健康科技公司正在泄露大量医疗记录和处方;18岁日本少年被控窃取13万美元数字货币;以色列总理候选人遭伊朗网络间谍攻击,个人数据泄露
翾 2019-3-18 23:1 转存

各位Buffer早上好,今天是2019年3月19日星期二。今天的早餐铺内容主要有:刚说想吃“日料”马上首位推荐 外卖App在“偷听”你说话吗?一家健康科技公司正在泄露大量医疗记录和处方;18岁日本少年被控窃取13万美元数字货币;以色列总理候选人遭伊朗网络间谍攻击,个人数据泄露;Play Store发现SimBad恶意软件,1.5亿Android用户成受害者。

20170614113739_54608.jpg

刚说想吃“日料”马上首位推荐 外卖App在“偷听”你说话吗?

2018年11月,有用户投诉称,怀疑外卖App在“偷听”自己说话,并根据偷听到的内容推荐店家。为此《IT时报》记者陆续用了3个多月的时间,对两款主流外卖App饿了么和美团外卖做了测试,在苹果手机、安卓手机、iPad等三种设备上,重新下载App,并在没有任何搜索记录的前提下,当着设备随意说出自己想吃的菜系,从结果来看,在随后数分钟到数小时的时间里,出现相关推荐的概率高达60%-70%。

对此,饿了么相关人士表示,饿了么既没有做类似的产品设置,也不具备相关技术条件,饿了么严格保护用户隐私,任何必要的信息采集都会在取得用户事先同意的前提下进行,在合法合规的范围内使用。美团人士则回应称,有关“根据麦克风收录的语音关键词为点外卖的用户做推荐”的行为并不存在,美团外卖只会在获得用户语音使用授权,且用户主动发起美团外卖App内的语音输入行为时,才会使用麦克风。此外,美团外卖仅会在用户表达了明确需求信息、进行主动查询后,才会进行相关推荐输出。

目前,最新iOS版美团外卖、饿了么,都不再索取麦克风权限,不过安卓版里的录音权限依然存在。[it-times]

一家健康科技公司正在泄露大量医疗记录和处方

外媒TechCrunch报道,一家健康科技公司在安全证书失效导致服务器没有密码后,每天泄漏数千张医生药方、医疗记录和处方。这家名不见经传的软件公司来自加利福尼亚州的Meditab,自称是医院、医生办公室和药房领先的电子医疗记录软件制造商之一。该公司为医疗保健提供商处理电子传真,仍然是将患者文件共享给其他提供商和药房的主要方法。

据发现数据的安全公司称,该传真服务器没有得到妥善保护。自2018年3月创建以来,公开的传真服务器运行的Elasticsearch拥有超过600万条记录。由于服务器没有密码,任何人都可以实时读取传输的传真,包括其内容。

根据对数据的简要回顾,传真包含大量个人身份信息和健康信息,包括医疗记录、医生药方、处方数量和数量,以及疾病信息等。传真还包括姓名、地址、出生日期,在某些情况下还包括社会安全号码和健康保险信息以及支付数据。传真还包括有关儿童的个人数据和健康信息。没有数据被加密。[cnbeta]

18岁日本少年被控窃取13万美元数字货币

一名18岁日本少年被控窃取了价值13万美元的数字货币。日本警方称这是第一次有人因为数字货币相关的黑客案件面临刑事指控。

去年8月14日到9月1日期间,这名少年利用礼品卡功能漏洞重复给自己充值,从萌奈币钱包服务Monappy的7735用户账号窃取了93078.7316个萌奈币。他使用了智能手机和Tor尝试隐藏身份,但未能成功,警方通过分析Monappy提供的服务器日志识别了他的身份。他声称就好象玩电玩发现了一个没人知道的技巧。[bleepingcomputer]

以色列总理候选人遭伊朗网络间谍攻击,个人数据泄露

以色列辛贝特国家安全局(Shin Bet internalsecurity service)称,伊朗网络间谍侵入了总理候选人Benny Gantz的手机,暴露了他的个人数据。伊朗黑客干扰了以色列前军事部长Benny Gantz的竞选活动,Benny Gantz是以色列总理Netanyahu下届选举中的主要竞争者。

据以色列情报部门称,网络间谍侵入了Gantz的移动设备,将他的个人信息和地址交到了对手手中。Gantz的发言人称,黑客在以色列4月9日大选前几周泄露窃取的数据,目的是破坏Gantz的政治竞选活动。

微软的安全专家曾警告,与伊朗有关的黑客组织正试图渗透全球的系统、企业和政府。会造成一系列经济损失。据微软称,在过去两年中,伊朗黑客已窃取了200家公司的秘密数据,并从其计算机网络中删除信息,造成了数亿美元的损失。[secrss]

Play Store发现SimBad恶意软件,1.5亿Android用户成受害者

Check Point的IT安全研究人员发现了一个复杂的恶意软件攻击行动,该行动通过谷歌Play Store在全球范围内针对Android用户进行攻击。到目前为止,已有超过1.5亿用户成为该软件的受害者。

研究人员称:“这是一个名为SimBad的恶意软件其感染的应用程序全部都是模拟器游戏。SimBad的恶意软件伪装成广告以避免引起怀疑。深入研究发现,该恶意程序代码隐藏在用于推销和盈利目的的软件开发工具包(SDK)后面,很难被发现。感染SimBad恶意软件后,除了显示恶意广告,SimBad还可以将受害者重定向到受攻击的网站,并从Play Store或远程服务器下载更多恶意应用程序来实施钓鱼攻击。

Check Point的研究人员Elena Root和Andrey Polkovnichenko在他们发表的博客文章中说:“这个恶意的SDK很容易骗过开发者,他们甚至不知道自己创造的内容导致了这次攻击行动。由此可见,此次攻击并非针对特定地区发起,恶意程序也不是由同一个开发者开发。”[leiphone]

原文阅读

EOS假充值(hard_fail 状态攻击)红色预警细节披露与修复方案
SlowMist慢雾科技 2019-3-18 9:0 转存

EOS 假充值(hard_fail 状态攻击)红色预警细节披露与修复方案

披露时间线

2019 年 3 月 10 日,我们捕获了 EOS DApp 上的一种新型攻击手法,一个帐号名为 fortherest12 的攻击者通过 hard_fail 状态攻击手法攻击了 EOS 游戏 Vegas town ,并造成了一定数量的损失。

2019 年 3 月 10 日,我们注意到出现了数量更多的 hard_fail 类型攻击。

2019 年 3 月 11 日,我们披露了相关的攻击手法,但是没有披露具体的攻击细节,并及时联系了相关的交易所以及项目方。

2019 年 3 月 12 日,我们发布红色预警,提醒交易所和钱包需要对 EOS 交易执行状态进行校验,必要时可暂停充提系统。

2019 年 3 月 13 日,预警得到 EOS New York 及 Block.one 的 BM 等核心成员响应及认可。

2019 年 3 月 14 日,细节正式公开。

漏洞细节

参考官方文档,可以得知 EOS 交易的执行状态存在多种,相应的类别及相应的描述分别为:

1. executed:交易正确执行,没有触发 error handler

2. soft_fail:交易客观失败(没有执行),但正确触发 error handler

3. hard_fail:交易客观失败,但没有触发 error handler

4. delayed:交易延迟/deferred/在队列中待执行

5. expired:交易过期

此次的攻击手法就是利用了上述状态中的 hard_fail 状态进行攻击,在以前的开发过程中,许多开发者都不曾碰到过这种交易执行状态,常规的区块浏览器上也无法查询到相关的交易,造成了开发者缺少对这种交易状态的认知。开发中的惯常思维也是只有合约才能发起延时交易。但是,通过 cleos 中的具体参数配置 delay-sec 参数:

EOS 假充值(hard_fail 状态攻击)红色预警细节披露与修复方案

即使使用非合约帐号也能正常发起 delay 交易,针对使用中心化开奖的 DApp 项目方或使用中心化管理的交易所及钱包,如果没有对 EOS 交易的执行状态进行校验,就有可能出现 “假充值” 攻击,攻击者不需要付出任何成本,却可以获得大量的 EOS。这是一种全新的攻击手法,而且也是大家十分容易忽略的点,但是导致的危害却是巨大的。对于这种手法,我们已经捕获到真实攻击,并成功阻止了一起损失金额以人民币亿为单位的攻击及多起巨额损失。但遗憾的是,还是存在几起被成功攻击的事件,这个超出了我们的能力,毕竟我们的客户或伙伴只是这个生态里的一小部分而已。

基于上述情况,我们于 3 月 12 日发布了红色预警,但由于翻译不够严谨,在 EOS 社区引起了恐慌,让 EOS 社区误以为这是 EOS 的漏洞,我们对此致以歉意。EOS 社区的一些成员认为,只要交易所及钱包做好相关的检查,并不会出现此类问题。但是我们很难要求所有程序员都能写出最佳安全实践的代码,当出现不严谨的校验方式便会导致攻击发生。

经过分析,我们更倾向于 transaction status 属于 EOS 的一种特性(features),历史上曾经出现多例与特性相关的 “假充值” 漏洞。例如:

USDT 虚假转账安全险分析

以太坊代币“假充值”漏洞细节披露及修复方案

XRP 官方披露的假充值漏洞及相关分析

这些问题都不是链自己本身的漏洞,但是由于链自己本身的特性的原因,以及开发者对此类特性校验的不严谨从而导致了攻击的发生。这就是我们为什么会发布红色预警。这不是恐吓(FUD),更像是一种容易被人忽略的攻击手法。此类攻击手法之前在 EOS 上没有相同的攻击案例,但在我们公布相关的攻击手法后,根据我们联合 EOSPark 的数据分析系统发现,已经有十几个帐号开始分别对 DApp、交易所以及钱包作出攻击测试,这些帐号有:

bobukulabobu

cuancuan2323

testsuperdex

zhangjiayiba

justjiezhan1

wnze2qwdiyne 

havls3k3iyge

ha11w4zzmpge

wkdoptxcjvdn

xmqukuailian

allosauruses

ccholr1ub2ku

walletthomas

fuckhakcer.x

johnwickteam

eosiotokenio

peospeospeos

eczpfezhvnrk

……

其中不乏攻击成功的帐号。因此,我们继续发出后续预警,提醒相关项目方做好防范措施。除此之外,Twitter 帐号 Whale Alert 也关注到了此类攻击行为。Whale Alert 官方帐号在 3 月 11 日发布推文称帐号 fuckhacker.x 转账 1 万亿 EOS,随后被官方证明为虚假交易。可见此次攻击波及范围之广。应引起足够的重视。

修复方案

针对此类型的交易,相关项目方以及交易所及钱包需要对 EOS 转账的执行状态进行校验,确保交易执行状态为 “executed”,除此之外,在区块不可逆的情况下,也要做到以下几点防止其他类型的 “假充值” 攻击的发生

1. 判断 action  是否为 transfer

2. 判断合约账号是否为 eosio.token 或其它 token 的官方合约账号

3. 判断代币名称及精度

4. 判断金额

5. 判断 to 是否是自己平台的充币账号

后记 Q&A

Q:节点开启 read only 模式能防范此类攻击吗?

A:根据官方文档对 read only 模式的描述

EOS 假充值(hard_fail 状态攻击)红色预警细节披露与修复方案

节点开启 read only 模式后可以查询到线上记录并存在的确认的交易。而此类攻击手法是先发出 defer 交易,defer 交易是在链上保存的真实存在的交易,随后这笔交易才会转变成 hard_fail,所以开启 read only 模式并不能防御此类攻击手法。交易的状态是从 delay 转变成 hard_fail,并不是回滚,这是需要注意的地方。

Q:为什么我在其他的区块浏览器上,如 EOSX 等不能查询到 hard_fail 交易?

A:现有的查询交易是通过 EOS 的历史插件 history plugin 来查询的,而根据 history plugin 的代码实现

EOS 假充值(hard_fail 状态攻击)红色预警细节披露与修复方案

可以发现,除了 executed 和 soft_fail 交易外其他交易都无法查询到。

Q:是否使用 history plugin 获取交易即可避免此类攻击?

A:无法保证,不同的节点 history plugin 插件的实现方式不一,不排除节点提供方自己修改 history plugin 实现,导致查询到的交易存在除 exectued 及 soft_fail 外的其他状态。

Q:交易所及钱包等项目方平台该如何配置他们自己的节点免受攻击?

A:使用默认的 history plugin 配置,除此之外检查 EOS 转账的交易状态,确保交易执行状态为 “executed”。同时,也需要判断以下几点防止其他类型的 “假充值”

1. 判断 action 是否为 transfer

2. 判断合约账号是否为 eosio.token 或其它 token 的官方合约账号

3. 判断代币名称及精度

4. 判断金额

5. 判断 to 是否是自己平台的充币账号

这些点都是曾在历史上出现过问题的点,我们认为 EOS 生态是一个很强大,灵活的全新的生态,从 EOS 主网启动以来,我们参与了许多的安全应急事件,开发者想在这个生态内安全的发展的确是一件充满挑战的事情。需要做好各方面的安全检查,才能确保资产不受损失。

结语

我们希望阅读此文的 EOS 生态中的用户不要模仿文中的攻击手法,我们无意对 EOS 社区造成恐慌。慢雾安全团队本着为 EOS 生态带来更多的安全感为宗旨,及时披露相关安全事件细节,目的是为了 EOS 生态中的更多成员获得安全保障。相关项目方应及时做好充提系统的安全保障,落实对应的风控策略,保障自身财产的安全。

相关参考

How to monitor state with State History Plugin

官方文档对 nodeos 三种模式的描述

USDT 虚假转账安全⻛险分析

以太坊代币“假充值”漏洞细节披露及修复方案

XRP 官方披露的假充值漏洞及相关分析

EOS 新型攻击手法之 hard_fail 状态攻击

EOS 智能合约最佳安全开发指南

致谢

EOSPark

IMEOS

jerry@EOSlive 钱包

*本文作者:慢雾安全团队,转载请注明来自FreeBuf.COM。

原文阅读

本站作者

每日荐书

在不完美的世界力求正常——读《公司的坏话》

书名:《公司的坏话》

作者:李天田(脱不花妹妹)

出版社:北京大学出版社

赞助商

广告