常問問題
WPA 安全漏洞
V1.0 - OCTOBER 16, 2017
Q: 發生了什麼事?
A: A
researcher has published a paper documenting fairly widespread vulnerabilities
in various implementations of WPA2. The vulnerabilities are related to
different key handshakes, used between the Wi-Fi supplicant (client) and the AP
(authenticator) to derive and install encryption keys. Different
implementations respond in different ways when keying handshake messages are retransmitted
– some of these responses did not anticipate that the retransmission may be due
to an attacker’s action rather than simple packet loss. Because these
vulnerabilities are related to implementation flaws, they can be fixed through
software updates.
One
vulnerability is related to 802.11r (also known as Fast BSS Transition). This
vulnerability is in the protocol itself, where the protocol does not adequately
protect against malicious attack. It is possible to mitigate this vulnerability
through a software update as well.
Q: 衝擊是什麼?
A:當成功的用AES-CCMP（大多數Wi-Fi網絡的默認操作模式）使用WPA2時，攻擊者可以在一 個通信
方向（從客戶端到AP）解密和重放數據包，但不能偽造數據包並將其注入網絡。
當使用WPA-TKIP（一種已經遭受嚴重安全漏洞的加密方案，不推薦使用） - 攻擊者可以解密，重放和偽
造數據包。
Q: 使此攻擊成為可能的原因?
A: Wi-Fi
uses AES-CTR (Advanced Encryption Standard in Counter Mode) to provide confidentiality.
With AES-CTR,
the combination of a specific key and nonce value should
only be used once to encrypt
a block of plaintext. If the combination
is used twice, an attacker can possibly decrypt the two pieces of plaintext –
particularly if the plaintext contains easily predicted values such as IP
packet headers.
The attack described in the paper does exactly this – it causes
various implementations of WPA2 to re- use the same key/nonce multiple times.
Q: 這攻擊很難實現嗎?
A: An
attacker must establish a man-in-the-middle position between a client and an
AP. Further, the AP must be
impersonating the MAC address of a legitimate AP, and must be on a different channel.
There are
existing tools that can create such a scenario. Someone will then need to write
code to attack the newly exposed vulnerability. Finally, tools will be needed
to perform decryption of traffic based on a reused nonce/key combination.
Aruba’s assessment is that this is within the capabilities of a skilled
attacker with cryptography and Wi-Fi experience, but it will likely take some
time before easy- to-use tools are developed.
Q: 為什麼這麼多廠商被攻擊?
A: The
IEEE 802.11 specification was silent about how to handle certain conditions, so
that an implementation could be 100% standard-compliant but still vulnerable.
In particular, the standard told implementers what to do, but not necessarily when
to do it. To protect against this vulnerability, implementers must add
additional state machine checks beyond what the standard requires. All vendors
worked from the same specification documents, which is why the flaw is widespread.
Q: 這會影響WPA2-PSK或是WPA2-Enterprise?
A: 兩者都會被影響. 這攻擊對抗key exchange handshake而非對抗authentication
exchange.
Q: 這影響 Wi-Fi infrastructure
(APs/controllers)、Wi-Fi clients或是兩者?
A: 兩者都會被影響
Q: 這意味著WPA2現在被攻破了?
A: No.
The vulnerability is due to implementation flaws (programmers did not
anticipate and guard against a particular set of circumstances when writing the
code) rather than a protocol-level weakness. Contributing to the problem was
insufficient/ambiguous guidance to developers in the 802.11 standard. All
vulnerabilities can be mitigated through software updates to affected systems
without the need for a change in the protocol.
Q: 會有額外的漏洞在未來被揭露嗎?
A: 所有最近已知的漏洞已經在這次被公開。我們預期這一連串的漏洞與額外的研究都有被私人研究與IEEE 802.11委員會展示。額外的漏洞有可能在未來被揭露。
Q: 這攻擊會暴露憑證或是 keys嗎?
A: 這攻擊不會揭露WPA2 authentication
credentials諸如密碼或是pre-shared keys.
不需要為了此漏洞修改密碼或是re-key一個Wi-Fi 網路.
Q: 對Aruba controlled Aps與運行ArubaOS 的Mobility Controllers的影響?
A: ArubaOS contains both authenticator and supplicant functionality. The two are affected differently:
·
As an authenticator (standard WPA2 functionality where the AP/controller
exchanges encrypted information with a Wi-Fi client), ArubaOS is not vulnerable to the key
reinstallation attack in the 4- way and group key handshakes. This is because
ArubaOS stores the latest value of the replay counter and will reject any
message that contains a different replay value.
·
As an authenticator in the 802.11r Fast BSS Transition (FT) handshake,
ArubaOS is vulnerable to the key
reinstallation attack. This is made possible because the first two messages of
the FT handshake do not contain a replay counter. Aruba has mitigated this
attack through a software update. Note that 802.11r is not enabled by default in ArubaOS; the majority of Aruba customers
will not be affected. For customers who have enabled 802.11r, disabling it will
prevent the attack. Bug 168097 is
tracking this issue.
·
The “mesh” feature of ArubaOS
allows APs to connect to other APs over wireless links for the purpose of
network extension. Mesh links are protected using WPA2, and the open-source
Linux “wpa_supplicant” utility is used to provide 802.1X authentication. The
research paper points out that wpa_supplicant is vulnerable to the key
reinstallation attack. Mesh is not
enabled by default in ArubaOS. For customers who have enabled this feature,
disabling it will prevent the attack. Bug
168489 is tracking this issue.
Q: 我需要升級ArubaOS嗎?
A: 推薦升級你的ArubaOS 軟體去緩解全部的漏洞
Q: 哪一個ArubaOS的軟體版本修復此問題?
A: 此漏洞被底下釋放出來的ArubaOS patch修復，這些ArubaOS都可以被馬上下載:
·
6.3.1.25
·
6.4.4.16
·
6.5.1.9
·
6.5.3.3
·
6.5.4.2
·
8.1.0.4
Q: ArubaOS 5.x, 6.1, 6.2,與6.5.2.x又如何呢?
A: ArubaOS
5.x reached its end-of-support date in May 2016 and is no longer supported or maintained.
Aruba 6.1 and 6.2 reached their end-of-support date in May 2015. See
http://www.arubanetworks.com/support-services/end-of-life/ for
more information.
ArubaOS 6.5.2.x was a “controlled release” with different support
policies than standard. The differences between 6.5.3.x and 6.5.2.x were
relatively minor at the time that 6.5.3 was introduced. Since that time,
6.5.2.x has not been maintained. Customers can migrate to 6.5.3.x with minimal
risk.
Q: Aruba Instant的影響是什麼?
A: InstantOS contains both authenticator and supplicant functionality. The two are affected differently:
·
As an authenticator (standard WPA2 functionality where the AP exchanges
encrypted information with a Wi-Fi client), InstantOS is not vulnerable to the key reinstallation attack in the 4-way and
group key handshakes. This is because InstantOS stores the latest value of the
replay counter and will reject any message that contains a different replay value.
·
As an authenticator in the 802.11r Fast BSS Transition (FT) handshake,
InstantOS is vulnerable to the key
reinstallation attack. This is made possible because the first two messages of
the FT handshake do not contain a replay counter. Aruba has mitigated this
attack through a software update. Note that 802.11r is not enabled by default in InstantOS; the majority of Aruba
customers will not be affected. For customers who have enabled 802.11r,
disabling it will prevent the attack. Bug
168101 is tracking this issue.
·
The “mesh” feature of InstantOS
allows APs to connect to other APs over wireless links for the purpose of
network extension. Mesh links are protected using WPA2, and the open-source
Linux “wpa_supplicant” utility is used to provide 802.1X authentication. The
research paper points out that wpa_supplicant is vulnerable to the key
reinstallation attack. Mesh is not
enabled by default in InstantOS 4.1 and higher – in previous versions of
InstantOS, mesh was enabled by default. For
customers who have enabled this feature, disabling it will prevent the
attack. Bug 168100 is tracking this issue.
·
IAP contains a feature called
“Wi-Fi Uplink”, which allows an IAP to connect as a Wi-Fi client to another AP.
This feature uses the open-source “wpa_supplicant” utility to provide 802.1X
authentication, and is vulnerable to the key reinstallation attack. Wi-Fi
Uplink is not enabled by default in
InstantOS. For customers who have enabled this feature, disabling it will
prevent the attack. Bug 168100 is
tracking this issue.
Q: 我需要升級InstantOS嗎?
A: 推薦升級你的ArubaOS 軟體去緩解全部的漏洞
Q: 哪一個InstantOS的軟體版本修復此問題?
A: 此弱點被底下釋放出來的ArubaOS patch修復，這些ArubaOS都可以被馬上下載:
·
4.2.4.9
·
4.3.1.6
·
6.5.3.3
·
6.5.4.2
Q: 我跟Aruba 沒有support contract 。我仍然可以下載新的軟體?
A: 本次事件， 不管support contract 的狀態為何，Aruba將提供軟體升級給任何需要的人，用在這網址裡的電話號碼清單聯絡Aruba Support
Q: How is Clarity Synthetic / Clarity Engine affected?
A: Some
customers have been beta-testing a new feature called “Clarity Synthetic,”
which allows an Aruba access point to act like a Wi-Fi client, connecting and
authenticating to another Aruba AP for the purpose of testing network
performance. Clarity Synthetic is not an ArubaOS feature in its current form
–
it is a separate system.
Clarity Engine contains the open-source Linux “wpa_supplicant” utility to
provide 802.1X authentication. The research paper points out that
wpa_supplicant is vulnerable to the key reinstallation attack. Customers
participating in the Clarity Synthetic beta should not use the feature until
they update the software. Clarity Engine 1.0.0.1 contains a fix for the vulnerability.
Clarity Synthetic differs
from “Clarity Live” – the latter is an ArubaOS feature that uses only passive
monitoring of wireless traffic to create performance statistics. Clarity Live
is not affected by the key reinstallation vulnerability.
Q: Aruba 501 Client
Bridge的影響為何?
A: The
client bridge acts as a Wi-Fi supplicant and incorporates the open-source
wpa_supplicant code. It is vulnerable in a similar way to other Aruba products
that contain supplicant functionality. Updated software is available for this
product to address the issue and may be downloaded from the HPE My Networking
Portal site.
Q: 其他Hewlett Packard
Enterprise (HPE)無線產品影響為何?
A: Aruba
has reached out to the teams responsible for the HP MSM series of controllers
and the HPE 8xx Unified WLAN Appliance series to obtain status. A separate
security advisory will be issued (https://www.hpe.com/us/en/services/security-vulnerability.html)
with full details. It has been reported that these products are not vulnerable to the key
reinstallation attack in the 4-way handshake or group key handshake when acting
as an 802.1X authenticator. The products do not support 802.11r and are not vulnerable to the FT handshake vulnerability.
Q: 到底Aruba在新軟體裡改變了什麼?
A: 大部份的Aruba特定漏洞來自於為了提供Wi-Fi client的某些功能而使用open-source的wpa_supplicant 軟體。 經過了與其他wpa_supplicant與ICASI合作，Aruba 提供patches去對付這些漏洞。 除此之外， Aruba確定nonce/PTK combination只能被使用一次，用於對付FT handshake漏洞。如果一個key必須被重安裝，一個新的nonce會被創造。
Q: 這個修復會導致任何的互動性問題嗎? 效能會降低嗎?
A: 此修復應該不會導致互動性問題。 Wi-Fi 聯盟新增了關於修復此漏洞之後與成員公司互動性的特定測試。Aruba參與了這個程序。這個修復應該也不會導致任何的效能下降或是漫遊時的延遲。
Q: 我沒辦法馬上升級軟體。有workarounds的方式嗎?
A: 有的。檢視上面關於ArubaOS 或InstantOS的解釋去確定workarounds的方式
停用漏洞功能將有效的緩解那些攻擊。
Q: 這workarounds對我來說不實際。如果我不升級會有什麼風險?
A: Risk will depend
on individual circumstances. For example, if all critical enterprise data is
protected in transit using HTTPS/TLS in addition to WPA2, then a partial loss
of WPA2 security may not be viewed as critical. In general, Aruba believes this
is an important update, but not an emergency update. It will take time
before attack tools become widely available. Once tools do become available,
the risk of decryption and replay appears to be limited to uni-directional
traffic from the client to the AP.
Q: The research paper
mentions that it is easier to attack the group key handshake on clients if the AP immediately installs a new group key. What does Aruba do?
A: Aruba
immediately installs the group key after sending Group Message 1, and does not
wait until all stations reply with Group Message 2. Aruba found through trial
and error that waiting for all stations to respond led to network instability
in enterprise networks. The problem in enterprise networks is that typically an
AP is dealing with a large number of clients. Clients may go into power-save
mode, may go to sleep, may roam out of Wi-Fi coverage, or disappear for a
number of other reasons. If the AP waits for all stations to acknowledge a
group key message, it may be left waiting forever – leaving the AP and stations
unable to send broadcast and multicast traffic in the interim. Therefore, the
decision was made to immediately install and begin using the new group key. Unfortunately, this behavior does make
attacking the group key easier when using an unpatched client device.
Q: 如果我升級Aruba軟體，會解決所有問題嗎?
A: 不一定。 Aruba只提供了Wi-Fi 網路的infrastructure side。 Client side也必需被考慮。你必須要確定是否有在網路中使用了有漏洞的裝置，像是筆電、平板、手機、或物聯網裝置。所有主要廠牌的Wi-Fi client 裝置都已經被通知有這樣的漏洞，而且大部份應該都有受到衝擊的情況與有可獲得的資訊。
另外，新資訊的獲得而迫使軟體的升級是可能的。如果Aruba知道額外的漏洞，這樣的的資訊將會經由Aruba的標準漏洞揭露程序傳達。
Q: 這意味著為了完整的防護，我必須升級infrastructure與clients嗎?
A: Updating
just one half of the solution does not effectively solve the problem. However,
an effective mitigation would be disabling 802.11r on the Aruba infrastructure
while updating clients that are vulnerable to the 4-way handshake vulnerability.
Q: 如果我在AP/controller上停用802.11r， clients仍然有FT handshake的弱點嗎?
A: 如果802.11r沒有在infrastructure上被啟用。 Clients將不會試圖使用FT handshake重新連繫。攻擊者將無法在這種情況下利用 FT
handshake vulnerability漏洞。
Q: 我可以偵測是否有人攻擊我的網路或是裝置嗎?
A: Aruba軟體會在per-client basis 上檢查replay counter
mismatches。 如果偵測被觸發，將會產生log message 。Log訊息以“Replay
Counter Mismatches“開頭，後面跟隨額外的細節。
Aruba已經釋放出新的 RFProtect (WIDS) 功能並且可以幫助偵測攻擊。這功能會在底下的ArubaOS被釋出:
·
6.4.4.16
·
6.5.1.9
·
6.5.3.3
·
6.5.4.2
·
8.2.0.0
Q: Aruba什麼時候發現這個的?
A: Aruba在July 15, 2017藉由其他的研究與在August 28, 2017的CERT Coordination Center發現了這個問題。Aruba也在September 12, 2017被ICASI通知。Aruba為了參與更多工業等級的討論而跟ICASI簽屬NDA 。
Q: 為什麼Aruba現在公開這個?
A: 一個這樣等級的漏洞需要多家廠商與其他團體的合作，所以回應與patches會被準備等到漏洞變得廣為人知。 The vendor community (represented by ICASI), in
cooperation with the author, CERT, and the Wi-Fi Alliance jointly agreed on
October 16 as the disclosure date for this
vulnerability.
Q: Aruba會提供特別的進階通知給任何客戶或是夥伴嗎?
A: 不會，Aruba不會從事選擇性的漏洞揭露。
Q: 有多少其他的廠商被影響?
A: 所有有Wi-Fi設備或clients的廠商多少都有被影響。
.
|
|
|
7
|
Q: 我可以在哪裡閱讀這次攻擊與弱點的細節?
A: 原始研究文件的標題是“Key
Reinstallation Attacks: Forcing Nonce Reuse in WPA2” 。出自Mathy Vanhoef 並被提交給在Computer and Communications Security 舉辦的第24次Association for Computing
Machinery (ACM)研討會。
沒有留言:
張貼留言