I want a "Red Teaming"
Michael Schneider
These are the Risks of Miracast
Miracast can be used on wireless networks in infrastructure mode and via Wi-Fi Direct. This article is going to focus on its use over Wi-Fi Direct, which is often the preferred method of using Miracast. When using Wi-Fi Direct, latency and noise on the air is reduced since data is only transmitted once, and not twice as in infrastructure mode: Once to the access point (AP) and once again from the AP to the display. After layer 1/2 is established through Wi-Fi Direct, the endpoints can talk to each other via standard IPv4/IPv6 protocols.
Miracast uses RTSP in conjunction with RTP to stream data from the source to the display. RTSP is a control protocol used for initiating and directing the delivery of multimedia, and RTP is the application layer protocol used for its delivery. In the majority of cases, there is no prior security context, such as a PSK, or security anchor, such as a PKI, between the RTSP/RTP connection of source and display. Therefore, this connection is vulnerable to man-in-the-middle attacks (MITM). The only security there is, is provided by the layer 1/2 protocol, Wi-Fi Direct.
All Miracast devices we encountered during our research by default either uses no authentication at all or WPS PIN authentication. The Miracast device we encountered which gave inspiration to write this article used WPS for authentication by default. It displays a dynamic 4-digit WPS PIN on the screen which the client uses to authenticate. WPS is plagued by design and implementation flaws which often break its security.
In the case of our test device, the dynamic PIN did not refresh on failed authentication attempts. This simply allows brute-forcing the 4-digit PIN. Furthermore, the dynamic 4-digit PIN did not refresh after successful layer 2 authentication, but only after a RTSP/RTP session was established. This allows brute-forcing a PIN and reusing it later, such as in a rogue AP attack to MITM a legitimate connection. Even if such a major flaw didn’t exist, we were curious if the PIN could be retrieved through other means. One approach that came to mind was to set up a rogue access point and get an unsuspecting the client to connect to it. It turns out that the WPS specification has taken this attack scenario into account. However, there is significant room for potential implementation errors which could give us an advantage. From this point on the terms registrar and enrollee are used for the Miracast device receiving the connection and the source device respectively.
In order to prevent an attacker from creating a rogue registrar and being handed the PIN on a silver platter by the enrollee, the PIN is not exchanged in clear text. Furthermore, the enrollee and registrar both authenticate each other mutually. Even if the PIN is not exchanged in clear text, would it not be possible to brute force it since the algorithm the enrollee uses to get to whatever derivation is known? The specification thought of this as well. The PIN derivative which is transmitted is the HMAC-SHA-256 value of the PIN concatenated with a secret 128-bit nonce and other session data. Furthermore, the PIN is split in two and transmitted in two parts, which we need not worry about now and will only become important later. For now, the enrollee prepares two HMAC hashes which the specification calls E-Hash1
and E-Hash2
.
E-Hash1 = HMAC(E-S1 || PSK1 || PKE || PKR)
E-Hash2 = HMAC(E-S2 || PSK2 || PKE || PKR)
The key for the HMAC is derived from session parameters (negotiated Diffie-Hellman secret, two nonces shared at session initiation and enrollee’s MAC address) which are known and shared between enrollee and registrar. E-S1
and E-S2
are two separate 128-bit nonces which only the enrollee knows for now. PSK1
and PSK2
are the first 128 bits of the HMAC-SHA-256 of the first and second half of the PIN respectively. PKE
and PKR
are the public keys of the enrollee and registrar respectively.
Because the authentication is mutual, the registrar also generates two HMAC hashes in the same fashion with his own two secret nonces R-S1
and R-S2
R-Hash1 = HMAC(R-S1 || PSK1 || PKE || PKR)
R-Hash2 = HMAC(R-S2 || PSK2 || PKE || PKR)
In a next step, the enrollee and registrar share their HMAC hashes with each other. The addition of the secret nonces when generating the HMAC hashes prevents us from being able to brute force the PIN range. However, at this point, neither party can verify that the other used the correct PIN to generate the HMAC, because of the same unknown secret nonce. So, in a next step, the enrollee and registrar share the nonces they used one half at a time. First, the enrollee shares his secret nonce used to generate the E-Hash1
: E-S1
. The registrar now has all the values needed to calculate the same E-Hash1
value by using the correct first half of the PIN. If it is correct, the registrar responds with the secret nonce RS-2
. The enrollee verifies that the registrar knows the second half of the PIN and then proceeds to send the E-S2
nonce. By making both parties share their HMAC hashes before exchanging the secret nonces, they both need to commit to telling what they think the PIN is, before getting the chance to retrieve any information on the PIN. If the nonces later shared by any party show that a different PIN was used to generate the HMAC, the nonce exchange is halted prematurely, preventing the PIN from being leaked.
Assuming the best-case scenario where an 8-digit pin is used, there should be a theoretical possibility range of 100,000,000 combinations. When the registrar is vulnerable to brute force attacks, we can retrieve the PIN in 231 days in the worst-case scenario with a pace of 5 PINs per second. However, by splitting the PIN up into two parts, each 4-digit part can be brute forced separately. This equates to 10’000 combinations per half or 33 minutes in the worst-case at 5 PINs per second. The second half of the PIN does not even have to be brute forced at the registrar, since it can be brute forced offline instantly after the registrar shares his R-S2
nonce. Registrars with static PINs are completely compromised by this. If the registrar uses a dynamic PIN, he should generate a new PIN on failed authentication attempts to prevent such attacks. The Miracast device we had access to did not refresh the dynamic PIN on failed authentication attempts.
Knowing the PIN exchange process, we can revisit our rogue AP idea. When the enrollee tries to authenticate with us, it will leak the first half of the PIN in every case, because the enrollee goes first with sharing a secret nonce. After receiving the nonce E-S1
and responding with our own R-S2
, the enrollee will not carry on with sharing E-S2
, as he will have seen that we are not in possession of the PIN. However, the first half of the PIN is all we need. We can connect with the real registrar and supply the correct first half of the PIN alongside a bogus second half. Because we can demonstrate that we know the first half of the PIN, the registrar will respond with the R-S2
nonce, allowing us to brute force the second half of the PIN offline practically instantly. Since we already “locked in” our answer for what we believe the second half of the PIN is with E-Hash2
before the nonce exchange began, we cannot complete this authentication successfully. However, we gained the ability to retrieve the entire PIN with only a single failed authentication attempt at the registrar. If the registrar is anything but super tight, this approach will retrieve the valid PIN and enable successful authentication at the registrar. This approach may be beneficial when targeting registrars with elevated security measures such as rate limiting or temporary lockouts to combat brute force attacks or when a dynamic PIN refreshes after a few failed login attempts. The only registrars who stand a chance here are those which use dynamic PINs and refresh the dynamic PIN on every failed authentication attempt.
WPS is plagued by design flaws. Even in the best-case scenarios where dynamic PINs are used, security-breaking implementation errors seem to be prevalent. Because WPS is the only protective mechanism for Miracast in many setups, the use of Miracast to share content of any sensitivity should be well considered. Motivated attackers who get into wireless transmission range of the Miracast setup have significant chances of success. This may be especially relevant for high-value targets such as businesses. Implementors should understand the threat model and common attacks against WPS to avoid releasing vulnerable implementations to the market. Here, the WPS specification provides sufficient guidance in security relevant areas.
We are going to monitor the digital underground for you!
Michael Schneider
Marisa Tschopp
Michèle Trebo
Andrea Covello
Our experts will get in contact with you!