2019 년 5 월 보안 사고에 대한 심층 분석 : 블로그 게시물 피드백

공격자의 의도에 대해 언급 할 수 있습니까?

특정 목표 / 특정 (사용자) 데이터를 추구 한 것으로 보입니까?

아니면 그들이 얼마나 멀리 갈 수 있는지 보며 막대기로 찌르는 "호기심 많은 십대"였을까요?

PS이 문제에 대해 개방 해 주셔서 감사합니다. 정말 감사합니다!

이 줄 :

Stack Exchange 네트워크에서 사물을 검색 (질문 방문)하는이 작업은 빈번하게 발생하며 앞으로 며칠 동안 공격자의 방법론 을 예측 하고 이해할 수있게 해줍니다 . (강조 광산)

이 같은 소리한다 실시간으로 공격이 일어나고, 당신은 대신에 그들은 과학적 증거들이 (공격 후) 볼 무엇을보고 무엇을했는지의 공격자들이 스택 오버플로에 방문한 내용을 기반으로 어떻게 할 것인지 정확히 파악할 수있다. 어떤 것을 의미 했습니까?

주로 공격자와 관련된 몇 가지 질문 :

1. 공격자는 어떻게 되었습니까?
2. 그들의 계정을 정지 했습니까?
3. SE가 언제라도 공격자에게 연락 했습니까?
4. 공격자의 신원을 공개하지 않는 이유는 무엇입니까?
5. 나중에 다른 사람이 동일한 공격 방법을 사용하려고 한 적이 있습니까?

이벤트의 다른 끝에 감지 가능한 수면주기가 있었습니까?

명확하게 편집 :

공격자를 알아 차리고 그들의 행동 중 일부를 펼친 후, 일상적으로나 회고 적으로 생물학적주기와 유사한 것을 발견 했습니까? 예 : 식사 (1-2 시간 휴식), 수면 (8 시간 비 활동 패턴), "파워 낮잠" (90 분) 등 ...?

이것은 실제로 사건의 일부는 아니지만 직원 계정에 대한 보안 조치에 대한보다 일반적인 관심사입니다. 이 사건에는 많은 단계가 있었지만 마지막 단계는 SE 계정의 권한을 높이는 것이 었습니다. 프로덕션 환경에서 SQL을 실행하기 위해 dev 인스턴스를 통해 CI 서버에 대한 관리자 액세스 권한을 얻는 것보다 훨씬 더 간단한 시도 방법을 상상할 수 있으며, SE가 더 간단한 시도를 방어하기 위해 구현 한 완화 및 보안 관행에 관심이 있습니다. 직원 계정에 대한 액세스.

주 SE 사이트는 분명히 방화벽 뒤에 놓을 수 없으므로 항상 노출됩니다. 그리고 SE 내부 로그인 방법은 2FA 방법을 제공하지 않습니다.

• 직원 계정 2FA는 다른 수단 (또는 다른 로그인 공급자)을 통해 보호됩니까?
• 보안 수준이 낮고 계정에 액세스하기 위해 복구 메일을 수신하는 데 여전히 사용될 수있는 직원 계정에 개인 이메일 주소 또는 로그인 제공 업체가 연결되지 않도록하는 조치가 있습니까?
• 직원 계정에 대한 새로운 소스의 로그인 시도를 모니터링하고 있습니까?
• 누군가가 직원 계정의 실행중인 세션에 액세스 할 경우 위험한 직원 도구에 대한 추가 보호가 있습니까 (예 : 보안에 중요한 도구에 액세스 할 때 암호 및 / 또는 2FA 토큰 다시 필요)

스피어 피싱과 같은 것은 아마도 누군가가 직원 계정에 대한 액세스 권한을 얻으려고 시도 할 가능성이 더 높은 방법 중 하나 일 것입니다.

이 보안 사고가 발생했을 때 며칠 후 일부 사용자는 채팅에서 트위터 원 박스가 더 이상 작동하지 않는다는 사실을 알아 차리기 시작했습니다 . 이후 한 직원은 내년 2 월 에이 보안 사고의 결과로 "일부 격차를 해소"해야했기 때문에 의도적 으로 비활성화 되었음을 확인했습니다 .

이 보안 사고의 결과로 채팅에서 Twitter oneboxing을 비활성화해야하는 이유에 대한 자세한 설명을 얻을 수 있습니까? 당시 게시 된 블로그 게시물에는 "다른 잠재적 벡터"가 폐쇄되었다고 명시되어 있으며 위에서 링크 한 2020 년 2 월 직원 메시지에는 트위터 원 박싱 기능이 "우리가 폐쇄 한 틈새 중 하나를 사용했습니다"라고 명시했습니다. 그게 무엇이며 어떤 보안 위험을 초래 했습니까?

마지막으로이 기능을 안전한 방식으로 다시 구현할 수있는 방법이 있습니까? 위의 직원 메시지가 나온 지 몇 달 후인 2020 년 8 월, 당시 제출 된 버그 보고서는 다른 직원에 의해 상태 별로 표시 되었습니다. (안전한 방식으로) 설계를 다시 변경하라는 기능 요청이 고려됩니까, 아니면 공격 벡터를 개방하지 않고는 그렇게 할 수 없습니까?

TeamCity의 "password" 매개 변수 유형 이 안전하지 않은 것으로 표시됩니다.

비밀번호 값은 TeamCity 데이터 디렉토리의 구성 파일에 저장됩니다. 서버 암호화 설정에 따라 값은 스크램블되거나 사용자 지정 키로 암호화됩니다.

빌드 로그 값은 간단한 검색 및 바꾸기 알고리즘으로 숨겨져 있으므로 간단한 암호가 "123"인 경우 "123"의 모든 항목이 대체되어 잠재적으로 암호가 노출됩니다. 매개 변수를 암호 유형으로 설정한다고해서 원시 값을 검색 할 수 없다는 보장은 없습니다. 모든 프로젝트 관리자는이를 검색 할 수 있으며 빌드 스크립트를 변경할 수있는 개발자는 암호를 얻기 위해 잠재적으로 악성 코드를 작성할 수 있습니다.

개발자의 매직 링크가 CM (아마도 dev에만 있음)이 볼 수있는 실제 매직 링크 인 이유는 무엇입니까?

이것은 정말 멋진 사건 보고서입니다! 내가 읽은 최고의 책 중 하나입니다.

공개 해주신 Stack과 훌륭한 글을 주신 Dean에게 감사드립니다!

나는 단지 몇 가지를 알고 싶습니다.

• 사고 대응 팀의 규모는 얼마입니까?
• 조사 중에 특정 프로토콜을 따랐습니까?
• 외부 보안 공급 업체를 참여시키기 위해 어떤 핵심 요소가 관련 되었습니까? 특정 공급 업체를 선택할 때 고려한 사항은 무엇입니까?
• 외부 보안 공급 업체로부터 어떤 교훈을 얻었습니까? 감사 프로세스가 팀에서 이미 사용한 것과 다른 (효과적 / 비 효과적) 프로세스였습니까?

이 기사는 Stack의 전체 아키텍처와 개발 프로세스를 잘 보여줍니다. 그것에 대한 기사가 이미 있다면 더 자세한 읽기 또는 링크가 좋을 것입니다.

"다른 사용자에게 조언"에서 :

모든 인바운드 트래픽을 기록하십시오. 모든 인바운드 연결에 대한 로그를 보관합니다. 이것은 우리의 모든 조사를 가능하게했습니다. 기록하지 않은 내용은 조사 할 수 없습니다.

Stack Exchange만큼 바쁜 네트워크가 전체 인바운드 트래픽을 어떻게 기록 할 수 있습니까? 이러한 로그는 웹 서버 항목입니까, IP 흐름입니까, 전체 TCP 세션입니까?

내 작은 네트워크에서 대부분의 항목과 연결 시도를 기록 할 수 있지만 그렇게 큰 네트워크가 어떻게 작동하는지 모르겠습니다.

아래 인용문에서 "공개적으로 접근 가능한 속성"이 무엇을 의미 하는지 더 명확하게 설명 할 수 있습니까 ?

공개적으로 액세스 할 수있는 속성에 대한 모든 트래픽의 로그를 포함하는 데이터베이스가 있습니다.