휴먼Tech 공통교양 [웹 해킹과 시큐어코딩] Part2–01. A1-Injection
안녕하세요, 휴먼스케이프 프론트엔드 개발자 Tasha입니다 :)
이번주부터 휴먼Tech팀은 프론트엔드, 백엔드 개발에 공통적으로 필요하다고 생각하는 책을 한 권 정하여 함께 공부해보기로 했는데요! 첫 프론트/백엔드 공통 교양책은 [웹 해킹과 시큐어코딩]입니다. 이 책의 Part2인 웹 취약점 점검기준부터 함께 살펴보기로 했는데요, 본론으로 들어가기 전에 먼저 첫 주자인 제가 프론트 새내기인지라 설명이 미숙할 수 있는 점 미리 양해 부탁드립니다( _ _ )
A1-Injection이란?
OWASP(Open Web Application Security Project: 전 세계 기업, 교육기관 및 개인이 만들어가는 오픈소스 어플리케이션 보안 프로젝트)에서 3년마다 업데이트하는 Top10 웹 취약점이 있습니다. 이는 심각성에 따라 순서가 정해진다고 하는데, 가장 최근 업데이트판인 2017년에도, 바로 전 발표인 2013년에도 꾸준히 첫번째를 유지하고 있는 것이 A1-Injection입니다.
[출처] https://grca-academy.com/a1-injection-owsap/
A1-Injection 공격은 이름에서도 알 수 있듯이 공격자의 데이터가 SQL, OS, LDAP에 명령 또는 쿼리의 일부로 주입되는 것을 뜻합니다. 이는 의도하지 않은 명령을 실행하거나 적절한 권한없이 데이터에 액세스하도록 속일 수 있습니다.
A1-Injection공격은 크게 세 분류로 나뉘는데, SQL쿼리 삽입을 이용한 SQL Injection, CRLF삽입을 이용한 CRLF Injection, 운영체제 명령어를 삽입하는 Command Injection이 있습니다.
SQL Injection
SQL 인젝션 공격은 포털사이트에 조금만 검색해봐도 최근까지도 피해사례들이 즐비합니다. 대표적으로 한 숙박어플에서는 SQL인젝션 공격으로 웹페이지 관리자 아이디가 노출되어 7만건의 고객 개인정보와 323만건의 숙박 예약정보가 유출, 한 암호화폐거래소에서는 같은 공격으로 개인정보 약 3만건이 유출되어 243명이 보유했던 70억원 상당의 암호화폐가 부정인출된 사례가 있다고 합니다.
SQL 인젝션은 쿼리 등이 SQL쿼리를 삽입하여 데이터베이스 조회, 변조 및 삭제 등의 공격을 의미하는데요, 삽입 유형에 따라 다섯가지 정도로 나뉩니다.
에러기반 SQL Injection
에러기반 SQL Injection은 SQL관련 에러를 통해 데이터베이스 정보를 예측하는 것입니다. 특수문자(싱클 쿼트(‘) 또는 세미콜론(;))를 GET, POST요청 필드, http 헤더값, 쿠키값 등에 삽입하는 경우를 처리해주지 않으면 에러메세지가 보이게 되는데, 이 에러메세지에서 데이터베이스 정보를 유추해볼 수 있습니다.
MSSQL Server Error (출처: http://raijee1337.blogspot.com/2015/07/mssql-injection-using-convert.html)
MySQL Server Error (출처: https://blog.detectify.com/2012/09/20/sql-injection-in-1-min/)
OWASP ZAP와 같은 웹 취약점 분석도구에서는 이러한 취약점 여부를 특수문자를 삽입하였을 때 응답코드가 500번이거나, 응답페이지에 SQL 관련 에러가 발생하면 취약점으로 판단하고 있다고 합니다.
Union기반 SQL Injection
Union은 SQL 연산자로 2개 이상의 쿼리를 요청하여 결과를 얻을 때 쓰이는데, 이를 악용하여 원래의 요청에 추가 쿼리를 삽입하여 정보를 얻어내는 해킹방법입니다.
Union기반 sql 인젝션 [출처] http://coashanee5.blogspot.com/2017/02/sql.html
웹 취약점 분석도구에서도(ex. sqlmap) null 패턴 삽입으로 쿼리개수를 파악하여 취약점 여부를 확인해준다고 합니다.
Blind 기반 SQL Injection
에러가 발생되지 않는 사이트에서는 위의 기법들을 사용할 수 없어, 정상적인 쿼리여부를 가지고 취약점 여부를 판단하는 기법입니다.
책 [웹 해킹과 시큐어코딩] Part 1에 [시큐어코딩 점검 및 코드수정실습]부분이 있는데, Blind기반 SQL 인젝션 공격을 실제로 해보고 코드 수정을 통해 막는 실습하는 부분이 있어서 해 보았습니다.
먼저 이 책에서 제공하는 Webgoat라는 사이트에 접속하면 다양한 해킹시도를 해볼 수 있는 부분이 있는데, 아래는 input에 싱글쿼터(‘)와 조건문을 이용해서 공격을 시도해본 예 입니다.
webGoat blind기반 sql injection 공격 성공 모습
input에 들어간 내용이 싱글쿼터로 감싸질것을 예상하며 인풋창에 Your Name’ or ‘1’=’1 을 넣어주게 되면 아래 나온 것처럼 셀렉트문이 SELECT * FROM user_data Where last_name = ‘Your Name or ‘1’=’1’ 이런식으로 처리되게 됩니다. 1=1조건이 참이므로, 모든 컬럼을 다 불러와 정보를 노출시키는 전략입니다.
sql injection 취약점이 있는 코드(책 [웹해킹과 시큐어코딩] 예제)
위의 코드를 보시면 위 부분은 외부입력값(accountName)이 쿼리에 직접 삽입되는 Statement방식을 취하고 있습니다. 이는 전형적인 SQL Injection을 보여주는데, 이를 수정하기 위해서는 Preparedstatement방식으로 변경해야합니다.
PreStatement로 바꿔준 코드(책 [웹해킹과 시큐어코딩] 예제)
위와 다르게 직접 변수를 지정하지 않고 ?로 표시하는 바인드 변수형태로 사용합니다. 또한 입력값은 setXXX 형태로 설정하여 입력을 처리하기 때문에 쿼리구조가 사전 컴파일됩니다. 이런식으로 바꾸고 다시 웹사이트에서 input값에 같은 쿼리 공격문을 넣어주면 입력값으로 아무 정보를 불러올 수 없다고 나오게 됩니다.
웹취약점 분석도구에서는 다양한 True/False조건을 요청하여 페이지가 정상적으로 호출되는지를 가지고 취약점을 확인합니다.
Stored Procedure기반 SQL Injection
저장 프로시저는 운영상 편이를 위해 만들어둔 SQL 집합형태이나, 명령어 실행이 가능한 MSSQL의 xp_cmdshell을 악용하여 운영체제 명령어를 삽입하는 기법입니다.
예시) http://www.site.com/member/checkid.asp?id=';CREAT.....r.dbo.xp_cmdshell%20' netstat%20-an’;
위의 예제는 MS SQL에서 사용할 수 있는 xp_cmdshell을 악용하여 윈도우 명령어인 netstat -an(네트워크 상태정보 제공)구문을 삽입하여 공격하는 예입니다.
타임기반 SQL Injection
쿼리 결과를 특정 시간만큼 지연시키는 것을 이용하는 기법으로, Blind 기법과 마찬가지로 에러가 발생되지 않는 조건에서 사용합니다. 지연시키는 방법은 데이터베이스마다 다른데, MSSQL 같은 경우는 wait for delay(0:0:5), MySQL같은 경우는 sleep(5), Oracle같은 경우는 begin dbms_lock.sleep(5); end의 구문을 이용합니다.
예시 ) http://testphp.vulnweb.com/listproducts.php?cat=1 AND SLEEP(5)
위의 예시처럼 공격을 시도한 후, 5초 후에 쿼리 결과가 출력이 된다면 취약점 여부를 확인할 수 있고, 데이터베이스 종류도 예측해볼 수 있는 것입니다.
예시) if(unicode(substring((select isnull(cast(system_user as nvarchar(4000)),char(32))),1,1))>64) waitfor delay ‘0:0:5’ —
이런식으로 유저정보를 한글자씩 아스키코드 숫자와 비교하는 구문을 만들고, delay걸리는 여부를 판단해서 유저정보를 알아내는 방법이 있습니다.
CRLF Injection
CRLF는 CR(Carriage Return : 현재 라인에서 커서의 위치를 가장 앞으로 당기는 것) + LF(Line Feed: 커서의 위치는 그대로 두고 종이를 한라인 위로 옮기는 것)을 의미하며, 따라서 줄바꿈코드를 이용해 공격하는 것을 뜻합니다.
CRLF 인젝션 공격은 위처럼 데이터베이스를 공격하기보다 XSS공격처럼 Client를 직접 공격하는 것입니다. 이는 HTTP의 응답분할 속성과 관련이 있는데, HTTP 응답 분할 속성이란 HTTP Request에 있는 파라미터가 HTTP Response 헤더로 다시 전달되는 경우 파라미터내에 CR, LF가 있는 경우 HTTP 응답 분할이 일어날 수 있는 것을 의미합니다.
이 경우 공격자는 개행문자를 이용하여 첫 번째 응답을 종료시키고 두 번째 응답에 악의적인 코드를 주입하여 XSS 및 캐시 훼손(cache poisoning) 공격 등을 수행할 수 있습니다.
Cache Poisoning공격 [출처] https://secuinfo.tistory.com/entry/WarGame-WebGoat-1-General%EC%9D%BC%EB%B0%98-%EC%B7%A8%EC%95%BD%EC%A0%90-2-2
위 사례가 CRLF를 이용한 캐시훼손 공격인데, 개행문자를 이용하여 파라미터에 last-modified부분을 넣어 헤더값을 변경시켜 놓은 것입니다. 이는 브라우저가 캐싱할 때 혼선을 일으켜 새 페이지를 못받게 하도록 유도할 수 있습니다.
책 Part 1 코드 수정실습부분에서는 이러한 개행문자 처리를 위해서 다음과 같은 filter를 이용할 것을 권장합니다.
Command Injection
GET, POST 요청필드, HTTP 헤더값, 쿠기값 등에 운영체제 명령어를 삽입하여 권한을 획득하는 공격을 의미합니다. 아래는 해당 공격에 대한 책 예제입니다.
/cgi-bin/shoppingcart.cgi?id-1020&page=|cat /etc/passwd&pid=A1023
이렇게 page파라미터에 |cat /etc/passwd를 삽입한 공격인데, 이 구문을 살펴보면 파이프(|) 는 명령어 구분자, cat은 리눅스 명령어로 /etc/passwd파일을 읽는 시도를 하는 것입니다.
웹취약점 분석도구에서는 위와 같이 파라미터에 ;print 1111*2222같은 구문을 삽입한 뒤, request정보에서 명령어가 삽입되어있는지 확인하고 1111*2222값이 화면에 출력되는지 확인하는 과정을 통해 취약점을 탐지한다고 합니다.
지금까지 OWASP에서 선정한 웹 취약점 A1-Injection 공격과 사례에 대하여 알아보았습니다. 앞으로도 나머지 Top 10 공격에 대한 소개가 계속될 예정이니 추후 포스팅도 함께 지켜봐주세요 :) 감사합니다!
[출처]
Union SQL Injection
SQL 인젝션 실제사례
타임기반 SQL Injection
CRLF Injection 정의
Get to know us better! Join our official channels below.
Telegram(EN) : t.me/Humanscape KakaoTalk(KR) : open.kakao.com/o/gqbUQEM Website : humanscape.io Medium : medium.com/humanscape-ico Facebook : www.facebook.com/humanscape Twitter : twitter.com/Humanscape_io Reddit : https://www.reddit.com/r/Humanscape_official Bitcointalk announcement : https://bit.ly/2rVsP4T Email : support@humanscape.io
가입하기
