[지디넷코리아]최근 사이버보안 이슈로 떠오른 PHP2셸(PHP2shell) 취약점으로 국내외 인터넷 사이트, 서비스가 위험에 노출됐다. 악의적인 공격자가 해당 취약점을 악용하면 작동 중단, 데이터 탈취 등이 가능하다. 최근 서울 모처에서 만난 박세준 티오리 대표는 시스템, 서비스 사업자들은 어떤 서버에서 어떤 버전의 PHP를 사용하는지부터 파악하고, 취약점을 수정한 버전으로 업데이트할 것을 권고했다. 일반 이용자에겐 개인정보 유출 안내를 받았을 경우 비밀번호를 변경하고, 같은 비밀번호를 다른 사이트에서도 사용하고 있다면 함께 바꾸는 게 바람직하다고 말했다.다음은 지디넷코리아와 박세준 대표의 일문일답이다.-이름만 들어도 어려운데, PHP2셸은 무슨 뜻인가"PHP는 웹사이트의 서버에서 프로그램을 실행하는 데 사용하는 언어이고, 셸(shell)은 컴퓨터에 명령을 내리는 환경을 뜻한다. PHP2셸은 PHP의 취약점을 이용해 외부에서 서버에 명령을 실행할 수 있다는 의미다. 취약점을 발견한 연구진이 공격 시연 도구에 사용한 이름에서 비롯됐다. 정식으로 등록된 취약점은 CVE-2026-109618과 CVE-2026-109619 두 건이다. CVE는 각각의 보안 취약점을 구분하기 위해 부여하는 고유 번호다."-PHP가 무엇이고 이 결함에 당하면 시민과 기업에 어떤 일이 벌어지나"PHP는 웹사이트에서 로그인과 회원 정보 조회, 결제 등 서버 측 기능을 구현하는 데 널리 사용되는 프로그래밍 언어다. 워드프레스 같은 웹사이트 제작 도구에도 사용된다. 전 세계에서 서버 측 프로그래밍 언어를 식별할 수 있는 웹사이트의 약 70%가 PHP를 사용한다. 다만 PHP를 사용하는 웹사이트의 70%가 이번 취약점에 노출됐다는 뜻은 아니다.개별 웹사이트가 아니라 PHP 자체에서 발견됐다는 점에서 중요하다. 웹사이트를 안전하게 개발했더라도 그 아래에서 실행되는 PHP에 취약점이 있다면 영향을 받을 수 있다. 공격에 성공하면 서버에서 임의의 코드를 실행할 수 있고, 개인정보 유출이나 서비스 변조, 추가 침해로 이어질 수 있다. 다만 서버 전체를 무조건 장악할 수 있다는 뜻은 아니다. 실제 피해 범위는 서버 구성과 실행 권한에 따라 달라진다."-이번 취약점의 CVE 점수는 몇 점이고, 이 점수는 어떤 기준으로 매기나"정확히 말하면 CVE는 취약점을 식별하는 번호이고, 위험도를 평가하는 점수는 CVSS다. 이번에 발견된 두 취약점은 CVSS 4.0 기준으로 모두 9.2점을 받았다. 10점 만점이며, 9.0점 이상은 가장 높은 치명적(Critical) 등급에 해당한다.평가할 때는 인터넷을 통해 공격할 수 있는지, 공격에 필요한 권한이나 사전 조건이 있는지, 공격 과정이 얼마나 복잡한지 등을 고려한다. 공격에 성공했을 때 정보 유출과 변조, 서비스 중단 등 어떤 피해가 발생할 수 있는지도 반영한다. 다만 CVSS 점수가 실제 공격 성공률이나 피해 발생 확률을 의미하는 것은 아니다."-CVE 점수가 10점 만점이 아닌 9.2점인데, 그만큼 덜 위험하다는 뜻인가"9.2점과 10점은 모두 가장 높은 치명적 등급이지만, 기술적으로 완전히 같은 위험이라는 뜻은 아니다. 이번 취약점은 공격에 성공했을 때의 파급력이 크지만, 실제 공격을 성공시키는 과정에는 상당한 기술적 난도가 있다. 서버의 실행 환경이나 메모리 구조 등에 따라 공격 가능성이 달라지고, 특정 조건을 충족해야 하는 경우도 있다.실제로 취약점 공개 이후 많은 공격 시도가 관측됐지만, 공격을 시도하는 것과 실제 침해에 성공하는 것은 전혀 다른 문제다.그렇다고 안심할 수는 없다. 이미 취약점의 악용 가능성이 입증됐고 관련 기술도 공개되고 있어, 시간이 지날수록 공격 난도가 낮아질 수 있다. 기업 입장에서는 9.2점과 10점의 차이를 따지기보다 실제로 영향을 받는 시스템이 있는지 확인하고 신속하게 조치하는 것이 중요하다."-PHP로 사이트나 서비스를 운영하는 기업과 기관은 지금 무엇부터 해야 하나"가장 먼저 어떤 서버에서 어떤 버전의 PHP를 사용하는지 파악해야 한다. 기업이 직접 개발한 웹사이트뿐 아니라 외부 솔루션이나 내부 관리 시스템에 포함된 PHP도 확인할 필요가 있다.PHP 공식 프로젝트에서는 이번 취약점을 수정한 8.5.12, 8.4.27, 8.3.36, 8.2.35 버전을 배포했다. 해당 버전 이상으로 업데이트하거나 운영체제 및 솔루션 공급업체가 제공하는 보안 패치를 적용해야 한다. 패치 적용 후에는 실행 중인 프로세스에도 수정 사항이 반영되도록 필요한 재시작이나 재배포를 진행해야 한다. 지원이 종료된 구버전은 가능하면 지원 버전으로 이전해야 한다.패치와 침해 여부 확인은 별개다. 패치를 적용했다고 해서 이미 침해된 시스템이 복구되는 것은 아니다. 이상 접속 기록이나 의심스러운 파일 및 프로세스가 있는지 살펴보고, 침해 정황이 발견된다면 인증 정보 교체 등의 후속 조치를 진행해야 한다.더 근본적으로는 기업이 자신이 운영하는 시스템과 소프트웨어를 상시 파악하고 있어야 한다. 공격자는 인터넷에 노출된 서버를 자동으로 찾아 취약점을 시험하는데, 방어자는 자신이 어떤 서버를 운영하는지 파악하는 데 며칠씩 걸린다면 처음부터 불리한 싸움이다. 자산 파악부터 취약점 검증과 수정까지 지속적으로 수행할 수 있는 체계가 필요하다."-PHP2셸 사태에서 일반 시민이 이용자 입장에서 조심할 점은 무엇인가"이번 취약점은 개인의 컴퓨터나 휴대전화가 아니라 웹사이트를 운영하는 서버에 있는 문제다. 따라서 일반 이용자가 직접 설치해야 할 패치는 없다.이용하는 서비스에서 개인정보 유출이나 계정 탈취가 확인됐다는 안내를 받았다면 비밀번호를 변경하고, 같은 비밀번호를 다른 사이트에서도 사용하고 있다면 함께 바꾸는 것이 좋다. 중요한 계정에는 2단계 인증을 설정하는 것도 도움이 된다. 변조된 사이트가 가짜 화면으로 이끌 수 있어 낯선 링크는 누르지 않는다.다만 취약점이 발견됐다는 사실만으로 개인정보가 유출됐다고 생각할 필요는 없다. 취약점의 존재와 실제 침해 여부는 구분해야 한다. 이번 사태에서 우선적으로 대응해야 할 주체는 개별 이용자가 아니라 웹서비스를 운영하는 기업과 기관이다."-지금까지 이 취약점으로 해킹 피해를 본 곳이 있는지, 공격 시도는 얼마나 되나"공격 시도가 잇따르고 있는 것은 사실이다. 아마존은 공식 패치가 공개되기 전인 10월 17일부터 관련 공격 시도를 관측했고, 여러 보안업체에서도 유사한 활동을 보고했다.하지만 공격 시도가 관측됐다는 것과 실제 침해에 성공했다는 것은 구분해야 한다. 실제로 소포스와 팔로알토네트웍스는 처음에 공격 성공 사례를 발표했다가 추가 분석을 거쳐 정정하거나 철회했다. 특히 팔로알토네트웍스가 보고한 정부기관 침해 사례는 이번 PHP 취약점이 최초 침입에 사용됐는지 확인되지 않았다.최근에는 보안 연구자가 운영하는 허니팟에서 명령 실행에 성공한 사례가 보고되기도 했다. 그러나 공격에 유리하게 구성된 실험 환경에서의 성공과 실제 기업의 운영 환경을 침해하는 것은 차이가 있다. 알려진 공격 코드를 이용해 제한적인 환경에서 실행에 성공했다고 해서 일반적인 서버에서도 안정적으로 공격할 수 있다는 뜻은 아니다.10월 27일 현재 공개적으로 검증된 실제 기업이나 기관의 침해 피해 사례는 확인되지 않았다. 물론 알려지지 않은 피해가 있을 가능성까지 배제할 수는 없다. 중요한 건 공격 시도 건수와 실제 침해 사례를 혼동하지 않고, 확인된 사실에 근거해 위험을 평가하는 것이다."-취약점을 AI가 찾아냈다는데, 해커도 AI를 쓰면 앞으로 더 위험해지나"이번 취약점은 AI를 활용한 보안 연구가 얼마나 발전했는지를 보여주는 사례다. 문제의 뿌리가 되는 메모리 처리 결함은 과거에도 일부 발견됐지만, 실제 원격 코드 실행으로 이어질 수 있다는 점을 충분히 입증하지 못했다. 이번에는 여러 연구진이 AI를 활용해 구체적인 공격 가능성을 확인했다.그렇다고 AI가 혼자서 모든 과정을 해결했다고 이해해서는 안 된다. 실제 취약점을 분석하고 공격 가능성을 입증하는 과정에는 여전히 상당한 전문성과 검증이 필요하다.중요한 변화는 과거에 많은 시간과 전문 인력이 필요했던 보안 분석을 AI를 통해 훨씬 빠르고 저렴하게 수행할 수 있게 됐다는 점이다. 이는 방어자뿐 아니라 공격자에게도 똑같이 적용된다.다만 AI를 사용한다고 해서 모든 취약점을 즉시 쉽게 악용할 수 있는 것은 아니다. 이번 PHP2셸 역시 공격 시도와 관련 코드가 빠르게 확산됐지만, 실제 환경에서 안정적으로 동작하는 공격을 구현하는 것은 별개의 문제였다.장기적으로는 취약점을 발견하고 공격 가능성을 검증하는 데 드는 시간과 비용이 계속 낮아질 것이다. 공격자는 더 많은 시스템을 더 자주 시험할 수 있게 되는데, 방어자가 여전히 사람의 수작업에 의존한다면 속도를 따라가기 어렵다. 방어하는 쪽도 AI를 활용해 취약점 탐지부터 실제 공격 가능성 검증, 수정까지 자동화해야 한다."-취약점을 이용해 남의 서버에 보안 패치를 대신 깔아 주는 도구까지 나왔다는데"우선 해당 도구가 실제로 그런 기능을 수행할 수 있는지부터 확인해야 한다. GitHub에 코드가 공개됐다는 것과 실제 환경에서 정상적으로 동작한다는 것은 별개의 문제다.이번 취약점과 관련해서도 여러 공격 코드와 도구가 공개됐지만, 실제로는 제대로 작동하지 않거나 제한된 실험 환경에서만 동작하는 경우도 있다.남의 서버에 원격으로 패치를 설치하려면 먼저 그 서버에서 코드를 실행할 수 있어야 하고, 실제 파일을 수정할 수 있는 권한까지 확보해야 한다. 원격 코드 실행 취약점이 존재한다는 사실만으로 모든 서버에서 그런 작업이 가능한 것은 아니다.따라서 실제로 검증된 도구인지, 단순한 개념증명이나 서버 관리자를 위한 패치 스크립트인지부터 구분할 필요가 있다. 실효성이 확인되지 않은 도구를 마치 누구나 남의 서버에 침입해 패치를 설치할 수 있는 것처럼 소개하는 것은 적절하지 않다.물론 실제로 타인의 서버에 허락 없이 접속해 파일을 수정한다면 선의였더라도 법적 문제가 발생할 수 있다. 보안 패치 역시 시스템 운영자의 승인과 통제 아래 이뤄져야 한다."
Continue to ZDNet Korea →You are being forwarded in 6s — stay on this page