▲

데비안 취약한 키 취약점에 걸려 넘어진 사연

 (hezmatt.org)
2P by GN⁺ 2024-04-10 | ★ favorite | 댓글 1개

데비안 취약한 키 취약점에 걸리고 말았던 이야기

  • 2008년 3월, 저자는 Engine Yard(EY)에서 일하고 있었음
  • 당시 EY는 GitHub에 무료로 인프라를 제공하며 도와주고 있었음
  • GitHub가 성장하면서 SSH 로그인 시간이 느려지는 문제가 발생함
  • GitHub는 표준 방식인 ~/.ssh/authorized_keys 파일을 사용하여 SSH 키를 관리하고 있었음
  • SSH는 사용자가 연결할 때 이 파일을 열어 사용자가 제시한 키와 일치하는 키를 선형 검색함
  • 보통은 몇 개의 키만 있어서 문제가 되지 않지만, GitHub처럼 사용자가 많아지면 느려짐

authorized_keys 파일 대신 MySQL DB 사용 결정

  • 여러 대안을 검토한 끝에 OpenSSH를 패치하여 키 검색을 MySQL DB에서 하도록 변경하기로 함
  • 이는 신중한 결정이었으며, 보안을 해치지 않도록 많은 노력을 기울임
  • 2008년 4월 초에 적용하여 SSH 로그인 속도 문제를 해결함

이상한 일 발생

  • 한 달 뒤인 5월 초, 일부 사용자가 다른 사용자의 저장소에 SSH로 접근할 수 있게 되는 문제 발생
  • 조사 결과, 서로 다른 사용자들이 동일한 키 지문을 가진 키를 사용하고 있었음
  • 이는 키를 공유하지 않는 한 일어날 수 없는 일임
  • 사용자들은 서로 모른다고 하며 어떻게 키가 유출되었는지 알 수 없다고 함
  • 다른 사용자 쌍에서도 동일한 문제가 발견됨
  • 공통점은 모두 Debian이나 Ubuntu 시스템을 사용하고 있다는 것뿐이었음

원인 규명

  • 2008년 5월 13일, DSA-1571-1 공개로 모든 것이 명확해짐
  • Debian 메인테이너가 OpenSSL의 난수 생성 코드를 정리하면서 실수로 가능한 키의 수를 32,000개 정도로 줄여버림
  • 많은 사람들이 GitHub에 가입하면서 모범사례에 따라 새 키를 생성했고, 이로 인해 충돌이 발생한 것
  • 이후 저자는 알려진 취약한 키들을 활용하여 문제가 있는 인증기관을 찾는 등 이 문제와 더 많은 연관을 가지게 됨

GN⁺의 의견

  • 이렇게 중요한 취약점을 찾아내려면 '이상하다'는 생각을 하고 끈질기게 조사할 수 있는 시간과 에너지가 필요함. 보통은 그런 여유가 없기 때문에 운이 좋아야 함.
  • 대부분의 사람들은 바쁜 일상에 쫓겨 문제의 근본 원인까지 캐내기 어려움. 우리 업계가 이런 여유를 되찾는 것이 중요한 숙제라고 봄.
  • OpenSSL은 가장 널리 쓰이는 암호화 라이브러리 중 하나라서 이런 취약점의 영향이 매우 큼. 오픈소스의 장점이자 단점이 여기서 잘 드러남.
  • 이런 취약점을 예방하려면 코드 리뷰와 보안 감사를 강화하고, 중요한 부분의 변경은 더 신중하게 검토해야 함. 하지만 완벽한 방법은 없음.
  • 그럼에도 오픈소스는 전문가들이 직접 코드를 살펴 문제를 찾아낼 수 있다는 장점이 있음. 폐쇄적인 프로그램은 그것도 불가능함.

함께 보면 좋은 글 β

▲
GN⁺ 2024-04-10  [-]
Hacker News 의견
  • Luciano Bello는 우연히 CVE-2008-0166 취약점을 발견했는데, 당시 IRC 로그에 따르면 많은 소수가 필요했고 매번 같은 숫자를 얻은 것은 아니었음
  • 업계 전반적으로 운이 좋았던 것 같은데, 적시에 큰 차이를 만들 수 있는 기술과 시간, 에너지를 가진 사람이 있었기 때문임. 이는 "많은 눈"과 "햇볕이 소독제"라는 통계가 실감나는 대목임. 누군가 우연히 버그를 발견할 확률이 아무리 낮더라도, 사람들은 그럴 수 있기에 발견하게 됨. 반면 사유/폐쇄형 코드에서는 그 확률이 0임
  • 이 취약점을 초래한 변경사항은 급하게 이뤄진 것이 아니었음. 관리자가 OpenSSL 메일링 리스트에서 문제를 제기하고, 피드백을 요청하며 해결책을 제안했고, 업스트림을 포함해 일부 피드백을 받았음. 결과는 끔찍한 취약점이었지만, 모두가 문제를 발견하지 못한 엄청나게 불행한 사례로 보임
  • GitHub이 MySQL 데이터베이스에서 키 지문으로 색인된 키를 조회하도록 OpenSSH를 패치하는 것이 최선의 옵션이라고 결론 내림. ~/.ssh/authorized_keys에 대한 액세스 속도를 높이려 한 상황에서 MySQL이 빛을 발할 수 있는 종류의 상황이었기에 SQLite 대신 선택한 것으로 보임
  • 이는 인기 있는 비트코인 하드웨어 지갑의 시드 생성 함수에서 이런 일이 일어날 가능성과 그 여파에 대해 생각해보게 함
  • GCD를 사용하여 공통 'p' 또는 'q' 인수가 있는 RSA 키 감지도 흥미로운 에피소드였음
  • SSH 로그인 시간이 느린 것이 이런저런 이유로 잡아당길 만한 가치가 있는 실마리임을 볼 수 있음
  • OpenSSL RNG는 초기화되지 않은 스택 메모리와 PID로 시드되었는데, Debian 패치가 없더라도 PID만으로 시드하는 것 자체가 이미 상당히 위험했던 것으로 보임
  • GitHub이 여전히 패치된 OpenSSH를 실행 중인지 궁금함
  • Ezra Zygmuntowicz가 GitHub을 필자에게 소개해주고, GitHub 팀과 함께 문제를 파고들 시간을 줬다는 문장이 재미있음. GitHub 팀 자체에 큰 문제가 있는 것처럼 읽히기 때문일 수도 있음
  • Luciano가 발견하지 않았다면 얼마나 더 오랫동안 발견되지 않았을지 궁금함. GitHub이나 대형 클라우드 제공업체 같이 사용자로부터 수천 개의 키를 저장하는 몇 안 되는 곳만이 우연히 발견했을 것으로 생각됨
답변달기