[ad_1]
ServiceNow는 인증되지 않은 공격자가 조직의 중요한 파일을 훔칠 수 있는 방법을 연구원이 발표한 후 데이터를 노출시키는 결함에 대한 수정 사항을 발표했습니다.
보안 연구원인 Aaron Costello는 ServiceNow 위젯의 기본 구성에서 개인 데이터가 노출될 수 있는 명백한 문제를 강조했습니다.
ServiceNow의 위젯은 플랫폼의 서비스 포털을 위한 강력한 API 역할을 합니다. 올해 초 안전성을 높이기 위한 코드 변경에도 불구하고 이러한 위젯의 기본 구성은 기록을 공개로 설정하는 것이었습니다. 즉, 변경하지 않은 채로 두면 공격자가 지정하는 데이터 유형을 반환하게 됩니다.
ServiceNow는 10월 20일 조용히 수정 사항을 발표하기 전에 다음과 같이 말했습니다. 레지스터 “잠재적인 잘못된 구성 문제”를 설명하는 연구를 알고 있었습니다. 그러나 어떤 변경 사항도 적용할 것이라고는 밝히지 않았으며 고객과 정기적으로 협력하여 각 조직에 보안 구성이 적절하게 구현되도록 한다고 덧붙였습니다.
대변인은 “우리는 액세스 제어 목록(ACL)을 포함한 보안 구성의 지속적인 안전을 위해 고객과 적극적으로 협력하여 ACL이 적절하게 구성되고 의도된 목적에 맞게 조정되도록 보장합니다”라고 말했습니다.
“우리는 이러한 프로토콜을 확장 가능하게 만들어 고객이 정보에 대한 광범위한 액세스를 제공하는 공용 포털이 있는 회사부터 일부 사용자에게 액세스가 제한되는 기업별 사용 사례에 이르기까지 고유한 보안 요구 사항에 따라 프로토콜을 구성할 수 있도록 합니다.”
데이터가 노출되는 방식
이 문제는 플랫폼 전체에서 광범위하게 사용되는 ServiceNow의 위젯과 관련이 있습니다.
많은 등록 독자들은 위젯이 사용자로부터 입력 매개변수(테이블 이름 및 필드 이름)를 받을 수 있는 API와 같다는 것을 알고 있습니다. 테이블은 사용자 데이터와 같이 저장되는 데이터 유형과 유사하며, 필드 이름은 이름과 같이 해당 테이블 내의 필드를 나타냅니다. 특정 테이블 및 필드 이름을 위젯 호출에 전달하면 인증되지 않은 사용자가 원하는 데이터를 검색할 수 있습니다.
ACL(액세스 제어 목록)은 테이블과 같은 ServiceNow 내의 리소스에 대한 액세스를 제어하지만 위젯 자체는 제어하지 않습니다. 여기에는 역할, 조건 및 스크립트에 대한 세 부분으로 구성된 검사가 있습니다. 지정된 리소스에 대한 ACL이 존재하지 않는 경우 기본 구현은 액세스를 거부하는 것입니다. 그러나 리소스에 세 가지 검사가 각각 “비어 있는” ACL이 있는 경우 액세스 시도는 true로 확인됩니다.
Costello는 자신의 연구에서 ServiceNow에서 사용되는 많은 ACL이 비어 있다고 제안했습니다. 즉, 세 가지 검사가 비어 있으므로 잠재적인 공격자에게 액세스 권한이 부여됩니다.
그의 연구에서 예로 사용된 Costello 위젯은 Simple List이며, 이 위젯의 기능은 테이블 및 필드 이름이 제공될 때 레코드 데이터를 반환하는 것입니다.
그의 연구 결과에 따르면 이러한 잘못된 구성을 이용하려는 공격자는 ServiceNow 인스턴스를 대상으로 하고 일련의 알려진 테이블 및 필드 이름을 반복하고 지속적으로 위젯을 호출하여 데이터가 반환되었는지 확인하는 스크립트를 작성함으로써 그렇게 할 수 있다는 것이 밝혀졌습니다.
성명, 이메일 주소와 같은 개인 식별 정보(PII)는 이 방법을 사용하여 연구자들이 검색한 데이터 중 하나입니다. 내부 문서와 사건 세부 정보도 검색되었습니다. 다른 사람.
Costello는 데이터 도난 시도에서 이러한 잘못된 구성을 악용하려는 시도를 감지하지 못했습니다. 그러나 그는 2021년에야 추적을 시작했으며 Simple List 위젯이 플랫폼에 추가된 2015년부터 잘못된 구성이 진행되어 과거 시도를 확인하기가 매우 어려울 것이라고 강조했습니다.
Costello는 자신의 글에서 “ServiceNow와 Salesforce뿐만 아니라 다른 인기 있는 SaaS 애플리케이션 전반에 걸쳐 거의 동일한 벡터가 존재한다는 것은 추측이 아니라 제가 알고 있는 것입니다.”라고 말했습니다.
2023년 3월 3일, ServiceNow는 공용 역할이 ACL에 명시적으로 적용되었는지 확인하는 리소스를 처음으로 조정했습니다. 그렇지 않은 경우 액세스가 거부됩니다. Costello는 리소스를 공개하는 다른 방법이 있기 때문에 이것이 충분하지 않다고 제안했습니다.
Costello는 “우리는 ACL의 역할, 조건 및 스크립트 부분을 충족해야 한다는 것을 알고 있습니다.”라고 말했습니다. “‘공개’가 ACL의 역할로 정의되지 않은 경우 인증되지 않은 사용자가 여전히 조건이나 스크립트 부분을 전달하여 액세스 권한을 부여받을 수 있습니다.
“ACL에 정의된 역할, 조건 또는 스크립트가 전혀 없어 인증되지 않은 사용자가 리소스에 액세스할 수 있을 가능성이 더 높습니다.”
연구원은 ServiceNow가 영향을 받는 구성 요소에 대한 공개 문서를 가지고 있지 않다는 점을 강조하고 싶었습니다.
그는 또한 3월에 초기 수정 사항을 발표함으로써 ServiceNow가 문제에 대해 알고 있음을 입증했지만 잠재적인 데이터 노출에 대해 고객에게 알리는 연락은 거의 하지 않았다고 제안했습니다.
그는 “올해 수정을 통해 입증된 것처럼 이 위젯 재앙이 공급업체에 의해 알려졌음에도 불구하고 2015년부터 공개된 문서 없이 존재했다는 사실은 끔찍하다”고 말했다.
회사가 문제를 조사하고 있음을 알리는 최근 공개된 ServiceNow 지원 페이지가 있지만 그에 따른 고객 커뮤니케이션은 고객 전용 기술 자료(KB) 문서로 제한되었습니다.
지난 주 연구가 주목을 받기 시작한 후 ServiceNow는 모든 빈 ACL이 기본적으로 공개 액세스를 허용하지 않도록 설정하는 문제에 대한 두 번째 수정 사항을 조용히 출시했습니다.
이는 비공개 KB 기사에서 발표되었습니다. 레지스터사용자가 로그인한 경우에만 액세스 권한이 부여되도록 보장하는 스크립트를 추가하기 위해 모든 빈 ACL에 업데이트가 적용되었습니다.
회사는 이것이 무단 액세스 시도를 완화하는 데 큰 도움이 될 것이라고 생각하면서 ServiceNow에서 사용되는 모든 ACL에 대한 역할, 조건 및 스크립트 검사를 정의할 것을 권장했습니다.
또한 업데이트가 무단 사용자가 의도적으로 특정 리소스에 액세스하도록 허용한 고객의 인스턴스에 영향을 미칠 수 있다고 경고했습니다. 이러한 경우 고객은 업데이트로 각 ACL에 추가된 스크립트를 제거하고 공용 역할을 수동으로 활성화하거나 테이블 및 필드에 대한 새 ACL을 생성하고 해당 역할을 “공용”으로 설정해야 합니다.
공개 액세스가 필요한 모든 테이블의 경우, 고객은 ACL이 공개 액세스를 허용하는 행 수를 줄이는 것을 고려할 것을 촉구했습니다. 이는 스크립트를 추가하고 이를 필요로 하는 특정 필드에만 공개 역할을 적용하여 수행할 수 있습니다. .
또한 필요하지 않은 “공개” 플래그가 있는지 위젯을 검토해야 하며, 외부 액세스가 전혀 필요하지 않은 경우 IP 액세스 제어를 ServiceNow 인스턴스에 적용하여 신뢰할 수 있는 IP 주소만 허용해야 합니다. ®
