hacking study/모의 해킹 프로젝트

정보보안 스터디 - 18주차 1일 - 쿠키/세션 취약점, 취약한 HTTPS 4종 세트

wonder12 2023. 2. 10. 13:03

 

 

☞ 기존 보고서 피드백 및 수정

 

최대한 볼드 체를 쓰지 않고 알록달록하게 하는 게 아니라, 그리고 폰트 크기도 최대한 10으로 맞추되

정말 강조해야할 부분이나, 목차같은 부분에서만 bold와 12, 11 정도의 폰트 크기를 사용합니다.

 

 

SQLi 같은 경우에는 

union 방식 등 중복되는 방식이 많습니다.

이럴 경우 정말 대표적인 예시만 작성하고 중복되는 걸 적지 않습니다.

또한 모든 자세한 기술적인 내용, STEP을 개발자가 알 필요가 없습니다.  증명만 하면됩니다.

Step 1. 회원가입 페이지에 접속 및 글 작성 페이지 이동
Step 2. database명을 알아내는 SQL문 삽입
Step 3. ~~ 파라미터에 UNION문 삽입으로 DB명을 추출 하는 것을 확인.
--- 만약 일반적인 데이터 추출이아니라, python 코드를 삽입하여 실행 하여 하는 등 다른 방식과 연계하여 제한된 데이터를 추출할 수 있을 경우에는 step4로 적어줍니다. 
Step 4. python 코드 를 이용해 추출가능.

 

 

XSS 같은 경우에는 

Stored XSS는 

Form URL: 글 작성, 수정하는 페이지
Process URL: 삽입되어 적용되는 페이지
View URL: 스크립트가 실행되는 페이지

로 나눠서 다른 사람을 위해서가 아니라

나중의 이행 점검을 할 때 파라미터와 URL 링크에 대해서 헷갈리지 않도록, 본인을 위해서 작성하는 것입니다.

 

Reflected XSS는

Process URL, View URL(PoC코드) 

정도로 나눌 수 있을 것 같네요.

 

 

 

☞ 이행 점검 시 유의사항

실력자 분들이 신규 취약점 점검을 나가고

기존에 했던 사람이 이행점검이라는 것을 나가야 할 것 같지만

그게 아니라 이행점검은 신입분들이 많이 나갑니다.

 

그래서 기존에 점검했던 분이 못잡은 취약점이 발견됐을 때

말하는 경우가 있고 말하지 않는 경우가 있습니다.

소속 PM 또는 영업 분에게 여쭤보거나 

해당 회사의 담당자와 친해졌을 경우에는 신규 취약점 발견건은 어떻게 할지 물어보고 

이행점검 - [신규] 로 작성을 하거나, 해당 URL과 파라미터만 전송해주고 처리하는 경우도 있습니다.

 

말하지 않을 경우는 그래도 기존에 하셨던 분의 전문성을 지켜주기 위해서나 영업분들이 꺼려할 수 있기 때문에

예를 들어 Reflected XSS 하나 정도 발견하는 심각하지 않을 경우에는 넘어가는 경우도 있습니다.

 

고객사에서 마음에 들지 않는 등 일이 더 커질 우려가 있기 때문에 말하지 않는 경우가 더 많습니다.

 

 

 

 

 

 

☞ 불충분한 세션 종료처리

1) 세션만료시간을 정하지 않아서, 아무런 동작이 없을 때 2~3시간 이후에도 세션이 파기되지 않아 사용할 수 있는점

2) 로그아웃을 했을 때 세션이 파기(destroy)되지않고 여전히 사용이 가능한 점 

- 여기에서 파기는 되었는데 재생성 되지 않는 경우인지 헷갈리긴 합니다.

 

 

사실 웹 브라우저에서 로그아웃을 한 게 아니라 브라우저 창을 닫았는지 정확하게 확인할 방법은 없습니다.

그래서 php에서의 세션타임아웃 설정이란 그냥 아무행동이 없을 때 세션이 만료 후 재생성되는 것입니다. 

사실 그럴려면 javascript로 1초 간격으로 핑을 쏴줘야하는데 그럴 수는 없기 때문입니다.

그래서 보통 세션이 오래 유지되는 취약점은 그렇게 심각하게는 잡지 않는 편입니다. 너무흔해서 굳이 하지 않고 나머지 심각한 것들이 있으면 적는 편입니다. 

 

위의 취약점들은 테스터들도 오해의 소지가 있으니 싸울 수 있어 헷갈리지 않게 정확하게 인지하고 잡고 갑니다.

그리고 정말 긴가 민가한 것은 실무에서 잘 못 잡았다가 더 귀찮아 질 수 있어서 잡지 않습니다.

 

 

 

☞ 세션정보 재사용

세션을 탈취한 후 공격자가 세션으로 접근하여 권한사용이 가능한지를 말하는겁니다.

근데 원래는 누가 진짜 유저인지 구분할 수 없습니다.

 

 

중복세션탐지를 IP주소로 할 수도 있습니다.

IP주소는 웹 브라우저에서 기록이 됩니다.

그래서 같은 세션이지만 IP주소가 다를 때는 점검을 합니다.

 

다른 브라우저를 이용하거나 가상머신을 돌려도 결국 사설 IP만 조금 달라지고

같은 외부 IP를 사용하는 것이기 때문에 점검이 어렵습니다. 

모바일 기기로 점검하면 다른 IP주소로 접근할 수 있기 때문에

해당 세션을 점검할 수 있습니다.

 

모바일 기기의 myIP에 접속한 결과를 보고서에 적습니다.

 

하지만 IP는 위치 즉 cellzone이 변경됨에 따라 달라질 수 있기 때문에 점검 기준이 애매합니다.

해당 고객사의 개발자들이 고치고 나서 이행점검 해주세요 하고 왔을 때 

IP가 다른 기기로 접속해도 똑같이 세션 접속이 되기 때문에 난감합니다.

IP를 이용한 애매한 부분 같은 경우에는 정확하지 않아 그런 취약점은 안 잡는 경우도 있습니다.

 

 

MAC주소가 고정된 ID역할을 하기 때문에 해볼까? 하고 접근할 수도 있지만

웹 브라우저에 요청할 수 있는 방법이 없습니다.

script로 잡아야하는 데 불가능하고, 외부 프로그램을 다운받아 이용하는 방법이 있지만 모든 유저를 대상으로 하지 못합니다. 모바일 기기는 가능하지만 말이죠

 

 

 

 

 

 

 

☞ 취약한 HTTPS 4종 세트 취약점

 

만약 HTTPS 암호화 프로토콜을 사용하지 않는다면, 평문전송이 되는지를 확인 후 데이터 평문전송 카테고리로 분류하면됩니다.

HTTPS를 사용할 경우

HTTPS 4종 세트에 대한 점검은 아래와 같이하고 TLS 버전을 캡쳐하여 하나의 카테고리에만 적으면됩니다.

 

 

 

점검은 도구 또는 사이트에 진행 가능합니다.

 

1. https://github.com/hahwul/a2sv

 

GitHub - hahwul/a2sv: Auto Scanning to SSL Vulnerability

Auto Scanning to SSL Vulnerability. Contribute to hahwul/a2sv development by creating an account on GitHub.

github.com

도구를 다운받아서 위 취약점을 확인 후 기록하는 방법입니다.

 

 

 

2. https://www.ssllabs.com/ssltest/

 

처음에 보안 등급이 뜹니다. 대부분 등급이 낮겠지만 네이버같은 개발을 잘한 사이트는 이렇게 좋은 점수가 뜹니다.

 

 

WEAK이 아닌 DANGEROUS 의 경우에 더심각하므로 잡습니다.

 

DES, 3DES 암호화를 사용중일 때 취약점하기 때문에 잡습니다.

 

 

 

예를 들어 naver.com 이라는 도메인 이름을 검색했을 때 

해당하는 사이트의 https 상태를 확인해줍니다.

현재 TLS 1.3, 1.2 버전 수준이 가장 안전한 버전이며 YES가 아니라 NO로 뜰 경우 그 부분을 캡쳐해서 취약점으로 잡습니다.

따라서 이전 버전인 SSL 3.0 , 2.0 등을 사용할 경우에는

POODLE이나 BEAST공격, HEART BLEED 취약점 등이 발생할 수 있기 때문에 위험합니다. 그 외로도 나머지가 있긴해서 찾아보면 좋을 듯합니다.

POODLE은 연구실에서 개발한 취약점이라서 그런지 실질적으로 해커들이 사용하기에는 현실성이 많이 떨어집니다.

먼저 XSS가 가능한 조건이여야하며, PoC 코드 즉 스크립트의 길이가 매우 길며 반복적으로 보내는 등 조금 복잡합니다. (Github에서 확인 가능합니다)

SSL은 통째로가 아닌 블록으로 나눠 암호화를 하는 방식을 사용하는 데

이 때

10글자 기준으로 암호화가 진행된다고 했을 때

aaa 3글자를 넣으면 + @@@@@@@ 패딩이 7글자가 추가되어 암호화 해야됩니다.

이 때, 공격자는 공격코드를 임의로 패딩을 만듭니다. 그러면 암호화했던 내용을 복호화하여 평문으로 읽을 수 있습니다.

 

BEAST 공격도 마찬가지입니다.

그 외로도 암호화 프로토콜이 아닌 암호화 방식에 대한 내용도 나오고

기기별 점검을 다르게 한 정보도 참고하면 좋을 것 같습니다.

 

사실 XSS가 된다면 다른 것이 더 취약할 것 같긴합니다.  그래도 여지가 있기 때문에 취약한 것은 마찬가지입니다.

 

위의 취약점도 사실 크게 critical한 취약점은 아니라서 다른 위험한 취약점을 쓰고 아주 없을 경우 위의 방법으로 씁니다.

 

 

 

 

 

 

 

☞ SSRF

간단하게 설명하자면

CSRF (클라이언트 측 요청 변조)의 반대 개념인

서버 측 요청을 변조하는 취약점입니다. 

그러니까 CSRF가 클라이언트 측이 자신도 모르게 어떤 요청을 하도록 하는 것이였다면

서버 측이 요청하도록 만드는 것입니다.

 

 

예를 들어 웹 서버와 네트워크를 공유하고 있는 내부 서버에 직접적으로 접근하지는 못하지만

웹서버를 통해서 내부 파일에 접근하거나, ftp: 등으로 다른 서버에 접근합니다.

 

그러니까 대표적으로 원래는 어떤 파라미터에 외부URL을 적어

해당 URL에 요청을 보내서 파일을 가져오는 거였다면

그 URL 파라미터에 내부주소를 적어서 접근을 합니다.

 

보통 자기 자신에게 요청을 주는 경우가 많습니다.

siteURL=http://127.0.0.1/etc/passwd 등의 파일을 가져옵니다.

siteURL=file://127.0.0.1

 

 

 

금취분평에서 전자금융을 제외한 기준으로 잡기도하고 

주통기반을 기준을 잡기도 합니다. 

해당 취약점이 무엇인지, 왜 위험한지 정확하게 설명할 수 있어야합니다.

 

 

 

저작자표시