세션을 해킹하고 도난으로부터 보호하는 방법
대부분의 인터넷 사이트는 해커의 외부 영향에 열려 있습니다. 대규모의 값비싼 인터넷 프로젝트도 해킹을 당합니다. 흔적을 남기거나 데이터베이스를 제거합니다. 결과적으로 리소스 소유자는 물론 방문자도 고통을 겪습니다.
해킹 문제를 피하기 위해서는 개발 과정에서 여러 가지 조치가 필요합니다. 사이트 운영 중에 몇 가지 예방 조치를 수행해야 합니다.
지난 기사에서 서버뿐만 아니라 서버가 수행되는 방식을 보여주었습니다. 오늘 우리는 해커에 의한 세션의 가로채기와 보호에 대해 이야기할 것입니다.
사이트 세션
PHP는 아마도 웹사이트를 위한 가장 일반적인 서버 측 프로그래밍 언어일 것입니다. PHP에서 session_start() 명령을 사용하여 웹 사이트 세션을 시작합니다. 시작하기 전에 다음을 지정할 수 있습니다. 추가 옵션. 세션은 일반적으로 사용자에 대한 중요한 개인 정보(로그인, 이름, 비밀번호, ..)를 저장합니다.
세션 하이재킹
세션 ID를 저장하는 두 가지 방법이 있습니다. 쿠키와 주소 표시 줄. 첫 번째 옵션은 두 번째 옵션보다 더 안전하지만 둘 다 다양한 정도로 해킹할 수 있습니다. 이 유형해킹을 세션 하이재킹이라고 합니다.
식별자를 사이트 URL에 저장합니다. 로그인한 방문자가 사이트 페이지를 탐색하면서 누군가와 함께 결정합니다. 링크를 게시할 때 그는 자신의 세션 ID와 함께 링크를 제공합니다. 사이트에 추가 보호 방법이 없는 경우 해당 링크를 클릭하면 세션이 아직 종료되지 않은 경우 새 방문자가 이미 첫 번째 사용자로 로그인됩니다. 그런 다음 규칙이 허용하는 한도 내에서 사이트에서 원하는 작업을 수행합니다.
쿠키를 사용하면 상황이 더 복잡해 지지만 모든 것이 매우 쉽게 가로챌 수 있습니다. 많은 사이트는 사용자가 정보를 게시할 때 브라우저 스크립트를 필터링하지 않습니다. 잠재적인 해커가 페이지에 이러한 스크립트를 배치합니다. 로그인한 방문자가 페이지를 방문합니다... 스크립트는 쿠키 값이나 주소 표시줄을 읽고 세션 ID를 다른 사이트로 전달합니다. 다른 사이트는 해커에 속합니다. 또한 모든 것이 간단합니다. 쿠키를 위조하거나 원하는 세션 ID를 가진 사이트 페이지의 주소를 입력합니다.
세션 해킹
세션이 시작되면 임시 디렉토리에 세션 파일이 생성됩니다. 이 파일은 정보를 저장합니다. 사용하는 경우 일반적으로 세션을 저장하기 위한 임시 폴더는 서버의 모든 사이트에서 공유됩니다. 또한 특정 방식으로 세션 데이터는 자체 스크립트에 의해 읽힙니다. 이렇게 하려면 공격자는 동일한 서버에 계정이 있어야 합니다. 결과적으로 사이트의 암호 또는 cvv 코드가 있는 신용 카드 번호가 세션에 저장되어 있으면 이 모든 유용한 정보공격자의 손에 넘어갑니다.
세션 데이터 해킹 방지
- 세션을 쿠키에 저장합니다. 복용하기가 더 어렵습니다.
- 세션을 컴퓨터의 IP 주소에 바인딩합니다. 다른 ip에서 진입 시 스크립트 설정에 따라 새로운 세션이 생성됩니다.
- 세션을 브라우저의 사용자 에이전트에 바인딩합니다. 다른 브라우저에서 로그인하면 세션이 0으로 재설정됩니다.
- 세션에 전달된 매개변수를 암호화합니다. 공격자가 세션 파일을 가져오면 읽을 수 없습니다. 특정 기술이 있으면 세션을 해독하는 것도 가능합니다.
- 세션 ID를 별도의 폴더에 저장합니다. PHP에는 이를 위한 session_save_path($path_to_dir) 명령이 있습니다. 동일한 설정을 php.ini 파일에 작성할 수 있습니다. 매개변수는 session.save_path라고 합니다.
- 세션이 저장되는 방식을 재정의하려면 PHP에서 session_set_save_handler()를 사용하십시오. 그리고 PHP 5.4부터 SessionHandlerInterface 유형의 객체를 session_set_save_handler()에 전달할 수 있습니다.
많은 사용자는 폐쇄된 인터넷 리소스에 등록하거나 인증할 때 로그인과 비밀번호를 입력하고 ENTER를 누르면 이 데이터가 쉽게 가로챌 수 있다는 사실조차 깨닫지 못합니다. 매우 자주 보안되지 않은 형태로 네트워크를 통해 전송됩니다. 따라서 로그인하려는 사이트가 HTTP 프로토콜을 사용하는 경우 이 트래픽을 캡처하고 Wireshark를 사용하여 분석한 다음 특수 필터와 프로그램을 사용하여 암호를 찾고 해독하는 것이 매우 쉽습니다.
암호를 가로채기에 가장 좋은 곳은 네트워크의 핵심으로 모든 사용자의 트래픽이 외부 리소스에 등록할 때 인터넷에 액세스하기 위해 폐쇄된 리소스(예: 메일)로 이동하거나 라우터 앞에 있습니다. 우리는 거울을 설치하고 해커처럼 느낄 준비가 되었습니다.
1단계. Wireshark를 설치하고 실행하여 트래픽 캡처
때로는 이를 위해 트래픽을 캡처할 인터페이스만 선택하고 시작 버튼을 클릭하는 것으로 충분합니다. 우리의 경우 무선으로 캡처합니다.
트래픽 캡처가 시작되었습니다.
2단계. 캡처된 POST 트래픽 필터링
브라우저를 열고 사용자 이름과 암호를 사용하여 모든 리소스에 로그인을 시도합니다. 승인 프로세스가 완료되고 사이트가 열리면 Wireshark에서 트래픽 캡처를 중지합니다. 그런 다음 프로토콜 분석기를 열고 많은 수의 패킷을 확인합니다. 대부분의 IT 전문가들이 다음에 무엇을 해야 할지 몰라 포기하는 단계입니다. 그러나 우리는 화면의 양식을 작성할 때 로컬 시스템에서 생성되어 원격 서버브라우저에서 "로그인" 또는 "인증" 버튼을 클릭할 때.
캡처된 패킷을 표시하려면 창에 특수 필터를 입력하십시오. http.요구.방법 == "게시하다"
수천 개의 패키지 대신 찾고 있는 데이터가 포함된 패키지 하나만 볼 수 있습니다.
3단계. 사용자 이름과 비밀번호 찾기
빠른 클릭 오른쪽 버튼마우스를 누르고 메뉴에서 선택 TCPSteam 팔로우
그런 다음 코드에서 페이지 내용을 복원하는 새 창에 텍스트가 나타납니다. 비밀번호 및 사용자 이름에 해당하는 "비밀번호" 및 "사용자" 필드를 찾아보겠습니다. 경우에 따라 두 필드 모두 읽기 쉽고 암호화되지도 않지만 Mail.ru, Facebook, Vkontakte 등과 같이 잘 알려진 리소스에 액세스할 때 트래픽을 캡처하려고 하면 암호는 다음과 같습니다. 인코딩:
HTTP/1.1 302 발견
서버: Apache/2.2.15(CentOS)
X-Powered-By: PHP/5.3.3
P3P: CP="NOI ADM DEV PSAi COM NAV OTro STP IND DEM"
쿠키 설정:비밀번호= ; 만료=2024년 11월 7일 목요일 23:52:21 GMT; 경로=/
위치: login.php
콘텐츠 길이: 0
연결: 닫기
콘텐츠 유형: 텍스트/html; 문자 집합=UTF-8
따라서 우리의 경우:
사용자 이름: networkguru
비밀번호:
4단계비밀번호를 해독하기 위한 인코딩 유형 결정
예를 들어 http://www.onlinehashcrack.com/hash-identification.php#res 사이트로 이동하여 식별 창에 비밀번호를 입력합니다. 우선 순위에 따라 인코딩 프로토콜 목록을 받았습니다.
5단계: 사용자 암호 해독
이 단계에서 hashcat 유틸리티를 사용할 수 있습니다.
~# 해시캣 -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt
출력에서 해독된 암호: simplepassword를 받았습니다.
따라서 Wireshark의 도움으로 우리는 응용 프로그램 및 서비스 운영의 문제를 해결할 수있을뿐만 아니라 사용자가 웹 양식에 입력하는 암호를 가로채어 해커가 될 수 있습니다. 당신은 또한 암호를 찾을 수 있습니다 사서함단순 필터를 사용하여 다음을 표시하는 사용자:
- POP 프로토콜과 필터는 다음과 같습니다. pop.request.command == "USER" || pop.request.command == "통과"
- IMAP 프로토콜 및 필터는 다음과 같습니다. imap.request에는 "로그인"이 포함되어 있습니다.
- SMTP 프로토콜을 사용하고 다음 필터를 입력해야 합니다. smtp.req.command == "인증"
인코딩 프로토콜을 해독하기 위한 더 심각한 유틸리티.
6단계. 트래픽이 암호화되고 HTTPS를 사용하는 경우 어떻게 됩니까?
이 질문에 답할 수 있는 몇 가지 옵션이 있습니다.
옵션 1. 사용자와 서버 사이의 연결이 끊어진 상태로 연결하고 연결이 설정되는 순간의 트래픽을 캡처합니다(SSL Handshake). 연결 설정 시 세션 키를 가로챌 수 있습니다.
옵션 2: Firefox 또는 Chrome에서 작성한 세션 키 로그 파일을 사용하여 HTTPS 트래픽을 복호화할 수 있습니다. 이렇게 하려면 브라우저가 이러한 암호화 키를 로그 파일(FireFox 기반 예)에 기록하도록 구성해야 하며 이 로그 파일을 받아야 합니다. 기본적으로 다음을 사용하여 세션 키 파일을 훔쳐야 합니다. 하드 드라이브다른 사용자(불법). 그런 다음 트래픽을 캡처하고 수신된 키를 적용하여 암호를 해독합니다.
설명.우리는 비밀번호가 도난당한 사람의 웹 브라우저에 대해 이야기하고 있습니다. 자체 HTTPS 트래픽의 암호 해독을 의미하고 연습하려는 경우 이 전략이 작동합니다. 컴퓨터에 액세스하지 않고 다른 사용자의 HTTPS 트래픽을 해독하려고 하면 작동하지 않습니다. 이것이 바로 암호화 및 개인 정보 보호를 위한 것입니다.
옵션 1 또는 2에 따라 키를 받은 후 WireShark에 등록해야 합니다.
- 메뉴 편집 - 기본 설정 - 프로토콜 - SSL로 이동합니다.
- "여러 TCP 세그먼트에 걸친 SSL 레코드 재조립" 플래그를 설정하십시오.
- "RSA 키 목록"을 클릭하고 편집을 클릭합니다.
- 모든 필드에 데이터를 입력하고 키를 사용하여 파일에 경로를 씁니다.
에 지난 몇 년인터넷 TLS/SSL을 위한 가장 중요한 보안 프로토콜에 대한 특수 서비스에 의한 공격 전략의 추세에 변화가 있습니다. 이제부터 직접적인 암호화 공격 및 해킹은 더 이상 극단적일 뿐만 아니라 프레임워크 내에서 불필요한 경우가 많습니다. 현대 세계돈과 금전적 이득이 주된 원동력이 되는 척도.
이 문제의 중요성 때문에 일련의 간행물의 일부로 이 사이트는 TLS/SSL 프로토콜 스택의 보안에 대한 개요를 제공하는 동시에 정보 기관이 이러한 프로토콜을 약화시키기 위한 일관되고 체계적인 전략을 고려합니다.
전 세계 보안 트래픽의 3분의 1이 생성됩니다. 암호화 수단의도적으로 약화 된 PRNG로?
채널에서 삭제됨
종자로서 러시아의 예를 살펴 보겠습니다 - 사건의 마지막 법원 청문회 전 소유자 지불 시스템 Aeroflot에 대한 DDoS 공격으로 기소된 Chronopay Pavel Vrublevsky.
핵심 음모의 본질은 법원이이 범죄 과정에서 참가자들 사이에 내부 통신을 요청했다는 사실에 요약되어 있습니다. 개인 계정페이스 북에서. 가장 중요한 범죄 정보를 담고 있음에도 불구하고, 교활한 미국 소셜 네트워크러시아 정의의 요청에 귀를 기울이지 않았고 러시아 연방 시민의 사적인 서신에 대한 접근을 거부했습니다. 그런 다음이 이야기에서 매우 극적인 전환점이 발생합니다. FSB는 법원 결정을 실행할 때 이러한 시민들의 서신을 독립적으로 "추출"합니다.
"FSB의 중앙 정보국은 "조작-수사 활동"에 관한 법률에 따라 이 사람들의 통신 채널에서 정보를 독립적으로 검색하여 DVD에 기록했습니다."
실제로, 나중에 변호인 측은 페이스북의 의지에 반해 필요한 개인 서신이 "네트워크에서 전체 및 범위에서 제거"되었음을 확인할 수 있었습니다. 동시에, 이 사건의 피고인들은 자신의 비밀번호와 자책하는 서신을 조사에 제공하는 것을 거부했습니다. RuNet에서 "The Russian FSB Hacked Facebook Servers"와 같은 화려한 뉴스 헤드라인을 찾을 수 있지만 너무 성급하게 결론을 내리면 안 됩니다.
첫째, Facebook과의 모든 통신 세션은 보안 HTTPS 통신 프로토콜을 통해서만 수행됩니다. 둘째, 피고인과 피고인의 마지막 접촉 이후 이 결정법원(결과적으로 이 결정을 집행하기 위한 FSB의 조사 조치)에 많은 시간이 흘렀습니다. 피고인 자신이 그 이후로 조사를 받고 온라인에 접속하지 않은 경우 이러한 "과거 데이터"를 어떤 종류의 "채널"에서 "제거"할 수 있습니까?
그들은 재판 중에 FSB 대표에게 가해지는 이러한 직접적인 질문을 무시했습니다. 대답의 가장 확실한 버전은 스스로 제안했습니다. 이 통신이 포함된 HTTPS 트래픽은 FSB에 의해 미리 스니핑/저장되었고 어떻게든 이후에 해킹되었습니다.
거의 유사한 사례가 같은 사례의 자료에 더 일찍 기록되어 있다는 점이 흥미롭다. FSB CIB는 수사 프로토콜을 인용하여 “피고인 중 한 사람의 인터넷 연결 트래픽을 저장 및 분석하여 봇넷 제어판(물리적으로 미국 서버에 위치)에서 로그인 및 비밀번호를 복구”한 후 이 봇넷에 대한 원격 제어를 탈취했습니다. 따라서 동일한 웹 패널에 대한 액세스는 보안 조치(예: 로컬 컴퓨터에 비밀번호 저장 없이)에 따라 암호화된 HTTPS 연결을 통해서만 피고가 수행했습니다.
따라서 러시아 특수 서비스에 의해 TLS/SSL의 "보호"를 극복한 놀라운 사례를 인용하여 HTTPS 보안에 문제가 있음을 나타냅니다.
운영 방식
암호화된 HTTPS 세션을 해독하려면 두 가지 주요 작업을 해결해야 합니다. 트래픽을 수신(차단)할 수 있어야 하고 보안 패킷에 캡슐화된 데이터를 해독할 수 있어야 합니다.
특수 서비스는 거의 모든 채널에 물리적으로 액세스할 수 있기 때문에 첫 번째 요점에 대해서는 언급하지 않겠습니다. SORMomostroeniya의 최신 뉴스를 팔로우하는 사람들은 2014년 7월 1일부터 새로운 법률에 따라 모든 러시아 공급자가 네트워크에 특수 장비를 설치하여 전체 전송 인터넷 트래픽을 기록하고 저장해야 한다는 것을 이미 알고 있습니다. 기간은 최소 12시간입니다. 또한 보안군은 모든 저장 및 전송 데이터 어레이에 직접 액세스할 수 있습니다.
Gmail에서 "귀하의 계정이나 컴퓨터가 특정 국가에서 지원하는 해커의 영향을 받았을 수 있습니다"라고 알려줍니다.
— 로만 도브로호토프(@Dobrokhotov) 2014년 9월 9일
HTTPS 세션 수신에 대해 이야기하면 즉시 중요한 점- 저장된 트래픽이 나중에 항상 해킹될 수는 없기 때문에 경우에 따라 "액티브 모드" 청취가 필요합니다. 우리는 통신 세션이 끝난 후(공격자가 나중에 유효한 사이트 키를 얻을 수 있더라도) 데이터를 복구할 가능성을 방지하는 HTTPS 프로토콜에 대한 소위 점진적 비밀 모드(순방향 비밀, FS)에 대해 이야기하고 있습니다. 이러한 모드의 존재는 공격자가 "뜨거울 때 철을 위조"해야 합니다. 즉, 대부분의 경우 기술적으로 거의 불가능한 실시간으로 데이터를 해독해야 합니다.
나쁜 소식은 Facebook이 다른 대부분의 주요 인터넷 포털과 마찬가지로 순방향 비밀 모드를 사용하지 않는다는 것입니다. 이미 과부하가 걸린 소셜 시스템에 심각한 부담을 주기 때문입니다. 또한 이러한 고급 DH 알고리즘을 사용하면 일부 인기 있는 브라우저와의 호환성에 부정적인 영향을 미칠 수 있습니다. Netcraft 통계에 따르면 2013년 여름 현재 이 모니터링에서 관찰된 SSL 연결의 약 70-99%가 FS를 전혀 사용하지 않는 이유를 이제 쉽게 알 수 있습니다.
즉, 대부분의 경우 공격자가 나중에 선택하고 해킹할 수 있도록 HTTPS 트래픽을 안전하게 저장할 수 있습니다(예: 개인 서버 키가 알려진 경우).
위는 각각 DHE가 활성화 및 비활성화된 6코어 웹 서버 프로세서의 성능 저하 측정입니다. DHE는 Perfect Forward Secrecy의 가장 대중적이고 모범적인 구현으로 선택되었습니다. 예를 들어, 서비스가 거의 모든 암호화 혁신과 사용자 보호 수단을 지원하는 Google(이는 일반적인 인터넷 관행에 대한 현저한 예외임)은 ECDHE_RSA를 기반으로 하는 단기("임시") PFS 세션 키를 구현합니다. 그리고 그것은 매우, 매우 비쌉니다. 저를 믿으십시오!
이 언급을 감안할 때 우리는 트래픽 차단으로 모든 것이 다소 명확하다고 가정합니다. 이제 저장된 암호화된 스트림으로 다음에 수행할 작업을 고려해 보겠습니다.
이 경우 일반 알고리즘은 다음과 같이 보일 것입니다. 관심 있는 트래픽을 가로챌 때 가상의 특수 서비스가 HTTPS 세션을 가로챕니다. 정보시스템해당 데이터베이스에 대한 해당 서버 키에 대한 검색 요청을 수신합니다. 그러한 키가 발견되지 않으면 추가 계산(크래킹)을 위해 대기합니다. FS 옵션의 실제 사용 불가능성에 대한 언급을 고려하면, 시스템이 실시간으로 복호화를 위한 키의 준비/가용성에 대해 응답할 때까지 기다리지 않고 관심 있는 트래픽을 조용히 누적(쓰기)하는 것이 항상 합리적입니다.
언급 된 데이터베이스와 관련하여 서버 키, 그리고 2013년 여름에 Cnet은 익명을 원하는 대규모 인터넷 회사에 NSA 요청의 정보와 예제 문서를 게시했습니다. 이 소식통에 따르면 다른 주요 인터넷 사이트(구글, 마이크로소프트, 애플, 야후, AOL, 버라이즌, AT&T 등)에서도 같은 요청을 받은 것으로 알려졌다. 씨넷은 공식적으로 이들 기관에 연락해 논평을 요청했다. 유사한 요청그러나 대부분의 경우 회사는 NSA와의 이러한 상호 작용을 확인하거나 거부하는 것을 거부했습니다.
“오픈 소스가 신뢰성으로 가는 길이라는 신화에 다시 한 번 발을 씻습니다. Debian OpenSSL의 이 버그는 거의 2년 전의 일입니다."
실제로 언론의 소란이 일어난 후에야 이 취약점을 닫는 것이 가능했습니다. 데비안 프로젝트 자체는 OpenSSL 저장소의 오랜 버그가 있는 상황을 "다소 이상한 이야기"라고 불렀습니다.
악명 높은 하드웨어 "북마크"에 대해 이야기하면 최근에 다리미에서 커피 머신에 이르기까지 가장 예상치 못한 곳에서 이미 폭력적인 색으로 꽃을 피웠습니다. 따라서 NSA "특수 접근 작전"(Tailored Access Operations, TAO)의 특별 부서인 Spiegel에 따르면 오랫동안가장 많이 구매한 대량 차단을 수행했습니다. 다른 회사그리고 공급자로부터 수취인에게 가는 도중에 컴퓨터 장비의 국가(뿐만 아니라). 동시에 NSA의 관심 고객에게 배송된 차단된 장비는 수정된 소프트웨어 또는 "버그"가 도입된 비밀 TAO "공장"을 빠르게 통과했습니다. "차단"이라는 특수 용어로 표시되는 자체 목적을 위한 공급망에서의 이러한 개입은 NSA 자체에서 "가장 효과적인 현대적 운영 유형" 중 하나로 평가되었습니다.
NSA는 Tailored Access Operations의 일환으로 잠재적으로 수백만 대의 컴퓨터를 맬웨어로 감염시킬 계획입니다.
활성화된 경우 모든 트래픽(암호화 및 비암호화)또는 암호화만에이전트는 SSL 인증서 스푸핑 기술을 사용하여 보안 웹 세션에서 전송되는 데이터를 가로챕니다. 서버와의 보안 연결을 설정할 때 에이전트는 원래 서버 인증서를 동일한 이름의 인증서로 교체하지만 에이전트의 루트 인증서에서 발급합니다. 시스템을 사용하면 사전 설치된 인증서와 서명 권한이 있는 수동으로 만든 인증서를 루트로 사용할 수 있습니다.
인증서를 서버에 연결하여 해당 서버(웹사이트, 프로그램)의 세션을 가로챌 때 대체할 특정 인증서를 수동으로 설치할 수 있는 시스템입니다.
경우에 따라 원본이 아닌 인증서를 사용하면 서버에 암호화된 연결을 설정하지 못할 수 있습니다. 이 경우 해당 서버를 가로채기에서 제외해야 합니다. 이러한 서버에 연결할 때 SSL 인증서의 대체를 금지합니다. 이렇게 하면 해당 사이트나 프로그램의 기능이 복원되지만 암호화된 트래픽은 가로채지 않습니다.
SSL 트래픽 가로채기를 구성하려면:
- 탭 창에서 에이전트 설정 프로필프로필 편집 영역에서탭 선택 네트워크 트래픽 제어.
- 버튼을 클릭 SSL 가로채기 옵션현재 단락의 권장 사항을 따르십시오.
SSL 인증서 스푸핑 모드 선택
설정 창에서 허용 가능한 차단 모드를 선택합니다.
- 자동 생성용에이전트 설치 중 SSL 루트 인증서사용자의 컴퓨터에 옵션을 선택하십시오. 자동 모드 . 생성된 루트 인증서는 신뢰할 수 있는 인증서 발급자 데이터베이스에 저장되고 에이전트가 자동으로 사용하여 발급자 이름이 Falcongaze SecureTower 로 기본적으로 서명된 하위 인증서를 발급합니다.
연결 보안 정보에 표시될 인증서 발급자의 이름을 변경하려면 필드에 원하는 이름을 지정하십시오. 이름 SSL 인증서 .
- 암호화된 트래픽을 가로챌 때 사용자 지정 SSL 인증서를 루트 인증서로 사용하려면옵션을 선택하세요 사용자 모드. 사용자 인증서는 미리 생성되어 시스템 데이터베이스에 추가되어야 합니다. 시스템 데이터베이스에서 인증서를 지정하려면 드롭다운 목록에서 해당 이름을 선택합니다.사용자 인증서또는 버튼을 클릭하십시오사용자 인증서시스템 데이터베이스에 인증서 및 개인 키 파일을 추가합니다.
열리는 창에서 버튼을 클릭하십시오 인증서 추가다음 방법 중 하나로 인증서 및 키 파일을 지정합니다.
- 새 인증서를 생성하려면 버튼을 클릭하십시오. 인증서 생성. 열리는 창에서 새 인증서의 이름, 유효 기간을 입력하고 새로 생성된 인증서(*.cer) 및 개인 키(*.pvk) 파일이 저장될 경로를 지정합니다. 생성 버튼을 클릭합니다.
- 이전에 PFX 형식으로 생성된 인증서를 추가하려면 버튼을 클릭합니다. PFX 형식의 인증서에서 변환. PFX 형식의 인증서 파일에 대한 경로와 암호를 지정하고 변환하려는 인증서(*.cer) 및 개인 키(*.pvk) 파일의 경로를 지정합니다. 원본 파일. 변환 버튼을 클릭하면 변환이 완료됩니다.
창에서 다음을 클릭하십시오. 사용자 인증서 추가절차를 계속하려면추가 . 열리는 창에서 추가된 인증서에 서명할 고유 이름과 설명(선택 사항)을 입력합니다.
완료를 클릭하십시오 프로세스를 완료합니다. 인증서는 SecureTower 시스템의 사용자 인증서 데이터베이스에 추가됩니다. 딸깍 하는 소리확인 추가를 완료합니다.추가된 사용자 지정인증서는 에이전트가 신뢰할 수 있는 작성자의 데이터베이스에 자동으로 배치한 다음(이전에 네트워크 관리자가 수행하지 않은 경우) 하위 인증서를 발급하는 데 사용됩니다.
메모.
사용자 모드를 사용하는 경우 네트워크 관리자는 다음을 사용하여 네트워크의 모든 컴퓨터에 사용자 인증서를 배포하는 것이 좋습니다. 그룹 정책또는 수동으로. 이렇게 하면 성공적인 인증서 인증이 보장됩니다. 그렇지 않으면 에이전트가 인증서를 신뢰할 수 있는 인증서 저장소에 자동으로 추가합니다.
SSL 인증서를 서버에 바인딩
"서버-인증서" 일치를 확인하려면 버튼을 클릭하십시오. 인증서 바인딩아래 지침을 따르십시오.
- 탭에서 특정 루트 인증서 서버에 바인딩하려면 루트 인증서, 버튼을 눌러 사이트 인증서 추가. 호스트 이름 입력( 도메인 이름) 하위 인증서가 발급되고 루트 인증서가 호스트 이름(IP 주소) 필드에 바인딩됩니다. 필드 드롭다운 목록에서 사전 설치된 루트 인증서 중 하나를 선택합니다. 루트 인증서또는 버튼을 클릭 사용자 인증서사용자 컴퓨터에 인증서 및 개인 키 파일을 추가하고 지정합니다.
- 이미 존재하는 인증서를 특정 서버에 바인딩하려면 탭을 선택합니다. 사용자 인증서. 에이전트는 이 탭에 지정된 서버에 대한 새 하위 인증서를 생성하지 않지만 대체 절차에 대해 사용자가 지정한 인증서를 사용합니다. 열리는 창의 호스트 이름(IP 주소) 필드에 인증서가 바인딩될 호스트 이름(도메인 이름)을 입력합니다. 인증서: 필드의 드롭다운 목록에서 인증서 중 하나를 선택하거나(이전에 인증서가 추가된 경우) 버튼을 클릭합니다. 사용자 인증서목록에서 사용자 인증서를 선택하거나 사용자 컴퓨터에 인증서 및 개인 키 파일을 추가 및 지정합니다.
메모.
필드를 채우려면 호스트 이름(IP 주소)호스트의 IP 주소 사용은 허용되지만 연결 중에 호스트 이름을 결정하지 않고 IP 주소만 알고 있는 경우에만 허용됩니다.
암호화된 트래픽을 가로채는 서버 제외
인증서 스푸핑 프로세스의 예외를 처리하려면 버튼을 클릭하십시오.SSL 서버 예외.
제외 관리자 창에는 기본적으로 교체 프로세스에서 제외된 서버(호스트) 목록이 표시됩니다. 새 제외를 추가하려면 버튼 예외 추가.
열리는 대화 상자의 입력 필드에 서버(호스트) 이름(예: accounts.google.com)을 대소문자를 구분하여 입력하고 추가 버튼을 클릭합니다. 시스템을 사용하면 마스크로 이름을 도입할 수 있습니다(예: *.microsoft.*를 사용하면 제외 목록에서 Microsoft 리소스가 중복되는 것을 방지할 수 있습니다). 입력한 이름이 제외 목록에 나타납니다.
다음으로 제외 모드를 선택해야 합니다. 위에 나열된 SSL 서버에 대해서만 스푸핑 인증서, 또는 SSL 대체 - 위에서 언급한 서버를 제외한 모든 서버에 대한 인증서. 첫 번째 경우 시스템은 제외 목록에 나열된 서버에 대해서만 인증서를 스푸핑합니다(따라서 해당 트래픽을 가로챌 수 있음). 다른 모든 경우에는 인증서가 스푸핑되지 않으며 해당 암호화된 트래픽을 가로채는 것이 불가능합니다. 두 번째 경우 시스템은 예외 목록에 지정된 서버를 제외한 모든 서버의 인증서를 교체합니다.
예외를 제외하고 다른 작업을 수행하려면 단락의 관련 권장 사항을 따르십시오.
보안 SSL 연결을 통해 전송되는 데이터를 가로채기 위해 sslstrip 유틸리티를 사용하는 방법을 보여주고 알려 드리겠습니다.
내 예에서 sslstrip 유틸리티(피해자에 대해 ARP 스푸핑 공격을 수행한 후)는 보안 SSL 연결을 설정하고 보안되지 않은 HTTP 프로토콜을 사용하도록 강제하는 피해자 웹 클라이언트의 요청을 가로챕니다. 다음으로 피해자가 HTTPS가 아닌 HTTP를 통해 메일을 읽는다는 사실에 주의를 기울이지 않고 피해자가 무엇을 하는지 살펴보겠습니다.
공격을 조직하는 것이 얼마나 쉬운지 알게 될 것입니다. 유형 MITM arp-spoof 기술과 sslstrip 프로그램을 사용하여 SSL에서.
내 예에서 피해자는 IP가 10.10.11.163(Windows가 설치된 일반 자동차)인 가상 머신이고 내가 공격하는 PC는 Kali OS가 설치되어 있고 sslstrip이 설치된 10.10.11.85입니다(이 유틸리티는 pentester Kali\BackTrack Linux 배포판). 우리 사이에는 IP 10.10.11.1의 게이트웨이가 있습니다.
1. 피해자가 gmail.com에 접속하면 https://gmail.com 주소로 발송되는데 이는 정상입니다. 당연히 피해자의 메일에 대한 비밀번호와 로그인은 보이지 않습니다.
2. Kali를 사용하여 PC에서 트래픽 라우팅을 활성화합니다.
에코 "1" > /proc/sys/net/ipv4/ip_forward
모든 http 트래픽이 포트 81로 전달되도록 iptables를 구성합니다.
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 81
arpspoof -i eth0 -t 10.10.11.163 10.10.11.1
이제 피해자의 트래픽은 내 차를 통과하고 (내 iptables 규칙에 따라) 포트 81로 전달됩니다.
3. ssltrip 실행
sslstrip -a -l 81 -w /root/Desktop/ssllog.txt
이것은 데스크탑에 바로 로그 파일을 생성하고 가로채는 http 트래픽을 쓰기 시작합니다.(사실 HTTPS는 가로채지만 제거됩니다.) 음, 일반적으로 콘솔에서 이 파일을 보기 시작합니다.
꼬리 -f /root/Desktop/ssllog.txt
4. 피해자가 우편물을 찾아가다
피해자는 메일을 읽기 위해 여느 때와 같이 MS 익스플로러(헤헤)에 올라 gmail.com에 들어간다. 그러나 어떤 이유로 브라우저는 피해자를 https로 리디렉션하지 않습니다(http 주소 표시줄에 있음)! 아래 그림은 내가 피해자의 비밀번호와 로그인을 알아내기 전 마지막 순간에 피해자가 보게 될 내용을 보여줍니다.
피해자가 "로그인"을 클릭하고 ... 가로챈 트래픽이 표시된 내 창에 다음이 표시됩니다.
비밀번호는 보시다시피 1q2w3e4r5t6y...
SSL 연결 시작 가로채기와 관련된 위협을 방지하려면 다음을 수행해야 합니다.
- 매우 필요한 경우라도 신뢰할 수 없는 네트워크에서 가제트를 사용하지 마십시오. 기업 네트워크귀하의 조직);
- 대칭 암호화 프로토콜로 메일을 암호화합니다(저는 PGP를 쓰고 생각합니다).
- 이런 식으로 직원을 염탐하고 싶지 않도록 관리자에게 정상적인 급여를 지불하십시오.
- ARP 테이블을 추적하고 podbny 공격을 모니터링하는 하드웨어/소프트웨어를 사용합니다.
- 신뢰할 수 있는 법적 출처에서 소프트웨어를 정기적으로 업데이트합니다.
이 문서는 법적으로 금지된 사항을 설명하고 그 예제는 교육 목적으로만 SSL을 공격하는 것이 얼마나 쉬운지 보여주기 위해 제공됩니다.