패스트 패션의 가격
럭키 열세! 가격 빠른 패션. 파이어폭스 고정 된. 기능 크리프 축소 실패 패치 화요일에.
아래에 오디오 플레이어가 없습니까? 듣다 직접 사운드클라우드에서.
폴 더클린, 체스터 위스니우스키와 함께. 인트로 및 아웃트로 음악 에디스 머지.
당신은 우리를들을 수 있습니다 사운드 클라우드, Apple Podcasts, Google 포드 캐스트, 스포티 파이, 스티 그리고 좋은 팟캐스트가 있는 곳이면 어디든지. 아니면 그냥 버리세요 RSS 피드의 URL 좋아하는 팟캐쳐에.
대본 읽기
[뮤지컬 모뎀]
오리. 모두들 안녕.
Sophos Naked Security 팟캐스트에 오신 것을 환영합니다.
보시다시피 저는 Duck입니다. 나는 Doug가 아닙니다(Doug는 휴가 중입니다).
그래서 저는 제 친구이자 동료인 Chester Wisniewski와 다시 한 번 합류했습니다.
돌아온 걸 환영해, 체스터.
당신이 있어서 정말 좋아요!
쳇. 고마워, 덕.
그냥 생각하고 있었는데… 사실, 당신이 팟캐스트를 소개할 때 제 화면을 보고 있었는데, 오늘이 제가 ChetChat 팟캐스트를 시작한 지 13주년이 되는 날이라는 것을 깨달았습니다. 그것이 은퇴하고 결국 이 팟캐스트가 되기 전이었습니다.
그래서 당신과 나는 13년 동안 이 일을 해왔습니다!
오리. 럭키 13, 응?
쳇. 네!
오리. 글쎄, 당신이 재미있을 때 얼마나 시간이 가는지.
쳇. 네, 재미있습니다.
Andy Greenberg의 자리에 앉게 된 것을 정말 영광으로 생각합니다.
내가 마지막으로 팟캐스트에 출연한 이후로 당신은 정말로 게임을 강화했습니다[LAUGHS].
오리. [LAUGHS] 그는 대화하기에 매우 재미있는 녀석이었습니다.
우리가 그와 함께 팟캐스트에 소개한 책을 읽어보셨는지 모르겠습니다. 어둠 속의 추적자?
쳇. 확실히 맞아요.
오리. 그것은 단지 매혹적인 이야기일 뿐이며, 아주 잘 말해지고 있습니다.
쳇. 네, 제 말은 확실히 제가 읽은 이 주제에 관한 최고의 책이었습니다...
…아마 Countdown to Zero Day 이후로, 그리고 그것은 제게 상당히 높은 평가를 받은 것입니다.
오리. Chester, 오늘의 첫 번째 주제부터 시작하겠습니다. Naked Security의 기사 제목을 읽어 보겠습니다. SHEIN 쇼핑 앱이 악용되어 클립보드에서 가격 및 URL 데이터를 가져옵니다.
명백히 악의적이지 않은 앱이라도 그 당시에는 좋은 아이디어였던 데이터를 수집하는 위험한 일을 할 수 있다는 사실을 상기시켜줍니다.
…하지만 그들은 유쾌하지 않아야 합니다.
쳇. 예 – 내 클립보드에 닿는 모든 것이 즉시 내 머릿속에서 그들이 하고 있다고 상상하는 끔찍한 일에 대한 모든 종류의 경보를 울립니다.
그리고 그것은 일종의 질문을 하게 합니다. 제가 개발자라면, 제가 순진한 일을 하고 있었다고 해도… 잠시 후에 그것에 대해 알게 될 것 같습니다.
그들이 하려고 했던 것이 얼마나 순진했는지 말하기는 어렵습니다.
오리. 그렇지.
쳇. 그런 허락을 구하면 머릿속에서 온갖 경종이 울린다.
마치 안드로이드 폰에서 오랫동안 블루투스를 사용하여 IoT 기기를 찾기 위해 필요한 권한은 블루투스가 필요한 "가까운 기기 접근"이었습니다.
그리고 화면에 "이것은 당신의 위치를 알고 싶어합니다."라는 털이 많은 경고를 보게 됩니다.
"이 스마트 전구가 내 위치를 알아야 하는 이유는 무엇입니까?"
내 클립보드에 액세스한다고 하면 "이 앱이 내 비밀번호를 도용하려는 이유는 무엇입니까?"라는 생각이 듭니다.
아마도 그것은 우리가 사람들을 위해 명확히 해야 할 것입니다…
..."클립보드의 내용을 앱에 넣으세요"라고 말할 때 *당신이* 그렇게 하는 경우가 있다고 생각하기 때문입니다(비밀번호를 복사하거나 메시지의 SMS XNUMX단계 코드를 복사하도록 선택할 수 있음). 앱을 선택한 다음 인증하려는 앱에 붙여넣기)…
오리. 예.
쳇. 그것은 우리가 이 권한에 대해 이야기할 때 말하는 것이 *아닙니다*, 그렇죠?
이 권한은 앱 자체가 선택할 때마다 기존 클립보드 콘텐츠를 엿보는 것입니다...
...앱과 적극적으로 상호 작용하고 길게 탭하고 "붙여넣기"라고 말할 때는 아닙니다.
오리. 그렇지.
기본적으로 의도하지 않았을 때 붙여넣기를 하는 것입니다.
클립보드에 복사하기로 선택한 데이터가 아무리 순진하더라도 임의의 앱이 “이봐, 기분이 좋아서 그냥 붙여넣을 거야. ”
그리고 본사에 있는 RESTful 마케팅 API로 보낸 웹 요청에 기본적으로 붙여넣었다는 사실이 특히 곤혹스럽습니다!
쳇. 예상되는 행동도 아니죠, 덕?
내 말은, 내가 뱅킹 앱에 있고 문자 메시지에서 코드를 요구한다면…
… 흐름을 단순하게 만들기 위해 텍스트 메시지 앱에 클립보드에 복사하여 자동으로 붙여넣도록 요청하는 방법을 볼 수 있습니다.
하지만 내 클립보드의 어떤 것도 패션 앱으로 끝나리라고는 결코 기대하지 않습니다!
필요하지 않으면 앱을 사용하지 마십시오.
즉, 여기서 큰 문제라고 생각합니다.
나는 지금 어떤 종류의 쇼핑 사이트에 갈 때마다 휴대 전화의 Firefox에서 "앱을 설치하시겠습니까? 앱을 통해 사이트에 액세스할 수 없는 이유는 무엇입니까? 앱을 사용하는 것이 좋을까요?”
대답은 NO, NO, NO입니다. 이는 신뢰할 수 없는 코드가 있을 때 발생하는 일이기 때문입니다.
Google에서 괜찮다고 해서 코드를 믿을 수 없습니다.
우리는 Google이 실제 사람을 검사하는 앱이 없다는 것을 알고 있습니다. Google은 Google Chat-GPT 괴물 같은 것에 의해 운영되고 있습니다.
따라서 Google이 검색하기에 적합한 방식으로 검색된 다음 Play 스토어에 저장됩니다.
그래서 저는 그 코드가 마음에 들지 않습니다.
내 말은, 내 기기에 로드해야 하는 앱이 있거나 게시자를 기준으로 더 신뢰가 가는 것…
...하지만 일반적으로 웹사이트로 이동하세요!
오리. Naked Security 팟캐스트를 듣는 사람은 브라우저 제로 데이와 같은 것에 대해 이야기할 때부터 브라우저 제조업체가 코드에서 버그를 찾고 제거하는 데 얼마나 많은 노력을 기울였는지 알고 있습니다.
쳇. 그리고 요즘에는 거의 모든 웹사이트가 앱처럼 작동하도록 만들 수 있다는 사실도 기억할 수 있습니다.
프로그레시브 웹 앱(Progressive Web App, PWA)이라는 것이 있습니다.
오리. 체스터, 지난 주의 다음 이야기로 넘어가자. 흥미로웠던 이야기.
나는 숫자가 마음에 들었고 몇 가지 흥미로운 문제가 있었기 때문에 이것을 썼습니다. Firefox 버전 111은 11개의 CVE 구멍을 수정했지만 제로데이는 1개도 없었습니다.
(그리고 그것은 숫자 1이 XNUMX번 반복되는 헤드라인에 대한 나의 변명입니다.) [LAUGHS]
쳇. [LAUGHS] 저는 Firefox의 팬이며 적극적으로 악용되고 있는 것으로 발견된 것이 없다는 것을 알게 되어 기쁩니다.
하지만 이것에 대한 가장 좋은 부분은 예방적으로 발견된 메모리 안전 문제를 포함한다는 것입니다. 그렇죠?
그들은 무언가를 발견하고 그것을 그들에게 보고한 외부인이나 당사자에게 그것을 인정하지 않습니다.
그들은 단지 적극적으로 사냥하고 있으며 메모리 안전 문제에 대해 작업하고 있음을 알려주고 있습니다…
...정말 좋은 것 같아요.
오리. Mozilla에서 제가 좋아하는 점은 XNUMX주마다 큰 업데이트를 할 때 모든 메모리 안전 버그를 작은 바구니 하나에 넣고 “그거 알아요? 우리는 실제로 이것이 악용 가능한지 여부를 알아내려고 시도하지 않았지만 여전히 CVE 번호를 부여할 것입니다…
…그리고 이것들이 실제로 악용될 수는 없지만, 누군가가 충분히 열심히 노력했거나, 의지가 있거나, 돈이 있거나, 그렇게 하기를 간절히 원했다면(그리고 그 모든 것에는 사람들이 있습니다) 가정할 가치가 있습니다. 범주), 당신은 그들이 당신에게 해를 끼치는 방식으로 이들 중 하나를 악용하는 방법을 찾을 것이라고 가정해야 합니다.”
그리고 Firefox나 Mozilla 안정에서 마음에 드는 것에 대한 약간의 이야기가 있습니다.
쳇. 당연히 – 나는 그것에 대해 생각하고있었습니다.
우리는 팟캐스트 전에 Firefox(또는 궁극적으로 Mozilla Foundation)가 만든 Servo라는 프로젝트에 대해 이야기했습니다.
그리고 당신이 말했듯이 이것은 브라우저 엔진 렌더링 엔진입니다(현재 Mozilla Firefox의 엔진은 Gecko라고 불립니다)... 아이디어는 전적으로 Rust로 렌더링 엔진을 작성하는 것이었고 실제로 이것은 Rust 프로그래밍 언어를 만드는 데 영감을 주었습니다.
여기서 중요한 점은 Rust가 메모리 안전 언어라는 것입니다.
이러한 CVE에서 수정되는 실수를 저지를 수 없습니다.
따라서 꿈의 세계에서는 메모리 안전 CVE 없이 이 Firefox 업데이트 블로그를 작성하게 될 것입니다.
그리고 Servo 개발을 계속하기 위해 Linux Foundation에 약간의 자금이 지원되는 것을 보고 매우 기뻤습니다.
어쩌면 미래에는 우리를 더욱 안전하게 만들어줄 새로운 Firefox 엔진이 될까요?
오리. 네!
분명히 합시다 – Rust로 코드를 작성한다고 해서 코드가 올바르게 되는 것은 아니며 취약성에 면역이 되지도 않습니다.
그러나 당신이 말했듯이, 특히 메모리 관리와 관련된 모든 종류의 문제가 있으며, 당신이 말한 것처럼 훨씬 더 하기가 어렵습니다.
그리고 잘 작성된 코드에서는 컴파일 시간에도 컴파일러가 "이것은 옳지 않다"는 것을 볼 수 있어야 합니다.
그리고 그것이 가비지 수집과 같은 작업을 수행하는 스크립팅 언어에 필요한 모든 오버헤드 없이 자동으로 수행될 수 있으므로 여전히 우수한 성능을 얻을 수 있다면 흥미로울 것입니다.
시간이 얼마나 걸릴지 궁금합니다.
쳇. 작게 한 입 베어물고 있는 것 같습니다.
첫 번째 목표는 CSS2 렌더링이 작동하도록 하는 것입니다. 마치 각 작업을 작은 작업 블록으로 간주하고 현대 렌더링 엔진인 거대한 괴물에서 분리하고... 약간의 물기를 섭취해야 하는 것과 같습니다.
그리고 그 프로젝트에 대한 자금 조달은 정말 중요합니다.
많은 것들이 브라우저 엔진을 내장하고 있습니다. 많은 제품이 Gecko 엔진, Google의 Blink 및 Apple의 Webkit을 기반으로 합니다.
그리고 더 많은 경쟁, 더 많은 성능, 더 많은 메모리 안전… 모두 좋습니다!
오리. 자, 이번 주의 마지막 주제로 넘어가겠습니다. 큰 이야기일 것 같은데요…
...그러나 좋은 점은 큰 이야기가 진행됨에 따라 몇 가지 흥미로운 버그가 있고 우리가 결국 이야기하게 될 두 버그가 모두 기술적으로 제로데이였지만 재앙적이지는 않다는 것입니다. .
그것들은 버그가 야기할 수 있는 문제의 종류에 대한 좋은 알림일 뿐입니다.
그리고 그 주제는 물론 화요일 패치입니다.
쳇. 글쎄, 나는 논쟁의 여지가 있고 그것에 대해 이야기 할 것입니다 웹의 마크 먼저 버그.
오리. [LAUGHS] 너무 귀에 쏙쏙 들어오는 이름이죠?
우리 모두는 좋은 옛날 Internet Explorer 시절처럼 "인터넷 영역"이라는 것을 알고 있습니다.
하지만 "Mark of the Web"... 훨씬 더 웅장하고, 더 흥미롭고, 더 중요하게 들립니다!
쳇. IE(Internet Explorer) 관리자의 경우 이것을 신뢰할 수 있는 영역에 있도록 설정할 수 있음을 기억할 것입니다. 인트라넷 영역에 있는 것; 다른 하나는 인터넷 영역에 있습니다.
그 설정이 우리가 말하는 것입니다.
그러나 이것은 Internet Explorer에 있을 뿐만 아니라 다른 많은 Microsoft 프로세스에서도 관찰되어 파일이 어디에서 왔는지에 대한 출처를 제공합니다…
...외부 파일이 내부 파일보다 훨씬 더 위험하다는 개념.
그래서 저는 이 전제에 동의하지 않습니다.
어리석은 일이라고 생각합니다!
모든 파일은 위험합니다!
당신이 그것들을 어디서 찾았는지는 중요하지 않습니다: 엄지 드라이브의 주차장에서; LAN에서; 또는 웹사이트에서.
그들 모두를 신뢰할 수 없는 것처럼 취급하고 끔찍한 일을 하지 않는 이유는 무엇입니까?
오리. 저는 Microsoft가 여기에서 어디에서 왔는지 알 수 있다고 생각하고 Apple도 비슷한 것을 가지고 있다는 것을 알고 있습니다. 파일을 다운로드하고 디렉토리 어딘가에 두었다가 XNUMX주 후에 다시 돌아옵니다.
그러나 나는 당신이 시작하기 시작할 때 "음, 그 파일은 방화벽 내부에서 왔기 때문에 신뢰할 수 있어야 합니다"라는 당신의 말에 동의할 것 같습니다...
...그것이 또 다시 좋은 옛날식 "부드러운 쫄깃한 인테리어"입니다!
쳇. 예.
그렇기 때문에 Mark of the Web을 우회할 수 있는 이러한 유형의 버그가 문제가 되는 것입니다.
많은 관리자는 "Microsoft Office는 Mark of the Web을 사용하여 파일에서 매크로를 실행할 수 없지만 Mark of the Web이 없으면 매크로를 실행할 수 있습니다. 재무 부서에서 Excel 스프레드시트 및 모든 관리자가 액세스해야 합니다.”
이런 종류의 상황은... 불행하게도 그 파일이 내부에 있는지 외부에 있는지 아는 것에 달려 있습니다.
그래서 제가 얻고자 하는 것, 제가 불평하고 있는 것은 다음과 같습니다. 이 취약점은 사람들이 외부에서 파일을 보낼 수 있게 해주며 파일이 외부에서 온 것처럼 표시되지 않도록 합니다.
그리고 이런 일이 일어날 수 있고 실제로 일어나기 때문에, 그리고 이런 일이 일어날 수 있는 다른 방법도 있기 때문에 Naked Security 기사에서 친절하게 지적해 주셨습니다.
...즉, 정책은 다음과 같아야 합니다. 매크로가 위험할 수 있다고 생각되면 매크로를 차단하거나 *어디에서 시작되든* 매크로를 활성화하도록 프롬프트를 표시해야 합니다.
내부와 외부를 구분하는 정책을 가져서는 안 됩니다. 우회될 위험이 있기 때문입니다.
오리. 전혀.
여기서 결론은 웹 "브랜딩"(파일의 인터넷 영역 레이블)의 이 마크를 우회하더라도... 그것이 사기꾼에게 분명히 유용한 것이지만, 일부 사람들이 의존한다는 것을 알고 있기 때문에 *그것은 어쨌든 계획을 세워야 하는 종류의 실패*.
저는 Mark of the Web에 대한 아이디어를 얻었고 그것이 나쁜 생각이라고 생각하지 않습니다.
나는 그것을 중요하거나 중요한 사이버 보안 변별자로 사용하지 않을 것입니다.
쳇. 음, 그리고 IT 관리자에게 상기시키기 위해…
...이 문제를 해결하는 가장 좋은 방법은 Mark of the Web을 보는 것이 아닙니다.
가장 좋은 방법은 내부 매크로에 서명하여 신뢰할 수 있는 매크로를 알고 나머지는 모두 차단하는 것입니다.
오리. 전혀.
당신이 절대적으로 필요하다고 알고 있고 신뢰할만한 충분한 이유가 있는 것을 그냥 허용하는 것이 어떻습니까?
… 그리고 당신이 말했듯이 다른 모든 것을 허용하지 않습니까?
하나의 대답은 "조금 더 어렵다"가 아닐까요?
그다지 편리하지 않습니다…
쳇. 글쎄, 이것은 범죄자가 허용할 수 있는 방식으로 Microsoft Outlook을 악용할 수 있는 다른 취약점으로 이어집니다.
...사칭 공격인가?
그게 당신이 말하는 방식인가요, Duck?
오리. 나는 이것을 일종의 Manipulator in the Middle(MitM) 공격이라고 생각합니다.
내가 일반적으로 사용하는 용어와 Microsoft에서 사용하는 용어… 릴레이 공격, 기본적으로 누군가를 속여 *당신*으로 인증하도록 하는 반면 *당신*은 그들을 대신하여 배후에서 실제 서버로 인증합니다.
이것이 속임수입니다. 기본적으로 누군가가 자신도 모르게 “이봐, 들어본 적도 없는 이 서버에 로그인해야 해. 정말 좋은 생각이야! 그들에게 내 암호의 해시를 보내겠습니다!”
무엇이 잘못 될 수 있습니까?
꽤 많이…
쳇. 제한적인 정책 대 허용적인 정책의 또 다른 좋은 예입니다. 그렇죠?
방화벽이 아웃바운드 SMB(서버 메시지 블록) 트래픽을 허용하도록 구성되지 않은 경우 이 취약점으로 인한 위험이 없습니다.
패치를 해서는 안 된다는 것이 아니라... 여전히 패치를 해야 합니다.
그러나 아이디어는 귀하의 정책이 "모든 것을 차단하고 발생해야 하는 일만 허용"하는 경우 허용하는 경우보다 이 경우 위험이 적다는 것입니다. 우리가 이미 나쁜 것으로 식별한 것을 제외한 모든 것을 허용합니다.”
제로데이가 발생했을 때 아무도 그것이 나쁘다고 식별하지 않았기 때문입니다.
그래서 제로데이!
오리. 그렇지.
어쨌든 사람들이 임의의 외부 서버에 로그인하기를 원하는 이유는 무엇입니까?
그들이 악의적이지 않더라도 회사 자격 증명을 사용하여 일종의 회사 스타일 인증을 통해 귀하에게 속하지 않은 일부 서버로 이동하기를 원하는 이유는 무엇입니까?
Chester, "부드럽고 쫄깃한 센터"에 대해 생각하고 있다면 이미 네트워크에 있고 약간의 발판이 있는 사기꾼이 네트워크 내부에서 이것을 사용할 수 있는 방법이 있다고 생각합니다. …
...불법 파일 서버를 설정하고 사용자를 속여 연결하도록 합니다.
쳇. [웃음] BYOD인가요?
나만의 Docker 컨테이너 가져오기?
오리. [LAUGHS] 음, 거기서 웃으면 안되는데 요즘 사기꾼들 사이에서 꽤 유행하는 거 맞지?
맬웨어가 탐지되는 것을 피하고 싶다면 소위 "토지에서 살기" 기술을 사용하고 이미 설치한 도구를 빌릴 것입니다...
… curl, bash, PowerShell 및 어쨌든 절대적으로 어디에나 있는 명령과 같습니다.
그렇지 않으면 가능하다면 VM[가상 머신]을 작동시킬 것입니다…
...어떻게든 VM 클러스터에 액세스할 수 있고 무고해 보이는 VM을 설정할 수 있는 경우 내부에서 맬웨어를 실행할 것입니다.
또는 그들의 도커 컨테이너는 당신이 가지고 있는 다른 것과 완전히 다르게 구성될 것입니다.
네, 맞습니다. 이것이 내부적으로 이것을 악용할 수 있는 방법입니다.
그러나 나는 그것이 흥미로운 버그라고 생각했습니다. 왜냐하면 사람들은 일반적으로 이메일 공격에 대해 생각할 때 보통 "이메일을 받았지만 해킹당하려면 첨부 파일을 열거나 링크를 클릭해야 합니다."라고 생각하기 때문입니다.
그러나 이것은 Outlook이 전자 메일을 준비하는 동안 사용자에게 전자 메일을 표시하기도 전에 트리거될 수 있다고 생각합니다!
꽤 불쾌하지 않습니까?
쳇. 예.
이메일 클라이언트에서 JavaScript 및 ActiveX 플러그인을 제거했을 때 이러한 종류의 버그가 사라진다고 생각했습니다.
오리. 나는 당신이 거기에서 잠시 "Flash"라고 말할 것이라고 생각했습니다, Chester. [웃음]
쳇. [웃음]
글쎄, 개발자에게는 이러한 종류의 버그가 기능 크립에서 비롯된다는 점을 기억하는 것이 중요합니다.
내 말은, 이메일이 더 안전한 이유는 우리가 실제로 기능을 제거했기 때문입니다.
오리. 옳은.
쳇. 우리는 ActiveX와 JavaScript, 그리고 이 모든 것들을 없앴습니다.
...그리고 이 너그는 이메일 발신자가 보낼 수 있는 변수인 "새 이메일을 받았습니다" 소리에 의해 트리거되었습니다.
나는 누가, 어느 행성에서 "좋은 기능인 것 같군."이라고 생각했는지 모르겠습니다.
오리. 이에 대해 제가 본 개념 증명은 (제 생각에는) 침투 테스트 회사에서 제작한 것입니다…
그래서 이것을 악용하는 사기꾼처럼 들리는데, 그것이 *그들이* 하는 방식입니다.
그러나 그것이 남용될 수 있는 유일한 기능이라는 것은 결코 분명하지 않습니다.
내 이해로는 "여기에 내가 사용하길 원하는 파일 이름이 있습니다"라고 말할 수 있다면 그 파일 이름은 분명히…
...음, 그냥 UNC 경로를 거기에 넣을 수 있습니다, 그렇죠?
\SOMEBODY.ELSES.SERVER.NAME… Outlook에서 액세스할 수 있습니다.
따라서 귀하의 말이 맞습니다. 실제로 기능 크립처럼 들립니다.
그리고 내가 말했듯이 이것이 적용될 수 있는 다른 누락된 기능이 얼마나 될 수 있는지, 그리고 그것들도 패치되었는지 궁금합니다.
Microsoft는 모든 세부 사항에 대해 약간 입을 다물었습니다. 아마도 이것이 야생에서 악용되었기 때문일 것입니다.
쳇. 나는 이 문제를 한 마디로 해결할 수 있다.
바보. [역사적인 텍스트 모드 전용 이메일 클라이언트.]
오리. 그래, 뮤트!
느릅나무, 소나무, mailx, 메일…
...넷캣, 체스터!
쳇. 당신은 고양이를 잊었다.
오리. 저는 Netcat을 생각하고 있었습니다. 실제로는 다른 쪽 끝에 있는 메일 서버와 대화식으로 대화하는 것입니다.
쳇. [LAUGHS] 키보드 앞에 있을 때만 이메일을 받을 수 있습니다.
오리. 패치하는 경우 파일에 액세스할 수 있는 Outlook의 모든 위치를 실제로 처리하고 해당 파일이 원격 서버에 있기를 바랍니다.
...그래서 Outlook은 "이봐, 내가 서버에 로그인해 보는 게 어때?"라고 말합니다.
자, Chester, 우리가 팟캐스트 전에 이 문제를 논의할 때 많은 ISP가 SMB 포트 445를 차단하기 때문에 이 버그가 야생에 나타났다는 사실에 놀랐다는 흥미로운 관찰을 하셨죠?
이 인증 버그 때문이 아니라 네트워크 웜이 확산되는 주요 방법 중 하나였기 때문입니다.
… 그리고 10년, 15년, 20년 전에는 모두가 너무 질려서 전 세계 ISP가 “아니요. 할 수 없습니다. 포트 445의 차단을 해제하려면 후프를 건너뛰거나 추가 비용을 지불해야 합니다.”
그리고 대부분의 사람들은 귀찮게하지 않았습니다.
따라서 설계가 아닌 우연에 의해 보호될 수 있습니다.
동의 하시겠습니까?
쳇. 예, 가능성이 있다고 생각합니다.
전 세계 대부분의 ISP가 이를 차단합니다.
내 말은, 몇 년 전 Windows XP에서 얼마나 많은 컴퓨터가 암호 없이 인터넷에 연결되어 C$ 공유가 노출되어 있었는지 상상할 수 있습니다.
우리는 여기서 악용에 대해 이야기하지도 않습니다.
우리는 ADMI|N$와 C$가 바람에 펄럭이는 사람들에 대해 이야기하고 있습니다!
오리. 그것이 당신을 보호하는 방법이라면(즉, 당신의 ISP가 작동하도록 허용하지 않기 때문에 작동하지 않는 경우)…
… 패치를 적용하지 않는 핑계로 사용하지 마십시오.
쳇. 네, 절대적으로.
시도가 성공하는 것은 고사하고 시도조차 발생하는 것을 원하지 않습니다.
우리 대부분은 여행을 하고 있죠?
저는 커피숍에서 노트북을 사용합니다. 그런 다음 식당에서 노트북을 사용합니다. 그런 다음 공항에서 노트북을 사용합니다.
그들이 무엇을 차단하고 있는지 누가 압니까?
포트 445가 차단된다고 믿을 수 없습니다…
오리. 체스터, 여기서 멈추는 게 좋을 것 같아.
그래서 짧은 시간에 마이크에 올라와 주셔서 대단히 감사합니다.
다음주에 또 나오나요?
당신은 그렇지 않습니까?
쳇. 특별한 상황이 없는 한 다음 주에 꼭 출연할 계획입니다.
오리. 우수!
남은 것은 우리가 관례대로 말하는 것뿐입니다.
쳇. 다음 시간까지 보안을 유지하세요.
[뮤지컬 모뎀]
- SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
- 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
- 출처: https://nakedsecurity.sophos.com/2023/03/16/s3-ep-126-the-price-of-fast-fashion-and-feature-creep-audio-text/
