아래에 오디오 플레이어가 없습니까? 듣다 직접 사운드클라우드에서.

더그.  암호 관리자 크랙, 로그인 버그, 엘리자베스 XNUMX세 대 스코틀랜드 메리 여왕… 물론이죠!

Naked Security 팟캐스트에서 이 모든 것.

[뮤지컬 모뎀]

팟캐스트에 오신 것을 환영합니다.

저는 Doug Aamoth입니다. 그는 폴 더클린이다.

폴, 어때?

오리.  와우!

16세기 정보 기술 skullduggery가 Naked Security 팟캐스트인 Douglas를 만납니다.

기다릴 수 없어!

더그.  분명히, 예… 곧 다룰 것입니다.

그러나 항상 그렇듯이 28년 1987월 XNUMX일, 온라인 서비스 제공업체인 CompuServe는 항상 그렇듯이 이번 주 기술 역사에서 그래픽 교환 형식(GIF [HARD G])이라는 작은 것을 출시했습니다.

CompuServe의 엔지니어 고 스티브 윌하이트(Steve Wilhite)가 초기 컴퓨터 네트워크의 제한된 대역폭과 저장 용량에서 컬러 이미지를 지원하는 수단으로 개발했습니다.

초기 버전인 GIF 87a는 최대 256색을 지원했습니다. 간단한 애니메이션을 표시하는 기능과 다양한 컴퓨터 시스템에 대한 광범위한 지원으로 인해 빠르게 인기를 얻었습니다.

감사합니다, 윌하이트 씨.

오리.  그리고 그것이 우리에게 무엇을 남겼습니까, 더글라스?

웹 애니메이션, 단어가 "그래픽"[HARD G]으로 발음되는지 또는 "giraffics"[SOFT G]로 발음되는지에 대한 논란.

더그.  정확히. [웃음]

오리.  나는 그것을 "giff"라고 부르지 않을 수 없습니다 [HARD G].

더그.  같은!

도장을 찍고 흥미진진한 이야기로 넘어갑시다…

...엘리자베스 XNUMX세 여왕, 스코틀랜드의 메리 여왕, 그리고 한 남자에 대해 양쪽 모두 연주 랜섬웨어 사기꾼과 그의 고용주인 Paul 사이.

랜섬웨어 이야기: 실제로 중간에 사람이 있었던 MitM 공격

오리.  [LAUGHS] 이야기의 끝에서 시작합시다.

기본적으로 영국 옥스퍼드셔에 있는 기술 회사에 대한 랜섬웨어 공격이었습니다.

(이것이 아니라… Sophos가 기반을 두고 있는 Abingdon-on-Thames에서 상류로 15km 떨어진 Oxford에 있는 회사였습니다.)

랜섬웨어의 공격을 받은 후 그들은 상상할 수 있듯이 데이터를 되찾기 위해 비트코인을 지불하라는 요구를 받았습니다.

그리고 그 이야기처럼 우리는 몇 주 전에, 이 문제를 해결하는 데 도움이 되어야 하는 자체 수비 팀 중 하나가 중간자 공격인 "MiTM을 실행하겠습니다"라는 것을 알아냈습니다.

요즘은 성별에 따른 언어를 피하고 항상 사람이 아니라는 사실을 반영하기 위해(가운데 컴퓨터가 있는 경우가 많습니다)…

... Naked Security에서 저는 이제 "Manipulator-in-the-Middle"을 씁니다.

그러나 이것은 말 그대로 중간에 있는 사람이었습니다.

간단히 말해서 Doug는 사기꾼의 이메일 주소와 유사한 일종의 타이포스쿼트 이메일 계정을 사용하여 집에서 고용주에게 이메일을 보내기 시작했습니다.

그는 고위 경영진의 이메일 계정에 액세스할 수 있었기 때문에 스레드를 하이재킹하고 과거 이메일 추적에서 비트코인 ​​주소를 변경했습니다.

...그리고 그는 기본적으로 중간자로서 협상을 시작했습니다.

이제 그가 사기꾼과 개별적으로 협상하고 그 협상을 고용주에게 전달한다고 상상해보십시오.

우리는 그가 모든 현상금을 가지고 달아나길 바랐는지 그리고 고용주에게 "이봐, 도둑들이 우리를 속였어"라고 말했는지, 아니면 그가 자신의 편에서 사기꾼들과 협상하기를 원했는지 알 수 없습니다. 그의 고용주는 반대편에 있습니다.

그는 회사 내부의 공포와 공포를 증가시키기 위해 말할 옳고 그름을 모두 알고 있었기 때문입니다.

그래서 그의 목표는 기본적으로 랜섬웨어 지불을 하이재킹하는 것이었습니다.

음, Doug, 불행하게도 그와 그의 고용주와 법 집행 기관을 위해 회사가 돈을 지불하지 않기로 결정했기 때문에 모든 것이 약간 배 모양으로 진행되었습니다.

더그.  [웃음] 흠!

오리.  따라서 그가 훔친 다음 잘라낼 비트코인이 없었습니다.

또한 자신의 흔적을 잘 숨기지 않아 이메일 로그에 대한 불법 접근이 적발된 것으로 보인다.

그는 집에 있는 자신의 컴퓨터와 전화에서 악성 데이터를 지우려고 했기 때문에 경찰이 자신에게 접근하고 있다는 것을 분명히 알고 있었습니다.

그러나 그들은 압수되었고 데이터는 복구되었습니다.

어찌된 일인지 사건은 XNUMX년 동안 계속되었고, 마침내 그가 재판을 받으러 가려고 할 때, 그는 분명히 자신이 설 수 있는 다리가 없다고 결정하고 유죄를 인정했습니다.

자, 여기 있습니다, 더그.

말 그대로 중간자 공격!

더그.  좋아요, 2023년에는 모든 것이 잘되고 좋습니다…

...하지만 우리를 데려가 1580 년대로 돌아 가기, 폴.

스코틀랜드 여왕 메리와 엘리자베스 XNUMX세 여왕은 어떻습니까?

오리.  음, 솔직히 말해서, 나는 그것이 그 모든 세월을 거슬러 올라가서 중간자 공격을 설명하는 좋은 방법이라고 생각했습니다.

유명하게도 엘리자베스 여왕과 그녀의 사촌 메리, 스코틀랜드의 여왕은 종교적, 정치적 적이기 때문입니다.

엘리자베스는 영국의 여왕이었습니다. 마리아는 왕위를 노리고 있었습니다.

그래서 Mary는 사실상 가택 연금 상태로 구금되었습니다.

Mary는 어느 정도 호화롭게 살고 있었지만 성에 갇혀 있었고 실제로 그녀의 사촌에 대한 음모를 꾸미고 있었지만 그들은 그것을 증명할 수 없었습니다.

그리고 Mary는 성으로 배달되는 맥주통 마개에 메시지를 채우고 메시지를 주고받고 있었습니다.

분명히 이 경우 중간자(man-in-the-middle)는 Mary가 메시지를 받기 전에 메시지를 제거하여 복사할 수 있는 준수 맥주 공급업체였습니다.

그리고 그는 Mary의 암호로 암호화된 대체 메시지를 미묘한 변경 사항과 함께 삽입했습니다. 느슨하게 말해서 결국 Mary는 그녀가 해야 할 것보다 더 많은 것을 작성하도록 설득했습니다.

그래서 그녀는 다른 공모자들의 이름을 공개했을 뿐만 아니라 엘리자베스 여왕을 암살하려는 음모를 승인했다고 밝혔습니다.

그때는 더 힘든 시기였습니다. 당시 영국은 확실히 사형을 선고받았고 Mary는 재판을 받고 처형되었습니다.

역사상 가장 크랙된 암호문 10개

더그.  좋습니다. 듣고 계시는 분들을 위해 이 팟캐스트의 엘리베이터 피치는 "사이버 보안 뉴스 및 조언, 약간의 역사 이야기"입니다.

오늘날의 중간자 이야기로 돌아갑니다.

우리는 -에 대해 이야기했다 또 다른 내부자 위협 얼마 전까지만 해도 이대로.

따라서 이것이 패턴인지 아니면 우연의 일치인지 확인하는 것이 흥미로울 것입니다.

그러나 이러한 유형의 공격으로부터 자신을 보호하기 위해 수행할 수 있는 몇 가지 작업에 대해 이야기했으므로 다시 빠르게 살펴보겠습니다.

로 시작: 분할 및 정복, 이는 기본적으로 "회사의 한 사람에게 모든 것에 대한 제한 없는 액세스 권한을 부여하지 마십시오"를 의미합니다. Paul.

오리.  예.

더그.  그리고 우리는: 변경 불가능한 로그 유지, 이 경우에 일어난 것처럼 보이죠?

오리.  예.

이 사건의 핵심 증거 요소는 그가 고위 간부들의 이메일을 파헤치고 변경했다는 사실이며, 그것을 숨길 수 없었다는 사실인 것 같습니다.

따라서 다른 증거가 없더라도 그가 특별히 랜섬웨어 협상 및 비트코인 ​​주소와 관련된 이메일을 만지작거리고 있었다는 사실은 매우 의심스러울 것입니다.

더그.  마지막으로: 항상 측정하고 가정하지 마십시오.

오리.  과연!

더그.  결국 좋은 사람들이 이겼습니다… XNUMX년이 걸렸지만 우리는 해냈습니다.

다음 이야기로 넘어 갑시다.

웹 보안 회사는 앱 구축 툴킷에서 로그인 버그를 발견합니다.

버그가 빠르고 투명하게 수정되서 좋긴 한데… 이야기에 더, 물론, 폴.

심각한 보안: 확인이 중요합니다. OAUTH 로그인 버그 검사

오리.  예.

이것은 SALT라는 웹 코딩 보안 분석 회사(나는 거기에서 올바른 용어를 골랐으면 좋겠다)이며, 그들은 Expo라는 앱 구축 툴킷에서 인증 취약점을 발견했습니다.

그리고 그들의 마음을 축복합니다. 엑스포는 OAUTH라는 것을 지원합니다. 공개 승인 시스템.

그것은 당신이 결정한 웹 사이트에 갈 때 사용되는 일종의 시스템입니다. 우리가 하려는 것은 'Google로 로그인, Facebook으로 로그인'이라고 말하는 것입니다.”

대략적으로 말하자면 Facebook, Google 또는 주류 서비스가 무엇이든 연락하고 "이봐, 내가 주고 싶어. example.com X를 할 수 있는 권한.”

그래서 페이스북, 구글 등 어떤 것이든 당신을 인증한 다음 이렇게 말합니다. 당신은 우리와 함께 인증했고 이것이 당신의 인증 토큰입니다.”

그런 다음 다른 쪽 끝은 독립적으로 Facebook, Google 또는 그 토큰이 귀하를 대신하여 발급되었는지 확인하기 위해 무엇이든 확인할 수 있습니다.

이것이 의미하는 바는 사이트에 암호를 넘길 필요가 없다는 것입니다. 원하는 경우 실제 인증 부분을 수행하도록 Facebook 또는 Google을 선택하는 것입니다.

귀하가 부티크 웹사이트이고 "내 자신의 암호화를 짜지 않을 것"이라고 생각한다면 좋은 생각입니다.

따라서 이것은 OAUTH의 버그가 아닙니다.

그것은 단지 감독일 뿐입니다. Expo의 OAUTH 프로세스 구현에서 잊혀진 것.

그리고 느슨하게 말하면 Doug, 이렇게 됩니다.

Expo 코드는 Facebook 인증에 필요한 모든 매개변수를 포함하는 거대한 URL을 생성한 다음 최종 매직 액세스 토큰을 보낼 위치를 결정합니다.

따라서 이론적으로 자신의 URL을 구성하거나 URL을 수정할 수 있다면 이 매직 인증 토큰이 최종적으로 전송되는 위치를 변경할 수 있습니다.

그러나 사용자를 속일 수는 없습니다. "앱이 다음 위치에 있습니다. URL-here 에서 Facebook 계정에 로그인하도록 요청하고 있습니다. 이것을 완전히 신뢰하고 그대로 두시겠습니까? 예 혹은 아니오?"

그러나 Facebook, Google 등에서 인증 코드를 수신하고 이 "반환 URL"에 전달하는 시점에 이르면 Expo 코드는 사용자가 실제로 클릭했는지 확인하지 않습니다. Yes 승인 대화 상자에서.

적극적으로 대화를 보고 클릭했다면 No, 그러면 공격이 발생하지 않도록 방지할 수 있습니다.

그러나 본질적으로 이것은 "오픈 실패"입니다.

대화 상자를 본 적이 없다면 클릭할 것이 있다는 사실조차 알지 못하고 아무 조치도 취하지 않은 다음 공격자가 더 많은 JavaScript를 사용하여 스스로 다음 URL 방문을 트리거한 경우…

… 그러면 시스템이 작동합니다.

그리고 이것이 작동한 이유는 초비밀 인증 코드가 전송되는 마법의 "반환 URL"이 Expo가 나중에 *클릭하기 전에 사용할 수 있도록 웹 쿠키에 설정되었기 때문입니다. Yes 대화 상자*에서.

나중에 "반환 URL" 쿠키의 존재는 사용자가 원하는 경우 기본적으로 사용자가 대화 상자를 보았고 계속 진행하기로 결정했음에 대한 증거로 사용되었습니다.

그러나 실제로는 그렇지 않았습니다.

그래서 컵과 립 사이에서 엄청난 미끄러짐이었습니다, Douglas.

더그.  알겠습니다. 다음으로 시작하는 몇 가지 팁이 있습니다. 이 버그를 보고하고 공개하는 것은 교과서적인 사례였습니다.

이것이 거의 정확히 당신이 해야 할 일입니다, 폴.

모든 것이 제대로 작동했기 때문에 이것이 가능한 최선의 방법으로 이를 수행하는 방법에 대한 훌륭한 예입니다.

오리.  그리고 그것이 내가 Naked Security에 글을 쓰고 싶었던 주된 이유 중 하나입니다.

SALT, 버그를 발견한 사람들…

.. 그들은 그것을 찾았습니다. 그들은 그것을 책임감 있게 공개했습니다. 그들은 말 그대로 몇 시간 안에 그것을 고친 Expo와 함께 일했습니다.

그래서 그것이 버그였음에도 불구하고 코딩 실수였음에도 불구하고 SALT는 이렇게 말했습니다.

그런 다음 SALT는 CVE를 받고 "이봐, 이제 버그가 수정되었으니 이틀 후에 그것에 대해 큰 홍보를 할 수 있습니다."라고 말하는 대신 실제로 작성할 날짜를 XNUMX개월 앞당겼습니다 발견한 내용을 정리하고 매우 교육적인 보고서를 작성합니다.

즉각적인 홍보 목적으로 급하게 내보내는 대신, 마지막 순간에 스쿠핑된 경우 사기꾼이 발견하기 전에 고칠 수 있도록 책임감 있게 보고했을 뿐만 아니라(누군가 이 취약점을 남용했다는 증거가 없음) Expo가 고객과 소통할 수 있는 약간의 여유를 주었습니다.

더그.  그리고 물론 우리는 이것에 대해 조금 이야기했습니다. 인증 확인 페일클로즈 확인.

누군가 무시하거나 취소해도 계속 작동하지 않도록 하십시오.

하지만 여기서 더 큰 문제는 다음과 같습니다. 자신의 클라이언트 측 코드가 확인 프로세스를 제어할 것이라고 가정하지 마십시오.

오리.  이 OAUTH 프로세스를 안내하기 위해 Expo에서 제공하는 JavaScript 코드의 정확한 프로세스를 따랐다면 문제가 없었을 것입니다.

그러나 그들의 코드를 피하고 실제로 팝업을 우회하거나 취소하는 것을 포함하여 자신의 JavaScript로 링크를 트리거했다면 당신이 이겼습니다.

클라이언트 코드를 우회하는 것은 공격자가 가장 먼저 생각하는 것입니다.

더그.  좋습니다. 마지막으로 중요한 사항입니다. 웹 계정을 적극적으로 사용하지 않을 때는 로그아웃하십시오.

그것은 모든면에서 좋은 조언입니다.

오리.  우리는 Naked Security 팟캐스트에서 항상 말하며, 수년.

온라인 안전을 위한 간단한 3단계

사람들에게 “이봐, 종료할 때 모든 쿠키를 지우도록 브라우저를 설정하는 게 어때?”라고 말하는 것과 같은 방식으로 다소 불편하기 때문에 인기 없는 조언입니다.

당신이 그것에 대해 생각한다면, 이 특별한 경우에… 로그인이 당신의 Facebook 계정을 통해 발생했다고 가정해 봅시다. 페이스북을 통한 OAUTH.

Facebook에서 로그아웃한 경우 공격자가 어떤 JavaScript 배반을 시도하더라도(Expo 팝업 및 그 모든 것 종료) Facebook의 인증 프로세스는 성공하지 못할 것입니다. 인증을 요청합니다. 현재 로그인되어 있지 않습니다.”

따라서 해당 지점에서 항상 피할 수 없이 Facebook 로그인 팝업이 표시됩니다. "지금 로그인해야 합니다."

그리고 그것은 속임수를 즉시 멀리 줄 것입니다.

더그.  그래 아주 좋다.

오늘의 마지막 이야기: 당황하지 마세요. 오픈 소스 암호 관리자인 KeePass의 마스터 암호를 해독할 수 있는 방법이 있는 것 같습니다.

그러나 다시 말하지만 당황하지 마십시오. 훨씬 더 복잡 생각보다, 폴.

누군가의 기계를 실제로 제어해야 합니다.

심각한 보안: KePass의 "마스터 비밀번호 크랙"과 이를 통해 배울 수 있는 것

오리.  당신은 않습니다.

이를 추적하려면 CVE-2023-32784입니다.

그것은 매혹적인 버그이고 나는 일종의 매그넘 오푸스 이에 대한 Naked Security의 스타일 기사 제목: 그 KePass '마스터 비밀번호 크랙'과 그로부터 배울 수 있는 것.

따라서 C 유형 메모리 할당, 스크립팅 언어 유형 메모리 할당, 마지막으로 C# 또는 .NET 관리 문자열… 시스템에 의한 관리 메모리 할당에 대한 기사를 망치지 않겠습니다.

이 경우 연구원이 발견한 내용만 설명하겠습니다.

그들이 한 일은... 그들은 KeePass 코드와 KeePass 메모리 덤프를 조사하여 메모리에서 마스터 암호를 찾는 것이 일시적이지만 얼마나 쉬운지에 대한 증거를 찾았습니다.

몇 분, 몇 시간 또는 며칠 후에 도착하면 어떻게 됩니까?

컴퓨터를 재부팅한 후에도 마스터 암호가 디스크의 스왑 파일에 여전히 남아 있으면 어떻게 합니까?

그래서 KeePass를 설정하고 메모리에서 찾았을 때 쉽게 알아볼 수 있도록 모두 대문자인 16자리 암호를 스스로에게 부여했습니다.

그리고 보라, 내 마스터 암호가 ASCII 문자열이 아닌 메모리에 있는 것을 발견한 적이 없습니다. Windows widechar(UTF-16)) 문자열이 아닙니다.

큰!

그러나이 연구원이 알아 차린 것은 KeePass에 암호를 입력하면 ... "유니 코드 얼룩 문자"라고 부르겠습니다. 예, 키를 눌렀다는 것을 보여주기 위해 입력한 문자 수.

따라서 암호를 입력하면 blob [●], blob-blob [●●], blob-blob-blob [●●●] 문자열이 표시되며 제 경우에는 최대 16개의 blob까지 모두 표시됩니다.

음, 이러한 blob 문자열은 보안 위험이 있는 것처럼 보이지 않으므로 "관리되는 문자열"로 관리하기 위해 .NET 런타임에 남겨진 것일 수 있습니다. 나중에 메모리에 있을 수 있습니다…

… "이봐, 그냥 얼룩일 뿐이야."

무려 250MB의 데이터를 제공하는 KeePass의 메모리 덤프를 수행하고 blob-blob, blob-blob-blob 등과 같은 문자열(얼마나 많은 blob)을 찾는다면 Blob 16개, Blob XNUMX개, Blob XNUMX개, Blob XNUMX개… 제 경우에는 최대 XNUMX개의 Blob이 표시되는 메모리 덤프 덩어리입니다.

그런 다음 원하는 경우 "실수로 발생하는 얼룩 문자"의 무작위 모음을 얻을 수 있습니다.

즉, 실제 암호를 제공하지 않더라도 해당 blob 문자열을 찾는 것만으로도 암호 길이가 유출됩니다.

그러나 이 연구원이 궁금해한 것은 "메모리에 있는 blob 문자열에 가까운 데이터가 암호에 입력하는 개별 문자와 어떤 식으로든 연결될 수 있다면 어떻게 될까요?"이기 때문에 훨씬 더 흥미로워집니다.

따라서 메모리 덤프 파일을 살펴보고 두 개의 blob, 세 개의 blob/네 개의 blob 등을 검색하는 대신…

...비밀번호에 있다고 생각되는 문자가 뒤따르는 얼룩 문자열을 검색합니까?

그래서 제 경우에는 A에서 Z까지의 문자만 검색했습니다. 비밀번호에 그것이 무엇인지 알고 있었기 때문입니다.

하나의 ASCII 문자가 뒤따르는 blob 문자열을 검색하고 있습니다.

무슨 일이 있었는지 맞춰보세요, 더그?

비밀번호의 세 번째 문자 다음에 두 개의 얼룩이 표시됩니다. 내 비밀번호의 네 번째 문자가 오는 세 개의 얼룩; 내 비밀번호의 15번째 문자가 바로 뒤에 오는 최대 16개의 얼룩입니다.

더그.  네, 이 기사에서는 야생 비주얼입니다!

나는 따라가고 있었다… 그것은 약간 기술적인 것이 되었고, 갑자기 나는 단지 “우와! 비밀번호 같아!”

오리.  기본적으로 비밀번호의 개별 문자가 메모리를 통해 자유로이 흩어져 있는 것처럼 보이지만 입력할 때 실제로 비밀번호의 일부였던 ASCII 문자를 나타내는 문자는…

...발광 다이가 부착된 것과 같습니다.

따라서 이러한 blob 문자열은 실수로 암호의 문자에 플래그를 지정하는 태깅 메커니즘으로 작동합니다.

그리고 실제로 이야기의 교훈은 당신이 전혀 예상하지 못한 방식으로 메모리에서 일이 누출될 수 있고 정보를 잘 아는 코드 검토자조차도 알아차리지 못할 수 있다는 것입니다.

따라서 흥미로운 읽기이며 보안 코드를 작성하는 것이 생각보다 훨씬 어려울 수 있음을 일깨워줍니다.

더 중요한 것은 안전한 코드를 검토하고 품질을 확인하고 테스트하는 것이 여전히 더 어려울 수 있다는 것입니다.

…왜냐하면 머리의 앞, 뒤, 옆에 눈이 있어야 하고 정말 공격자처럼 생각하고 가능한 모든 곳에서 새는 비밀을 찾으려고 노력해야 하기 때문입니다.

더그.  좋구나, 확인해, 그것은 madedsecurity.sophos.com에 있습니다.

그리고 우리 쇼에서 해가지기 시작하면 독자 중 한 사람의 말을들을 시간입니다.

이전 팟캐스트(폴)에서 Naked Security 청취자 Chang은 다음과 같이 언급했습니다.

거기. 난 끝냈어. 거의 XNUMX년 동안 폭음 청취 후 Naked Security 팟캐스트 에피소드를 모두 청취했습니다. 나는 모두 잡혔다.

오래 실행되는 Chet Chat으로 시작하여 처음부터 즐겼습니다. 그런 다음 영국 승무원에게; "안 돼! 김이야”가 다음이었다. 그런 다음 마침내 오늘의 "기술 역사의 이번 주"에 도달했습니다.

얼마나 타고!

고마워, 창!

나는 당신이 모든 에피소드를 폭식했다는 것을 믿을 수 없지만 우리는 모든 것을 합니다.

오리.  정말이지, 더그!

사람들이 듣고 있다는 것뿐만 아니라 팟캐스트가 유용하다는 것을 알게 되어 사이버 보안에 대해 더 많이 배우고 조금이라도 게임을 향상시키는 데 도움이 된다는 사실을 알게 되어 기쁩니다.

이전에 여러 번 말했듯이 우리 모두가 사이버 보안 게임을 조금이라도 강화한다면 한두 개의 회사, 한두 개의 조직, 한두 개의 조직, 한두 개의 조직, 두 사람은 엄청난 노력을 기울이지만 나머지는 뒤쳐져 있습니다.

더그.  정확하게!

글쎄요, 그걸 보내주셔서 다시 한 번 감사드립니다, 창 씨.

정말 감사합니다.

제출하고 싶은 흥미로운 이야기, 의견 또는 질문이 있는 경우 팟캐스트에서 읽을 수 있습니다.

Tips@sophos.com으로 이메일을 보내거나, 우리 기사 중 하나에 댓글을 달거나, @nakedsecurity 소셜에서 연락할 수 있습니다.

그것이 오늘의 쇼입니다. 들어주셔서 대단히 감사합니다.

Paul Ducklin의 경우, 저는 Doug Aamoth라고 합니다. 다음 시간까지...

양자 모두.  보안 유지!

[뮤지컬 모뎀]