일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- todo
- 라우터
- 정보시스템
- 써니나타스
- study
- 취약점
- algotithm
- programmers
- meterpreter
- Algorithm
- 웹해킹
- 취약점진단
- ToDoList
- 미터프리터
- Suninatas
- SQL Injection
- 모의해킹
- StringBuilder
- CSRF
- todo List
- wpscan
- Router
- HTML Injection
- stock price
- java
- 모드 설정
- hackerrank
- leetcode
- metasploit
- SQLMap
- Today
- Total
보안 / 개발 챌린저가 목표
모의해킹의 이해 (2) 본문
▶ SQL Injection
- SQL Injection 이란 ?
§ 사용자의 입력 값으로 웹 사이트 SQL 쿼리가 완성되는 약점을 이용하며,
입력 값을 변조하여 비정상적인 SQL 쿼리를 조합하거나 실행하는 공격.
§ 개발자가 생각지 못한 SQL 문을 실행되게 함으로써 데이터베이스를 비정상적으로 조작 가능.
- SQL Injection의 취약점 : 사용자의 입력 값으로 웹 사이트 SQL 쿼리가 완성되는 약점.
- 인증 우회
§ 사용자 인증 우회, 정상적인 사용자의 인증 권한 획득 가능
- 데이터베이스(DB) 획득
§ 의도적으로 DB 에러메시지 유발, DB의 구조 파악 가능
- 취약점 점검 방법
§ 홈페이지 파라미터 값에 특수문자나 임의의 SQL 문을 전달하여 DB 에러 페이지 반환 여부 확인
1) 파라미터
: 사용자 입력 폼 또는 URI의 파라미터 확인
: 링크 클릭 시 웹 프록시를 이용한 파라미터 확인
2) 특수문자
: ' (싱글쿼테이션)
: " (더블쿼테이션)
3) 임의의 SQL 문
: SELECT, UNION, HAVING, GROUP BY 등
▽ 인증 우회
Quick Search 안에 ' (싱글쿼테이션)을 넣어 검색해보면 DB 에러가 나온다.
해당 에러는 개발자가 만든 것이 아닌, DB 자체 에러 문구이다.
폼이 많을 때에는 각각 사용자 입력 폼 마다 모두 점검해야 한다.
①번 검사할 때 : ①에 ', ②에 aaaaa
②번 검사할 때 : ①에 aaaaa, ②에 '
표시한 부분의 게시글을 보여 달라는 URI이다.
page, v_num이 파라미터이다. 이는 사용자 입력 폼이 아니지만 점검을 해줘야한다.
'를 넣어 검색해본다.
'이 %27로 바뀌었다. 이것은 URL 인코딩값이다. %27이 들어오면 '으로 이해한다.
공격자 관점에서 URL 인코딩은 우회 기법이 된다!
ex) v_num=566' ➡ DB에러페이지 확인 ➡ 취약점 판단 ➡ replace=v_num("'", "")
'이 들어오면 ""으로(아무것도 없는 것) 치환!
❗ 이런 경우, 공격자는 '이 아닌 %26로 공격한다.
§ 홈페이지 파라미터 값에 참인 SQL 문과 거짓 SQL 문을 둘 다 입력 후 페이지의 반응이 다른지 확인
1) 참인 SQL 문
: 문자열이 입력 가능한 파라미터인 경우 ex) 'and 1=1 -- / 'or 1=1 --
: 숫자만 입력 가능한 파라미터인 경우 ex) and 1=1 / or 1=1
참을 넣었으므로 모든 게시물이 랜덤으로 출력된다.
검색된 게시물이 없다.
§ 로그인 페이지 사용자 입력 폼에 참인 SQL 문 전달 시 로그인 되는지 확인
1) 참인 SQL 문
: ex) 'or 1=1 --
ID : 'or 1=1 -- / PW : aaaaa
으로 로그인 했을 시,
oyes로 로그인되어 있는 것이 확인된다.
➡ DB에서는 다 SELECT 되는데, 웹 애플리케이션이 첫 번째 정보를 선택해서 보여주는 것!
SELECT *
FROM Members
WHERE user_id = 'or 1=1 --' and passwd = 'aaaaa'
여기에서, -- 뒤는 주석이라 컴파일 과정에서 없어진다.
SELECT *
FROM Members
WHERE user_id = ''or 1=1
이렇게 되는데, '' 과 1=1 둘 중 하나라도 참이면 참이기 때문에 실행된다.
이러한 느낌이라고 볼 수 있다.
ID : 'or 1=1 and user_id='kisec'-- / PW : aaaaa
혹은
ID : kisec'-- / PW : 아무거나~
하면 kisec 계정으로 로그인이 가능하다.
▼ 데이터베이스(DB) 획득
- SQL Injection 공격이 가능한 취약한 페이지 + 기본 에러페이지를 사용하는 경우
- 데이터베이스의 종류를 파악하고 고의적으로 DB 에러페이지를 유발시킴
① 데이터베이스의 종류 알아내기
§ DB 에러메시지에서 획득 가능
: '(싱글쿼테이션) 등을 이용하여 DB 에러메시지 확인
➡ DBMS : MS-SQL
② MS-SQL의 데이터베이스의 이름을 반환하는 함수
§ db_name()
§ db_name()을 이용하여 DB 에러 유발
: ID 입력 칸에 'and db_name() > 1 -- 입력
➡ DB명 : oyesmall
③ HAVING을 이용하여 Table명 및 Column명 파악하기
*HAVING 참고 : https://makand.tistory.com/entry/SQL-HAVING-구문?category=708124
*GROUP BY 참고 : https://makand.tistory.com/entry/SQL-GROUP-BY-구문
'having 1=1 --
입력 시에,
SELECT *
FROM Members
WHERE user_id = ''having 1=1
으로 쓰여진 것이다. HAVING은 GROUP BY랑 써야하기 때문에 오류가 난다.
여기서 알 수 있는 것은, 테이블명 : Members / 첫 번째 컬럼명 : num
④ group by()를 이용한 컬럼명 하나씩 알아내기
'group by(num) --
입력 시에,
SELECT *
FROM Members
WHERE user_id = ''GROUP BY(num) --
두 번째 컬럼명 : user_id
'group by num, user_id --
입력 시에,
세 번째 컬럼명 : passwd
⑤ 회원의 아이디 알아내기
§ 로그인 페이지와 연동하는 DB의 정보
*Table : Members
*Primary Key Column : num
*ID Column : user_id
§ 회원의 아이디를 알아내기 위한 에러구문
'or 1 in(SELECT user_id FROM Members WHERE num > 0) --
* 서브쿼리는 in을 사용!
user_id의 첫 번째 데이터는 oyes 이다.
Q) 회원의 아이디 3개를 알아내보기!
'or 1 in(SELECT user_id FROM Members WHERE user_id not in('oyes', '???')) --
이런 식으로 뒤에 추가 추가를 하며 알아낼 수 있다.
▽ UNION SQL Injection
- UNION 구문
§ 다른 두 테이블의 데이터를 한 테이블에 접합시켜서 출력할 때 사용
§ 열의 갯수와 데이터 타입이 일치해야 함
- 시스템 테이블 ( https://www.mssqltips.com/sqlservertutorial/196/informationschematables/ )
§ information_schema.tables
§ information_schema.columns
- 데이터를 출력해주는 기능을 가진 페이지에서 SQLi 취약점 확인
§ 주소찾기 페이지에서 SQLi 취약점 확인
*'(싱글쿼테이션) 삽입 시 DB 에러페이지 발생
*'or 1=1-- / 'or 1=2-- 삽입 시 페이지의 반응이 서로 다름
§ 원본 테이블의 열의 갯수 파악하기
§ UNION SQLi으로 회원의 아이디와 패스워드 노출
*회원정보가 저장되어 있는 테이블 이름 추측
: 시스템 테이블의 테이블 이름 출력해보기
'UNION SELECT '1', '2', '3', '4', TABLE_NAME FROM information_schema.tables --
'UNION SELECT '1', '2', '3', TABLE_NAME, '5' FROM information_schema.tables --
⇒ members
*회원정보가 저장되어 있는 테이블의 컬럼 이름 추측
: 시스템 테이블을 이용하여 사용자 테이블의 컬럼 이름 출력해보기
'UNION SELECT '1', '2', '3', '4', COLUMN_NAME FROM information_schema.columns --
⇒ user_id, passwd
*회원정보 테이블의 아이디와 패스워드 출력해보기
'UNION SELECT '1', '2', '3', user_id, passwd FROM members --
⇒ 이와 같이 ID PW 순으로 쭉 나오게 된다.
*회원의 아이디와 패스워드로 로그인 해보기
ID : aaaaa / PW : aaaa
잘 로그인이 되었다!
▼ 관리자 권한 명령 실행
- pangolin.exe 를 사용
실습하고 있는 주소를 넣어 데이터가 잘 출력되는지 확인한다.
▷ XSS(Cross Site Scripting)
- XSS란?
§ 외부의 공격자가 클라이언트 스크립트를 악용하여 웹 사이트에 접속하려는 일반 사용자로 하여금
공격자가 의도한 명령이나 작업을 수행하도록 하는 공격
§ 공격자는 이 공격을 이용하여 악성 서버 유도, 사용자 쿠키 정보 추출을 통한 세션 가로채기 공격 등을 수행할 수 있음
§ 즉, 스크립트를 이용하여 웹 사이트 접속자로 하여금 주로 악성 코드 감염 또는 쿠키 탈취를 이용한 권한 획득이 가능한 공격 기법
- 점검문자열
① 반사형 : 시간 단축 측면에서 효율적인 동적인 메커니즘으로 제작되는 경우, XSS 취약점을 유발하는 원인.
따로 기록이 남지 않고 즉각적으로 실행됨.
// XSS 팝업 창 출력
<script>alert("XSS");</script>
Quick Search 칸에 XSS라는 문자열을 alert 창으로 출력하는 스크립트 문을 작성한다.
alert 창이 나오게 된다. 취약한 것!
// Cookie 값 팝업 창 출력
<script>alert(document.cookie);</script>
똑같이 Quick Search 칸에 해당 쿠키 값을 alert 창으로 출력하는 스크립트 문을 작성한다.
쿠키 값도 alert 창에 출력된다. 취약!
② 저장형 : 웹 애플리케이션의 일반적인 입력, 열람 기능을 이용.
악의적 사용자가 입력한 데이터가 필터링 등의 적절한 조치 없이 다른 사용자에게 보여지는 경우 발생.
글을 작성하는 곳에 스크립트 문을 작성 후, 해당 글을 다시 들어가본다.
이와 같이 뜨게 된다. 이 또한 취약한 것이라고 본다.
- 웹 인증 기술
§ HTTP 프로토콜은 연결 비지향적
*클라이언트가 웹 페이지를 요청하고 응답 받으면 서버와 session을 유지하지 않음
➡ HTTP State Less 구성
*로그인 기능 / 내 정보 기능을 이용할 때 서버에서 사용자를 식별해야될 필요성이 생김
*이와 같은 한계를 극복하기 위해 웹 인증 기술이 탄생함
§ Cookie
*로그인 성공한 사용자에게 서버에서 고유한 Cookie 값을 만들어서 보내줌
*사용자 PC에 저장된 Cookie 값을 전송받은 서버는 해당 Cookie 값을 확인하고 사용자를 식별
*Cookie 기술은 사용자가 전송한 값을 무조건 신뢰함
➡ 조작을 통해 타 사용자로 변경하거나 관리자 권한 획득이 가능한 위험성이 존재
§ Session
*사용자가 보내는 Session 정보를 서버에 저장된 Session 정보와 비교 검증 보안 신뢰성 확보할 수 있는 기술
§ JWT
*사용자가 보내는 Token 정보를 서버에 저장된 Token 정보와 비교 검증 보안 신뢰성 확보할 수 있는 기술
'IT Security > Class' 카테고리의 다른 글
모의해킹의 이해 (1) (0) | 2020.10.05 |
---|---|
Window Batch File (0) | 2020.09.23 |
정보 시스템의 이해와 취약점 진단 기준 (0) | 2020.09.14 |
어플리케이션(Application) 보안 (0) | 2020.09.13 |
IPS(Suricata) 구축 (0) | 2020.09.09 |