[태그:] 해킹

ATM 한 대 뜯어보면 암호화 모듈, 인증 라이브러리, 카드리더 펌웨어까지 외부 부품이 수십 개 들어가 있다. 한 보안 연구자가 이 부품들 속에서 아홉 개의 취약점을 찾아냈는데, 문제는 은행 창구 앞 기계 한 대로 끝나지 않는다. 같은 암호화 라이브러리와 인증 모듈이 결제 단말기, 산업용 제어 장비, 일반 기업 서버에도 그대로 재사용되기 때문이다. 소프트웨어 공급망 공격이 무서운 이유가 바로 여기 있다. 정작 정확히 아는 사람은 드물다.

소프트웨어 공급망 공격, 정확히 뭔가

직접 공격은 해커가 목표 시스템의 방화벽이나 로그인 화면을 뚫는 방식이다. 공급망 공격은 다르다. 목표를 곧바로 노리지 않는다. 대신 그 목표가 쓰는 부품, 라이브러리, 업데이트 서버를 먼저 장악한다. 건물을 부수는 대신 벽돌 공장에 불량 벽돌을 섞어 넣는 셈이다. 그 벽돌을 산 건설사는 전부 위험에 노출된다.

은행, 병원, 제조사가 각자 만들었다고 믿는 프로그램도 실제로는 오픈소스 라이브러리나 외부 벤더 모듈을 가져다 조립한 결과물이다. 모듈 하나에 구멍이 나면, 그 모듈을 쓰는 회사 전부가 동시에 뚫린다.

ATM 취약점, 패턴은 늘 비슷하다

와이어드가 전한 이번 조사 결과를 보면, 발견된 결함들이 하나같이 낯익다.

• 암호화 키가 코드 안에 하드코딩되어 있어 리버스 엔지니어링만으로 추출 가능
• 수년 전 폐기된 구버전 암호화 알고리즘을 여전히 기본값으로 사용
• 인증 절차를 우회할 수 있는 로직 오류
• 제조사 간 코드 재사용으로 한 벤더의 결함이 여러 브랜드 기기에 동시 존재

ATM 제조사가 직접 짠 코드가 아니라, 암호화·인증을 전담하는 서드파티 소프트웨어 회사의 라이브러리에서 문제가 나왔다는 게 핵심이다. 이 라이브러리, ATM에만 들어가는 게 아니다. 키오스크, 결제 단말기, 잠금장치 같은 다른 임베디드 기기에도 그대로 박혀 있다.

왜 자꾸 반복될까

구조적인 이유는 세 가지로 정리된다.

• 레거시 의존성 — 임베디드 기기는 교체 주기가 10~15년으로 길다. 한번 탑재된 암호화 모듈은 좀처럼 바뀌지 않는다.
• 벤더 신뢰의 함정 — 대형 제조사도 하청 업체가 만든 모듈의 내부 코드까지 검증하지 않고 그대로 채택하는 경우가 흔하다.
• 패치 배포의 어려움 — 서버 소프트웨어와는 다르다. 물리적으로 흩어진 수만 대 기기에 업데이트를 적용하려면 현장 출동이 필요할 때가 많다.

결함 하나가 발견돼도 실제 패치가 모든 기기에 깔리기까지 몇 년씩 걸리는 일, 드물지 않다.

기억해둘 만한 사고 세 건

비슷한 구조의 사고, 이전에도 있었다.

• 솔라윈즈(2020) — 네트워크 관리 소프트웨어 업데이트 서버가 해킹당했다. 이를 쓰던 미국 정부기관과 대기업 수천 곳이 동시에 뒷문을 열어준 꼴이 됐다.
• 로그4셸(2021) — 자바 로깅 라이브러리 Log4j의 결함 하나로 전 세계 서버 애플리케이션 상당수가 원격 코드 실행 위험에 노출됐다.
• XZ 유틸스(2024) — 리눅스 배포판 다수가 의존하는 압축 라이브러리에 수년에 걸쳐 은밀하게 백도어가 심어졌다가 뒤늦게 발견됐다.

ATM 사례는 규모만 다를 뿐 패턴은 같다. 눈에 보이는 서비스 하나가 아니라, 그 뒤에 숨은 부품 하나가 사고의 진짜 원인이라는 점. 매번 똑같이 확인된다.

기업·개발팀이 지금 점검해야 할 것들

소프트웨어를 만들거나 운영한다면 아래부터 확인해볼 만하다.

• SBOM(소프트웨어 자재명세서) 작성 — 어떤 오픈소스와 서드파티 모듈을 쓰는지 목록화
• 사용 중인 암호화 라이브러리의 버전과 알고리즘이 여전히 안전한 수준인지 주기 점검
• 외부 벤더 코드에 대한 정기 보안 감사 계약 조항 포함
• 패치 배포 자동화 — 임베디드·현장 기기일수록 원격 업데이트 체계가 사고 대응 속도를 가른다
• 디지털 서명 검증 없이는 업데이트를 설치하지 않는 정책

이 다섯 가지만 지켜도 사고 발생 시 원인 파악 시간이 크게 줄어든다.

일반 사용자가 챙길 만한 것들

당장 코드를 고칠 수는 없어도, 습관으로 위험을 줄이는 방법은 있다.

• 은행 지점이나 사람 많은 장소의 ATM을 이용하고, 카드 투입구에 이물질이 붙어 있는지 확인
• 거래 후 명세서나 앱 알림으로 이상 거래 여부를 바로 확인하는 습관
• 같은 은행이라도 기기별로 소프트웨어 버전이 다를 수 있다. 화면 UI가 유독 오래되거나 반응이 느리면 이용을 피하는 것도 방법
• 회사에서 쓰는 결제 단말기나 키오스크도 정기 점검 대상에 포함하도록 요청

이런 것도 궁금할 텐데

Q. SBOM이 정확히 뭔가요?
소프트웨어에 들어간 모든 구성 요소를 재료 목록처럼 정리한 문서다. 식품 성분표 생각하면 된다. 문제가 터졌을 때 어떤 제품에 특정 라이브러리가 들어갔는지 빠르게 추적하는 용도다.

Q. 공급망 공격은 왜 막기가 유독 힘든가요?
공격 대상이 하나가 아니라, 그 부품을 쓰는 모든 회사이기 때문이다. 제조사 하나가 아무리 보안을 잘 갖춰도, 협력사 코드까지 매번 검증하기는 현실적으로 쉽지 않다.

Q. 개인이 ATM을 쓸 때 실제로 위험한가요?
이번에 나온 결함들은 물리적 접근이나 네트워크 조작이 함께 필요한 경우가 많다. 평범한 이용자가 당장 피해를 볼 확률은 낮다. 다만 은행 입장에서는 대량 인출이나 카드 정보 유출로 이어질 여지가 있어, 가볍게 볼 사안은 아니다.

출처: Wired

법원, 병원, 공항. 보안이 생명인 곳들이 같은 이유로 한꺼번에 뚫릴 뻔했다. 범인은 다름 아닌 웹 콘텐츠 관리 소프트웨어, 이른바 CMS의 취약점이었다. 전혀 관련 없어 보이는 수백 개 사이트가 알고 보니 같은 부품을 쓰고 있었고, 그 부품 하나에 구멍이 나 있었던 셈이다.

교훈은 명확하다. 홈페이지 보안은 서버 하나만 잘 지킨다고 끝나는 문제가 아니다. 내가 쓰는 소프트웨어 자체에 결함이 있을 수도 있다는 뜻이다. 중소기업이나 개인 블로그 운영자라면 ‘나랑 무슨 상관이냐’ 싶겠지만, 이런 공급망형 취약점은 개인 사이트까지 그대로 파고든다. 그래서 정리해봤다. 내 홈페이지가 어떤 CMS로 돌아가는지, 뭘 점검해야 하는지.

CMS, 대체 뭐길래 자꾸 뚫리나

CMS는 코드를 몰라도 홈페이지 콘텐츠를 올리고 관리할 수 있게 해주는 소프트웨어다. 워드프레스, 그누보드, XE, 제로보드 같은 것들이 대표적이다. 국내 관공서와 기업 상당수가 이런 오픈소스 혹은 상용 CMS 위에 사이트를 얹어 운영한다. 문제는 같은 CMS를 쓰는 사이트가 전 세계에 수만 개씩 존재한다는 점. 공격자 입장에서는 CMS 코드 한 곳의 취약점만 찾아내면, 그 CMS를 쓰는 사이트를 통째로 노릴 수 있다. 법원과 병원, 공항이 같은 취약점으로 묶이는 이유도 여기 있다. 좀 얄궂지 않나.

내 홈페이지, 위험한지 확인하는 법

점검, 생각보다 어렵지 않다. 아래 항목부터 하나씩 짚어보자.

• 사이트 하단이나 페이지 소스에 CMS 이름과 버전이 그대로 노출되는지 본다
• Wappalyzer, BuiltWith 같은 브라우저 확장 프로그램으로 사용 중인 기술 스택을 조회해본다
• KISA(한국인터넷진흥원) 웹 취약점 자동진단 서비스나 무료 스캐너로 기본 점검을 돌려본다
• 관리자 로그인 페이지 주소가 기본값(/wp-admin, /admin 등) 그대로인지 확인한다
• 최근 1년 사이 CMS나 플러그인을 업데이트한 적이 있는지 본다

이 중 두세 개 이상 걸린다면, 손볼 때가 된 거다.

국내에서 많이 쓰는 CMS, 뭐가 약할까

CMS 종류마다 약한 지점이 조금씩 다르다.

• 워드프레스 — 본체보다 서드파티 플러그인과 테마에서 취약점이 훨씬 많이 터진다. 안 쓰는 플러그인 방치가 제일 흔한 실수다
• 그누보드, 영카트 — 게시판 파일 업로드 기능으로 웹셸을 심거나 SQL 인젝션을 노리는 게 단골 공격 경로다
• 카페24, 고도몰 같은 호스팅형 솔루션 — 플랫폼 자체 보안은 업체 몫이지만, 부가 모듈이나 디자인 스킨에서 구멍이 생기곤 한다
• 자체 개발 게시판 — 유지보수 인력이 빠지면 몇 년째 방치되는 일이 많아 오히려 더 위험하다

지금 바로 손댈 수 있는 보안 조치

큰돈 안 들이고도 손댈 수 있는 것부터 정리하면 이렇다.

• CMS 본체와 플러그인, 테마를 최신 버전으로 유지한다
• 안 쓰는 플러그인과 테마는 비활성화 말고 아예 삭제한다
• 관리자 페이지 접근을 특정 IP나 VPN으로 묶어둔다
• 관리자 계정에는 2단계 인증(OTP)을 걸어둔다
• 웹 방화벽(WAF)을 앞단에 세우고, 전체 백업은 주기적으로 별도 저장소에 보관한다

손보고 끝나는 게 아니다, 정기 점검이 진짜

한 번 손보고 끝내면 다시 뚫린다. 월 1회 CMS와 플러그인 업데이트 여부를 확인하고, 서버 접속 로그와 관리자 로그인 이력을 훑어보는 습관이 필요하다. 예산에 여유가 있다면 Nikto나 OpenVAS 같은 무료 취약점 스캐너를 정기적으로 돌리거나, 1년에 한 번쯤은 외부 보안업체에 모의해킹(펜테스트)을 맡기는 것도 방법이다. 공공기관이나 금융권처럼 규모가 큰 조직은 이런 점검이 의무인 경우가 많지만, 중소 웹사이트는 이런 절차 자체가 아예 없는 곳이 대부분이다.

해킹당했다면, 초기 대응 3단계

이미 이상 징후가 보인다면, 순서대로 움직이는 게 낫다. 먼저 서버를 네트워크에서 떼어내 추가 피해를 막고, 접속 로그와 파일 변조 흔적부터 확보한다. 증거를 남긴 다음엔 KISA 118 상담센터나 한국인터넷진흥원 침해사고 신고 창구에 신고하고, 안전한 시점의 백업으로 복원한 뒤 원인이 된 취약점을 반드시 막고 나서 서비스를 다시 열어야 한다. 원인을 못 찾은 채 복구만 하면, 같은 구멍으로 또 뚫리는 일이 흔하다.

자주 나오는 질문 몇 가지

Q. 워드프레스는 원래 위험한 CMS인가요?
A. 워드프레스 자체보다 관리 소홀이 진짜 원인인 경우가 많다. 본체 업데이트는 자동으로 잘 되는 편인데, 방치된 플러그인이 사고를 친다.

Q. 방문자가 적은 작은 사이트도 표적이 되나요?
A. 트래픽 크기와 상관없이 자동화된 스캐너는 도메인을 가리지 않고 훑는다. ‘설마 내 사이트가’ 싶겠지만, 오히려 관리가 허술한 소규모 사이트가 더 쉬운 먹잇감이다.

Q. 무료 CMS와 유료 솔루션 중 뭐가 더 안전한가요?
A. 라이선스보다 업데이트 주기와 관리 인력 유무가 안전을 가른다. 무료라도 꾸준히 관리하면 유료 솔루션보다 낫다.

출처: TechCrunch

리틀 스니치를 처음 설치한 사람들이 제일 먼저 하는 말이 있다. “이게 다 연결하고 있었어?” 컴퓨터를 켜놓기만 해도 수십 개의 프로세스가 외부 서버와 조용히 통신한다. 업데이트 확인, 기능 동기화, 라이선스 검증 — 대부분은 정상적인 작동이다. 문제는 그 틈새에 있다. 악성코드나 스파이웨어가 개인 정보를 빼내는 통로도 정확히 이 ‘보이지 않는 연결’을 이용한다. 네트워크 모니터링은 그걸 가시화하고 통제하는 기술이다.

방화벽이 있는데 왜 또 필요한가

방화벽(Firewall)으로 충분하다고 생각하기 쉽다. 틀린 말은 아닌데, 방화벽은 구조적으로 외부에서 내부로 들어오는 인바운드(Inbound) 트래픽 차단에 최적화돼 있다. 내 컴퓨터가 먼저 손을 뻗는 경우 — 즉 아웃바운드(Outbound) 트래픽 — 는 그냥 통과시키는 경우가 많다. 네트워크 모니터링 툴은 바로 이 부분을 잡는다. 방화벽과는 결정적으로 다른 지점이다. 네트워크 모니터링이 필요한 이유는 세 가지로 정리된다.

• 보안 강화: 악성코드가 감염된 후 C&C(명령 제어) 서버에 연결을 시도하거나, 랜섬웨어가 암호화 키를 전송하려는 행동을 실시간으로 탐지·차단한다.
• 프라이버시 보호: 사용자 동의 없이 사용 패턴이나 개인 정보를 외부로 전송하는 소프트웨어를 잡아낸다. 생각보다 이런 앱이 많다.
• 시스템 이해: 어떤 프로세스가, 어느 서버와, 얼마나 자주 통신하는지 파악하면 시스템 동작 원리를 더 깊이 이해하고, 불필요한 네트워크 자원 낭비도 줄인다.

아웃바운드 감시가 핵심인 이유

대부분의 공격은 인바운드로 시작된다. 그런데 실제 피해 — 정보 유출, 추가 공격 명령 수신 — 는 아웃바운드 통신을 통해 완성된다. 키로거가 탈취한 키보드 입력 기록을 해커 서버로 조용히 전송하는 게 전형적인 패턴이다. 내가 직접 설치한 워드 프로세서가 갑자기 알 수 없는 해외 IP로 접속을 시도한다면? 뭔가 이상하다. 이런 의심스러운 아웃바운드 신호를 포착하는 것, 그게 핵심이다.

대표 툴: 리틀 스니치(Little Snitch)

네트워크 모니터링 분야에서 가장 잘 알려진 툴은 단연 리틀 스니치다. macOS에서 오랫동안 신뢰를 쌓아온 도구로, 작동 방식이 직관적이다. 특정 앱이 인터넷에 연결을 시도하는 순간, 바로 알림창이 뜬다. 영구 허용, 이번만 허용, 완전 차단 — 세 가지 중 하나를 고르면 된다. 이렇게 규칙을 하나씩 쌓아가는 방식이라 처음엔 알림이 조금 많다. 일주일쯤 지나면 대부분 정리된다.

최근 리눅스 버전까지 출시하며 적용 범위를 넓혔다. The Verge 보도에 따르면, 개발자가 우분투(Ubuntu) 환경에서 일주일간 직접 테스트한 결과 시스템 프로세스 9개가 사용자 모르게 인터넷 연결을 생성한 것으로 드러났다. 운영체제 자체도 허락 없이 외부와 통신한다는 사실을 보여주는 결과다. 이건 좀 불편한 사실이긴 하다.

연결 요청이 왔을 때 판단하는 법

알림이 뜬다고 무조건 차단하면 프로그램이 제대로 작동하지 않는다. 정상적인 동작에 꼭 필요한 연결일 수도 있으니까. 아래 4가지 정보를 종합해서 판단해야 한다.

• 프로세스 이름: 어떤 프로그램이 연결을 시도하는가? (예: Chrome.exe, svchost.exe)
• 목적지 주소: 어느 서버의 IP 또는 도메인으로 접속하려 하는가? (예: google.com, akamaihd.net)
• 포트 번호: 80·443은 웹 트래픽, 22는 SSH 원격 접속이다.
• 연결 방향: 인바운드인가, 아웃바운드인가?

포토샵(Photoshop)이 adobe.com 서버의 443 포트로 연결하는 건 업데이트 확인이다. 정상이다. 반면 계산기(calc.exe)가 낯선 국가 IP 주소로 접속을 시도한다면 악성코드 감염을 의심하고 즉시 막아야 한다. 이 두 사례만 기억해도 판단이 훨씬 쉬워진다.

리눅스 환경의 선택지 — OpenSnitch

리눅스는 원래 netstat, ss, tcpdump 같은 커맨드라인 도구로 네트워크 연결 상태를 확인한다. 강력하긴 한데, 실시간으로 모든 연결 시도를 GUI로 제어하기엔 솔직히 불편하다. 리틀 스니치의 리눅스 버전, 그리고 오픈소스 프로젝트 ‘OpenSnitch’는 이 간극을 메워준다. 터미널이 낯선 사용자도 자기 리눅스 시스템에서 어떤 일이 벌어지는지 한눈에 파악하고 통제권을 쥘 수 있다.

결국 통제권의 문제다

네트워크 모니터링은 보안 기술이기도 하지만, 본질은 따로 있다. 내 컴퓨터가 내 허락 없이는 그 어떤 정보도 외부로 내보내지 않는다는 확신. 보이지 않던 연결이 화면에 드러나는 순간, 뭔가 달라지는 느낌이 있다. 디지털 주권이라고 거창하게 부를 수도 있겠지만 — 솔직히 그냥, 내 컴퓨터가 진짜 내 것이 되는 기분이다. 보이지 않는 연결을 가시화하고 제어하는 것, 그게 시작이다.

출처: The Verge