cirocosta/lighty-sqlinj-demoCVE-2014-2323 SQL 인젝션 취약점에 대한 교육용 익스플로잇 데모로, lighttpd의 mod_mysql_vhost에서 발생하며, Docker 기반 실습 환경을 통해 취약점 분석 및 패치를 직접 실습할 수 있습니다.
title: Ep4 - 네트워크 관련 취약점 members:
관련 취약점:
CVE-2014-2323 [1]은 SQL 인젝션 버그에 할당되었습니다.
CVE-2014-2324 [2]는 경로 탐색 버그에 할당되었습니다.
확인: http://download.lighttpd.net/lighttpd/security/lighttpd_sa_2014_01.txt
공격 대상 서비스는 Lighttpd입니다. 이는 가볍고 빠르도록 최적화된 오픈소스 웹서버(BSD 라이선스)입니다. 유명한 c10k 문제(서버에서 10,000개의 동시 연결 처리 방법)의 '개념 증명'으로 등장하여 당시(2003년) 상당한 인기를 얻었으며, 현재 Whatsapp.com, Xkcd에서 사용되고 있으며 과거에는 Youtube에서도 사용되었습니다. 시장에서의 위치는 아래 그래프에서 확인할 수 있듯이 매우 흥미롭습니다.
이 서버는 이벤트 기반 비동기 메커니즘(BSD의 kqueue, Linux의 epoll)을 사용하여 많은 연결 문제를 해결하며, 여러 스레드의 필요성을 줄여 훨씬 적은 메모리 사용량과 더 나은 CPU 활용을 제공합니다. (이는 Nginx 서버에서도 사용되는 전략으로, 최근 몇 년간 사용량이 크게 증가했습니다.)
Lighty의 특징 중 하나는 가상 호스트의 쉬운 관리입니다.
이는 동일한 IP로 해석되는 여러 도메인 이름을 호스팅하는 방법으로, 각 웹사이트에 전용 서버를 예약할 필요가 없으므로 웹사이트를 제공하려는 기업의 호스팅 비용을 절감합니다.
이 기술은 IP 기반(각 호스트마다 하나의 인터페이스) 또는 이름 기반(인터페이스를 공유하며 각 호스트에 하나의 이름 사용)으로 구현될 수 있으며, 이 발표에서는 이름 기반 방식을 다룹니다.
이름 기반
: 클라이언트가 제공한 '호스트명'을 사용하여 응답할 서비스를 식별합니다. 이 방법에는 두 가지 어려움이 있습니다: 보안 세션(TLS) 처리의 복잡성 - 핸드셰이크는 호스트를 서버에 알리는 헤더 전송 전에 이루어져야 하므로, 핸드셰이크 시 어떤 인증서를 제시할지 결정하기 어렵습니다. 이 문제에 대한 해결책은 TLS 확장인 *Server Name Indication(SNI)*으로, 핸드셰이크 시작 시 이름을 제시하여 올바른 인증서를 선택할 수 있게 합니다. 두 번째 문제는 Host 헤더가 명확하지 않은 연결 시도로, 사용할 서비스를 결정하지 못하게 됩니다.
IP 기반
: 각 애플리케이션에 별도의 IP를 사용합니다. 웹서버는 여러 물리적 네트워크 인터페이스(또는 동일한 인터페이스 아래 가상 인터페이스)로 구성되어 대상 IP 주소에 따라 적절히 응답합니다.
*IP 에일리어싱*을 사용하면 각 서비스에 대한 가상 인터페이스를 생성할 수 있습니다.
대기업의 경우 클라이언트 수에 따라 이러한 매핑을 관리하는 것이 복잡해질 수 있습니다. Lighty는 이러한 목적을 위해 데이터베이스 사용을 지원하며, 이에 대해 아래에서 설명하겠습니다.
먼저 서버를 수동으로 구성하고 가상 호스팅을 추가하는 방법을 살펴보겠습니다.
기본 lighttpd 서버를 준비하는 것은 매우 쉽습니다. 설치 후 포트, 특정 요청 처리 방법 및 기타 설정을 정의하는 구성 파일을 생성하면 됩니다.
정적 파일(.html 또는 .txt) 요청만 처리하는 예제 구성을 준비할 수 있습니다.
server.document-root = "/usr/lighttpd/mysite.com/"
server.port = 80
mimetype.assign = (
".html" => "text/html",
".txt" => "text/plain"
)
이제 웹사이트 판매 기반 사업을 만들고 구매자에게 자체 도메인을 제공하려 한다고 가정해 보겠습니다. 비용을 최소화하기 위해 각 고객에게 가상 호스트를 만들고자 합니다. 네트워크 수업에서 세 개의 웹사이트인 redes.io, mac0448.io, mac5910.io를 구매하려 한다고 가정해 보겠습니다. 우리 회사는 도메인을 등록하고, 모두 단일 인터페이스를 가진 단일 서버의 IP를 가리키도록 합니다.
참고: 이를 시뮬레이션하려면 /etc/hosts 파일을 수정할 수 있습니다.
172.17.0.2 redes.io
172.17.0.2 mac0448.io
172.17.0.2 mac5910.io
단일 IP에서 클라이언트의 다른 웹사이트를 제공하기 위해 수동으로 서버를 구성할 수 있습니다.
server.document-root = "/usr/lighttpd/default/"
server.port = 80
mimetype.assign = (
".html" => "text/html",
".txt" => "text/plain"
)
$HTTP["host"] == "redes.io" {
server.document-root = "/usr/lighttpd/redes/"
} else $HTTP["host"] == "mac0448.io" {
server.document-root = "/usr/lighttpd/mac0448/"
} else $HTTP["host"] == "mac5910.io" {
server.document-root = "/usr/lighttpd/mac5910/"
}
그러나 많은 클라이언트를 처리하고 각 웹사이트에 대해 앞서 언급한 것처럼 다른 구성을 제공하려면 이것이 문제가 될 수 있습니다.
mod_mysql_vhost 모듈을 사용하면 서버를 이러한 매핑을 담당하는 mysql 데이터베이스에 연결할 수 있습니다. 데이터베이스 이름, 네트워크에서 찾을 위치, 검색에 사용할 명령을 지정합니다.
server.modules = (
"mod_accesslog",
"mod_mysql_vhost"
)
mysql-vhost.db = "데이터베이스_이름"
mysql-vhost.user = "사용자"
mysql-vhost.pass = "비밀번호"
(!!!!!!!!!!!!!!!)
mysql-vhost.sql = "SELECT docroot FROM domains WHERE domain='?';"
(!!!!!!!!!!!!!!!)
mysql-vhost.hostname = "호스트명"
mysql-vhost.port = "포트"
SQL은 관계형 데이터베이스를 관리하기 위한 선언적 언어입니다. (...) 등
TODO
TODO
문제는 SQL을 사용하는 데이터베이스 관리 시스템이 삽입된 명령이 관리자가 알고 잘 관리하는 명령이라고 가정한다는 점에서 발생합니다. 이러한 가정은 항상 사실이 아니며, 데이터베이스 시스템과 상호작용하는 시스템, 특히 사용자와의 상호작용이 많은 웹에서 결함이 발생할 수 있습니다.
SQL 명령 문제는 사용자 이름, 비밀번호 또는 기타 동적 콘텐츠와 같이 사용자로부터 비롯된 텍스트를 사용하여 명령을 구성하려는 의도가 있을 때 나타납니다.
(TODO)
해결 방법? 이스케이핑.
예를 들어, 우리 구성에는 큰 허점이 있습니다.
mysql-vhost.sql = "SELECT docroot FROM domains WHERE domain='?';"
버전 1.4.34까지는 ?가 임의의 명령으로 대체되어 MySQL에서 실행될 가능성이 있었기 때문입니다.
이제 세 개의 컨테이너로 구성된 네트워크에서 이를 시뮬레이션해 보겠습니다. MySQL 서버 하나, 취약한 Lighttpd 서버 하나, 패치된 Lighttpd 서버 하나입니다.
Docker는 운영 체제 위에 추상화 계층을 제공하여 커널이 제공하는 격리 메커니즘(예: cgroups(CPU, IO, 메모리 및 네트워크 사용량 격리) 및 namespaces)을 사용함으로써 다른 OS 없이 가상화를 가능하게 하여 가상 머신을 시작하고 유지하는 오버헤드를 제거합니다. 이로 인해 리소스 할당(예: 1GB 이미지의 가상 머신 100개 -> 100GB, 1GB 이미지의 컨테이너 100개 -> 약 1GB) 및 처리 공유에서 큰 최적화가 이루어지며, 커널과 운영 체제 자체도 공유됩니다. 컨테이너 간 공통 파일은 계층형 파일 시스템을 통해 공유될 수도 있습니다.
네임스페이스에 대한 흥미로운 비유는 chroot입니다. 이는 프로세스가 디렉토리를 전체 파일 시스템의 루트로 인식하게 하여 시스템 관점을 변경합니다(시스템의 나머지 부분은 변경하지 않음). 네임스페이스를 사용하면 프로세스 트리, 네트워크 인터페이스, 파일 시스템, IPC 등 다양한 OS 측면에 대해 이러한 차별화된 관점을 만들 수 있습니다.
(더 보기: Separation Anxiety: A Tutorial for Isolating Your System with Linux Namespaces)
사용자가 이러한 공유와 약한 격리를 원하지 않을 수도 있다는 점을 고려해야 합니다.
Docker 데몬 부팅 시 호스트에 docker0라는 가상 인터페이스가 구성되며, 호스트에서 사용되지 않는 서브넷을 선택하여 가상 인터페이스에 사용 가능한 IP를 할당합니다. 다음 세 범위 중 하나가 사용될 수 있음을 기억하십시오.
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
예를 들어 내 머신의 경우:
docker0 Link encap:Ethernet HWaddr 02:42:58:ca:78:6d
inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:58ff:feca:786d/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:74601 errors:0 dropped:0 overruns:0 frame:0
TX packets:98561 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4196391 (4.1 MB) TX bytes:380442767 (380.4 MB)
기본 네트워크 설정으로 인스턴스화된 각 컨테이너에 대해 데몬은 호스트에 인터페이스(아래 예에서는 컨테이너 1의 경우 verth5998947)를 구성하고(docker0 서브넷의 일부) 컨테이너에 다른 인터페이스(eth0)를 구성하며, iptables(호스트에서 패킷 처리를 위한 규칙 체인 테이블 정의 가능) 및 NAT를 수정하여 외부 트래픽이 컨테이너로 전달되도록 합니다.
데모는 Linux 머신에 docker가 제대로 구성된 환경이 필요합니다. 그런 다음 이미지를 생성해야 합니다.
$ ./scripts/create-lighty-image.sh
위 명령은 Dockerfile을 기반으로 이미지를 생성하며, 취약한 버전과 패치된 버전의 lighttpd 소스 코드를 모두 포함합니다.
그런 다음 데모의 처리 인스턴스와 데이터베이스를 나타내는 컨테이너를 인스턴스화할 수 있습니다. 데이터베이스도 별도의 컨테이너로 격리됩니다.
$ ./scripts/create-mysql-container.sh
$ ./scripts/create-lighty-container.sh vulnerable
$ ./scripts/create-lighty-container.sh patched
결과는 다음과 같습니다.