제품문의

02-6011-1377

보안관제센터

02-6011-2337

FAX

02-463-1376

E-mail

iamguide
@cmtinfo.co.kr

보안공지

공지사항

드루팔 취약점 공략하는 해커들, 속도 훨씬 빨라졌다

페이지 정보

작성자 최고관리자 작성일18-05-07 19:57 댓글0건

본문

최근 드루팔(Drupal)에서 원격 코드 취약점이 발견됐다. 그래서 지난 주 수요일 드루팔 측은 비정기 보안 패치를 재빨리 발표했다. 취약점인 CVE-2018-7602의 위험 잠재력이 높았기 때문이다. 이 취약점은 CVE-2018-7600이라는 취약점의 3월 패치가 가진 불완전성 때문에 발생한 것이었다. 
 


그러면서 드루팔 측은 웹사이트 관리자 및 운영자들에게 “패치를 빨리 적용해야 한다”고 권고했다. 특히 드루팔 7과 드루팔 8 사용자들에게는 더 시급한 문제라고 강조했다. 7.x 버전 사용자는 7.59로, 8.5.x 사용자는 8.5.3으로, 8.4.x 사용자는 8.4.8로 업그레이드 하라는 안내가 드루팔 편에서 나왔다. 

그런데 이러한 안내문과 다급한 경고문이 나온 지 겨우 수 시간 만에 해커들의 공격이 나타나기 시작했다. 이 취약점을 익스플로잇 해 암호화폐를 심거나 디도스 공격에 활용할 수 있을지 시험해보는 움직임이 많았다. 드루팔이 해결책을 광고하고 거의 곧바로, 그러니까 사용자들이 드루팔의 경고를 듣고 조치를 취하기 훨씬 전에 공격자들이 움직인 것이다. 덕분에 세계 곳곳의 호스트 시스템들이 위협에 노출되었다.

해커들이 아무리 빨리 움직인다지만 지난 3월 드루팔에서 취약점이 발견되었을 때와는 상당한 차이가 있었다. 당시 CVE-2018-7600 취약점이 공개되고 약 2주 후에서야 첫 번째 실제 공격이 발생했었다. 3월 한 달 동안 이 취약점을 공략한 해커들의 활동양도 굉장히 낮았다. 그래서 보안 업체 임퍼바(Imperva)는 “해커들이 요즘 게을러지고 있나?”라는 의문을 갖기도 했다.

“그때는 2주 걸렸고, 지금은 24시간도 걸리지 않았습니다.” 임퍼바의 보안 분석가인 코비 킬림닉(Koby Kilimnik)의 설명이다. “3월 한 달 동안 드루팔 취약점 공략법을 익히고 4월에 또 다른 취약점이 등장하자마자 실력을 발휘한 듯 합니다.”

보안 업체 리스크IQ(RiskIQ)의 수석 제품 관리자인 스티브 긴티(Steve Ginty)는 “드루팔에서 두 달 연속 취약점이 나왔고, 이에 대해 공격자들이 보란 듯이 빠르게 움직였다는 건, 조직들이 공격 표면을 줄이고 패치를 적용하는 속도가 상대적으로 얼마나 느린지를 드러낸다”고 분석한다. 

“더 빨리 움직이려면 취약한 자산이 무엇인지를 알고 있어야 합니다. 이번과 같은 경우 드루팔에 기반을 둔 시스템들이었겠죠. 서드파티가 관리하는 데이터나 툴들도 마찬가지고요. 뭐가 어떤 위험에 약한지를 알고 있어야 실제 사건이 터질 때 우선순위를 두고 움직일 수 있게 됩니다. 호환성 문제 등으로 패치 적용이 어렵다고 해도, 이런 식의 가시성을 확보해두고 있어야 중요한 결정을 제 시간에 내릴 수 있습니다.” 긴티의 설명이다. 

해커들의 움직임이 더 빨라지고 있다는 건 여러 기업들이 긴장감을 가지고 접해야 하는 소식이다. 특히 패치를 개발하는 회사와 이를 받아서 적용해야 하는 사용자 기업은 이것이 큰 압박으로 작용할 수밖에 없다. “잘못된 패치 한 번이 엄청난 공격 시도를 유발했죠. 패치로 문제를 해결해야 하는데, 도리어 문제를 일으킨 꼴이 됐습니다.”

또한 충분한 실험을 거친 후에 패치를 적용해보고 싶어하는 기업들의 문화도 문제가 될 수 있다고 긴티는 지적한다. “그렇기 때문에 패치가 나와도 몇 달 후에나 적용이 됩니다. 기업의 크기 혹은 패치의 크기에 따라 이 기간이 더 늘어날 수도 있고요. 물론 안전을 위해서는 나쁘지 않은 방식입니다만 이번 드루팔 사태 때 봤던 것처럼 해커들이 빨리 움직인다면 오히려 위험을 불러들이는 방식일 수 있습니다.”

보안 업체 플릭서(Plixer)의 감사 및 컴플라이언스 책임자인 저스틴 젯(Justin Jett)은 “보안 패치 소식을 실시간으로 접하고, 최대한 빨리 반영하면서도 호환성 문제를 일으키지 않게 하는 건 IT 담당자들에게 있어 가장 어려운 숙제 중 하나”라고 말한다. “하지만 드루팔의 패치 같은 경우 핵심 기능에 대한 변화는 없고 주변적인 것들만 고친 것이라 패치 리스크가 적었습니다.”

그러니 소프트웨어나 패치에 따라 시험 기간을 유동성 있게 늘렸다 줄였다 할 수 있지 않겠느냐는 것이 그의 제안이다. “사무실에서 모든 직원들이 사용하는 주요 소프트웨어라면, 아마도 테스트를 충분히 하고 나서 패치를 적용하는 게 나을 수 있습니다. 만에 하나 패치가 잘못 됐다면 더 큰 피해가 발생할 수 있으니까요. 하지만 그렇게까지 하지 않아도 되는 패치들도 분명히 있으니, 그런 점들을 고려하는 것이 필요합니다.”

또한 패치에만 의존하는 것도 좋은 보안 습관은 아니라고 킬림닉은 말한다. “개발사 입장에서는 패치를 빨리 내는 게 굉장히 중요하거든요. 즉 서두를 수밖에 없는 사정일 때가 많다는 겁니다. 개발사라고 모든 걸 완벽하게 만들지 않아요. 담당자가 압박감 속에 일을 급하게 하면 실수가 나오기 마련입니다. 그러니 패치 외에도 리스크를 줄일 수 있는 다른 방법들을 미리 마련하고 정착시키는 것이 중요합니다.”