Tor 출구 릴레이 300여 개를 퇴출시킨 과정

AI 요약

10월 2일 오전 9시 35분, 감염된 Tor 출구 릴레이 333개가 SSH 연결을 가로채기 시작했습니다. 전체 출구 릴레이 약 3,000개의 10%가량입니다. 공격자는 두 달 전인 8월에 서버에 침투해 Linux용 OpenSSH 백도어이자 자격 증명 탈취 도구인 Ebury 1.8.3을 설치했습니다.

공격 방식과 영향

공격에는 암호화되지 않은 이메일 트래픽을 모으는 목적과 SSH 연결을 중간자 공격으로 가로채는 목적이 있었던 것으로 보입니다. 특정 포트를 차단해 릴레이가 암호화되지 않은 메일 트래픽만 처리하게 했습니다. SSH 공격에서는 감염된 출구 릴레이를 통과해 22번 포트로 접속하면, 연결이 12개의 SSH 가로채기 서버 중 하나로 우회됐습니다. 일반적인 암호화 웹 트래픽은 그대로 전달됐습니다.

공격자가 만든 서버는 정상 서버와 다른 SSH 호스트 키를 보내므로, 클라이언트에는 원격 호스트 식별 정보가 바뀌었다는 경고가 표시됩니다. 이 경고를 무시하고 로그인을 계속하면 공격자는 비밀번호를 훔치고, 명령 입력을 엿보는 중간자 연결을 열며, 별도의 연결로 대상 서버에 Ebury를 설치하려 했습니다.

감염 릴레이를 찾아내고 차단한 과정

글쓴이는 exitmap으로 출구 릴레이를 하나씩 지정한 뒤 자신의 서버 A에서 서버 B로 SSH 연결을 시도하는 스크립트를 작성했습니다. 서버 A는 서버 B의 올바른 SSH 지문이 도착했는지 확인했습니다. 서버 B는 연결이 지정한 출구 릴레이에서 왔는지, 아니면 12개 가로채기 서버 중 하나에서 왔는지 확인했습니다.

약 3,000개 출구 릴레이를 검사한 결과, 약 12개에서 가짜 지문이 관찰됐습니다. 나머지 300여 개는 직접 가로채지 않고 같은 가로채기 서버로 연결을 우회했습니다. 글쓴이는 우회만으로도 릴레이가 감염됐음을 확인할 수 있었다고 설명합니다. 추가 분석에는 SSH 허니팟 sshesame를 사용했습니다. 공격자가 허니팟에 접속하도록 유도해 Python SSH 라이브러리 paramiko를 사용하고 Perl로 Ebury 설치를 시도한다는 점을 파악했습니다. 설치 명령은 먼저 권한을 확인한 뒤 Base64로 인코딩한 명령을 디코딩해 실행하는 방식이었습니다.

대응과 남은 의문

글쓴이는 금요일 저녁 Tor Project의 네트워크 상태팀에 발견 내용을 전달했습니다. 팀은 운영자들에게 연락했고, 10월 4일 감염 릴레이를 BadExit으로 지정해 클라이언트가 출구로 사용하지 못하게 했습니다. 공격자가 10월 5일 다수 릴레이를 재시작했지만, 이미 표시된 릴레이는 중계 노드로만 작동했습니다. 감염 서버는 운영자와 공격자가 차례로 종료했습니다. Tor 측은 공격자가 Linux 호스트에 침투한 뒤 비출구 릴레이의 torrc를 수정해 출구 릴레이로 바꿨다는 패턴을 설명했습니다.

침투 경로는 밝혀지지 않았습니다. 호스팅 업체 자체가 해킹됐다는 설이 있지만 확인된 사실은 아닙니다. 공격 주체가 금전적 동기를 가진 범죄 집단이라는 추정도 Ebury 사용과 데이터 수집 양상에 근거한 추측입니다. 글쓴이는 SSH 비밀번호 인증 대신 키 인증을 권하고 하드웨어 키를 구매하겠다고 덧붙입니다.

Lobsters 반응

• @dzwdz — 제목에 '악성'이라는 말이 빠진 것 같습니다. 농담은 그렇고, SSH에 비밀번호 인증을 쓰는 사람이 아직도 있다는 점이 놀랍습니다. 별다른 이점 없이 여러 위험에 노출되는 일처럼 보입니다. 기본값으로 활성화되지 않았으면 좋겠습니다. OpenSSH에서 PAKE를 설정하는 방법이 있었던 것 같은데 sshd_config(5)를 훑어봐도 찾지 못했습니다. 좋은 해결책은 아닐 겁니다. 클라이언트에서도 일반 비밀번호 인증과 자동 공개키·익명 로그인을 차단해야 하니, 그럴 바에는 공개키 인증을 쓰면 됩니다. 그래도 흥미롭기는 합니다.

원문: Kaba / 번역·요약: Trawling