데비안 취약한 키 취약점에 걸리고 말았던 이야기
- 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은 가장 널리 쓰이는 암호화 라이브러리 중 하나라서 이런 취약점의 영향이 매우 큼. 오픈소스의 장점이자 단점이 여기서 잘 드러남.
- 이런 취약점을 예방하려면 코드 리뷰와 보안 감사를 강화하고, 중요한 부분의 변경은 더 신중하게 검토해야 함. 하지만 완벽한 방법은 없음.
- 그럼에도 오픈소스는 전문가들이 직접 코드를 살펴 문제를 찾아낼 수 있다는 장점이 있음. 폐쇄적인 프로그램은 그것도 불가능함.