NGINX App Protect 를 사용하여 OWASP(2021) A3 방어 재현
OWASP(2023) TOP 10은 웹 애플리케이션 보안을 위한 표준 인식 문서입니다. 해당 문서중 A3 Injection은
악성 데이터를 보내 애플리케이션이 처리하도록 하고 애플리케이션이 해서는 안 될 일을 하게 하는 위험한 공격 중 하나입니다. 이 포스트에서는 NGINX App Protect WAF를 사용하여 Injection의 대표적인 공격 시나리오를 재현합니다.
목차
1. 환경 구성
2. OWASP top 10이란?
3. OWASP A3 Injection 공격이란?
4. Command Injection이란?
4-1. Command Injection 방어
5. Cross Site Scripting(XSS)이란?
5-1. Cross Site Scripting(XSS) 방어
6. Remote File Include이란?
6-1. Remote File Include 방어
7. SQL – Injection이란?
7-1. SQL – Injection 방어
8. 결론
1. 환경 구성
NGINX 1.25.5
NGINX App Protect WAF 5.2.0
NGINX App Protect WAF Compiler 5.2.0
NGINX Management Suite 2.17.0
NGINX Security Monitor 1.7.1
DVWA 1.9
2. OWASP top 10
Open Web Application Security Project(OWASP)는 오픈 소스 웹 애플리케이션 보안 프로젝트를 의미합니다. 이 프로젝트는 웹 애플리케이션의 보안을 향상시키기 위한 다양한 도구와 리소스를 제공합니다.
아래는 마지막으로 갱신된 OWASP top 10입니다.
- Broken Access Control (A1): 권한 부여 오류로 인한 데이터 유출, 무단 접근 등의 문제 발생
- Cryptographic Failures (A2): 암호화 알고리즘 오용, 키 관리 부실 등으로 인한 데이터 유출
- Injection (A3): Command Execution, Cross Site Scripting(XSS), Remote file Include, SQL-INjection 등 다양한 형태의 Injection 공격
- Insecure Design (A4): 애플리케이션 설계 단계부터 보안을 고려하지 않아 발생하는 취약점
- Security Misconfiguration (A5): 기본 설정 미변경, 불필요한 기능 노출 등으로 인한 보안 위험
- Vulnerable and Outdated Components (A6): 취약한 라이브러리, 프레임워크 사용으로 인한 공격
- Identification and Authentication Failures (A7): 약한 비밀번호 정책, 세션 관리 부실 등으로 인한 인증 우회
- Software and Data Integrity Failures (A8): 소프트웨어, 데이터 무결성 훼손으로 인한 시스템 장애, 데이터 변조
- Security Logging and Monitoring Failures (A9): 로그 관리 부실, 이상 징후 탐지 실패로 인한 위협 탐지 지연
- Server-Side Request Forgery (SSRF) (A10): 서버측 요청 위조를 통한 내부 시스템 접근
이 포스트에서는 OWASP A3 Injection 부분을 다룹니다.
3. OWASP A3 Injection 공격이란?
OWASP A3 Injection 공격은 OWASP(오픈 웹 애플리케이션 보안 프로젝트)에서 정의한 웹 애플리케이션 보안 취약점 중 하나로, 공격자가 애플리케이션의 입력 데이터를 조작하여 악의적인 명령어나 쿼리를 실행할 수 있게 하는 취약점을 의미합니다. Injection 공격은 데이터베이스, OS 명령어, LDAP, XML 파서 등 다양한 시스템에서 발생할 수 있습니다. 가장 흔한 예로는 SQL Injection이 있습니다.
이 포스트에서는 Command Execution, Cross Site Scripting(XSS), Remote file Include, SQL-Injection의 공격을 다룹니다.
포스트에는 NGINX App Protect를 사용하여 방어하게 되는데 공격당 1가지의 Signature를 사용합니다. Signature 안에는 많은 정책 위반을 감지하는 Attack Signature가 들어가 있습니다.
4. Command Injection이란?
공격은 공격자가 시스템 명령어를 실행할 수 있도록 애플리케이션을 악용하는 보안 취약점입니다. 이 공격은 서버에서 운영체제 명령어를 실행하는 웹 애플리케이션에서 주로 발생합니다. 공격자는 애플리케이션이 실행하는 명령어에 악의적인 코드를 삽입하여 시스템의 제어권을 획득할 수 있습니다.
아래 사진과 같이 dvwa 내에 삭제가능한 파일을 모두 삭제하여 서버에 대한 content를 삭제시켜 사이트를 무력화 할 수 있습니다.
NGINX App Protect에서는 Command Execution Signature를 활성화하여 방어할 수 있습니다.
4-1. Command Injection 방어
Command Injection를 방어한다면 NGINX App Protect의 정책을 구성하고 컴파일하여 사용해야합니다.
아래의 JSON는 Command Injection 방어 정책입니다.
command_a3.json
1 {
2 "policy": {
3 "name": "all_signatures",
4 "template": {
5 "name": "POLICY_TEMPLATE_NGINX_BASE"
6 },
7 "applicationLanguage": "utf-8",
8 "enforcementMode": "blocking",
9 "signature-sets": [
10 {
11 "name": "Command Execution Signatures",
12 "block": true,
13 "alarm": true
14 }
15 ]
16 }
17 }정책 파일의 해석입니다.
2: policy를 지정하여 정책을 구성합니다.
3: 정책의 이름을 지정합니다. (security monitor에 띄울 이름입니다.)
4: 사용할 템플릿을 지정합니다. 템플릿은 POLICY_TEMPLATE_NGINX_BASE 한개입니다. NGINX 기반의 정책 템플릿입니다.
7: 애플리케이션의 언어를 “utf-8″로 설정합니다.
8: 정책의 차단 모드를 “blocking”(차단)으로 설정합니다. 이는 탐지된 공격을 차단한다는 의미입니다.
9: 서명 세트 목록을 정의합니다. 서명 세트는 특정 유형의 공격을 탐지하는 규칙 모음입니다.
11: Command Excution Signatures를 정의합니다.(command injection 관련 서명)
12: 차단으로 지정합니다.
13: security 모니터에서 알림을 허용합니다.
해당 정책 파일을 컴파일하여 tgz파일로 만듭니다.
컴파일한 정책 파일을 app_protect/conf 파일로 옮긴 후 NGINX를 재시작합니다.
$ docker run --rm -v $(pwd):$(pwd) waf-compiler-5.2.0:custom -p $(pwd)/command_a3.json -o $(pwd)/compiled_policy.tgz && mv compiled_policy.tgz /etc/app_protect/conf && nginx -s reload
{"filename":"/home/chanok/compiled_policy.tgz","threat_campaigns_package":{"version":"2024.07.14","revisionDatetime":"2024-07-14T09:59:43Z"},"attack_signatures_package":{"revisionDatetime":"2024-07-11T12:06:47Z","version":"2024.07.11"},"compiler_engine":"full","bot_signatures_package":{"revisionDatetime":"2024-07-14T10:18:32Z","version":"2024.07.14"},"file_size":1858654,"completed_successfully":true}Command Injecction 공격이 막히는 것을 볼 수 있습니다.
정책에서 alert가 허용되었으므로 security monitor에서도 확인할 수 있습니다.
모니터링에서 확인할 수 있는건 정책의 이름과 공격한 IP 그리고 Violations(정책이 감지한 보안 위반 사항),
Signatures (정책 위반 감지), subviolations, Attack URI(공격 URLS)가 나옵니다. 위의 Id로 검색하여 확인한 것과는 달리 간소화되어 간략하게 볼 수 있습니다.
구성한 Command Execution은 Top Signatures에 나와 있습니다. rm에 대한 공격이 차단되었고 command execution을 제한했다는 것을 볼 수 있습니다.
5. Cross Site Scripting(XSS)이란?
Cross-Site Scripting(XSS)는 공격자가 악의적인 스크립트를 신뢰할 수 있는 웹사이트에 삽입하여 다른 사용자의 브라우저에서 실행되도록 하는 보안 취약점입니다. 이 공격은 주로 웹 애플리케이션의 입력 값 검증 및 인코딩이 불충분할 때 발생합니다. XSS는 사용자의 세션 쿠키 탈취, 웹사이트 변조, 악성 코드 배포 등 다양한 공격을 수행할 수 있습니다.
아래 사진과 같이 쿠키를 해커 서버로 보내는 스크립트가 들어간 게시판에서 게시물을 클릭시에 사용자의 세션 쿠키를 해커 서버에 보내는 보습을 볼 수 있습니다.
NGINX App Protect의 Cross Site Scripting(XSS)를 사용하여 게시물을 올리기 전에 차단할 수 있습니다.
5-1. Cross Site Scripting(XSS) 방어
Cross Site Scripting(XSS)를 방어합니다. Cross Site Scripting(XSS) Signature를 추가하고 컴파일합니다.
아래는 정책 구성입니다.
cross_a3.json
1 {
2 "policy": {
3 "name": "all_signatures",
4 "template": {
5 "name": "POLICY_TEMPLATE_NGINX_BASE"
6 },
7 "applicationLanguage": "utf-8",
8 "enforcementMode": "blocking",
9 "signature-sets": [
10 {
11 "name": "Cross Site Scripting Signatures",
12 "block": true,
13 "alarm": true
14 }
15 ]
16 }
17 }정책 구성은 1~10번 줄까지 같고 signature-set에 Cross Site Scripting Signatures로 변경되었습니다.
Cross Site Scripting Signatures는 Cross Site Scripting에 해당되는 공격을 차단합니다.
Cross Site Scripting Signatures를 차단합니다.
컴파일한 정책 파일을 app_protect/conf 파일로 옮긴 후 NGINX를 재시작합니다.
$ docker run --rm -v $(pwd):$(pwd) waf-compiler-5.2.0:custom -p $(pwd)/cross_a3.json --bundle $(pwd)/compiled_policy.tgz && mv compiled_policy.tgz /etc/app_protect/conf && nginx -s reload
{"bot_signatures_package":{"version":"2024.07.14","revisionDatetime":"2024-07-14T10:18:32Z"},"compiler_engine":"full","completed_successfully":true,"threat_campaigns_package":{"version":"2024.07.14","revisionDatetime":"2024-07-14T09:59:43Z"},"filename":"/home/chanok/compiled_policy.tgz","file_size":1841819,"attack_signatures_package":{"version":"2024.07.11","revisionDatetime":"2024-07-11T12:06:47Z"}}Cross Site Scripting 공격을 하여 정책이 허용되었는지 확인합니다.
스크립트를 넣은 메세지를 추가하게 된다면 아래와 같이 정책에 의해 차단되는 것을 볼 수 있습니다.
TOP Signature에 쿠키의 값과 javascript docuement, Cross-site Scripting과 onclick, loction이 시그니처에 위배되어 알람이 나왔다는 것을 볼 수 있습니다.
6. Remote File Include이란?
웹 애플리케이션의 보안 취약점 중 하나로, 공격자가 외부 서버에 호스팅된 악성 파일을 포함시켜 실행할 수 있도록 하는 취약점을 말합니다. 이 취약점은 주로 웹 애플리케이션이 사용자로부터 파일 경로를 입력받아 서버 측에서 파일을 포함(inclusion)하는 기능을 제공할 때 발생합니다. 공격자는 이 기능을 악용하여 원격 서버에 저장된 악성 코드를 웹 애플리케이션에 삽입하여 실행할 수 있습니다.
아래 사진과 같이 파일명을 URL 파라미터로 받아 파일을 include하여 출력하기 때문에 다른 파일도 include 하여 확인할 수 있습니다. vm 유저 정보가 들어가있는 파일중 하나인 /etc/passwd를 파라미터에 입력하여 출력되는 것을 볼 수 있습니다.
NGINX App Protect의 Remote File Include Signature를 사용하여 방어할 수 있습니다.
6-1. Remote File Include 방어
Remote File Include Signature가 추가된 정책 파일을 구성합니다.
remote_a3.json
1 {
2 "policy": {
3 "name": "all_signatures",
4 "template": {
5 "name": "POLICY_TEMPLATE_NGINX_BASE"
6 },
7 "applicationLanguage": "utf-8",
8 "enforcementMode": "blocking",
9 "signature-sets": [
10 {
11 "name": "Remote File Include Signatures",
12 "block": true,
13 "alarm": true
14 }
15 ]
16 }
17 }11번의 Signature를 변경하였습니다.
해당 정책 파일을 컴파일하여 tgz파일로 만듭니다.
컴파일한 정책 파일을 app_protect/conf 파일로 옮긴 후 NGINX를 재시작합니다.
$ docker run --rm -v $(pwd):$(pwd) waf-compiler-5.2.0:custom -p $(pwd)/remote_a3.json --bundle $(pwd)/compiled_policy.tgz && mv compiled_policy.tgz /etc/app_protect/conf && nginx -s reload
{"compiler_engine":"full","file_size":1789324,"filename":"/home/chanok/compiled_policy.tgz","bot_signatures_package":{"version":"2024.07.14","revisionDatetime":"2024-07-14T10:18:32Z"},"completed_successfully":true,"threat_campaigns_package":{"revisionDatetime":"2024-07-14T09:59:43Z","version":"2024.07.14"},"attack_signatures_package":{"version":"2024.07.11","revisionDatetime":"2024-07-11T12:06:47Z"}}해당 정책을 통해 Remote File Include가 막힌 것을 볼 수 있습니다.
security 모니터를 통해 확인할 수 있습니다.
/etc/passwd 접근에 대한 알림이 나왔고 File Inclusion 에 대한 알림이 나왔다는 것을 볼 수 있습니다.
7. SQL – Injection이란?
웹 애플리케이션의 보안 취약점 중 하나로, 공격자가 애플리케이션의 데이터베이스에 임의의 SQL 코드를 삽입하여 실행할 수 있는 취약점을 말합니다. 이를 통해 공격자는 데이터베이스에서 민감한 정보를 탈취하거나, 데이터 조작, 삭제, 데이터베이스 관리 권한 획득 등의 악의적인 행위를 할 수 있습니다.
아래 사진과 같이 1=1이라는 조건이 만족되는 유저들을 검색하는 SQL입니다. 1=1은 항상 참이기 때문에 모든 유저의 정보가 나오게됩니다. 이렇게 민감한 정보를 탈취할 수 있는 SQL Injection을 방어해야합니다.
NGINX App Protect SQL-INjection Signature를 사용하여 방어할 수 있습니다.
7-1. SQL – Injection 방어
SQL Injection Signatures가 구성된 정책파일을 생성합니다.
sql_a3.json
1 {
2 "policy": {
3 "name": "all_signatures",
4 "template": {
5 "name": "POLICY_TEMPLATE_NGINX_BASE"
6 },
7 "applicationLanguage": "utf-8",
8 "enforcementMode": "blocking",
9 "signature-sets": [
10 {
11 "name": "SQL Injection Signatures",
12 "block": true,
13 "alarm": true
14 }
15 ]
16 }
17 }11번의 Signature를 변경하였습니다.
해당 정책 파일을 컴파일하여 tgz파일로 만듭니다.
컴파일한 정책 파일을 app_protect/conf 파일로 옮긴 후 NGINX를 재시작합니다.
$ docker run --rm -v $(pwd):$(pwd) waf-compiler-5.2.0:custom -p $(pwd)/sql_a3.json --bundle $(pwd)/compiled_policy.tgz && mv compiled_policy.tgz /etc/app_protect/conf && nginx -s reload
{"threat_campaigns_package":{"revisionDatetime":"2024-07-14T09:59:43Z","version":"2024.07.14"},"attack_signatures_package":{"version":"2024.07.11","revisionDatetime":"2024-07-11T12:06:47Z"},"completed_successfully":true,"bot_signatures_package":{"revisionDatetime":"2024-07-14T10:18:32Z","version":"2024.07.14"},"filename":"/home/chanok/compiled_policy.tgz","compiler_engine":"full","file_size":1836266}
해당 SQL injection 공격을 하게된다면 아래 사진과 같이 정책에 의해 막히는 것을 볼 수 있습니다.
SQL INJ의 ‘, or 1=1, OR 1=1에 위배되어 차단되었다는 것을 볼 수 있습니다.
8. 결론
OWASP A3 Inection은 매우 흔하고 위험한 취약점입니다.
Command Injection, Cross-Site Scripting(XSS), Remote File Include, SQL Injection의 대표적인 공격 시나리오를 소개하고 각각의 공격을 방어하기 위한 NGINX App Protect 정책을 구성하였습니다. 각 공격 유형마다 별도의 시그니처를 사용하여 공격을 감지하고 차단할 수 있었습니다.
- Command Injection: 악의적인 명령어가 실행되지 않도록 Command Execution Signatures를 적용하여 방어하였습니다.
- Cross-Site Scripting (XSS): 악성 스크립트 삽입을 방지하기 위해 Cross Site Scripting Signatures를 사용하였습니다.
- Remote File Include: 외부 파일 포함 공격을 차단하기 위해 Remote File Include Signatures를 구성하였습니다.
- SQL Injection: 데이터베이스에 대한 불법 접근을 막기 위해 SQL Injection Signatures를 적용하였습니다.
정책 파일을 JSON 형식으로 구성하고, NGINX App Protect WAF 컴파일러를 사용하여 정책을 컴파일한 후, NGINX 서버에 적용하여 공격을 실시간으로 차단할 수 있음을 확인하였습니다. 또한, 보안 모니터링을 통해 차단된 공격 시도에 대한 상세 정보를 확인할 수 있었습니다.
NGINX App Protect는 강력한 보안 기능을 제공하며, 다양한 공격 시나리오에 대응할 수 있는 유연한 정책 구성을 지원합니다. 이를 활용하여 OWASP Top 10에 명시된 다양한 취약점을 효과적으로 방어할 수 있습니다.
댓글을 달려면 로그인해야 합니다.