Samsong · 2016/05/25″

Author: [email protected]

0 x00 profile

TeslaCrypt recently mentioned in the group of authors released the master key, a brief look at his encryption process is more interested. There were no early samples (only later ones), and a dog search turned up nothing, but two decryption programs. One is TeslaCrack by Googulator and the other is TeslaDecoder by BloodDolly. The former, though open source, supports decryption in fewer versions than the latter. This paper tries to understand the design idea of TeslaCrypt by analyzing and reverse sample and these two tools.

All images below are screenshots of the reverse process of TeslaDecoder (” TD “) developed by BloodDolly unless otherwise noted.

0x01 Description of encryption Process

TeslaCrypt (along with AlphaCrypt, collectively referred to as “TC”) is one of the more “mature” ransomware versions, which have been progressively upgraded from version 0.2 to the highest known version 4.0+. As the version is upgraded, so are its encryption and key handling skills.

Ransomware makers typically give users the address of a Bitcoin wallet in order to reach them. After paying for the wallet, the user can get a decryption key, which can be decrypted. Reports that different victims need to make payments to different wallets suggest that the creation of bitcoin wallets may have something to do with the creation of encryption keys. So, take a look at how wallets were created.

The basic steps of bitcoin wallet generation are:

  • Initialize a pair of keys that can be used for ECDSA signature Public/PrivateBtcKey
  • Run SHA256 on PublicBtcKey to obtain S256_PublicBtcKey
  • Hash the previous result with RIPemD-160 and add the version number to the front of the hash to get VR160_S256_PublicBtcKey
  • Add the version number to the front of the previous hash, hash twice, append the first 4 bytes of the result to VR160_S256_PublicBtcKey, and finally use Base58 algorithm encoding. The resulting wallet address is 33 characters long.

If you want to know more about the elliptic curve algorithm, there is a good article to read. In addition, TC also uses ECDHE algorithm for key exchange, except that the asymmetric encryption mechanism in DH is replaced by elliptic curve algorithm. Other changes are not significant, please refer to here for more details.

TC was first loaded, it generates a PublicBtcKey/PrivateBtcKey. Where PublicBtcKey is the address displayed to the user, and PrivateBtcKey is sent to the C&C server for subsequent transfers. This is constant from version to version of TC.

The key published by the author of TC is key 4, which is applied to TC3.0 and TC4.0. The two versions adopt a more complete layered key mechanism and improve the concealment of samples. The preparation process for TC4.0 is as follows:

  • Prepare random number generator, etc.;
  • Generate a random number and set up a bitcoin wallet with curve 714 (secP256K1) corresponding to the keys Public_BtcKey and Private_BtcKey.
  • Run the sha-256 hash on Private_BtcKey to obtain Private_HashedPRBK. Then use Public_BtcKey to calculate the wallet address and show it to the client later.
  • Run Private_HashedPRBK into the curve to get the second pair of keys Public_HashedPRBK;
  • In addition, the author of TC has a pair of keys Public/Private_MalMaster. In this pair of keys, Public_MalMaster is put into the program by the TC author, while Private_MalMaster is the “master key” published by the author this time, which is difficult to calculate;
  • Regenerate a third pair of keys used to encrypt transmitted data Public/Private_Master;
  • Use Private_Master and Public_MalMaster to calculate the secret t_master used for symmetric encryption.
  • Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK Encrypted_PRBK
  • Send Encrypted_PRBK and Public_Master to the CC end;
  • The attacker can calculate Secret_Master by Public_Master and Private_MalMaster.
  • Decrypt Encrypted_PRBK to Private_BtcKey with Secret_Master.
  • Calculates the hash of Private_BtcKey, Private_HashedPRBK, as the key returned to the client after payment is received;

T.c. is now ready to encrypt. TC encryption consists of one session. Each restart or shutdown of the computer terminates the current session and starts a new session. The encryption details in each session are:

  • Generate a Private_SessionKey and a SessionIV as the file encryption key and CBC mode initialization vector for this session.
  • Generate and save the corresponding key pair Public_SessionKey based on Private_SessionKey.
  • Use Private_SessionKey and Public_HashedPRBK to generate a Secret_Session key with symmetric encryption;
  • Encrypted_FILE with Private_SessionKey;
  • Encrypted_PSSK with Secret_Session Private_SessionKey;
  • Flush the storage areas for Secret_Session and Private_SessionKey immediately;

According to the attacker’s Settings, users should use the following process to decrypt files after being attacked:

  • Pay into the wallet corresponding to Public_BtcKey;
  • After verifying that a payment has been received in Private_BtcKey, return Private_HashedPRBK to the client;
  • For each file:
    • According to Private_HashedPRBK and Public_SessionKey, Secret_Session is calculated.
    • Decrypt the Encrypted_PSSK with Secret_Session to obtain the Private_SessionKey;
    • Decrypt the Encrypted_FILE with Private_SessionKey to get the source file.

In TC4.0, the author saves three values in each header that are essential for decryption:

  • SessionIV
  • Public_SessionKey and Encrypted_PSSK

Also preserved are:

  • Public_Master (also sent to CC)
  • Encrypted_PRBK (also sent to CC)
  • Public_HashedPRBK
  • Original file length

Moreover, after the key is not saved, the corresponding storage area is cleaned with data immediately to prevent security/forensics software from obtaining the decryption password. As can be seen here, virus authors have upgraded their techniques by analyzing some special kill tools and decryption tools. The key layering mechanism is also quite clear. Data transmitted in the network cannot decrypt the BTC wallet address without Private_MalMaster, and the SessionKey decryption relies on this address to ensure that no third party other than the attacker can bypass the logic to decrypt the file. The 3. X and 4. X versions are basically used as demonstration programs for cryptographic applications. After the author published the key, TD also embedded the key and realized the above decryption process.

0x02 Partial vulnerability analysis

Older versions of the TC are not as “secure” as the new version. Improper use of encrypted channels is a common error, which is also found in TCS. This was one of the earliest fixes. A more iconic version was V6. Before V6, all files could be decrypted by capturing infected network traffic to CC, but with V6, this was no longer possible. A reasonable guess is that in older versions of the software, the encryption key could be directly parsed out. Analysis of TD bears this out. The following figure is how TD determines whether the key matches the bitcoin address after obtaining network traffic (to avoid decryption errors) :

TD then places the key in the corresponding field and performs other operations similar to normal decryption:

TCS from VERSION V2 to version V5 encrypt the transmitted private key in a specific way, and the key varies from version to version, but because the key is hard coded in the program, it can still be directly extracted by TD, which is very embarrassing:

From TD’s validation logic, the old TC should send back the BTC address and Private_BtcKey (or simply encrypted Private_BtcKey) directly to the CC server:

Therefore, in a variant of V5 version, TC author removed part of the data, so that TC could not verify whether the BTC address and private key in the network request are consistent, and in V6 version, the data transmitted to CC was completely modified, and the encryption key was no longer directly exposed in the communication, completely plugging this logic vulnerability. However, to exploit this vulnerability, users need to continuously collect network traffic, which is not easy to achieve in many environments, so it is difficult to use this method.

The second vulnerability exists in the first two versions of the TC. There is a simpler approach that exploits vulnerabilities in the design of encryption. Due to incomplete cleaning of the data store area, some decryption keys may remain in key.dat and the registry. Obtain part of the key, can greatly reduce the TD decryption difficulty, and because the design process is more serious, so get the key is not SessionKey but user master key, so you can directly decrypt all files:

The bug was relatively easy to exploit and easy to patch, so it only survived two versions before being fixed by hardworking underground workers.

The third loophole is less easy to exploit. The weakness of older TCS prior to V7 is that they retain “RecoveryKey” or a similar parameter in the target file. This parameter is the product of a private key and the private key used to encrypt it. Its existence is unknown, and its location and number vary with version. For example, in an. Xyz file, the 130 bytes at the offset 0x108 store the product of the file private key Private_SessionKey and the Secret_Session encryption password. Obviously, this product can be decomposed into a product of primes, and the value of Private_SessionKey can be multiplied by one or more of these primes. This leads to the idea of blasting:

  • Decompose the product into the prime table M
  • Cycle through the primes in M and compute the product M
  • Calculate the public key value n corresponding to m in SECP256K1 mode
  • Verify that n is consistent with Public_SessionKey. If it matches, it is available

There are two main factors for the success of this approach. The most important one is that the existence of the product increases the amount of information and thus weakens the confidentiality feature. Another factor is that the attacker uses elliptic curve algorithm here. The key secret of this algorithm is that it is difficult to solve ECDLP (given a point G on the curve Ep, take any integer k, then it can be proved that the point P=k*G is easily found on the same curve. However, if appropriate parameters are selected, it will be too slow to find the group operation of K in the case of known P and G, and it is the basic principle of elliptic curve encryption to specify G and Ep well, making K the private key and P the public key, instead of relying solely on the number of bits of the key. Therefore, in the operation, considering the time problem, generally set the private key in 160~300 bits, even compared with RSA1024, this length is much shorter, so it is easier to be mined from the prime table (here “more” is relative to RSA1024, in fact, also need a considerable amount of computing power and luck). This vulnerability can be resolved simply by modifying the encryption process or simply deleting the product. Therefore, in V7 and later versions, this product data is removed, so that decryption of V7 and V8 can only rely on the key given by the attacker.

The above is my decryption code according to the old version of Teslacrypt, understand some vulnerability information. Own cryptography compares dish, if have wrong, still hope everybody gives a little life experience.

0x03 Related links

  • English Wiki has a lot of articles about cryptography, in addition, there is a relatively reliable article about ECC can also be referred to, from Jianxue forum
  • Source: Solidot
  • BTC wallet generation: bitcoii.it
  • If you focus primarily on sample behavior: Cloud, SecureWorks, and Cisco
  • Qiming stars on the software points
  • Code that exploits the third vulnerability: Github
  • An introduction to the third vulnerability: BleepingComputer.com