▲

GN⁺: 오픈 소스 프로젝트 대상 사회공학 기법을 통한 탈취에 대한 경보

 (openssf.org)
3P by neo 7달전 | favorite | 댓글 1개

OpenJS와 OpenSSF, 오픈소스 프로젝트의 Social Engineering 공격 위험에 대한 경보를 발령

  • 최근 XZ Utils 백도어 시도(CVE-2024-3094)는 독립된 사건이 아닐 수 있음
  • OpenJS Foundation이 유사한 신뢰할 수 있는 인수 시도를 차단한 것으로 보아, 이는 단편적 사건이 아닐 수 있음
  • OpenSSF와 OpenJS Foundation은 모든 오픈 소스 관리자에게 사회 공학적 인수 시도에 대해 경계하고, 초기 위협 패턴을 인식하며, 오픈 소스 프로젝트를 보호하기 위한 조치를 취할 것을 촉구함

실패한 인수 시도

  • OpenJS Foundation Cross Project Council은 유사한 메시지를 담은 의심스러운 이메일 시리즈를 받았음
  • 이메일 작성자는 "중요한 취약점을 해결하기 위해" 인기 있는 JavaScript 프로젝트 중 하나를 업데이트하기 위해 OpenJS에 조치를 취하라고 촉구했지만, 구체적인 사항은 언급하지 않았음
  • 이메일 작성자는 이전에 거의 코드에 관여하지 않았음에도 불구하고 프로젝트의 새로운 관리자로 지정해 줄 것을 원했음
  • 이 접근 방식은 "Jia Tan"이 XZ/liblzma 백도어에서 자신을 포지셔닝한 방식과 매우 유사함
  • OpenJS 호스팅 프로젝트에 이 사람들에게 액세스 권한을 부여되지 않았음
  • 프로젝트에는 재단 보안 실무 그룹에서 개략적으로 설명한 것을 포함하여 보안 정책이 마련되어 있음
  • OpenJS 팀은 재단에서 호스팅하지 않는 다른 두 개의 인기 있는 JavaScript 프로젝트에서도 유사한 의심스러운 패턴을 인식하고 잠재적인 보안 문제를 각각의 OpenJS 리더와 미국 국토안보부(DHS) 내 사이버 보안 및 인프라 보안 기관(CISA)에 즉시 알렸음

사회공학적 탈취(Takeover)의 의심스러운 패턴

  • 패턴들
    • 상대적으로 알려지지 않은 커뮤니티 구성원이 관리자 또는 호스팅 기관(재단 또는 회사)을 우호적이지만 공격적이고 끈질기게 요청함
    • 새로운 사람이나 알려지지 않은 사람이 관리자 지위로 승격해 줄 것을 요청함
    • 가짜 신원을 사용할 수도 있는 알려지지 않은 다른 커뮤니티 구성원의 지지를 받음 (일명 "sock puppets")
    • 아티팩트로 Blob을 포함하는 PR
    • 고의로 난독화되거나 이해하기 어려운 소스 코드
    • 점진적으로 심각해지는 보안 문제
    • 일반적인 프로젝트 컴파일, 빌드 및 배포 관행에서 벗어나 Blob, Zip 또는 기타 바이너리 아티팩트에 외부 악성 페이로드를 삽입할 수 있음
    • 특히 관리자가 긴박감으로 인해 검토의 철저함을 줄이거나 제어를 우회하도록 강요하는 경우 더욱 그러함
  • 이러한 소셜 엔지니어링 공격은 프로젝트와 커뮤니티에 대한 관리자의 사명감을 악용하여 이들을 조종함
  • 상호작용이 어떤 느낌을 주는지 주의할 것.
    • 자기 의심, 부적절함, 프로젝트에 충분한 기여를 하지 못한다는 느낌 등을 유발하는 상호작용은 사회 공학 공격의 일부일 수 있음
  • XZ/liblzma에서 목격한 것과 같은 소셜 엔지니어링 공격은 OpenJS 커뮤니티에 의해 성공적으로 예방 되었음
  • 이러한 유형의 공격은 소셜 엔지니어링을 통한 신뢰 위반을 이용하기 때문에 프로그램적으로 탐지하거나 방어하기 어려움
  • 단기적으로는 위에서 언급한 것과 같은 의심스러운 활동을 명확하고 투명하게 공유하면 다른 커뮤니티가 경계를 유지하는 데 도움이 될 것
  • 유지 관리자를 잘 지원하는 것이 이러한 소셜 엔지니어링 공격에 대한 주요 억제책

오픈소스 프로젝트 보안을 위한 단계

  • OpenSSF 가이드와 같은 업계 표준 보안 모범 사례를 따르는 것을 고려할 것
  • 강력한 인증 사용 : 2FA, 암호 관리자, 리커버리 코드를 안전한 곳에 저장, 암호/크레덴셜을 서로 다른 서비스에서 재사용하지 말 것
  • "Coordinated disclosure" 프로세스를 포함한 보안 정책 마련
  • 새 코드를 병합할 때 베스트 프랙티스 적용
    • 브랜치 보호 및 서명된 커밋을 활성화
    • 가능하면 PR이 관리자로부터 온 것이라도 병합하기 전에 두 번째 개발자가 코드 검토를 수행하도록 할 것
    • 가독성 요구 사항을 적용하여 새 PR이 난독화되지 않도록 하고 불투명한 바이너리 사용을 최소화
    • npm 게시 권한을 가진 사람을 제한
    • 커미터와 관리자를 파악하고 주기적으로 검토. 예를 들어 워킹그룹 회의에서 이들을 보았거나 이벤트 등에서 만난 적이 있나?
  • 오픈 소스 패키지 리포지토리를 운영중인 경우 Package Repository Security를 위한 원칙 채택을 고려할 것
  • CISA의 "사회 공학 및 피싱 공격 방지" 및/또는 ENISA의 "사회 공학이란 무엇인가"를 검토할 것

주요 오픈소스 인프라 보안을 위한 산업계와 정부의 조치

  • 안정적이고 안전한 오픈 소스 프로젝트를 유지하기 위한 압박은 관리자에게 압박을 줌
  • 민간/공공 국제 협력을 통해 대규모 자원이 필요함
  • Open Source Foundations, Sovereign Tech Fund 등 이미 많은 기관에서 훌륭한 작업이 진행 중임
  • 오픈소스 프로젝트에 안전망을 제공하기 위해 리눅스 재단 패밀리 재단과 유사한 조직들의 노력 필요
  • 독일 정부의 Sovereign Tech Fund 이니셔티브를 통해 중요한 오픈 소스 인프라에 투자하고 있는 것은 고무적임
  • 글로벌 공공 투자 확대를 위해 독일의 Sovereign Tech Fund와 같은 이니셔티브에 대해 더 많은 글로벌 공공 투자를 지지하고 있음

GN⁺의 의견

  • 공격자들은 관리자의 의무감을 교묘히 이용해 개발자들을 교란시키고 있음. 따라서 프로젝트에 대해 관리자들이 느끼는 감정 변화에도 주의를 기울여야 할 것 같음.
  • 보안을 위해 투자를 늘려야 한다는 것에 동의하나, 결국 근본적으로는 개발 문화 자체가 보안을 우선하는 방향으로 바뀌어야 할 것 같음. 개발 과정 전반에 보안이 자연스럽게 스며들도록 해야 함.
  • 공격자들이 커뮤니티의 신뢰를 이용하는 만큼 오픈소스 프로젝트에서는 지속적으로 구성원들간 신뢰를 쌓고 강화하는 노력도 병행되어야 할 것 같음. 서로 얼굴을 마주보며 소통하는 것이 그 시작이 될 수 있겠음.
  • Alpha-Omega 프로젝트 처럼 실제 취약점 개선에 투자하는 프로젝트가 더 많이 만들어지고 지원받아야 할 것 같음. 그래야 실질적으로 오픈소스 프로젝트의 보안 수준이 높아질 수 있을 것임.
▲
neo 7달전  [-]
Hacker News 의견

요약:

  • 오픈소스 프로젝트 관리자로서, 새로운 기여자의 PR에 대해 더 의심하게 됨
    • 표면적으로는 양호해 보이지만, 은밀한 의도가 있을 수 있음을 염두에 둠
  • 오랜 기간 동안 기능이 추가되면서 소프트웨어가 매우 복잡해짐
    • 소수의 사람만이 이해할 수 있을 정도로 코드가 인식하기 어려워짐
    • 경험 많은 개발자들이 은퇴하면 많은 부분을 이해하지 못하게 될 것임
  • 대형 프로젝트의 관리자 변경사항에 대한 보고 시스템이 필요함
    • 버전/릴리스와 함께 npm.js나 Debian 패키지 등에 동기화되어야 함
    • 유럽 은행의 사례처럼, 여러 국가의 기관이 감시할 수 있어야 함
  • Eve Online 게임에서처럼, 가치 있는 기여자가 되어 신뢰를 얻은 후 배신하는 과정을 경계해야 함
  • 2FA/MFA는 자체 호스팅된 시스템에서만 사용해야 함
    • 서드파티 시스템에서는 2차 인증 수단을 잃으면 영구적으로 잠길 수 있음
    • 프로젝트를 직접 호스팅해야 통제력을 잃지 않음
  • 포용성과 장기적 보안 사이의 난처한 논의가 오픈소스에서 일어날 것임
    • 이란, 러시아, 중국 등 일부 국가 출신 개발자들은 이미 의심을 받고 있음
    • 포크하여 동맹국과 함께 기여하는 것이 더 나은 선택일 수 있음
    • 적대국은 라이선스나 저작권 문제에 구애받지 않고 원본의 변경사항을 병합할 수 있음
  • 각 프로젝트는 자체적인 기준을 세워야 하며, 유지보수되지 않는 종속성은 신속히 제거해야 함
    • 프로젝트의 민감도를 평가하는 것도 고려해볼 만함
  • XZ 공격 이후, 이런 공격이 얼마나 흔할지 생각해 봄
    • 오픈소스가 폐쇄형 소프트웨어에 비해 더 취약할 수 있음
    • 누구나 코드를 작성할 수 있고 악의적인 동기가 있기 때문
  • 기존 오픈소스 프로젝트의 행동을 소급해서 살펴보는 것은 어려울 것으로 보임
  • 단순한 아키텍처와 코딩 표준 개선에 집중해야 한다고 오랫동안 주장해 왔음
    • 하지만 사람들은 TypeScript, React 등을 사용하면서 불필요한 종속성을 늘리고 있음
    • 적들은 우리의 무지와 순진함을 비웃고 있음
    • 전체 산업, 심지어 정치 시스템까지 타협되었을 수 있음
  • 사람들은 최소한의 코드와 종속성을 가진 프로젝트를 찾았어야 함
    • 깨끗한 프로젝트는 관심과 기회를 박탈당하고, 과도하게 설계된 프로젝트가 전면에 나섬
    • 이제 그들은 악의적 행위자들의 쉬운 표적이 되었음
    • 복잡성 속에 취약점을 숨기는 것은 너무나 쉬운 일임
답변달기