앱 공격의 세 가지 징후, 개발자가 알아야 함

앱은 공격을 받고 있습니다. 메릴랜드 대학의 연구 에 따르면 공격은 39초마다 놀라울 정도로 빈번하게 발생하며 성공 확률도 놀라울 정도로 높습니다.

이런 앱을 보호하는 데 점점 더 많은 부담을 지고 있는 개발자들은 이러한 위협을 잘 알고 있습니다. NodeSource와 Sqreen이 2017년 후반에 실시한 node.js 개발자 설문 조사에 따르면 "모든 응답자의 3분의 1 이상(34%)이 향후 6개월 내에 조직이 대규모 공격의 표적이 될 가능성이 높다고 믿는다"고 밝혔습니다. 공격의 86%에서 초기 공격 벡터가 애플리케이션 자체이거나 ID라는 우리의 조사 결과를 고려하면 그러한 믿음은 매우 타당합니다.

그런데 "응답자의 35%가 공격이 발생했을 때 이를 식별하는 방법을 잘 모른다 "는 사실을 알게 되면 불안해질 수도 있습니다. 그들은 그것이 나타날 것이라고 기대하지만 그것이 실제로 나타났을 때 그것을 인식하는 방법을 잘 모릅니다. 진행 중인 공격을 식별하는 방법을 모른다면, 공격을 막는 것은 매우 어렵습니다.

이로 인해 공격에 대비해 실시간 보호 수단을 전혀 사용하지 않는 Node.js 개발자가 23%에 달한다는 사실이 더욱 문제가 됩니다.

좋은 소식은 애플리케이션 제공 상태 에 대한 우리 자신의 연구를 기반으로 한다는 것입니다. 대부분의 조직에서는 공격에 대비해 일종의 실시간 보호 기능을 사용합니다. 5명 중 4명은 웹 애플리케이션 방화벽 (57%), 런타임 애플리케이션 자체 보호(11%), 사용자 행동 분석(26%)을 포함하여 두 개 이상의 기술을 사용합니다.

이러한 모든 기술이 공통적으로 갖고 있는 특징은 개발자에게 종종 부족한 것, 즉 가시성입니다. 공격을 탐지하고 (가능하면 식별하고) 하기 위해서는 비정상적인 동작을 인식할 수 있어야 하므로 가시성이 필요합니다.

애플리케이션과 서비스는 비교적 예측 가능한 사용 패턴을 가지고 있습니다. 예를 들어, SSO(Single Sign On) 애플리케이션은 월요일 아침에 많이 사용되고 금요일 오후에는 적게 사용되는 경향이 있습니다. 재무 관련 애플리케이션은 급여일, 과세 기간 종료, 회계 연도 마감 등 재무 관련 이벤트 직전에 많이 사용되는 경향이 있습니다.

소비자 대상 애플리케이션에도 예측 가능한 사용 패턴이 있으며, 이를 활용하여 비정상적이고 잠재적으로 위험한 동작을 감지할 수 있습니다. 예를 들어, 2017년 4월 Malauzai Software는 "435개 이상의 은행 및 신용 조합에서 수집한 사용 데이터, 730,000명의 활성 인터넷 및 모바일 뱅킹 사용자의 1,320만 로그인을 포함"을 기반으로 한 월별 "소규모 데이터" 보고서 를 발표했습니다. 그것에서 우리는 다음을 배웁니다. "최종 사용자의 100%가 잔액을 확인하고 최근 거래 내역을 검토합니다. 잔액과 최근 내역이 모든 사람이 볼 수 있도록 랜딩 페이지에 표시되기 때문입니다. 그리고 이것이 그들이 오는 이유입니다. 77%의 경우. 사용자가 하는 일의 77%는 잔액과 내역을 확인하는 것뿐입니다. 디지털 뱅킹에서 전체 상호작용의 23%만이 잔액과 내역을 넘어 다른 작업을 수행합니다."

그러므로 다른 유형의 거래에 대한 갑작스러운 관심은 공격의 징후일 수 있다고 추론할 수 있습니다.

안타깝게도 이러한 통계는 모든 응용프로그램에서 쉽게 사용할 수 있는 것은 아닙니다. 그렇기 때문에 가시성(모니터링)이 중요합니다. 이를 통해 이상 징후가 명백해지는 기준을 확립할 수 있습니다. 물론 모든 이상 현상이 공격을 나타내는 것은 아닙니다. 주중에 SSO 서비스 사용량이 급증하는 것은 회사 비밀번호를 변경해야 하는 마감일이 있거나, 월요일과 화요일이 공휴일이어서 사무실에 아무도 없었기 때문일 수 있습니다. 그래도 기준선을 정해 놓으면 공격이 진행 중이라는 것을 알려주는 행동을 식별하는 데 도움이 됩니다.

실제로 공격일 경우를 대비해 이러한 세 가지 비정상적인 사용 패턴을 꼭 확인하세요. 사실, 종종 그렇죠.

1. 연결의 극적인 증가 아마도 당신이 방금 바이러스처럼 퍼졌을 수도 있지만, 다른 일이 일어나고 있을 가능성이 큽니다. 연결 속도가 크게 증가하면 네트워크 트래픽도 그에 따라 증가하는지 즉시 확인하는 것이 좋습니다. 그렇지 않다면, 잠재적인 공격이기 때문에 스파이디 감각이 자극을 받아야 합니다. GET 플러드는 HTTP 기반 DDoS 공격 중에서 가장 쉽게 실행할 수 있는 공격입니다. 왜냐하면 이 공격은 애플리케이션에 엄청난 양의 HTTP GET을 뿌리는 것에만 의존하고 다른 것은 아무것도 하지 않기 때문입니다. 그들은 실제 URL에 액세스하려고 하지도 않는 경우가 많습니다. 그 이유는 가능한 한 많은 연결을 소비하고 과부하 상황에 빠지게 하는 것이 목적이기 때문입니다.

만약 증가가 로그인을 제공하는 URL이나 서비스를 특별히 타겟으로 한다면, 무차별 대입 공격을 받아 액세스 권한을 얻을 수 있습니다. 

지속적인 공격의 징후로 서버 오류, 점차 저하되는 성능, 리소스 고갈을 살펴보세요.

2. 아웃바운드 응답의 크기. 갑자기 큰 규모의 발신 응답은 공격자가 접근해서는 안 될 데이터에 접근한 성공적인 침출 공격의 징후일 수 있습니다. 이는 SQLi 공격이 성공했음을 알려주는 주요 위험 신호 중 하나입니다. 공격자는 종종 와일드카드를 사용하여 데이터에 대한 무단 액세스를 얻기 때문입니다. SQLi가 너무나 잘 알려진 공격 벡터라서 이제는 이 문제를 해결할 수 있을 것이라고 생각할 수도 있을 겁니다. 그러나 SQLi는 매년 수많은 업계 보고서에 따르면 가장 성공적인 공격 중 하나로 꼽힙니다.

기본적으로 이 공격은 데이터 접근 제한을 우회하도록 설계되었습니다. 따라서 단 하나의 레코드(심지어 몇 개만)를 수신하는 대신, 공격은 수천 개의 레코드 를 수신할 수 있습니다. 성공적인 공격은 반환되는 데이터 양이 일반적인 수준보다 훨씬 많기 때문에 눈에 띄게 나타날 것입니다.

응답 규모에 큰 차이가 있으면 즉각적인 조사가 필요합니다.

3. 충돌과 실패. 이러한 문제는 결함이나 실수로 '잘못된' 입력으로 설명될 수 있지만, 새로운(또는 오래된) 취약점을 악용하고자 타사 라이브러리나 웹 서버 플랫폼(또는 애플리케이션)에서 버퍼를 오버런시키려는 시도를 나타낼 수도 있습니다. 오늘날 시스템이 스스로를 '재시작'할 수 있는 것은 좋은 일이지만, 재시작이 필요한 이유를 무시하는 것도 좋은 일은 아닙니다 .

가끔씩 발생하는 충돌을 무시하고 싶을 수도 있지만 그렇게 하지 마십시오.

충돌과 오류를 무시하지 말고, 오류가 있는 시스템을 검토할 때까지 격리할 수 있는 아키텍처를 고려하세요.

물론 이것이 모든 것을 포괄하는 목록은 아니지만 애플리케이션이 공격을 받을 때 이를 식별하고 중단시키는 데 좋은 시작점이 됩니다.

안전히 계세요!