오펜시브 보안 영역의 LLM 활용 사례 (2)

들어가며

[오펜시브 보안 영역의 LLM 활용 사례 (1)]에서는 테스팅 및 취약점 탐지의 효율성을 높이기 위한 오펜시브 보안 영역의 대표적인 LLM 활용 사례들을 살펴보았습니다. 이번 포스트에서는 추가적인 LLM 활용 사례들을 웹 서비스 보안에 조금 더 초점을 두어 살펴보겠습니다.

먼저 살펴볼 사례는 LLM을 활용하여 정적 분석을 통한 보안 취약점 식별 과정의 효율을 개선한 연구입니다. Security Assessment 팀이 정적 분석을 통해 취약점을 발굴하는 과정의 효율을 개선하기 위한 리서치 수행 중 발견한 논문을 소개하겠습니다.

LLM-Assisted Static Analysis for Detecting Security Vulnerabilities

취약점을 발견하는 방식은 크게 (1) 애플리케이션(Application)을 실행하지 않고 소스 코드 정적 분석을 통해 취약점을 찾는 SAST(Static Application Security Testing, White Box Testing)와 (2) 프로그램을 실행하여 동적 분석을 통해 소스 코드 없이 취약점을 찾는 DAST(Dynamic Application Security Testing, Black Box Testing) 두 가지로 나눌 수 있습니다.

정적 분석의 대표적인 도구로는 CodeQL이 있습니다. CodeQL은 유용한 도구이지만, CodeQL을 비롯한 대부분의 정적 분석 도구들은 아래와 같은 한계를 지닙니다.

Missing taint specifications of third-party library APIs

• CodeQL을 이용한 정적 분석을 위해서는, 그에 앞서 서드파티 라이브러리(third-party library)에서 사용하는 소스(source), 싱크(sink), 정화(sanitize)의 API를 사람이 수동으로 분석해야 합니다. 해당 작업이 누락될 경우 잘못된 결과가 출력될 수 있으며, 해당 라이브러리가 업데이트될 경우, 다시 분석해서 CodeQL에 적용해야 하는 번거로움도 존재합니다.

Lack of precise context-sensitive and intuitive reasoning

• 컨텍스트(맥락, context) 대한 분석 및 추론 부족으로 인해, 소스나 싱크를 잘못 탐지하여 유효하지 않은 결과를 출력할 수 있습니다.

위의 상황에서, 취약점이 실행되지 않는 잘못된 결과가 포함되어 있을 경우 분석에 더 많은 시간이 소요되기도 합니다. 또한, 코드의 컨텍스트에 대한 이해 부족으로 인해 존재하는 취약점을 결과로 출력하지 못할 가능성(False Negatives)도 존재합니다.

일례로, CVE-2021–41269에서 공격자가 유효하지 않은 expression 값을 전달할 경우, parse() 함수에서 IllegalArgumentException이 발생하여 6번 구문(statement)이 실행됩니다. 여기서 buildConstraintViolationWithTemplate() 함수의 인자로 공격자의 입력이 들어가기 때문에, 공격자는 Java Expression Language(Java EL)을 통해 코드 실행(code execution)을 할 수 있습니다.

• 참고: Fix security vulnerability regarding the Hibernate dependency. · Issue #461 · jmrozanec/cron-utils

위 취약점을 정적 분석을 통해 찾기 위해서는 상당히 긴 코드를 분석해야 하고, 내부에서 개발된 코드와 서드파티 라이브러리에서 사용하는 코드 간의 제어 흐름(control flow), 소스, 싱크를 식별해야 합니다. 또한, 어떤 상황에서 예외(exception)가 발생하는 지에 대한 컨텍스트를 이해해야 하며, 해당 과정의 입력값 정화(sanitizer) 프로세스를 확인해야 합니다.

논문에서는 위에서 살펴본 기존 정적 분석 도구의 한계를 해결해야 하는 문제로 설정하고, LLM을 통한 해결을 제안합니다. 단계는 아래와 같습니다.

1. LLM을 통해 내부에서 개발된 코드와 서드파티 라이브러리에서 사용하는 코드 간의 제어 흐름, 소스, 싱크(서드파티 라이브러리에서 사람이 수동으로 분석하는 부분)를 라벨링(labeling)합니다.

2. 위 과정의 결과를 정적 분석 도구(예: CodeQL)의 입력 형식에 맞게 변환합니다.

3. 변환된 값을 정적 분석 도구의 입력값으로 전달한 후, LLM을 이용하여 출력값을 검증하여 오탐(False Positive)을 줄이고 최종 결과를 이용자에게 출력합니다.

이러한 일련의 과정을 통해 정적 분석의 정확성과 효율성을 향상시킬 수 있습니다. 특히, LLM의 자동화된 코드 이해 능력은 복잡한 서드파티 라이브러리의 취약점 식별에 걸리는 시간을 크게 단축시킬 것으로 기대됩니다.

생성형 AI가 발전하고 주목 받으며, LLM이 통합된 웹 애플리케이션 서비스가 증가하고 있습니다. 챗봇이 대표적인 예시입니다. 고객을 위해 접근성 향상을 비롯한 다양한 이점을 제공하고 있으며, 이용자의 질문에 답변하기 위해 자연어를 해석할 뿐만 아니라 내부 애플리케이션 간의 데이터를 기반으로 결과를 제공합니다.

이와 같이 LLM을 서비스에 연동할 때도 보안 취약점이 발생할 수 있습니다. LLM이 연동된 웹 애플리케이션에서 발생할 수 있는 주입(injection) 취약점에 대한 연구를 살펴보겠습니다.

From Prompt Injections to SQL Injection Attacks: How Protected is Your LLM-Integrated Web Application?

Langchain과 같은 LLM 통합 미들웨어(middleware)는 LLM과 웹 애플리케이션 간의 통합을 간소화하는 SDK(Software Development Kit)의 일종입니다. 개발자는 Langchain을 통해 다양한 LLM 모듈(module)을 통합하여 활용할 수 있습니다. 이 내용은 아래 그림과 같이 나타낼 수 있습니다.

이때, 이용자의 입력에 대한 검증이 존재하지 않을 경우 악의적인 입력을 이용하여 챗봇을 통한 SQLi(SQL 주입, SQL Injection) 공격을 수행할 수 있습니다. 아래 이미지는 그 예시로, 공격자 프롬프트(prompt)에 적용된 완화 방안(mitigation)을 우회하여 LLM에게 특정 테이블을 삭제하는 SQL 쿼리(query) 실행을 명령합니다.

이와 같이, 공격자는 챗봇의 인터페이스를 이용해 LLM이 악성 SQL 쿼리를 생성하도록 유도하는 악의적인 질문을 전달할 수 있습니다. 이용자의 입력을 제대로 검증하지 않으면, 공격자는 데이터베이스에 대한 악의적인 행위가 가능합니다.

이는 Langchain의 이슈(Issue)와 PR(Pull Request)에 등록되어 논의가 이루어진 이슈입니다. 이슈를 참고하면, 해당 공격을 방어하기 위해서는 (1) SQL 쿼리를 실행하기 전에 이를 가로채서(intercept) 특정 동작(action)을 차단할 수 있어야 하고, (2) 데이터베이스의 권한을 제한하여 위험한 쿼리 실행을 차단해야 합니다.

논문은 해당 이슈에 대해 아래와 같은 추가적인 방어 기법을 제안합니다.

SQL query rewriting

• 공격자가 다른 이용자 정보 조회를 시도하면, 해당 SQL 쿼리를 가로채서 다시 작성하여 악의적인 행동을 방지하는 방법

• 참고: 위의 이슈에서는 공격자가 악의적인 입력으로 다른 이용자의 정보를 조회할 수 있는 SELECT에 대한 완화 방안이 존재하지 않는다.

Preloading data into the LLM prompt

• 이용자의 데이터를 미리 로드(load)하여 LLM 프롬프트에 적용함으로써, 데이터베이스에 접근할 필요성을 제거하는 방법

• 참고: 해당 작업이 소비하는 토큰으로 인해 비용 및 성능 이슈가 발생할 수 있다.

Auxiliary LLM Guard

• LLM이 데이터베이스에 SQL 쿼리를 이용하여 질의를 요청할 경우, 해당 쿼리를 가로채고 LLM을 이용하여 악성 여부를 판단하는 방법

살펴본 바와 같이, 프롬프트 주입(prompt injection) 뿐만 아니라 프롬프트를 통해 악의적인 SQL 쿼리를 생성한 주입 공격 또한 위협이 될 수 있습니다. 만약 유사한 서비스(LLM과 웹 애플리케이션을 통합한 서비스)를 개발/검수하고 있다면, LLM이 데이터베이스에 접근하는 과정을 모니터링하여 위협 시나리오를 나열한 뒤, 이를 막기 위한 방법을 적용해야 할 것입니다.

마치며

이번 포스트에서는 LLM을 이용하여 소스 코드 정적 분석을 통한 취약점 탐지를 보다 효율적으로 개선할 수 있는 가능성 및 LLM의 도입으로 인해 발생할 수 있는 웹 애플리케이션의 새로운 위협에 대해 살펴보았습니다. 기술의 발전은 항상 변화를 가져옵니다. LLM은 업무의 효율을 개선할 수 있는 수단이지만, 새로운 공격이 시작될 수 있는 지점이기도 합니다.

Security Assessment 팀은 오펜시브 보안 분야에서의 LLM 활용 가능성에 대해 많은 관심을 가지고 있으며, 변화하는 생태계에서 발생할 수 있는 새로운 위협들에 대해서도 선제적으로 대응하고자 합니다.

About Theori Security Assessment

티오리 Security Assessment 팀은 실제 해커들의 오펜시브 보안 감사 서비스를 통해 고객의 서비스와 인프라스트럭처를 안전하게 함으로써 비즈니스를 보호합니다. 특히, 더욱 안전한 세상을 위해 난제급 사이버보안 문제들을 해결하는 것을 즐기며, 오펜시브 사이버보안의 리더로서, 공격자보다 한발 앞서 대응하고 불가능하다고 여겨지는 문제를 기술중심적으로 해결합니다.