그래서 당신은 얻을 수 있습니다 Slack 암호 재설정 프롬프트. Slack 사용자 기반의 절반 정도가 이상한 버그로 인해 암호 해시가 잠재적으로 노출되었을 수 있습니다. 공유 초대 링크를 보낼 때 암호 해시가 작업 영역의 다른 구성원에게 전송되었습니다. 비밀번호 해시가 이와 같은 사용자에게 전송되어서는 안 되므로 이 정확한 문제가 어떻게 발생했는지 알아내기가 약간 어렵습니다. 내 생각에 링크가 생성될 때 다른 사용자가 상태 업데이트 패킷을 받았고 코드의 논리 오류로 인해 너무 많은 상태 정보가 전송되었습니다.

증거에 따르면 버그를 가장 먼저 포착한 사람은 XNUMX월 중순에 문제를 공개한 연구원이었습니다. Slack은 정상적인 암호 정책을 사용하는 것으로 보이며 해시되고 솔트된 암호만 저장합니다. 아침식사 레시피처럼 들릴 수도 있지만, slack에 로그인하기 위해 비밀번호를 입력하면 비밀번호가 단방향 암호화 해시를 거치고 해시 결과가 저장된다는 의미입니다. 소금에 절이는 것은 추가 데이터를 추가하는 것입니다. 사전 계산 공격 비실용적. Slack은 이 버그가 이러한 해시를 캡처하는 데 사용되더라도 영향을 받는 사용자로 직접 인증하는 데 사용할 수 없다고 말했습니다. 유출된 정보의 오용을 방지하기 위해 2단계 인증을 켜는 것에 대한 일반적인 조언이 여전히 적용됩니다.

엣 투 트윌리오

능가하지 말고 Twilio는 진행 중인 문제를 방금 공개했습니다., 그러나 이것은 적극적인 사회 공학 공격이었습니다. Twilio 직원에 대한 표적 피싱 캠페인으로 시작되었으며 직원들이 가짜 로그인 페이지에 속아 넘어가자 공격자는 캡처한 자격 증명을 사용하여 내부 도구에 액세스하고 최종 사용자 데이터에 액세스했습니다. 특히 이러한 피싱 시도는 알려진 Twilio 직원을 대상으로 하고 정확한 전화 번호를 사용하고 이름이나 사용자 이름을 포함했기 때문에 성공적이었습니다. Cloudflare 및 Cicso와 같은 다른 회사도 유사한 공격을 경험하고 있는 것으로 보고되었습니다. 대상 낚시를 가능하게 한 공유 공급자에 위반이 있을 수 있습니다.

CPU 취약점 악몽 전선에서 더 많은 정보

그 책임을 주도하는 것은 인텔의 ÆPIC 누출, 새로운 종류의 프로세서 버그. 이것은 추측 실행 버그가 아닙니다. — 우리는 CPU가 롤백될 메모리에서 작동하도록 속이는 것이 아닙니다. 이것은 초기화되지 않은 메모리에서 읽고 다른 프로세스의 비밀을 찾는 것과 비슷합니다. 그것은 실제로 연구원들이 의도적으로 버퍼와 캐시를 알려진 패턴으로 채운 다음 무의미한 메모리 위치에서 해당 패턴을 찾으려고 시도했기 때문에 연구원들이 찾고 있던 정확한 종류의 버그입니다. 메모리 읽기가 카나리아 데이터를 반환했다면 흥미로운 일이 발생한 것입니다.

이것은 APIC(Advanced Programmable Interrupt Controller)에 할당된 I/O 주소에서 읽을 때 정확히 일어난 일입니다. APIC 범위 내의 특정 바이트는 예약되어 있으며 이를 읽으려고 하면 정의되지 않은 동작이 호출됩니다. 많은 CPU 모델에서 이는 시스템 중단 및/또는 전체 CPU 충돌을 의미합니다. 일부 프로세서에서는 읽기가 작동했지만 APIC가 실제로 이러한 주소로 데이터를 보내지 않기 때문에 오래된 캐시 콘텐츠가 반환됩니다. 이것은 매우 흥미로운 결과이지만 실제로 공격을 시작하려면 시스템에 대한 루트 수준 액세스가 필요합니다. 커널이 이미 임의의 메모리를 읽을 수 있기 때문에 기본적으로 의미가 없습니다. 그렇죠?

Kernel-sees-all의 규칙에는 중요한 예외가 있습니다. Intel의 SGX 엔클레이브 기술은 커널에서도 메모리 영역을 보호하도록 특별히 설계되었습니다. 실제로 이것은 DRM 키와 SGX 보호 가상 머신을 의미합니다. DRM 키 유출은 최종 사용자에게 *위협이 되지 않으므로 걱정할 필요가 없습니다. 그리고 SGX로 보호되는 VM을 실행하는 사람들의 수는 매우 적습니다.

스큅

AMD는 재미를 놓치지 않고 있습니다. 이번 주 SQUIP 공개 (백서). 스케줄러 대기열에서 프로세스 상태를 파생시키는 새로운 부채널입니다. SMT(Simultaneous MultiThreading)는 최신 프로세서에서 두 스레드의 명령어를 단일 처리 코어에 공급하는 데 사용하는 기술입니다. 다른 명령어는 CPU의 다른 구성 요소를 사용하기 때문에 SMT는 기존의 코어당 스레드 XNUMX개 배열보다 처리량이 더 높습니다. 한 가지 단점은 한 스레드의 활동이 다른 스레드의 성능에 영향을 미칠 수 있다는 것입니다. 예를 들어, 라이브 오디오 처리를 수행하는 경우 권장 사항 중 하나는 데이터 언더런을 방지하기 위해 SMT를 비활성화하는 것이었습니다. 보안을 생각한다면 한 프로세스가 CPU 코어에서 형제 스레드가 수행하는 작업에 대한 약간의 정보를 배울 수 있다는 명백한 부작용이 있습니다. 이 효과를 감지하고 활용하는 몇 가지 방법이 있으며 SQUIP이 제공하는 것은 형제 스레드를 감시하는 새로운 방법입니다.

AMD Zen 프로세서에는 CPU 코어당 여러 ALU(산술 논리 장치)가 있지만 이러한 장치 중 하나만 곱셈, 나눗셈 및 CRC(순환 중복 검사) 작업을 수행할 수 있습니다. SQUIP는 많은 곱셈 연산 요청을 연속적으로 큐에 넣은 다음 rdpru 명령어, 프로세서 레지스터 읽기. 특히 APERF(실제 성능 주파수 클록 카운터)의 값을 찾고 있습니다. 여기에 공격의 핵심인 기발한 행동이 있습니다. 각 ALU에 대한 별도의 대기열과 코어에 대한 마스터 대기열이 있습니다. 마스터 큐는 개별 하위 큐에 명령을 푸시하지만 다음 대상 큐가 가득 차면 마스터 큐는 다음 명령을 올바른 구성 요소로 보낼 수 있을 때까지 정지합니다. 실제로 ALU1 큐가 가득 차면 +1, rdpru 통화가 지연됩니다. 해당 명령이 기본 CPU 대기열의 끝에 도달하면 다른 ALU 중 하나에서 즉시 실행할 수 있습니다. 이것은 본질적으로, 예를 들어, 형제가 우연히 다른 VM에 있더라도, 특권이 없는 프로세스가 형제 프로세스에 의해 얼마나 많은 곱셈 명령이 수행되고 있는지 감시할 수 있도록 합니다.

따라서 곱셈 명령어를 결정할 수 있습니다. 정확히 무엇을 얻을 수 있습니까? 연구원들이 도달한 예는 RSA의 제곱 및 곱셈이었습니다. 여기서 비밀 키의 각 비트는 해당 비트의 값에 따라 50,000개 또는 XNUMX개의 곱셈을 트리거합니다. 많은 실행(XNUMX회 이상)에 SQUIP 기술을 사용하면 비밀 키의 값을 유추할 수 있습니다. 그것은 훌륭한 작업이지만 아마도 실제 사용에는 제한적일 것입니다. 최소한 AMD의 지침은 모범 사례 코딩 기술을 사용하여 이 문제를 완화하는 것이기 때문입니다.

Microsoft Office 및 기호

그것은 "지옥이 얼어 붙었습니까?"의 또 다른 것입니다. 순간, 마이크로소프트, 마이크로소프트 오피스용 디버깅 심볼 출시 발표. 당신이 묻는 디버깅 기호는 정확히 무엇입니까? 바이너리 파일에 대한 로드맵으로 생각할 수도 있습니다. 프로그램이 충돌할 때 디버깅 기호는 충돌이 발생했을 때 어떤 기능이 실행되고 있었는지 알려줍니다. 심지어 원인이 된 변수의 이름도 알려줍니다. 이제 이것이 전체 소스 릴리스만큼 많은 정보는 아니지만 실제로 주어진 프로그램 내에서 일어나는 일에 대해 많은 투명성을 제공합니다. Office의 Ghidra 디컴파일 결과를 상상해 보십시오. 그리고 그것이 일종의 요점입니다. Microsoft는 연구원들이 악용 가능한 버그를 찾아 보고하기를 원합니다. 또한 타사에서 Office용 플러그인 및 통합을 만들고 더 나은 디버깅을 통해 두 작업을 더 쉽게 수행할 수 있습니다.

VM웨어

Source Incite의 [스티븐 실리] XNUMX월에 VMWare 취약점 모음을 찾았습니다., 그리고 그것들이 합쳐지면 취약점 체인을 근절하기 위한 인상적인 RCE가 됩니다. 첫 번째는 아마도 기능일 것입니다. 관리자가 vRealize Manager 애플리케이션에서 대시보드 링크를 생성하면 해당 링크에 포함된 토큰을 통해 누구나 유효한 계정 없이 대시보드에 액세스할 수 있습니다. 본질적으로 읽기 전용 액세스이지만 새 사용자를 생성하기 위한 API 호출이 일반 인증 검사를 우회하는 두 번째 문제가 있습니다.

그 다음 문제는 로그에 기록되는 민감한 정보이며, 이 경우 시스템이 권한이 없는 사용자에게 로그 액세스를 허용하거나 사용자가 전혀 허용하지 않는다는 것입니다! 문제의 로그 행에는 기본 인증 문자열이 포함되어 있습니다. 기본 인증은 Base64 인코딩을 통해 실행되는 비밀번호와 ID입니다. 이 공격 체인에서 설명한 것처럼 실제로 사용하는 것은 좋지 않습니다. 그럼에도 불구하고 이렇게 하면 관리자 사용자에 대한 암호 재설정이 허용되어 공격자 관리자가 시스템에 액세스할 수 있습니다. 관리자는 SSH 포트를 활성화하고 로그인할 수 있습니다. 따라서 공격자는 관리자와 SSH를 가지고 있지만 여전히 루트가 아닙니다.

다음은 sudo 모든 사용자가 sudo로 특정 Python 스크립트를 실행할 수 있도록 하는 규칙 — 스크립트가 루트로 실행됨을 의미합니다. 그 스크립트는 바이너리를 찾기 위해 환경 변수를 찾고, 그 변수는 설정하기 쉽습니다. 루트로 실행되는 스크립트가 사용자가 작성한 스크립트를 실행하도록 변수를 설정하고 계정에 전체 sudo 권한을 부여하는 것과 같은 모든 작업을 수행할 수 있습니다. 전체 익스플로잇 체인은 대시 오버라이드, 그리고 플레이 중인 세 가지 취약점에 대한 패치를 사용할 수 있습니다. [Steven] 잘 찾았습니다.

SELinux를

RedHat 랜드에서 게임을 하고 있다면 SELinux에 익숙할 것입니다. 소프트웨어 작동을 위해 끄는 성가신 일뿐입니다. RHEL 및 해당 클론에서 작업하는 많은 시스템 관리자는 첫 번째 문제 해결 단계로 RHEL을 일시적으로 비활성화하는 데 사용됩니다. 음, [esp0x31] 당신이 그 습관을 재고하고 싶습니다, SELinux가 시스템 강화에 유용한 도구가 될 수 있습니다. 이 게시물은 주어진 프로그램에 대한 파일 컨텍스트를 설정한 다음 해당 컨텍스트가 있는 파일에만 액세스를 엄격하게 제한하는 방법을 설명합니다. 이 응용 프로그램이 UDP를 통해 통신할 수 있어야 합니까? 그렇지 않은 경우 UDP 소켓 생성을 방지하는 규칙을 추가하십시오. 킬러 팁은 newrole 명령을 사용하면 방금 정의한 SELinux 도메인으로 이동할 수 있습니다. 이는 허점을 찾는 새 규칙을 강타하는 데 적합합니다.

비트 및 바이트

Windows의 Point-to-Point 프로토콜에는 결함이 있습니다. CVE-2022-30133, 여기서 포트 1723으로 트래픽을 보내면 임의 코드가 실행될 수 있습니다. 이것에 대한 무서운 점은 잠재적으로 웜 가능하고 포트가 Windows의 초기 VPN 솔루션이었기 때문에 의도적으로 인터넷에 노출될 수 있다는 것입니다. 요익.

X-as-a-Service는 수익을 창출하는 가장 인기 있는 방법 중 하나이며 범죄 요소가 등장했습니다. 우리는 서비스로서의 랜섬웨어를 가지고 있었고 지금은 서비스로서의 명령 및 제어. 봇넷에 있는 많은 기계를 지시하는 것이 너무 많은 문제입니까? 저렴한 월 사용료로 이 사람들이 당신을 대신할 것이며, 매끄러운 대시보드와 모든 것이 함께 제공됩니다. 우리는 진정으로 현대에 살고 있습니다.

Rsync에는 결함이 있습니다. 악성 서버가 연결 클라이언트에 임의의 파일을 쓸 수 있는 곳. 이것은 메시지 가로채기(man-in-the-middle) 공격의 형태로 활용될 수도 있습니다. 찾다 향후 3.2.5 릴리스, 수정 사항이 포함됩니다.

5.4만 개의 트위터 계정이 개인 데이터를 스크랩하여 판매했습니다. Twitter 웹 코드의 제로데이 덕분에. 민감한 비트는 계정을 확인하는 데 사용된 이메일 또는 전화번호였습니다. 우리 대부분에게는 그것이 탈출하는 것이 성가신 일입니다. 또 다른 스팸 발송자의 목록을 만들 수 있습니다. 정당한 이유로 익명으로 운영되는 소수의 Twitter 계정이 있으며, 악의적인 행위자가 점을 연결할 수 있다면 이러한 종류의 유출은 상당한 문제가 될 수 있습니다. 이것을 지적해 주신 [app-le-bees]에게 감사드립니다. 우리의 디스코드에서!