기술 지원
문서
로그인
문의하기
취약점 뒤에 숨겨진 버그 - 1부
조아오 코레이아
2022년 10월 31일 기술 에반젤리스트
새로운 취약점과 익스플로잇에 대한 소식은 흔히 들을 수 있으며, 그 중 일부는 멋진 이름을 갖기도 하지만, 때로는 개념 증명 코드와 영향력 점수에 묻혀서 어떻게 나타나는지에 대한 세부 사항이 알려지지 않는 경우도 있습니다.
이 시리즈에서는 모든 시스템에 영향을 미치는 대부분의 보안 취약점의 근저에 있는 실제 코드 문제에 대한 인사이트를 제공함으로써 이러한 숨겨진 버그에 대해 설명합니다.
개별 코드 버그와 오류를 원하는 순서대로 살펴볼 수 있습니다. 하지만 Mitre가 발표한 2022년에 가장 위험한 상위 25개 버그 목록을 발표했는데, 이 목록은 다른 어떤 목록보다 좋은 목록이므로 코드 문제가 각 버그로 이어지는 과정을 설명하고 애플리케이션에 이러한 코드가 있을 때 발생하는 몇 가지 취약점을 지적하면서 살펴보겠습니다.
이 시리즈의 첫 번째 편에서는 Mitre가 선정한 2022년 가장 위험한 상위 25개 버그 중 25번부터 21번까지의 항목을 살펴봅니다.
25 - 부적절한 코드 생성 제어('코드 인젝션')
이는 프로그래머가 사용자 입력과 관련하여 충분한 방어 코드를 제공하지 않는 경우, 즉 소프트웨어가 수신한 모든 입력을 살균하지 않고 그대로 사용하여 내부 기능에 공급하는 경우에 흔히 발생하는 문제입니다.
아주 낮은 수준에서 특수하게 조작된 입력은 프로그램의 작동 방식을 예상치 못한 방식으로 변경하여 사용자가 프로그램을 더 많이 제어할 수 있게 하고, 경우에 따라 전체 시스템을 제어할 수 있게 합니다.
이로 인해 데이터 손상이나 의도하지 않은 프로그램 흐름 변경과 같은 원치 않는 부작용이 발생할 수 있도록 입력이 신중하게 구성되는 상황이 발생할 수 있습니다.
이러한 유형의 버그 중 가장 흔한 특수 사례는 "SQL 인젝션"으로, 이 글 시리즈에서 따로 분류할 가치가 있지만 코드 인젝션의 특수 사례에 지나지 않습니다.
예를 들어, PHP에서 "eval()"을 사용하면 전달된 값이 사전에 제대로 검증되지 않은 경우 코드 인젝션 가능성을 알려주는 코드 "냄새"가 나는 경우가 종종 있습니다.
24 - XML 외부 엔티티 참조의 부적절한 제한
XML 파일은 구조의 일부로 외부 문서에 대한 참조를 포함할 수 있지만, 이로 인해 애플리케이션이 의도한 범위를 벗어난 문서를 로드할 수 있습니다. 이로 인해 잠재적으로 경로 탐색 문제, 부적절한 파일 액세스 또는 애플리케이션에서 잘못된 데이터를 정상으로 간주하는 문제가 발생할 수 있습니다.
이는 다른 로컬 파일을 가리키는 URI(고유 리소스 식별자)나 file:// 또는 http:// URI를 사용하여 인터넷에 있는 파일을 가리키는 경우에도 적용됩니다.
다른 방법으로는 접근할 수 없는 파일에 액세스할 수 있을 뿐만 아니라, 애플리케이션에 예기치 않은 대용량 문서를 전송하여 속도를 늦추거나 애플리케이션이 응답하지 않게 함으로써 과도한 양의 데이터를 처리하도록 강제하는 데 사용할 수도 있습니다.
애플리케이션이 이를 방어하지 않으면 다음과 같은 XML 파일을 제작하여 시스템을 악용할 수 있습니다:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck>
<productId>&xxe;</productId>
</stockCheck>
그리고 결과를 관찰합니다.
[이 예제는 다음에서 가져온 것입니다. https://portswigger.net/web-security/xxe.]
공격자가 일반적으로 액세스할 수 없는 다른 내부 시스템에 공격 대상 서버가 액세스할 수 있는 경우, 이 버그를 디딤돌로 활용하여 해당 시스템에서 정보를 얻을 수 있습니다.
버그 23 - 제어되지 않는 리소스 소비
처리 능력, 스토리지, 네트워크 대역폭, 메모리 용량, 데이터베이스 연결 등 애플리케이션에서 사용할 수 있는 모든 리소스는 제한되어 있습니다.
애플리케이션이 이러한 리소스 중 하나 이상을 남용하도록 속일 수 있다면 리소스를 모두 소진하여 애플리케이션 또는 경우에 따라 전체 시스템이 응답하지 않거나 완전히 사용할 수 없게 만들 수 있습니다.
이전 호출이 아직 완료되지 않은 상태에서 반복 호출에 대해 보호되지 않는 컴퓨팅 집약적인 함수 또는 아주 작은 입력에서 불균형한 양의 데이터를 생성하는 함수(예: 한 글자 실수로 인한 복잡한 오류 메시지)로 코드에 나타날 수 있으며, 이러한 유형의 버그의 잠재적 원인이 될 수 있습니다.
이 버그의 또 다른 일반적인 증상은 애플리케이션이 할당된 리소스를 처분하지 않아 메모리 부족 오류 또는 이와 유사한 오류가 발생하는 경우입니다.
이는 애플리케이션이 프로덕션 단계에 도달하기 전이나 부적절한 테스트로 인해 진단하기 어려운 경우가 많은 특히 심각한 유형의 버그로, 애플리케이션을 잠재적으로 충돌 또는 예상치 못한 최악의 상태로 만들 수 있습니다.
대부분의 정적 코드 분석 도구에는 이러한 유형의 상황을 감지하기 위한 검사가 마련되어 있지만, 코드는 다양한 방식으로 작성될 수 있으므로 이러한 분석 도구가 감지하지 못할 정도로 복잡한 코드가 항상 존재할 수 있습니다.
버그 22 - 부적절한 동기화가 있는 공유 리소스를 사용한 동시 실행("경쟁 조건")
여러 애플리케이션이 동일한 리소스를 사용하거나 동일한 애플리케이션 내에서 여러 스레드를 사용하려고 할 때, 각 애플리케이션이 필요한 기간 동안 필요한 액세스 권한을 갖도록 하기 위해 어떤 형태로든 조정이 이루어져야 합니다.
그렇지 않으면 한 애플리케이션이 다른 애플리케이션과 동시에 파일에 쓰기 시작하여 결국 파일에 있어야 할 콘텐츠가 혼합되어 있거나, 애플리케이션 중 하나의 콘텐츠만 있거나, 심지어 빈 파일만 남는 상황이 발생할 수 있습니다.
이러한 유형의 상황은 부하 의존성이 매우 높기 때문에 적절하게 재현하고 식별하는 것도 어렵습니다.
파일뿐만 아니라 모든 유형의 리소스에 영향을 미칠 수 있습니다. 예를 들어 인메모리 데이터, 네트워킹, 데이터베이스에 영향을 미칠 수 있으며, 이러한 상황을 해결하기 위해 시간이 지남에 따라 많은 언어별 구조가 추가되어 '원자'라는 유형의 액세스를 생성하여 부분 읽기/쓰기가 전혀 발생하지 않도록 보장하는 것을 궁극적인 목표로 하고 있습니다.
변수 값 증가(x++)와 같은 간단한 작업은 실제 작업이 여러 머신 수준 작업(x의 원래 값 읽기, 증가, 새 값 다시 x에 할당)으로 나뉘기 때문에 실제로 이러한 유형의 문제가 발생하기 쉽습니다. x가 애플리케이션 내에서 여러 스레드가 공유하는 변수인 경우 여러 스레드가 동시에 x를 증가시키려고 하면 버그가 발생할 수 있습니다.
뮤텍스, 세마포어 및 기타 스레드 동기화 메커니즘과 같은 언어 구조는 이러한 유형의 문제를 해결하기 위해 특별히 도입되었습니다. 이러한 종류의 버그에서 비롯되는 취약성의 유병률을 고려할 때 이러한 구조체의 성공적인 구현은 이상적이지 않을 수 있습니다.
버그 21 - 서버 측 요청 위조(SSRF)
서버를 속여 쿼리에 대한 응답을 원래 요청자의 주소가 아닌 다른 대상에게 보낼 수 있습니다.
앞서 설명한 것처럼 버그 #24에서는 애플리케이션이 특수하게 조작된 XML 파일에 URI를 포함하여 다른 콘텐츠에 액세스하도록 할 수 있습니다. 이러한 파일이 타사 위치에 있는 경우 요청은 공격자의 시스템이 아닌 XML 파일을 처리하는 서버에서 발생한 것처럼 보입니다. 이 버그가 이 범주에 속하는 유일한 버그는 아니지만, 서버/애플리케이션이 타사 시스템과의 연결을 시작하도록 속이는 명백한 예입니다.
제대로 유효성이 검사되지 않은 URI 목록을 포함할 수 있는 모든 입력은 SSRF 메커니즘으로 사용할 수 있습니다.
예를 들어 M3U 파일 형식에는 외부 파일에 대한 참조가 포함될 수 있습니다.. M3U 파일을 콘텐츠 목록으로 받아들이는 비디오 인코딩 웹 서비스가 있는 경우, 다른 방법으로는 액세스할 수 없는 시스템 파일에 대한 참조를 포함하여 웹 서비스 출력의 일부로 포함할 수 있습니다.
