'웹해킹'에 해당되는 글 41건

2021년 9월 24일에 발표한 ‘OWASP Top 10 – 2021’에는 신규 3개 항목이 추가됐으며, 기존 3개 항목은 다른 항목에 병합되는 등 새롭게 개정된 내용이 있음.

[OWASP TOP 10(2021) 항목]

A01: Broken Access Control(접근 통제 권한 취약점)

• 접근 제어가 취약하면 사용자는 주어진 권한을 벗어나 데이터를 무단으로 열람하거나 수정, 삭제 등의 행위가 가능하게 됨
• 대표적으로 클라이언트, 서버 단에서의 매개변수 값 변조에 의해 접근 권한을 벗어날 수 있게 되며 타 사용자의 데이터 무단 열람, 수정, 삭제 등이 가능해짐
• 메소드(post, get, delete 등)이 API 요청에 대한 접근 제어가 누락된 경우도 있음

A02: Crytograthic Failures(암호화 오류)

• Sensitive Data Exposure(민감 데이터 노출)의 명칭이 2021년에 암호화 오류로 변경됨.
• 적절한 암호화가 되어 있지 않으면 민감한 데이터가 노출될 수 있음.
• 예를 들어 SSL 프로토콜 미적용으로 인한 평문 노출, 클라이언트에서 마스킹 처리 되어 있지만 응답값 내에선 중요 정보 등이 평문으로 노출 되는 등이 있음.

A03: Injection(인젝션)

• 2013년도 부터 계속 1위를 차지했지만 2021년에는 3위가 됨
• SQL, NoSQL, OS, LDAP, EL, OGNL 등의 인젝션 취약점은 신뢰할 수 없는 데이터 명령어나 조작된 쿼리문을 통해 서버로 전송될 때 취약점이 발생함
• 대표적으론 SQL Injection이 있지만 종류가 다양하며 최근엔 프레임워크에도 SQL 인젝션 방어가 다 되어 있지만 옛날 서버에선 종종 Injection 취약점이 발생되는 곳이 있기 때문에 알아두는게 좋음.
• XSS 공격도 2021년엔 인젝션 항목에 포함되었으며 사용자 제공 데이터 조작 공격은 모두 인젝션 항목으로 통일됨.

A04: Insecure Design(안전하지 않은 설계)

• 2021년에 새로 신설된 항목으로 코드 구현 단계에 앞서 기획과 설계 단계에서 발생하는 보안 결함을 의미함
• 개발을 완료한 후에 소스 코드를 수정해도 보안 결함을 완벽하게 방어하는덴 한계가 존재함
• 소프트웨어 개발보안 방법론은 총 5가지의 단계가 존재함

A05: Security Misconfiguration(보안 설정 오류)

• 보안 설정 오류는 애플리케이션을 최초 설치하거나 업데이트 시 보안성을 고려하지 않은 설정으로 인해 취약점이 발생함
• XXE 항목은 애플리케이션의 잘못된 보안 설정으로 인해 발생하는 취약점 중 하나로 2021년엔 보안 설정 오류 항목에 병합됨.
• 대표적으로 불필요 포트, 불필요한 페이지, 계정 등이 노출되는 취약점이 있으며 그 외에도 관리자 계정(ID/Password)을 디폴트로 사용하거나 에러 정보 노출, 보안 헤더 설정 누락 등이 있음.

A06: Vulnerable and Outdated Components(취약하고 지원이 종료된 구성 요소)

• 2021년에 새롭게 생긴 항목이며 취약하고 지원이 종료된 구성요소, 취약한 버전, 소프트웨어 기술 중단 상태인 소프트웨어를 계속 사용하는 경우 그로 인해 발생할 수 있는 모든 보안 위협을 포함하고 있는 항목임.
• 서비스 구성 모든 요소(OS, WEB/WAS, DB, 어플리케이션 등)이 모두 이 항목에 해당됨
• 대표적으론 지원 종료된 OS 사용, 알려진 취약점이 존재하는 버전의 애플리케이션 사용(Apache, tomcat, nginx 등), 프레임워크 사용(Apache Struts 2, Spring 등), 라이브러리 사용(OpenSSL 등)이 있음
• 최신 버전을 잘 탐색해서 업데이트 하는 것이 중요함

A07: Idetification and Authentication Failures(식별 및 인증 실패)

• 2021년 개정으로 취약한 인증(Broken Authentication) 항목에 식별 실패를 포함 시켜서 조금 더 넓은 의미로 식별 및 인증 실패(Idetification and Authentication Failures) 항목으로 변경됨
• 사용자 신원 확인이나 인증 및 세션 관리에 해당하는 항목이며 여전히 많이 발생되는 취약점임.
• 대표적으론 멀티팩터인증, 비밀번호정책, 인증 실패 제한 부재로 Brute Force 공격이 가능한 것과 Get 메소드로 전송 시 URL에 인증 세션 ID가 노출되는 경우, 세션 타임 아웃이 없는 경우가 있음.

A08: Software and Data Integrity Failures(소프트웨어 및 데이터 무결성 오류)

• 2021년에 신설된 항목으로 기존에 안전하지 않는 역직렬화(Insecure deserialization) 항목이 병합됨.
• 애플리케이션이 신뢰할 수 없는 소스, 저장소 CDN, 플러그인, 라이브러리, 모듈에 의존하는 경우에 발생됨
• 안전하지 않은 CI/CD 파이프라인은 개발 및 배포 과정에서 애플리케이션이 변조되면 무결성이 훼손될 가능성이 있어 애플리케이션이 사용하는 코드에 대한 무결성 검증 절차 추가가 필요함
• 대표적으로 라이브러리나 모듈에 대한 무결성 검증이 없어 변조가 가능하거나 업데이트 공급망에 검증이 없는 경우, 직렬화된 데이터에 대한 무결성 검증이 없는 경우 등이 있음.

A09: Security Logging and Monitoring Failures(보안 로깅 및 모니터링 오류)

• 기존 2017년엔 불충분한 로깅 및 모니터링(Insufficient Logging & Monitoring) 항목이었으나 이번 2021년 개정에서 보안 로깅 및 모니터링 실패(Security Logging and Monitoring Failures) 항목으로 변경됨
• 적절한 로깅과 모니터링이 있어야 대응이 가능하며 취약점 공격 예방 뿐 아니라 공격 발생 감지 및 대응까지 포함 되어야 하는 걸로 개정됨.
• 대표적으로 로그인, 인증 실패, 권한설정 등에 중요 기능 수행에 대한 로깅이 없거나 일정 주기로 로그에 대한 백업이 없는 경우, 불명확한 로깅 및 모니터링을 하는 경우가 있다. 이러한 경우를 예방하기 위해선 침해 사고 대응 절차의 대한 복구 계획 수립이 있음.

A10: Server-Side Request Forgery(SSRF, 서버 측 요청 변조)

• 2021년에 신설된 항목으로 애플리케이션이 사용자 제공 데이터를 적절한 검증 없이 로컬 및 원격 리소스를 가져와 취약점을 발생시킴.
• 서버 측에 있는 값을 조작해서 공격한다는 특징을 가지고 있으며 서버 권한에 대한 신뢰 관계를 이용해 공격함.
• 대표적으로 서버가 적절한 검증 절차 없이 사용자 요청을 신뢰하여 로컬이나 원격 리소스 데이터에 접근하도록 하는 경우가 있음.
• 모든 사용자 요청에 대해 검증을 할 필요가 있으며 내부 네트워크끼리 통신할 때도 방화벽에 접근 제어 규칙 패턴을 생성해 모니터링 하는 것이 좋음.

1. 하트블리드 취약점 개요

하트 블리드 취약점은 2014년 4월에 발견된 OpenSSL 소프트웨어 버그다. CVE-2014-0160이며 이 취약점은 사용자나 관리자의 아이디, 패스워드, SSL 비밀키 등을 노출하게 하는 매우 위험한 취약점으로 판명됐다. OpenSSL 1.0.1 이후 '하트비트'라는 세션 연결을 확인하는 방법을 제공하지만 전달되는 값의 길이가 검증되지 않아 버퍼 오버플로우가 발생한다. 이 결함은 최대 64KB의 응용 프로그램 메모리 내용을 요청할 수 있다. 서버의 메모리 정보를 평문으로 볼 수 있어 지속적으로 공격해 정보들을 합치면 아이디, 패스워드, 기타 개인 정보 노출이 가능해진다.

                                                                                                          <사진 출저 : blog.alyac.co.kr>

[그림 1-1] 하트블리드 시나리오

하트블리드 시나리오를 보면 클라이언트는 의도적으로 거짓 정보를 서버에게 전달해 오류를 발생시킨다. 서버측은 클라이언트에서 받은 거짓 정보를 검증 하지 않고 클라이언트가 요청한 거짓 정보 값을 그대로 다시 응답한다. 예를 들면 "이것은 잘못된 정보입니다. 사용자의 ID 값은 Hello며 PW는 1234$ 입니다."로 잘못된 정보를 포함해 또 다른 정보들을 클라이언트에게 전달하게 된다. 이러한 정보들이 합쳐져 아이디, 패스워드, 개인 정보 등과 같은 중요 정보들이 노출되게 된다.

2. 취약점 실습 환경 구성

3. 하트 블리드 취약점 스크립트 코드 시연

[그림 3-1] 하트 블리드 취약점

Nginx 웹 서버가 취약한 버전의 OpenSSL을 사용하고 있다. 8443 포트로 공격 스크립트를 작동하라는 메시지가 출력되었다.

[그림 3-2] 명령어 입력

위의 스크립트를 다운 받아 저장 후 실행한다. Python heartbleed.py [웹 서버 IP] | more 명령어를 입력하고 실행하면 공격 스크립트가 실행된다.

[그림 3-3] 8443 포트 접근

희생자 PC에서 웹 서버의 8443 포트로 접근한 후 계정 정보로 로그인을 시도한다.

[그림 3-4] 계정 정보 노출

로그인 시도 후 실행했던 공격 스크립트를 확인하면 메모리 단에 로그인했던 계정 정보가 평문으로 노출되어 있음을 확인할 수 있다.

[그림 3-5] 와이어 샤크 패킷 전송

와이어샤크에서 ip.addr == [웹 서버 IP]로 필터링하고 패킷을 확인하면 하트블리드 공격에 의해 전송된 값을 볼 수 있고 입력 했던 계정 정보가 평문으로 노출되고 있음을 확인할 수 있다.

[그림 3-6] TCP Steam

정상 SSL 통신에서 암호화되는 요청 패킷의 내용이 하트블리드 취약점에 의해 요청 패킷 내용이 평문으로 전송되고 있다.

4. 하트블리드 취약점 메타스플로잇 시연

[그림 4-1] 모듈 검색

msfconsole 실행 후 search heartbleed 명령어로 하트블리드 관련 모듈을 확인한다. 하트블리드 취약점 시연을 위해 auxiiary/scanner/ssl/openssl_heartbleed 모듈을 사용한다.

[그림 4-2] 옵션 지정

하트블리드 모듈을 실행하고 옵션을 지정한다. 지정 옵션들은 다음과 같다.

[그림 4-3] 공격 수행

옵션 지정 후 공격을 수행하면 스캔이 시작된다. 스캔이 되고 메모리 값이 노출되는데 웹 서버에서 로그인 했던 계정 정보가 평문으로 노출되고 있음을 확인할 수 있다.

5. 대응 방안

Open SSL 버전 업데이트, 비밀번호 이중 인증, 인증서 재발급, IPS 탐지룰 설정 등으로 방어한다. 사용하는 운영체제의 정식 페이지에서 Open SSL 업데이트 버전을 설치한 후 테스트 해보는 방법도 필요하다.

1. SQL 인젝션 공격 대응 방안

SQL 인젝션 공격과 같은 모든 파라미터 입력값 조작으로 이뤄지는 공격은 입력값 검증을 통해 대응이 가능하다. 대표적인 방어 방법은 화이트리스트 검증이다.

 $query = "Select first_name, last_name FROM users WHERE user_id='$id';";

위와 같은 쿼리 방식은 $id 방식이 입력값을 조작할 수 있을 가능성이 높기 때문에 매우 취약한 SQL 쿼리다.

[그림 1-1] SQL 방어 쿼리 - 1

SQL 인젝션 대응 방안이 되는 모범 코드다. 맨 윗쪽에는 CSRF 공격 방어까지 구현되어 있어 CSRF 공격도 하기 힘든 구조다. SQL 인젝션 공격을 방어하기 위해 사용하는 방법은 파라미터 쿼리로 변경하는 것이다. Check the database 주석을 보면 prepare, bindParam, execute를 호출해 쿼리문을 실행한다. Prepare 함수에선 미리 실행할 쿼리문의 형태를 작성하고 사용자 입력값이 들어가는 $id 부분은 bindParam 함수에서 실행할 수 있도록 하는 형태를 띠고 있다. 즉, 데이터베이스는 어떤 것이 코드고 어떤 것이 쿼리인지 구분을 할 수 있게 되기 때문에 공격자가 입력값을 조작하려고 해도 쿼리문에서 일부가 될 수가 없고 데이터로 처리되기 때문에 SQL 인젝션 공격을 효과적으로 방어 할 수 있다.

[그림 1-2] SQL 방어 쿼리 - 2

SQL 인젝션 High 단계의 소스 코드다. [그림 1-1] 소스 코드와 비교해 봤을 때 따로 처리하는 함수가 없고 온전히 쿼리 안에서만 처리하려고 하기 때문에 공격자가 입력값을 조작하는게 가능하다. LIMIT 1이라는 레코드 값 제한을 걸어도 #이나 --와 같은 주석으로 우회가 가능하기 때문에 안전한 소스 코드라곤 볼 수 없다.

1. SQL 인젝션 공격 High 단계 실습

[그림 1-1] SQL 인젝션 공격

DVWA 레벨을 high로 설정한 후 SQL Injection 탭을 클릭하면 기존과는 다르게 영어로 된 링크가 있다. 이 링크를 클릭한다.

[그림 1-2] 소스코드

SQL 인젝션 공격에 앞서 소스코드를 확인하면 '$id' 뒤에 LIMIT라는 쿼리가 추가 되어 있는데 이 쿼리는 레코드의 개수를 제한한다. 현재 쿼리는 1로 제한 되어 있지만 이 부분을 우회하기 위해 주석처리를 한다면 우회가 가능하다.

[그림 1-3] SQL 인젝션 공격

앞에 값이 참이든 거짓이든 뒷 부분을 참으로 만들어 쿼리가 동작하는 구문을 삽입한다. 1' or '1'='1'#을 입력한 후 전송한다. #은 주석으로 소스코드에서 본 Limit 1을 우회하기 위해 사용된다.

[그림 1-4] 공격 성공

1' or '1'='1'#을 입력한 후 전송된 결과 SQL 인젝션 공격이 성공했음을 확인할 수 있다. Limit 1이 우회되면서 전체 데이터베이스의 정보를 출력된다.

[그림 1-5]  테이블 정보

테이블 정보를 확인하기 위해 union SQL 공격 구문을 삽입한다. 1' union select user, password from users#을 삽입하고 전송한다. Users 테이블에서 user, password의 컬럼을 숫자 1과 조합해 참을 만들어 추출한다는 쿼리다.

[그림 1-6]  테이블 내용

1' union select user, password from users# 쿼리 전송 결과 아이디, 패스워드로 보이는 정보들이 노출되었음을 확인할 수 있다. 패스워드는 암호화 되어 있지만 MD5 형식이고 구글에서 쉽게 평문으로 변환이 가능하다.

1. Blind SQL 인젝션 공격 개요

Blind SQL 인젝션 공격은 임의의 SQL 구문을 삽입해 인가되지 않은 데이터를 열람할 수 있는 공격 기법이라는 것은 다른 SQL 인젝션 공격 기법과는 크게 다르진 않다. 차이점이 있다면 일반 SQL 인젝션 공격은 임의의 SQL 조작된 쿼리를 입력해 한번에 정보를 보여 줄 수 있지만 Blind SQL 인젝션 공격은 쿼리의 결과에 따른 서버의 참과 거짓의 반응을 통해 데이터베이스의 정보를 알아 낼 수 있다. 일반 SQL 인젝션 공격에 비해 시간이 상당히 오래 걸린다는게 단점이지만 시간을 투자하면 언제든지 데이터베이스 정보를 탈취할 수 있기 때문에 위험한 SQL 인젝션 공격 기법 중 하나라고 판단할 수 있다.

(1) Blind SQL 인젝션 공격 실습

[그림 1-1] User ID 입력

Blind SQL Injection 탭을 선택하고 User ID 값에 1을 요청한다. 1을 전송하면 User ID가 존재한다고 표시된다.

[그림 1-2] User ID 입력

이번엔 User ID 값에 6을 요청한다. 6을 전송하면 User ID가 존재하지 않는다고 표시된다. 이러한 응답값을 통해 데이터베이스는 총 5개가 된다는 것을 추측할 수 있다.

[그림 1-3] 정상값 처리

AND 뒤에 1=1#이라는 항상 참이 되는 조건을 추가해 삽입하고 실행한다. 1'이라는 값이 참이기 때문에 뒤에 1=1# 이라는 참이 되는 조건을 추가하면 데이터베이스는 존재한다는 것을 알 수 있다. 만약 SQL 인젝션 쿼리문이 실행되지 않는다면 ID가 1이 아니라 1' AND 1=1#의 전체 문자열을 하나의 ID로 처리하고 비정상적인 값은 실행하지 않아 User ID가 없다는 메시지가 나와야 한다.

[그림 1-4] 비정상값 처리

AND 뒤에 1=2#이라는 거짓이 되는 조건을 추가해 삽입하고 실행한다. User ID는 존재하지 않는다고 출력된다. AND 뒤에 1=2가 거짓이 되기 때문에 앞에 붙은 조건과 관계 없이 거짓이 된다. 즉, AND 이후 조건에 따라 결과가 바뀐다는 거고 입력하는 값이 SQL 쿼리문을 통해 처리되고 있다고 추측할 수 있다.

[그림 1-5] 소스 코드

소스 코드를 보면 빨간색 박스 안에 SQL 쿼리문을 구성하고 있다. User_id='1' AND 1=1과 같이 전제가 참인 조건문이 되서 사용자가 존재한다고 출력된거고 AND 1=2를 입력하면 where 구문이 전부 거짓이 되서 사용자가 없다고 출력한 것이다. 이와 같이 참, 거짓이 구분 되서 출력되는 것은 SQL 쿼리문이 뒤에서 사용되고 있는 것을 추측해 볼 수 있다.

(2) Time based SQL 인젝션 공격 실습

[그림 2-1] sleep 함수

User ID에 1' AND sleep(5)#을 입력한 후 요청한다. 개발자 도구를 활용해 응답시간을 확인하면 약 5초 동안 응답값이 지연 되는 현상을 볼 수 있다.

[그림 2-2] sleep 함수

이번에는 User ID에 6' AND sleep(5)#을 입력한 후 요청한다. 개발자 도구를 활용해 응답시간을 확인하면 응답값이 지연 되지 않고 응답 되는 현상을 볼 수 있다. 앞에 6'이 거짓이기 때문에 응답값이 지연 되지 않고 응답 되는 것이다. 즉, 6이라는 데이터베이스는 존재하지 않는 것이다. 조건이 참일 때만 응답값이 지연되고 거짓일 땐 응답값이 지연되지 않는 참, 거짓을 통해 구분할 수 있게 된다.

1. WHERE 구문

[그림 1-1] WHERE SQL 인젝션 공격 과정

[사진 출저: 화이트해커가 되기 위한 8가지 웹 해킹 기술]

정상적인 경로라면 사용자가 ID값 1을 요청하기 위해 ID값 1을 출력하는 SQL 쿼리 구문을 웹 애플리케이션에 요청하면 웹 애플리케이션은 SQL 구문을 DB에 전달한다. DB는 필요한 정보를 추출해 ID값 1인 사용자 정보를 웹 애플리케이션에 전달하고 웹 애플리케이션은 사용자에게 전달해주게 된다.

이에 반해 악의적인 의도를 가진 공격자는 SQL 쿼리문을 조작해 요청값 이외의 정보도 탈취한다. 공격자는 ID값 1 이외에도 다른 정보도 탈취하기 위해 or '1'='1이라는 쿼리를 추가해 웹 애플리케이션에 요청하고 웹 애플리케이션은 DB에 SQL 구문을 전달한다. DB에서 특별한 검증을 하지 않으면 요청 이외의 값들도 웹 어플리케이션에 전달되고 웹 어플리케이션에서 공격자에게 정보를 전달하게 된다.

(1) Where 구문 DB 정보 탈취 실습

[그림 1-2] 요청 ID 값

DVWA SQL Injection 항목을 실행하면 UserID 폼에 1을 입력해 전송하면 DB에 있는 정보들이 그대로 출력된다.

[그림 1-3] 소스코드

소스코드를 확인하면 별다른 검증값이 없고 '$id'라는 SQL 구문이 일치하면 DB가 동작한다. ''이라는 세미콜론 안에 SQL 구문이 정상적으로 일치하면 SQL 인젝션 공격이 가능하다는 의미다.

[그림 1-4] SQL 공격 구문

[그림 1-3]에서 확인했던 ''값의 조건을 맞춰 SQL 공격 구문을 삽입한다. 1' or '1'=1을 삽입하면 ''값 조건에도 맞게 되고 OR 연산자를 사용하게 되서 OR 앞, 뒤 중 한 부분만 맞게 되도 참으로 반환되기 때문에 SQL 인젝션 공격이 성사된다. 해당 구문의 SQL 인젝션 공격이 성공하면 모든 DB 정보를 탈취할 수 있다.

2. Union 구문

[그림 1-1] UNION SQL 인젝션 공격 과정

[사진 출저: 화이트해커가 되기 위한 8가지 웹 해킹 기술]

정상적인 경로라면 사용자가 ID값 1을 요청하기 위해 ID값 1을 출력하는 SQL 쿼리 구문을 웹 애플리케이션에 요청하면 웹 애플리케이션은 SQL 구문을 DB에 전달한다. DB는 필요한 정보를 추출해 ID값 1인 사용자 정보를 웹 애플리케이션에 전달하고 웹 애플리케이션은 사용자에게 전달해주게 된다.

이에 반해 악의적인 의도를 가진 공격자는 SQL 쿼리문을 조작해 요청값 이외의 정보도 탈취한다. 공격자는 ID값 1 이외에도 다른 DB 정보도 탈취하기 위해 1' union select name,pw from users#이라는 SQL 쿼리를 웹 애플리케이션에 전달한다. union 구문은 두개 이상의 select 구문을 합치는데 사용하게 된다. 여기서도 요청 값 이외에 union 구문을 삽입해 참을 만들어 추가 DB 정보를 탈취한다. DB에 SQL 공격 쿼리 구문이 전달되고 별다른 검증값을 거치지 않는다면 DB에 존재하는 모든 사용자의 이름, 비밀번호가 공격자에게 그대로 전달된다.

(1) Union 구문 칼럼 개수 추측 실습

[그림 1-2] Union SQL 공격 구문

Union SQL 공격 구문을 삽입해 실행하면 [그림 2-2]와 같이 DB 정보가 그대로 노출됨을 확인할 수 있다. #은 Mysql의 라인을 처리하는 주석으로 만약 ID, password 창이 있다면 ID에 #이 적용되면 password 창은 모두 주석 처리 되서 참인 결과를 반환한다.

[그림 1-3]  SQL 공격 구문

칼럼의 개수를 확인하기 위해 select에 1,1,1을 삽입해 실행한다.

[그림 1-4] 에러 메시지

Union select 구문 실행 결과 에러 메시지가 출력된다. 이는 컬럼의 개수가 3개는 아니라는 의미다. 따라서 공격자는 컬럼의 개수는 2개 임을 추측할 수 있다.

[그림 1-5] order by SQL 공격 구문

order by 구문은 SQL에서 지정된 컬럼순으로 오름차순, 내림차순으로 정렬을 해주는 역할을 한다. [그림 2-5]에서 컬럼의 개수를 알아보기 위해 order by SQL 공격 구문을 삽입하면 DB 정보가 그대로 노출 됨을 확인할 수 있다.

[그림 1-5] order by SQL 공격 구문

order by 뒤에 2를 붙여 컬럼 2개를 묶어 실행한 결과 DB 정보가 그대로 노출 됨을 알 수 있다.

[그림 1-6] order by SQL 공격 구문

order by 뒤에 3을 붙여 컬럼 3개를 묶어 실행한다.

[그림 1-7] 에러 페이지

order by SQL 공격 구문 실행 결과 에러 페이지가 출력 됨을 확인할 수 있다. 에러 페이지가 출력 됨으로써 컬럼의 개수는 2개임을 추측할 수 있다.

(2) Union 구문 계정 탈취

[그림 2-1] 데이터베이스 명

데이터베이스 명을 알아보기 위해 1' union select schema_name,1 from information_schema.schemata #을 입력해 데이터베이스 명을 확인한다. 입력한 SQL 공격 구문은 schemata 테이블의 information_schema 컬럼에서 schema_name, 1의 정보를 가져와 앞의 1'와 합쳐서 DB 정보를 출력한다는 의미다. Union SQL 공격 구문을 입력하면 데이터베이스 명을 알 수 있다.

[그림 2-2] dvwa 데이터베이스의 테이블 명

dvwa 데이터베이스의 테이블 명을 알아보기 위해 1' union select table_schema, table_name from information_schema.tables where table_schema = 'dvwa' #를 입력해 테이블 명을 확인한다. table_schema의 dvwa 데이터베이스에서 tables 테이블의information_schema 컬럼에서 table_schema, table_name의 정보를 가져와 앞의 1'와 합쳐서 DB 정보를 출력한다는 의미다. Union SQL 공격 구문을 입력하면 테이블 명을 알 수 있다.

[그림 2-3] users 테이블 칼럼

Users 테이블의 칼럼 정보를 알아보기 위해 1' union select table_name, column_name from information_schema.columns where table_schema = 'dvwa' and table_name = 'users'# 을 입력해 테이블 칼럼을 확인한다. 기존과 형식은 비슷하지만 where 조건 뒤에 and table_name = 'users'#가 추가되서 조회된다. DB 정보를 가져오면 users의 테이블의 칼럼을 확인할 수 있다.

[그림 2-4] users 테이블 정보

users 테이블 정보를 알아보기 위해 1' union select user, password from users#을 입력해 실행한다. 실행 결과 사용자 계정으로 추측되는 정보들이 있음을 확인할 수 있다. 아이디는 평문이지만 패스워드는 MD5 형식의 해쉬값으로 저장되어 있다. 하지만 MD5 형식의 해쉬값도 구글에 검색하면 바로 해독이 가능하다.

[그림 2-5] 해쉬값 해독

구글에 검색해 해쉬값 해독 결과 아이디가 admin으로 저장되어 있는 정보는 패스워드가 password 라는 것을 확인 할 수 있다.

1. 브루트 포스 공격 대응 방안

[그림 1-1] 로그인 페이지

브루트 포스 방어가 되어 있는 로그인 페이지는 오류가 3회 이상 발생 시엔 15분 동안 로그인을 차단한다. 3회에 15분을 기다려야 하기 때문에 브루트 포스 공격은 사실상 불가능하다.

[그림 1-2] 소스 코드 - 1

소스코드를 보면 패스워드는 md5 형태로 해서 처리하고 있으며 username 변수에 대해선  mysql_real_escape_string() 함수를 처리한다. 또한 만약 로그인에 실패했을 때 sleep 함수를 사용해 응답 속도를 늦춘다. 만약 일정한 응답 속도로 설정하면 공격자 입장에선 패스워드가 틀린 것이라고 생각하고 다시 공격을 시도 할 수 있게 된다. 하지만 [그림 1-2] 소스코드에선 랜덤하게 응답 속도를 설정해서 공격자가 입력한 패스워드가 일치하는지 불일치하는지 판단하기 어려워져 브루트 포스 공격에 부담을 줄 수 있다.

[그림 1-3] 소스 코드 - 2

타임 아웃을 설정해놓는 소스코드다. 만약 3회 이상 로그인이 실패하면 자동으로 15분동안 로그인이 금지된다. 하지만 정상적인 사용자도 3회 이상 패스워드가 틀리면 15분 동안 접속이 차단된다. 사용자의 ID를 차단하기 보단 접속자 IP를 차단하는게 가용성을 높일 수 있지만 접속자 IP 주소를 서버에서 관리를 해야 하기 때문에 서버의 부담이 늘어날 수 있는 단점이 있다.

1. 브루트 포스 공격 개요

[그림 1-1] 브루트 포스 공격

[출저: 화이트헤커를 위한 웹 해킹의 기술]

브루트 포스 공격이란 특정 정보(사용자의 패스워드)를 알아내는 공격이다. 만약 패스워드가 일치하지 않아도 계속 바꿔가며 공격할 수 있고 시간이 오래 걸리지만 언젠가는 계정 정보가 일치해 로그인이 가능하게 된다. 패스워드가 너무 쉽거나 추측 가능하게 설정하면 브루트 포스 공격에 의해 너무 쉽게 노출될 수 있다. 하지만 특수문자를 섞어서 설정하면 공격에 시간이 상당히 많이 소요되기 때문에 패스워드가 쉽게 노출될 수 없게 된다. 브루트 포스 공격 방지를 위해 페이지 내에 방어도 중요하지만 사용자의 비밀번호 설정 방식도 브루트 포스 공격을 예방하는 방법 중 하나가 될 수 있다.

2. 브루트 포스 공격 실습

(1) 자동 브루트 포스 공격

[그림 2-1] Intruder

브루트 포스 탭에서 계정 정보를 입력 한 후 프록시를 잡는다. 계정은 admin, 1234임을 알 수 있고 현재 정보를 Intruder 탭으로 보낸다.

[그림 2-2] Positions

페이로드 포지션에서 현재 패스워드 값을 알아내는게 목적이기 때문에 패스워드 부분에만 $를 표시한다.

[그림 2-2] payloads

페이로드 설정에서 Payload type을 Brute Forcer로 선택한다. Payload Options에서 Character set이 자동 지정되는데 영문자부터 숫자 9까지 지정된다. 이 부분에 특수문자들을 추가하면 Payload count는 늘어나고 Max length 숫자를 높이면 unknown이 표시된다. 그만큼 브루트 포스 공격을 하는데 있어서 많은 시간이 소요된다는 의미다.

[그림 2-3] 브루트 포스 공격

브루트 포스 공격 화면이다. 문자를 하나씩 넣어가며 자동화 공격을 시도하고 있다. 만약   응답 요청 길이가 다른 숫자 값으로 나온다면 그 문자열이 사용자 계정의 비밀번호다. 하지만 Brute forcer를 이용한 공격은 많은 시간이 걸리기 때문에 비효율적인 방법의 브루트포스 공격이 될 수 있다.

(2) Dictionary 브루트 포스 공격

[그림 2-4] Intruder

브루트 포스 탭에서 계정 정보를 입력 한 후 프록시를 잡는다. 계정은 admin, 1234임을 알 수 있고 현재 정보를 Intruder 탭으로 보낸다.

[그림 2-5] Positions

페이로드 포지션에서 현재 패스워드 값을 알아내는게 목적이기 때문에 패스워드 부분에만 $를 표시한다.

[그림 2-6] payloads

Payload type을 Simple list로 선택한 후 Payload Options에서 사용자들이 가장 많이 사용하는 패스워드를 담은 txt 파일을 만든 후 업로드 한 후 Start Attack 버튼을 누른다.

[그림 2-7] 브루트 포스 공격

브루트 포스 공격 시도 결과 응답 요청 길이가 다른 것이 있다. 2번 응답 요청 길이는 5293이지만 1번 응답 요청 길이는 5358이다. 이 때 사용자 계정 비밀번호는 1234라는 것을 알 수 있다. 패스워드가 올바르지 않은 경우면 로그인 실패 페이지가 응답되지만 패스워드가 올바른 경우면 로그인 성공 페이지가 출력되게 된다. 즉, 1번 요청은 로그인에 성공한 페이지가 응답된 것이라고 생각할 수 있다.

[그림 2-8] 소스 코드

소스 코드를 보면 비밀번호는 md5로 해쉬화 해서 취약점은 발생하지 않는다. 하지만 username은 별다른 조치 없이 SQL 문에 그대로 입력 됨을 볼 수 있다. 하지만 쿼리 구문 아래 코드에서 SQL 결과 값이 1개일 때만 로그인 된다는 것을 알 수 있다. 이 경우에 사용자 비밀번호를 알지 못해도 SQL 인젝션 취약점이 발생할 수 있음을 추측할 수 있다.