You are currently viewing a new version of our website. To view the old version click .
Sensors
  • Article
  • Open Access

15 May 2022

Vulnerabilities of Live-Streaming Services in Korea

,
,
,
,
,
and
1
System Security Research Center, Chonnam National University, Gwangju 61186, Korea
2
Computer & Telecommunications Engineering, Mirae Campus, Yonsei University, Wonju 26493, Gangwon-do, Korea
3
Department of Cyber Defense, Korea University, Seoul 02841, Korea
4
ALL IT ONE Inc., Seoul 08390, Korea
This article belongs to the Special Issue Cybersecurity in the Internet of Things

Abstract

Recently, the number of users and the demand for live-streaming services have increased. This has exponentially increased the traffic to such services, and live-streaming service platforms in Korea use a grid computing system that distributes traffic to users and reduces traffic loads. However, ensuring security with a grid computing system is difficult because the system exchanges general user traffic in a peer-to-peer (P2P) manner instead of receiving data from an authenticated server. Therefore, in this study, to explore the vulnerabilities of a grid computing system, we investigated a vulnerability discovery framework that involves a three-step analysis process and eight detailed activities. Four types of zero-day vulnerabilities, namely video stealing, information disclosure, denial of service, and remote code execution, were derived by analyzing a live-streaming platform in Korea, as a representative service, using grid computing.

1. Introduction

The fourth industrial revolution has significantly increased activity in the IT industry. As the use of PCs, smartphones, IoT, etc., increases, the software market continues to evolve. However, in the past three years, the number of vulnerabilities in systems (i.e., applications, services, mobiles, IoT, content management systems (CMSs), and ActiveX) has also increased. The number of infringement incidents that exploit software vulnerabilities is increasing with the development of the current software market. To prevent this, we analyzed the exploitation of potential vulnerabilities from an attacker’s perspective. Preemptively removing these is necessary for the industry to progress.
Social distancing has been implemented because of COVID-19, and live-streaming services are often used for non-face-to-face events, classes, and conferences by organizations such as schools and companies. As shown in Figure 1, the most used live-streaming platforms in Korea are YouTube and Facebook, which have many users worldwide. However, Naver TV, Kakao TV, and Afreeca TV, developed by Korean companies, also have many users in Korea []. These live-streaming platforms use grid computing technology to provide high-quality video transmission services to users. Grid computing technology is a type of distributed parallel computing that can be used as a single supercomputer by utilizing the resources of multiple user PCs connected to the network. This grid computing technology is primarily used by platforms that provide peer-to-peer (P2P)-based services. Grid computing technology, which is a method of sharing internal resources between users, requires strict security control because data are exchanged without server intervention after a connection is established between a sender and receiver.
Figure 1. Top 10 video platforms in terms of the number of visitors in Korea.
In this study, we analyzed the technical security vulnerabilities of grid computing, a technology that has been researched and developed since the early 2000s. A three-step analysis framework was developed and used to analyze a live-streaming platform that uses grid computing technology. The goal was to preemptively remove potential vulnerabilities by replacing them. Although grid computing technology is continuously developed and used, it does not utilize appropriate security verification, which may put users at risk. Previous studies have presented the architectural vision of grid computing, emphasized security, or reported security factors that should be considered in the P2P data communication of live-streaming services. However, research has not been conducted to prove the presence of these vulnerabilities by analyzing the data flow, creating a data flow diagram, identifying threats, and constructing attack scenarios. To address this, we propose a three-step vulnerability discovery framework. These three steps consist of a data flow analysis, threat modeling, and vulnerability analysis. An experiment environment was configured to control the access of service users, and a local experiment environment for a direct attack was established. Next, a data flow diagram (DFD) was derived by analyzing the flow of data based on an analysis of the process characteristics and protocols. Then, STRIDE threat modeling techniques were applied to identify threats and construct an attack tree and attack scenarios. The system vulnerability was verified by building it.
Our contributions can be summarized as follows:
  • We provide a vulnerability discovery framework that can effectively analyze grid-computing-based client software;
  • We analyze the vulnerabilities of actual services, which were not performed in previous studies, by using our proposed analysis framework. Several zero-day vulnerabilities were derived, thereby verifying our proposed analysis framework;
  • We find four types of zero-day vulnerabilities, namely video stealing, information disclosure, denial of service, and remote code execution, which were derived by analyzing a live-streaming platform in Korea.
This paper provides details of the vulnerability analysis of a grid-computing-based live-streaming service and is structured as follows. Section 2 presents a review of related studies, the technology trends and security trends of grid computing systems, and the technical status of live-streaming services, the operational structure of live-streaming platforms in Korea, and threat modeling. Section 3 describes the three-step vulnerability discovery framework proposed for the data flow analysis and threat modeling of grid-computing-based applications. It includes the data flow analysis, threat modeling, and analysis of vulnerabilities. Section 4 shows the derivation of the zero-day vulnerability using the framework proposed for a grid-computing-based live-streaming service. Finally, Section 5 concludes this study.

3. Suggested Vulnerability Discovery Framework

3.1. Overview of Vulnerability Discovery Framework

To analyze the vulnerabilities of grid-computing-based live-streaming services, a framework for vulnerability detection was constructed, as shown in Figure 7. Naver TV, Kakao TV, and Afreeca TV, which utilize grid computing technology and are used for live streaming in Korea, were selected for analysis.
Figure 7. Vulnerability discovery framework composition.

3.2. Structural Analysis

The structural analysis stage consisted of three detailed activities and was divided into the identification of major entities, identification of data flow between entities, and DFD creation. In this step, the framework was configured to identify major entities, such as processes and external objects, through an initial analysis and the data flow between entities through a network protocol analysis. The output was then structured by creating a data flow chart to visualize and identify threats. At this stage, processes, external objects, data flows, and trust boundaries were abstracted and could be expressed visually. The DFD was derived in this step and used as input for threat modeling.

3.3. Threat Modeling

In the third stage (the threat modeling stage), the framework was configured to perform three tasks. Based on the created data flow chart, STRIDE threat modeling was applied to identify threats, and the identified threats were analyzed to create an attack tree as the basis of the attack scenario. Thus, the threat identified in each entity was configured to allow its use in an attack scenario. At this stage, threats based on STRIDE were identified. The attack tree, which was the core of the threat modeling stage, was finally derived by analyzing the identified major threats. In the attack tree, the elements required for each attack were located based on the identified threats.

3.4. Vulnerability Analysis

In the vulnerability analysis stage, the attack tree constructed based on the previously derived threats was converted into an attack scenario that can be utilized in an actual grid computing system. Subsequently, the validity was determined by verifying the derived scenario to derive the zero-day vulnerability.

4. Experiments

This section describes the results of applying the proposed analysis framework for the vulnerability analysis of grid-computing-based live-streaming services, along with the results of establishing the environment configuration, data flow analysis, threat modeling, and vulnerability analysis.

4.1. Experimental Environment Configuration

On a live-streaming platform, establishing an analysis environment is essential to avoid a reduction in the availability of the service to its many users. To this end, an environment was configured such that the experiment could proceed without reducing the availability by implementing a “secret room” function provided by the live-streaming service. In addition, a P2P connection script was created to facilitate the connection between analysis PCs. Because of the nature of mesh-structured grid computing, two-way communication was required. Thus, connecting the analysis PCs to each other in a form different from a tree-structured experimental environment, which communicates in one direction, was necessary.

4.2. Results

This section describes the results of the experiment. The results of the data flow analysis are explained according to the grid computing structures of Naver TV, Kakao TV, and Afreeca TV, which were the analysis targets. Table 5 lists the DFD components.
Table 5. Components of DFD.

4.2.1. Data Flow Analysis in Tree-Structured Grid Computing Environments

Afreeca TV, which has a high usage rate in Korea, and Kakao TV, which has recently been in high demand because of its original content, use tree-structured grid computing systems. In tree-structure-based grid computing, as shown in Figure 8, five trust boundaries exist, along with two external entities, fifteen data flows, and six processes. Table A4 describes each component of the tree structure DFD.
Figure 8. DFD of a tree-structure-based grid computing system.

4.2.2. Data Flow Analysis in Mesh-Structured Grid Computing Environment

Among the live-streaming services, Naver TV was the only service using the mesh structure, and the data flow chart prepared was configured accordingly, as shown in Figure 9.
Figure 9. DFD of mesh-structure-based grid computing system.
The tree structure formed in grid computing differs significantly from a mesh structure because the streaming data received from the main server are managed in sequence and transmitted to the necessary nodes in the group. Therefore, streaming data containing sequences received from the Group A Trust Boundary and main server were added to the component. Table A5 describes each component of the mesh structure DFD.

4.2.3. Threat Modeling Results

In this study, we used the STRIDE technique for threat modeling. This is a threat modeling technique proposed by Microsoft, which has six goals to achieve information protection for each element: the authentication, integrity, non-repudiation, confidentiality, availability, authorization, and identification of the symmetrical threats of spoofing, tampering, denial, information disclosure, denial of service, and elevation of privilege []. Table 6 lists the threats according to each component of the data flow chart based on the tree and mesh structure.
Table 6. Threats available in DFD components based on tree and mesh structures.
The tool used in this study was Microsoft’s Threat Modeling Tool Version 7.3.10801.1, which allows threats mapped to STRIDE to be automatically identified using the reporting function. Therefore, an analysis showed that the same types of threats existed in both the tree and mesh structures, with 134 and 133 threats derived from each, respectively. Thus, 267 threats were identified, which are too many to include in the main text. Table A1 in Appendix A lists 48 main threats.
Figure 10 shows an attack tree created based on the identified threats. A total of four attack trees were derived, each of which consisted of remote code execution (RCE), personal information disclosure, video stealing, and DoS.
Figure 10. Derived attack tree.

4.2.4. Attack Scenario Configuration

This section describes the attack surface discovered based on the threats derived above, and the attack scenarios that can be exploited. Figure 11 shows the attack surface discovered based on the identified threats. It comprises four attack vectors, each of which provides communication with the main server, communication with the update server, initial data in the client P2P connection process, video request data in the client P2P communication process, and video request data in the client P2P communication process. The attack scenarios included key information exposure during communication with the main server, update file tampering and remote code execution through DNS spoofing, image theft by data tampering at the beginning of a connection, DoS attacks through request-based index access, and pirate broadcasting through video data tampering.
Figure 11. Attack surface discovered based on identified threats.
The main server provides information about the node to be connected to in the grid computing processor transmitting the streaming data requested by the user. To this end, the streamer process delivers information about its CPU speed and RAM availability to the main server, and then the main server delivers information about the IP and port of the node connected to the streamer process. In this process, the possibility of exposing information on the IP list was confirmed, which occurred during grid computing with a mesh structure, and was analyzed as unnecessary work such that the private IP of the group was transmitted to form a group. Therefore, because a private IP can specify an individual, specifying a user watching a specific channel is possible when abused. The update server communicates with the local updater process. This confirms that the updater requests the file version from the server to obtain the latest file information, and the server uses the HTTP protocol. Therefore, in the LAN environment, an RCE attack is expected to be possible by tampering with the DNS.
The initial data of the client P2P connection process is connected to sub-nodes or grouped nodes to share streaming data in both tree- and mesh-structured grid computing. To this end, the initial data are used to identify each other between streamer clients. If a mechanism does not exist to authenticate this, attacks such as memory corruption and image stealing are expected through data tampering. When a P2P connection is established between clients through the previous initial data, in a grid computing environment with a mesh structure, a group is formed, and the sender and receiver broadcast the sequence number of the image data possessed by each client without distinction to request the necessary data. In this process, if the corresponding sequence number is tampered, the attacker can receive the video data of the desired frame or cause memory corruption. Thus, a DoS attack can occur.
In the grid computing used by live-streaming platforms, most of the packets are video data. However, if these are shared between sub-nodes and groups through grid computing communication, they can operate similar to a network worm even if the tampering is confined to only one data stream. Thus, maintaining integrity is an important factor. However, the analysis confirmed that the logic to verify the integrity does not exist, and if this is abused, pirate broadcasting can occur, allowing a user to watch unauthorized images through image data modulation, with the expectation that the largest part of the data exchanged would be available. Memory corruption is also an expected attack scenario.

4.2.5. Proof-Of-Concept

This section describes the results of verifying the validity of the previously written scenario. Also, the tools used in the proof-of-concept experiment are described in detail in Appendix B. In this process, a number of vulnerabilities were derived, and depending on the configuration of the scenario, screen tampering, pirate broadcasting, and memory contamination vulnerabilities, including video stealing, personal information disclosure, and DoS and RCE attacks, were possible. As shown in Figure 12, video stealing and personal information disclosure threaten availability, while DoS and RCE threaten confidentiality.
Figure 12. Security’s fundamental principles (CIA) that each attack violates.
  • Video Stealing
Screen tampering vulnerabilities occurred when transmitting image data during P2P communication between clients. It is a vulnerability that occurred equally on all platforms. It is a serious vulnerability that leads to pirate broadcasting, which allows a receiver to control the screen being viewed on a specific platform. This occurs because of the absence of a routine for verifying the integrity of image data. Because the integrity is unverified, when the sender located in the parent node modulates data, the modulated image can be confirmed to have been transmitted to the child node and other nodes without filtering. After the receiving client sends the initial data to the sending client, the video and audio data receiving process occurs. At this time, the initial data are unverified. Thus, although the Streamer process is not running, it is a secret room without permission and age restrictions. We were able to steal images of rooms, etc. Figure A2 and Figure A3 show the memory dump results of the sending process of the initial data from the receiving client to the sending client and received streaming data. As shown in Figure A4, none of the processing or verification processes are performed after receiving the streaming data from the sender with the recv() function or before sending it to another node with the send() function.
  • Personal Information Disclosure
A python script was written to steal data, and it proved that stealing video data from an unauthorized channel is possible by transmitting the initial data about the IP and targeted port. The code in Figure A5 is part of a function that executes a file in the Management process. The file name is received as an argument to the Buffer variable, and the Updater process is executed through the creatProcessW or ShellExecuteExW() function. Therefore, the address of the update server can be set as the address of the attacker server through DNS Spoofing, and malicious code can be executed on the user’s PC, watching the same channel in the LAN environment. This vulnerability occurred in the nodes constituting a group in the mesh structure. This was derived through a packet analysis using Wireshark and designed to receive private IP information when trying to connect to the same public IP band. In this case, because it can refer to a specific person, this can be said to expose personal information. As shown in Figure A6, a verification script is written to collect the private IP watching the channel, thereby proving the vulnerability.
  • DoS and RCE
In the DoS attack depicted in Figure A7, among the attack vectors, the attack occurred during the initial data transmission process of the client P2P connection, image request data transmission, and image data transmission processes.
  • DoS attack through connection and initial data tampering: A packet analysis confirmed that the user was authenticated using the ticket value received from the server. In addition, if the ticket length value was altered to make it larger than the length defined in the ticket-related structure, the process was confirmed to terminate without exception, and the availability reduced. Therefore, this corresponded to a DoS attack.
  • DoS attack through request-based index access: The mesh-structured grid computing environment forms a group to transmit and receive data. As a result of modulating the sequence number according to the attack scenario configured, a crash was confirmed to occur outside the packet range, and the process terminated.
  • DoS attack through video data tampering: In the case of image data, a DoS attack was confirmed to be possible in the tree structure. When modulating the header and video data of the protocol, a field responsible for the length of the corresponding packet data existed.
If the vulnerabilities occurring in these three vectors are exploited, users cannot use high-definition services while using live-streaming services. In particular, DoS attacks caused by memory corruption were prevalent. This was classified as a fatal vulnerability because of the possibility of RCE. All vulnerabilities verified earlier occurred because grid computing was utilized and demand an improvement because they affect all connected nodes. Table 7 summarizes the problems that can occur through the vulnerabilities proven through proof of concept and the countermeasures to the vulnerabilities.
Table 7. Issue caused by vulnerability and countermeasure to vulnerability.

5. Conclusions

In this study, we analyzed the grid computing systems of live-streaming platforms that can be easily accessed in Korea to determine their technical security. To this end, a three-step vulnerability discovery framework was proposed. In an experiment, system threats were identified by configuring the experiment environment, data flow analysis, and STRIDE-based threat modeling, and an analysis was conducted to identify the vulnerabilities. The availability was secured by opening a secret room and using an automatic P2P connection script, and four attack scenarios were created using STRIDE and attack tree methods to identify the security threats in grid computing systems. After these were validated, deriving more than 10 zero-day vulnerabilities was possible in the grid-computing-based live-streaming services. The vulnerabilities identified can cause economic damage and leak users’ personal information. Moreover, when an attack occurs, these were proved to act similar to a network worm that affects an individual user and all nodes. Therefore, using a grid computing system requires authentication between users and data integrity verification. We analyzed the vulnerabilities of the most accessible live-streaming platform in Korea to determine the security in grid computing systems.
However, we did not analyze all services using different grid computing systems. Thus, our proposed vulnerability detection framework cannot be a standard of vulnerability detection for services using grid computing systems. To compensate for this, we are investigating services that use overseas grid computing systems. In future research, the proposed vulnerability detection framework will be validated for overseas services.

Author Contributions

kakaoTV vulnerability analysis, S.-H.H., T.-H.K. and T.-S.Y.; naverTV vulenrability analysis, S.-H.M. and S.-M.Y.; afreecaTV vulnerability analysis, S.-H.H., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; protocol analysis, S.-H.H., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; identify data flow, S.-H.H., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; proof of concept, S.-H.H., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; conceptualization, S.-H.H., G.-Y.K., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; methodology, S.-H.H., G.-Y.K., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; software, S.-H.H., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; validation, S.-H.H., S.-H.M., T.-S.Y., S.-M.Y., T.-H.K. and I.-C.E.; formal analysis, S.-H.H. and I.-C.E.; investigation, S.-H.H., G.-Y.K., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; resources, T.-H.K.; data curation, S.-H.H.; writing—original; draft preparation, S.-H.H.; writing—review and editing, S.-H.H., G.-Y.K. and I.-C.E.; visualization, S.-H.H. and S.-H.M.; methodology, S.-H.H., G.-Y.K., S.-H.M., T.-S.Y., S.-M.Y. and T.-H.K.; supervision, I.-C.E.; project administration, T.-S.Y. and I.-C.E.; and funding acquisition, I.-C.E. All authors have read and agreed to the published version of the manuscript.

Funding

This work was supported by Nuclear Safety Research Program through the Korea Foundation of Nuclear Safety (KoFONS) using the financial resource granted by the Nuclear Safety and Security Commission(NSSC) of the Republic of Korea. (No.2106061) also the results of a study on the supported by Institute for Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea government (MSIT) under grant no. 2019-0- 01343, regional strategic industry convergence security core talent training business.

Institutional Review Board Statement

Not applicable.

Conflicts of Interest

The funders had no role in the design of the study; in the collection, analysis, or interpretation of data; in the writing of the manuscript; or in the decision to publish the results.

Appendix A

Table A1. Main threats of grid-computing-based live-streaming services.
Table A1. Main threats of grid-computing-based live-streaming services.
ElementElement NameSTRIDEThreat AnalysisThreat Number
External EntityBrowserSThe browser may be spoofed by an attacker, which may lead to unauthorized access to the Management Process. Consider using a standard authentication mechanism to identify the external entity.T1
ECross-site request forgery (CSRF or XSRF) is a type of attack in which an attacker forces a user’s browser to forge requests to a vulnerable site by exploiting an existing trusted relationship between the browser and vulnerable website.T2
ProcessManagement ProcessSThe Management Process may impersonate the context of the browser to obtain additional privilege.T3
EThe Management Process may impersonate the context of the browser to obtain additional privilege.T4
Update ProcessSThe Update Process may be spoofed by an attacker, which may lead to unauthorized access to the Update Server Process. Consider using a standard authentication mechanism to identify the source/destination process.T5
RThe Update Process claims it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.T6
DThe Update Process crashes, halts, stops, or runs slowly, which violates an availability metric in all cases.T7
EThe Update Process may impersonate the context of the Management Process to obtain additional privilege.T8
Streaming ProcessSThe Streaming Process may be spoofed by an attacker, which may lead to information disclosure through the Streaming Process. Consider using a standard authentication mechanism to identify the source/destination process.T9
RThe Streaming Process claims it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.T10
DThe Streaming Process crashes, halts, stops, or runs slowly, which violates an availability metric in all cases.T11
EThe Streaming Process may impersonate the context of the Update Process to obtain additional privilege.T12
EThe Streaming Process may remotely execute code for the Streaming Process.T13
EAn attacker may pass data to the Streaming Process to change the flow of program execution within the Streaming Process to the attacker’s choosing.T14
Update ServerSThe Update Server Process may be spoofed by an attacker, which may lead to information disclosure through the Update Process. Consider using a standard authentication mechanism to identify the source/destination process.T15
RThe Update Server Process claims it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data.T16
DThe Update Server Process crashes, halts, stops, or runs slowly, which violates an availability metric in all cases.T17
EThe Update Server Process may impersonate the context of the Update Process to obtain additional privilege.T18
EUpdate Process may be able to remotely execute code for Update Server Process.T19
EAn attacker may pass data to the Update Server Process to change the flow of program execution within the Update Server Process to the attacker’s choosing.T20
Main ServerSThe Main Server Process may be spoofed by an attacker, which may lead to unauthorized access through the Streaming Process. Consider using a standard authentication mechanism to identify the source/destination process.T21
EThe Streaming Process may impersonate the context of the Main Server Process to obtain additional privilege.T22
EThe Main Server Process may remotely execute code for the Streaming Process.T23
EAn attacker may pass data to the Streaming Process to change the flow of program execution within the Streaming Process to the attacker’s choosing.T24
Data FlowUpdate FileTData flowing through the Update File may be tampered by an attacker. This may lead to a denial-of-service attack against the Update Process, an elevation-of-privilege attack against the Update Process, or information disclosure through the Update Process.T25
IData flowing through the Update File may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations. Consider encrypting the data flow.T26
DAn external agent interrupts data flowing across a trust boundary in either direction.T27
Process Version InfoTData flowing across the Process Version Info may be tampered by an attacker. This may lead to a denial-of-service attack against the Update Server Process, an elevation-of-privilege attack against the Update Server Process, or information disclosure through the Update Server Process.T28
IData flowing across the Process Version info may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations. Consider encrypting the data flow.T29
DAn external agent interrupts data flowing across a trust boundary in either direction.T30
Streaming DataTData flowing across the Streaming Data (sequence) may be tampered by an attacker. This may lead to a denial-of-service attack against the Streaming Process, an elevation-of-privilege attack against the Streaming Process, or information disclosure through the Streaming Process.T31
IData flowing across the Streaming Data (sequence) may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations. Consider encrypting the data flow.T32
DAn external agent interrupts data flowing across a trust boundary in either direction.T33
Resource DataTData flowing across the Resource Data may be tampered by an attacker. This may lead to a denial-of-service attack against the Main Server Process, an elevation-of-privilege attack against the Main Server Process, or information disclosure through the Main Server Process.T34
IData flowing across the Resource Data may be sniffed by an attacker.T35
DAn external agent interrupts data flowing across a trust boundary in either direction.T36
IP List InfoTData flowing across the IP List Info may be tampered by an attacker. This may lead to a denial-of-service attack against the Streaming Process, an elevation-of-privilege attack against the Streaming Process, or information disclosure through the Streaming Process.T37
IData flowing across the IP List Info may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations. T38
DAn external agent interrupts data flowing across a trust boundary in either direction.T39
Request Streaming DataTData flowing across the Request Streaming Data may be tampered by an attacker. This may lead to a denial-of-service attack against the Main Server Process, an elevation-of-privilege attack against the Main Server Process, or information disclosure through the Main Server Process.T40
IData flowing across the Request Streaming Data may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations. Consider encrypting the data flow.T41
DAn external agent interrupts data flowing across a trust boundary in either direction.T42
Response Streaming DataTData flowing across the Response Streaming Data may be tampered by an attacker. This may lead to a denial-of-service attack against the Streaming Process, an elevation-of-privilege attack against Streaming Process, or information disclosure through the Streaming Process.T43
IData flowing across the Response Streaming Data may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations. Consider encrypting the data flow.T44
DAn external agent interrupts data flowing across a trust boundary in either direction.T45
Initial DataTData flowing across the Initial Data may be tampered by an attacker. This may lead to a denial-of-service attack against the Streaming Process, an elevation-of-privilege attack against the Streaming Process, or information disclosure through the Streaming Process.T46
IData flowing across the Initial Data may be sniffed by an attacker. Depending on the type of data an attacker can read, it may be used to attack other parts of the system or simply disclose information, which leads to compliance violations.T47
DAn external agent interrupts data flowing across a trust boundary in either direction.T48

Appendix B. Tools Used in the Experiment

The tools used for vulnerability analysis are described below. Table A2 describes the tools used for the vulnerability analysis in the Proof-of-Concept. A disassembler was used for static code analysis, and tools such as windbg, x64dbg, and Cheat Engine were used for debugging. Subsequently, hooking was performed through frida for data modification, and Wireshark and API Monitor were used to analyze network traffic and APIs that process calls. Finally, lighthouse was used to check code coverage.
Table A2. List of tools used in the experiment.
Table A2. List of tools used in the experiment.
FunctionToolsDescription
DisassemblerIDA ProDisassembler for computer software
GhidraDisassembler framework developed by the U.S. National Security Agency
Binary NinjaReverse engineering platform developed by Vector 35 Inc
DebuggingwindbgVersatile debugger for Microsoft Windows
x64dbgProvides a UI (User Interface) that allows step-by-step debugging through the code running as an open-source debugger for Windows and check exactly what you are doing
Cheat EngineAn open-source memory scanner and debugger primarily used for recompilation on Windows operating systems
HookingfridaDynamic Binary Instrumentation (DBI) tool to run and analyze binaries dynamically with a dynamic instrumentation toolkit for developers and reverse engineering and security researchers
Network traffic analysiswiresharkUsed to analyze network traffic with an open-source packet analysis program
API MonitorProvides a function to monitor APIs called by programs written in C and C++ and check API call stacks, parameter values, and hex dumps.
Code coverage analysislighthouseCode inspection explorer for IDA Pro and Binary Ninja, it can analyze the execution flow of code and provide it to analysts

Appendix B.1. Disassembler

A disassembler is a computer program that converts machine language into assembly language. It is a tool that converts an analyst’s written program to be easy to read. In this experiment, it was used to analyze the executable files and DLL (Dynamic Link Library) of the software of the three companies analyzed.

Appendix B.2. Debugging

A debugger is a computer program used to test and debug programs. In our experiment, to analyze the execution flow of the target program, we followed the input and output values and checked how the program operates according to the corresponding values.

Appendix B.3. Hooking

Hooking refers to a command, method, technique, or action that intercepts function calls and events occurring between software components in various computer programs, such as operating systems and applications. In our experiment, because input values cannot be arbitrarily given owing to the nature of real-time streaming services, modifying the transmitted data is possible by hooking the send()/WSASend()or recv() APIs to prevent the crash that occurs when data is tampered in the local environment. Table A3 was written to modify the input value in the local environment by hooking the recv() API.
Table A3. Example of writing a hooking script using frida.
Table A3. Example of writing a hooking script using frida.
Process.enumerateModules();
var recv_address = Module.getExportByName('ws2_32.dll','recv');

var target_ip = ‘10.10.1.X’;
var tmp = 1;

Interceptor.attach(ptr(recv_address), {
  onEnter: function(args) {
    this.fd = args[0];
    this.buf = args[1];

    var address = Socket.peerAddress(parseInt(this.fd));
    var header = Memory.readByteArray(ptr(parseInt(this.buf)), 0x4);
    var data = new Uint8Array(header);

    if ( address.ip == target_ip && this.len != 0x40000 && this.len >= 0x40 ) {
     console.log('========= onEnter =========');
     console.log('buf : '+this.buf);
     console.log('len : '+this.len);
     console.log(Memory.readByteArray(ptr(parseInt(this.buf)), parseInt(0x40)));
    }
   },

   onLeave: function(ret) {
    var address = Socket.peerAddress(parseInt(this.fd));
    if ( address.ip == target_ip && this.len != 0x40000 && this.len >= 0x40 ) {
     console.log('========= onLeave =========');
     console.log('buf : '+this.buf);
     console.log('len : '+this.len);
     // var mutaion = [0xad, 0xde, 0xef, 0xbe];
     var mutaion = [0x41, 0x41];
     var mutaion2 = [0x42, 0x42];
     if( tmp == 1 ) {
      tmp = 0;
      Memory.writeByteArray(ptr(parseInt(this.buf)).add(0x35), mutaion);
     }
     else {
      tmp = 1;
      Memory.writeByteArray(ptr(parseInt(this.buf)).add(0x35), mutaion2);
     }
     console.log(Memory.readByteArray(ptr(parseInt(this.buf)), 0x40));
    }
   }
});

Appendix B.4. Network Traffic Analysis

In the case of a real-time streaming service, data in a specific format is not transmitted, but a different protocol for each manufacturer is used. Therefore, in this experiment, tools such as Wireshark and API Monitor were used to understand the protocol structure and analyze it.

Appendix B.5. Code Coverage Analysis

The code coverage was analyzed by modulating data through the hooking described in the application program analysis of the real-time streaming platform and then checking it. Representatively, lighthouse, a plug-in that can be used in IDA Pro and Binary Ninja, was used. As shown in Figure A1, lighthouse provides a function to indicate whether the code has been executed and check whether it has passed through the corresponding block. This was used to compare the process execution flow before data modification and the execution flow after modification, and it was used to derive vulnerabilities.
Figure A1. Example of DoS attack through video data tampering (picture distortion).

Appendix C. Components of the DFD

Table A4. Components of a tree-structure-based grid computing system.
Table A4. Components of a tree-structure-based grid computing system.
GroupComponentsDescription
External EntityBrowserA medium that expresses encoded streaming data for users of streaming services
High-definition Service UserUsers who want to use high-quality streaming services
ProcessMain Server ProcessThe server that selects a parent node based on the resource information of a user watching on a streaming channel and connects child nodes
Update Server ProcessThe server where the latest files exist, and is in charge of version management of the three locally existing processes: Streaming, Update, and Management
Management ProcessThe process responsible for running and managing a process that exists locally
Update ProcessWhen running, the process that communicates with the update server and receives the latest files
Streaming ProcessThe process that shares data between nodes and transmits the received streaming data through a websocket connection to the browser
Data FlowProcess StartData used to execute a process using the ShellExecute() API
Update FileInformation about the latest file version since connecting to the update server
Process Version InfoVersion information of local files sent to the server
Streaming Data (encrypted)Streaming data encrypted using DTLS when delivered to the browser through a websocket connection
Request High-definition ServiceHigh-definition service request data that the user passes to the browser to receive high-definition streaming data
Resource DataResource data transmitted to the main server during node selection process by checking the remaining amount of RAM and CPU
Request Streaming DataStreaming request data sent to the server or parent node when connecting to a channel
Response Streaming DataResponse streaming data sent from the parent node or server to the child node in response to the streaming data request
Initial DataInitial data used for the initial connection between nodes
IP List InfoData about the IP to connect to, which the main server sends to the node
Trust BoundaryUpdate ServerThe boundary where the update server is located
Admin PermissionBoundary where processes with administrator privileges, instead of regular user privileges, are located in the local environment
Parent NodeParent node boundary that receives data from the server or parent node in the streaming process and transmits streaming data to lower nodes
Main ServerBoundary where the main server is located
Internal NodeChild node boundary that receives streaming data through the parent node during streaming
Table A5. Components of mesh-structure-based grid computing system.
Table A5. Components of mesh-structure-based grid computing system.
GroupComponentsDescription
External EntityBrowserA medium that expresses encoded streaming data to users of streaming services
High-definition Service UserUsers who want to use high-quality streaming services
ProcessMain Server ProcessThe server that selects a parent node based on the resource information of a user watching a streaming channel and connects child nodes
Update Server ProcessThe server where the latest files exist, and is in charge of version management of the three locally existing processes: Streaming, Update, and Management
Management ProcessThe process responsible for running and managing a process that exists locally.
Update ProcessWhen running, the process that communicates with the update server and receives the latest files
Streaming ProcessThe process that shares data between nodes and transmits the received streaming data through a websocket connection to the browser
Data FlowStart Process Data used to execute a process using the ShellExecute() API
Update FileInformation about the latest file version since connecting to the update server
Process Version InfoVersion information of local files sent to the server
Streaming Data (encrypted)Streaming data encrypted using DTLS when delivered to the browser through a websocket connection
Request High-definition ServiceHigh-definition service request data that the user passes to the browser to receive high-definition streaming data
Streaming Data (sequence)Streaming data with a sequence for sharing streaming data within a group
Trust BoundaryUpdate ServerThe boundary where the update server is located
Admin PermissionThe boundary where processes with administrator privileges, instead of regular user privileges, are located in the local environment
Nodes 1, 2, 3The boundary where each connected node in the group is located
Group AThe group boundary where each node is connected based on the IP information received from the main server for streaming data sharing

Appendix D. Capturing the Results of the Proof-Of-Concept

Figure A2. Initial data sent by the receiving client to the sending client.
Figure A3. Process of receiving streaming data by connecting after sending all initial data.
Figure A4. Data processing after calling recv().
Figure A5. Code of process execution.
Figure A6. Verification script execution result.
Figure A7. Example of DoS attack through video data tempering (picture distortion).

References

  1. Incross, Media Data Clipping-Video Platform Edition. 2020. Available online: https://www.incross.com/insight/?pageid=1&mod=document&keyword=%EB%8F%99%EC%98%81%EC%83%81%20%ED%94%8C%EB%9E%AB%ED%8F%BC&uid=210 (accessed on 11 March 2022).
  2. Singh, M. An overview of grid computing. In Proceedings of the 2019 International Conference on Computing, Communication, and Intelligent Systems (ICCCIS), Greater Noida, India, 18–19 October 2019; pp. 194–198. [Google Scholar]
  3. Namane, S.; Goualmi, N. Grid and Cloud Computing Security: A Comparative Survey. Int. J. Comput. Netw. Appl. 2019, 6, 1–12. [Google Scholar] [CrossRef] [PubMed]
  4. Pagliarecci, F.; Spalazzi, L.; Spegni, F. Model checking grid security. Future Gener. Comput. Syst. 2013, 29, 811–827. [Google Scholar] [CrossRef]
  5. Chakrabarti, A.; Damodaran, A.; Sengupta, S. Grid Computing Security: A Taxonomy. IEEE Secur. Priv. 2008, 6, 44–51. [Google Scholar] [CrossRef]
  6. Bart, J.; Michael, B.; Kentaro, F.; Nihar, T. Introduction to Grid Computing, An IBM Redbooks Publication. 2005. Available online: http://www.redbooks.ibm.com/abstracts/sg246778.html?Open (accessed on 11 March 2022).
  7. Rajkumar, B.; Srikumar, V. A gentle introduction to grid computing and technologies. CSI Commun. 2005, 29. Available online: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.4243&rep=rep1&type=pdf (accessed on 20 March 2022).
  8. Marty, H.; Mary, R.T. Security implications of typical grid computing usage scenarios. Clust. Comput. 2002, 5, 257–264. [Google Scholar] [CrossRef]
  9. Lee, I.W.; Park, H.J. A Trend of P2P-Based Service and Charging Technics. Electron. Telecommun. Trends 2007, 22, 121–129. [Google Scholar]
  10. Gheorghe, G.; Renato, L.C.; Alberto, M. Security and privacy issues in P2P streaming systems: A survey. Peer-Peer Netw. Appl. 2011, 4, 75–91. [Google Scholar] [CrossRef] [Green Version]
  11. Jan, S. Security issues for P2P-based voice-and video-streaming applications. In Proceedings of the International Workshop on Open Problems in Network Security, Zurich, Switzerland, 23–24 April 2009; pp. 95–110. [Google Scholar]
  12. Rafael, V.C.; Jonata, T.P.; Rodolfo, S.A.; Marinho, P.B.; Ingrid, J.P.; Luciano, P.G. Challenging the feasibility of authentication mechanisms for P2P live streaming. In Proceedings of the 6th Latin America Networking Conference, New York, NY, USA, 12–13 October 2011; pp. 55–63. [Google Scholar]
  13. Torr, P. Demystifying the threat-modeling process. IEEE Secur. Priv. 2005, 3, 66–70. [Google Scholar] [CrossRef]
  14. Howard, M.; Lipner, S. The Security Development Lifecycle; Microsoft Press: Redmond, WA, USA, 2006. [Google Scholar]
  15. Adam, S. Threat Modeling: Designing for Security; Wiley: Hoboken, NJ, USA, 2014; ISBN 978-1-118-80999-0. [Google Scholar]
  16. Tony, U.; Marco, M.M. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis; Wiley: Hoboken, NJ, USA, 2015; ISBN 978-0-470-50096-5. [Google Scholar]
  17. Paul, S.; Brenda, L.; Michael, E. Trike v.1 Methodology Document [Draft]. 2005. Available online: https://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf (accessed on 11 March 2022).
  18. Deng, M.; Wuyts, K.; Scandariato, R.; Bart, P.; Wouter, J. A privacy threat analysis framework: Supporting the elicitation and fulfillment of privacy requirements. Requir. Eng. 2011, 16, 3–32. [Google Scholar] [CrossRef]
  19. Wuyts, K. Privacy Threats in Software Architectures. Ph.D. Thesis, KU Leuven, Leuven, Belgium, 2015. [Google Scholar]
  20. Park, E.J. A Study on Smart Factory Security Requirements Based on STRIDE Threat Modeling. Master’s Thesis, Korea University, Seoul, Korea, 2017. [Google Scholar]
  21. Park, J.H.; Kang, S.Y.; Kim, S.J. Study of Security Requirement of Smart Home Hub through Threat Modeling Analysis and Common Criteria. J. Korea Inst. Inf. Secur. Cryptol. 2018, 28, 513–528. [Google Scholar]
  22. Lee, J.S.; Kang, S.Y.; Kim, S.J. Study on the AI Speaker Security Evaluations and Countermeasure. J. Korea Inst. Inf. Secur. Cryptol. 2018, 28, 1523–1537. [Google Scholar]
  23. Lee, J.S.; Kang, S.Y.; Kim, S.J. Study on the Smart Speaker Evaluations and Countermeasures. Adv. Multimed. Ubiquitous Eng. 2019, 590, 50–70. [Google Scholar]
  24. Kim, H.M.; Kim, H.K. Threat Modeling and Risk Analysis: PS4 Remote Play with PC. J. Korea Inst. Inf. Secur. Cryptol. 2018, 28, 135–143. [Google Scholar]
  25. Kang, S.I.; Kim, H.M.; Kim, H.K. Trustworthy Smart Band: Security Requirements Analysis with Threat Modeling. J. Korea Inst. Inf. Secur. Cryptol. 2018, 28, 1355–1369. [Google Scholar]
  26. Cha, Y.S.; Kim, S.J. A Study on Security Requirements of Electric Vehicle Charging Infrastructure Using Threat Modeling. J. Korea Inst. Inf. Secur. Cryptol. 2017, 27, 1441–1455. [Google Scholar]
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.