[260329][Theori] Xint로 구축한 안전한헬스케어 보안

Xint는 비즈니스 로직 취약점 식별에 강점을 가진 AI 기반 침투 테스트 솔루션. 

-이용자로부터 점검할 자산의 웹 서비스 주소와 서비스 이용에 필요한 인증 정보를 전달받아 공격자 관점에서 서비스의 보안을 점검, 이 과정에서 각 요청과 응답의 맥락을 파악하고 그에 맞는 공격 시나리오를 생성하여 취약점을 탐지.

 

헬스케어 산업군의 서비스를 점검하는 과정에서 환자의 개인 건강 정보(PHI, Protected Health Information)를 적절한 권한 없이 조회할 수 있는 취약점을 발견

-해당 서비스는 인증 기반 접근 제어와 병원 단위 데이터 분리를 적용하고 있었기 때문에, 취약점을 트리거하기 위해서는 시스템의 접근 제어 구조를 이해한 API 요청이 필요했음

 

이 게시글에서는, 실제 고객사의 사례를 익명화하여 재구성한 내용을 바탕으로, Xint가 도메인의 맥락을 파악하며 비즈니스 취약점을 탐색한 과정을 소개함.

 

<헬스케어 산업의 정보보안>

헬스케어 산업은 다루는 데이터의 민감도가 높아 서비스 운영 시 보안이 특히 중요

-환자의 진료 기록, 진단 결과 등은 개인의 민감한 정보

-유출 사고 발생 시 중대한 법적 책임과 비즈니스 리스크로 이어질 수 있음

국내에서도 개인정보 보호법과 의료법에 따라 환자 정보의 무단 접근과 유출은 엄격하게 규제되고 있음.

 

-최근 많은 보안 사고가 발생함에 따라, 정보 유출 사고의 비즈니스 리스크는 증가하는 추세임.

-국내의 경우, 침해사고 발생 시 징벌적 과징금의 상한을 매출액 기준 최대 3%에서 10%로 확대하는 개정안이 통과되기도 하였음

-헬스케어 서비스는 일반적인 대고객 서비스와 달리 정보 권한을 일괄적으로 관리하기 어렵다는 특징 있음.

-환자 정보에 대한 조회 권한을 부여하는 상황에서도, 의사가 본인의 환자가 아닌 다른 의사의 환자 기록을 열람하는 것이 기능적으로 허용되어야 하는 경우와 제한되어야 하는 경우가 공존할 수 있음

-따라서, 필요한 정보만을 최소한으로 제공할 수 있도록 권한을 적절하게 부여하기 위해서는 기능을 사용하는 맥락을 파악해야함.

 

헬스케어 서비스의 보안성을 점검하는 보안 도구는 서비스의 동작 원리를 파악하고, 맥락을 분석하여 정상 기능과 취약점을 구분해야 함.

 

<Xint의 취약점 발견 과정>

복잡한 권한 체계, 리소스 간 관계, 비즈니스 로직에 결합된 인가(Authorization) 정책에서 발생하는 취약점은 기존의 보안 도구들이 탐지하기 어려운 유형임. 

-Xint가 헬스케어 서비스에서 취약점을 식별한 과정을 살펴봄.

 

step 1: 인증 토큰 발급 및 의미 확인

Xint는 고객사로부터 취약점을 스캔할 대상 페이지와 인증 정보를 전달받은 후, 정보를 바탕으로 로그인을 수행하고, API 요청에 필요한 토큰을 발급받음.

발급된 JWT(JSON Web Token)의 페이로드에는 아래와 같은 claim이 포함되어 있었음.

{
  "sub": "1",
  "userId": 1,
  "hospital": 1,
  "role": "User",
  "token_type": "access"
}

Xint는 해당 정보를 통해 현재 인증된 이용자의 계정이 userId=1, hospital=1 임을 확인

 

step 2: 서비스 내 계정의 역할 파악

인증 토큰을 이용하여 의사의 프로필과 병원 내 의사 목록을 조회.

해당 요청들을 통해, 병원 내에 다른 의사들이 존재한다는 사실과, 각 의사들이 본인의 진료가 정보와 연결되어 있다는 것을 파악 가능.

또한, 현재 로그인한 계정이 병원 내 여러 의사 중 한 명의 계정(내과 소속 id=1 의사) 인 것을 확인 가능.

 

step 3: 다른 의사의 환자 목록 조회

로그인한 계정으로 접근할 수 있는 API 엔드포인트를 탐색하여, 병원 식별자(hospitalId) 와 의사식별자(doctorId)를 쿼리 파라미터로 사용하는 환자 목록 반환 엔트포인트(/hospital/patients-list)를 확인하였다.

-해당 엔드포인트가 의사가 소속 병원 내에서 자신에게 배정된 환자 목록을 조회할 수 있도록 지원한다고 판단.

-doctorId를 변조하여 다른 의사에게 배정된 환자 목록을 조회하는 시나리오를 테스트함.

 

테스트 결과, 환자 목록 반환 엔드포인트는 요청을 전송한 의사가 doctorId에 해당하는 의사와 일치하는지 검증하지 않음

-이는 다른 의사의 환자 목록을 조회할 수 있는 IDOR 취약점으로 이어짐.

 

doctorId를 포함하지 않은 요청을 환자 목록 반환 엔드포인트에 전송하여,

서버가 병원 내 모든 의사의 환자 목록을 응답으로 반환하는 것을 확인했음

 

또한, 응답 데이터는 환자를 식별할 수 있는 고유한 개인정보(ex. 연락처, 생년월일, 주민등로번호)가 포함되어 있었음

- page 파라미터를 조절하는 방식으로 병원 내 환자 목록을 조회하여 취약점의 영향력을 파악

-결과적으로 특정 의사의 계정(권한)으로 병원 내 전체 환자의 개인정보에 접근 가능한 상태임을 확인함.

 

step 4-1: 환자의 의사 방문 이력 조회

이후, step3에서 획득한 환자 식별자를 이용한 요청을 통해, 

-해당 환자가 만난 의사가 로그인한 계정의 의사가 아닌 다른 의사임을 확인.

-또한, 현재 인증된 의사는 내과 소속이지만, doctorId=2 의 의사는 신경과 소속이라는 정보를 바탕으로, 진료과 간 데이터가 격리되지 않는다는 정보를 추론함.

 

정보 조회 권한을 확인하기 위해 다른 환자 식별자에 대한 검증을 추가로 진행.

서버가 환자에게 배정된 의사와 무관하게 동일한 응답을 반환한다는 것을 확인

 

서버가 요청자의 의사ID와 환자 담당 의사의 ID를 비교하지 않는다는 사실을 확인.

해당 상황을 다른 의사의 환자 정보를 조회할 수 있는 IDOR 취약점을 분류함.

 

step 4-2: 환자 진료 기록 조회

step 3에서 획득한 환자 식별자를 이용하여 환자 진료 기록 조회 엔드포인트에 요청을 전송하였음.

status 200 메시지와 함께 응답 반환됨.

-진료 기록에는 단순 방문이력외에도, 환자가 입력한 증상에 대한 내용과 현재 진료의 진행 상태가 포함되어 있었음

 

step 4-1과 동일한 방식으로 다른 의사에게 배정된 환자의 진료 기록에 접근 시도,

-모든 요청에서 정상적으로 환자의 진료 기록이 반환되는 것을 확인.

 

진료 기록에서 획득한 정보 중, record-id를 사용하여 진료 녹음 파일에 접근을 시도.

-엔드포인트는 진료 녹음 파일을 응답으로 반환

-응답에 포함된 진료 녹음 파일의 주소(downloadUrl)에 접근할 경우, 파일을 다운로드 하는 것도 가능.

 

-병원 내의 모든 의사가 임의의 환자와 의사 사이의 진료 녹음 정보에 접근 가능하다는 것을 의미.

-진료 녹음을 기반으로 구성된 대화 내역(진료 내역) 조회 엔드포인트를 발견, 열람 가능한 정보 확인을 위해 요청 전송함.

-진료 녹음 기반으로 생성된 진료 내용 요약 확인 가능

-추가 요청 전송 결과 해당 엔드포인트에서도 다른 의사의 환자 정보(환자 진료 내용 요약)를 조회할 수 있는 취약점 확인.

 

이번 단계에서는, 환자의 진료 기록과 관련된 엔드포인트를 탐색.

-탐색 과정의 응답에서 획득한 정보를 기반으로 추가 요청을 구성하며 접근 가능한 API 와 조회 가능한 정보를 확보해나갔음

-그 결과, 특정 의사의 계정(권한)으로 병원 내 모든 환자의 진료 기록 및 진료 녹음 데이터에 접근할 수 있는 상태임을 확인

 

 step 5: 타 병원 환자 정보 조회 시도

접근 가능한 정보의 범위 파악을 위해 다른 병원의 환자 정보를 조회하는 위협 시나리오를 생성

-hospitalId 를 변조하여 계정이 소속되지 않은 다른 병원의 정보에 대한 접근을 시도한 결과는 아래와 같음.

Request
GET /hospital/patients-list?hospitalId=2&page=0
Authorization: Bearer <access-token>

Response
Status 200
{ "data": [] }

 

응답으로 status 200 메세지 반환.

다른 병원의 환자 목록에 대해서는 빈 배열이 반환

-병원 간의 데이터 격리가 적용

-계정의 hospitalId를 기반으로 병원 레벨의 접근 제어가 이루어지고 있었음

 

 

마무리

헬스케어 서비스에는 의사가 진료를 위해 다른 의사에게 배정된 환자의 정보에 접근해야 하는 상황 존재하지만,

스캔 결과 필수적이지 않은 상황에서 다른 환자의 정보를 조회할 수 있는 취약점 다수 발견.

 

비즈니스 로직 취약점은 기존의 DAST(Dynamic Application Security Testing) 도구로 탐지하기 어려움.

-단일 요청 단위에서 정상적인 API 호출에 해당되기 때문에, 실질적인 취약점 검증을 위해서는 여러 요청 간의 관계와 맥락을 함께 고려해야 함.

 

서비스의 복잡성이 높아질수록, 취약점은 단일 지점이 아닌 기능 간 연결과 흐름속에 발생함.

-AI를 기반으로 엔드포인트 검증의 한꼐 극복 가능.

-비즈니스 로직의 경계를 명확히 파악하여 서비스의 맥락을 기반으로 현실의 취약점을 명확히 식별할 수 있도록 지원함.