- 🇰🇷 번역상태: 1차 검토/수정 중
이 글은 저자의 허락을 받아 영문으로 된 원문을 한국어로 번역한 글입니다.
번역에 참여하실 분은 기존에 생성된 issue를 참조하시고 필요시 새 issue 등록 후 작업 바랍니다.
-
아래 글 번역에 참여한 이:
-
원본 문서: IPinside: Korea’s mandatory spyware (2023-01-25)
-
번역 문서 최초 작성일: 2023-01-25 (PR을 통해 계속 업데이트 중)
대한민국의 소위 보안 애플리케이션이라 불리는 것들을 살펴보는 여정 (번역판)을 시작하며 이미 TouchEn nxKey에 대해서 살펴보았는데, 이 애플리케이션은 키로거를 막기 위해 ... 노트를 뒤적이며 ... 키로킹을 더 쉽게 만들어 버렸다. 오늘은 대한민국에 거주하는 많은 사람들이 컴퓨터에 설치를 해야만하는 또 다른 애플리케이션을 조명해 보겠다. 그것은 인터리젠 (Interezen) 에서 만든 IPinside LWS Agent 이다.
이 애플리케이션의 명시된 목적은 사용자의 "실제 (real)" IP 주소를 확인하여 온라인 사기를 막는 것이다. 하지만 원래 용도보다 훨씬 더 많은 양의 데이터를 수집하는 것으로 확인하였다. 어떤 웹사이트든 격식을 갖춰 요청할 경우 많은 데이터를 제공하지만 실제 사기를 막는데는 그다지 유용해 보이지 않는다.
- 어떻게 동작할까?
- 어떤 데이터를 포함하는가?
- 이 데이터는 어떻게 보호하는가?
- 그러면 애플리케이션의 전반적인 보안은 어떨까?
- 언제 수정될까?
- 과연 IPinside는 온라인 뱅킹을 더 안전하게 만들까?
TouchEn nxKey와 유사하게 IPinside LWS Agent 애플리케이션도 로컬 서버를 통해서 웹사이트와 통신을 한다.
대한민국의 은행 웹사이트가 접속자에 대한 정보를 더 얻기 위해 localhost:21300로 JSONP 요청을 보낸다.
이 요청이 실패할 경우, 은행 웹사이트는 접속을 거부하고 IPinside LWS Agent를 먼저 설치할 것을 요구한다.
그러므로 대한민국에서 이 애플리케이션의 실행여부는 선택의 여지가 없다.
다른 한편으로, 이 애플리케이션이 실행되고 있다면 웹사이트는 wdata, ndata 와 udata 필드를 통해서 다양한 데이터를 받아 볼 수 있다. 사실 꽤 많은 데이터가 전송된다:
이 데이터에서는 접속자의 IP주소를 담고 있지만 크기로 봤을 때 그 것만을 포함한 것이 아니라는 사실이 뻔하다. 실제로 훨씬 더 많은 데이터가 전송된다.
일단 가장 흥미로운 자료 구조를 가지고 있는 wdata 부터 살펴보자.
복호화 할 경우 꽤 많은 양의 바이너리 데이터를 얻을 수 있다:
결과물에서 보듯이, 가상 머신 내에서 IPinside를 실행중이다.
심지어 이 컴퓨터가 더 이상 VirtualBox 상에서 실행되고 있지 않음에 불과하고 결과물 끝에 VirtualBox도 읽을 수 있다.
다른 뻔히 보이는 데이터는 내 가상 머신에 장착된 두 개의 하드 드라이브이다. 하나는 시리얼 번호가 QM00001이고 다른 하나는 abcdef 이다. F0129A45 는 주 하드 드라이브 볼륨의 시리얼 번호이다.
그리고 자세히 살펴보면 다음과 같은 연속된 바이트가 보인다; c0 a8 7a 01 (내 IP 주소인 192.168.122.1 을 나타냄), c0 a8 7a 8c (192.168.122.140, 첫 네트워크 카드의 IP 주소) 그리고 c0 a8 7a 0a (192.168.122.10, 두번째 네트워크 카드의 IP 주소).
하지만 이 보다 더 많은 정보들이 있다.
예를 들면 하드 드라이브 정보 전에 나오는 65 (문자 e)의 경우 GetProductInfo() 힘수를 호출한 결과값이다. 이 것은 내가 윈도우 10 홈 에디션을 사용하고 있는 것을 나타낸다. 그 전에 74 (문자 t) 는 내가 사용하는 정확한 윈도우 버전 정보를 저장하고 있다.
한 가지 데이터가 특별히 더 흥미롭다.
어디서 firefox.exe 라는 데이터가 왔는지 궁금하지 않은가?
이것은 모질라 파이어폭스 프로세스가 백그라운드로 실행중이라는 것을 나타낸다.
실제 사용하는 애플리케이션이 구글 크롬인데도 불구하고 이 정보가 전송된다.
웹사이트에서 아웃풋을 정하는 여러 파라미터를 IPinside에게 전송한다.
그 파라미터 중에 하나는 winRemote이다.
간단한 난독화가 적용(obfuscated)되어 있지만 난독화를 풀고 나면 다음과 같은 데이터를 얻을 수 있다:
TeamViewer_Desktop.exe|rcsemgru.exe|rcengmgru.exe|teamviewer_Desktop.exe
이 것을 보면 은행 웹사이트에서는 당신이 원격 접속 도구를 사용하는지 알고 싶어 한다.
만약 주어진 문자열과 일치하는 프로세스를 발견하게 되면 wdata응답에 추가된다.
물론 이 기능은 원격 접속 도구만 찾는 용도로만 제한되지 않는다.
winRemote 파라미터를 AGULAAAAAAtmaXJlZm94LmV4ZQA=으로 대체하면 파이어 폭스의 현재 실행여부에 대한 정보를 받아올 수 있다.
그러므로 이 기능은 관심있는 어떤 애플리케이션이든 그것의 실행여부를 찾는데 악용될 수 있다.
이것이 전부가 아니다.
IPinside agent는 substring으로도 매칭을 한다.
그래서 fire라는 이름이 들어간 프로세스가 실행중인지 알려 줄 수 있다.
웹사이트에서는 이 기능만으로 실행 가능한 프로세스를 모르는 상태에서도 충분히 실행 중인 프로세서의 목록을 얻어올 수 있다.
나는 .exe 접미로 시작해서 깊이 우선탐색 (depth-first search)을 하는 웹페이지를 만들었다.
여기서 문제점은 IPinside의 각 요청에 대한 응답속도가 1/2 초 정도로 느리다는 것이었다.
성능을 약간 향상시키기 위해 여러 개의 추측을 하나의 요청으로 묶었고 이것을 바탕으로 40-50초 마다 프로세스 이름을 찾아내는 개념 증명 (proof of concept) 페이지를 만들었다:
충분한 시간만 주어진다면 이 웹페이지는 시스템에서 실행되는 모든 프로세스를 알아낼 수 있다.
응답에서 ndata부분은 훨씬 더 단순하다. 이 것은 다음과 같다:
��HDATAIP=▚▚▚.▚▚▚.▚▚▚.▚▚▚��VD1NATIP=▚▚▚.▚▚▚.▚▚▚.▚▚▚��VD1CLTIP=192.168.122.140��VD2NATIP=��VD2CLTIP=192.168.122.10��VPN=2��ETHTYPE=ETH1
내가 데이트 복호화 과정에 실수를 한 것이 아니다.
�가 실제 응답에 포함되어 있다.
원래는 ∽ (reverse tilde 부호)를 구분자로 사용하려는 것인데 내 운영체제에 한국어 설정이 되어 있지 않기 때문에 (IPinside LWS Agent와 같이) 유니코드를 사용하지 않는 애플리케이션의 경우 문자 인코딩이 EUC-KR로 설정되지 않는다.
애플리케이션은 이런 상황을 지원하도록 만들지 않아서 UTF-8로의 변환을 제대로 처리하지 못한다.
다른 한 편으로 ▚▚▚.▚▚▚.▚▚▚.▚▚▚ 는 내 IP주소를 숨기기 위해 직접 대체한 문자이다.
애플리케이션은 두 가지 방식을 사용해서 IP 주소를 얻는다.
VD1NATIP 는 내 집에 있는 라우터로부터 얻어온 듯 보인다.
하지만 HDATAIP 는 웹서버로부터 온다.
어떤 웹서버일까?
그것은 웹사이트가 애플리케이션에 전달하는 host_info 파라미터로 결정된다.
이 값은 난독화 처리된 값이며 실제 값은 다음과 같다:
앞의 2파트만 사용되는 것처럼 보인다.
애플리케이션은 http://www.securetrueip.co.kr:80/androidagent.jsc로 요청을 보낸다.
응답 헤더의 내용 중 하나는 RESPONSE_IP이다.
여러분이 맞췄듯이 이 것은 웹서버가 봤을 때의 접속자 IP주소이다.
여기서 애플리케이션은 하위 레벨의 WS2_32.DLL API를 사용하는데 아마도 웹으로 전송되는 데이터가 프록시 서버나 VPN을 통하는 것을 방지하려고 일 것이다. 결국 목표는 사용자를 비익명화 (deanomymizing)하는데 있으니 말이다.
마지막으로 udata가 있는데 “u” 는 “unique”의 약자다.
여기에는 몇 가지 다른 아웃풋 타입이 있다.
다음은 타입 13이다:
[52-54-00-A7-44-B5:1:0:Intel(R) 82574L Gigabit Network Connection];[52-54-00-4A-FD-6E:0:0:Intel(R) 82574L Gigabit Network Connection #2];$[QM00001:QEMU HARDDISK:];[abcdef:QEMU HARDDISK:];[::];[::];[::];
역시 네트워크 카드들과 하드 드라이브의 목록이 보인다. 하지만 이번에는 네트워크 카드의 MAC 주소도 목록에 포함되어 있다. 다른 아웃풋 타입은 대체로 유사한 데이터를 별도의 포멧으로 저장한 것이지만 타입 30은 예외이다. 이것은 16바이트의 데이터로 16진수 CPU 식별자를 포함하여 15개의 서로 다른 CPUID 명령호출의 결과를 합쳐서 만든 것이다.
사용자를 비익명화하기 위한 여러 데이터들이 사용된다. 사용자가 사용하는 하드웨어와 소프트웨어에 대한 데이터를 통해서 시스템에 어떤 취약점이 있는지 들춰내므로 이 것을 통해 잠재적으로 다른 공격을 도울 가능성도 있다. 그렇다면 당연히 이런 데이터는 잘 보호하고 있겠지? 한국의 모든 온라인 뱅킹 웹사이트 및 한국 정부 웹사이트가 다 사용하니까 말이다. 그리고 더 많은 인터리젠 고객이 있을테니까. 하지만 이외의 다른 사용자는 없을 것이다. 그렇지 않은가?
localhost:21300에서 동작하는 서버는 누가 응답하는지 상관하지 않는다.
어떤 웹사이트든 데이터를 요청할 수 있다.
하지만 데이터를 디코딩 하는 방법은 알아야 한다.
wdata에 대해서는 3단계의 보호 장치가 적용된다: 난독화, 압축 그리고 암호화.
그렇다. 무작위 한 바이트의 데이터를 기반으로 XOR연산을 한 결과로는 데이터를 제대로 보호한다고 보기 어렵다.
압축도 데이터 보호라고 볼 수 없다.
왜냐하면 인터리젠에서 라이선스 위반까지하며 사용한 잘 알려진 GPL 라이선스의 코드을 다른 사람들은 쉽게 찾을 수 있을 것이다.
하지만 암호화가 있고 이것은 공개키 암호화를 사용한다.
애플리케이션에는 공개 RSA키만 가지고 있고 이것 만으로는 데이터를 복호화하는데 충분하지 않다. 비공개키는 인터리젠과 그들의 여러 고객들만 알고 있다. 단지 모든 고객들이 이 비공개키를 적절히 보호하고 있어어서 임의의 해커가 이것을 손에 넣지 못하기를 바랄 뿐이다.
어쨋든 RSA 암호화는 적당한 길이의 키(moderately sized key)를 사용하면 안전하다고 간주할 수 있다. 하지만 여기서 사용된 키는 적당한 길이의 키라고 할 수도 없다. 심지어 약한 키(weak key)가 사용되는 것도 아니다. 320비트의 키 이야기이다. 첫 RSA 소인수분해 챌린지 (RSA Factoring Challenge)에서 사용되었던 첫 키보다도 길이가 짧다. 그 챌랠지는 1991년 4월에 있었던 챌린지로 30년 전 이야기이다. 제대로 된 RSA 라이브러리라면 이렇게 짧은 키로 동작조차하지 않는다.
그래서 msieve를 다운로드 해서 내 노트북 CPU에서 하나의 코어만 사용하도록하여 실행했다.
$ ./msieve 108709796755756429540066787499269637…
sieving in progress (press Ctrl-C to pause)
86308 relations (21012 full + 65296 combined from 1300817 partial), need 85977
sieving complete, commencing postprocessing
linear algebra completed 80307 of 82231 dimensions (97.7%, ETA 0h 0m)
elapsed time 02:36:55
그렇다. 이런 기본적인 성능의 하드웨어에서 2시간 36분 만에 비공개키를 계산해 냈다. 여기서 사용된 RSA 암호화가 제공하는 보호란 것이 딱 그 정도 수준이다.
ndata와 udata를 살펴보면 더 절망적이다.
여기서 적용된 유일한 보호장치는 암호화이다.
공개키 암호화가 아니라 AES-256 기반의 대칭 암호화이다.
그리고 다른 방법이 없기에 암호화키는 애플리케이션 내에 하드코딩되어 있다
설상가상으로 매 실행마다 동일한 ciphertext를 생성한다. 난 처음에 이것이 deprecate된 ECB 블록 연쇄모드)의 결과를 사용할 것으로 생각했다. 하지만 아니였다. 애플리케이션은 CBC 블로 연쇄 모드(CBC block chaining mode)를 사용한다. 하지만 암호화 라이브러리에 초기화 벡터(initialization vector)를 전달하지 않아서 초기화 벡터를 항상 영으로 채운다.
앞의 긴 이야기를 단순히 말하면 이것은 애플리케이션에서 암호화키를 추출할 수 있는지의 여부와 상관없이 암호화를 풀 수 있다는 말이다.
요약하자면 이 데이터를 제대로 보호하고 있지 않다. 만약 사용자가 IPinside LWS Agent를 설치했다면 어떤 임의의 웹사이트에서도 수집한 데이터를 접근할 수 있다. 적용된 암호화는 무용지물이다.
21300 포트에서 실행되는 웹서버 애플리케이션은 어떤 것인가? 이것은 하위레벨 네트워크 소켓 기능을 사용해 자체 개발한 코드이다. 이 사실 만으로는 아무 문제가 없지 않은가? 누가 서브스트링 매칭을 사용해 요청을 파싱하는 기초적인 웹서버를 만들어서 수백만명에게 배포해본 적이 없겠는가?
이 웹서버도 여전히 SSL 지원이 필요하므로 OpenSSL 라이브러리를 사용하고 있다. 어떤 라이브러리 버전일까? 물론 OpenSSL 1.0.1j 버전이다. 그렇다 ,이것은 8년 전에 릴리즈 된 것이다. 그렇다, 6년전에 OpenSSL 1.0.1에 대한 지원이 중단되었다. 그렇다, 1.0.1j 이후로 1.0.1 브랜치에 11번의 추가 릴리즈가 있었고 수 많은 취약점이 수정되었지만 IPinside LWS Agent에는 하나도 적용되지 않았다.
역시 그 웹서버는 단일 쓰레드로 동작한다. 왜 그렇지 않겠는가? 사람들이 은행 웹사이트 2곳을 동시에 띄우지는 않을 테니까. 그렇다 이 것으로 악성 웹사이트가 오래 실행되는 요청(서비스 거부 공격)으로 웹서버를 락업 하는 것이 가능하다. 하지만 그래봤자 사용자들이 온라인 뱅킹이나 정부 웹사이트에 접속하는 것을 막을 뿐이다. 그렇게 심각한 일은 아니지 않는가?
서버의 구현을 살펴보니 다음과 유사한 동작을 하는 코드를 볼 수 있다:
BYTE inputBuffer[8192];
char request[8192];
char debugString[8192];
memset(inputBuffer, 0, sizeof(inputBuffer));
memset(request, 0, sizeof(request));
int count = ssl_read(ssl, inputBuffer, sizeof(inputBuffer));
if (count <= 0)
{
…
}
memcpy(request, inputBuffer, count);
memset(debugString, 0, sizeof(debugString));
sprintf(debugString, "Received data from SSL socket: %s", request);
log(debugString);
handle_request(request);이 코드의 문제점을 찾을 수 있는가?
...
기다리고 있다. 빨리 찾아 보아라.
...
물론 난 약간의 도움을 받았다.
난 여러분과 다른게 실제 코드를 디버깅 했고 얼마나 안 좋은 결과들이 있는지 실시간으로 확인하였다.
...
먼저 ssl_read 가 정확히 8192 바이트를 리턴해서 버퍼를 꽉 채울 수도 있다.
이럴 경우 inputBuffer는 널문자로 종료되지 않는다.
그리고 이것을 복사한 request 도 마찬가지로 널문자로 종료되지 않는다.
그래서 sprintf() 나 handle_request()에서 request를 널문자로 종료되는 문자열로 취급할 경우 버퍼를 초과해서 읽을 것이다.
사실 메모리 구성을 보면 동일한 데이터를 가진 inputBuffer 메모리 영역을 읽고 무엇이든 그 다음에 오는 데이터까지 읽어버린다.
그렇게 되면 sprintf() 는 16384 바이트 이상의 데이터를 읽을텐데 타깃 버퍼에 다 담기는 너무 크다. 만약 널종료문자가 있다고 해도 8192 바이트의 문자열에 더 많은 문자를 추가한 후 그 것을 8192 바이트의 버퍼에 넣을 수는 없다.
이것은 코드에서 발견한 단순 한 건의 오류가 아니다. 이 애플리케이션의 기능을 연구하면서 이외에도 여러 건의 스택오버플로우나 버퍼의 범위를 벗어난 읽기를 발견했다. 내 (매우) 제한적인 바이너리 취약점 공격에 대한 이해를 바탕으로는 이 취약점을 사용해 원격코드 실행을 할 수는 없을 것이다. 고맙게도 StackGuard와 SafeSEH 기능이 효율적으로 동작하고 있어서 그렇다. 만약 좀 더 경험이 많은 사람이 이 것을 우회할 수 있는 방법을 찾는다면 문제는 매우 심각해 질 것이다. 애플리케이션은 ASLR 이나 DEP 보호가 사용되지 않고 있다.
하지만 이 취약점 중 일부는 확실히 애플리케이션을 죽일 수도 있다. 난 2개의 개념증명 (proof of concept) 웹페이지를 만들어서 여러 차례 이 사실을 확인하였다. 이것은 또 다른 서비스 거부 공격으로 사용될 수 있고 사용자들이 대한민국에서 온라인 뱅킹을 사용하지 못하는데 쓰일 수 있다.
나는 2022년 10월 21일 3건의 취약점 보고서를 KrCERT에 신고하였다. 11월 14일에 KrCERT에서 보고서들을 인터리젠에 전달하였다고 확인해 주었다. 그 이후로 아무 소식도 듣지 못하였다.
이 사실을 공개하기 이전에 어떤 한국의 기자가 인터리젠에게 답변을 요청하였다. 내 보고서를 받은 것은 확인해 주었으나 보고서 중에 하나만 2023년 1월 6일에서야 받았다고 주장하였다. 그렇기 때문에 문제점에 대한 수정버전은 2월에 배포할 예정이고 그 이후 새로운 버전을 사용자에게 배포하는 것은 그들의 고객(즉 은행 등)에 달려 있다고 하였다.
다른 유사 애플리케이션처럼 이 소프트웨어는 자동 업데이트 기능이 없다. 그래서 사용자가 수동으로 업데이트를 다운로드해서 설치를 하든지 Wizvera Veraport와 같은 관리 애플리케이션을 통해서 업데이트를 해야한다. 은행에서 오래된 IPinside 버전의 사용을 거부하고 사용자에게 업데이트를 강제하지 않는 이상 둘 다 가능성이 적어 보인다.
인터리젠은 단순히 IPinside agent 애플리케이션만을 제공하는 것이 아니다. 그들이 직접 작성한 설명을 보면 빅 데이터 전문 기업이다. 데이터를 수집하고 분석하는 서비스를 많은 은행, 보험사 그리고 정부기관들에 제공하고 있다.
온라인에서 2009년에 작성된 매뉴얼)을 찾았는데 인터리젠의 백엔드 솔루션의 화면 캡처를 볼 수 있다. 웹사이트에 접속하는 모든 방문자를 추적하는 것을 알 수 있고 그들의 정보도 볼 수 있다. 2009년에는 IP주소 이외의 정보를 별로 수집하지 않았지만 백엔드의 현재 버전은 agent 애플리케이션이 수집하는 모든 정보를 보여준다고 추정할 수 있다.
IPinside 3.0 제품 설명서 화면 캡쳐
이미 2009년도에 각 사용자에 대한 상세 정보를 보여주는 것 외에도 IP주소, 위치, 브라우저, 운영체제 등의 정보를 바탕으로 통계요약을 보여주는 것이 가능했다.
IPinside 3.0 제품 설명서 화면 캡쳐
여기서 목표는 사용자 보호가 아니다. 은행과 다른 인터리젠의 고객을 보호하는 것이다. 은행이 더 많은 정보를 가지고 있으면 사기나 공격을 더 쉽게 막을 수 있다는 생각이다. 사기꾼은 단순히 프록시나 VPN만을 사용하는 것 만으로는 신분을 숨길 수 없다. 은행이 그것과 상관없이 그들을 인식할 수 있을 것이다.
사실 인터리젠은 그들이 가진 아이디어로 한국내에서 몇 가지 특허를 등록했다. 첫번째 특허인 대한민국 등록특허공보 10-1005093호는 "클라이언트 식별 방법 및 장치"로 명시되어 있다. 특허 출원서에 "발명"에 대한 이유는 다음과 같다고 나와 있다. (역자 주: 원문은 한국어 자동번역을 사용했으나, 아래는 대신 한국 특허 문서에서 직접 인용했다.)
불특정 다수를 대상으로 하는 인터넷 환경에서 클라이언트를 식별하는 방법의 중요성과 가치는 점점 증대되고 있다. 그러나 다양한 위장 및 은폐수단의 발전과 현존 하는 식별 기술의 한계로 인해 제대로 된 식별과 분석이 현실적으로 매우 어렵다.
여기에 더하여 쿠키의 사용이 충분치 않으며 사용자의 실제 (real) IP주소를 획득해야 한다고 설명한다.
"전자상거래 불법 침입 감시 및 차단 방법과 시스템" 라는 제목의 대한민국 등록특허공보 10-1088084호는 앞의 논리를 다음과 같이 확장하고 있다 (역자 주: 역시 한국 특허 원문을 인용한다.)
본 발명은 인터넷을 통한 모든 전자상거래서비스와 관련된 불법거래의 탐지/차단에 있어서 기존 보안시스템으로는 불가능했던 실시간 처리를 가능케 하는 기술과 기존 보안 기술로는 정상적인 거래로 판단될 수밖에 없는 전자상거래 불법거래까지도 탐지/차단하는 기술 및 서비스 업체의 정책에 따라 상기 탐지/차단을 운영할 수 있게 하는 기술을 제공하는 것이다.
이 특허에는 웹사이트 사용을 위해서 사용자에게 agent를 설치 강제한다는 개념이 소개되고 있다.
하지만 이러한 방법이 실제 제대로 동작할까?
사기꾼들이 자신들의 웹서버를 localhost:21300에 설치한 후 뱅킹 웹사이트에 가짜 데이터를 전송하는 것을 막을 수 있을까?
그러려면 누군가 IPinside LWS Agent를 역동학(reverse engineering)을 통해 기능을 알아낸 후 복제해야 한다. 물론 그렇게 단순한 일이 아니다. 내가 해본 바로는 .... 노트를 뒤적이며 ... 개념 증명을 만드는 것을 포함 일주일이나 걸렸다. 사기꾼들이 여러 레벨의 난독화 기능을 해독하기 위해 그만큼의 시간을 투자할 리가 없다.
잠깐만, 하지만 굳이 그렇게까지 할 필요가 있을까?
재전송 공격(replay attack) 이 훨씬 더 단순하다. 미리 저장해둔 유효한 응답을 웹사이트에 보내는 것으로 충분하다.
여기엔 challenge-handshake scheme도 없으며, 타임 스탬프(timestamp)도 없고, 이 공격을 막을 아무 것도 존재하지 않는다.
아마도 웹사이트에서 이전에 이미 사용되었던 응답이라고 인식할 수도 있다.
하지만 그것도 제대로 동작하지 않는다: ndata나 udata 난독화는 랜덤성도 없으며 데이터는 항상 동일하다.
그리고 wdata는 난독화시 단지 랜덤 바이트 하나만 사용한다. 이것만으로는 동일한 유효 응답 중에 재전송된 응답을 신뢰있게 구분할 수 없다.
그러므로 IPinside는 막대한 개인정보 침해를 하는 것으로 보이며 아무나 그것을 요청하는 누구에게든 너무나 많은 정보를 노출하고 있다. 그럼에도 불구하고 그들이 주장하는 것처럼 불법 거래를 제대로 막는 것도 부족하다. 내가 틀렸음을 증명하기 바란다.