绿盟科技博客 - 2017最新注册送体验 http://blog.cholochitro.com Fri, 17 May 2019 03:14:12 +0800 zh-CN hourly 1 https://wordpress.org/?v=5.1.1 IoT设备逆向工程中的函数识别 http://blog.cholochitro.com/function-recognition-reverse-engineering-iot-equipment/ http://blog.nsfocus.net/function-recognition-reverse-engineering-iot-equipment/#respond Fri, 17 May 2019 03:14:12 +0000 http://blog.cholochitro.com/?p=15100 本文主要讨论IoT设备逆向工程中的函数识别、符号迁移问题,不考虑BinDiff、PatchDiff2等重型工具,有些场景也不太适用。函数识别技术主要涉及两大类,一是IDA自身的FLIRT技术,二是Craig的rizzo技术,本文介绍它们的基本原理、工程实践细节。另外附赠几个其他类型IDA插件的使用说明。

☆ 前言

本文主要讨论IoT设备逆向工程中的函数识别、符号迁移问题,不考虑BinDiff、PatchDiff2等重型工具,有些场景也不太适用。函数识别技术主要涉及两大类,一是IDA自身的FLIRT技术,二是Craig的rizzo技术,本文介绍它们的基本原理、工程实践细节。另外附赠几个其他类型IDA插件的使用说明。

☆ 函数识别/符号迁移

1) FLIRT

1.1) FLIRT简介

考虑如下场景,分析一个被strip过的、不包含调试信息、符号信息的ELF,此ELF静态链接过OpenSSL的libcrypto.a,而你关心ELF所用加密算法、HASH算法。findcrypt插件可用于这种需求,但不够。

FLIRT是”Fast Library Identification and Recognition Technology”的缩写。这是IDA自带的一种函数识别技术,用于前述需求。

参[1],作者介绍IDA 3.6中FLIRT技术的基本原理:

————————————————————————–
Each function is represented by a pattern. Patterns are first 32 bytes of a function where all variant bytes are marked.

A special signature file, called startup signature file is applied to the entry point of the disassembled program to determine the generating compiler.

For the sake of user’s convenience we attempted to recognize the main() function as often as it was possible. The algorithm for identifying this function differs from compiler to compiler and from program to program.

The signature file contains no byte from the original libraries, except for the names of the functions.
————————————————————————–

简单点说,为静态库中每个函数确定其特征字节流、特定调用关系、特定检查项等等,以此识别出对应函数。将各函数名及其识别特征按特定格式组织并存放在签名文件中,形成扩展名为.sig的签名文件。IDA在分析ELF时,可以加载.sig,自动识别ELF中静态链接进来的库函数。

签名文件对函数的识别标准比较复杂,并不是函数入口32字节这么简单,细节参[1]。

1.2) 签名文件

IDA自带一些签名文件:

$ cd "C:\Program Files\IDA"
$ tree /F /A sig
|   list
|
+---arm
|       android_arm.sig
|       armlibb.sig
|       armlibl.sig
|       armlib_l.sig
|       autoload.cfg
|       elf.sig
|       mfc.sig
|       pe.sig
|       vc_atl.sig
|       vc_extra.sig
|       vc_rtf.sig
...
|
+---mips
|       mfc.sig
|       pe.sig
|       psx.sig
|       psyq.sig
|
+---pc
|       autoload.cfg
...

IDA自带签名文件存放在:

<IDA PATH>\sig\<arch>\*.sig

<arch>是CPU架构,IoT设备逆向工程很可能面对arm。.sig的名字已经提供了一定信息,可以从中猜测该.sig源自什么,.sig中可能含有一条说明信息,用如下办法查看:

$ strings -n 5 armlibl.sig | head -2
IDASGN
ARM library little endian

第二行输出即可能存在的说明信息,不是所有的.sig都有说明信息。

1.3) 应用签名

View->Open subviews->Signatures(Shift-F5)

此处看到当前使用的签名文件及靠它识别出来的函数个数

View->Open subviews->Signatures(Shift-F5)->右键菜单->Apply new signature(Ins)

File->Load file->FLIRT signature file

此处看到”<IDA PATH>\sig\<arch>\”下所有签名文件

《The IDA Pro Book》第2版第12章介绍FLIRT、FLAIR的使用。

--------------------------------------------------------------------------
Only functions named with an IDA dummy name can be automatically renamed.
In other words, if you have renamed a function, and that function is later
matched by a signature, then the function will not be renamed as a result
of the match. Therefore, it is to your benefit to apply signatures as
early in your analysis process as possible.
--------------------------------------------------------------------------

“dummy name”形如”sub_…”。这即是说,binary被反汇编后尽可能早地应用签名文件,以免出现人工重命名干挠签名文件带来的重命名。

1.4) FLAIR简介

FLAIR是”Fast Library Acquisition for Identification and Recognition”的缩写。这是IDA自带工具集,用于定制自己的签名文件。

FLAIR工具集的基本使用方式:

ELF -- (pelf) --> PAT -- (sigmake) +--> SIG -- (zipsig) --> 压缩格式的SIG
                                   |
                                   +--> EXC

.a通过pelf得到.pat,后者是静态库中各函数名及其识别特征的文本文件格式。

.pat通过sigmake得到.sig。一般情况下第一次执行sigmake会碰上冲突,就是说多个函数的识别特征是一样的,此时会产生.exc文件,必须手工处理.exc,解决冲突,再次执行sigmake得到.sig。

sigmake得到的.sig已经可以为IDA所用,可用zipsig对之压缩,得到扩展名仍然是.sig的压缩版,IDA同时支持非压缩、压缩版.sig。

FLAIR自带帮助文件:

--------------------------------------------------------------------------
readme.txt
    FLAIR工具集概述
pat.txt
    详细介绍PAT文件格式
sigmake.txt
    sigmake.exe的帮助文件,介绍EXC文件格式及处理方式
plb.txt
    plb.exe的帮助文件
--------------------------------------------------------------------------

1.5) EXC文件

$ pelf libcrypto.a libcrypto_arm.pat
$ sigmake -n"openssl-1.0.1l libcrypto.a for arm" libcrypto_arm.pat libcrypto_arm.sig
libcrypto_arm.sig: modules/leaves: 497/595, COLLISIONS: 9

这表示.pat中存在冲突,多个函数的识别特征一样;自动生成libcrypto_arm.exc,比如:

--------------------------------------------------------------------------
;--------- (delete these lines to allow sigmake to read this file)
; add '+' at the start of a line to select a module
; add '-' if you are not sure about the selection
; do nothing if you want to exclude all modules
X509_get_default_private_dir                      	00 0000 00001FE51EFF2FE1........00001FE51EFF2FE1........00001FE51EFF2FE1
EVP_dss                                           	00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5
EVP_dss1                                          	00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5
EVP_ecdsa                                         	00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5
NETSCAPE_SPKI_free                                	00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA
PROXY_CERT_INFO_EXTENSION_free                    	00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA
--------------------------------------------------------------------------

.exc最前面4行内容是固定的,它告诉你可以在后面的每行打头处增加+/-号,其意义是:

+ 使用该函数名
– 让该函数名以注释形式出现

后面是空行分隔的冲突分组。

手工处理.exc示例:

--------------------------------------------------------------------------
X509_get_default_private_dir                      	00 0000 00001FE51EFF2FE1........00001FE51EFF2FE1........00001FE51EFF2FE1
+EVP_dss                                           	00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5
EVP_dss1                                          	00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5
EVP_ecdsa                                         	00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5
NETSCAPE_SPKI_free                                	00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA
-PROXY_CERT_INFO_EXTENSION_free                    	00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA
--------------------------------------------------------------------------

必须删掉.exc最前面4行,表示这个.exc已被手工处理过,否则第二次sigmake不会做动作。

对第1冲突分组(从1计)不做任何动作,该函数名被废弃。

对第2冲突分组采用函数名”EVP_dss”,其余两个函数名被废弃,这导致误报。

对第3冲突分组在匹配函数处增加注释”PROXY_CERT_INFO_EXTENSION_free”。

处理EXC文件时的三条基本原则:

————————————————————————–
a)

最简处理方式是删除EXC文件最前面(以分号打头的)4行内容,其余内容保持不变。这
表示冲突分组中所有函数名被废弃,重命名时不会用到它们。

b)

不要在同一个冲突分组内同时使用+/-,要么+要么-,且只出现一次。

c)

如果某冲突分组只有一个函数,不要对之使用+/-,保持原样,表示废弃该函数名。
我不清楚为什么会出现这种情形。
————————————————————————–

2) IDB2PAT

定制签名文件的一般套路是:

ELF -> PAT -> SIG

有可能出现:

IDB -> PAT -> SIG

考虑如下场景,分析过一个裸格式的IoT固件,已经重命名一批关键函数,某天需要分析另一个与前者高度接近的新版固件,此时可以用BinDiff、PatchDiff2进行二进制比较,但那过于重型,有无其他办法快速迁移函数名?

IDB2PAT是个IDA插件,顾名思义,从当前IDB导出PAT文件。然后sigmake生成SIG并应用到新IDB中。

最早IDB2PAT是C版插件,需要IDA SDK编译,IDA一升级就得重新编译。FireEye提供了Python版插件,参[6]。

Alt-F7加载idb2pat.py,提示选择输出PAT文件到哪里,确定即可。

idb2pat.py可用于IDA 7.2。为了在IDA 7.1中使用,需要做些修改。把所有的”get_name(“全文替换成”get_name(BADADDR,”,7.2版get_name()函数原型是”get_name(ea)”,7.1版get_name()函数原型是”get_name(from,ea)”。原实现中Config()使用缺省参数”mode=ALL_FUNCTIONS”,改成”NON_AUTO_FUNCTIONS”,否则会将”sub_…”一并导出到PAT文件,这没有意义。

3) lscan

参[7]。

考虑如下场景,用IDA分析某strip过的ELF,发现其中存在被静态链接进来的库函数,想快速知道该ELF用到哪些静态库,想快速重命名相应的静态库函数。假设你有大量现成的.sig,一个个试过去太累。

lscan可以解决上述需求。它不是IDA插件,是独立使用的Python脚本。lscan检查SIG与ELF的匹配程度,匹配百分比越高,ELF用到相应静态库的可能性越大。lscan可以一次性检查多个SIG与单个ELF的匹配度,然后在IDA中优先应用匹配度最高的SIG。

lscan不能使用经zipsig压缩过的SIG,只认非压缩版SIG。

[scz@ /home/scz/src]> pip2 install pyelftools pefile
[scz@ /home/scz/src]> git clone https://github.com/maroueneboubakri/lscan.git
[scz@ /home/scz/src]> du -hs lscan
406M    lscan

“git clone”下回来406M,真正有用的就lscan.py一个文件,其他的都算测试集,其自带SIG没啥大用,所以不必”git clone”下载。

[scz@ /home/scz/src/lscan]> python2.7 lscan.py -h
Usage: lscan.py [options]
Options:
  -h, --help            show this help message and exit
  -v, --versbose        Verbose mode
  -s SIGFILE, --sig=SIGFILE
                        Signature file
  -S SIGDIR, --sigs=SIGDIR
                        Signature folder
  -f BINFILE, --file=BINFILE
                        ELF file
  -d, --dump            Dump signature filre

用lscan自带”arm/sig/”下的所有SIG去匹配FLIRTTarget:

[scz@ /home/scz/src/lscan]> python2.7 lscan.py -S arm/sig -f /tmp/FLIRTTarget
arm/sig/libssl-1.0.1e.sig 15/573 (2.62%)
arm/sig/libpthread-2.13.sig 0/260 (0.00%)
arm/sig/libssl-1.1.0.sig 0/863 (0.00%)
arm/sig/libc-2.22.sig 0/2841 (0.00%)
arm/sig/libc-2.23.sig 0/2853 (0.00%)
arm/sig/libm-2.13.sig 0/318 (0.00%)
arm/sig/libcrypto-1.0.1e.sig 27/4518 (0.60%)
arm/sig/libcrypto-1.1.0.sig 0/37 (0.00%)
arm/sig/libm-2.22.sig 0/339 (0.00%)
arm/sig/libpthread-2.22.sig 0/273 (0.00%)
arm/sig/libc-2.13.sig 0/2816 (0.00%)

lscan自带SIG没有适用于FLIRTTarget的。

用自制SIG去匹配FLIRTTarget:

[scz@ /home/scz/src/lscan]> ls /tmp/sig
fromidb.sig  libcrypto_arm.sig  libssl_arm.sig

fromidb.sig源自IDB2PAT,其余两个.sig源自自编译库文件。

[scz@ /home/scz/src/lscan]> python2.7 lscan.py -S /tmp/sig -f /tmp/FLIRTTarget
/tmp/sig/fromidb.sig 4358/2803 (155.48%)
/tmp/sig/libcrypto_arm.sig 107955/4771 (2262.73%)
/tmp/sig/libssl_arm.sig 247/600 (41.17%)

从这个输出看出lscan有BUG,匹配百分比都超出100%了,我懒得去找原因。

4) rizzo

FLIRT的函数识别特征主要是机器码序列,而静态库函数的机器码序列受编译器、编译选项、源代码版本影响太大。Craig提出另一套启发式函数识别标准,参[8],他检查函数如下项:

a) 对特征字符串的引用
b) 对特征常量的引用
c) CFG
d) …

这些检查项受编译器、编译选项、源代码版本影响较小。

rizzo的工作流程是:

IDB A -> RIZ -> IDB B

rizzo和IDB2PAT都是从IDB出发。在IDB A中利用rizzo导出.riz文件,这相当于FLIRT的.sig文件。然后在IDB B中利用rizzo导入.riz文件,这相当于应用签名。

考虑如下场景,用IDA反汇编静态库libsome.a,用rizzo导出some.riz,用IDA反汇编怀疑用到libsome.a的ELF,用rizzo导入some.riz。

rizzo.py是IDA插件,将之复制到plugins目录,重启IDA即可。

导出.riz:

File->Produce file->Rizzo signature file

加载.riz:

File->Load file->Rizzo signature file

如果没看到这两项,说明插件有BUG。

.riz文件随便在哪儿,不要求放到”<IDA PATH>\sig\<arch>\”下。

5) 利用IDC迁移符号

如果两个IDB对应同一个ELF,通过导出IDC迁移符号、结构、注释即可。为什么会有这种需求,自己想去。

导出.idc:

File->Produce file->Dump database to IDC file

编辑some.idc,修改main(),只保留Bytes()、Functions()相关的函数。

加载.idc:

File->Load file->Additional binary file

6) syms2elf

参[10]。

假设某ELF是strip过的,用IDA对之进行分析,利用FLIRT、rizzo等技术重命名过一批函数,此时利用syms2elf生成一个包含符号信息的新ELF。IDA反汇编新ELF时、gdb调试新ELF时,符号信息自动生效。将syms2elf.py复制到plugins目录,重启IDA即可。可用于IDA 6.95至7.2,x86/x64均可。

Edit->Plugins->sym2elf

假设FLIRTTarget是旧ELF,FLIRTTarget_new是新ELF:

$ file -b FLIRTTarget
ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
$ file -b FLIRTTarget_new
ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, not stripped
$ nm -C FLIRTTarget_new | grep Private

nm可以看到新ELF中已经包含重命名过的函数名。

$ nm -C FLIRTTarget_new | grep sub_

syms2elf会将”sub_…”当成有效函数名写入新ELF,这不好,应该只写”sub_…”之外的其他函数名,我懒得改。

可用objcopy从新ELF中导出符号文件:

$ objcopy --only-keep-debug FLIRTTarget_new FLIRTTarget_new.sym

显然,syms2elf只能用于ELF格式的binary,不能用于裸格式的固件。

syms2elf构造新ELF时会去找旧ELF,如果旧ELF不在相应路径上,syms2elf会失败。

检查binary所在路径:

idaapi.get_input_file_path()

修改binary所在路径:

idaapi.set_root_filename( “…” )

修改成相对路径,比如只保留ELF文件名,不要目录结构,这样ELF与IDB在同一目录
即可。

7) 静态库

FLIRT、rizzo技术都依赖一个匹配度较高的静态库,有它才有SIG、RIZ。一般情况下分析ELF时很难知道它用到哪些静态库,更不要说获取编译时所用静态库文件本身。运气好的话,可能在ELF中看到一些相关字符串信息。

$ file -b FLIRTTarget
ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
$ strings -n 5 FLIRTTarget | grep -i gcc | sort -u
GCC_3.5
libgcc_s.so.1

这可能表示编译FLIRTTarget时用的是gcc 3.5。在没有ldd的环境中查看ELF所依赖的动态库:

$ LD_TRACE_LOADED_OBJECTS=1 ./FLIRTTarget
        libdl.so.0 => /lib/libdl.so.0 (0x4000f000)
        libstdc++.so.6 => /lib/libstdc++.so.6 (0x4001a000)
        librt.so.0 => /lib/librt.so.0 (0x400fe000)
        libc.so.0 => /lib/libc.so.0 (0x40109000)
        libcrypt.so.0 => /lib/libcrypt.so.0 (0x401a3000)
        libm.so.0 => /lib/libm.so.0 (0x401bf000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x401d7000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401f5000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)
$ strings -n 5 FLIRTTarget | grep -i rsa | sort -u | less
...
Eric Young's PKCS#1 RSA
...
rsa_ameth.c
RSA_blinding
...
rsa_eay.c
rsaEncryption
rsaesOaep
...
rsa_keygen_bits
rsa_keygen_pubexp
...
rsa_lib.c
...
RSA_new faild
...
rsa_oaep.c
...
RSA part of OpenSSL 1.0.1l 15 Jan 2015
rsa_pk1.c
rsa_pmeth.c
...
rsa_pss.c
...
rsa_saos.c
...
rsa_sign.c
...
ssl_rsa.c
...

FLIRTTarget可能用到”OpenSSL 1.0.1l”ARM版静态库(libcrypto.a)。

如下命令查看libcrypto.a中的符号:

$ nm -C libcrypto.a | grep RSA_new

如下命令可知libcrypto.a的版本号:

$ strings -n 5 libcrypto.a | grep -E "^OpenSSL\s+[0-9]\."

如果有条件,还可以这样确定版本号及编译选项:

$ openssl version -a

上哪儿去找FLIRTTarget所用libcrypto.a呢?

7.1) 从源码编译OpenSSL

https://ftp.openssl.org/source/old/1.0.1/openssl-1.0.1l.tar.gz

版本是”openssl-1.0.1″,后面跟着小写的字母”l”。

交叉编译ARM版本:

[scz@ /tmp/arm]> tar xfz /tmp/openssl-1.0.1l.tar.gz
[scz@ /tmp/arm/openssl-1.0.1l]>
./Configure --prefix=/usr/local --openssldir=/usr/local/openssl threads no-zlib no-shared linux-armv4
make CC=arm-gcc

arm-gcc是个示意写法,你得设法分析FLIRTTarget,找出一个最接近的交叉编译工具链。

我们只关心加密算法相关的函数,比如RSA_new(),指定no-zlib表示不关心zlib,否则还得交叉编译zlib,麻烦。

从源码编译OpenSSL是被逼无奈的选择,不知道当时所用编译器、编译选项等信息,只能瞎猜将就。

7.2) 生成SIG

$ nm -C libcrypto.a | grep RSA_new
$ pelf libcrypto.a libcrypto_arm.pat
$ sigmake -n"openssl-1.0.1l libcrypto.a for arm" libcrypto_arm.pat libcrypto_arm.sig
libcrypto_arm.sig: modules/leaves: 497/595, COLLISIONS: 9

sigmake很少能一次性成功,必须手工处理.exc解决冲突。

二次执行sigmake:

$ sigmake -n"openssl-1.0.1l libcrypto.a for arm" libcrypto_arm.pat libcrypto_arm.sig

可用zipsig对.sig进行压缩,减少空间占用,但这不是必须的:

$ zipsig libcrypto_arm.sig

可用dumpsig查看.sig:

$ dumpsig libcrypto_arm.sig libcrypto_arm.txt
$ dumpsig -f -X libcrypto_arm.sig libcrypto_arm.txt

dumpsig不能还原出.pat,由.pat到.sig的过程有信息丢失,是单向过程,但dumpsig得到的.txt中仍能看到特征字节流信息。

新生成的.sig应该放到”<IDA PATH>\sig\<arch>\”下。

用IDA反汇编libcrypto.a,用rizzo导出libcrypto.riz。

7.4) SIG/RIZ实验

个人经验是优先应用RIZ,再应用SIG。

先在FLIRTTarget.idb中应用libcrypto.riz,成功识别出:

00AF2A60 RSA_new

注意到FLIRTTarget.idb中RSA_new之后的函数未被识别。接着应用SIG,先Shift-F5,
再Ins,依次应用:

libcrypto_arm.sig
libssl_arm.sig
fromidb.sig

测试发现反复应用SIG可以多识别出一些函数,比如:

File          State   #func Library name
----          -----   ----- ------------
armlibl       Applied 0     ARM library little endian
libcrypto_arm Applied 2403  openssl-1.0.1l libcrypto.a for arm
libssl_arm    Applied 111   openssl-1.0.1l libssl.a for arm
libcrypto_arm Applied 715   openssl-1.0.1l libcrypto.a for arm
libssl_arm    Applied 37    openssl-1.0.1l libssl.a for arm
libcrypto_arm Applied 256   openssl-1.0.1l libcrypto.a for arm
libssl_arm    Applied 0     openssl-1.0.1l libssl.a for arm
libcrypto_arm Applied 172   openssl-1.0.1l libcrypto.a for arm
libcrypto_arm Applied 172   openssl-1.0.1l libcrypto.a for arm

第二行表示该轮应用libcrypto_arm.sig时有2403处函数重命名发生。

从FLIRT技术原理看,应该多次应用SIG,直至不再新增被识别函数。

7.5) 其他

静态链接时,.o中所有函数都被链接到binary中。假设在FLIRTTarget.idb中识别出.o中某函数,其前后函数很可能对应.o中的布局,如果前后函数未被重命名,可手工检查之。

8) 社区维护的SIG库 vs 自编译源码

参[7],有一些社区维护的SIG库,不过没啥用,用脚趾头都能想像。实践表明,还得想办法自编译源码获取SIG/RIZ,从最终效果看,这样做有意义。

9) IDA Signsrch

参[4]。

Tool for searching signatures inside files, extremely useful as help in
reversing jobs like figuring or having an initial idea of what encryption/
compression algorithm is used for a proprietary protocol or file. It can
recognize tons of compression, multimedia and encryption algorithms and
many other things like known strings and anti-debugging code which can be
also manually added since it's all based on a text signature file read at
run-time and easy to modify

“IDA Signsrch”功能类似过去的findcrypt.plw,能识别的算法更多,可用于IDA 7.2。将IDA_Signsrch.plw、IDA_Signsrch.p64、signsrch.xml、IDA_Signsrch.dll、IDA_Signsrch64.dll分别放入相应版本plugins目录,重启IDA即可。

Edit->Plugins->Signsrch->Continue

匹配结果在”Signsrch matches”窗口展示。

“IDA Signsrch”和findcrypt不能说没用,但用处有限,很多时候还不如自己肉眼识别特征常数并Google之。

10) 静态识别 vs 动态调试

用IDA静态识别加密函数只是手段之一,如能动态调试,可以通过观察in/out合理猜
测算法并验证之,二者可以结合着来。

☆ 反编译

1) Snowman

参[2]。

Snowman类似Hex-Rays,但远不如Hex-Rays。简单的”Hello World”反编译结果都惨不忍睹。号称支持x86、x64、ARM、ARM64。官方声称支持到IDA 7.0,但实际上7.2也可以用。

将snowman.plw、snowman.p64、snowman.dll、snowman64.dll分别放入相应版本plugins目录,重启IDA即可。在光标处按F3展示当前函数C代码。F3的展示窗口有两块区域,左侧是汇编,右侧是C/C++,可以在汇编区域选中代码片段,右键菜单中有”Decompile (Ctrl-E)”,对所选代码片段进行反编译,但这没有什么意义。

2) HexRaysCodeXplorer

参[5]。

将HexRaysCodeXplorer.plw、HexRaysCodeXplorer.p64、HexRaysCodeXplorer32.dll、HexRaysCodeXplorer64.dll分别放入相应版本plugins目录,重启IDA即可。

这是Hex-Rays的插件,在Hex-Rays的反编译窗口中通过右键菜单使用。插件生效时,右键菜单多出如下项:

Display Ctree Graph     T
Object Explorer         O
REconstruct Type        R
Extract Types to File   S
Extract Ctrees to File  C
Ctree Item View         V
Jump to Disam           J
Show/Copy item offset   Q
Rename vars             E

IDA可以在”Local types (Shift-F1)”中自定义结构,HexRaysCodeXplorer的”REconstruct Type”就是自动干这事,这是该插件最有用的功能。基本用法是:

a) 在Hex-Rays反编译窗口中选中对象(结构)指针
b) 右键”Reset pointer type”,或手工将变量由指针类型变成整型
c) 右键”REconstruct Type”
d) 检查”Local types (Shift-F1)”

HexRaysCodeXplorer-2.1.zip与IDA 7.2 SDK不兼容,目前不能在IDA 7.2中使用。

☆ 其他

1) IdaRef

参[3]。

IdaRef的效果是,当光标停留在某条汇编指令上时,在”Instruction Reference”窗口实时显示该汇编指令的帮助信息。支持x86、x64、ARM、MIPS。

|   idaref.py
|
\---archs
        arm.sql
        mips32.sql
        x86-64.sql
        x86-64_old.sql
        xtensa.sql

将idaref.py和archs目录复制到plugins目录,重启IDA即可。

Edit->idaref->Stop Idaref/Start Idaref

这是个鸡肋插件,食之无味、弃之可惜。

Options->General->Disassembly->Auto comments

一般来说,打开IDA的自动注释就够了。

☆ 参考资源

[1] IDA F.L.I.R.T. Technology: In-Depth
https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml

[2] Snowman
https://github.com/yegord/snowman

[3] IdaRef
https://github.com/nologic/idaref

[4] IDA Signsrch
https://sourceforge.net/projects/idasignsrch/

[5] HexRaysCodeXplorer
https://github.com/REhints/HexRaysCodeXplorer

[6] IDB2PAT
https://github.com/fireeye/flare-ida/blob/master/python/flare/idb2pat.py

http://www.openrce.org/downloads/details/26/IDB_2_PAT
(C版本)

[7] lscan
https://github.com/maroueneboubakri/lscan

Community driven collection of IDA FLIRT signature
https://github.com/Maktm/FLIRTDB
https://github.com/push0ebp/sig-database
(没有arm的)

[8] https://github.com/devttys0/ida/tree/master/plugins/rizzo

A Code Signature Plugin for IDA – Craig [2014-10-11]

A Code Signature Plugin for IDA

[10]
syms2elf
https://github.com/danigargu/syms2elf

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/function-recognition-reverse-engineering-iot-equipment/feed/ 0
【威胁通告】Cisco Prime Infrastructure and Evolved Programmable Network Manager远程代码执行漏洞 http://blog.cholochitro.com/cisco-prime-infrastructure-evolved-programmable-network-manager/ http://blog.nsfocus.net/cisco-prime-infrastructure-evolved-programmable-network-manager/#respond Thu, 16 May 2019 06:57:35 +0000 http://blog.cholochitro.com/?p=15098 当地时间5月15日,Cisco官方发布一则安全通告,称修复了Cisco Prime Infrastructure and Evolved Programmable Network Manager中存在的3个高危漏洞(2018年送彩金网站大全2019-1821、2018年送彩金网站大全2019-1822、2018年送彩金网站大全2019-1823)。这些漏洞源于软件没有合理地对用户输入进行校验和过滤,攻击者可以通过向管理员界面上传恶意的文件来触发,利用成功会使得攻击者在被攻击系统中以root权限执行代码。

CVSS:3.0 Base 9.8

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:X/RL:X/RC:X

详细信息可参考:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-pi-rce

受影响的版本

  • Cisco PI Software Releases < 3.4.1
  • Cisco PI Software Releases < 3.5
  • Cisco PI Software Releases < 3.6
  • EPN Manager Releases < 3.0.1

不受影响的版本

  • Cisco PI Software Releases == 3.4.1
  • Cisco PI Software Releases == 3.5
  • Cisco PI Software Releases == 3.6
  • EPN Manager Releases 3.0.1

解决方案

Cisco官方已经发布了对应的新版本修复了上述漏洞,用户应及时更新升级进行防护,下载地址及方法详见参考链接[1]。检查软件版本操作办法详见参考链接[2]。

参考链接:

[1] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-pi-rce#fr

[2] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-pi-rce#vp

声 明

本安全2018博彩游戏网站大全仅用来描述可能存在的安全问题,绿盟科技不为此安全2018博彩游戏网站大全提供任何保证或承诺。由于传播、利用此安全2018博彩游戏网站大全所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,绿盟科技以及安全2018博彩游戏网站大全作者不为此承担任何责任。绿盟科技拥有对此安全2018博彩游戏网站大全的修改和解释权。如欲转载或传播此安全2018博彩游戏网站大全,必须保证此安全2018博彩游戏网站大全的完整性,包括版权声明等全部内容。未经绿盟科技允许,不得任意修改或者增减此安全2018博彩游戏网站大全内容,不得以任何方式将其用于商业目的。

 

关于绿盟科技

北京神州绿盟信息安全科技股份有限公司(简称绿盟科技)成立于2000年4月,总部位于北京。在国内外设有30多个分支机构,为政府、运营商、金融、能源、互联网以及教育、医疗等行业用户,提供具有核心竞争力的安全产品及解决方案,帮助客户实现业务的安全顺畅运行。

基于多年的安全攻防2017最新注册送体验,绿盟科技在网络及终端安全、互联网基础安全、合规及安全管理等领域,为客户提供入侵检测/防护、抗拒绝服务攻击、远程安全评估以及Web安全防护等产品以及专业安全服务。

北京神州绿盟信息安全科技股份有限公司于2014年1月29日起在深圳证券交易所创业板上市交易,股票简称:绿盟科技,股票代码:300369。

 

文章来源:绿盟科技博客
无标签]]>
http://blog.nsfocus.net/cisco-prime-infrastructure-evolved-programmable-network-manager/feed/ 0
【M01N】APT34 Glimpse&PoisonFrog 项目分析 http://blog.cholochitro.com/apt34-glimpsepoisonfrog/ http://blog.nsfocus.net/apt34-glimpsepoisonfrog/#respond Wed, 15 May 2019 08:38:28 +0000 http://blog.cholochitro.com/?p=15092 近期在Lab Dookhtegan Telegram Chanel中泄露的关于APT34的攻击工具项目、攻击成果记录及部分组织成员信息的事件,引发业界威胁情报及Red Team领域的安全人员强烈关注。类似于2017年Shadow Brokers泄漏的NSA攻击工具事件,但APT34工具的工程化程度和威胁影响力远不及NSA的泄露内容。就C2分析该组织习惯使用DNS隧道技术,并以文件系统来作为信息交互的媒体,这是一种非常规的实现方法,我们将在本文中对相关远控工具进行分析并尝试完成攻击功能还原。

0x01 简介

近期在Lab Dookhtegan Telegram Chanel中泄露的关于APT34的攻击工具项目、攻击成果记录及部分组织成员信息的事件,引发业界威胁情报及Red Team领域的安全人员强烈关注。类似于2017年Shadow Brokers泄漏的NSA攻击工具事件,但APT34工具的工程化程度和威胁影响力远不及NSA的泄露内容。就C2分析该组织习惯使用DNS隧道技术,并以文件系统来作为信息交互的媒体,这是一种非常规的实现方法,我们将在本文中对相关远控工具进行分析并尝试完成攻击功能还原。

0x02 TTPs分析

该组织被公开威胁情报平台关联命名为APT34Oilrig或者HelixKitten 。自2014年,FireEye就已追踪到APT34根据伊朗的战略利益进行了侦察。该组织主要在中东开展活动,重点针对金融,政府,能源,化工,电信和其他行业。对中东金融,能源和政府组织的反复攻击聚焦导致FireEye评估这些行业是APT34的主要关注点。依据与伊朗行动相关的基础设施、时机以及与伊朗国家利益保持一致也使FireEye评估APT34代表伊朗政府行事。

本次泄漏工具列表如下:

  • Glimpse(基于PowerShell的的新版木马,Palo Alto Networks命名为BondUpdater)
  • PoisonFrog(旧版BondUpdater)
  • HyperShell
  • HighShell(Palo Alto Networks称之为TwoFace)
  • MinionProject(fox管理界面,加载了HighShell模块)
  • Webmask(HTTP代理劫持工具,DNSpionage的主要工具,用于DNS修改)

本次泄漏工具与以往APT34开源情报进行TTPs对比分析,如下图所示,蓝色代表开源威胁情报当中APT34所涉及的技术,红色代表本次事件泄漏工具所涉及技术(注意出现的红色模块均覆盖到蓝色模块),可以发现泄漏工具技术均覆盖到APT34开源情报TTPs,并占据了1/5的内容,涉及到攻击链中执行和C2这两块相当重要的攻击阶段,所以这次泄漏事件对于APT34组织来说也是相当受打击的。

通过TTPs分析我们认为此次泄漏工具集与OilRig攻击者使用的一致(另外泄漏的webshell后门全球的受影响的地区分布和行业分布也和公开威胁情报显示内容一致),并且自2016年5月以来,OilRig使用了DNS隧道进行攻击的远程控制程序,并且已经使用不同的隧道协议为其工具集(来源:Palo Alto Networks’ Unit 42 research team)。DNS Tunneling技术已经很成熟了,实现工具类似dns2tcp、iodine、dnscat2等也很多,包括Cobalt Strike以及MSF中也都有相应的模块。将数据封装在DNS协议中传输建立隐蔽通信隧道已经是高级威胁团伙的标配工具,DNS的无处不在(以及经常缺乏安全审计)可以实现非常优雅和微妙的方法来进行通信和共享数据滥用,超出了协议的初衷。DNS隧道存在延迟加密、跨平台、动静小的特点,但存在不稳定及速度慢等特点,因此相比于其他的隧道技术,它更适合在高度安全目标环境中穿透内网所用,红队在评估过程的有限时间内也可以选择性使用DNS隧道来维持攻击链不被蓝队斩断。

此次泄漏工具当中涉及到的远控工具就是一些开源情报中提到的BOUNDUPDATER,OilRig内部分为老版本PoisonFrog和新版本Glimpse,这可能是目前已知的最完整的APT34项目,除了依靠DNS协议外还依靠文件系统来完成命令控制和数据传输,这是一个非常不寻常的通信解决方案,本文将对两款工具进行简单分析并尝试完成攻击功能还原。

 

0x03  Glimpse项目

泄漏Glimpse项目文件列表如下

├── Glimpse
│   ├── Agent
│   │   ├── dns.ps1
│   │   ├── dns_main.ps1
│   │   ├── refineddns_main.ps1
│   │   └── runner_.vbs
│   ├── Read\ me.txt
│   ├── panel
│   │   ├── ToggleSwitch.dll
│   │   └── newPanel-dbg.exe
│   └── server
│   └── srvr.js

Readme.txt为项目部署说明文件

runner_.vbs脚本用来启动当前目录下的PowerShell脚本文件,需要配合其他Execution方法去启动执行,dns.ps1dns_main.ps1refineddns_main.ps1三个脚本文件功能基本一致,另外两个文件在dns_main.ps1的基础上做了变量名混淆,sacr.js使用nodejs开发作为服务端提供DNS服务用于与agent的交互,交互过程大致如下:

Agent部分$aa_domain_bb变量为需要向C2充当权威域名服务器去查询的主域名(默认为example.com)。函数aa_ping_response_bbaa_text_response_bb将数据编码后以PING或者TEXT的方式完成DNS正向和反向解析请求,期间使用IP99.250.250.199来判断,用来传输不同的信息。

客户端agent最初创建文件夹%public%\Libraries并判断lock是否存在,如果不存在,创建文件并写入当前powershell进程的pid;如果文件存在,读取文件创建时间,如果距离现在的时间超过10分钟,那么会退出进程并删除lock文件,然后生成识别agent目标系统的标识符,并写入文件%public%\Libraries\quid

通信管理功能由agent端aa_AdrGen_bb完成,它实现控制发送和接收信息。解码的action类型存储在变量aa_act_bb中,从服务端可以看出包括:

  • Action M:如果代理已经注册到C2,则此命令的作用类似于ping,它会将基本信息更新到相应的agent文件夹。如果是agent第一次回连C2,服务端会去创建相应的文件夹去存放等待、接受不了、完成的命令和发送和已发送的信息;
  • Action W:等待需要执行命令的TXT请求,在注册阶段之后执行的第一个命令是标记为10100的命令,其内容为:“whoami&ipconfig / all”(泄漏文件中dns_main.ps1文件错误将Action W 写为P:$aa_change_receive_mode_address_bb = aa_AdrGen_bb “000” “P” “” “” “r” $rn
  • Action D:等待需要执行命令的TXT请求。将标记的任务作为输入,并将其转发到请求agent的文件的Base64编码内容。
  • Action 0 此请求使权威DNS(C2)向agent响应wait文件夹中的请求文件。如果没有文件在wait文件夹中,则C2响应返回ip(11.24.237.110)的A记录,如果有文件,C2响应字段“24.125”的A记录值(“24.125.” + fileNameTmp.substring(0, 2) + “.” + fileNameTmp.substring(2, 5) )
  • Action 1 此请求使权威DNS(C2)向agent响应文件内容。根据RFC4408,它实现了一个多应答链,用于发送大于255个字符的文件。
  • Action 2 此请求使权威DNS(C2)从agent接收文件。发送完所有数据后,agent将发出带有“COCTabCOCT”的最终DNS查询。此查询通知C2服务器agent已完成信息发送。

此过程当中agent会创建以下文件夹,运行情况如下图所示

%public%\Libraries\files
%public%\Libraries\<agentid>
%public%\Libraries\<agentid>\reveivebox
%public%\Libraries\<agentid>\sendbox
%public%\Libraries\<agentid>\done

服务端程序在此过程当中会在/Glimpse/dns/agentid/目录下创建wait、receive、done、sended、sending等子文件夹,通过这些子目录下的文件读写来实现与agent的通信。Server端srvr.js运行情况如下图所示

整个过程当中的流量内容


Panel部分为Glimpse项目图形化控制界面,包括显示agent上线列表、命令执行、文件上传下载、查看执行结果、切换DNS请求方式、 刷新等功能

为防止工具被二次恶意利用,这里不提供项目的具体搭建方法。

该工具的公开线索

 

0x04  PoisonFrog项目

泄漏PoisonFrog项目包含两个版本,主要是agent部分poisonfrog.ps1文件内容不一致,项目文件列表如下

├── posionfrog
│   ├── agent
│   │   └── poisonfrog.ps1
│   └── serverside
│   ├── 0000000000.bat
│   ├── 9999999999.bat
│   ├── config.json
│   ├── installing
│   │   ├── filesList
│   │   ├── install_pachages.bat
│   │   ├── installing\ mongo_nodejs
│   │   └── stop\ dnsmasq
│   ├── routes
│   │   └── index.js
│   └── views
│   ├── agents.ejs
│   ├── login.ejs
│   ├── notfound.ejs
│   ├── panel.html
│   └── result.ejs

PoisonFrog项目与FireEye在2017年12月公开的面相中东的攻击事件情报当中提到的BONDUPDATER程序有直接关联。
Poison Frog服务器端使用Nodejs开发,Poison Frog服务器端运行两个poisonfrog.ps1释放文件不一样,一个版本释放dUpdater.ps1和hUpdater.ps1,第二个版本多释放一个UpdateTask.vbs文件,该文件用来加载运行dUpdater.ps1和hUpdater.ps1两个PowerShell脚本,运行后同样依靠文件系统和上传下载完成与C2的交互,通过创建计划任务每10分钟执行一次agent。
该工具的公开线索

0x05  总结

此次泄漏PoisonFrog和Glimpse项目是多模块的远程控制工具,通过TTPs的分析我们可以大致确认泄漏工具和公开威胁情报当中对OilRig工具集的分析一致,但我们也看到项目文件存在缺失和编码错误(或被篡改)等情况。另外Glimpse项目的成功运行需要配合DNS劫持来完成,操作相对复杂,我们猜测该工具不会被大量滥用。还有值得注意的是DNS信息交互使用文件来存储信息并同步操作,这是一种不同寻常的实现方式,猜测可以实现许多panel同时控制C2,这个CobaltStrick的teamserver有异曲同工之妙,但技术实现上就差的比较多了。不管怎样此次泄漏或多或少都对红队对手技术模拟、威胁情报等方面提供了极大的价值。

0x06  参考

APT34攻击全本分析

 

 

关于M01N Team

绿盟科技M01N红队安全2017最新注册送体验团队专注于Red Team、APT等高级攻击技术、战术及威胁2017最新注册送体验,涉及WEB安全、终端安全、AD安全、云安全等相关领域。通过研判现网攻击技术发展方向,以攻促防,为风险识别及威胁对抗提供决策支撑,全面提升安全防护能力。

 

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/apt34-glimpsepoisonfrog/feed/ 0
【威胁通告】Adobe 5月安全更新 http://blog.cholochitro.com/adobe-security-update/ http://blog.nsfocus.net/adobe-security-update/#respond Wed, 15 May 2019 02:28:35 +0000 http://blog.cholochitro.com/?p=15090 当地时间5月14日,Adobe官方发布了5月安全更新,修复了Adobe 多款产品的多个漏洞,包括Adobe Flash player、Acrobat and Reader以及Media Encoder等。

官方通告地址:

https://helpx.adobe.com/security.html

漏洞概述

Adobe Flash Player

Adobe已发布Adobe Flash Player安全更新,修复了1个安全漏洞。

漏洞概括如下:

漏洞影响 严重程度 CVE编号
Arbitrary Code Execution Critical 2018年送彩金网站大全2019-7837
  • 受影响版本:

Adobe Flash player version <= 32.0.0.171

  • 不受影响版本:

Adobe Flash player version 32.0.0.192

关于漏洞的具体影响版本及修复情况,请参考Adobe官方安全通告:

https://helpx.adobe.com/security/products/flash-player/apsb19-26.html

Adobe Acrobat and Reader

Adobe已发布Adobe Acrobat and Reader安全更新,修复了多个安全漏洞。

漏洞概括如下:

漏洞影响 严重程度 CVE编号
Information Disclosure Important 2018年送彩金网站大全2019-7841

2018年送彩金网站大全2019-7836

2018年送彩金网站大全2019-7826

2018年送彩金网站大全2019-7819

2018年送彩金网站大全2019-7813

2018年送彩金网站大全2019-7812

2018年送彩金网站大全2019-7811

2018年送彩金网站大全2019-7810

2018年送彩金网站大全2019-7803

2018年送彩金网站大全2019-7802

2018年送彩金网站大全2019-7801

2018年送彩金网站大全2019-7799

2018年送彩金网站大全2019-7798

2018年送彩金网站大全2019-7795

2018年送彩金网站大全2019-7794

2018年送彩金网站大全2019-7793

2018年送彩金网站大全2019-7790

2018年送彩金网站大全2019-7789

2018年送彩金网站大全2019-7787

2018年送彩金网站大全2019-7780

2018年送彩金网站大全2019-7778

2018年送彩金网站大全2019-7777

2018年送彩金网站大全2019-7776

2018年送彩金网站大全2019-7775

2018年送彩金网站大全2019-7774

2018年送彩金网站大全2019-7773

2018年送彩金网站大全2019-7771

2018年送彩金网站大全2019-7770

2018年送彩金网站大全2019-7769

2018年送彩金网站大全2019-7758

2018年送彩金网站大全2019-7145

2018年送彩金网站大全2019-7144

2018年送彩金网站大全2019-7143

2018年送彩金网站大全2019-7142

2018年送彩金网站大全2019-7141

2018年送彩金网站大全2019-7140

Arbitrary Code Execution Critical 2018年送彩金网站大全2019-7829

2018年送彩金网站大全2019-7825

2018年送彩金网站大全2019-7822

2018年送彩金网站大全2019-7818

2018年送彩金网站大全2019-7804

2018年送彩金网站大全2019-7800

2018年送彩金网站大全2019-7820

2018年送彩金网站大全2019-7835

2018年送彩金网站大全2019-7834

2018年送彩金网站大全2019-7833

2018年送彩金网站大全2019-7832

2018年送彩金网站大全2019-7831

2018年送彩金网站大全2019-7830

2018年送彩金网站大全2019-7823

2018年送彩金网站大全2019-7821

2018年送彩金网站大全2019-7817

2018年送彩金网站大全2019-7814

2018年送彩金网站大全2019-7809

2018年送彩金网站大全2019-7808

2018年送彩金网站大全2019-7807

2018年送彩金网站大全2019-7806

2018年送彩金网站大全2019-7805

2018年送彩金网站大全2019-7797

2018年送彩金网站大全2019-7796

2018年送彩金网站大全2019-7792

2018年送彩金网站大全2019-7791

2018年送彩金网站大全2019-7788

2018年送彩金网站大全2019-7786

2018年送彩金网站大全2019-7785

2018年送彩金网站大全2019-7783

2018年送彩金网站大全2019-7782

2018年送彩金网站大全2019-7781

2018年送彩金网站大全2019-7772

2018年送彩金网站大全2019-7768

2018年送彩金网站大全2019-7767

2018年送彩金网站大全2019-7766

2018年送彩金网站大全2019-7765

2018年送彩金网站大全2019-7764

2018年送彩金网站大全2019-7763

2018年送彩金网站大全2019-7762

2018年送彩金网站大全2019-7761

2018年送彩金网站大全2019-7760

2018年送彩金网站大全2019-7759

2018年送彩金网站大全2019-7828

2018年送彩金网站大全2019-7827

2018年送彩金网站大全2019-7824

2018年送彩金网站大全2019-7784

2018年送彩金网站大全2019-7779

关于漏洞的具体影响版本及修复情况,请参考Adobe官方安全通告:

https://helpx.adobe.com/security/products/acrobat/apsb19-18.html

Adobe Media Encoder

Adobe已发布Adobe Media Encoder安全更新,修复了2个安全漏洞。

漏洞概括如下:

漏洞影响 严重程度 CVE编号
Remote Code Execution Critical 2018年送彩金网站大全2019-7842
Information Disclosure Important 2018年送彩金网站大全2019-7844
  • 受影响版本:

Adobe Media Encoder 13.0.2

  • 不受影响版本:

Adobe Media Encoder 13.1

关于漏洞的具体影响版本及修复情况,请参考Adobe官方安全通告:

https://helpx.adobe.com/security/products/media-encoder/apsb19-29.html

解决方案

Adobe官方已经发布新版本修复了上述漏洞,用户应及时升级进行防护。

详细信息及操作可参考各产品漏洞部分的官方通告链接。

声明

本安全2018博彩游戏网站大全仅用来描述可能存在的安全问题,绿盟科技不为此安全2018博彩游戏网站大全提供任何保证或承诺。由于传播、利用此安全2018博彩游戏网站大全所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,绿盟科技以及安全2018博彩游戏网站大全作者不为此承担任何责任。绿盟科技拥有对此安全2018博彩游戏网站大全的修改和解释权。如欲转载或传播此安全2018博彩游戏网站大全,必须保证此安全2018博彩游戏网站大全的完整性,包括版权声明等全部内容。未经绿盟科技允许,不得任意修改或者增减此安全2018博彩游戏网站大全内容,不得以任何方式将其用于商业目的。

 

关于绿盟科技

北京神州绿盟信息安全科技股份有限公司(简称绿盟科技)成立于2000年4月,总部位于北京。在国内外设有30多个分支机构,为政府、运营商、金融、能源、互联网以及教育、医疗等行业用户,提供具有核心竞争力的安全产品及解决方案,帮助客户实现业务的安全顺畅运行。

基于多年的安全攻防2017最新注册送体验,绿盟科技在网络及终端安全、互联网基础安全、合规及安全管理等领域,为客户提供入侵检测/防护、抗拒绝服务攻击、远程安全评估以及Web安全防护等产品以及专业安全服务。

北京神州绿盟信息安全科技股份有限公司于2014年1月29日起在深圳证券交易所创业板上市交易,股票简称:绿盟科技,股票代码:300369。

 

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/adobe-security-update/feed/ 0
【威胁通告】微软发布5月补丁修复82个安全问题 http://blog.cholochitro.com/microsoft-released-patch-fix-82-security-issues/ http://blog.nsfocus.net/microsoft-released-patch-fix-82-security-issues/#respond Wed, 15 May 2019 02:15:31 +0000 http://blog.cholochitro.com/?p=15084 微软于周二发布了5月安全更新补丁,修复了82个从简单的欺骗攻击到远程执行代码的安全问题,产品涉及.NET Core、.NET Framework、Adobe Flash Player、Azure、Internet Explorer、Kerberos、Microsoft Browsers、Microsoft Dynamics、Microsoft Edge、Microsoft Graphics Component、Microsoft JET Database Engine、Microsoft Office、Microsoft Office SharePoint、Microsoft Scripting Engine、Microsoft Windows、NuGet、Servicing Stack Updates、Skype for Android、SQL Server、Team Foundation Server、Windows DHCP Server、Windows Diagnostic Hub、Windows Kernel、Windows NDIS以及Windows RDP。

相关信息

相关信息如下:

产品 CVE 编号 CVE 标题 严重程度
.NET Core 2018年送彩金网站大全2019-0980 .Net Framework and .Net Core 拒绝服务漏洞 Important
.NET Core 2018年送彩金网站大全2019-0981 .Net Framework and .Net Core 拒绝服务漏洞 Important
.NET Core 2018年送彩金网站大全2019-0982 ASP.NET Core 拒绝服务漏洞 Important
.NET Framework 2018年送彩金网站大全2019-0820 .NET Framework and .NET Core 拒绝服务漏洞 Important
.NET Framework 2018年送彩金网站大全2019-0864 .NET Framework 拒绝服务漏洞 Important
Adobe Flash Player ADV190012 May 2019 Adobe Flash 安全更新 Critical
Azure 2018年送彩金网站大全2019-1000 Microsoft Azure AD Connect 特权提升漏洞 Important
Internet Explorer 2018年送彩金网站大全2019-0921 Internet Explorer 欺骗漏洞 Important
Internet Explorer 2018年送彩金网站大全2019-0929 Internet Explorer 内存破坏漏洞 Critical
Internet Explorer 2018年送彩金网站大全2019-0930 Internet Explorer 信息泄露漏洞 Important
Internet Explorer 2018年送彩金网站大全2019-0995 Internet Explorer 安全功能绕过漏洞 Important
Kerberos 2018年送彩金网站大全2019-0734 Windows 特权提升漏洞 Important
Microsoft Browsers 2018年送彩金网站大全2019-0940 Microsoft Browser 内存破坏漏洞 Critical
Microsoft Dynamics 2018年送彩金网站大全2019-1008 Microsoft Dynamics On-Premise Security Feature Bypass Important
Microsoft Edge 2018年送彩金网站大全2019-0926 Microsoft Edge 内存破坏漏洞 Critical
Microsoft Edge 2018年送彩金网站大全2019-0938 Microsoft Edge 特权提升漏洞 Important
Microsoft Graphics Component 2018年送彩金网站大全2019-0882 Windows GDI 信息泄露漏洞 Important
Microsoft Graphics Component 2018年送彩金网站大全2019-0892 Win32k 特权提升漏洞 Important
Microsoft Graphics Component 2018年送彩金网站大全2019-0903 GDI+ 远程代码执行漏洞 Critical
Microsoft Graphics Component 2018年送彩金网站大全2019-0961 Windows GDI 信息泄露漏洞 Important
Microsoft Graphics Component 2018年送彩金网站大全2019-0758 Windows GDI 信息泄露漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0893 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0894 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0895 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0896 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0897 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0898 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0899 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0900 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0901 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0902 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0889 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0890 Jet Database Engine 远程代码执行漏洞 Important
Microsoft JET Database Engine 2018年送彩金网站大全2019-0891 Jet Database Engine 远程代码执行漏洞 Important
Microsoft Office 2018年送彩金网站大全2019-0945 Microsoft Office Access Connectivity Engine 远程代码执行漏洞 Important
Microsoft Office 2018年送彩金网站大全2019-0946 Microsoft Office Access Connectivity Engine 远程代码执行漏洞 Important
Microsoft Office 2018年送彩金网站大全2019-0947 Microsoft Office Access Connectivity Engine 远程代码执行漏洞 Important
Microsoft Office 2018年送彩金网站大全2019-0953 Microsoft Word 远程代码执行漏洞 Critical
Microsoft Office SharePoint 2018年送彩金网站大全2019-0956 Microsoft SharePoint Server 信息泄露漏洞 Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0957 Microsoft SharePoint 特权提升漏洞 Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0958 Microsoft SharePoint 特权提升漏洞 Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0963 Microsoft Office SharePoint XSS Vulnerability Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0949 Microsoft SharePoint 欺骗漏洞 Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0950 Microsoft SharePoint 欺骗漏洞 Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0951 Microsoft SharePoint 欺骗漏洞 Important
Microsoft Office SharePoint 2018年送彩金网站大全2019-0952 Microsoft SharePoint Server 远程代码执行漏洞 Important
Microsoft Scripting Engine 2018年送彩金网站大全2019-0884 Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0911 Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0912 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0913 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0914 Chakra Scripting Engine 内存破坏漏洞 Moderate
Microsoft Scripting Engine 2018年送彩金网站大全2019-0915 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0916 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0917 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0918 Scripting Engine 内存破坏漏洞 Moderate
Microsoft Scripting Engine 2018年送彩金网站大全2019-0922 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0923 Chakra Scripting Engine 内存破坏漏洞 Important
Microsoft Scripting Engine 2018年送彩金网站大全2019-0924 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0925 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0927 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0933 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Scripting Engine 2018年送彩金网站大全2019-0937 Chakra Scripting Engine 内存破坏漏洞 Critical
Microsoft Windows 2018年送彩金网站大全2019-0863 Windows Error Reporting 特权提升漏洞 Important
Microsoft Windows 2018年送彩金网站大全2019-0886 Windows Hyper-V 信息泄露漏洞 Important
Microsoft Windows 2018年送彩金网站大全2019-0942 Unified Write Filter 特权提升漏洞 Important
Microsoft Windows 2018年送彩金网站大全2019-0733 Windows Defender Application Control 安全功能绕过漏洞 Important
Microsoft Windows 2018年送彩金网站大全2019-0885 Windows OLE 远程代码执行漏洞 Important
Microsoft Windows 2018年送彩金网站大全2019-0931 Windows Storage Service 特权提升漏洞 Important
Microsoft Windows ADV190013 Microsoft Guidance to mitigate Microarchitectural Data Sampling vulnerabilities Important
Microsoft Windows 2018年送彩金网站大全2019-0936 Windows 特权提升漏洞 Important
NuGet 2018年送彩金网站大全2019-0976 NuGet Package Manager Tampering Vulnerability Important
Servicing Stack Updates ADV990001 Latest Servicing Stack Updates Critical
Skype for Android 2018年送彩金网站大全2019-0932 Skype for Android 信息泄露漏洞 Important
SQL Server 2018年送彩金网站大全2019-0819 Microsoft SQL Server Analysis Services 信息泄露漏洞 Important
Team Foundation Server 2018年送彩金网站大全2019-0971 Azure DevOps Server and Team Foundation Server 信息泄露漏洞 Important
Team Foundation Server 2018年送彩金网站大全2019-0872 Azure DevOps Server and Team Foundation Server Cross-site Scripting Vulnerability Important
Team Foundation Server 2018年送彩金网站大全2019-0979 Azure DevOps Server and Team Foundation Server Cross-site Scripting Vulnerability Important
Windows DHCP Server 2018年送彩金网站大全2019-0725 Windows DHCP Server 远程代码执行漏洞 Critical
Windows Diagnostic Hub 2018年送彩金网站大全2019-0727 Diagnostic Hub Standard Collector, Visual Studio Standard Collector 特权提升漏洞 Important
Windows Kernel 2018年送彩金网站大全2019-0881 Windows Kernel 特权提升漏洞 Important
Windows NDIS 2018年送彩金网站大全2019-0707 Windows NDIS 特权提升漏洞 Important
Windows RDP 2018年送彩金网站大全2019-0708 Remote Desktop Services 远程代码执行漏洞 Critical

 

修复建议

微软官方已经发布更新补丁,请及时进行补丁更新。

附件

微软发布5月补丁修复82个安全问题

 

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/microsoft-released-patch-fix-82-security-issues/feed/ 0
【预警通告】微软远程桌面服务(Remote Desktop Services)远程代码执行漏洞2018年送彩金网站大全2019-0708 http://blog.cholochitro.com/2018年送彩金网站大全2019-0708/ http://blog.nsfocus.net/2018年送彩金网站大全2019-0708/#respond Wed, 15 May 2019 02:00:26 +0000 http://blog.cholochitro.com/?p=15080 当地时间5月14日,微软发布的5月份月度更新中修复了一个存在于远程桌面服务中(Remote Desktop Services)的高危远程代码执行漏洞(2018年送彩金网站大全2019-0708),RDP协议本身不受影响。该漏洞可以被蠕虫类攻击利用,建议受影响用户尽快下载补丁升级进行防护。

受影响的版本

  • Windows 7
  • Windows Server 2008 R2
  • Windows Server 2008
  • Windows Server 2003
  • Windows XP

注:其中Windows Server 2003以及Windows XP已经不再受支持,但此次仍会发布对应的漏洞补丁

不受影响的版本

  • Windows 8
  • Windows 10

解决方案

在微软发布的5月更新中已经修复了该漏洞,建议用户尽快升级进行防护。

参考链接:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/2018年送彩金网站大全2019-0708

声 明

本安全2018博彩游戏网站大全仅用来描述可能存在的安全问题,绿盟科技不为此安全2018博彩游戏网站大全提供任何保证或承诺。由于传播、利用此安全2018博彩游戏网站大全所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,绿盟科技以及安全2018博彩游戏网站大全作者不为此承担任何责任。绿盟科技拥有对此安全2018博彩游戏网站大全的修改和解释权。如欲转载或传播此安全2018博彩游戏网站大全,必须保证此安全2018博彩游戏网站大全的完整性,包括版权声明等全部内容。未经绿盟科技允许,不得任意修改或者增减此安全2018博彩游戏网站大全内容,不得以任何方式将其用于商业目的。

 

关于绿盟科技

北京神州绿盟信息安全科技股份有限公司(简称绿盟科技)成立于2000年4月,总部位于北京。在国内外设有30多个分支机构,为政府、运营商、金融、能源、互联网以及教育、医疗等行业用户,提供具有核心竞争力的安全产品及解决方案,帮助客户实现业务的安全顺畅运行。

基于多年的安全攻防2017最新注册送体验,绿盟科技在网络及终端安全、互联网基础安全、合规及安全管理等领域,为客户提供入侵检测/防护、抗拒绝服务攻击、远程安全评估以及Web安全防护等产品以及专业安全服务。

北京神州绿盟信息安全科技股份有限公司于2014年1月29日起在深圳证券交易所创业板上市交易,股票简称:绿盟科技,股票代码:300369。

 

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/2018年送彩金网站大全2019-0708/feed/ 0
绿盟科技等级保护2.0系列解决方案正式发布 http://blog.nsfocus.net/nsfocus-hierarchical-protection-2-0-series-solutions-officially-released/ http://blog.nsfocus.net/nsfocus-hierarchical-protection-2-0-series-solutions-officially-released/#respond Tue, 14 May 2019 10:23:56 +0000 http://blog.cholochitro.com/?p=15076 根据《网络安全法》规定“国家实行网络安全等级保护制度”,等级保护作为我国在网络安全方面的基本制度将长期实行下去。同时,为了解决新技术、新应用的安全问题,等级保护2.0系列标准进行了修订并正式对外发布。国家相关法律、法规和标准的发布,让新时期的等级保护建设跨入快车道。

绿盟科技作为等级保护安全建设服务机构,始终践行网络安全等级保护。在等级保护2.0时代,绿盟科技将多年积累的安全能力和等级保护系列标准相结合,推出《绿盟科技等级保护2.0系列解决方案》。方案通过建设“一个中心”管理下的“安全通信网络、安全区域边界、安全计算环境”,为行业单位构建网络安全纵深防御体系。

 

绿盟科技等级保护2.0系列解决方案不仅满足行业单位等保合规需求,同时依托现有安全服务体系,支撑行业单位和主管部门进行持续监测、预警和应急处置,提升行业单位的综合防御能力。

绿盟科技等级保护解决方案整体框架

 

绿盟科技等级保护2.0场景化方案

绿盟科技等级保护2.0系列解决方案,在分析保护对象面临的安全风险基础上,结合安全通用要求和安全扩展要求,将安全技术体系、安全管理体系、安全服务体系融入到方案设计中。形成绿盟科技等级保护2.0安全通用场景方案、云计算安全方案、工控系统等方案。

方案充分考虑行业特性,在安全设计中以行业安全需求为导向,把等级保护应用到行业安全防护中,帮助行业单位落实网络安全等级保护制度。

解决方案价值

  • 省时、省心、省力的等保全流程解决方案

绿盟科技提供等级保护2.0全流程解决方案,在定级、备案、建设整改、等级测评、安全运营阶段,提供专业的等保咨询服务、安全防护产品、安全技术服务、安全运营服务,让单位在等级保护建设中省时、省心、省力。

2、提供协同安全运营,提高单位安全监测预警与应急处置能力

绿盟科技等级保护2.0系列方案,提供协同安全运营,帮助单位形成比较成熟的监测预警体系,同时依托安全管理平台,建设符合单位现状的安全应急和处置服务体系,通过协同安全运营可以使单位建立网络安全服务队伍,增强单位对安全事件分析、处置的能力。

 

3、为关键信息基础设施防护奠定基础

关键信息基础设施防护是网络安全等级保护的防护重点,绿盟科技等级保护2.0系列方案,针对关键信息基础设施防护的特殊性,在安全风险识别、安全防护、检测评估、监测预警、应急处置方面,解决关键信息基础防护的通用性安全问题,为关键信息基础设施奠定防护基础。

 

4、等保场景覆盖全面,满足不同行业客户等保要求

方案覆盖安全通用、云计算、工控系统等场景,针对不同的行业客户,绿盟科技提供符合其自身行业特性的解决方案,满足行业单位等保合规要求。

文章来源:绿盟科技博客
]]>
http://blog.nsfocus.net/nsfocus-hierarchical-protection-2-0-series-solutions-officially-released/feed/ 0
美国能源部2019年Q1电力应急和故障报告解读 http://blog.cholochitro.com/interpretation-q1-power-emergency-fault-report-department-energy-2019/ http://blog.nsfocus.net/interpretation-q1-power-emergency-fault-report-department-energy-2019/#respond Tue, 14 May 2019 09:00:45 +0000 http://blog.cholochitro.com/?p=15070 2019年4月,美国能源部(DOE)发布2019年Q1电力应急和故障报告,出2019年第一季度发生系统故障次数62次,产生的电力损失高达135019兆瓦,影响客户数超过250万。美国电力保障由北美电力可靠性公司(NERC)进行承担,其为一个非营利性国际监管机构,使命是确保有效和高效地降低电网可靠性和安全性的风险。

2019年Q1电力应急和故障报告(PDF: https://www.oe.netl.doe.gov/download.aspx?type=OE417PDF&ID=79 / XLS: https://www.oe.netl.doe.gov/download.aspx?type=OE417XLS&ID=79 )

美国电力保障由北美电力可靠性公司(NERC)进行承担,其为一个非营利性国际监管机构,使命是确保有效和高效地降低电网可靠性和安全性的风险。

北美电力可靠性公司(NERC)的主要职责如下:

  • 制定并实施可靠性标准
  • 每年评估季节性和长期可靠性
  • 通过系统实时监控大容量电力系统
  • 教育,培训和认证行业人员

北美电力可靠性公司(NERC)的责任范围跨越美国大陆,加拿大和墨西哥下加利福尼亚州北部,受联邦能源监管委员会(FERC)和加拿大政府部门的监督。其下属区域单位分布以及管理范围如下:

图片来自:https://www.nerc.com/AboutNERC/keyplayers/Pages/default.aspx

 

备注:西南电力池区域实体(SPP RE)已经于2017年7月获批解散,并于2018年12月31日前完成将其业务转让给中西部可靠性组织(MRO)和电监会可靠性公司(SERC)。

针对各电力保障单位保障区域发生的失效故障次数进行分析发现西部电力协调委员会(WECC)负责的区域故障数最高,详细的各区域如下:

北美电力可靠性公司(NERC)针对故障的告警标准如下:

告警标准 告警内容
故障可在一小时内修复 1.   对关键基础设施或运营造成重大中断或影响的物理攻击。

2.   引起电气系统运行中断的网络事件。

3.   传输或配电电气系统运行故障或关闭。

4.   电气系统分离(孤岛),部分在受影响的情况下仍能正常运行。

5.   单次超过15分钟的故障造成的电力损失超过300兆瓦。

6.   根据应急政策减少负荷超过100兆瓦的负载。

7.   全系统电压降低超过3%。

8.   公众呼吁减少用电,维持大容量电力系统的稳定工作。

故障可在六个小时内修复 9.   针对电力系统的充分性和可靠性以及任何安全系统组件的物理攻击。

10. 影响电力系统充分性或可靠性的网络事件。

11. 超过五万客户失去电力供应服务超过1小时。

12. 影响电力系统充分性或可靠性的燃料供给异常。

故障修复时间超过六个小时 13. 由于区域设施损坏或破坏,导致采取行动避免大规模电力系统紧急情况。

14. 人为损坏或毁坏相关设施。

15. 非自然因素导致的(物理威胁)设备性能降低或者异常运行。

16. 人为损坏或毁坏大型电力系统控制中心的物理威胁。

17. Bulk Electric System Emergency导致电压偏差超过10%且持续时间连续超过15分钟。

18. 前一年峰值需求小于或等于3,000兆瓦的实体,单次故障超过15分钟且损失电力超过200兆瓦。

19. 一分钟内,东部与西部互连接超过2000兆瓦或在ERCOT互连中超过1,400兆瓦。

20. 完全丧失影响核发电站的场外电力。

21. 由于共同干扰导致超过三个大型电力系统设施发生意外传输损失。

22. 非计划的从Bulk Electric System control疏散超过30分钟。

23. 与Bulk Electric System控制中心失去通讯能力超过30多分钟。

24. Bulk Electric System控制中心完全丧失监控和控制能力超过30多分钟。

此部分来源于:https://www.oe.netl.doe.gov/docs/OE417_Form_Instructions_05312021.docx

依据不同告警描述对发生的故障事件进行分析,各告警描述对应的故障数分布如下:

根据上图可以看出超过5万用户失去电力服务超过1小时的故障出现的次数最多。排查故障并进行修复需要一定的时间,根据北美电力可靠性公司(NERC)的告警标准,对不同修复阶段的故障数如下:

从分布图可以看出,能够在6小时内完成故障修复的故障数占据总故障数的50%,6小时以外可以恢复的故障数次之,能够在1小时以内进行故障恢复的故障数最少。

电力设施发生故障的因素如下:

美国能源部发布的应急与故障报告中根据故障发生原因如下:

通过对电力故障产生的原因分析发现,除了自然因素导致的设备异常、能源供应等问题外,占比较高的是人为操作(包括误操作、恶意破坏、恶意操作、网络攻击等)。

美国能源部发布的应急与故障报告中并未明确指出电力故障是由于网络攻击造成的,但是美国对相关行业的操作标准具备明确的要求,因此在人为因素里面排除了内部人员的误操作和恶意操作,同时由于报告中的告警描述中多数为电力系统无法提供服务,因此推断电力系统是由于受到网络攻击而发生了拒绝服务。

报道能源和环境新闻的 E&E News 从美国能源部官员处了解到,电力系统故障涉及到拒绝服务攻击(DoS),该攻击并不属于有组织黑客行动,所涉拒绝服务(DoS)漏洞也有补丁可打,攻击具体针对哪类设备尚未查明。这也从侧面印证了电力系统出现故障的原因为网络攻击。

总之,工业控制系统对于实时性和可靠性要求相对比较高,拒绝服务(DoS)对工业控制系统造成的影响会比较高,工控行业也是恶意黑客的重要目标,因此在进行工业控制系统实施时需要考虑自然、设备、人为、传输等方方面面的因素,以保证相关设备和业务的稳定运行。根据美国能源部发布的应急与故障报告以及绿盟科技多年来在工控行业的业务经验,建议方案如下:

故障向量 建议方案
自然因素 温度:保证设备运行在厂商建议的温度范围内。
湿度:保证设备运行在厂商建议的湿度范围内。
粉尘:增加除尘设备或者使用三防设备。
能源:根据自然环境调节能源的补给与存储,保障能源供应。
地质:建站最好选择在非地震带,能源与数据实现异地双工。
洪涝:建站需要考虑设备的位置,避免洪涝灾害的影响。
蚊虫:运行环境需要具备蚊虫的隔离网,减少蚊虫对设备的影响。
设备因素 实时监控设备的运行状态,在设备进行异常告警时提前排查处理。
定期进行设备维护,减轻自然因素对设备的老化影响程度,保证设备符合运行可靠性要求。
设备上线前进行安全测试,防止设备存在安全缺陷。
提前做好设备故障的应急预案,故障发生时可以通过紧急维修/更换设备等方式及时恢复系统,减少损失。
定期通过远程评估系统发现工业控制系统缺陷,协调资源进行缺陷修复。
安排值守/巡检岗位,及时发现并处理故障。
提前进行设备老化/换代处理。
人为因素 增加工作站人员工作指导书,规范操作流程。
针对人员对设备的操作进行审计,及时发现误操作和恶意操作。
IT系统内主机/服务器增加安全软件。
对不同功能域进行划分并增加访问控制策略。
门禁系统部署生物识别技术,防止非授权人员的随意进入。
系统内增加网络安全防护设备,减少系统因为误操作/恶意网络攻击造成的影响。
针对敏感数据的存储和传输,利用加密和压缩技术进行保护,数据实现认证访问。
账户使用强密码或者证书进行认证。
在非必要的情况下关闭例如telnet、ssh、远程桌面等风险服务。
定期培养人员的安全意识和能力,做到知行合一。
针对第三方运维人员接入,需要引入风控机制,减少运维造成的系统故障的风险。
增加对外开放服务(站点/工单等)的安全监控和防护方案。
针对资产的病毒/漏洞管理、补丁管理、配置管理等,形成统一的安全措施分发机制。
按照“谁主管,谁负责,谁运营,谁负责,谁接入,谁负责”的原则强化岗位责任。
通过强加密套件、强认证功能、准入策略实现网络接入,尽量避免使用无线网络接入。
传输因素 定期线路检修,保障线路传输质量。
提前做好线路故障的应急预案,故障发生时可以通过紧急维修/更换等方式及时恢复线路,减少损失。
传输线路增加状态上报机制,提前/快速发现并定位线路故障点。
选择比较可靠的传输线路材料,保障线路传输稳定。
信息网、监控网与生产网之间利用隔离设备实现单向传输。
排查无线网络范围内的干扰源,保证无线传输质量。
高可靠性网络实现双线传输。
提前进行线路扩容,满足业务/系统增长需求。

 

绿盟科技格物实验室专注于工业互联网、车联网、物联网等方面的安全2017最新注册送体验,曾发现多款工业物联网设备安全漏洞,协助厂商进行安全修复。多次参与国内外知名安全会议并发表专题演讲。积极与相关的厂商进行合作,共同努力创建和谐、稳定的网络安全生态环境

 

 

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/interpretation-q1-power-emergency-fault-report-department-energy-2019/feed/ 0
绿盟科技互联网安全威胁周报NSFOCUS-19-19 http://blog.cholochitro.com/nsfocus-19-19/ http://blog.nsfocus.net/nsfocus-19-19/#respond Tue, 14 May 2019 06:05:54 +0000 http://blog.cholochitro.com/?p=15068 绿盟科技发布了本周安全通告,周报编号NSFOCUS-19-19, 绿盟科技漏洞库 本周新增48条,其中高危13条。本次周报建议大家关注Apache Karaf 任意文件覆盖漏洞,Apache Karaf 4.2.5之前版本存在一个漏洞,允许攻击者在受影响应用的上下文中覆写任意文件或执行任意命令。目前厂商已经提供补丁程序,请到厂商的相关页面下载补丁。

焦点漏洞

Apache Karaf 任意文件覆盖漏洞

  • CVE ID
    • 2018年送彩金网站大全2019-0226
  • NSFOCUS ID
    • 43224
  • 受影响版本
    • Apache Group Karaf < 4.2.5
  • 漏洞点评
    • Apache Karaf是美国阿帕奇(Apache)软件基金会的一款用于部署应用程序和组件的轻量级的OSGi(Java动态化模块化系统)容器。 Apache Karaf 4.2.5之前版本存在一个漏洞,允许攻击者在受影响应用的上下文中覆写任意文件或执行任意命令。目前厂商已经提供补丁程序,请到厂商的相关页面下载补丁。

(数据来源:绿盟威胁情报中心)

一. 互联网安全威胁态势

1.1 CVE

最近一周CVE2018博彩游戏网站大全总数与前期相比有明显减少。

1.2 威胁信息回顾

  • 标题:SQLite中发现了一个远程代码执行漏洞
    • 时间:2019-05-11
    • 简介:在SQLite中发现了一个use-after-free()的漏洞,攻击者可利用该漏洞远程执行受影响设备上的代码,通过向易受攻击的安装发送恶意SQL命令来触发此漏洞。SQLite是一个C语言库,它实现了一个小型,快速,自包含,高可靠性,功能齐全的SQL数据库引擎。SQLite的 它被认为是世界上使用最多的数据库引擎,它内置于移动电话和大多数计算机中,并用于无数其他应用程序。
    • 链接:https://securityaffairs.co/wordpress/85354/hacking/sqlite-rce.html
  • 标题:Yoroi网络安全2018年度报告
    • 时间:2019-05-13
    • 简介:《Yoroi网络安全2018年度报告》提到2018年,网络安全专家观察到网络攻击数量增加,恶意软件成为最具攻击性和普遍性的威胁。Yoroi网络安全2018年度报告分析了2018年1月至2018年12月期间观察到的威胁形势的演变。
    • 链接:https://securityaffairs.co/wordpress/85439/malware/yoroi-cyber-security-annual-report-2018.html
  • 标题:Turla组织利用LightNeuron后门发起攻击活动
    • 时间:2019-05-07
    • 简介:近日发现俄罗斯间谍组织Turla使用后门LightNeuron来控制通过Exchange电子邮件服务器的所有内容。Turla(又名Snake、Waterbug、WhiteBear、VENOMOUS BEAR和Krypton)是一个来自俄罗斯的威胁组织,最早可追溯到2004年,主要针对欧洲、中亚和中东的政府和外交实体,曾在2008年侵入美国国防部(Department of Defense)和2014年侵入瑞士国防等主要机构,近期包括法国和捷克共和国在内的几个欧洲国家公开谴责Turla对其政府的攻击。
    • 链接:https://www.welivesecurity.com/wp-content/uploads/2019/05/ESET-LightNeuron.pdf
  • 标题:朝鲜黑客Hidden Cobra使用ElectricFish泄露数据
    • 时间:2019-05-10
    • 简介:美国国土安全部(DHS)和联邦调查局发布了一份关于新版恶意软件的联合警报,这是一个多产的朝鲜APT黑客组织Hidden Cobra在野外积极使用的,对世界各地的媒体组织,航空航天,金融和关键基础设施部门发起网络攻击。该组织与2017年WannaCry勒索软件威胁、2014年索尼影视黑客攻击以及2016年SWIFT银行业务攻击相关。
    • 链接:https://thehackernews.com/2019/05/north-korean-hacking-tool.html
  • 标题:Microsoft SharePoint 2018年送彩金网站大全2019-0604漏洞在野外被利用
    • 时间:2019-05-11
    • 简介:威胁演员试图在野外攻击中利用2018年送彩金网站大全2019-0604 Microsoft Sharepoint漏洞。该2018年送彩金网站大全2019-0604漏洞是由SharePoint的失败验证的应用程序包的源标记引起了远程执行代码缺陷。攻击者可以通过将特制的SharePoint应用程序包上载到受影响的软件版本来利用该漏洞。
    • 链接:https://securityaffairs.co/wordpress/85324/breaking-news/ms-sharepoint-2018年送彩金网站大全2019-0604-flaw.html
  • 标题:ATM恶意软件ATMitch攻击俄罗斯银行
    • 时间:2019-05-07
    • 简介:ATM恶意软件ATMitch近期发现攻击俄罗斯银行,它被认为是针对银行业的高级攻击者武器库的一部分,该恶意软件在广泛的企业网络入侵后手动安装在受害者ATM上,使网络犯罪分子能够操纵机器上的现金提取流程。
    • 链接:https://blog.yoroi.company/research/atmitch-new-evidence-spotted-in-the-wild/
  • 标题:Google Chrome将针对在线跟踪引入改进的Cookie控件
    • 时间:2019-05-08
    • 简介:谷歌宣布计划在即将推出的Chrome网络浏览器版本中引入两个新的隐私和面向安全的功能。为了让用户能够阻止在线跟踪,Google宣布了两项新功能-改进的SameSite Cookie和指纹识别保护功能-谷歌将在今年晚些时候在Chrome网络浏览器中进行预览,Cookie(也称为HTTP Cookie或浏览器Cookie)是网站存储在您计算机上的一小段信息,它们可以在改善您的在线体验方面发挥重要作用。
    • 链接:https://thehackernews.com/2019/05/chrome-samesite-cookies.html
  • 标题:持续攻击从超过数百个购物网站窃取信用卡
    • 时间:2019-05-08
    • 简介:近期2017最新注册送体验人员透露正在进行的信用卡黑客攻击活动的细节,该活动目前正在窃取访问超过105个电子商务网站的客户的支付卡信息。在过去七个月监控恶意域名www.magento-analytics[.]com时,2017最新注册送体验人员发现攻击者已将此域上托管的恶意JS脚本注入数百个在线购物网站。
    • 链接:https://thehackernews.com/2019/05/magento-credit-card-hacking.html
  • 标题:美国向中国黑客收取2015年Anthem数据泄露费用
    • 时间:2019-05-09
    • 简介:美国司法部今天宣布对一名中国黑客和他的黑客团队成员提出指控,因为他们涉嫌参与2015年医疗保险巨头Anthem和其他三家未透露姓名的美国公司的大规模数据泄露。2015年,黑客设法侵犯了该国第二大健康保险公司Anthem,并窃取了超过8000万客户的个人信息,包括他们的社会安全号码,出生日期,电子邮件地址,住址,医疗识别号码,就业信息和收入数据,该事件是历史上最严重的数据泄露之一,该公司支付了创纪录的1.15亿美元罚款以解决美国的诉讼。
    • 链接:https://thehackernews.com/2019/05/chinese-hacker-anthem-breach.html
  • 标题:Microsoft Edge for Mac发布,包括浏览器保护
    • 时间:2019-05-07
    • 简介:在昨天的Microsoft Build 2019主题演讲中,我们看到了在macOS上运行的新Microsoft Edge的简要介绍。在与MS Build一起发布的博客文章中,微软声称macOS版本即将发布。
    • 链接:https://www.bleepingcomputer.com/news/microsoft/microsoft-edge-for-mac-leaked-includes-browser-protection/

(数据来源:绿盟科技 威胁情报中心 收集整理)

二. 漏洞2017最新注册送体验

2.1 漏洞库

截止到2019年5月10日,绿盟科技漏洞库已收录总条目达到43264条。本周新增漏洞记录48条,其中高危漏洞数量13条,中危漏洞数量33条,低危漏洞数量2条。

  • Oracle E-Business Suite 信息泄露漏洞(2018年送彩金网站大全2019-2640)
    • 危险等级:高
    • BID:107932
    • cve编号:2018年送彩金网站大全2019-2640
  • Citrix XenMobile Server验证绕过漏洞(2018年送彩金网站大全2018-18571)
    • 危险等级:中
    • BID:108081
    • cve编号:2018年送彩金网站大全2018-18571
  • systemd 本地权限提升漏洞(2018年送彩金网站大全2019-3844)
    • 危险等级:中
    • BID:108096
    • cve编号:2018年送彩金网站大全2019-3844
  • Apache Pluto 跨站脚本漏洞(2018年送彩金网站大全2019-0186)
    • 危险等级:中
    • BID:108091
    • cve编号:2018年送彩金网站大全2019-0186
  • Linux Kernel 拒绝服务漏洞(2018年送彩金网站大全2019-3900)
    • 危险等级:中
    • BID:108076
    • cve编号:2018年送彩金网站大全2019-3900
  • Linux Kernel ‘perf_event_open()’函数本地信息泄露漏洞(2018年送彩金网站大全2019-3901)
    • 危险等级:低
    • BID:89937
    • cve编号:2018年送彩金网站大全2019-3901
  • Pivotal Application Service远程权限提升漏洞(2018年送彩金网站大全2019-3798)
    • 危险等级:中
    • BID:108095
    • cve编号:2018年送彩金网站大全2019-3798
  • Dell EMC Open Manage System Administrator拒绝服务漏洞(2018年送彩金网站大全2019-3721)
    • 危险等级:高
    • BID:108092
    • cve编号:2018年送彩金网站大全2019-3721
  • Dell EMC Open Manage System Administrator目录遍历漏洞(2018年送彩金网站大全2019-3720)
    • 危险等级:中
    • BID:108092
    • cve编号:2018年送彩金网站大全2019-3720
  • Apache Solr认证绕过漏洞(2018年送彩金网站大全2018-11802)
    • 危险等级:中
    • BID:108078
    • cve编号:2018年送彩金网站大全2018-11802
  • dhcpcd 缓冲区溢出漏洞(2018年送彩金网站大全2019-11577)
    • 危险等级:高
    • BID:108090
    • cve编号:2018年送彩金网站大全2019-11577
  • dhcpcd 延迟攻击漏洞(2018年送彩金网站大全2019-11578)
    • 危险等级:中
    • BID:108090
    • cve编号:2018年送彩金网站大全2019-11578
  • dhcpcd 读缓冲区溢出漏洞(2018年送彩金网站大全2019-11579)
    • 危险等级:中
    • BID:108090
    • cve编号:2018年送彩金网站大全2019-11579
  • Linux Kernel竞争条件漏洞(2018年送彩金网站大全2019-11815)
    • 危险等级:高
    • BID:108283
    • cve编号:2018年送彩金网站大全2019-11815
  • Atlassian Confluence Server和Atlassian Data Center目录遍历漏洞(2018年送彩金网站大全2019-3398)
    • 危险等级:高
    • BID:108067
    • cve编号:2018年送彩金网站大全2019-3398
  • ProjectSend跨站点脚本漏洞(2018年送彩金网站大全2019-11533)
    • 危险等级:中
    • BID:108088
    • cve编号:2018年送彩金网站大全2019-11533
  • Ghostscript代码执行漏洞(2018年送彩金网站大全2018-16509)
    • 危险等级:高
    • BID:105122
    • cve编号:2018年送彩金网站大全2018-16509
  • Ghostscript代码执行漏洞(2018年送彩金网站大全2018-15910)
    • 危险等级:中
    • BID:105122
    • cve编号:2018年送彩金网站大全2018-15910
  • Oracle WebLogic Server反序列化远程命令执行漏洞(2018年送彩金网站大全2019-2725)
    • 危险等级:高
    • BID:108074
    • cve编号:2018年送彩金网站大全2019-2725
  • Ghostscript代码执行漏洞(2018年送彩金网站大全2018-15911)
    • 危险等级:中
    • BID:105122
    • cve编号:2018年送彩金网站大全2018-15911
  • Cloud Foundry cf-deployment代码注入漏洞(2018年送彩金网站大全2019-3801)
    • 危险等级:高
    • BID:108104
    • cve编号:2018年送彩金网站大全2019-3801
  • systemd本地权限提升漏洞(2018年送彩金网站大全2019-3843)
    • 危险等级:中
    • BID:108116
    • cve编号:2018年送彩金网站大全2019-3843
  • ProjectSend跨站脚本漏洞(2018年送彩金网站大全2019-11533)
    • 危险等级:中
    • BID:108088
    • cve编号:2018年送彩金网站大全2019-11533
  • IBM StoredIQ 开放式重定向漏洞(2018年送彩金网站大全2019-4166)
    • 危险等级:中
    • BID:108088
    • cve编号:2018年送彩金网站大全2019-4166
  • Moodle任意PHP代码执行漏洞(2018年送彩金网站大全2019-11631)
    • 危险等级:中
    • BID:108119
    • cve编号:2018年送彩金网站大全2019-11631
  • ImageMagick缓冲区溢出漏洞(2018年送彩金网站大全2019-11597)
    • 危险等级:中
    • BID:108102
    • cve编号:2018年送彩金网站大全2019-11597
  • ImageMagick缓冲区溢出漏洞(2018年送彩金网站大全2019-11598)
    • 危险等级:中
    • BID:108102
    • cve编号:2018年送彩金网站大全2019-11598
  • Rockwell Automation ControlLogix拒绝服务漏洞(2018年送彩金网站大全2019-10954)
    • 危险等级:高
    • BID:108118
    • cve编号:2018年送彩金网站大全2019-10954
  • Rockwell Automation ControlLogix缓冲区溢出漏洞(2018年送彩金网站大全2019-10952)
    • 危险等级:高
    • BID:108118
    • cve编号:2018年送彩金网站大全2019-10952
  • Citrix SD-WAN信息泄露漏洞(2018年送彩金网站大全2019-11550)
    • 危险等级:中
    • BID:108114
    • cve编号:2018年送彩金网站大全2019-11550
  • Cisco Web Security Appliance远程拒绝服务漏洞(2018年送彩金网站大全2019-1817)
    • 危险等级:中
    • BID:108130
    • cve编号:2018年送彩金网站大全2019-1817
  • Cisco Application Policy Infrastructure Controller本地权限提升漏洞(2018年送彩金网站大全2019-1682)
    • 危险等级:中
    • BID:108129
    • cve编号:2018年送彩金网站大全2019-1682
  • Cisco Nexus 9000 Series Fabric Switches安全限制绕过漏洞(2018年送彩金网站大全2019-1804)
    • 危险等级:中
    • BID:108127
    • cve编号:2018年送彩金网站大全2019-1804
  • Linux Kernel本地竞争条件漏洞(2018年送彩金网站大全2019-11599)
    • 危险等级:中
    • BID:108113
    • cve编号:2018年送彩金网站大全2019-11599
  • Linux Kernel信息泄露漏洞(2018年送彩金网站大全2018-20510)
    • 危险等级:低
    • BID:108125
    • cve编号:2018年送彩金网站大全2018-20510
  • Apache Archiva HTML注入漏洞(2018年送彩金网站大全2019-0214)
    • 危险等级:中
    • BID:108124
    • cve编号:2018年送彩金网站大全2019-0214
  • Apache Archiva HTML注入漏洞(2018年送彩金网站大全2019-0213)
    • 危险等级:中
    • BID:108123
    • cve编号:2018年送彩金网站大全2019-0213
  • ImageMagick拒绝服务漏洞(2018年送彩金网站大全2019-10131)
    • 危险等级:中
    • BID:108117
    • cve编号:2018年送彩金网站大全2019-10131
  • Microsoft Visual Studio ‘asm’远程内存损坏漏洞
    • 危险等级:中
    • BID:108122
    • cve编号:
  • Lenovo XClarity Administrator信息泄露漏洞(2018年送彩金网站大全2019-6158)
    • 危险等级:中
    • BID:108165
    • cve编号:2018年送彩金网站大全2019-6158
  • Cisco Firepower Threat Defense Software拒绝服务漏洞(2018年送彩金网站大全2019-1703)
    • 危险等级:高
    • BID:108170
    • cve编号:2018年送彩金网站大全2019-1703
  • Apache Commons Imaging信息泄露漏洞(2018年送彩金网站大全2018-17201)
    • 危险等级:中
    • BID:108161
    • cve编号:2018年送彩金网站大全2018-17201
  • Apache Karaf 漏洞(2018年送彩金网站大全2019-0226)
    • 危险等级:中
    • BID:108174
    • cve编号:2018年送彩金网站大全2019-0226
  • dhcpcd缓冲区溢出漏洞(2018年送彩金网站大全2019-11766)
    • 危险等级:高
    • BID:108172
    • cve编号:2018年送彩金网站大全2019-11766
  • Atlassian JIRA跨站脚本漏洞(2018年送彩金网站大全2019-3400)
    • 危险等级:中
    • BID:108168
    • cve编号:2018年送彩金网站大全2019-3400
  • Alpine Linux Docker映像硬编码凭证验证绕过漏洞(2018年送彩金网站大全2019-5021)
    • 危险等级:中
    • BID:108288
    • cve编号:2018年送彩金网站大全2019-5021
  • Kaspersky Antivirus Engine堆缓冲区溢出漏洞(2018年送彩金网站大全2019-8285)
    • 危险等级:高
    • BID:108284
    • cve编号:2018年送彩金网站大全2019-9698
  • Symantec AV Engine任意文件删除漏洞(2018年送彩金网站大全2019-9698)
    • 危险等级:中
    • BID:108128
    • cve编号:2018年送彩金网站大全2019-9698

(数据来源:绿盟威胁情报中心)

 

文章来源:绿盟科技博客
]]>
http://blog.cholochitro.com/nsfocus-19-19/feed/ 0
Istio系列一:Istio的认证授权机制分析 http://blog.cholochitro.com/analysis-istios-authentication-authorization-mechanism/ http://blog.nsfocus.net/analysis-istios-authentication-authorization-mechanism/#respond Tue, 14 May 2019 02:02:04 +0000 http://blog.cholochitro.com/?p=15060 随着虚拟化技术的不断发展,以容器为核心的微服务概念被越来越多人认可,Istio因其轻量级、服务网格管理理念、兼容各大容器编排平台等优势在近两年脱颖而出,许多公司以Istio的架构设计理念作为模板来管理自己的微服务系统,但在其势头发展猛劲之时,也有许多专家针对Istio的安全机制提出了疑问,比如在Istio管理下,服务间的通信数据是否会泄露及被第三方劫持的风险;服务的访问控制是否做到相对安全;Istio如何做安全数据的管理等等,这些都是Istio目前面临的安全问题,而我们只有深入分析其机制才能明白Istio是如何做安全的。

摘要

随着虚拟化技术的不断发展,以容器为核心的微服务概念被越来越多人认可,Istio因其轻量级、服务网格管理理念、兼容各大容器编排平台等优势在近两年脱颖而出,许多公司以Istio的架构设计理念作为模板来管理自己的微服务系统,但在其势头发展猛劲之时,也有许多专家针对Istio的安全机制提出了疑问,比如在Istio管理下,服务间的通信数据是否会泄露及被第三方劫持的风险;服务的访问控制是否做到相对安全;Istio如何做安全数据的管理等等,这些都是Istio目前面临的安全问题,而我们只有深入分析其机制才能明白Istio是如何做安全的。

本文为Istio系列的首篇,后续还有三篇分别对Istio组件Envoy、Pilot、Mixer的原理解读,本篇作为开胃菜,首先介绍Istio背景及主要架构,再从身份认证和授权鉴权两方面对Istio的认证授权机制加以剖析,最后通过实验分析具体讲述Istio如何做访问控制,文章阅读时间大致15分钟,希望能给各位读者带来收获。

 

Istio概述

Istio是由Google、IBM、Lyft联合开发的开源项目,它是一款微服务管理框架,也被称为第二代微服务Service Mesh代表。Istio的架构思想类似软件定义网络(SDN),其主要分为控制平面和数据平面两个部分,下图为Istio官方架构图:

图1 Istio架构图

数据平面由一组Sidecar方式部署的智能代理Envoy(上图中的Proxy)组成,Envoy是Istio默认的数据平面代理,这些代理用于调节和控制服务及Mixer之间的所有网络通信。

控制平面按各自功能分为以下四个组件:

  • Mixer:负责前置条件检查(例如ACL检查、白名单检查、日志检查),遥测报告上报(日志、监控、配额),配额管理(限流);
  • Pilot:负责管理和配置Envoy,将流量路由到各服务中;
  • Galley:在Istio 1.1版本被引入,是整个控制平面的配置管理中心,除了提供配置验证功能以外,还负责配置的管理和分发,使用网络配置协议和其它组件进行配置交互;
  • Citadel:负责管理密钥和证书,用于保证数据平面各服务的通信安全;

下面本文将着重介绍Istio在安全方面的设计和实现机制。

Citadel认证授权机制

Istio的认证授权机制主要是由Citadel完成,同时需要和其它组件一起配合,参与到其中的组件还有Pilot、Envoy、Mixer,它们四者在整个流程中的作用分别为:

  • Citadel:用于负责密钥和证书的管理,在创建服务时会将密钥及证书下发至对应的Envoy代理中;
  • Pilot: 用于接收用户定义的安全策略并将其整理下发至服务旁的Envoy代理中;
  • Envoy:用于存储Citadel下发的密钥和证书,保障服务间的数据传输安全;
  • Mixer: 负责管理授权完成审计工作。

Istio通过以上四个组件的协同工作可实现服务间的身份认证以及授权鉴权功能。

下面从Istio在,如下图所示:

图2 Istio拓扑图

具体工作流程可描述如下:

  • Kubernetes某集群节点新部署了服务A和服务B,此时集群中有两个Pod被启动,每个Pod由Envoy代理容器和Service容器构成,在启动过程中Istio的Citadel组件会将密钥及证书依次下发至每个Pod中的Envoy代理容器中,以保证后续服务A,B之间的安全通信。
  • 用户通过Rules API下发安全策略至Pilot组件,Pilot组件通过Pilot-discovery进程整理安全策略中Kubernetes服务注册和配置信息并以Envoy API方式暴露给Envoy。
  • Pod A, B中的Envoy代理会通过Envoy xDS API方式定时去Pilot拉取安全策略配置信息,并将信息保存至Envoy代理容器中。
  • 当服务A访问服务B时,会调用各自Envoy容器中的证书及密钥实现服务间的mTLS通信,同时Envoy容器还会根据用户下发的安全策略进行更细粒度的访问控制。
  • Mixer在整个工作流中核心功能为前置条件检查和遥测报告上报,在每次请求进出服务A,B时,服务A,B中的Envoy代理会向Mixer发送check请求,检查是否满足一些前提条件,比如ACL检查,白名单检查,日志检查等,如果前置条件检查通过,处理完后再通过Envoy向Mixer上报日志,监控等数据,从而完成审计工作。

 

身份认证分析

Istio官方的身份认证架构如下图所示:

图3 Istio的身份认证架构图

Istio的身份认证流程可以概括为以下步骤:

  • Administrators制定三个策略,其中一个策略作用域在Foo命名空间,目标服务为Service A,另两个策略作用域在Bar命名空间,目标服务分别为Service B和All。
  • Pilot根据Administrators下发的三个策略中的元数据(Pod、Service、Deployment等)调用Kubernetes API Server监视配置存储,有任何策略变更后,会将新策略转换为适当配置并将身份验证以及凭证中的其它声明(如果适用)输出至服务对应的Envoy代理。
  • Envoy代理根据身份验证信息以及凭证信息对服务进行访问验证。

以传输身份认证举例,传输身份验证可以理解为服务到服务的身份验证,Istio提供mTLS(双向TLS)功能来实现。

在整个身份认证过程中,涉及到两种证书和私钥,分别为root-cert.pem、cert-chain.pem、key.pem。其中:

  • root-cert.pem:用于证书校验的根证书,所有Envoy共用同一个root-cert.pem;
  • cert-chain.pem:Envoy的证书,由root-cert.pem签署,会在需要时提供给对端的服务;
  • pem:Envoy的私钥,和cert-chain.pem中的证书相匹配;

 

这三个文件在当服务被创建时,由Citadel组件管理并传递至服务对应的Envoy代理中。

 

以Istio官方的bookinfo demo举例,我们可以进到productpage服务的Envoy代理容器中查看/etc/certs目录,如下图所示:

图4 Envoy代理容器的证书及密钥

图中红框部分即为证书和私钥,证书的有效期限默认为三个月,过期后Citadel会对证书密钥进行更换。

当开启了mTLS后,服务间的流量为加密流量,并且相互根据证书以及密钥进行访问从而保障服务间的通信安全。值得一提的是,在同一个Pod中服务与Envoy代理之间通信采用的是localhost,不使用加密流量。

另外,一般会出现这种情况,即没有注入Envoy代理容器的服务与设置了mTLS的服务之间通讯,通常情况下为了微服务安全性需要为未注入Sidecar容器的服务进行证书配置,或是在访问时附加上密钥及证书信息。

 

授权鉴权分析

Istio中服务间的授权鉴权主要由Kubernetes的RBAC(基于角色的访问控制)功能实现。

在微服务架构中,服务间的调用我们可以理解为一个C-S模式。在默认不开启授权的情况下,服务间的访问是无限制的。开启授权模式后,默认情况下必须显示进行授权才能对服务进行访问。

这里会有两种级别的访问控制:

  • 命名空间级别

指定命名空间内的所有(或部分)服务可以被另一命名空间的所有(或部分)服务所访问,需要用户创建ServiceRole、ServiceRoleBinding策略来实现此过程。

  • 服务级别

指定服务可以被另一个服务访问,需要用户创建Service Account、ServiceRole、ServiceRoleBinding策略来实现此过程。

Istio官方授权鉴权的架构图如下所示:

图5 Istio授权、鉴权架构图

根据图5整个工作流程可描述为:

  • 用户使用yaml文件指定Istio授权策略。部署后,Istio将策略存至Istio Config Store中;
  • Pilot通过Kubernetes API Server监控Istio授权策略变更,如果有更改,则获取最新的授权策略;
  • Pilot将授权策略下发至服务的Envoy代理;
  • 每个Envoy代理都运行一个授权引擎,在引擎运行时对请求进行授权。

 

实验分析

同样以bookinfo demo举例,默认情况下,各个服务间通过页面可以进行访问,我们通过

kubectl create -f samples/bookinfo/platform/kube/rbac/rbac-config-ON.yaml

可以开启授权模式,yaml文件如下图所示:

图6开启授权模式yaml文件内容

再次访问bookinfo页面时如下图所示:

图7 访问productpage页面

由图7可知,Istio授权行为默认为拒绝,所以必须要显示授权,才能对其服务进行访问。

实验前提:

  • 部署bookinfo实例时用TLS模式,即istio-demo-auth.yaml。
  • 在下面实验里,我们会在 Service account 的基础上启用访问控制,为了给不同的微服务以不同的访问授权,需要建立一系列不同的 Service account,用这些账号来分别运行 Bookinfo 中的微服务。

创建Service Account需执行以下命令:

kubectl create -f bookinfo-add-serviceaccount.yaml

此命令创建了两个ServiceAccount,如下图所示:

图8 查看添加的两个Service Account

命名空间级的访问控制

Bookinfo demo中,productpage、reviews、details 以及 ratings 服务被部署在 default 命名空间中,而 istio-ingressgateway等 Istio 组件是部署在 istio-system 命名空间中。我们可以定义一个策略,default 命名空间中所有服务,如果其 app label取值在 productpage、reviews、details 以及 ratings 范围内,就可以被default命名空间内以及 istio-system 命名空间内的服务进行访问。

执行以下命令:

istioctl create -f samples/bookinfo/platform/kube/rbac/namespace-policy.yaml

返回结果如下:

图9 创建基于命名空间的授权策略

我们简单看下这个策略文件内容:

图10 基于命名空间的策略内容

如上图红框部分所示,这个策略文件定义了两个对象分别为ServiceRole和ServiceRoleBinding,含义如下所示:

  • ServiceRole:创建名为service-viewer 的 ServiceRole,允许访问 default 命名空间中所有 app 标签值在 productpage、reviews、details以及 ratings 范围之内的服务。
  • ServiceRoleBinding:创建ServiceRoleBinding 对象,用来把 service-viewer 角色指派给所有 istio-system 和 default 命名空间的服务。

执行命令后,再通过网页访问bookinfo样例,发现服务正常了,如下图所示:

图11 访问加载了命名空间的策略页面

服务级的访问控制

执行下一策略之前先将之前的策略移除,如图12所示:

图12 移除基于命名空间访问的策略

服务级的访问控制由于Bookinfo demo的服务调用关系,需要逐步进行访问控制,首先允许到ProductPage服务的访问,执行以下命令:

kubectl apply -f productpage-policy.yaml

返回结果如下:

图13  productpage页面的访问策略执行

我们简单看下productpage-policy.yaml文件的内容:

图14 productpage页面的访问策略内容

如图14所示,该策略首先创建了一个名为productpage-viewer的ServiceRole,其作用为允许到 productpage 服务的读取访问;再创建一个名为bind-productpage-viewer的ServiceRoleBinding,将角色productpage-viewer赋给所有用户。

再次浏览bookinfo demo页面,如下图所示:

图15 访问加载了productpage策略的页面

由上图我们可以看出,访问productpage服务没有问题了,但左边红框的detail服务和右边红框的review服务显示无法访问,这是因为我们还没有给productpage访问details和reviews的权限,所以我们再执行下一条命令:

istioctl create -f samples/bookinfo/platform/kube/rbac/details-reviews-policy.yaml

返回结果如下:

图16 details和reviews的访问策略执行

我们简单看下details-reviews-policy.yaml这个文件的内容:

图17 details和reviews的访问策略内容

由图17可看出,该策略首先创建了一个名为details-reviews-viewer的ServiceRole对象,它的作用为允许对 details 和 reviews 服务进行只读访问;紧接着又创建了一个名为bind-details-reviews的ServiceRoleBinding对象,用于将details-reviews-viewers对象绑定到cluster.local/ns/default/sa/bookinfo-productpage中去,也就是bookinfo-productpage服务的ServiceAccount,再次访问页面,如下图所示:

图18 访问加载details和reviews策略的页面

由图18可看出,details和reviews服务可以被访问了,但ratings服务仍然无法访问,原因是 reviews 服务无权访问 ratings 服务,要更正这一问题,就应该给 ratings 服务授权,使其能够访问 reviews 服务,所以执行以下命令:

istioctl create -f samples/bookinfo/platform/kube/rbac/ratings-policy.yaml

我们简单看下文件内容,如下图所示:

图19 对ratings服务授权的yaml文件内容

 

执行文件后再次访问页面如下图所示:

图20 访问加载了ratings策略的页面

可以看到已经可以正常访问所有的服务。

通过以上两个实验结果可以看出,服务之间想要互相访问首先需要服务账户(Service Account),以上两个实验的Service Account为productpage和reviews, 具体为何需要这两个Service Account是因为productpage服务需要允许对reviews和details两个服务的访问权限,reviews服务需要允许对Ratings服务的访问权限。这就是实验开始前添加这两个ServiceAccount的原因,相信各位读者看到这里应该知道Istio是如何做访问控制了,我们可以看出其核心还是调用了Kubernetes中的RBAC机制。

总结

将单一应用程序拆分为微服务带来了各种好处,包括更好的灵活性、可伸缩性以及服务复用的能力,但微服务也面临着许多特殊的安全需求,比如防止中间人攻击,需要服务间进行流量加密;为了提供灵活的访问控制,需要mTLS和更细粒度的访问策略;还有大量的数据需要审计工具来进行审计。

Istio在设计之初就将部分安全机制考虑了进去,Istio官方宣称在安全上目标要达到默认安全(即应用程序代码和基础结构无需更改)、深度防御(与现有安全系统集成,提供多层防御)、零信任网络(在不受信任的网络上构建安全解决方案)。

目前看来Istio在安全方面的实现还是主要依靠Kubernetes一些内置的安全机制。对于微服务的身份认证主要依赖于与双向TLS及JSON Web Token;授权鉴权策略主要依赖于Kubernetes中的RBAC机制,使用ServiceRole以及ServiceRoleBinding等CRD(CustomResourceDefinition)对象来实现。微服务安全任重而道远,Istio想实现全面的安全防护还需更多的精力投入。

下一篇将介绍Istio的数据平面组件Envoy,笔者会详细解释Envoy在Istio中是如何部署以及如何对入站出站流量进行代理转发及流量劫持,欢迎各位读者持续关注。

 

文章来源:绿盟科技博客
]]>
http://blog.nsfocus.net/analysis-istios-authentication-authorization-mechanism/feed/ 0