📝 LDAP injection & Blind LDAP Injection 문헌 번역

LDAP Injection & Blind LDAP Injection
In WEB Application

**이해한대로의 변역이기 떄문에 과한 의역이나 오류가 포함되었을 수 있습니다.
정확한 번역을 위해선 원문을 참고해주세요.

1. 도입

데이터 베이스에 저장된 데이터의 양이 최근 급격히 증가되면서, 예민한 데이터 중 일부는 조직에 의해 민감하게 관리되어진다.

데이터베이스는 보통 칩입 탐지 시스템(intrusion detection mechanisms)과 애플리케이션만 액세스를 하는 웹 방화벽 뒤에 설치됨으로 보호된다. 데이터 베이스에 접근하기 위해서 유저는 그들의 웹중에 하나에 연결해 데이터베이스에 쿼리를 보내야한다. 데이터 베이스데이스에 대한 위협은 사용자 입력값을 검증없이 쿼리에 대조하고 제대로 처리하지 않을때 발생한다.

웹 애플리케이션 취약점의 50%는 코드의 약용을 허용하는 입력값 검증에 관련이 있다. 이러한 공격들은 앱과 시스템의 심각한 보안 문제의 원인으로 수년간 증식해왔다. 이 SQL 공격 기술은 다른 언어나 LDAP이나 XPath와 같은 프로토콜과 연관되어 대부분 광범위하게 사용되며 연구된다.

이러한 공격 피해에 대응하는 것은 공격 가능성들을 연구하고, 이것들을 공개적으로 관리자나 개발자들이 잘 알게함으로 수행될 수 있다. 헤당 논문내에선 LDAP 구조를 사용하는 웹 애플리케이션이 이러한 공격들에 취약하기 때문에 관련 공격들을 깊게 분석했다.

LDAP 악용 공격 기술의 중요 부분은 서비스에 직접적으로 검색필터를 조종할 수 있다. 이러한 기술을 사용하는 공격은 중요 기업 정보가 있는 LDAP 구조 내부 데이터베이스에 직접 접근한다. 이는 LDAP을 기반으로 하는 SSO(Single sign on)를 사용하는 많은 서비스나 애플리케이션의 보안에 큰 위협이 될 수 있다.

이러한 위협을 이끌어내는 취약점들이 이해하고 고치기 쉽더라도, 공격에 대한 정보가 부족하기 때문에 위협은 지속될 것이다. 이런 종류에 취약성에 대한 이전 언급이 존재하지만, 제시된 기술은 대부분의 최신 LDAP 서비스에 적용되지 못한다. 이 논문에 주요한 부분은 악용되어지곤 하는 새로운 LDAP 공격 기술에 깊게 분석하고 제시한다.

2. 개요
The lightweight Directory Access protocol(경량 디텍토리 엑세스 프로토콜)은 TCP/IP를 통해 실행되는 디렉토리 서비스로 수정, 쿼리 기능을 가진 프로토콜이다. LDAP 서비스에 구현되는 것은 Micorosoft의 ADAM(Active Application Mode) 과 OpenLDAP이다. LDAP 디렉토리 서비스는 공통 속성을 포함한 정보 공유를 조직하고 저장하는 소프트웨어 애플리케이션이다. 이러한 정보는 디렉토리 엔트리의 구조 기반으로 구성되며 서버는 강력한 브라우징과 검색 능력 등을 제공한다. LDAP 은 객체지향적이다. 그러므로 LDAP 디렉토리 서비스의 모든 개체는 모든 객체의 특정 구현이고 개체 특성에 대한 일관된 규칙에 일치해야한다.

또한 LDAP은 서버/클라이언트 모델이다. 클라이언트는 서버로 쿼리를 보내고 서버는 필터에 매칭해 디렉토리 엔티티에서 응답한다. LDAP 필터들은 RFC 4515에 의해 정의된다.

[요약]

모든 필터들은 괄호안에 있고 논리 연산자(OR, AND and NOT)와 관계 연산자(=,>=,<=,~=)의 일부만 이를 구성할 수 있다. 특별한 기호 *는 필터의 구성에서 하나 이상의 문자를 대체할 수 있다.

논리 연산자의 일부로 RFC 4515에서는 다음 독립 기호를 두개의 특수 상수로 사용할 수 있다.

(&) : Absolute TRUE
(|) : Absolute FALSE

3. 흔한 LDAP 환경구성들
LDAP 서비스는 많은 회사와 기관들이 주로 이용하는 요소중에 하나다. Micorosoft Active Directory, Novell E-Directory와 RedHat Directory Services와 같은 디렉토리 서비스는 LDAP 프로토콜를 기반으로 한다. 그러나 이러한 서비스들은 LDAP 서비스의 장점을 이용한 각기 다른 서비스와 애플리케이션이다.

이런 앱과 서비스들은 작동하는 다른 디렉토리들을 필요로한다. 예를 들어 하나의 디렉토리는 도메인을 요구하고 다른 디렉토리는 메일박스나 메일 그룹을, 그리고 웹 애플리케이션이나 데이터베이스를. 원격으로 더 많은 디렉토리에 접근을 요구해 사용한다.(의역: 각기 다른 디렉토리 방식을 사용한다는 의미인 듯 하다.) LDAP 서비스를 기반으로 하는 새로운 디렉토리는 다목적으로, SSO 환경에 사용 가능하고 사용자들의 인가를 위한 중앙 집중식 정보저장소로 사용된다.

새로운 시나리오는 장애 허용과 향상된 보안성, 관리자의 복잡성 감소로 인한 생산성이 증가했다. 대부분의 환경에 이 애플리케이션은 LDAP 서비스의 기반으로 다음의 목적들 중 하나를 위한 디렉터리를 사용한다.

-접근 제어(아이디/패스워드 쌍의 검증, 사용자 자격 관리)
-권한 관리
-자원 관리

기업 네트워크를 위한 LDAP 서비스의 중요성 때문에 LDAP 서비스는 다른 데이터베이스 서버들과 함께 백앤드에 위치한다. 그림 1은 기업 네트워크에 배포되는 특정한 시나리오를 보여준다. 다음의 절에 노출된 인젝션 기법의 함축된 의미를 이해하기 위해 이 시나리오를 염두해 두는 것은 중요하다.

 

4. 앱 애플리케이션 내 LDAP Injection

LDAP Injection 공격은 SQL Injection 공격과 비슷한 원리를 가지고 있다. 기본 개념은 일반적으로 LDAP 쿼리에 사용자들에 의해 도입된 매게변수를 활용한다. 하나의 웹 애플리케이션 보안은 서버에 쿼리를 보내고 구축하기 전에 유저에 의해 만들어진 파라미터들을 검증해야한다. 취약한 환경에서 이러한 파라미터들은 제대로 필터링되어지지않고 공격자들은 악성코드를 이용해 공격할 수 있다.

 

LDAP 필터들의 사용을 위해 충분히 고려되어야할 점은 아래 'Section2와 LDAP 가정 널리 사용되는 LDAP 구현들: ADAM, OpenLDAP'에 설명되어 있다. 다음과 같은 결론은 코드 공격을 이끌어낼 수 있다. (다음의 필터들은 유저들로부터 검증되어지지않은 입력 값으로서 사용되어진다.)

 

-(atteibute=value) 

만약 쿼리를 구성하는 필터에 논리연산자(Or or And)가 없는 경우는 "value)(injection_filter"와 같은 공격을 두개의 필터로 수행할 수 있다. OpenLDAP에서 두번째 값은 무시되어지고 첫번째 값만 실행될 것이다. ADAM에서 두 필터들은 허용되지않기에 따라서 공격은 수행될 수 없을 것이다.

 

-(|(atteibute=value)(second_filter) or (&(atteibute=value)(second_filter))

만약 만약 쿼리를 구성하는 필터에 논리연산자(Or or And)가 있는 경우는 "value)(injection_filter)" : (&(atteibute=value)(injection_filter))(second_filter)와 같은 공격을 수행할 수 있다. 필터가 문법상으로 정확하지않지만 OpenLDAP은 이것을 무시한 채 첫번째 필터를 닫은 후에 왼쪽부터 차례로 수행하기 시작할 것이다. 몇 LDAP 고객사에서는 두번째 필터를 무시할 것이고 ADAM, OpenLDAP에 완전한 첫번째 문을 전송해 공격을 허용할 수 있다.

 

몇몇의 애플리케이션 프래임워크는 LDAP서버에 보내기전에 필터의 오류를 체크할 것이다. 이 경우에 필터는 정확해야하는데, 다음과 같은 공격으로 가능할 수 있다."value)(injection_filter))&(1=0". 이것은 두개의 다른 필터가 되어 두번째 필터는 무시되어질 것이다. : (&(atteibute=value)(injection_filter))&(1=0)(second_filter))

 

두번째 필터가 서버에 의해 무시되어지면서 일부 구성요소는 필터가 두 개인 LDAP 쿼리를 허용하지 않는다. 이러한 경우 특정한 인젝션은 LDAP 싱글 쿼리를 포함하기 위해 만들어진다. 공격은 다음과 같다. "value)(injrction_filter"는 필터안에서 이러한 결과를 갖는다. (&(atteibute=value)(injection_filter)(second_filter).

 

애플리케이션이 코드 공격에 취약한지 아닌지를 알기위한 특정한 테스트는 유효하지 않은 입력을 생성하는 쿼리를 서버에 보내는 것으로 구성된다. 그러므로 만약 서버가 에러메세지를 반환한다면 공격자가 서버에 그의 쿼리를 실행하고 코드 공격기술들을 악용할 수 있음은 분명하다. 이전의 의견차이를 고려하여 AND 공격환경과 OR 공격 환경 두 종류의 환경으로 구별할 수 있다. 

 

4.1 AND LDAP injection

이 경우 애플리케이션은 사용자에 의해 입력된 하나이상의 파라미터와 "&" 연산자가 포함된 LDAP 디렉토리에 검색하기 위한 일반 쿼리로 구성된다. 예를들어 (&(parameter1=value)(parameter2=value2)). 값 1과 2는 LDAP 디렉토리에 검색을 수행하는 값이다. 공격자는 올바른 필터 구도를 유지하면서도 쿼리를 사용하여 자신의 목적을 수행하기 위한 코드 공격을 할 수 있다.

 

4.1.1 접근 제어 우회

로그인 페이지는 유저이름과 비밀번호 두개의 입력 필드값을 가진다. Uname, Pwd는 유저이름과 비밀번호를 입력하기 위한 부분이다. 클라이언트로부터 유저/비밀번호 쌍의 입력 값을 확인하기 위해 LDAP 검색 필터는 구성되어지고 LDAP 서버에 보내질것이다.

 

(&(User=Uname)(PASSWORD=Pwd))

 

만약 공격자가 예를 들어 slisberger하고 이 뒤에 적절한 입력을 주입해 유저이름에 입력한다면 비밀번호 검증은 우회될 수 있다. Uname=sliberger)(&)), Pwd값에 일련의 값을 입력하면 다음의 쿼리는 구성되어 서버에 보내질 것이다.

 

(&(User=slisberger)(&))(PASSWORD=Pwd))

 

이 경우 첫번째 필터는 서버에서 처리되어진다. 이 쿼리는 항상 참이기때문에 공격자는 유효한 비밀번호 값 없이 접근을 얻을 수 있다.

 

4.1.2 권한 관리 우회

 

(&(directory=documents)(security_level=low))

다음과 같은 공격 수행 (&(directory=documents)(security_level=*))(&(directory=documents)(security_level=low))

서버는 두번째 것을 무시한 채 첫번째 필터만을 수행할 것이다..

 

4.2 OR LDAP Injection

이 경우 애플리케이션은 사용자에 의해 입력된 하나이상의 파라미터와 "|" 연산자가 포함된 LDAP 디렉토리에 검색하기 위한 일반 쿼리로 구성된다. 예를들어 (|(parameter1=value)(parameter2=value2)). 값 1과 2는 LDAP 디렉토리에 검색을 수행하는 값이다. 공격자는 올바른 필터 구도를 유지하면서도 쿼리를 사용하여 자신의 목적을 수행하기 위한 코드 공격을 할 수 있다.

 

4.2.1 정보 공개

관리자가 유저에게 시스템의 이용가능한 리소스를 공개한다고 가정하자. 사용가능한 리소스가 표시하는 쿼리에 사용되어지는 특정한 LDAP 공격 경우가 있다. 

 

(|(type=Rsc1)(type=Rsc2))

 

Rsc1와 Rsc2는 프린터, 스캐너와 같은 다른 종류의 리소스를 표시한다. 입력가능한 공격은 Rsc1=printer)(uid=*)으로

(|(type=printer)(uid=*))(type=Rsc2)) LDAP 서비스는 모든 프린트 및 사용자 개체를 응답한다.

 

 

5. Blind LDAP Injection

비록 참과 거짓을 만드는 LDAP 코드 공격에 (직접적인) 에러메세지가 뜨지 않더라도, 공격자는 서버 응답으로부터 이것을 유추가능하다고 가정하자. 공격자는 참과 거짓의 질문을 요청하는 행동을 사용할 것이다. 이러한 공격을 "Blind Attacks"이라고 한다. 블라인드 LDAP 공격은 더 느리지만 이항 논리를 기반으로 쉽게 구성할 수 있다. 그들은 LDAP 디렉토리로부터 정보를 추출한다. 

 

5.1 And Blind LDAP injection

에러문이 뜨지 않는 곳에서 웹 애플리케이션이 LDAP 디렉토리 내 이용가능한 Epson 프린터를 리스트하길 원한다고 가정하자.  그 애플리케이션은 다음과 같은 LDAP 검색 필터를 보낼 것이다. (&(objectClass=printer)(type=Epson))

쿼리로 인해, 이용가능한 프린터가 있으면 클라이언트에게 아이콘이 보여진다. 다른 아이콘은 보이지 않는다. 만약 공격자가  *)(objectClass=*))(&(objectClass=void 을 주입해 Blind LDAP injection을 수행한다면, 웹 애플리케이션은 다음 LDAP 쿼리로 구성될 것이다.

 

(&(objectClass=*)(objectClass=*))(&(objectClass=void)(type=Epson))

 

첫번째 완전한 필터만 실행될 것이다: (&(objectClass=*)(objectClass=*)) 

이 결과로 프린터 아이콘은 항상 결과를 포함해 클라이언트에게 보여질 것이다. objectClass=*는 항상 개체를 반환한다.

아이콘이 응답에 보여질 때는 참이고, 그렇지 않으면 거짓이다. 이런 관점에서 Blind injection 기술을 사용하는 것은 쉽다. 예를 들어, 다음과 같은 주입이 구조될 수 있습니다.

 

(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(type=Epson))

(&(objectClass=*)(objectClass=resources))(&(objectClass=foo)(type=Epson))

 

이 코드 공격은 공격자들에게 LDAP 디렉토리 서버의 다른 가능한 objectClass 값을 유추하는 것을 허용한다. 웹 페이지 응답에 최소 하나 이상의 프린터 아이콘이 포함되었을 때, objectClass 값은 존재한다(참), 반면 objectClass 값이 존재하지 않거나 이것에 접근하지 못하면, 아이콘이 없이 objectClass값은 존재하지 않는다.(거짓)

 

Blind LDAP injection 기술은 공격자들에게 참/거짓 질의문을 사용해 모든 정보에 접근하는 것을 가능하게 한다.

 

5.2 OR Blind LDAP injection

이 경우엔 OR 논리 연산자의 문장때문에 원하는 정보를 유추하기 위해 사용되는 논리가 반대이다. 같은 예제에 따르면 OR 환경의 주입은 이럴 것이다.

 

(||(objectClass=void)(objectClass=void))(&(objectClass=void)(type=Epson))

 

이 LDAP 쿼리는 LDAP 디렉토리 서비스로 부터 객체를 포함하지 않고 프린터 아이콘은 클라이언트에게 보여지지 않는다.(거짓) 만약 어떤 아이콘이 웹 페이지 응답에 포함된다면 그 프린터 아이콘은 클라이언트에게 보여지지 않을 것이다.(참) 그러므로, 공격자는 정보수집을 위해 다음의 LDAP 필터를 주입할 것이다.

 

(||(objectClass=void)(objectClass=users))(&(objectClass=void)(type=Epson)

(||(objectClass=void)(objectClass=resources))(&(objectClass=void)(type=Epson)

 

5.3. 악용 예시

이 LDAP 환경은 위에서 설명한 주입 기술을 사용하는 것을 보여주고, 현재 보안 시스템 내에서 이 공격의 중요한 영향과 취약점의 악용이 미칠 수 있는 영향을 설명하기 위해 구현되어 진다. 페이지 printerstatus.php 예제안에서는 다음의 LDAP 검색 필터로 구성돤 idprinter 파라미터를 받는다. (&(idprinter=Value1)(Objectclass=printer))

 

5.3.1 속성 검색

Blind LDAP 공격기술은 웹 애플리케이션 안에 LDAP 검색 필터 제작의 시작에 AND 연산자를 이용함으로써 LDAP 디텍토리 서비스로부터 민감한 정보를 얻는데 사용되어진다. 예를 들어, 주어진 특성은 Value=HPLaserJet2100의 그림 10에 LDAP 쿼리의 응답 페이지와 그림 9에 보여진 프린터 객체로 정의된다. 

 

하나의 속성 검색 공격은 다음과 같은 LDAP 주입을 만듬으로써 수행되어질 수 있다.

(&(idprinter=HPLaserJet2100)(ipaddress=*))(Objectclass=printer))

 

(&(idprinter=HPLaserJet2100)(department=*))(Objectclass=printer))

확실히, 공격자는 속성이 존재하거나 아닌 이러한 결과로부터 유추할 수 있다. 첫번째 경우에 프린트에 대한 정보는 애플리케이션에 의해 특성 ipaddress이 존재하지 않거나 접근가능하지 않아(False) 주어지지 않았다. 다른 경우는, 두번째의 경우, 웹 페이지의 응답은 프린터의 상태를 보여준다. 그러므로 특성 department는 LDAP 디렉토리에 존재하거나 이것은 접근가능하다.

 

게다가 Blind LDAP 주입 공격과 함께 이러한 몇몇의 값들은 얻어질 수 있다. 예를 들어 공격자가 department 속성의 값을 알기를 원한다고 가정하자. 그는 이것을 유추하기 위해 ,다음에서 설명될, 부울화 및 문자 집합 축소 기술을 사용할 수 있다.

 

5.3.2 부울화

공격자는 숫자 검색 또는 알파벳을 사용하는 속성들으로 값을 추출할 수 있다. 이 아이디어의 핵심은 참/거짓의 리스트안의 복잡한 값(예: 문자열 또는 날짜)을 변형하는 것이다. 이 부울화로 불리는 매커니즘은 매우 다양한 방법으로 적용될 수 있고 그림 13에 요약되어져있다. 

공격자가 department 속성의 값을 알기를 원한다고 가정하자. 이 과정은 다음과 같다.

(&(idprinter=HPLaserJet2100)(department=a*))(Objectclass=printer))

(&(idprinter=HPLaserJet2100)(department=f*))(Objectclass=printer))

(&(idprinter=HPLaserJet2100)(department=fa*))(Objectclass=printer))

그림16

 (&(idprinter=HPLaserJet2100)(department=fI*))(Objectclass=printer))

그림17

그림 9에서 이 예시 안에서 department 값은 financial 이다. a 문자와 함께 첫번째 시도는 어떤 프린터의 정보도 얻지 목했고 첫번째 문자는 a가 아니다. 이후 나머지 문자들의 테스트에서 애플리케이션에서 일반적 반응을 얻은 단 하나는 f이다. 두번째 문자열에 관해 애플리케이션에서 일반적 반응을 얻은 단 하나는 i이다. 다음의 과정에서 department 값은 얻어질 수 있다.

 

이 알고리즘은 수 값 또한 사용되어질 수 있다. 이것의 수행을 위해 이 부울화 과정은 <= 연산자와 >=연산자를 사용할 것이다.

 

5.3.3 문자열 축소

공격자가 정보를 얻기 위해 필요로 되는 요청의 수를 감소하기 위해 문자열 축소를 사용할 수 있다. 이 성취를 위해 그는 주어진 문자집합이 값의 *어디든* 존재하는지 테스트하기 위해 와일드카드를 사용한다.

 

(&(idprinter=HPLaserJet2100)(department=*b*))(Objectclass=printer))

(&(idprinter=HPLaserJet2100)(department=*n*))(Objectclass=printer))

그림 18은 문자열 b를 테스트했을 때의 웹 페이지를 보여준다: LDAP 디렉토리 서비스로부터 결과가 보내지지 않고 b는 존재하지 않는다. 그러나 그림 19는 일반적인 반응 웹 페이지를 보여준다. 문자 n이 값안에 존재함을 의미한다.

 

6. Blind LDAP injection & LDAP injection attacks 에 반하는 안전한 애플리케이션

이전에 제시된 공격은 응용 프로그램 계층에서 수행된다, 그러므로 네트워크 계층의 방화벽과 칩입 탐지 시스템은 이러한 공격을 예방하는데 영향을 주지 못한다. 하지만, LDAP 서비스의 일반적 보안 권고안은 이러한 취약점을 완화시키거나 최소 권한 원칙과 최소 노출을 지원함으로 영향을 최소화할 수 있다.

 

코드 주입을 예방에 사용되는 매커니즘은 방어적인 프로그래밍, 민감한 입력 유효성 검사, 동적 검사와 정적 소스 코드 분석을 포함한다. LDAP 주입들을 완화시키는 이 일들은 비슷한 기술들에 반드시 수반되어야한다.

 

LDAP 주입 공격이 클라이언트에서 서버로 보내는 매개변수에 특수 문자를 포함함으로써 수행된다는 것이 이전 부분에서 입증되었습니다. 그러므로 서버로 쿼리를 보내기 전에 LDAP 필터가 구성되는 변수들을 필터링하고 검증하는 것이 중요하다는 것은 분명합니다. 결론으로, 우리는 괄호, *, 논리연산자와 관계연산자(&, |, !, <=, >=, =, ~=)가 애플리케리션 계층에서 필터링되어야할 것입니다.

 

가능할때마다, LDAP 검색 필터를 구성하는데 사용되어지는 값들은 LDAP 서버에 쿼리를 보내지기 전에 애플리케이션 계층에서 허용 값 목록과 대조되어야할 것입니다.