웹 애플리케이션이 해킹됐을 때’ 5가지 징후와 대응 방안

웹 애플리케이션으로 소비자가 기업을 처음으로 접하는 경우가 많다. 때문에 웹 애플리케이션은 그 기업의 얼굴이다. 하지만 이 앱은 외부에 공개돼 있기 때문에 취약점이 되기도 한다.

대부분의 웹 애플리케이션 공격은 은밀해서 포착하기 어렵다. 버라이즌의 2015년 데이터 침해 사고 보고서(Data Breach Investigations Report)에 따르면, 해커들은 네트워크에 침입한 후 평균 205일 동안 숨어 있는다. 그리고 바로 이 부분이 문제다. 법 집행 기관이나 화가 난 고객에게 연락을 받고 나서야, 누군가 기업 네트워크 환경을 침해했다는 사실을 알아채기 때문이다.

그렇다면 웹 애플리케이션이 해킹 당했는지 알 수 있는 방법이 있을까? 인포메이션 시큐리티 포럼(Information Security Forum)의 매니징 디렉터 스티브 더빈은 “웹 애플리케이션이 해킹 당하면 이상 행동이 감지되기 시작한다”고 밝혔다. 따라서 애플리케이션의 정상 행동이 뭔지 철저히 파악한 후, 이상 행동에 주의를 기울이는 것이 아주 중요하다.

다음은 애플리케이션이 감염됐음을 알려주는 5가지 징후다. 여기에 웹 애플리케이션 보안에서 ‘일반 상식’이나 다름 없는 조언 몇 가지를 덧붙였다.

징후 1: 애플리케이션이 해야 할 일을 하지 않는다
애플리케이션에 의심스러운 일이 발생했는지 알아채는 가장 좋은 방법 중 하나는 모니터링이다.

예를 들어, 데이터베이스에서 결과를 가져오는데 과거보다 더 많은 시간이 걸리는 현상이 발생할 수 있다. 예기치 않은 때 페이지를 표시하고, 사용자를 다른 페이지로 인도하는 현상도 있다. 또 트래픽을 폭증시킬 마케팅 활동이 없었음에도 트래픽이 증가한다. 하루 평균 주문량이 50건인 작은 인터넷 상점의 주문량이 갑자기 5,000건으로 증가하는 현상도 있다.

물론 웹 애플리케이션 감염과 상관 없이 이런 현상이 발생할 수 있다. 예를 들어, 디도스 공격을 포함해, 일시적으로 인터넷 연결에 문제가 발생해 페이지 로딩 시간이 지연될 수 있다. 이 경우, 큰 피해가 닥치기 전에 당장 조사를 시작하는 것이 좋다.

애플리케이션이 사용자를 다른 페이지로 보내는 이유를 찾아야 한다. 악성 광고가 페이지 기능을 방해하고 있을 수 있다. 최근 페이지 코드를 수정했을 수 있다. 데이터베이스의 정보가 조작되어 있을 수 있다. 실제 사용 환경에서 애플리케이션을 조사해 정상적인 행동을 파악해야 한다. 그래야 이상 행동을 식별한 즉시 조사에 들어갈 수 있다.

징후 2: 예기치 않은 로그 메시지가 발견된다
로그는 제대로 설정만 한다면 정보의 보고 역할을 한다. 데이터베이스 로그를 자세히 조사하면 예기치 않은 쿼리나 정보가 들어온 시점을 알 수 있다. 데이터베이스 로그에 단기간 동안 여러 차례 오류가 기록되어 있다면, 누군가 SQL 주입 공격의 표적이 될 애플리케이션을 찾고 있거나, 이미 찾았다는 신호다. 데이터베이스 쿼리가 시작된 장소를 추적하고, 애플리케이션이 인풋(input)을 올바르게 처리했는지 확인한다.

웹 서버 소프트웨어는 시스템 FTP와 HTTP 로그를 통해 인바운드와 아웃바운드 네트워크 연결을 로그로 기록한다 (이 기능이 활성화되어 있어야 함). 이 로그는 승인되지 않은 행위, 악성 행위를 경고하는 신호를 제공한다.

웹 서버는 보통 내부 데이터베이스와 연결된다. 웹 서버에 공공 IP 주소로 연결된 아웃바운드 네트워크 연결이 있다면, 그 이유를 파악해야 한다. 이유 없는 파일 전송은 웹 서버에서 데이터가 유출됐음을 알려준다. 해커가 애플리케이션에서 데이터를 탈취했거나, 원격 서버로 콘텐츠를 전송하고 있음을 알려주는 단서다.

네트워크 외부의 현상에 너무 집중해 내부의 움직임을 경시하는 우를 범해서는 안 된다. 웹 서버가 사용자 파일 공유, 개별 컴퓨터 등 다른 내부 네트워크 자원과 통신하는 것이 공격자 이미 접근 권한을 획득해 네트워크를 돌아다니고 있다는 신호일 수도 있다. 사용자가 파일을 업로드 할 수 있는 애플리케이션이라면, 기업 내부에서 이용하는 서버 대신 전용 파일 서버를 사용해야 한다.

애플리케이션 로그는 서버 로그처럼 올바르게 설정해 모니터링 하고 있다면, 문제가 발생한 때를 알려준다. 애플리케이션 로그에는 사용자 또는 다른 관리자 계정 생성 등 관리자 권한의 작업이 기록돼야 한다. 애플리케이션이 관리자 등 특수 권한의 계정을 생성했다면, 해커가 그 계정을 생성한 것은 아닌지 확인한다.

또 관리자가 웹 애플리케이션에 로그인 한 시간을 알아야 한다. 그래야 로그인 시간과 위치를 기준으로 접근 상태를 정기 점검할 수 있다. 관리자 계정으로 수행된 작업도 확인한다. 웹 애플리케이션의 관리자 계정 작업이 설명되지 않는 작업이라면 침해가 발생했음을 알리는 강력한 신호다.

웹 페이지 로딩 시 관련 오류 건수가 늘어났다면, 애플리케이션이 이상 행동을 하고 있다는 신호다. 오류가 증가한 경우, 오류를 촉발한 페이지를 찾아 변경된 부분이 있는지 찾는다.

징후 3: 생소한 프로세스, 사용자, 작업이 발견된다
웹 서버에서 실행되는 프로세스를 모니터링, 서버에 알려지지 않은 프로세스가 실행되고 있거나, 알려진 프로세스가 이례적인 시간대에 실행되고 있는지 확인한다. 알려지지 않은 프로세스는 애플리케이션이 통제권을 벗어났음을 알려주는 단서다.

공격자가 서버에 계정을 생성하면 못하는 일이 거의 없다. 따라서 고급 권한을 가진 사용자를 중심으로 사용자가 생성됐는지 정기적으로 감시해야 한다. 통상 계정은 무작위로 생성되지 않는다. 따라서 계정이 생성될 때마다 모니터링을 해야 한다. 고급 권한이나 루트 권한이 없는 특정 사용자가 이런 권한을 요청한 경우, 공격자가 탈취한 계정 정보를 이용하고 있는지 의심해야 한다.

리눅스 서버의 크론탭(Crontab)이나 윈도우 서버의 예정된 작업을 조사하고, 정상적인 현상을 이해하는 습관을 들여야 한다. 새로운 작업이 추가돼 애플리케이션이 예상을 벗어나 작동할 수 있다. 임시 유지관리 작업일 수도 있다. 그러나 이와 동시에 공격자가 C&C 서버에서 새 명령을 호출하려는 시도일 수도 있다. 또 공격자가 탈취한 데이터를 작게 쪼개 원격 서버에 전송하는 것일 수도 있다.

징후 4: 파일이 변경되어 있다
웹 애플리케이션 타임스탬프를 확인하니, 몇 년 전에 변경했던 파일이 최근 수정되었음을 발견할 수 있다. 웹 서버를 잘못 설정하거나 애플리케이션에 취약점이 있다면, 공격자가 애플리케이션을 수정해 자산의 악성코드를 실행시킬 수 있다. 자바스크립트를 주입하거나, 모듈을 수정하는 방식이다. 파일이 승인 없이 수정됐는지 타임스탬프를 확인한다. 파일이 변경되어 있다면, 앞서 버전과 비교해 변경된 부분을 찾는다.

서버 유틸리티로 애플리케이션을 스캔해 악성코드를 찾을 수 있다. 정기적으로 유틸리티를 실행시켜, 승인 없는 변경을 찾는다(Sucuri가 이런 유틸리티임).

웹 서버에 정상적인 용도가 아닌 새로운 파일이 다수 생성되어 있을 수 있다. 웹 루트에 새 파일이 있다면 문제가 될 수 있다. 특히 스크립트와 기타 실행 파일이 위험하다. 웹 루트에 파일을 추가할 때는 이를 꼼꼼하게 문서로 남겨놔야 한다. 웹 루트 등의 장소에서 새 파일을 발견했다면, 침해가 발생한 것이다. 공격자가 애플리케이션을 악용, 이를 인식하지 못한 사이트 방문자에게 악성코드를 배포하거나, 다른 장소로 유도할 수 있다. 또는 수집한 데이터가 들어있는 텍스트 파일일 가능성도 있다.

공격자가 새 디렉토리를 생성해, 자신의 애플리케이션을 설치한 사례들이 있다. 웹 애플리케이션 대신, 도메인과 서버를 이용해 자신의 툴을 실행시킨다.

애플리케이션에 써드파티 플러그인이 사용되고 있다면, 경고 없이 플러그인이 업데이트되거나 설치되는지 확인한다. 사이트에 도움이 될 것이라는 생각이 든다는 이유로 무조건 플러그인을 설치하는 행위를 삼간다. 플러그인으로 인해 사이트에 악성 기능이 설치되지 않는지 테스트해야 한다. 화이트햇시큐리티(White Hat Security) 등이 개발한 스캐닝 툴로 잠재적인 공격 코드를 찾을 수 있다.

징후 5: 경고를 받는다
애플리케이션이 감염되어 악성코드 배포에 악용되고 있다면, 다른 보안 툴이 이를 포착할 가능성이 높다. 구글의 경우 크롬 사용자에게 나쁜 평가를 받는 페이지를 재빨리 차단하는 것도 바로 이 때문이다. 다른 브라우저도 주기적으로 블랙리스트를 업데이트한다. 다른 브라우저를 이용해 이런 메시지가 있는지 애플리케이션을 확인한다. 또는 구글의 세이프 브라우징(Safe Browsing) 툴을 이용한다.

또 소셜미디어와 헬프데스크의 이메일에 사용자가 제기한 불평불만이 있는지 확인한다. 사용자에게 보낸 비밀번호 재설정 이메일이 스팸메일로 분류되었다면, 애플리케이션이 스팸에 악용되고 있는지 조사해야 한다.

주의 사항: 웹 애플리케이션에도 보안 위생을 적용한다
문제를 발견하면 애플리케이션과 서버를 백업, 포렌직 조사를 실시할 수 있다. 백업에서 복구할 경우, 클린 카피를 이용해야 한다. 그래야 악성코드가 다시 설치되는 문제를 방지할 수 있다. 감염된 파일을 찾아 깨끗한 파일로 바꾼다. 이를 위해서는 정기적으로 백업을 수행해야 한다.

애플리케이션을 복구하고 불필요한 파일을 삭제한 후, CMS와 관리자 계정, 기타 개별 서비스의 비밀번호를 모두 바꿔야 한다. 가능하다면 이중 인증 기술을 이용한다. 불가능한 곳에는 VPN을 설정한다. 이렇게 하면 애플리케이션을 안전하게 만들고, 공격자의 재침입을 막을 수 있다.

애플리케이션을 강화해야 한다. 불필요한 쓰기 권한을 없앤다. 기본 비밀번호는 절대 사용하지 않는다. 디렉토리 경로를 추측하기 어렵도록 만드는 것이 좋다. PHP 애플리케이션의 경우, phip.ini 파일을 이용해 안전하게 만들 수 있다. 보안 스캐너는 애플리케이션에 알려진 보안 취약점이 있는지 점검한다.

개인 노트북 컴퓨터, 업무용 노트북 컴퓨터에는 안티바이러스 소프트웨어를 사용하고, 프로그램을 다운로드 받을 때 주의를 기울인다. 그리고 정기적으로 운영 시스템과 써드파티 소프트웨어를 업데이트한다. 이는 웹 서버와 애플리케이션에도 그대로 적용되는 원칙이다. 정기적으로 써드파티 애플리케이션을 업데이트, 취약점을 패칭한다. 최신 서버용 안티바이러스 툴은 공개된 웹 쉘(Shell) 대부분과 서버에 설치된 악성코드를 감지한다.

어느 경우든 애플리케이션을 복구하면서 공격자가 침입에 악용할 수 있는 취약점을 없애야 한다. 최후의 방편으로 서버를 다시 구축한 후, 애플리케이션을 설치할 수 있다. 최신의 깨끗한 백업이 없는 경우 유일한 방법이다. 그러나 가장 먼저 할 일은 공격자가 침입한 신호가 있는지 정기적으로 점검하는 것이다.

dl-ciokorea@foundryco.com