OpenSSH SSHole, SANS도 공격 시도 관측

OpenSSH SSHole(CVE-2026-123158)의 공격 시도를 SANS 인터넷 스톰 센터도 별도로 관측했습니다. 다만 원문 표의 713건을 피해 서버 713대로 읽으면 안 됩니다. 이는 긴 비밀번호 요청 기록이며, SANS가 확정한 성공 로그인 수가 아닙니다.[1]

핵심 요약

SANS의 새 자료는 공격 시도에 관한 관측입니다. 긴 입력 기록, 실제 악용 시도, 인증 성공, 조직 피해는 서로 다른 단계입니다. 운영자는 숫자만 보기보다 노출된 SSH의 배포판·인증 구성과 공식 수정 패키지를 확인해야 합니다.[1][3][4]

SANS가 새로 관측한 것은 무엇인가요?

공격을 관찰하도록 마련한 유인 시스템인 허니팟에서 SSHole 악용 시도가 늘었다는 설명과 날짜별 긴 비밀번호 요청 기록입니다. SANS는 Cowrie를 이용해 SSH 데이터를 수집한다고 밝혔습니다. 기존 단일 허니팟 성공 사례와는 별개의 관측 자료입니다.[1][2]

SANS 본문의 Published 표시는 2026년 11월 8일로 날짜만 나옵니다. 마지막 수정시각은 11월 8일 15:44:33 UTC이며, 공식 RSS 배포시각도 같아 한국시간으로는 11월 9일 00:44:33입니다. 본문 날짜와 RSS 배포시각을 구분해서 볼 필요가 있습니다.[1][7]

관측에는 한계가 있습니다. SANS의 Cowrie는 비밀번호의 첫 255자까지만 수집합니다. 따라서 잘린 기록만으로 모든 요청의 전체 길이나 악용 의도를 확정할 수는 없습니다. 이 특성을 일반 운영 서버의 기본 SSH 로그 기능으로 이해해서도 안 됩니다.[1]

긴 비밀번호 713건은 어떤 숫자인가요?

원문의 11월 6일에 집계된 긴 비밀번호 요청 기록 수입니다. 서버나 피해 조직의 수가 아니며, 모두 검증된 SSHole 악용이라는 뜻도 아닙니다.[1]

이 표의 집계 시간대는 원문에 명시돼 있지 않습니다. 한국시간 기준 하루 통계로 바꾸지 않았습니다. SANS는 악용 시도 증가를 설명하지만, 위 값으로 최근까지 매일 공격이 늘거나 폭증했다고 말할 수는 없습니다.[1]

긴 입력이 포착됐다는 사실과 특정 취약점 악용으로 분류됐다는 판단도 구분해야 합니다. SANS는 11월 5일을 첫 실제 SSHole 악용 시도로 설명했습니다. 반면 11월 1일 기록은 잘못 작성된 스크립트가 명령을 비밀번호 칸에 넣은 것으로 보이며, SSHole 악용과 무관해 보인다고 했습니다. 앞선 기록까지 취약점 공개 전 공격의 증거로 끌어오면 원문과 달라집니다.[1]

로그인 성공과 실제 피해도 확인됐나요?

SANS는 성공 로그인 수를 확정하지 않았습니다. 저자는 상당수 시도가 성공했을 것으로 예상하면서 추가 분석을 예고했습니다. 예상은 성공 확인이나 감염 대수 발표와 다릅니다.[1]

앞서 Help Net Security는 Previdian 창업자 Ryan Dewhurst의 설명을 인용해 실제 Alpine·OpenSSH 허니팟에서 root 접근이 확인됐다고 보도했습니다. 이는 한 센서, 한 출발지에서 나온 8번의 시도와 관련된 별도 관측입니다. SANS의 요청 기록과 더해 전체 공격·피해 규모를 계산할 수 없습니다.[2]

이번 글의 확인 범위에서는 실제 조직의 피해 대수, 랜섬웨어 연계, 봇넷 감염 규모를 뒷받침할 자료를 확보하지 못했습니다. 피해가 없다는 뜻은 아닙니다. 허니팟의 침입 성공과 실사용 조직의 피해 확인을 같은 사실로 다루지 않는다는 뜻입니다.[1][2]

Ubuntu 운영자는 무엇을 구분해야 하나요?

호스트의 배포판 이름뿐 아니라 실제로 SSH 서버가 실행되는 환경과 인증 구성을 구분해야 합니다. 공식 설명의 핵심 조건은 musl 기반 Linux에서 PAM을 사용하지 않는 인증 경로와 비밀번호 인증 등입니다. 계정 상태에 관한 추가 조건도 있어 모든 OpenSSH 설치가 같은 영향을 받는 것은 아닙니다. root 직접 로그인에는 별도의 허용 설정도 관계됩니다.[3][4][6]

Ubuntu 호스트 위에서 Alpine 기반 SSH 컨테이너나 사용자 빌드를 실행한다면 호스트와 별도로 살펴봐야 합니다. 반대로 SSH 서버가 실행되지 않는 컨테이너까지 모두 취약하다고 볼 수는 없습니다.[3][4]

2026년 11월 9일 07:58 KST 선행 조사에서 확인한 Ubuntu 공식 페이지의 openssh 항목 중 22.04·24.04·26.04 LTS 및 26.10은 Needs evaluation으로 표시됐습니다. 뜻은 ‘평가 필요’입니다. 취약 확정, 미패치 확정, 수정 완료 어느 것으로도 바꿔 쓸 수 없습니다. 이번 작성 중 재조회는 시간 초과로 완료하지 못했으므로 이후 상태가 바뀌었는지는 확인하지 못했습니다. 이 상태표는 독자의 실제 설치 구성이나 전체 안전성을 확인해 주는 자료도 아닙니다.[5]

수정 버전은 10.6p2만 보면 되나요?

아닙니다. 업스트림 릴리스와 배포판이 기존 버전에 수정을 반영한 패키지를 구분해야 합니다. OpenSSH는 10.6p2에서 해당 인증 우회를 막는 보안 조치를 제공했습니다. Alpine은 분기별 수정 패키지를 안내하므로 버전 숫자가 10.6p2보다 작다는 이유만으로 미수정이라고 판단하면 안 됩니다.[3][4]

Alpine 공지의 예로 3.24는 10.3_p1-r2, 3.23은 10.2_p1-r1, 3.22는 10.0_p1-r11입니다. 실제 적용 판단은 해당 자산의 분기와 공식 패키지 안내를 기준으로 해야 합니다. 수정 패키지가 제공됐다는 사실과 해당 분기의 정상 지원 여부도 별개입니다. 모든 서버에 업스트림 10.6p2를 직접 설치하는 방식으로 대응을 통일할 사안은 아닙니다.[3]

운영 대응은 어떤 순서로 판단하면 좋을까요?

자산과 영향 조건을 나눈 뒤 공식 패치 안내, 실행 중인 프로세스, 기존 로그인 기록을 각각 확인하는 순서가 좋습니다. 패치 완료와 과거 침입 여부 확인은 서로 다른 작업입니다.[3][4]

1. 일반 운영 권고 — 자산 식별: 외부에 노출된 SSH와 호스트·컨테이너별 배포판, 지원 분기, musl/PAM 및 유효 인증 구성을 목록으로 구분합니다. 호스트 이름만 보고 내부 실행 환경까지 같은 결론을 내리지 않는 것이 중요합니다.
2. Alpine 공식 권고 — 수정 패키지와 재시작: 영향 환경에는 해당 분기의 수정 패키지를 적용하고 sshd를 재시작하도록 안내합니다. 패키지 업데이트만으로 실행 중인 프로세스까지 교체되는 것은 아닙니다. 실제 변경은 조직의 접속 보존·승인 절차를 따라야 합니다.[3]
3. 일반 운영 권고 — 노출 최소화: 기존 관리망·VPN·접근 허용 정책을 기준으로 불필요한 SSH 노출을 줄이는 방안을 검토합니다. 이는 패치를 대신하는 완전한 방어책이나 SANS가 새로 내린 공식 지시가 아닙니다.
4. Alpine 공식 권고 — 기존 기록 검토: 비밀번호 로그인이 없어야 할 계정의 로그인 성공 기록과 doas 사용, 최근 사용자·파일·authorized_keys 변경을 살펴보도록 안내합니다. 배포판별 로그 위치와 보존 설정은 다를 수 있습니다. 의심 로그인을 배제할 수 없다면 침해 대응 절차로 다뤄야 합니다.[3]

즉시 갱신이 어려운 경우 Alpine은 비밀번호 인증 비활성화를 완화책으로 설명합니다. 다만 키 로그인이 가능한지, 현재 접속을 보존할 수 있는지 등을 먼저 검토해야 합니다. 이 글은 특정 장비의 설정 변경이나 명령 실행을 지시하는 절차서가 아닙니다.[3]

운영 서버의 기본 sshd 로그가 비밀번호 본문이나 길이를 항상 남긴다고 가정해서는 안 됩니다. 새로 비밀번호 원문을 수집할 필요도 없습니다. 이미 확보된 인증·접속 기록을 검토하되, 로그가 없다는 이유만으로 공격이 없었다고 단정하지 않는 편이 안전합니다.

이번 후속에서 달라진 점은 별도 관측망인 SANS에서도 시도 기록이 나왔다는 것입니다. 중요한 것은 713이라는 숫자를 피해 대수로 바꾸는 일이 아니라, 관측의 한계를 이해하고 자신의 실행 환경에 맞는 공식 조치를 판단하는 일입니다.[1][3]

배경 글: 초기 영향 조건과 패치는 [8], Previdian 허니팟 성공 관측을 다룬 이전 후속은 [9]에서 볼 수 있습니다. 이번 글은 두 글과 별개의 SANS 관측 후속입니다.

출처