* 原创作者:魅影儿,本文属FreeBuf原创奖励计划,转载请注明来自FreeBuf.COM 

image030.gif

IEEE 802.11协议规定无线帧包含数据帧、控制帧和管理帧三类,本文将详细剖析此无线安全协议。

数据帧的任务是在工作站间传递数据,数据帧信息会因为所处的网络环境不同而发生变化。控制帧多用于为数据帧提供服务,保证工作站之间数据能可靠传输。控制帧能够选择通信信道、维护载波监听功能、清理工作区域、对收到的数据作出应答等。管理帧起监督作用。比如对 STA加入无线网络、退出无线网络、在基站间的漫游等进行管理。

IEEE 802.11i提供给企业网络管理员使用的安全保护,只适应于网络中的数据通信。若管理员想管理或者控制无线网络的运行,基本上无能为力。目前管理、控制报文并未受到保护,机密性、真实性、完整性无法得到保证,容易受到仿冒或者监听。为了在一定程度上消除这个安全隐患,802.11w 诞生了。它经由保护无线网络“管理帧”的过程来改善安全性,能够在一定程度上制止通过“管理帧“进攻网络的行为。

1.1  802.11w协议内容

1.1.1  无线管理帧

IEEE规定的802.11管理帧的通用格式如图1-1所示。

image003.gif

图 1- 1  管理帧基本结构

管理帧十分具有弹性。帧主体中的数据,长度不会变化的位叫做固定式位;长度在一定范围内可变的位就叫做IE(information element, 信息元素)位。信息元素指的就是长度有所变化的数据块。每一个数据块均会标注上类型编号与大小。不同IE的数据位具有不同的解释方式。802.11标准允许增加新的 IE 。

1.1.2  802.11w协议简介

802.11w保护的管理帧,包括去认证帧、去关联帧、强健Action帧。强健Action帧主要包含: SpectrumManagement 、Qos、DLS、Block Ask 、Radiomeasurement、Fast BSS Transition、 SA Query 、ProtectedDual of Public Action、Vendor-specfic Protected帧[27] 。

对于单播管理帧采用数据帧的临时密钥对其进行加密保护。对广播管理帧采用新提出的加密套件BIP进行保护,提供了完整性校验以及重放保护。

802.11w协议一致性测试的内容主要包括两部分:管理帧保护和SA Query处理机制,SA Query处理机制中涉及的 SA Query Request和SA Query Response帧属于强壮Action帧,同样受 802.11w标准保护。

1.1.3  RSNIE变更

IE(Information Element,信息元素)是管理帧的组成成分,其长度可变。管理帧会通过 IE来与别的系统交换信息。信息元素一般包括一个Element ID(元素识别码) 位、一个 Length(长度)位和一个长度不定的位。16bit的 Capability Information (能力信息)位,用于在发送Beacon帧时通告一个服务集内的工作站本网络所具有的能力。它同样能够用于Probe Request 和 Probe Response帧中。每个bit位各自代表一个旗标,分别代表网络具备何种功能。STA 使用这些公告信息判断自己是否支持该 BSS所有的功能。一般情况下,不具备性能通告中要求的能力的工作站,不能加入此服务集。首先AP通过信标帧广播 RSN能力,使得无线工作站之间能够互换安全信息。版本 Version属于必要位,802.11定义了版本 0, 1保留未用,版本2以上未定义[22] 。群组密码套件 Group Data CipherSuit在同一时间能且只能选择一种。并且所选套件必须和全部接入该服务集的工作站的组密码套件兼容。密码套件选项占四个字节,由厂商的OUI以及代表密码套件的编号组成, 802.11系列协议所使用的OUI为00-0F-AC ,IEEE802.11w中定义的标准密码套件如表2-2所示;成对密码套件 Pairwise Cipher Suites(count+list) 作用是保护单播管理帧,它包含二字节的计数字段与4*n(n为正整数) 字节它允许的密码套件描述符。除信息元素长度有受限外,协议并未规定其允许的密码套件数量;身份认证与密钥管理套件 Authentication andKey Management Suites(count+list)也存在好几种身份认证类型,它由一组四个字节的识别码组成。包括一个 OUI和一组套件类型标识符。 AKM取不同值时对应的认证和密钥管理类型如表2-3所示。强健安全网络能力 RSN Capability 字段占两个字节,用于描述发送方的安全性能。

802.11w协议提出在RSN信息元素的RSN capabilities(如表 1-1)中增加MFPR及MFPC位; AKM 字段新增类型00-0F-AC:5和00-0F-AC:6;并且新增Group Management Cipher suit 字段。

增加的MFPR和MFPC位用来协商保护管理帧能力,MFPR 位置1表示强制要求管理帧保护,MFPC位置 1 表示支持管理帧保护;通过MFPR及MFPC位的设置来协商保护管理帧能力。

AKM字段新增类型00-0F-AC:5及00-0F-AC:6分别表示认证类型为 802.1x及PSK,相较00-0F-AC:1和 00-0F-AC:2 ,把加密算法从SHA1变为SHA256。

Group Management Cipher suit字段用来保护广播或多播管理帧[1],新增密码套件BIP 用来保护广播或多播的完整性,BIP协议运用AES加密算法,在CBC-MAC模式下计算认证码。健壮安全网络信息元素格式如图 2-所示。 image004.gif

图 1- 2  强健安全网络信息元素格式

Element ID :协议设定为48(十进制)。

Length:定义了从该字段以后RSN IE字段的总字节数。

Version:版本类型,值为1。

Group Cipher Suite(组播加密套件):该字段标识了使用何种加密算法进行组播加密,字段结构如图2-3。

image005.jpg

图 1- 3  加密套件选择器格式

Pairwise Cipher Suite Count:多存在于STA发往AP的帧中,该字段为 1。而在AP广播所带的RSN IE中,该字段值为 AP 支持的加密套件总数。

Pairwise Cipher Suite List:该字段列出了所用的加密算法,格式类似组播加密算法的标识格式,数量与Pairwise CipherSuite Count字段的值一致。

AKM Suite Count:标识使用的AuthenticationKey Management (AKM)套件的数量。

AKM Suite List:结构同字段Pairwise CipherSuite List,具体值见表1-3[22] 。

RSN Capability :此字段用于描述发送端能力,后六位保留未用,必须设定为0,字段结构如表1-1 所示[22]。

表 1- 1  RSN Capability字段结构

B0 B1 B2-B3 B4-B5 B6 B7 B8 B9 B10-B15
PreAuth No Pairwise PTKSA Replay Counter GTKSA Replay Counter MFPR MFPC Reserved Peer Key Enabled  

表 1- 2  加密套件选择器

OUI Suite type Meaning
00-0F-AC 0 Use group cipher suite
00-0F-AC 1 WEP-40
00-0F-AC 2 TKIP
00-0F-AC 3 Reserved
00-0F-AC 4 CCMP-default pairwise cipher suite for data frames in RSNA
00-0F-AC 5 WEP-104
00-0F-AC 6 BIP-default group management cipher suite in an RSNA with management frame protection enabled
00-0F-AC 7 Group addressed traffic not allowed
00-0F-AC 8-255 Reserved
Vendor OUI Other Vendor-specific
Other Any Reserved

 

表 1- 3  身份认证与密钥管理套件选择器

OUI State type Meaning
Authentication type Key management type
00-0F-AC 0 Reserved Reserved
00-0F-AC 1 Authentication negotiated over IEEE 802.1X or using PMKSA catching as defined in 8.4.6.2 – RSNA default RSNA key management as defined in 8.5 or using PMKSA catching as defined in 8.4.6.2 – RSNA default
00-0F-AC 2 PSK RSNA key management as defined in 8.5, using PSK
00-0F-AC 3-255 Reserved Reserved
Vendor OUI Any Vendor-specific Vendor-specific
Other Any Reserved Reserved

1.1.4  无线终端协商上线

1.1.4.1  802.11w 能力协商

STA发送关联请求帧,AC解析关联请求帧中的RSNIE。在原有的基础上新增解析 MFPC位和MFPR位及Group Management Cipher Suite字段,解析完成后,对 MFPC及MFPR位按表1-4所示进行协商。当 AP 没有保护管理帧功能时,允许STA上线;当AP开启保护管理帧功能时,分以下两种情况考虑。

1)     AP端的MFPC置1,MFPR置0,STA端的MFPC置0或1,MFPR置0时,允许STA上线,并回应关联响应报文,PMF Status字段的值为Inactive;若STA端的MFPC置1,MFPR置1,也允许STA上线,回应关联响应报文,PMF Status字段值为Active;若STA端的MFPC置0,MFPR置1,AP不允许STA上线,回应携带错误码31的关联响应报文。

2)     AP端的MFPC和MFPR都置1,STA端的MFPC置1,MFPR置0或1时,允许STA上线,回应关联响应报文,PMF Status字段的值是Active;若STA端的MFPC置0,MFPR置0或1,则回应携带错误码31的关联响应报文。

然后对广播管理帧进行协商,若AP设置Group Management Cipher Suite为 BIP ,且STA默认为BIP,允许STA 上线;否则,不允许 STA上线。

表 1- 4  扩展服务集中健壮管理帧协商原则

AP MFPC AP MFPR STA MFPC SPA MFPR AP Action STA  Action
0 0 0 0 The AP may associate with the STA The STA may associate with the AP
1 0 0 0 The AP may associate with the STA The STA may associate with the AP
1 0 or 1 1 0 or 1 The AP may associate with the STA The STA may associate with the AP
1 1 0 0 The AP shall reject associations from the STA with the Status Code“Robust management frame policy violation” The STA shall not associate with the AP
0 0 1 1 No action The STA shall not try to associate with the AP
0 0 1 0 The AP may associate with the STA The STA may associate with the AP
1 0 or 1 0 1 The STA advertises an invalid setting. The AP shall reject associations from the STA with the Status Code “Robust management frame policy violation” The STA shall not try to associate with the AP
0 1 1 0 or 1 No action The AP advertises an invalid setting. The STA shall not try to associate with the AP

 1.1.4.2 AKM套件协商

STA发送关联请求帧后与AC协商身份认证与密钥管理方式,以保证服务的私密性与完整性。

AKM字段新增类型00-0F-AC:5及00-0F-AC:6对应 802.1x及PSK,相较于00-0F-AC:1, 00-0F-AC:2 ,变化体现在对密钥衍生算法进行了升级,并且使用AES-128-CMAC算法保证信息完整性;因此AKM套件 00-0F-AC :5和00-0F-AC:6 提升了 RSN的安全性能。

被测设备对这些AKM套件若都支持,即支持00-0F-AC:1,00-0F-AC:2 ,00-0F-AC:5,00-0F-AC:6,则首先选00-0F-AC:5 ,对应的结果为 802.1x_SHA256。

若支持PSK,即00-0F-AC:2,00-0F-AC:6 则首选00-0F-AC:6,结果为PSK_SHA256。

若支持802.1x,即00-0F-AC:1,00-0F-AC:5则首选00-0F-AC:5, 结果为802.1x_SHA256。

当协商的AKM为00-0F-AC:5 或6时,EAPOL-Key帧的填充和密钥衍生算法会发生改变,密钥衍生算法由prf 变成kdf,具体改变在密钥协商一节中有介绍。

1.1.4.3  密钥协商

802.11w标准中,STA首次接入AP时,经由四次握手的过程完成单播及组播密钥的协商,对管理帧进行保护。

CCMP安全协议中的密钥有单播密钥和组播密钥两种[30]。客户端认证成功后,单播密钥被通信双方 STA 和AP同时拥有。单播密钥又名成对密钥。它的层次结构非常复杂:最顶层的是PMK( Pairwise Master Key ,成对主密钥),PMK主要用于导出所有别的成对密钥。当用户认证为802.1X 认证时, PMK在AP对STA认证完成后由 Radius 服务器产生并下发给AP和STA。当客户端认证方式为 PSK 认证时,配置的PSK直接转换为PMK 。但是 ,真正用来保证AP和STA 间安全连接的是成对临时密钥 PTK(Pairwise TemporaryKey)而非PMK 。 PTK是由PMK导出的一个单独加密组,代表一系列密钥。PTK 由临时密钥 TK(Temporal Key)、密钥加密密钥KEC(EAPOL-Key Encryption Key) 和密钥认证密钥KCK(EAPOL-Key Conformation Key)三部分组成。其中,TK 用于加密通信数据; KEK同于加密EAPOL-Key中所携带的数据;KCK 用于对 EAPOL-Key进行认证。STA重新关联到AP 时要更新 PTK,PTK的实时性由nonce 来保证 [26]。当STA和 AP 生成一个新的PTK之后,AP再用它来传送组播临时密钥 GTK给STA。由PMK 生成由 PTK过程如图1-4所示,其中 AA 代表AP的Mac地址, SPA代表STA的MAC 地址。

image006.gif

图 1- 4 成对密钥衍生过程

802.11w中的RSN四次握手协商密钥发生在PMK成功获取后,过程如图 1-5

image007.gif

图1- 5  四次握手密钥协商过程

1)     AP向STA发送Message 1帧,该帧中包含用于产生PTK的随机数Anonce,并表明目前正在进行PTK的发布过程,Message 1没有受到任何的加密及认证保护。

2)     STA收到Message 1后得到Anonce并选择一个随机数Snonce用PRF算法计算出PTK,PTK=SHA1_PRF(PMK,Len(PMK),“Pairwisekeyexpansion”,MIN(AA,SA)||Max(AA,SA)||Min(ANonce,SNonce)||Max(ANonce,SNonce));而后发送Message 2帧给AP,该帧中包含Snonce及STA的RSN信息元素,并且该帧使用了计算得到的PTK中的前16个字节作为MIC KEY(又称KCK)对Message 2进行MIC完整性校验。

3)      AP收到Message 2后,得到Snonce并计算出PTK、GTK、IGTK。同时使用计算出的PTK中的KCK对数据进行MIC校验。如果校验不成功,就会丢弃Message 2。如果校验成功,则向STA 发送Message 3[25]。Message 2帧中包含要求STA装入PTK(包括PTK中的TK、KEK和KCK)、GTK和IGTK及AP的RSN信息元素,并且AP对Message 2帧进行了MIC认证。为实现对组播管理帧的保护,802.11w协议标准规定:AP对接收到的EAPOL-KeyMessage 2进行解析,并且在原有EAPOL-Key基础上增加了IGTK/IPN协商,然后将IGTK和IPN协商结果添加到原来的EAPOL-Key之后,封装成新的EAPOL-KeyMessage3和RSN IE一起下发给STA。

4)     STA收到Message 3后装入PTK、GTK和IGTK,并且发送特殊的空信息Message 4(EAPOL=Key帧的Key Data字段无任何数据)表示已经装入密钥,AP在收到Message 4后也装入PTK、GTK和IGTK。

至此,四次握手结束,通信过程中所需要的密钥被全部生成,通信双方安装密钥完毕,可以开始传输安全数据。另外,802.11w协议标准还规定当有客户端离开基础服务集时、或者密钥生存周期已到时、或者密钥加密的数据流量达到限制值时,通过组播握手进行GTK密钥、IGTK密钥的更新,并且这两个密钥以加密的方式被分发给通信客户端。IGTK随着GTK的变化而变化。IGTK是802.11w协议中新定义的密钥,BIP运用IGTK对广播管理帧进行签名。IGTK被同一BSS中的STA共享。四次握手协商密钥的过程较难理解,这也是实现802.11w协议一致性自动化测试套必须解决的难题,若不能正确区分各个密钥之间的关系,就无法正确修改程序中加密和解密函数的相关参数,无法对接收的报文正确解密,从而无法对802.11w协议进行一致性测试。

组播握手过程如图1-6所示。 

image008.gif

图 1- 6  组播握手密钥协商过程

组播密钥层次结构如图1-7所示。

 

image009.gif

图 1- 7  组播密钥衍生过程

EAPOL-Key的具体格式如表1-5所示,其中Key Information字段格式如表 2-6所示。AKM协商为00-0F-AC: 5 或00-0F-AC:6时将做如下改变。

1)     EAPOL-Key message 1中Key Information字段的Key Descriptor Version值为3。

2)      EAPOL-Keymessage 3中,在原有基础上,使用SHA256算法生成GTK,填充至EAPOL-Key帧keydata字段中,将EAPOL帧和KCK作为AES-128-CMAC算法的输入生成16字节MIC填充至MIC字段。

3)      将BSSID、Gnonce、字符前缀和GMK作为SHA256算法的输入生成GTK。

4)     IGTK密钥需要添加到EAPOL-Key的Key Data字段中GTK之后,原802.11i协议中Message3的Key Data Length和Key Data字段将发生变化。

表 1- 5  EAPOL-Key Message 3格式

Protocol Version – 1 octet Packet Type – 1 octet Packet BodyLength – 2 octets
Descriptor Type – 1 octet
Key Information – 2 octets Key Length – 2 octets
Key Replay Counter – 8 octets
Key Nonce – 32 octets
EAPOL – Key IV – 16 octets
Key RSC – 8 octets
Reserved – 8 octets
Key MIC –variable
Key Data Length – 2 octets Key Data – n octets

表1- 6  Key Information字段格式

B0           B1      B2        B3          B4       B5         B6       B7

Key Descriptor Version Key Type Reserved Install Key ACK
Key MIC Secure Error Request Encrypted Key Data SMK Message Reserved

1.1.4.4 STA 802.11w能力确认机制

STA协商为11w并首次上线后,AC 会首先发送一个加密的SA Query request报文,只有收到合法的响应后才完成这个STA上线,否则将 STA 踢下线。

1.1.5  保护管理报文的处理

802.11w保护的管理帧包括单播管理帧和广播管理帧,对单播管理帧和广播管理帧有不同的处理方式。如图1-8所示。 

image010.gif

图 1- 8  802.11w保护管理帧内容

1.1.5.1  单播管理帧的处理

在AP和某一STA的PMF 协商成功之后(即STA支持11w;STA和 AP协商PTK和IGTK完成), AP 将会对部分单播管理帧进行加密,以提高单播管理帧的机密性、真实性和完整性并保证抗重放性。要求加密的单播管理帧包括:去认证帧、去关联帧和802.11w协议中规定的部分Action 帧。在 PMF协商成功之前,STA不应发送单播健壮Action 帧 ,若AP收到此健壮Action帧,则直接在 AP端忽略此帧,不上送AC。

在本功能中,要将收到的加密单播管理帧进行解密,解密单播管理帧时所用的TK和解密数据帧的TK相同,区别就是解密单播管理帧需要额外维护本地的 Rx_ReplayCounter(接收重放计数器),Rx_ReplayCounter用来进行重放检测,它在协商/ 刷新 TK时初始化为0。经过CCMP加密的帧,在原有帧的基础上添加了 8 字节的CCMP头和8字节的MIC 尾。先计算 MIC对报文进行认证,而后对帧主体部分和MIC值进行加密,认证和加密使用的是同一个密钥TK 。受保护的单播管理帧格式如图 1-9所示。

image011.gif

图 1- 9  受保护的单播管理帧格式

1.1.5.2  广播管理帧的处理

保护管理帧能力协商成功之后,协议实体不仅对单播管理帧进行保护,对广播管理帧也会进行一定程度上的保护。但保护机制略有不同,具体体现在对广播管理帧的保护会使用一套新的加密套件BIP,以达到保护广播管理帧的完整性,增强广播管理帧抗重放性的目的。

BIP的主要是通过在广播的管理帧的帧主体后面增加一个Manangement MIC InformationElement(简称MMIE) 来实现的。MMIE的具体格式如表1-7所示,由Element ID 、 Length、Key ID、IPN和 IPN 五个字段构成。

表1- 7  MMIE格式

Octets: 1 1 2 6 8

其中,IPN是IGTK报文序列号,用来统计广播管理帧的数目,不同的报文其IPN 值是不同的,IPN字段对广播管理帧实现重放检测,提供抗重放保护。MIC为当前报文及IGTK 使用AES-128-CMAC计算后的值,用来对管理帧进行完整性校验。受保护的广播管理帧格式如图1-10所示。 

image012.gif

图 1- 10  受保护的广播管理帧格式

PMF协商成功的情况下,AP接收到的没有BIP 保护的组播健壮管理帧将被丢弃。现将AP接收、发送广播管理帧的处理总结在表1-8中。

表 1- 8  AP 接收、发送广播管理帧的处理

报文类型 是否 IGTK 保护 Rx/Tx AP处理
Deauthentication Y Rx 忽略报文
Deauthentication Y Tx 用户关闭无线服务,去使能射频或者通过命令行将所有STA踢下线。
Deauthentication N Rx 忽略报文
Disassociation Y Rx 检测广播管理帧完整性和重放保护,合法则将STA去关联
Disassociation N Rx 忽略报文 

1.1.5.3  主动SA Query处理

为防止被仿冒(重)关联报文干扰,导致AP对STA作出错误的响应,当AP 处在安全的连接,并收到与此STA具有相同MAC地址的(重)关联请求报文时,AP 要拒绝此STA的(重)关联请求。并且发送附带 TIE(Timeout IE ,时间间隔信息元素)的(重)关联响应报文,TIE格式如图2-12所示,其中设置保护管理帧关联返回时间,到了保护管理帧关联返回时间, AP 才能再次接收此STA的(重)关联请求。(重)关联响应帧中状态码为30,表示关联拒绝,请稍后再试。而后, AP 启动SA Query 机制,并且向STA发送SA Query 请求帧。若AP收到SA Query 响应帧,则认为当前已有的连接是可靠的,不启动新的连接;若未收到 SAQuery 响应帧,则AP在判断客户端超时后,向STA重发一次 SA Query 请求帧,重发次数不能超过客户端检查重试次数;若AP自始至终未收到SA Query响应帧,则直接删除 STA。SAQuery无超时情况下的流程如图1-11所示。

image013.gif

图 1- 11  SA Query无超时机制

image014.jpg

图 1- 12  TIE格式

1-12中,Element ID占一个字节,取值56 Length占一个字节,取值5Timeout Interval Type 占一个字节,如表1-9所示,取值3

表 1- 9  时间间隔选择器

Timeout Interval Type Meaning Units
0 Reserved  
1 Reassociation deadline interval Time units(TUs)
2 Key lifetime interval Seconds
3 Association Comeback time Times units
4-255 Reserved   

SA Query 超时机制如图1-13所示。

 image015.gif

图 1- 13  SA Query超时机制

SA Query帧格式如表1-10:其中,Category字段值为 8SA Query Action字段为0时表示安全关联请求帧,为 1 时表示安全关联响应帧。 

表1- 10  SA Query帧格式

Octets 1 1 2

1.1.5.4  被动SA Query处理  

被动SA Query 处理是指:AP被动收到SAQuery 请求报文后对其的处理。具体来说,如果STA实现了同AP之间的管理帧保护协商机制,当其收到未保护的去关联帧或者去认证帧后, STA 需要启动SAQuery机制,并向AP发送SAQuery 请求帧。若 AP向此STA回复正确的SAQuery 响应帧 , 说明STA在线,可以继续使用SA;若AP 没有回应合法的 SAQuery Response 帧, STA就破坏掉安全关联,并且把此AP 的状态设置为未认证。

1.2  RSN安全框架

RSN全称Robust SecurityNetwork,即强健安全网络[32],是 IEEE802.11i工作组致力于制定2004年IEEE通过的 802.11i 安全标准时定义的新名词。定义它的初衷是增强无线MAC层的数据加密和认证性能。如今,RSN框架被延伸运用到 802.11w 协议中,用于保护管理帧,从而提升无线网络安全性能。RSN使用高级加密标准AES( AdvancedEncryption Standard )加密数据,使用端口控制协议(IEEE 802.1X)进行访问控制,运用基于802.1X 的成对密钥交换协议– 可扩展认证协议EAP(ExtensibleAuthentication Protocol                            )进行认证和密钥管理[38] 。一个真正的RSN网络中,只允许有 RSN能力的无线设备接入。下图 1-14给出了用于支持这些功能的协议,图1-15列出了用于这些服务的密码学算法。

 

image016.gif

图 1- 14  RSN服务和协议

image017.gif

图 1- 15  密码算法

TKIP(Temporal Key Integrity Protocol,临时密钥完整性协议)保留了 WEP(Wired Equivalent Protocol,有线等效协议)的基本架构与过程方式。能在兼容现存的无线产品的基础上升级旧式 WEP硬件的安全性。是为WEP向CCMP平稳过渡而制定的协议。 TKIP 和WEP一样,都是基于RC4算法的,RC4 算法存在很多漏洞,密码容易被破解,受它保护的数据机密性差。而 CCMP是重新打造的加密协议,能提供最高级别的安全性。它基于AES加密算法和 CCM操作模式 ,AES是一种分组密码算法,从根本上改变了RC4 的弊端,因而安全性较高,802.11w 协议规定保护管理帧只允许使用CCMP安全协议。

1.3CCMP数据保密机制

以AES(Advanced EncryptionStandard)为基础的链路层安全标准称为CCMP (CounterMode with CBC-Mac Protocol,带有密码分组连接消息认证码的计数器模式协议)。它定义了一套适用AES分组密码的规范,是目前无线局域网中最安全的数据保密协议,主要由 AES与CCM两部分构成。AES是 CCMP 的核心算法,计算MIC与对数据加密和解密都要采用此算法。而CCM是指导 AES 的操作模式。其名称也源自底层所使用的区块密码组CCM(Counter Mode withCBC-MAC)。

1.3.1  AES加密算法

AES属于分组加密算法。分组长度为128bit且仅允许密钥长度为128、 192或256比特。CCMP安全协议在采用 AES 时,限制密钥与分组长度均为128比特。分组加密算法和序列加密算法相比有很多优点。例如:分组加密算法的加密和解密密码本不同;黑客依靠截获的部分明密文对破解密钥信息会难很多;对数据加密得到的密文非常随机;目前指导分组加密算法的操作模式已经非常成熟,不必担心因对加密算法操作不当引起安全问题。 TKIP 采用RC4加密算法,以bit为单位对明文加密。CCMP 安全协议使用 AES加密算法,以128bit的分组为单位加密明文数据。 802.11w 标准规定保护管理帧选用CCMP协议[38]。

1.3.1.1  AES的输与输出

AES加密需要输入的内容是明文和密钥,输出是密文[25]。解密时输入的内容是密文和密钥,输出明文[25] 。采用AES加密或解密数据时,所有分组都需要经过多轮变换。各轮变换使用的轮密钥不同。每结束一轮变换,都会得到一个结果,称为状态[28]。 状态、轮密钥、明文分组以及密文分组四者的长度一致。

AES依据Nb(Nb=分组长度/32)和 Nk(Nk=密钥长度/32)计算出各个分组需要变换的轮数Nr[29]。 Nb 和Nk取不同值时,Nr的取值如表1-11                所示。

表 1- 11  不同的Nb和Nk,Nr的取值

Nr Nb=4 Nb=6 Nb=8
Nk=4 10 12 14
Nk=6 12 12 14
Nk=8 14 14 14 

CCMP限定AES只能支持长度为128bit的分组与密钥,由 Nb和Nk的计算公式得Nb=4, Nk=4 ,查表可知Nr=10。

AES对各个分组都进行Nr+1轮变换。每轮变换使用的密钥不同。这 Nr+1个轮密钥是通过把初始密钥输入密钥扩展模块计算得出的。状态和轮密钥均使用字节的二维矩阵形式表示,前者为4行Nb 列,后者为 4行Nk列。当Nb=4 、 Nk=4时,可用两个4行4 列的二维矩阵表示状态和轮密钥,如表 1-12、1-13所示[38] 。每一列构成一个字。一个字中各字节间的顺序是从上到下,字和字间的顺序是从左到右 [38]。

表 1- 12  状态矩阵

P0 P4 P8 P12
P1 P5 P9 P13
P2 P6 P10 P14
P3 P7 P11 P15 

表 1- 13  轮密钥矩阵

K0 K4 K8 K12
K1 K5 K9 K13
K2 K6 K10 K14
K3 K7 K11 K15

1.3.1.2  AES的加解密过程

AES加密过程总共包含三种类型的轮变换[38]:轮密钥加变换,第1~Nr-1轮变换和第 Nr轮变换。第1~Nr-1轮变换步骤一样,每轮都是通过字节代替、 行移位、列混淆和轮密钥加四步完成;第 Nr 轮变换略有变化,只有字节替代、行移位和轮密钥加阶段,不执行列混淆操作。图1-16表示了 AES 的加密流程。

 

image018.gif

图 1- 16  AES加密过程

AES解密流程和加密流程类似,如图1-17所示

image019.gif

图 1- 17  AES解密过程

(1)      SubBytes与InySubBytes

SubBytes变换是一个简单的查表操作,该表指的是AES中定义的S盒,即图1-18 中的SRDS盒是一个16*16 字节的矩阵,包含了 8位所能表示的256个数的一个置换。状态中的每个字节按图1-18 所示的方式进行替换。以被替换字节的高 4位为行值、低4位为列值作为索引从S 盒中取出对应元素作为输出。图 1-18描述了字节代替变换操作

image020.gif

图 1- 18  SubBytes变换

InvSubBytesSubBytes的逆运算,利用的是逆S盒。

(2)      ShiftRows与InvShiftRows

ShiftRows[21]过程对状态中的各行依次进行循环左移。不同行移动的字节数不同。如果第i行移动Ci 字节,那么第i行第j位的字节将移动到位置(j-Ci)modNb Nb的值决定了偏移量C0C1 C2C3的大小。表1-14列出了分组长度为 128bit,即Nb的值为4时, C0C1C2 C3 的值 [38]

表 1- 14  Nb=4时,C0、C1、C2、C3的取值

Nb C0 C1 C2 C3
4 0 1 2 3

ShiftRows操作基本原理如图1-19所示。 

image021.gif

图 1- 19  ShiftRows操作基本原理

InvShiftRows即逆向ShiftRows,它对状态中的底部3行进行相反方向的循环移位操作。

(3)      MixColumns与InvMixColumns

MixColumns运算对状态中的各列独立地进行操作。每一列中的各个字节都被映射为一个新值,该值由此列中的4个字节通过函数变换得到。 MixColumns 变换过程如图1-20所示。

 

image022.gif

图 1- 20  MixColumns变换

InvMixColumns即逆向MixColumns,变换的方法也是和一个特定矩阵相乘。

(4)     AddRoundKey

AddRoundKey即轮密钥加,该变换是通过将状态的一列中的四个字节与轮密钥的一个字进行列间的操作实现的。过程如图 1-21所示[38],对AddRoundKey进行逆运算结果还是其本身。

 

image023.gif

图 1- 21  AddRoundKey 密钥加法变换

2.3.2  CCM操作模式

CCMP规定AES只能加密长度为128比特的数据块。然而,实际要加密的明文长度却是时时变化的,为了使用 AES,必须对待加密的明文进行处理。长度不够时进行填充,长度超过128bit时拆分为多个数据块,以此达到每个待加密的明文分组都是128bit 的目的。除此之外,还要有指导AES对各个明文分组进行加密和解密的操作规则,称为AES的操作模式。能和 AES 结合使用的操作模式非常多。但是若选择的操作模式不合适,即使底层的加密算法很强大,还是容易出现安全问题。由于涉及到实现的安全性,操作模式的选择变得极其重要。操作模式分为电码本模式、密文分组链接模式、密文反馈模式、输出反馈模式五种。

计数器模式CTRCounter)以其发展的非常成熟并且实现简单的特点受到了密码界的一致认可。然而,计数器模式仅能够指导 AES对消息的的加密和解密过程,并不能用于消息认证。以CBC模式为基础的CBC-MAC CipherBlock Chaining Message Authentication Code,密码分组消息认证码)模式,在国际上已被标准化,并经过了多年实践的检验,AES CBC-MAC 模式下能够用于生成MICMessage Integrity Code,消息认证码)。

CTR模式与CBC-MAC模式结合起来运用的操作模式叫做CCM 操作模式。CCMP运用的就是CCM操作模式。CCM 是一种组合过程模式。RFC3610详细介绍了CCM,既给出了用密钥加密明文的方式,又给出了用同一个密钥生成密码学上认为安全的完整性检验值的方式。 20039月,NIST National Instituteof Standards and Technology ,美国国家标准与技术研究)展开了对CCM的研究。2004 5 月,NIST批准了CCM,成为了 CCMP 的核心。CCM操作模式下,AES使用 CBC-MAC模式提供认证功能、确保消息完整性;使用CTR模式加密或者解密明文数据。

1.3.2.1  CBC-MAC模式

CBC-MAC模式按照图1-22所示的流程工作。首先使用AES对待加密的明文数据块的第一个分组进行加密运算。 而后把加密结果和第二个明文分组异或,再用AES加密标准对异或结果加密。所得结果再和第三个明文分组异或,同样再用AES 加密标准对异或结果加密 依次类推,直至所有明文分组加密完成,最后输出了消息的信息完整性校验码,附加在明文消息后。

image024.gif

图 1- 22  CBC-MAC模式的应用过程

明文消息经最后一轮加密后输出128bit的单个分组。它蕴含明文数据中全部分组的信息。输出分组的高64比特位是整个明文分组序列的 MIC。接收端首先把收到的密文分组解密。若接收端使用和发送端相同的计算方法对明文数据操作后计算出的MIC值与实际接收到的MIC 值不一致,就能断定密文数据在发送过程当中已经被攻击者篡改。在CBC-MAC模式下,每个明文数据块依次被执行加密和异或操作。

1.3.2.2  CTR模式

AES运用于CCMP中时,首先以128bit 为单位将明文划分成一个个相连的数据块。再把每一个数据块和采用AES加密CTR值产生的输出按位异或,得到该明文数据块的密文。 CTR 的值随明文分组个数的增加不断加11-23展示了 CTR模式的应用过程。

image025.gif

图 1- 23  CTR模式的应用过程

图中,CTR值从1开始每次加1 ,从1增加到11。实际应用中,CTR 的初始值是随机的,且依照一定的规律递增。解密密文的接收端同样拥有 CTR的初始值和递增规律。为保证相同的明文分组被加密成不同的密文,提升抗攻击能力,每个明文分组对应的CTR值要求不同。然而, CTR 如果总是从同一个值开始并且按同一个规律增加,对于两条不同的消息,若含有某个相同的明文分组,还是会出现两个相同的但是分离的明文分组被加密成相同密文的情况,更易于攻击者提取消息的明文特征。通过对不同的待加密明文序列采用不同的CTR 初始值的方法能够很好地解决此问题。接收端对收到的密文解密时,也是采取和发送端一样的方式先对密文进行分组,然后针对各个密文分组进行解密。方法是:首先加密 CTR值、然后把运算得出的结果和密文分组进行逐位异或运算的过程完成解密,还原出明文。

2.3.3  CCMP封装与解封装流程

CCMP协议是对MPDU进行操作。MPDU由MAC头部和明文数据两个部分构成。MAC头部中包含了一些无线局域网相关的信息,比如源地址和目的地址等。CCMP只保护MAC的承载数据部分,下层协议帧头和802.11帧头则保持不变。如图1-24所示。

image026.gif

图 1- 24  CCMP封包过程

1)      封包编号PN(PacketNumber)用于检测重放攻击。每传一个报文PN值增加一。同一个临时密钥加密的报文的PN值都不相同。

2)      从MAC头部中提取认证数据AAD(Additional Authentication Data)[23]。它包含帧标头的802.11协议版本、帧类型、传输系统位元、片段与次序位元、地址字段和顺序控制字段,这些字段必须通过真实性的检验,又不经过加密。AAD的最后两个字段–来自MAC标头的第四个地址字段(如果使用无线传输系统)以及服务品质标头信息字段是可选的。AAD结构如图1-25所示,其中,A1、A2、A3和A4分别代表MPDU中的四个地址;FC是MPDU帧控制字段;SC是序列号控制字段;QC是QoS控制字段。

 

image027.jpg   

图 1- 25  AAD结构

从MAC头部中提取信息与PN组成CCMP nonce。由封包号码以及传送端地址构成的CCMP nonce使得不同的工作站能够拥有相同的封包编号。Nonce同时包含QoS会用到的优先性数据,Nonce结构如图1-26所示。Nonce Flags子字段构造如图1-27所示,协商为管理帧保护模式时Management 位置1,否则置0。

 

image028.jpg

图 1- 26  Nonce 结构

image029.jpg

图 1- 27  Nonce Flags构造

3)      构造八字节的CCMP头部,添加到MAC头部和明文数据之间。CCMP头部的功能有两个。第一,头部中包含的48比特的分组号PN能够防止报文受到重放攻击。第二,能够在多点传送时通知接收端选用哪一组密钥。CCMP[22]头部字段中,6个字节用来表示48比特分组号值。CCMP将构成PN的六个位元组拆开,然后把密钥识别码Key ID填充进去。CCMP头部字段当中包含四个密钥槽。扩展初始向量Extended IV位元在CCMP中永远被设为1,这是因为报文数量可能非常多,导致PN字段值可能非常大,必定要用八个位元组的标头才能满足要求。CCMP标头帧格式图1-28所示。

 image030.gif

图1- 28  CCMP 封包格式 

4)      把Nonce、AAD、CCMP头部和明文数据从左至右排成序列,再以128比特为单位分组,当最后一个分组不够128比特时,补零填充。而后计算MIC值,并添加至明文数据之后,用于保证MAC头部、CCMP头部和明文数据的完整性。

5)      加密明文数据与MIC值,生成密文。

6)      将MAC头部、CCMP头部和密文数据够成的报文放入队列中待传。

AES在CBC-Mac操作模式下计算MIC时,输入的第一个分组的内容来源于Nonce,第二个和第三个分组的内容均来源于AAD。除前三个分组之外才是用户数据。如图1-29所示。

image031.gif

图 1- 29  明文分组序列

AESCTR模式下执行加密操作时,不加密MAC头和 CCMP头。仅加密明文数据部分和MIC。并且对二者的加密是分开进行的。首先把用户数据部分以128 比特为单位进行划分再对各数据块加密。最后一个分组不足 128比特也不用进行填充,直接取计数器加密结果的相同比特与其进行异或操作即可。这和CTR属于流模式的结构有关。

密文传送至接收端之后,接收端还原得到明文并检测接收数据的有效性还需要经历许多过程如图1-30所示。

1)     首先接收端根据密文消息序列的MAC头部中的源MAC地址选择正确的密钥。

2)     在CCMP头部中,PN以明文形式被传送。接收端将读取到的PN值和接收到的上一帧的PN值做比较。前者小于后者时,该帧被认为是上一个帧的重传而被丢弃。

3)      假定PN值匹配,就在CTR操作模式下用AES算法解密报文。解密要用到CTR的初始值。接收端从收到的帧中提取AAD与CCMP nonce。而后根据这二者的值计算CTR的初始值。AES解密与加密过程类似。先使用AES加密CTR的值,再运用加密的结果与收到的密文数据执行异或操作,还原出明文数据与MIC值。

4)     接收端按照与发送端同样的方式计算MIC值。若计算所得结果与收到的报文中携带的MIC值相同,表明该帧有效;若存在差异,就能判定消息在传递

过程中已被篡改,接收端会丢掉该帧。

5)     如果帧有效,CCMP会把解密后的报文的MAC头和CCMP头去掉,而后把去掉MAC头和CCMP头的明文分组向上层传递,将该分组与其它分组重组后获得完整的明文数据。 

image032.gif

图1-30  CCMP 解封包过程

2.3.4  CCMP安全性分析

CCMP的安全性主要取决于AES CCM

和无线局域网操作相关的信息存放在802.11MAC帧头中,以明文形式传送。若这些信息被伪造,接收端能够通过AES CBC-MAC模式下计算出的MIC值检测出来,有效地防止重放攻击。

CCMP中,AES加密算法在CTR 模式与CBC-MAC模式下使用同一个密钥。很多人可能会怀疑其安全性。需要注意的是,这个相同的密钥并未直接用于加密,而是先和初始化IV结合产生出一个新的密钥。 CTRCBC-MAC模式构造IV的方法不同,因此二者生成的直接用于加密的密钥也不同。这种相同密钥不同 IV的方法的安全性已经通过密码学专家的确认。

AESCCM不仅具有可靠的理论基础,而且经受了长期实践的检验,备受网络安全界专家的青睐。以二者为基础的CCMP 是目前无线局域网内等级最高的安全机制,必定会在今后的无线局域网产品中普及应用。

* 原创作者:魅影儿,本文属FreeBuf原创奖励计划,转载请注明来自FreeBuf.COM

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

目录

一.物联网安全概述

二.物联网安全威胁现状及预防

2.1.物联网通信协议安全

2.2.物联网设备安全现状

2.2.1. IOT设备通用漏洞按厂商排名

2.2.3. IOT设备通用漏洞按风险技术类型分布

2.2.4. IOT设备通用漏洞按设备标签类型分布

2.2.5. IOT设备事件型漏洞按设备标签类型分布

2.2.6. 传统网络设备漏洞收录统计

2.2.7. 典型IOT设备漏洞案例

2.3.云安全

2.3.1. 数据库信息泄露

2.3.2. 服务配置信息明文存储在云上

2.3.3. 虚拟化漏洞

三.    企业安全

3.1.为什么做安全?

3.2.企业需要什么样的安全?

3.3.如何做好安全?

一.物联网安全概述

物联网定义:日常物品(如电视、冰箱、空调、灯光、窗帘)的有网络连接,允许发送和接收数据。

万物互联(IOT)时代已经到来,随着智能硬件创业的兴起,大量智能家居和可穿戴设备进入了人们的生活,根据Gartner 报告预测,2020年全球IOT物联网设备数量将高达260亿个。但是由于安全标准滞后,以及智能设备制造商缺乏安全意识和投入,物联网已经埋下极大隐患,是个人隐私、企业信息安全甚至国家关键基础设施的头号安全威胁。试想一下,无论家用或企业级的互连设备,如接入互联网的交通指示灯,恒温器,或医用监控设备遭到攻击,后果都将非常可怕。

物联网总的体系结构通常由执行器、网关、传感器、云和移动app五部分组成。

 image001.png

移动app(Mobile):移动设备大多使用的,在设备上的应用程序,以实现手机端控制 IoT环境来进行互动;

云(Cloud):Web界面或API 托管用于收集数据的云端web应用和大型数据集分析。一般来说,就是在做信息与其它方资源共享时使用;

网关(Gateway):用于收集传感器信息和控制中心;

执行器(Actuator):通过物理过程控制事物,如空调机组、门锁、窗帘;

传感器(Sensor):用于检测环境,例如光、运动、温度、湿度、水/ 电量;

物联网根据业务形态主要分为工业控制物联网、车载物联网、智能家居物联网。不同的业务形态对安全的需求不尽相同。

工业控制物联网:涉及到国家安全、再加上目前工业控制网络基本是明文协议很容易遭受攻击。所以很早就有很多安全公司看到这块蛋糕:威努特、匡恩网络等已经完成市场布局。主要产品形态:工控防火墙、工控漏洞挖掘、主机白名单产品。安全需求基本是传统安全的思路。

车载物联网:涉及到驾车人生命安全。但是目前是争标准的时代,目前国内厂商360在这方面有所建树。在标准未确定前,安全厂商都想做升级版的 OBD,嵌入式安全硬件。国外相关安全厂商产品形态大致是OBD防火墙、云端大数据分析异常监控等。安全需求集中在车载核心物联网硬件安全上。

智能家居物联网:涉及到个人家庭隐私安全。这一块的安全投入,比较少。但是大的家电企业相对来说会多一点。这也是安全厂商的机会。目前我们公司的产品形态主要是智能家居物联网,文中后续会对这块重点关注。

要想做物联网安全,首先要了解企业级物联网架构。 

智能家居物联网:

image003.jpg

当前一个典型的物联网项目,从组成上来讲,至少有三部分:一是设备端;二是云端;三是监控端。三者之间遵照通信协议完成消息传输。物联网安全的威胁风险也主要来自于这四部分。

二.物联网安全威胁现状及预防

惠普安全研究院调查的10个最流行的物联网智能设备后发现几乎所有设备都存在高危漏洞,主要有五大安全隐患,一些关键数据如下:

80%的IOT设备存在隐私泄露或滥用风险;

80%的IOT设备允许使用弱密码;

70%的IOT设备与互联网或局域网的通讯没有加密;

60%的IOT设备的web 界面存在安全漏洞;

60%的IOT设备下载软件更新时没有使用加密;

读一下网上关于物联网安全的报道,我们会发现很多与安全相关的骇人听闻的事件,例如:汽车被黑客远程操纵而失控;摄像头被入侵而遭偷窥;联网的烤箱被恶意控制干烧;洗衣机空转;美国制造零日漏洞病毒,利用 “震网”攻入伊朗核电站,破坏伊朗核实施计划等,这些信息安全问题已经影响到了我们的人身、财产、生命安全乃至国家安全。

2.1.物联网通信协议安全

需要物联网厂商提供协议访问API接口,以及访问证书,这样可以更全面的监控物联网设备,更好判断异常现象。针对MQTT 协议,如果是XMPP,建议不要使用这种不支持TLS的物联网协议,协议本身就缺乏安全考虑。自由协议,建议是站在巨人的肩膀上做事情,自己造轮子会存在很多缺陷,所以不建议用。如果出于成本考虑,协议本身建议增加部分安全限制。

2.2.物联网设备安全现状

2.2.1. IOT设备通用漏洞按厂商排名

2016年CNVD收录IOT设备漏洞 1117个,漏洞涉及Cisco、Huawei、Google 、Moxa等厂商。其中,传统网络设备厂商思科(Cisco)设备漏洞356条,占全年 IOT设备漏洞的32%;华为(Huawei)位列第二,共收录155 条;安卓系统提供商谷歌(Google)位列第三,工业设备产品提供厂商摩莎科技(Moxa)、西门子(Siemens )分列第四和第五。

image005.png

2.2.3. IOT设备通用漏洞按风险技术类型分布

2016年CNVD收录IOT设备漏洞类型分别为权限绕过、拒绝服务、信息泄露、跨站、命令执行、缓冲区溢出、 SQL注入、弱口令、设计缺陷等漏洞。其中,权限绕过、拒绝服务、信息泄露漏洞数量位列前三,分别占收录漏洞总数的23%,19%, 13%。而对于弱口令(或内置默认口令)漏洞,虽然在统计比例中漏洞条数占比不大(2%),但实际影响却十分广泛,成为恶意代码攻击利用的重要风险点。

image007.png

2.2.4. IOT设备通用漏洞按设备标签类型分布

2016年CNVD公开收录1117个 IOT设备漏洞中,影响设备的类型(以标签定义)包括网络摄像头、路由器、手机设备、防火墙、网关设备、交换机等。其中,网络摄像头、路由器、手机设备漏洞数量位列前三,分别占公开收录漏洞总数的10%,9% ,5%。

image009.png

2.2.5. IOT设备事件型漏洞按设备标签类型分布

根据CNVD白帽子、补天平台以及漏洞盒子等来源的汇总信息,2016 年CNVD收录IOT设备事件型漏洞540个。与通用软硬件漏洞影响设备标签类型有所不同,主要涉及交换机、路由器、网关设备、 GPS设备、手机设备、智能监控平台、网络摄像头、打印机、一卡通产品等。其中,GPS设备、一卡通产品、网络摄像头漏洞数量位列前三,分别占公开收录漏洞总数的22% ,7%,7%。值得注意的是,目前政府、高校以及相关行业单位陆续建立一些与交通、环境、能源、校园管理相关的智能监控平台,这些智能监控平台漏洞占比虽然较少( 2%),但一旦被黑客攻击,带来的实际威胁却是十分严重的。

image011.png

2.2.6. 传统网络设备漏洞收录统计

根据CNVD平台近五年公开发布的网络设备(含路由器、交换机、防火墙以及传统网络设备网关等产品)漏洞数量分布分析,传统网络设备漏洞数量总体呈上升趋势。 2016年CNVD公开发布的网络设备漏洞697条,与去年环比增加27% 。 

image013.png

2.2.7. 典型IOT设备漏洞案例

Android NVIDIA摄像头驱动程序权限获取漏洞

Lexmark打印机竞争条件漏洞

格尔安全认证网关系统存在多处命令执行漏洞

多款mtk平台手机广升FOTA服务存在system 权限提升漏洞(魅魔漏洞)

Android MediaTek GPS驱动提权漏洞

多款Sony网络摄像头产品存在后门账号风险

网件Netgear多款路由器存在任意命令注入漏洞

Pulse Secure Desktop Client(Juniper Junos Pulse)权限提升漏洞

Cisco ASA Software IKE密钥交换协议缓冲区溢出漏洞

Fortigate防火墙存在SSH认证“后门”漏洞

2.3.云安全

黑客入侵智能设备并不难,很多时候它们不需要知道物联网智能设备有哪些功能以及如何运作的。只要它们能进入与智能设备连接的相关网站,他们就能操控物联网设备,而设备连接的网站通常都部署在云端,因此保护好云端安全也是保护好物联网安全的关键环节,云端一般包含三部分:web 前台+web后台+中间件。

根据对2016年云产品的调研,发现云安全主要有十二大威胁,云服务客户和提供商可以根据这些威胁调整防御策略。

安全威胁 防御策略
数据泄露 采用多因子身份认证和加密措施
凭据被盗和身份认证如同虚设 妥善保管密钥,建立防护良好的公钥基础设施。定期更换密钥和凭证,让攻击者难以利用窃取的密钥登录系统
界面和API被黑 对API和界面引入足够的安全机制,比如“第一线防护和检测” ;威胁建模应用和系统,包括数据流和架构设计,要成为开发生命周期的重要部分;进行安全的代码审查和严格的渗透测试
系统漏洞利用 修复系统漏洞的花费与其他IT支出相比要少一些。部署IT过程来发现和修复漏洞的开销,比漏洞遭受攻击的潜在损害要小。管制产业(如国防、航天航空业)需要尽可能快地打补丁,最好是作为自动化过程和循环作业的一部分来实施。变更处理紧急修复的控制流程,要确保该修复活动被恰当地记录下来,并由技术团队进行审核。
账户劫持 公司企业应禁止在用户和服务间共享账户凭证,还应在可用的地方启用多因子身份验证方案。用户账户,甚至是服务账户,都应该受到监管,以便每一笔交易都能被追踪到某个实际的人身上。关键就在于,要避免账户凭证被盗。
恶意内部人员 企业要自己控制加密过程和密钥,分离职责,最小化用户权限。记录、监测和审计管理员活动的有效日志。
APT(高级持续性威胁)寄生虫: APT渗透进系统,建立起桥头堡,然后,在相当长一段时间内,源源不断地,悄悄地偷走数据和知识产权。跟寄生虫没什么区别。   定期意识强化培训,使用户保持警惕不被诱使放进APT,IT部门需要紧跟最新的高级攻击方式。不过,高级安全控制、过程管理、时间响应计划、以及 IT员工培训,都会导致安全预算的增加。公司企业必须在安全预算和遭到APT攻击可能造成的经济损失之间进行权衡。
永久的数据丢失 多地分布式部署数据和应用以增强防护; 采取足够的数据备份措施,坚守业务持续性和灾难恢复最佳实践;云环境下的日常数据备份和离线数据存储。
调查不足 每订阅任何一个云服务,都必须进行全面细致的尽职调查,弄清他们承担的风险。
云服务滥用 客户要确保提供商拥有滥用报告机制。尽管客户可能不是恶意活动的直接猎物,云服务滥用依然可能造成服务可用性问题和数据丢失问题。
拒绝服务攻击 DoS攻击消耗大量的处理能力,最终都要由客户买单。尽管高流量的DDoS攻击如今更为常见,公司企业仍然要留意非对称的、应用级的DoS 攻击,保护好自己的Web服务器和数据库。
共享技术,共享风险 采用深度防御策略,在所有托管主机上应用多因子身份验证,启用基于主机和基于网络的入侵检测系统,应用最小特权、网络分段概念,实行共享资源补丁策略。

近年来,云端应用安全事件频发。

2.3.1. 数据库信息泄露

案例:

某云平台是面向个人、企业和政府的云计算服务,206年3 月被曝出存在门户管理后台及系统管理员账户弱口令,通过登录账号可查看数十万用户的个人信息。通过获取的用户个人账户密码能够登录客户应用平台,查看应用配置信息,然后获取业务安装包、代码及密钥数据等敏感信息,进一步获取数据库访问权限、篡改记录、伪造交易、瘫痪系统等。这样一次看似简单的数据泄露事件,发生在云平台门户,造成的影响非比寻常。

产生原因:

账户弱口令容易被暴力破解。

预防:

增加密码复杂度,设置好记难猜的密码。

2.3.2. 服务配置信息明文存储在云上

案例:

2014年8月,专业从事Paas服务的某云被曝出由于服务器权限设置不当,导致可使用木马通过后台查看不同客户存放在云上的服务配置信息,包括 WAR包、数据库配置文件等,给托管客户的应用服务带来了巨大的安全隐患。

产生原因:

云服务商的服务器权限设置不当。

预防:

使用云平台的用户加密存储放在云上的服务配置信息。

2.3.3. 虚拟化漏洞

案例:

“传送门事件”—越界读取内存导致跨虚机执行任意代码。

产生原因:

云平台的虚拟化漏洞导致能够在宿主机上进行越界内存读取和写入,从而实现虚拟机逃逸。

预防:

经调研,大部分云端的威胁风险都来自于云服务提供商自身的平台漏洞,但云服务使用者过于简单的应用部署以及对敏感数据保护的不重视,也是导致威胁风险的重要原因。

image015.png

对于云服务使用者,不能把安全防护完全寄托在云服务提供商身上,必须考虑自保。云服务使用方需要重点保护其云端应用核心代码、关键数据及其系统访问安全,可分别从云端代码加固、数据安全保护、云端安全接入三个维度,设计一套安全防护体系。

image016.png

云服务使用者在应用层面对其云端代码、数据及系统接入进行安全保护,保证云端应用在不可信环境下的安全。云服务商需要进行云平台基础设施安全保护,提供云平台虚拟化、网络、配置、漏洞等多方面的安全保护功能。

构建云端安全可信的运行环境,需要云服务提供商和使用者的共同努力,加大黑客进入与物联网设备连接的网站的难度,进而提升物联网安全度。

三.企业安全

3.1.为什么做安全?

企业做安全的驱动力主要源于以下几个方面:

1).面临来自各方面的安全威胁

譬如:外部黑客、网络黑产、竞争对手、内鬼等

2).面临各种安全挑战

譬如:安全漏洞、网络攻击、勒索、敏感信息泄露等

3).安全问题会对公司运营、业务发展造成不良影响

譬如:经济损失、用户流失、财产损失、声誉受损、公信力下降等

3.2.企业需要什么样的安全?

虽然各个企业由于自身业务特性有所不同,但还是有很多共性的,例如:

1).数据安全

数据安全是所有互联网公司最核心的安全需求,也是大多数网络企业高管最为关注的安全问题。目标是保障企业敏感数据的安全、可控。

2).在攻防对抗中占据主动地位

能够掌握企业整体的安全态势,可主动发现潜在安全风险,及时知道谁、什么时间、做过什么样的攻击、攻击是否成功、目标系统受影响程度,并且在第一时间内解决遇到的安全问题。

3).保障业务安全、连续、可用

尽可能降低因网络攻击造成业务系统受影响的安全风险,比如最常见的DDOS、CC 攻击。

3.3.如何做好安全?

1).树立正确的安全观

安全是相对的。企业绝不是做一次渗透测试、找安全公司提供个安全解决方案或者购买一些安全产品及服务就可以搞定的事情。安全是一个整体的、动态的、需要长期做且持续投入的事情。

2).企业安全完整视角

互联网企业安全包含以下几大部分:

image017.png 

人们总想着把任何东西都交给互联网,但往往会发生严重的安全错误。目前,我们还处于物联网早期,很多东西并未联网。但一旦它们互通互联,无论对普通用户还是对黑客来说,都会有非常大的利用价值。这就要求公司应当把安全因素排在首位,将保护措施植入到设备中。大多数错误是由于安全目标不明确,缺乏经验和意识。我们必须采取安全的物联网策略,而不是期望它们主动来给我们安全。面对物联网的安全危机,物联网智能设备厂商进行安全建设时可参考以下建议:

1. 对生产的智能产品进行全面的安全审计;

2. 企业生产IOT产品前需要部署基本的安全标准;

3. 将安全融入产品生命周期,在产品还处于设计阶段就接受隐私和风险评估认证,比如当用户在使用可能有安全隐患的网络时,强制他们修改密码或开启加密服务;

针对传统的连接互联网的网络以及传统的云端架构还是需要使用传统边界防护解决方案。

a.)带防火墙模块硬件IPS:可以限制App 访问的端口,对传统的SQLi、XSS等做检测;

b.)WAF:web应用防火墙,主要是通过上下文语义关联对 OWASP Top 10攻击类型做检查和阻断;

c.)定期对后端web应用、数据库服务器、物联网大数据分析平台等做操作系统、中间件、数据库漏洞扫描。建议配合渗透测试发现更多问题。

调研了各个物联网安全公司,发现它们大致的解决方案如下:

a.)对IOT设备进行资产管理

快速发现连接到网络的IoT设备;

已经连接的IoT设备可视化;

配置检测、基线检测;

b.)快速安全响应

快速检测到异常终端;

隔离可疑应用程序和停止攻击扩散到IoT网络;

c.)通过大数据分析IoT事件,预测其安全状态、给出预防建议

d.)IoT设备上安装状态防火墙、保证通讯协议安全

各制造商与开发商为了有效降低风险并提升物联网设备的安全性水平,可以从以下六个方面入手。

   
物理安全 开发商应当在设计之初就将继承化防篡改措施纳入考量,从而确保产品不会被恶意人士所解码。另外,确保设备在被突破后其中全部与身份、认证以及账户信息相关的数据都被擦除,这将使得相关信息不会被攻击者利用。如果选择将PII存储在设备之内,那么远程擦除功能将成为必要配备
设备不要留下后门 目前,很多机构会向设备中添加后门,从而在必要时进行监控或者满足执法机构提出的要求。这种做法会对最终用户的信息完整性与安全性造成严重损害。制造商应当确保产品内不存在恶意代码或者后门,且设备UUID不可被复制、监控或者捕捉。这样我们就能够确保设备在联机注册过程中不会由于监控或者非法窃听机制的存在而导致重要信息泄露。
安全编码 物联网开发商应当严重遵循安全编码时间,并将其作为设备软件构建流程中的重要组成部分。着眼于质量保证与漏洞识别/整治,我们利用这种方式简化开发生命周期中的相关保护工作,同时轻松降低潜在风险。
认证与设备识别 为每台设备提供唯一身份并配合理想的安全认证机制,使设备自身拥有安全连接能力以及后端控制系统及管理后台。如果每台设备皆拥有自己的独特身份,则企业将能够了解当前通信设备的宣称身份是否属实。要实现这项目标,需要使用PKI等个别设备识别解决方案。
加密 在利用物联网解决方案时,企业必须对不同设备及后端服务器之间的往来流量进行加密。确保各操作命令经过加密,且通过签名或者强编码保证完整性。另外,由物联网设备收集到的任何敏感用户数据也应该被加密。
简化更新流程 建立对设备的轻松升级能力,这样bug与安全更新就能够更为轻松地得到部署与管理。

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

OpenVAS,即开放式漏洞评估系统,是一个用于评估目标漏洞的杰出框架。功能十分强大,最重要的是,它是“开源”的——就是免费的意思啦~

它与著名的Nessus“本是同根生”,在Nessus商业化之后仍然坚持开源,号称“当前最好用的开源漏洞扫描工具”。最新版的Kali Linux(kali 3.0)不再自带OpenVAS了,所以我们要自己部署OpenVAS漏洞检测系统。其核心部件是一个服务器,包括一套网络漏洞测试程序,可以检测远程系统和应用程序中的安全问题。

但是它的最常用用途是检测目标网络或主机的安全性。它的评估能力来源于数万个漏洞测试程序,这些程序都是以插件的形式存在。openvas是基于C/S(客户端/服务器),B/S(浏览器/服务器)架构进行工作,用户通过浏览器或者专用客户端程序来下达扫描任务,服务器端负责授权,执行扫描操作并提供扫描结果。

本文档属于部署方案文档,详细介绍了部署方法,搭建部署过程中有很多踩过的坑,这里整理出来供参考。

OpenVAS系统架构

一套完整的openvas系统包括服务器端和客户端的多个组件,如下图所示:

image001.jpg

服务器层组件(建议都安装) 客户层组件(任选其一安装即可)
OpenVAS-scanner(扫描器) 负责调用各种漏洞检测插件,完成实际的扫描操作。 OpenVAS-cli(命令行接口) 负责提供从命令行访问OpenVAS服务层程序。
OpenVAS-manager(管理器) 负责分配扫描任务,并根据扫描结果生产评估报告。 Greenbone-security-assistant(安全助手) 负责提供访问OpenVAS服务层的Web接口,便于通过浏览器来建立扫描任务,是使用最简便的客户层组件。
OpenVAS-administrator(管理者) 负责管理配置信息,用户授权等相关工作。 Greenbone-Desktop-Suite(桌面套件) 负责提供访问OpenVAS服务层的图形程序界面,主要在windows系统中使用。

kali Linux安装openvas

我这里是在kali linux系统上安装的openvas,最新版本的kalilinux系统是不带openvas的

注意:openvas服务器端仅支持安装在linux操作系统中,客户端安装在windows和Linux系统均可。

我的linux系统版本号如下:

image002.jpg

image003.jpg

虚拟机的网络连接方式如下,设置为桥接模式,设置为NAT。

image004.jpg

安装openvas过程

1. 更新软件包列表:

         apt-get update

image005.jpg

2. 获取到最新的软件包:

         apt-get dist-upgrade

image006.jpg

3. 安装openvas

         apt-get install openvas

执行以上命令后,如果没有报错,说明已经成功安装openvas。

kali Linux配置openvas

4.下载并更新OpenVAS库

openvas-setup

image007.jpg

在更新openvas库过程中创立了证书,下载及更新了一切扫描插件。

5.在更新OpenVAS库时,自动为admin用户创建了一个密码,只是该密码比较长,不容易记忆,我们使用如下命令将admin密码修改为容易记忆的密码,以kali123为例:

         image008.jpg

另外,我们新增一个普通用户wdl1,如下图:

image009.png

6.openvas-check setup

这个命令用于查错并用来确认OpenVAS是否成功安装,用apt-get安装总会出现这样那样的错误,我们可以用openvas-check-setup查看安装到哪步出错了,以及缺少什么东西。

image010.jpg

当出现如下结果时,表示安装成功:

image011.jpg

然后输入openvasmd –rebuild:rebuild the openvasmd database

image012.png

安装完成后,在应用程序—〉漏洞分析中会出现openvas这个应用,如下图:

image013.png

注意:openvas安装好之后并没有openvas-restart命令和openvas-status命令,该命令需要自定义安装。

在/usr/bin目录下,新建两个文件夹,分别为openvas-restart和openvas-status,然后赋予这两个文件可执行的权限:

image014.jpg

openvas-restart和openvas-status内容分别如下:

image015.png

之后就能够使用openvas-restart命令重启系统,使用openvas-status察看openvas系统状态了:

image016.jpg

image017.jpg

可以看到openvas目前处于运行状态。

kali linux启动openvas

由于OpenVAS是基于C/S,B/S架构进行工作的,所以,如果要使用该漏洞检测系统,必须先将OpenVAS服务启动,客户端才能连接进行测试。

双击应用程序中的openvas start启动openvas服务,出现如下界面:

image018.png

或者输入命令行程序openvas-start来启动openvas服务

image019.jpg

使用客户端访问openvas服务器

当openvas服务成功启动后,用户就可以连接openvas服务器并进行扫描了。根据前面的介绍,可知openvas有三种不同的客户端,分别是:OpenVAS命令行接口,Greenbone安全助手和Greenbone桌面套件。而且客户端能够用于各种操作系统。在kali linux中,默认安装的是Greenbone安全助手。

 本部署方案中使用最简单的浏览器客户端方式访问OpenVAS服务。因为,这种使用方式不仅简单,而且不需要客户额外安装应用程序,避免了枯燥的命令行方式,用户在任何操作系统中只要通过浏览器就可以在本地或远程连接OpenVAS服务器来对目标主机或网络进行漏洞检测。

通过使用浏览器客户端访问openvas服务器进行漏洞检测

然后我们使用客户层组件Greenbone-security-assistant访问openvas服务器,通过浏览器来建立扫描任务。

image020.jpg

 

image021.jpg

绿骨安全助手 GSA( Greenbone Security Assistant)是开放漏洞评估系统 OpenVAS(OpenVulnerability Assessment System)的基于网页的用户图形界面。 GSA 通过 OpenVAS Management Protocol (OMP) 连接 OpenVAS Manager。 通过实现完整的 OMP 特性集合,GSA 提供了一个直接了当的、非常强力的途径以管理网络漏洞扫描。

配置外部访问

安装完成后,openvas默认设置的监听地址为127.0.0.1,每次使用都只能用linux虚拟机打开浏览器通过https://127.0.0.1:9392来进行登录扫描,不如通过自己的电脑浏览器连接到openvas服务器直接进行扫描来的方便。

如果openvas安装在远程服务器或者虚拟机里面,则必须用服务器或者虚拟机打开浏览器来扫描,这样比较麻烦。用户更加希望,通过自己的电脑浏览器连接到openvas服务器,直接进行扫描。下面介绍配置外部访问的方法:

openvas新版本有两种方式控制openvas的开关,一种是服务的方式,一种是脚本的方式。

1.服务的方式

这种方式是通过openvas-start/openvas-stop脚本启动和关闭的,这两个脚本里调用的是service指令。启动openvas服务的脚本都存放在/lib/systemd/system下。

修改三个配置文件openvas-manager.service,openvas-scanner.service和greenbone-security-assistant.service,将配置文件中的监听IP由127.0.0.1改为0.0.0.0(相比于更改为openvas服务器的实际IP地址,改为0.0.0.0会更好,因为0.0.0.0代表本机的任意地址,适用于服务器有多个IP或者服务器IP有变动的情况)。修改后的三个配置文件内容如下:

image022.jpg

image023.jpg

image024.jpg

2.脚本的方式

需要三个脚本控制开启和关闭openvas,

/etc/init.d/openvas-manager  //管理manager服务

/etc/init.d/openvas-scanner  //管理scanner服务

/etc/init.d/greenbone-security-assistant //管理gsad服务

这三个脚本对应了三个配置文件,分别为:

/etc/default/openvas-manager

/etc/default/openvas-scanner

/etc/default/greenbone-security-assistant

image025.jpg

分别修改配置文件中的监听ip,由127.0.0.1改为0.0.0.0,保存。修改后三个配置文件的内容分别如下:

image026.jpg

image027.jpg

image028.jpg

察看openvas的监听地址,如下图:

image029.jpg

image030.jpg

或者使用ps aux | less命令查看系统目前正在运行的进程。

可以看到,openvas监听地址已由127.0.0.1变为0.0.0.0。

察看linux虚拟机的IP地址为192.168.9.208:

image031.jpg

在不登录linux服务器的情况下,即可在本机windows系统的客户端浏览器中输入https://192.168.9.208:9392/login/login.html 连接openvas服务器进行漏洞检测。

注意:要保证主机和虚拟机间能通信。经过在多台台式机测试,测试者都能通过自己台式机浏览器连接我部署的openvas漏洞检测系统进行主机和网络安全测试。

image032.jpg

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