Security

파이선 리포지터리 PyPI에서 고급 악성 패키지 발견돼

문가용 기자

Published: 11:45, 04 Oct 2025 (Updated: 14:42, 14 Jan 2026)

💡

Editor's Pick
- soopsocks라는 악성 패키지, 2600번 다운로드 돼
- SOCKS5 프록시 생성 후 여러 악성행위 실시
- 공공 리포지터리의 안전한 활용 위한 대책 도입 시급

파이선 생태계의 코드 리포지터리인 PyPI에서 악성코드가 유포되고 있다는 사실이 발견됐다. 이번 악성 패키지는 일종의 백도어 기능을 가지고 있다고 한다. SOCKS5 프록시 서비스를 생성하고, 추가 페이로드를 다운로드 해 설치할 수 있다. 이 패키지의 이름은 soopsocks이며, 현재까지 2600번 이상 다운로드 됐다. 업로더는 수달파이(soodalpie)라는 인물이다.

악성 패키지의 특성
악성 패키지를 제일 먼저 발견한 보안 업체 제이프로그(JFrog)는 “해당 패키지는 윈도 환경을 대상으로 하며, 다운로드 받아 실행할 경우 자동 설치 과정을 통해 백도어 프록시 서버 역할을 하도록 만들어져 있다”고 설명한다. 그 최초 실행을 위한 실행파일은 고(Go) 언어로 컴파일링 되어 있다. 다음과 같은 기능들을 가지고 있다.

1) SOCKS5 프록시 서비스를 생성한다
2) 파워셸 스크립트를 실행한다
3) 방화벽 규칙을 설정한다
4) 권한을 상승시킴으로써 스스로 재실행하도록 설정을 바꾼다
5) 인터넷 익스플로러의 보안 설정을 알아낸다
6) 윈도 설치 날짜를 알아낸다
7) 기본 시스템 및 네트워크 정보를 빼돌린다
8) 수집한 모든 정보를 디스코드(Discord)를 통해 유출한다

2)번 과정에서 실행되는 파워셸 스크립트는, 또 다른 배치 스크립트를 호출하여 파이선 패키지가 실행되게 한다. 실행된 파이선 패키지는 순차적으로 권한을 상승시키며, UDP와 TCP 통신을 1080 포트를 통해 허용하는 방화벽 규칙을 새롭게 구성한다. 또한 디스코드와의 통신망을 연결해 유지하고, 호스트에서 작업 스케줄을 조작함으로써 공격 지속성을 확보한다.

제이프로그는 이러한 soopsocks 패키지에 대해 이렇게 설명한다. “정교하고 치밀하게 설계된 SOCKS5 프록시입니다. 또한 여러 가지 악성 행위를 고루 갖추고 있기도 합니다. 누군가 단순 프록시를 넘어, 악성 행위를 철저하게 계획하여 만들어낸 것으로 추정됩니다.”

공공 리포지터리들을 어떻게 해야 하나
PyPI뿐만 아니라 NPM과 깃허브(GitHub) 등 각종 리포지터리들이 해커들의 집중 공략을 받고 있다. 여기에 스리슬쩍 악성 패키지를 만들어 올리기만 해도 개발자들이 가져가고, 가져간 것을 가지고 각종 애플리케이션을 개발한다. 그러면 다량의 악성 애플리케이션이 자동으로 만들어지고, 사용자들에게로 퍼져간다. 패키지 하나 업로드하면 여러 사람들이 한꺼번에 감염된다는 게 이런 ‘리포지터리 감염 공격’의 가장 큰 장점이다.

이는 리포지터리의 주요 사용자인 개발자들이 다운로드 받은 패키지를 사용하기 전에 검사만 몇 번 해도 근절시킬 수 있는 문제다. 그렇다고 개발자의 안일한 보안 인식만 탓할 수도 없다. ‘속도’가 최고의 미덕인 개발 환경 상 모든 패키지를 하나하나 점검한다는 건 쉬운 일이 아니기 때문이다. 그래서 리포지터리 및 오픈소스를 활용한 개발 방법론과, 속도를 중시하는 기업들의 출시 경쟁 문화가 상극이라는 분석도 나오고 있다.

리포지터리의 안전한 활용에 대한 방법론 중 일반적으로 통용되는 것은 다음과 같다.
1) 거버넌스와 자산 파악/총망라 : 어떤 패키지가 사용되고 있는지 정확히 파악하는 게 모든 보안 점검보다 선행돼야 한다. 또한 소프트웨어 물자표(SBOM)를 작성 및 유지하는 체계도 정착시켜야 한다.

2) 패키지 무결성 확인 : 패키지 서명 제도를 도입하는 등, 패키지의 무결성을 확인하고 유지하기 위한 시스템이 갖춰져야 한다. 서명된 아티팩트만 배포 과정에 허용하도록 한다면 큰 도움이 될 수 있다.

3) 리포지터리 계정 보호 : 리포지터리에 각종 패키지를 올리고 퍼블리시 할 수 있는 계정들은 다중인증 등을 기본으로 해야 한다. 또한 각 기업들도 이런 계정들을 엄격히 관리할 필요가 있다.

4) 의존성 관리 정책 수립 : 애플리케이션 개발을 위해 여러 오픈소스나 코드를 가져다 쓰기 때문에, 각 요소들은 상호 의존을 할 수밖에 없다. 이를 ‘의존성’이라고 하는데, 요즘 소프트웨어들은 이런 의존성들이 그물처럼 빽빽하게 얽혀있다. 그래서 관리를 못하게 되는데, 이 지점을 취약점 하나가 파고들면 재앙과 같은 사태가 발생한다. 따라서 의존성 스캔과 관리를 효과적으로 하는 방법을 개발해야 한다.

5) 패키지 설치 시 위험 줄이기 : 런타임과 빌드 환경을 격리시켜서 실행 스크립트가 안전하게 돌아가도록 꾀해야 한다. 실제 상품 개발과 배포 환경에 새로운 코드를 무작정 실행시키는 건 매우 위험한 일임을 기억하는 게 중요하다.

6) 개발자 교육 : 시스템과 상업적 환경의 영향(압박)을 심하게 받는 게 현재 개발자들이긴 하지만, 그렇다고 개발자 개개인에 대한 보안 훈련의 필요성이 간과되어서는 안 된다. 내가 다운로드 받은 스크립트 안에 뭐가 있을 지 모른다는 찜찜함이 본능처럼 개발자들 안에 자리를 잡는다면, 개발을 통한 결과물이 더 안전해질 수 있다.