Blog de lapinhib0u

  • Evolution of 3GPP over-the-air security

    May 10, 2018

    I have written this page to have a centralized view of the radio interface security inside 3GPP technologies, from 2G to 5G. Getting a clear view of what is going on can be confusing and discouraging as it often requires to browse through dozens of 3GPP documents at the same time.

    The most important security functions are listed for each technology: authentication, confidentiality and integrity. I have tried to keep this as short as possible while keeping the most revelant information, such as which radio layers are involved and links to the specifications.

    GSM

    In this section, A3 and A8 are derivation functions implemented as part of the COMP128 algorithm. A5 functions are the encryption algorithms.

    Authentication

    The BTS authenticates the MS using a challenge-response scheme relying on a 128-bit shared secret Ki stored in the SIM card and the core network.

    1. MS ⟵ BTS : Authentication Request (128-bit RAND)
    2. MS ⟶ BTS : Authentication Response (32-bit SRES = A3(Ki, RAND))
    3. MS ⟵ BTS : Authentication Reject if SRES is incorrect

    Encryption

    Traffic encryption is initiated by the BTS after authentication by sending a Ciphering Mode Command to the MS. The message contains the encryption algorithm to use. The dedicated channels TCH and DCCH are then encrypted at the physical layer. The encryption 64-bit key Kc is A8(Ki, RAND).

    • A5/0 : no encryption
    • A5/1 : LFSR-based stream cipher, 64-bit key, broken
    • A5/2 : LFSR-based stream cipher, 64-bit key, broken, prohibited use
    • A5/3 : KASUMI in OFB mode, 64-bit key extended to 128 bits (3GPP TS 55.216)

    In the event of a handover from a UTRAN, the mobile can use its UMTS security context to switch to a 128-bit algorithm. The 128-bit encryption key K128 is HMAC-SHA256(CK || IK, "\x32") truncated to 128 bits (3GPP TS 33.102, 3GPP TS 33.220).

    Integrity

    Traffic is not integrity protected in GSM.

    GPRS

    Authentication

    GPRS use a challenge-response authentication scheme similar to GSM.

    1. MS ⟵ BTS : Authentication and Ciphering Request (RAND, algorithm)
    2. MS ⟶ BTS : Authentication and Ciphering Response (SRES = A3(Ki, RAND))
    3. MS ⟵ BTS : Authentication and Ciphering Reject if SRES is incorrect

    Encryption

    The traffic is encrypted at the LLC layer. The 64-bit encryption key GPRS-Kc is A8(Ki, RAND). Contrary to GSM, the traffic is asymmetrically encrypted by using a direction bit. The sequence number of the LLC packet is also used in the computation. Some GPRS encryption algorithms are not publicly documented.

    • GEA0 : no encryption
    • GEA1 : undocumented, LFSR-based stream cipher, 64-bit key, broken, prohibited use
    • GEA2 : undocumented, LFSR-based stream cipher, 64-bit key
    • GEA3 : KASUMI in OFB mode, 64-bit key extended to 128 bits, similar to A5/3 (3GPP TS 55.216)

    As with GSM, the device can use a 128-bit algorithm if it already has a UMTS security context. The 128-bit encryption key K128 is HMAC-SHA256(CK || IK, "\x32") truncated to 128 bits.

    Integrity

    Traffic is not integrity protected in GPRS.

    UMTS

    UMTS uses a set of function f1 to f9 for security purposes. Derivation functions f1 to f5 are not standardized. The specifications provide two example algorithms sets: MILENAGE based on AES (3GPP TS 35.206), and TUAK based on SHA3 (3GPP TS 35.231).

    Authentication

    UMTS uses a mutual authentication between the mobile and the base station. It relies on a 128 or 256-bit shared secret key K stored in the USIM and the core network. The mobile and the network keep track of a 48-bit sequence number SQN to prevent replay attacks. The authentication scheme also makes use of a 16-bit AMF value that is operator dependent.

    1. Network generates a 128-bit RAND and computes the following values:
      • 48-bit AK = f5(K, RAND)
      • XRES = f2(K, RAND)
      • MAC = f1(K, SQN || RAND || AMF)
    2. MS ⟵ NodeB : Authentication Request (128-bit RAND, AUTN = SQN ⊕ AK || AMF || MAC)
    3. MS verifies MAC and aborts by sending Authentication Failure if it is incorrect
    4. MS computes AK, verifies SQN, and aborts by sending Synchronization Failure if it is incorrect
    5. MS ⟶ NodeB : Authentication Response (RES = f2(K, RAND))
    6. MS ⟵ NodeB : Authentication Failure if RES and XRES do not match

    Encryption

    Ciphering is initiated by the network by sending a RRC Security Mode Command through DCCH.

    The traffic is encrypted at the RLC layer, or MAC layer in case of bearers in transparent mode. As with GPRS, a direction bit is used in the computation as well as a counter from the RLC or MAC header. Moreover, the traffic of each radio bearer is encrypted separately by using a 4-bit bearer id. The 128-bit encryption key CK is f3(K, RAND). Encryption algorithms are referred to as f8.

    • UEA0 : no encryption
    • UEA1 : KASUMI in OFB mode, 128-bit key, similar to A5/3 (3GPP TS 35.201)
    • UEA2 : SNOW 3G, 128-bit key (3GPP TS 35.216)

    Integrity

    Integrity is initiated by the network by sending a RRC Security Mode Command through DCCH.

    The traffic is integrity protected for non-access stratum at the RRC layer. The computation involves a direction bit, the sequence number of the RRC frame, and a 32-bit nonce value sent by the network in the Security Mode Command message. The 128-bit integrity key IK is f4(K, RAND). Integrity algorithms are referred to as f9.

    LTE

    Authentication

    LTE uses the same mutual authentication scheme as UMTS.

    Whereas in UMTS, the resulting keys CK and IK are used to protect traffic, in LTE they are used to derive a tree of keys. Two intermediary 256 bit keys are derived:

    • KASME : derived from CK, IK, as well SQN, AK (from the AUTN token) and the SN id (serving network identity)
    • KeNB : derived from KASME and the counter of uplink NAS messages

    Those keys are then further derived into a set of confidentiality and integrity keys. The final tree hierarchy after authentication is:

    • K
      • CK, IK
        • KASME
          • KNASenc
          • KNASint
          • KeNB
            • KUPenc
            • KRRCenc
            • KRRCint

    The derivation functions are based on HMAC-SHA256 and are described in 3GPP TS 33.401.

    Encryption

    Ciphering is initiated by the network by sending RRC and NAS Security Mode Command.

    Traffic is encrypted at the PDCP layer. Three different 128-bit keys are used depending whether on the nature of the traffic:

    • KNASenc for Non-Access Stratum messages
    • KRRCenc for Access Stratum messages
    • KUPenc for User Plane messages

    KNASenc is derived from KASME while KRRCenc and KUPenc are derived from KeNB.

    The computation involves a direction bit, a direction dependent 32-bit PDCP counter and a 5-bit bearer id.

    Integrity

    Integrity is initiated by the network by sending RRC and NAS Security Mode Command.

    Traffic is integrity protected at the PDCP layer. Control plane traffic must be protected while user plane traffic must not. Two different 128-bit keys are used depending whether on the nature of the traffic:

    • KNASint for Non-Access Stratum messages derived from KASME
    • KRRCint for Access Stratum messages derived from KeNB

    A key KUPint to protect user traffic is also computed by the eNodeB, but is only used between an eNodeB and a relay node.

    The computation involves a direction bit, a direction dependent 32-bit PDCP counter and a 5-bit bearer id.

    LTE D2D ProSe (Device to Device Proximity Services)

    ProSe is a 3GPP technology that appeared during Release 12. It allows LTE user equipments to discover themselves in a geographic area and communicate with one another through a direct communication channel.

    It is principally meant to be a competitor of TETRA for Public Safety, but it can also operate on commercial bands, allowing for other potential usages such as Vehicle-to-Vehicle communication.

    I am not aware of any real-life uses of ProSe but I am including it for the sake of completeness. Its security aspects are defined in 3GPP TS 33.303.

    Authentication

    UEs are provisioned with a long term pre-shared key. For communicating with another UE, a 256-bit key KD is negociated. This key is then stored in the UE and can possibly be reused or refreshed at a later point.

    Everytime two UEs establish a communication channel, a new 256-bit KD-sess is derived from KD and two nonces exchanged between the UEs.

    The key derivation functions are based on HMAC-SHA256. The key hierarchy upon communication establishment is:

    • LTK
      • KD
        • KD-sess
          • PEK
          • PIK

    KD can be negociated between the two UEs in two ways:

    1. by separately interacting with a key management server (PKMF) located in the network core.
    2. by direct communication with each other. The standard mentions the use of ECCSI (Elliptic Curve-based Certificateless Signatures for Identity-based Encryption) and SAKKE (Sakai Kasahara Key Encryption), both defined in RFC 6507 and RFC 6508.

    Once two UEs need to communicate with each other, they establish a secure communication channel:

    1. UE1 ⟶ UE2 : Direct Communication Request (LTK id, KD id, algorithms, Nonce_1)
    2. UE1 ⟺ UE2 : Authentication and KD negociation (optional)
    3. UE2 generates Nonce_2 and computes KD-sess = KDF(KD, Nonce_1, Nonce_2), as well as PIK and PEK
    4. UE1 ⟵ UE2 : Direct Security Mode Command (Nonce_2, chosen algorithms, MAC-I)
    5. UE1 computes KD-sess, PIK, PEK and verifies MAC-I with PIK
    6. UE1 ⟶ UE2 : Direct Security Mode Complete (MAC-I)
    7. UE2 verifies MAC-I with PIK. Both UEs then have a synchronized security context.

    Encryption

    The traffic is encrypted at PDCP layer, with the same algorithms as for LTE. The 128-bit encryption key is PEK, derived from KD-sess.

    Integrity

    The traffic is integrity protected at the PDCP layer, with the same algorithms as for LTE. The 128-bit integrity key is PIK, derived from KD-sess.

    EC-GSM-IoT (Extended Coverage GSM for IoT)

    The security of EC-GSM-IoT is described in 3GPP TS 43.020, starting from Release 13.

    Authentication

    The scheme of EC-GSM-IoT is an integrity-protected version of the authentication and key agreement (AKA) of UMTS.

    1. MS ⟵ BTS : Authentication and Ciphering Request (RAND, AUTN, encryption and integrity algorithms, MAC-GMM)
    2. MS performs UMTS AKA, derives integrity key Ki128 and verifies MAC-GMM
    3. MS ⟶ BTS : Authentication and Ciphering Response (SRES, MAC-GMM)
    4. Network verifies MAC-GMM and verifies SRES as for UMTS

    Encryption

    Traffic is encrypted at the LLC layer. The 128-bit encryption key Kc128 is HMAC-SHA256(CK || IK, "\x32") truncated to 128 bits.

    • GEA0 : no encryption
    • GEA4 : same as GEA3, 128-bit key (3GPP TS 55.226)
    • GEA5 : undocumented, based on SNOW 3G, 128-bit key (3GPP TS 55.251)

    Integrity

    Traffic integrity is mandatory for the control plane. Messages are integrity protected at the GMM or LLC layers. The 128-bit integrity key Ki128 is HMAC-SHA256(CK || IK, "\x38") truncated to 128 bits.

    • GIA4 : undocumented, 32-bit MAC, based on KASUMI in CBC-MAC mode (3GPP TS 55.241)
    • GIA5 : undocumented, 32-bit MAC, based on SNOW 3G (3GPP TS 55.251)

    5G-NR

    The information in this section may be subject to change in the future. The security architecture of 5G is described in 3GPP TS 33.501.

    Authentication

    5G-NR supports two authentication schemes: EAP-AKA’ and 5G AKA.

    EAP-AKA’ is described in RFC 5448.

    5G AKA is a hardened version of the UMTS authentication scheme. It goes as follows:

    1. MS ⟵ gNB : Authentication Request (RAND, AUTN)
    2. MS performs UMTS AKA and computes RES
    3. MS derives RES into SRES* = KDF(CK || IK, RES, RAND)
    4. MS ⟶ gNB : Authentication Response (RES*)
    5. MS ⟵ gNB : Authentication Failure if RES* and XRES* do not match

    Once authentication is performed, a hierarchy of tree is derived for the various network components, until generating the keys used for encryption and integrity.

    • K
      • CK, IK
        • CK', IK' (only with EAP-AKA’)
          • KAUSF
            • KSEAF
              • KAMF
                • KNASenc
                • KNASint
                • KgNB
                  • KUPenc
                  • KUPint
                  • KRRCenc
                  • KRRCint
                • KN3IWF

    KN3IWF is an IKEv2 key that can be used to connect to the network core through a non-3GPP connection.

    The derivation functions involved (such as the one used for derivating SRES*) are based on HMAC-SHA256 and are described in 3GPP TS 33.501.

    Encryption

    The traffic is encrypted at the PDCP layer. Similarly to LTE, a set of three different 128-bit encryption keys are used for user plane, NAS and AS: KUPenc, KNASenc, KRRCenc. Encryption algorithms are the same as for LTE.

    • NEA0 : no encryption
    • 128-NEA1 : identical to 128-EEA1 (SNOW 3G)
    • 128-NEA2 : identical to 128-EEA2 (AES-128 CTR)
    • 128-NEA3 : identical to 128-EEA3 (ZUC)

    Integrity

    The traffic is integrity protected at the PDCP layer. As for LTE, AS and NAS are integrity protected using KRRCint and KNASint. However, 5G-NR also allows to optionally protect user plane using KUPint. Integrity algorithms are the same as for LTE.

    • NIA0 : no integrity
    • 128-NIA1 : identical to 128-EIA1 (based on SNOW 3G)
    • 128-NIA2 : identical to 128-EIA2 (AES-128 CMAC)
    • 128-NIA3 : identical to 128-EIA3 (based on ZUC)

  • The path pivot attack

    Nov 6, 2017

    In April was published CVE-2017-2619, a race condition vulnerability affecting Samba. The vulnerability is described as follows:

    Clients that have write access to the exported part of the file system via SMB1 unix extensions or NFS to create symlinks can race the server by renaming a realpath() checked path and then creating a symlink. If the client wins the race it can cause the server to access the new symlink target after the exported share path check has been done. This new symlink target can point to anywhere on the server file system.

    Regarding the exploitability of this bug, the announcement adds:

    This is a difficult race to win, but theoretically possible.

    There is however another vector to exploit this vulnerability: when the shared folder is stored on a drive controlled by the attacker.

    Getting started

    Some network devices like home routers or NAS provide the ability to plug an USB external drive and share its contents on the network. This is for example the case in France for the DSL routers shipped with most ISPs.

    Once a USB drive is plugged in, the system will detect its partitions, automatically mount them and create a network share on the LAN, usually using Samba.

    One of the first easy thing to do is to create a symbolic link on the partition and verify that you can’t read files outside of the shared folder. Unless you are using an extremely old version of Samba, widelinks should be disabled by default and this should fail.

    On the server side, this is what happens:

    1. A request is received for opening a file at A
    2. The path A is checked to ensure it is contained within the shared folder
    3. If everything is fine, the file is opened

    Samba uses the function realpath to canonize the path and verifies it is contained inside the shared folder. On Linux, realpath will in turn use the lstat and readlink system calls to resolve symlinks, while the final operation will invoke open.

    This behavior can be confirmed by running strace on a vulnerable Samba. Trying to open the path a/b/c pointing to a file file shows:

    stat("a/b/c", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
getcwd("/mnt/shared", 4096) = 12
lstat("/mnt/shared/a", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/mnt/shared/a/b", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/mnt/shared/a/b/c", {st_mode=S_IFLNK|0777, st_size=4, ...}) = 0
readlink("/mnt/shared/a/b/c", "file", 4095) = 4
lstat("/mnt/shared/a/b/file", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("a/b/c", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
getxattr("a/b/c", "system.posix_acl_access", 0x7fff672973c0, 132) = -1 ENODATA (No data available)
stat("a/b/c", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("a/b/c", O_RDONLY)     = 12

    Since those operations are not done in an atomic way, there is no guarantee that the file we checked is the same file as we opened.

    The principle behind the attack is to trick the OS by making the realpath and the open operations work on different files using a fake USB storage drive.

    Exploitation

    The most obvious way for exploiting this design flaw would be to trigger a remount of the partition between the call to realpath(path, ...) and the call to open(path, ...). This way not only would they operate on different files, but also on different filesystems. This is however unpractical for a number of reasons:

    1. the race condition is almost impossible to win
    2. most devices I have seen will kill the server when the device is detached

    Since we control the storage device, a better idea will be to detect the call to realpath during the access to some disk sectors, and later return some different data during the open operation.

    Path pivot

    The filesystem cache

    In practice, modern operating systems are pretty much optimized for reducing the number of I/O accesses. During a path resolution, the Linux kernel may have to fetch information for a path component by reading the disk, but it will not do it again if it does not need to. Instead, this information is kept in memory into the dentry cache (or dcache).

    The dentries are the kernel structures associating a name to an inode. For a local filesystem, they remain in the dcache undefinitely until the kernel reclaims the memory for some other use.

    Consequently, the path resolution during open will lookup each path component in the dcache first, and the device will simply not be queried.

    Path pivot with dcache

    However the cache is used for performance reasons, it is not meant for security. It is in fact possible to reliably remove entries from the cache between the two calls as we are going to see.

    Invalidating the cache

    The Linux dcache is a LRU cache, which means the first entries to get replaced are the ones that are the least recently used. The cache also does not have a fixed size. It will occupy as much memory as possible but the kernel reserves itself the right to shrink it and reclaim the memory whenever it is needed elsewhere.

    When memory is reclaimed, the kernel will enumerate the dentries in the cache and garbage collect those that are unused (for which the reference counter is equal to zero). Each dentry holds a reference to its parent dentry. The kernel also keeps a reference to the current path component being looked up. Let’s consider the resolution of the paths a/b/c and a/d. After the path resolution, the tree of dentries would look like this:

    Path resolution

    The kernel would first garbage collect c and d, which would then be followed by the collection of b, then of a. But if this were to happen during the lookup of component b, the kernel would not be able to free it, nor a, because their reference counters would not be zero.

    Now the situation is little different when symlinks are involved in the path. Let’s consider the case of a path a/b/c but where b is a symbolic link to a directory a/x.

    Path resolution with symlink

    During the resolution of b, the kernel will follow the symbolic link and continue the path walk at x. The symbolic link b will keep its reference counter to zero and it can be removed from the dcache even during the path resolution.

    It means that by putting a symlink in a path, there is the possibility for its dentry to be freed by the kernel before the return of the lstat system call. The disk will then have to be read again during the following call to open with the same path.

    At first it may seem improbable for a cached dentry to be removed during the short lapse of time of a few syscalls, but actually it is possible because we can make the whole operation go very slowly. By delaying the SCSI response packets, we can leave the system call in a blocking state. Linux will wait by default 30 seconds by SCSI request before considering the disk as being dead. By staying under this threshold and by following a lot of symlinks, we can easily make a simple realpath take an hour and still return correctly.

    If we consider a path a/b/c pointing to a file f, we can chain a large number of symlinks together (but less than 40 to avoid an ELOOP error) and put them on different locations on the disk in order to drastically slow down the whole path resolution. We can also slow down the process even more by splitting the SCSI responses and returning smaller chunks of data or by creating intermediate directories with their inode on different physical locations.

    Symlink chain

    While the realpath operation is stuck with slow I/Os in lstat and readlink, we can begin the process of evicting our cached symlink entries (the green boxes in the picture). Different strategies can be adopted for that aim. The easiest one is to perform a SMBLoris attack to create a high number of connections and allocate a lot of memory. Under high memory pressure, the dcache will shrink. It only takes a few seconds to fill the memory and for the dentries to get evicted, so the race is easily winable. Of course this would also work with any other DoS vulnerabilities leading to high memory consumption.

    The time for the dentries to be evicted depends on the amount of RAM available on the device. It may require some calibration for the DoS to occupy enough memory to shrink the cache without triggering the OOM killer.

    Building the fake USB drive

    For creating our “slow drive”, we will need a device running Linux with an USB OTG port, for example a Raspberry Pi Zero.

    Using the Linux module g_mass_storage and the OTG port, we can emulate a USB key. The module takes an argument file specifying the path to the disk image. We will specify that disk image to be in a FUSE mount point. This way we will control in userland every physical access to the disk.

    USB drive

    SCSI READ commands are converted to vfs_read calls by the kernel module. This call is handled by FUSE and forwarded to a userland program. The userland application will read the disk image file and will possibly call sleep to delay the SCSI responses depending on what is being read.

    Attack demo

    The following demo will target a server running Samba 4.1.13. The partition is formatted with ext3 and contains a symlink tree xxx1/.../xxx39. Each xxx symlink redirects to a directory prefixed with magic_ that will be intercepted by our controller.

    During a read operation, Samba 4 will do the following operations:

    1. stat the target file and cache the result
    2. Canonize the filename with realpath
    3. Check file permissions and ACL (stat and getxattr)
    4. Open the file with read access
    5. fstat the file descriptor and check the device/inode number has not changed since step 1
    6. Read the file

    During step 1, we will pivot the stat call to point to /etc/passwd. During step 2, we will make the path point to a dummy passwd file. Then at step 3 we pivot again to /etc/passwd . This way we effectively bypass the checks at steps 2 and 5.

    Note that the server has 1 GB of RAM, and the DoS had been calculated to create and destroy the right number of processes. In order for the attack to succeed, you also have to use a Samba client that will not timeout when the server takes too long to respond. I used a custom script relying on pysmb here, but this can also be done with a patched smbclient.

    Final words

    Samba versions starting from 4.4.12, 4.5.7 and 4.6.1 are not impacted anymore by this vulnerability. The source code used for the attack can be found on GitHub.

    It is worth noting that this kind of attack can be extended to different scenarios. This type of attack could potentially also apply to:

    • UPnP multimedia servers (DLNA)
    • devices offering a file browser for an external drive (image viewers, multimedia players)
    • firmware updates with their signature being verified while being stored on a USB key

    The rule of thumb is to not assume that an external disk will return the same values across calls. Be extra careful when manipulating files stored on an external drive!