Vulnerabilities in MyChat by NetworkSoftwareSolutions (fixed and none)
In connection with the termination of the development of such a wonderful client jabber as Pandion (the latest available version 2.6.114 was released on April 10, 2013), it was decided to find out what sensible alternative exists for the junction of the Openfire jabber server and the Pandion client, which were used in my case for messaging inside a small organization.
The client represented by Pandion was pleased with its capabilities and usability, but in recent versions it lost its file exchange, and the number of detected bugs began to make itself felt: high processor load when changing themes in the OS or remotely connecting to a PC using remote control software , frequent departures with reference to the msxml6.dll library, problems with some functionality due to the lack of support for the new Internet Explorer engine, the situation with non-receipt of messages from other users and some others tnye detail. In principle, it would be enough to install a new version of OpenFire and start using an alternative client, for example, Miranda, which was done later, but before that I was interested in the MyChat network chat from Ukrainian developers from NetworkSoftwareSolutions.
In the process of in-depth familiarity with MyChat, some vulnerabilities were discovered. The first vulnerability lies in the features of FTP authorization on the server. In MyChat client, FTP is used for receiving and transmitting data directly between clients, and in a server — for transferring data between clients only through the server (if enabled), organizing public access to personal data and public access. To save received data via FTP, folders are used which by default are placed in the common profile in the case of a server and in the personal profile in the case of a client.
In MyChat server there are several differences in authorization via FTP, and it will be impossible not to describe each of them. Each MyChat user has a unique UIN identifier, which has a numeric value and is automatically assigned when creating an account, while the numbering goes in order, starting with 1. According to MyChat documentation, UIN and password are used as FTP username and password which are used to authorize a client using an internal protocol (it is well documented and available for public viewing). To interact with the MyChat server via FTP, you can use any application supporting it, you need to enable passive mode in the settings, specify the IP address of the MyChat server, as well as the port 20000 (default), the UIN numeric value as the user name and password. After connecting to the server with such authorization parameters, the personal folder will be available in read and write mode. In addition to this access, developers can provide access to anyone who wishes to a personal folder on the server in read mode. To do this, the password must be public. MyChat also has the ability to integrate with Active Directory, which allows you to import domain user accounts and use them for authorization. The way domain accounts are used for authorization, for example, through the FTP protocol is not specified anywhere. With the help of the network protocol analyzer, Wireshark managed to find out that the authorization uses a pair of the UIN assigned during the import for the domain user and a password consisting of the username for the login and the string * DomainUser * (for example, if the username is user1, then the password for it will be user1 * DomainUser *). Thus, the use of domain accounts in MyChat can lead to unauthorized deletion or creation of data on the server. The developers were notified of the vulnerability on 07/27/2014, but at the moment (hereinafter - it is 04/04/2016 with the latest available version of MyChat 5.18.0 of 03/23/2016) the vulnerability has not been eliminated. All three FTP authentication methods described on the server can also be used in one of the following vulnerabilities.
')
The second discovered vulnerability is the ability to gain full access to the folder in which files received from another user were saved. The vulnerability takes effect from the moment when one of the users receives at least one file from another user, and ceases to act after restarting the client. After the vulnerability begins to act, it is enough to connect via FTP in passive exchange mode on port 10000 (by default) to the victim client using the sender's UIN as the login and password. Thus, knowing the approximate range of UIN identifiers in MyChat and the IP address of the client victim, you can periodically try to log in using a login and password like 2: 2, 3: 3, etc., until the vulnerability is triggered. The developers were notified of the vulnerability on 07/27/2014, but at the moment the vulnerability has not been eliminated.
The third discovered vulnerability in MyChat is to bypass the restriction on the root folder when connecting via FTP. To exploit the vulnerability, it is necessary to specify the path of the "/ .." type as a remote directory when connecting. This will allow to get to the folder one level higher and, depending on the authority of the authorization performed, access all data in the read or read and write mode. A limitation on exploiting a vulnerability is the impossibility in a connection session to return from folders of the 2nd nesting level. Due to this vulnerability, it is possible to access the logs and backup copies of the MyChat server, as well as the data sent to users who were not connected to the server at the time of sending. In addition, a special offline folder becomes available in the root of the FTP server folder, inside which there are folders whose names use the UIN of users. To transfer data to the user, it is enough to create a folder with the sender's UIN in the folder with his UIN and place files into it. After launching the client, if at least one of the authorized users sends him a file, it will be offered to accept files from both this and all users from the offline folder. Thus, MyChat users may be at risk of infection. For a client, the same folder with all files accepted from other users becomes the default vulnerable folder. As it turned out, the vulnerability was caused by using the old version of one of the components responsible for implementing the FTP protocol. The developers were notified of the vulnerability on July 27, 2014, and on July 28, 2014, they were removed from the vulnerability.
The fourth vulnerability in MyChat concerns the use of domain authentication. The essence of the vulnerability is that, knowing the address of the server, the domain name and domain user, as well as having the ability to connect to the server, an attacker can successfully log in with this data. An attacker can enter the domain, IP, Port, ServerPassword (null) string values in the HKEY_CURRENT_USER \ Software \ MyChat Client registry key (oddly enough, but this is a documented way to enable domain authorization) , create a local account in the operating system that matches the domain name by name, and then log in using it. Now when you start the MyChat client, you will successfully connect to the server on behalf of the domain user. Thus, we can conclude that MyChat does not use the secure version of the transparent NTLM or Kerberos authorization. The developers were notified of the vulnerability on August 10, 2014, but currently the vulnerability has not been fixed.
The fifth vulnerability lies in the MyChat server and lies in the possibility of a denial of service call, which is related to an error in the implementation of receiving the cs_hello greeting command from the client from the client. The vulnerable version of the MyChat server allows you to receive an unlimited number of cs_hello commands from an unauthorized user. The essence of the MyChat server exposure to a denial of service attack in this case is that the newly received cs_hello command from the client increases the memory consumption of the server. MyChat server is a 32-bit application, so the amount of memory that can be allocated for it by the operating system is 1.8 GB. The experiment showed that a successful attack on the server requires sending a couple of millions of cs_hello commands, which will take a very long time. You can increase the size of the command by filling in arbitrary data one of the transmitted parameters in JSON format, but such an attack will also be long in time due to the large size of the transmitted data. However, this attack can be speeded up thousands of times by using the GZIP compression supported by the MyChat data exchange protocol. Thus, a string with the same characters of 65 KB can be compressed to 100 bytes. Repeatedly sent to the server, the cs_hello command with such data will lead to lightning-fast consumption of RAM, having reached the limit of which, the server will not be able to allocate memory for internal needs, which ultimately will affect its performance. The developers were notified of the vulnerability on December 6, 2014, and on December 8, 2014, the vulnerability was eliminated by them.
What conclusion can be drawn from this article: developers do not respond to all vulnerabilities in a timely manner, postponing the elimination of some of them indefinitely or simply ignoring, and also do not always track changes in the components used, which can play a trick on their application, but most of all it is alarming and frustrating that many of the vulnerabilities are the obvious result of unwillingness or laziness to make the implementation of this or that security mechanism truly safe.
The client represented by Pandion was pleased with its capabilities and usability, but in recent versions it lost its file exchange, and the number of detected bugs began to make itself felt: high processor load when changing themes in the OS or remotely connecting to a PC using remote control software , frequent departures with reference to the msxml6.dll library, problems with some functionality due to the lack of support for the new Internet Explorer engine, the situation with non-receipt of messages from other users and some others tnye detail. In principle, it would be enough to install a new version of OpenFire and start using an alternative client, for example, Miranda, which was done later, but before that I was interested in the MyChat network chat from Ukrainian developers from NetworkSoftwareSolutions.
In the process of in-depth familiarity with MyChat, some vulnerabilities were discovered. The first vulnerability lies in the features of FTP authorization on the server. In MyChat client, FTP is used for receiving and transmitting data directly between clients, and in a server — for transferring data between clients only through the server (if enabled), organizing public access to personal data and public access. To save received data via FTP, folders are used which by default are placed in the common profile in the case of a server and in the personal profile in the case of a client.
In MyChat server there are several differences in authorization via FTP, and it will be impossible not to describe each of them. Each MyChat user has a unique UIN identifier, which has a numeric value and is automatically assigned when creating an account, while the numbering goes in order, starting with 1. According to MyChat documentation, UIN and password are used as FTP username and password which are used to authorize a client using an internal protocol (it is well documented and available for public viewing). To interact with the MyChat server via FTP, you can use any application supporting it, you need to enable passive mode in the settings, specify the IP address of the MyChat server, as well as the port 20000 (default), the UIN numeric value as the user name and password. After connecting to the server with such authorization parameters, the personal folder will be available in read and write mode. In addition to this access, developers can provide access to anyone who wishes to a personal folder on the server in read mode. To do this, the password must be public. MyChat also has the ability to integrate with Active Directory, which allows you to import domain user accounts and use them for authorization. The way domain accounts are used for authorization, for example, through the FTP protocol is not specified anywhere. With the help of the network protocol analyzer, Wireshark managed to find out that the authorization uses a pair of the UIN assigned during the import for the domain user and a password consisting of the username for the login and the string * DomainUser * (for example, if the username is user1, then the password for it will be user1 * DomainUser *). Thus, the use of domain accounts in MyChat can lead to unauthorized deletion or creation of data on the server. The developers were notified of the vulnerability on 07/27/2014, but at the moment (hereinafter - it is 04/04/2016 with the latest available version of MyChat 5.18.0 of 03/23/2016) the vulnerability has not been eliminated. All three FTP authentication methods described on the server can also be used in one of the following vulnerabilities.
')
The second discovered vulnerability is the ability to gain full access to the folder in which files received from another user were saved. The vulnerability takes effect from the moment when one of the users receives at least one file from another user, and ceases to act after restarting the client. After the vulnerability begins to act, it is enough to connect via FTP in passive exchange mode on port 10000 (by default) to the victim client using the sender's UIN as the login and password. Thus, knowing the approximate range of UIN identifiers in MyChat and the IP address of the client victim, you can periodically try to log in using a login and password like 2: 2, 3: 3, etc., until the vulnerability is triggered. The developers were notified of the vulnerability on 07/27/2014, but at the moment the vulnerability has not been eliminated.
The third discovered vulnerability in MyChat is to bypass the restriction on the root folder when connecting via FTP. To exploit the vulnerability, it is necessary to specify the path of the "/ .." type as a remote directory when connecting. This will allow to get to the folder one level higher and, depending on the authority of the authorization performed, access all data in the read or read and write mode. A limitation on exploiting a vulnerability is the impossibility in a connection session to return from folders of the 2nd nesting level. Due to this vulnerability, it is possible to access the logs and backup copies of the MyChat server, as well as the data sent to users who were not connected to the server at the time of sending. In addition, a special offline folder becomes available in the root of the FTP server folder, inside which there are folders whose names use the UIN of users. To transfer data to the user, it is enough to create a folder with the sender's UIN in the folder with his UIN and place files into it. After launching the client, if at least one of the authorized users sends him a file, it will be offered to accept files from both this and all users from the offline folder. Thus, MyChat users may be at risk of infection. For a client, the same folder with all files accepted from other users becomes the default vulnerable folder. As it turned out, the vulnerability was caused by using the old version of one of the components responsible for implementing the FTP protocol. The developers were notified of the vulnerability on July 27, 2014, and on July 28, 2014, they were removed from the vulnerability.
The fourth vulnerability in MyChat concerns the use of domain authentication. The essence of the vulnerability is that, knowing the address of the server, the domain name and domain user, as well as having the ability to connect to the server, an attacker can successfully log in with this data. An attacker can enter the domain, IP, Port, ServerPassword (null) string values in the HKEY_CURRENT_USER \ Software \ MyChat Client registry key (oddly enough, but this is a documented way to enable domain authorization) , create a local account in the operating system that matches the domain name by name, and then log in using it. Now when you start the MyChat client, you will successfully connect to the server on behalf of the domain user. Thus, we can conclude that MyChat does not use the secure version of the transparent NTLM or Kerberos authorization. The developers were notified of the vulnerability on August 10, 2014, but currently the vulnerability has not been fixed.
The fifth vulnerability lies in the MyChat server and lies in the possibility of a denial of service call, which is related to an error in the implementation of receiving the cs_hello greeting command from the client from the client. The vulnerable version of the MyChat server allows you to receive an unlimited number of cs_hello commands from an unauthorized user. The essence of the MyChat server exposure to a denial of service attack in this case is that the newly received cs_hello command from the client increases the memory consumption of the server. MyChat server is a 32-bit application, so the amount of memory that can be allocated for it by the operating system is 1.8 GB. The experiment showed that a successful attack on the server requires sending a couple of millions of cs_hello commands, which will take a very long time. You can increase the size of the command by filling in arbitrary data one of the transmitted parameters in JSON format, but such an attack will also be long in time due to the large size of the transmitted data. However, this attack can be speeded up thousands of times by using the GZIP compression supported by the MyChat data exchange protocol. Thus, a string with the same characters of 65 KB can be compressed to 100 bytes. Repeatedly sent to the server, the cs_hello command with such data will lead to lightning-fast consumption of RAM, having reached the limit of which, the server will not be able to allocate memory for internal needs, which ultimately will affect its performance. The developers were notified of the vulnerability on December 6, 2014, and on December 8, 2014, the vulnerability was eliminated by them.
What conclusion can be drawn from this article: developers do not respond to all vulnerabilities in a timely manner, postponing the elimination of some of them indefinitely or simply ignoring, and also do not always track changes in the components used, which can play a trick on their application, but most of all it is alarming and frustrating that many of the vulnerabilities are the obvious result of unwillingness or laziness to make the implementation of this or that security mechanism truly safe.
Source: https://habr.com/ru/post/280910/
All Articles