2021.08.06

임베디드 TCP/IP 스택의 심각한 결함, 산업용 제어 장치가 위험하다

Lucian Constantin | CSO
임베디드 장치, 특히 산업 자동화용으로 만들어진 보존 기간이 긴 장치는 소프트웨어 취약점에 대한 인식이 지금처럼 보편적이지 않았던 시절에 개발된 내부 자체 코드와 서드파티 코드를 혼합해 사용하는 경우가 많다. 하드웨어 공급업체가 오랜 시간 동안 광범위하게 사용해 온 구성요소에서 발견된 치명적인 결함이 미치는 영향은 크다. 패치를 적용할 수 없는 경우도 있다.
 
ⓒ Getty Images Bank

시장조사업체 포스카우트 리서치 랩(Forescout Research Labs)과 J프로그 시큐리티 리서치(JFrog Security Research)가 지난해 다양한 IoT 및 기타 임베디드 시스템에 사용되는 TCP/IP 스택을 조사한 결과를 보면 이와 같은 문제점이 잘 나타난다. 이 조사에 이어 Ripple20, NAME:WRECK, NUMBER:JACK 또는 AMNESIA:33과 같이 수많은 장치에 영향을 미치는 중대한 결함이 발견됐다.

최근 <INFRA:HALT>라는 제목으로 발표된 보고서는 200여 개 공급업체의 운영 기술(OT) 장치에 광범위하게 사용되는 니치스택(NicheStack)이라는 사유 TCP/IP 스택에서 발견된 14개의 치명적인 취약점을 다룬다. 영향을 받는 장치에는 산업 자동화의 구성요소이자 핵심 인프라 부문에 사용되는 지멘스(Siemens) S7과 같은 PLC(Programmable Logic Controllers)도 포함된다.


TCP/IP 스택의 거대한 공격 표면

TCP/IP 스택 또는 인터넷 프로토콜 모음은 DNS, HTTP, FTP, ARP, ICMP를 비롯한 일반적인 인터넷 프로토콜 구현으로 구성되며, 운영체제와 애플리케이션에서 IP 네트워크를 통해 데이터를 송수신할 수 있게 해준다. 이 스택이 지원하는 프로토콜이 다양하고 처리하는 데이터 및 패킷 형식이 많은 만큼 무단으로 악용할 수 있는 공격 표면도 상당히 크다.

산업 제어 장치는 전통적으로 직렬 인터페이스를 통해 통신했지만 이후 이더넷 인터페이스를 도입하는 경우가 차츰 늘었다. 일반 컴퓨터 및 IT 장치와 통신할 수 있도록 이더넷에는 TCP/IP 스택도 자연스럽게 따라온다. 

현대의 많은 IoT 장치는 리눅스를 기반으로 실행하므로 보안 연구원과 리눅스 커널 개발자들이 30년 넘게 엄격히 관리해온 리눅스 TCP/IP 스택을 사용한다. 그러나 산업용 제어 장치는 사유 실시간 운영체제(Real-Time Operating Systems, RTOS)를 사용하는 경우가 많다. RTOS는 버전 관리가 들쭉날쭉하고 각자의 상황에 맞게 수정되고 소유권이 변경되기도 한 사유 TCP/IP 스택이 사용된다. 이와 같은 이유로 취약한 제품을 찾아 패치하기가 매우 어렵다.

니치스택은 1996년, 또는 이보다 더 이전에 인터니치 테크놀로지(InterNiche Technologies)라는 기업이 개발한 TCP/IP 스택으로, 2003년에 새로운 IPv6 기술을 지원하도록 확장됐다. 2016년 인터니치 테크놀로지는 HCC 임베디드(HCC Embedded)라는 기업에 인수됐고 이 기업이 지금도 스택을 유지관리하고 있다.

포스카우트의 연구진은 이 보고서에서 “이 스택은 지난 20년 동안 ST마이크로일렉트로닉스(STMicroelectronics), 프리스케일(Freescale, NXP), 알테라(Altera, 인텔), 마이크로칩(Microchip)과 같은 OEM에 의해 여러 RTOS, 또는 니치태스크(NicheTask)라는 간단한 자체 RTOS에서 사용하기 위해 여러 가지 변형으로 배포됐다. 또한 세거(SEGGER)의 emNet(이전의 embOS/IP)과 같은 다른 TCP/IP 스택의 기반이 되기도 했다”라고 설명했다.


메모리 손상(Memory corruption)

포스카우트와 J프로그 연구원들이 발견한 14개 취약점 가운데 대부분은 다양한 프로토콜에 대한 안전하지 않은 패킷 파싱에서 비롯되는 버퍼 오버플로우와 대역 외 메모리 읽기/쓰기다. 이와 같은 취약점은 DNSv4, HTTP, TCP, ICMP 또는 TFTP를 통해 악용이 가능하며 원격 코드 실행(2개 취약점)과 서비스 거부 조건(8개 취약점)으로 이어질 수 있다.

다른 결함의 원인은 예측 가능한 TCP ISN, 충분히 랜덤하지 않은 DNS 트랜잭션 ID, 그리고 DNS 쿼리의 예측 가능한 소스 포트 번호 등으로, 이를 통해 TCP 스푸핑이나 DNS 캐시 포이즈닝과 같은 공격이 가능해진다. 모든 취약점은 조사가 수행된 시점에서 최신 버전인 니치스택 버전 4.3 이전의 모든 버전에 영향을 미친다.

두 개의 원격 코드 실행 결함은 DNSv4와 HTTP 구현에 있으며, CVSS 등급은 각각 9.8과 9.1로 치명적인 등급에 해당한다. 서비스 거부(DoS) 문제의 심각도 지수는 7.5 또는 8.2다. 산업용 제어 시스템의 경우 영향을 받는 장치가 제어하는 산업 공정의 유형에 따라 DoS 문제가 매우 심각한 영향을 미칠 가능성이 있다는 점을 감안해야 한다.

예를 들어 DoS를 포함한 이런 취약점을 악용하는 공격으로부터 복구하기 위해서는 영향을 받는 장치의 전원을 끄고 켜야 할 수 있다. 포스카우트의 연구 부문 부사장인 엘리사 코스탄트는 “이 말은 장치에 물리적으로 접근해야 함을 의미한다. 문제의 장치가 해상 변전소나 석유 시추 시설에 있는 경우를 생각해 보면 그 영향은 상당히 크다고 할 수 있다”라고 말했다.


복잡한 취약점 조율 프로세스 

INFRA:HALT 취약점 공개 조율은 소프트웨어 취약점의 표준인 90일을 훨씬 넘긴 1년 가까이 지속됐다. 포스카우트와 J프로그 시큐리티 리서치는 해당 결함과 관련해 2020년 9월에 HCC 임베디드에 연락했고, CERT 코디네이션 센터(CERT/CC), 독일 연방 사이버 보안국(BSI), 그리고 미국 CISA 산하 산업용 제어 시스템 사이버 응급 대응 팀(ICS-CERT)과 협력했다.

이렇게 해도 영향을 받을 가능성이 있는 장치와 공급업체를 찾기는 매우 어려웠고 지금도 계속 찾는 중이다. 연구진은 쇼단(Shodan) 검색 엔진의 쿼리를 사용해 니치스택을 실행하는 6,400여 개의 공개적으로 접근 가능한 장치를 발견했다. 포스카우트는 수백만 개의 장치 핑거프린트가 있는 자체 데이터베이스를 사용해 21개 공급업체에서 2,500개의 잠재적으로 취약한 장치를 발견했다. 이 가운데 가장 큰 영향을 받는 분야는 공정 제조, 소매, 이산형 제조 분야다. 파악된 장치의 약 절반이 에너지 및 전력 산업 제어 시스템이다.

그러나 이런 수치는 결함의 실제 영향을 제대로 반영하지 못한다. 연구진에 따르면, 더 이상 온라인에 없는 인터니치의 레거시 웹사이트에는 200개에 육박하는 장치 공급업체가 고객으로 기재돼 있으며 여기에는 지멘스(Siemens), 에머슨(Emerson), 허니웰(Honeywell), 미쓰비시 일렉트릭(Mitsubishi Electric), 로크웰 오토메이션(Rockwell Automation), 슈나이더 일렉트릭(Schneider Electric) 등의 주요 OT 공급업체가 포함돼 있다.

코스탄트는 공개 주의보에 나온 공급업체의 수는 적지만 실제 영향을 받는 장치의 수는 수백만 개에 이를 것으로 추정된다면서 “이 연구 결과는 역사상 가장 많은 ICS 공급업체에 영향을 미치지만 실제 공개적으로 노출된 OT 장치의 수가 많지 않으므로 관련된 정보를 얻기가 더 어렵다”라고 말했다.

포스카우트는 TCP/IP 스택에 대한 조사와 관련해 영향을 받는 공급업체의 주의보 목록을 깃허브에 운영 중이다. INFRA:HALT와 관련된 새로운 주의보가 나오면 이 목록도 업데이트된다.


문제 완화를 위한 가시성 필요

HCC 임베디드는 취약점에 대한 패치를 개발했지만 이 패치는 고객이 요청하는 경우에만 제공되며 고객의 대부분은 장치 제조업체다. 영향을 받는 제품의 최종 사용자는 각각의 장치 제조업체가 패치를 적용할 때까지 기다려야 한다.

게다가 오래 전에 이 TCP/IP 스택을 제품에 통합한 모든 공급업체가 HCC 임베디드와 여전히 연락을 유지하고 있을 가능성은 높지 않고, 특히 중소 공급업체라면 더욱 기대하기 어렵다. 또한 영향을 받는 일부 장치는 지원 종료 시점을 넘겨 패치를 받지 못할 수도 있다.

코스탄트는 “또 다른 문제는 자산 소유자에 있다. 패치가 제공되더라도 소유자가 영향을 받는 장치를 갖고 있는지 알고 있느냐가 문제”라면서 “모든 장치를 완전히 인벤토리화하지 않은 경우도 있으므로 위험을 평가하는 것조차 쉽지 않다”라고 지적했다.

포스카우트는 오픈소스 스크립트를 개발했다. 자산 소유자는 이 스크립트를 사용해 네트워크에서 니치스택, 또는 이전에 프로젝트 메모리아(Project Memoria)라는 이름으로 수행된 더 큰 규모의 조사에서 발견된 취약점이 있는 다른 TCP/IP 스택을 실행하는 장치를 찾을 수 있다. 또한 포스카우트는 영향을 받는 장치를 찾고 악용 시도를 탐지할 수 있도록 자체 상용 제품을 업데이트했다.

패치 배포의 또 다른 문제는 영향을 받는 장치 중에는 공장 또는 산업 시설에서 필수적이거나 상시 가동해야 하는 공정을 제어하거나 원격지의 현장에 구축되어 있다는 것이다. 이 경우 예정된 유지보수 없이 즉시 가동 중단과 업데이트가 불가능하다. 코스탄트는 “대다수 공급업체, 특히 규모가 작은 경우 패치보다는 영향 완화가 더 효과적일 것”이라고 말했다.

INFRA:HALT 취약점을 완화하기 위한 포스카우트의 조언은 다음과 같다.
  
  • 세그먼트화 제어와 적절한 네트워크 위생을 통해 취약한 장치에서 발생하는 위험을 완화한다. 취약한 장치를 패치할 수 없는 경우(또는 패치가 가능해질 때까지) 위험 완화 수단으로 외부 통신 경로를 제한하고 취약한 장치를 따로 격리해야 한다.  
  • 영향을 받는 공급업체가 배포하는 패치를 모니터링하고 취약한 자산 인벤토리에 대한 교정 계획을 마련해 비즈니스 위험과 비즈니스 연속성 요구사항 간의 균형을 맞춘다.
  • 모든 네트워크 트래픽에서 알려진 취약점을 이용하려 시도하는 악성 패킷 또는 제로데이를 모니터링한다. 이상 트래픽이나 기형적인 트래픽은 차단하거나 최소한 네트워크 운영자에게 해당 트래픽의 존재를 알려야 한다.
  • DNSv4 클라이언트가 불필요하다면 비활성화하거나 DNSv4 트래픽을 차단한다. 여러 취약점이 DNS 스푸핑 공격을 가능하게 하는 원인이 되므로 내부 DNS 서버를 사용하는 것으로는 충분하지 않을 수 있다(공격자가 요청-응답 매칭을 가로챌 수 있음).
  • HTTP가 불필요하다면 비활성화하거나 HTTP 연결을 화이트리스트로 작성한다.
  • 트래픽에서 기형적인 IPv4/TCP 및 ICPMv4 패킷을 모니터링해 차단한다.  editor@itworld.co.kr


2021.08.06

임베디드 TCP/IP 스택의 심각한 결함, 산업용 제어 장치가 위험하다

Lucian Constantin | CSO
임베디드 장치, 특히 산업 자동화용으로 만들어진 보존 기간이 긴 장치는 소프트웨어 취약점에 대한 인식이 지금처럼 보편적이지 않았던 시절에 개발된 내부 자체 코드와 서드파티 코드를 혼합해 사용하는 경우가 많다. 하드웨어 공급업체가 오랜 시간 동안 광범위하게 사용해 온 구성요소에서 발견된 치명적인 결함이 미치는 영향은 크다. 패치를 적용할 수 없는 경우도 있다.
 
ⓒ Getty Images Bank

시장조사업체 포스카우트 리서치 랩(Forescout Research Labs)과 J프로그 시큐리티 리서치(JFrog Security Research)가 지난해 다양한 IoT 및 기타 임베디드 시스템에 사용되는 TCP/IP 스택을 조사한 결과를 보면 이와 같은 문제점이 잘 나타난다. 이 조사에 이어 Ripple20, NAME:WRECK, NUMBER:JACK 또는 AMNESIA:33과 같이 수많은 장치에 영향을 미치는 중대한 결함이 발견됐다.

최근 <INFRA:HALT>라는 제목으로 발표된 보고서는 200여 개 공급업체의 운영 기술(OT) 장치에 광범위하게 사용되는 니치스택(NicheStack)이라는 사유 TCP/IP 스택에서 발견된 14개의 치명적인 취약점을 다룬다. 영향을 받는 장치에는 산업 자동화의 구성요소이자 핵심 인프라 부문에 사용되는 지멘스(Siemens) S7과 같은 PLC(Programmable Logic Controllers)도 포함된다.


TCP/IP 스택의 거대한 공격 표면

TCP/IP 스택 또는 인터넷 프로토콜 모음은 DNS, HTTP, FTP, ARP, ICMP를 비롯한 일반적인 인터넷 프로토콜 구현으로 구성되며, 운영체제와 애플리케이션에서 IP 네트워크를 통해 데이터를 송수신할 수 있게 해준다. 이 스택이 지원하는 프로토콜이 다양하고 처리하는 데이터 및 패킷 형식이 많은 만큼 무단으로 악용할 수 있는 공격 표면도 상당히 크다.

산업 제어 장치는 전통적으로 직렬 인터페이스를 통해 통신했지만 이후 이더넷 인터페이스를 도입하는 경우가 차츰 늘었다. 일반 컴퓨터 및 IT 장치와 통신할 수 있도록 이더넷에는 TCP/IP 스택도 자연스럽게 따라온다. 

현대의 많은 IoT 장치는 리눅스를 기반으로 실행하므로 보안 연구원과 리눅스 커널 개발자들이 30년 넘게 엄격히 관리해온 리눅스 TCP/IP 스택을 사용한다. 그러나 산업용 제어 장치는 사유 실시간 운영체제(Real-Time Operating Systems, RTOS)를 사용하는 경우가 많다. RTOS는 버전 관리가 들쭉날쭉하고 각자의 상황에 맞게 수정되고 소유권이 변경되기도 한 사유 TCP/IP 스택이 사용된다. 이와 같은 이유로 취약한 제품을 찾아 패치하기가 매우 어렵다.

니치스택은 1996년, 또는 이보다 더 이전에 인터니치 테크놀로지(InterNiche Technologies)라는 기업이 개발한 TCP/IP 스택으로, 2003년에 새로운 IPv6 기술을 지원하도록 확장됐다. 2016년 인터니치 테크놀로지는 HCC 임베디드(HCC Embedded)라는 기업에 인수됐고 이 기업이 지금도 스택을 유지관리하고 있다.

포스카우트의 연구진은 이 보고서에서 “이 스택은 지난 20년 동안 ST마이크로일렉트로닉스(STMicroelectronics), 프리스케일(Freescale, NXP), 알테라(Altera, 인텔), 마이크로칩(Microchip)과 같은 OEM에 의해 여러 RTOS, 또는 니치태스크(NicheTask)라는 간단한 자체 RTOS에서 사용하기 위해 여러 가지 변형으로 배포됐다. 또한 세거(SEGGER)의 emNet(이전의 embOS/IP)과 같은 다른 TCP/IP 스택의 기반이 되기도 했다”라고 설명했다.


메모리 손상(Memory corruption)

포스카우트와 J프로그 연구원들이 발견한 14개 취약점 가운데 대부분은 다양한 프로토콜에 대한 안전하지 않은 패킷 파싱에서 비롯되는 버퍼 오버플로우와 대역 외 메모리 읽기/쓰기다. 이와 같은 취약점은 DNSv4, HTTP, TCP, ICMP 또는 TFTP를 통해 악용이 가능하며 원격 코드 실행(2개 취약점)과 서비스 거부 조건(8개 취약점)으로 이어질 수 있다.

다른 결함의 원인은 예측 가능한 TCP ISN, 충분히 랜덤하지 않은 DNS 트랜잭션 ID, 그리고 DNS 쿼리의 예측 가능한 소스 포트 번호 등으로, 이를 통해 TCP 스푸핑이나 DNS 캐시 포이즈닝과 같은 공격이 가능해진다. 모든 취약점은 조사가 수행된 시점에서 최신 버전인 니치스택 버전 4.3 이전의 모든 버전에 영향을 미친다.

두 개의 원격 코드 실행 결함은 DNSv4와 HTTP 구현에 있으며, CVSS 등급은 각각 9.8과 9.1로 치명적인 등급에 해당한다. 서비스 거부(DoS) 문제의 심각도 지수는 7.5 또는 8.2다. 산업용 제어 시스템의 경우 영향을 받는 장치가 제어하는 산업 공정의 유형에 따라 DoS 문제가 매우 심각한 영향을 미칠 가능성이 있다는 점을 감안해야 한다.

예를 들어 DoS를 포함한 이런 취약점을 악용하는 공격으로부터 복구하기 위해서는 영향을 받는 장치의 전원을 끄고 켜야 할 수 있다. 포스카우트의 연구 부문 부사장인 엘리사 코스탄트는 “이 말은 장치에 물리적으로 접근해야 함을 의미한다. 문제의 장치가 해상 변전소나 석유 시추 시설에 있는 경우를 생각해 보면 그 영향은 상당히 크다고 할 수 있다”라고 말했다.


복잡한 취약점 조율 프로세스 

INFRA:HALT 취약점 공개 조율은 소프트웨어 취약점의 표준인 90일을 훨씬 넘긴 1년 가까이 지속됐다. 포스카우트와 J프로그 시큐리티 리서치는 해당 결함과 관련해 2020년 9월에 HCC 임베디드에 연락했고, CERT 코디네이션 센터(CERT/CC), 독일 연방 사이버 보안국(BSI), 그리고 미국 CISA 산하 산업용 제어 시스템 사이버 응급 대응 팀(ICS-CERT)과 협력했다.

이렇게 해도 영향을 받을 가능성이 있는 장치와 공급업체를 찾기는 매우 어려웠고 지금도 계속 찾는 중이다. 연구진은 쇼단(Shodan) 검색 엔진의 쿼리를 사용해 니치스택을 실행하는 6,400여 개의 공개적으로 접근 가능한 장치를 발견했다. 포스카우트는 수백만 개의 장치 핑거프린트가 있는 자체 데이터베이스를 사용해 21개 공급업체에서 2,500개의 잠재적으로 취약한 장치를 발견했다. 이 가운데 가장 큰 영향을 받는 분야는 공정 제조, 소매, 이산형 제조 분야다. 파악된 장치의 약 절반이 에너지 및 전력 산업 제어 시스템이다.

그러나 이런 수치는 결함의 실제 영향을 제대로 반영하지 못한다. 연구진에 따르면, 더 이상 온라인에 없는 인터니치의 레거시 웹사이트에는 200개에 육박하는 장치 공급업체가 고객으로 기재돼 있으며 여기에는 지멘스(Siemens), 에머슨(Emerson), 허니웰(Honeywell), 미쓰비시 일렉트릭(Mitsubishi Electric), 로크웰 오토메이션(Rockwell Automation), 슈나이더 일렉트릭(Schneider Electric) 등의 주요 OT 공급업체가 포함돼 있다.

코스탄트는 공개 주의보에 나온 공급업체의 수는 적지만 실제 영향을 받는 장치의 수는 수백만 개에 이를 것으로 추정된다면서 “이 연구 결과는 역사상 가장 많은 ICS 공급업체에 영향을 미치지만 실제 공개적으로 노출된 OT 장치의 수가 많지 않으므로 관련된 정보를 얻기가 더 어렵다”라고 말했다.

포스카우트는 TCP/IP 스택에 대한 조사와 관련해 영향을 받는 공급업체의 주의보 목록을 깃허브에 운영 중이다. INFRA:HALT와 관련된 새로운 주의보가 나오면 이 목록도 업데이트된다.


문제 완화를 위한 가시성 필요

HCC 임베디드는 취약점에 대한 패치를 개발했지만 이 패치는 고객이 요청하는 경우에만 제공되며 고객의 대부분은 장치 제조업체다. 영향을 받는 제품의 최종 사용자는 각각의 장치 제조업체가 패치를 적용할 때까지 기다려야 한다.

게다가 오래 전에 이 TCP/IP 스택을 제품에 통합한 모든 공급업체가 HCC 임베디드와 여전히 연락을 유지하고 있을 가능성은 높지 않고, 특히 중소 공급업체라면 더욱 기대하기 어렵다. 또한 영향을 받는 일부 장치는 지원 종료 시점을 넘겨 패치를 받지 못할 수도 있다.

코스탄트는 “또 다른 문제는 자산 소유자에 있다. 패치가 제공되더라도 소유자가 영향을 받는 장치를 갖고 있는지 알고 있느냐가 문제”라면서 “모든 장치를 완전히 인벤토리화하지 않은 경우도 있으므로 위험을 평가하는 것조차 쉽지 않다”라고 지적했다.

포스카우트는 오픈소스 스크립트를 개발했다. 자산 소유자는 이 스크립트를 사용해 네트워크에서 니치스택, 또는 이전에 프로젝트 메모리아(Project Memoria)라는 이름으로 수행된 더 큰 규모의 조사에서 발견된 취약점이 있는 다른 TCP/IP 스택을 실행하는 장치를 찾을 수 있다. 또한 포스카우트는 영향을 받는 장치를 찾고 악용 시도를 탐지할 수 있도록 자체 상용 제품을 업데이트했다.

패치 배포의 또 다른 문제는 영향을 받는 장치 중에는 공장 또는 산업 시설에서 필수적이거나 상시 가동해야 하는 공정을 제어하거나 원격지의 현장에 구축되어 있다는 것이다. 이 경우 예정된 유지보수 없이 즉시 가동 중단과 업데이트가 불가능하다. 코스탄트는 “대다수 공급업체, 특히 규모가 작은 경우 패치보다는 영향 완화가 더 효과적일 것”이라고 말했다.

INFRA:HALT 취약점을 완화하기 위한 포스카우트의 조언은 다음과 같다.
  
  • 세그먼트화 제어와 적절한 네트워크 위생을 통해 취약한 장치에서 발생하는 위험을 완화한다. 취약한 장치를 패치할 수 없는 경우(또는 패치가 가능해질 때까지) 위험 완화 수단으로 외부 통신 경로를 제한하고 취약한 장치를 따로 격리해야 한다.  
  • 영향을 받는 공급업체가 배포하는 패치를 모니터링하고 취약한 자산 인벤토리에 대한 교정 계획을 마련해 비즈니스 위험과 비즈니스 연속성 요구사항 간의 균형을 맞춘다.
  • 모든 네트워크 트래픽에서 알려진 취약점을 이용하려 시도하는 악성 패킷 또는 제로데이를 모니터링한다. 이상 트래픽이나 기형적인 트래픽은 차단하거나 최소한 네트워크 운영자에게 해당 트래픽의 존재를 알려야 한다.
  • DNSv4 클라이언트가 불필요하다면 비활성화하거나 DNSv4 트래픽을 차단한다. 여러 취약점이 DNS 스푸핑 공격을 가능하게 하는 원인이 되므로 내부 DNS 서버를 사용하는 것으로는 충분하지 않을 수 있다(공격자가 요청-응답 매칭을 가로챌 수 있음).
  • HTTP가 불필요하다면 비활성화하거나 HTTP 연결을 화이트리스트로 작성한다.
  • 트래픽에서 기형적인 IPv4/TCP 및 ICPMv4 패킷을 모니터링해 차단한다.  editor@itworld.co.kr


X