옛날 옛적에 비뇨기과 의사와 Roskomnadzor의 도움으로 모든 것을 깨뜨리는 방법

이 기사는 Group-IB 전문가들이 몇 년 전에 실시한 매우 성공적인 침투 테스트를 바탕으로 작성되었습니다. 발리우드 영화에 적용할 수 있는 이야기가 일어났습니다. 이제 아마도 독자의 반응은 다음과 같을 것입니다. "아, 또 다른 PR 기사입니다. 또 이것이 묘사되고 있습니다. 얼마나 좋은지, 침투 테스트를 구입하는 것을 잊지 마십시오." 글쎄, 한편으로는 그렇습니다. 그런데 이 글이 나온 데에는 다른 이유도 많이 있습니다. 저는 침투 테스터가 정확히 무엇을 하는지, 이 작업이 얼마나 흥미롭고 사소하지 않은지, 프로젝트에서 어떤 재미있는 상황이 발생할 수 있는지, 가장 중요하게는 실제 사례를 통해 라이브 자료를 보여주고 싶었습니다.

세상의 겸손의 균형을 회복하기 위해 잠시 후에 잘 되지 않았던 오순절에 대해 글을 써보겠습니다. 우리는 회사에서 잘 설계된 프로세스가 어떻게 모든 범위의 공격으로부터 보호할 수 있는지 보여줄 것입니다. 잘 준비된 공격이라 할지라도 단순히 이러한 프로세스가 존재하고 실제로 작동한다는 이유만으로 말입니다.

이 기사에 나온 고객의 경우 우리의 감정에 따르면 모든 것이 일반적으로 러시아 연방 시장의 95% 이상으로 훌륭했지만 긴 이벤트 체인을 형성하는 작은 뉘앙스가 많이 있었습니다. 작업에 대한 긴 보고서를 작성하고 이 기사로 이어졌습니다.

그러니 팝콘을 비축하고 탐정 이야기에 오신 것을 환영합니다. 단어 - 파벨 수프루뉴크, Group-IB "감사 및 컨설팅" 부서의 기술 관리자입니다.

1부. 포치킨 의사

2018 많은 고객에게 서비스를 제공하는 첨단 IT 회사인 고객이 있습니다. 다음 질문에 대한 답을 얻고 싶습니다. 초기 지식이나 액세스 없이도 인터넷을 통해 작업하여 Active Directory 도메인 관리자 권한을 얻을 수 있습니까? 나는 소셜 엔지니어링에 관심이 없습니다(아, 하지만 헛된 일이야), 의도적으로 작업을 방해할 의도는 없지만 실수로 이상하게 작동하는 서버를 다시 로드할 수 있습니다. 추가적인 목표는 외부 경계에 대해 가능한 한 많은 다른 공격 벡터를 식별하는 것입니다. 회사에서는 정기적으로 이러한 테스트를 수행하고 있으며 이제 새로운 테스트 마감일이 다가왔습니다. 조건은 거의 일반적이고 적절하며 이해할 수 있습니다. 시작하자.

고객의 이름이 있습니다. 기본 웹사이트에는 "회사"라고 입력하세요. www.company.ru. 물론 고객은 다르게 호출되지만 이 기사에서는 모든 것이 비인격적입니다.
저는 네트워크 정찰을 수행합니다. 어떤 주소와 도메인이 고객에게 등록되어 있는지 확인하고 네트워크 다이어그램을 그리며 서비스가 이러한 주소에 배포되는 방법을 알아냅니다. 결과는 4000개가 넘는 라이브 IP 주소였습니다. 저는 이러한 네트워크의 도메인을 살펴봅니다. 다행스럽게도 대다수는 고객의 클라이언트를 위한 네트워크이며 우리는 이에 공식적으로 관심이 없습니다. 고객도 같은 생각이다.

256개의 주소를 가진 하나의 네트워크가 남아 있는데, 이 순간에는 이미 IP 주소별 도메인 및 하위 도메인 분포를 이해하고 있으며 스캔된 포트에 대한 정보가 있으므로 서비스에서 흥미로운 포트를 볼 수 있습니다. 동시에 모든 종류의 스캐너가 사용 가능한 IP 주소와 웹사이트에서 별도로 실행됩니다.

많은 서비스가 있습니다. 일반적으로 이것은 침투 테스터에게는 기쁨이고 빠른 승리에 대한 기대입니다. 서비스가 많을수록 공격 필드가 커지고 아티팩트를 찾는 것이 더 쉬워지기 때문입니다. 웹사이트를 잠깐 살펴보면 대부분이 글로벌 대기업의 잘 알려진 제품의 웹 인터페이스라는 것을 알 수 있었는데, 겉보기에는 환영받지 못할 것 같습니다. 사용자 이름과 비밀번호를 요청하고, 두 번째 요소를 입력하기 위해 필드를 흔들고, TLS 클라이언트 인증서를 요청하거나, Microsoft ADFS로 보냅니다. 일부는 단순히 인터넷에서 액세스할 수 없습니다. 일부의 경우 세 급여에 대한 특별 유료 클라이언트가 있거나 입력할 정확한 URL을 알아야 합니다. 알려진 취약점에 대한 소프트웨어 버전의 "돌파"를 시도하고, 웹 경로에 숨겨진 콘텐츠를 검색하고, LinkedIn과 같은 타사 서비스에서 유출된 계정을 검색하고, 이를 사용하여 비밀번호를 추측하는 과정에서 점진적인 낙담의 또 다른 주를 건너뛰겠습니다. 자체 제작한 웹사이트의 취약점을 발굴하는 것 등 — 그런데 통계에 따르면 이는 오늘날 외부 공격의 가장 유망한 벡터입니다. 나는 이후에 발사된 영화 총에 대해 즉시 주목하겠습니다.

그래서 우리는 수백 개의 서비스 중에서 눈에 띄는 두 개의 사이트를 발견했습니다. 이러한 사이트에는 한 가지 공통점이 있습니다. 도메인별로 세심한 네트워크 정찰에 참여하지 않고 열려 있는 포트를 정면으로 살펴보거나 알려진 IP 범위를 사용하여 취약성 스캐너를 대상으로 삼는 경우 이러한 사이트는 검색을 피하고 단순히 검색되지 않습니다. DNS 이름을 몰라도 표시됩니다. 아마도 그것들은 더 일찍 놓쳤을 것이고, 우리의 자동 도구는 그것들이 리소스로 직접 전송되더라도 어떤 문제도 발견하지 못했습니다.

그건 그렇고, 이전에 출시된 스캐너가 일반적으로 발견한 내용에 대해 설명합니다. 상기시켜 드리겠습니다. 어떤 사람들에게는 “pentest”가 “automated scan”과 동일합니다. 하지만 이 프로젝트의 스캐너는 아무 말도 하지 않았습니다. 최대값은 중간 취약점(심각도 측면에서 3점 중 5점)으로 나타났습니다. 일부 서비스에서는 잘못된 TLS 인증서 또는 오래된 암호화 알고리즘이 있고 대부분의 사이트에서는 클릭재킹이 발생했습니다. 그러나 이것은 당신의 목표를 달성하지 못할 것입니다. 여기에서는 스캐너가 더 유용할 수도 있지만 고객이 직접 그러한 프로그램을 구입하여 직접 테스트할 수 있으며, 암울한 결과로 판단하여 이미 확인했다는 점을 상기시켜 드리겠습니다.

"변칙적인" 사이트로 돌아가 보겠습니다. 첫 번째는 비표준 주소에 있는 로컬 Wiki와 같은 것이지만 이 기사에서는 wiki.company[.]ru라고 하겠습니다. 그녀는 또한 즉시 로그인과 비밀번호를 요청했지만 브라우저의 NTLM을 통해 요청했습니다. 사용자에게 이는 사용자 이름과 비밀번호를 입력하라는 금욕적인 창처럼 보입니다. 그리고 이것은 나쁜 습관입니다.

작은 메모. 경계 웹 사이트의 NTLM은 여러 가지 이유로 좋지 않습니다. 첫 번째 이유는 Active Directory 도메인 이름이 공개되기 때문입니다. 이 예에서는 "외부" DNS 이름과 마찬가지로 company.ru인 것으로 나타났습니다. 이를 알면 일부 샌드박스가 아닌 조직의 도메인 시스템에서만 실행되도록 악의적인 작업을 신중하게 준비할 수 있습니다. 둘째, 인증은 계정이 암호 입력 시도 횟수를 초과하지 못하도록 차단하는 것을 포함하여 "내부" 네트워크 정책의 모든 기능을 사용하여 NTLM을 통해 도메인 컨트롤러를 통해 직접 진행됩니다(놀랐죠?). 공격자가 로그인을 알아내면 해당 로그인에 대한 비밀번호를 검색합니다. 계정이 잘못된 비밀번호를 입력하지 못하도록 차단하도록 구성한 경우 작동하며 계정이 차단됩니다. 셋째, 이러한 인증에는 두 번째 요소를 추가하는 것이 불가능합니다. 아직도 방법을 알고 있는 독자가 있다면 알려주세요. 정말 흥미로울 것입니다. 넷째, Pass-the-Hash 공격에 대한 취약성입니다. 무엇보다도 ADFS는 이 모든 것을 방지하기 위해 고안되었습니다.

Microsoft 제품에는 한 가지 나쁜 속성이 있습니다. NTLM을 특별히 게시하지 않았더라도 적어도 OWA 및 Lync에는 기본적으로 설치됩니다.

그런데 이 글의 작성자는 실수로 같은 방법으로 한 대형은행 직원의 계좌 약 1000여 개를 단 한 시간 만에 실수로 차단한 뒤 다소 창백해 보였다. 은행의 IT 서비스도 미흡했지만 모든 것이 적절하게 잘 끝났고, 이 문제를 가장 먼저 발견하고 신속하고 결정적인 해결을 유도했다는 칭찬까지 받았습니다.

두 번째 사이트의 주소는 "분명히 일종의 성.company.ru"였습니다. Google을 통해 10페이지에서 이와 같은 내용을 찾았습니다. 그 디자인은 XNUMX년대 초중반의 것인데, 존경할만한 사람이 메인 페이지에서 그것을 보고 있었는데, 다음과 같았습니다.

여기서는 "Heart of a Dog"의 스틸을 촬영했는데, 어렴풋이 비슷했고 색상 디자인도 비슷한 톤이었습니다. 사이트를 호출하자 preobrazhensky.company.ru.

비뇨기과 의사의 개인 웹사이트였습니다. 비뇨기과 전문의의 웹사이트가 첨단 기업의 하위 도메인에서 무엇을 하고 있는지 궁금했습니다. Google에 대한 빠른 조사 결과 이 ​​의사는 우리 고객의 법인 중 하나의 공동 창립자였으며 심지어 승인된 자본으로 약 1000루블을 기부한 것으로 나타났습니다. 해당 사이트는 아마도 수년 전에 만들어졌을 것이며 고객의 서버 리소스가 호스팅으로 사용되었습니다. 이 사이트는 오랫동안 관련성을 잃었지만 어떤 이유로 오랫동안 작동하지 않았습니다.

취약점 측면에서는 웹사이트 자체가 안전했습니다. 앞으로는 그것이 신장과 방광 형태의 그림이 삽입된 간단한 HTML 페이지인 일련의 정적 정보라고 말할 것입니다. 그러한 사이트를 "파괴"하는 것은 쓸모가 없습니다.

하지만 밑에 있는 웹서버가 더 흥미로웠어요. HTTP Server 헤더로 판단하면 IIS 6.0을 사용하고 있으며 이는 Windows 2003을 운영 체제로 사용했음을 의미합니다. 스캐너는 이전에 이 특정 비뇨기과 의사 웹사이트가 동일한 웹 서버의 다른 가상 호스트와 달리 PROPFIND 명령에 응답했음을 식별했습니다. 이는 WebDAV를 실행하고 있음을 의미합니다. 그건 그렇고, 스캐너는 정보 표시와 함께 이 정보를 반환했습니다(스캐너 보고서의 언어에서는 위험이 가장 낮습니다). 이러한 항목은 일반적으로 간단히 건너뜁니다. 이는 Google에서 또 다른 조사 후에야 밝혀진 흥미로운 효과를 제공했습니다. Shadow Brokers 세트, 즉 CVE-2017-7269와 관련된 드문 버퍼 오버플로 취약점은 이미 이미 악용되어 있었습니다. 즉, Windows 2003을 사용하고 있고 WebDAV가 IIS에서 실행되고 있는 경우 문제가 발생합니다. 2003년에 Windows 2018을 프로덕션 환경에서 실행하는 것 자체가 문제입니다.

익스플로잇은 Metasploit에서 발생했으며 제어된 서비스에 DNS 요청을 보내는 로드로 즉시 테스트되었습니다. Burp Collaborator는 전통적으로 DNS 요청을 잡는 데 사용되었습니다. 놀랍게도 처음에는 작동했습니다. DNS 녹아웃이 수신되었습니다. 다음으로 포트 80을 통해 역연결(즉, 피해자 호스트의 cmd.exe에 액세스하여 서버에서 공격자로의 네트워크 연결)을 만들려는 시도가 있었지만 실패가 발생했습니다. 연결이 이루어지지 않았고 사이트를 세 번째 사용하려고 시도한 후 모든 흥미로운 사진과 함께 영원히 사라졌습니다.

일반적으로 이 메시지 뒤에는 "고객님, 일어나세요. 모든 것을 버렸습니다."라는 스타일의 편지가 표시됩니다. 그러나 우리는 사이트가 비즈니스 프로세스와 아무 관련이 없으며 전체 서버처럼 아무 이유 없이 작동하며 이 리소스를 원하는 대로 사용할 수 있다는 말을 들었습니다.
하루쯤 지나서 갑자기 사이트가 자체적으로 작동하기 시작했습니다. IIS 6.0에서 WebDAV로 벤치를 구축한 결과, 기본 설정은 30시간마다 IIS 작업자 프로세스를 다시 시작하는 것임을 알았습니다. 즉, 제어가 셸코드를 종료하면 IIS 작업자 프로세스가 종료된 다음 몇 번 다시 시작된 다음 30시간 동안 휴지 상태가 되었습니다.

처음에 tcp에 대한 역연결이 실패했기 때문에 이 문제는 닫힌 포트 때문이라고 생각했습니다. 즉, 그는 나가는 연결이 외부로 전달되는 것을 허용하지 않는 일종의 방화벽이 있다고 가정했습니다. 많은 tcp 및 udp 포트를 검색하는 쉘코드를 실행하기 시작했지만 효과가 없었습니다. Metasploit에서 http(s)를 통한 역방향 연결 로드가 작동하지 않았습니다. -meterpreter/reverse_http(s). 갑자기 동일한 포트 80에 대한 연결이 설정되었지만 즉시 끊어졌습니다. 나는 이것이 미터프리터 트래픽을 좋아하지 않는 여전히 가상의 IPS의 행동 때문이라고 생각했습니다. 포트 80에 대한 순수 TCP 연결은 통과되지 않았지만 http 연결은 통과했다는 사실을 고려하여 시스템에 http 프록시가 어떻게든 구성되어 있다고 결론을 내렸습니다.

DNS를 통해 미터프리터도 사용해 보았습니다(감사합니다. d00kie 여러분의 노력으로 많은 프로젝트를 구했습니다) 첫 번째 성공을 회상했지만 스탠드에서는 작동하지 않았습니다. 이 취약점에 비해 쉘코드가 너무 방대했습니다.

실제로는 다음과 같았습니다. 3분 내에 4~5번의 공격을 시도한 후 30시간을 기다렸습니다. 그리고 XNUMX주 연속 이런 일이 계속됐다. 시간을 낭비하지 않기 위해 알림도 설정했습니다. 또한 테스트 환경과 프로덕션 환경의 동작에 차이가 있었습니다. 이 취약점에는 두 가지 유사한 익스플로잇이 있었습니다. 하나는 Metasploit에서, 두 번째는 인터넷에서 Shadow Brokers 버전에서 변환된 것입니다. 그래서 Metasploit만 전투에서 테스트했고, 두 번째만 벤치에서 테스트했는데, 이로 인해 디버깅이 더욱 어려워지고 머리가 아팠습니다.

결국, http를 통해 특정 서버에서 exe 파일을 다운로드하고 이를 대상 시스템에서 실행하는 쉘코드가 효과적인 것으로 입증되었습니다. 쉘코드는 들어갈 만큼 작았지만 적어도 작동했습니다. 서버는 TCP 트래픽을 전혀 좋아하지 않았고 http(s)에서 미터프리터가 있는지 검사했기 때문에 가장 빠른 방법은 이 쉘코드를 통해 DNS-미터프리터가 포함된 exe 파일을 다운로드하는 것이라고 결정했습니다.

여기서 다시 문제가 발생했습니다. exe 파일을 다운로드할 때 시도에서 알 수 있듯이 어느 파일이든 다운로드가 중단되었습니다. 다시 말하지만, 내 서버와 비뇨기과 의사 사이의 일부 보안 장치는 내부에 exe가 포함된 http 트래픽을 좋아하지 않았습니다. "빠른" 해결책은 쉘코드를 변경하여 즉석에서 http 트래픽을 난독화하여 exe 대신 추상 바이너리 데이터가 전송되도록 하는 것 같았습니다. 마지막으로 공격은 성공했으며 씬 DNS 채널을 통해 제어권을 받았습니다.

내가 아무것도 할 수 없는 가장 기본적인 IIS 워크플로 권한을 갖고 있다는 것이 즉시 분명해졌습니다. Metasploit 콘솔의 모습은 다음과 같습니다.

모든 침투 테스트 방법론에서는 액세스 권한을 얻을 때 권한을 높여야 한다고 강력하게 제안합니다. 나는 일반적으로 이 작업을 로컬에서 수행하지 않습니다. 첫 번째 액세스는 단순히 네트워크 진입점으로 간주되고 동일한 네트워크의 다른 시스템을 손상시키는 것이 일반적으로 기존 호스트에서 권한을 상승시키는 것보다 쉽고 빠르기 때문입니다. 그러나 여기서는 그렇지 않습니다. 왜냐하면 DNS 채널이 매우 좁고 트래픽 정리를 허용하지 않기 때문입니다.

이 Windows 2003 서버가 유명한 MS17-010 취약점에 대해 복구되지 않았다고 가정하고, 미터프리터 DNS 터널을 통해 포트 445/TCP로 트래픽을 로컬 호스트로 터널링하고(예, 이것도 가능합니다) 이전에 다운로드한 exe를 통해 실행하려고 합니다. 취약점. 공격이 작동하고 두 번째 연결을 받았지만 SYSTEM 권한이 있습니다.

그들이 여전히 MS17-010으로부터 서버를 보호하려고 시도했다는 점은 흥미롭습니다. 외부 인터페이스에서 취약한 네트워크 서비스가 비활성화되어 있었기 때문입니다. 이는 네트워크를 통한 공격으로부터 보호하지만 로컬 호스트에서 SMB를 신속하게 끌 수는 없기 때문에 로컬 호스트 내부에서의 공격은 효과가 있었습니다.

다음으로, 새로운 흥미로운 세부 사항이 공개됩니다.

1. SYSTEM 권한이 있으면 TCP를 통해 쉽게 역연결을 설정할 수 있습니다. 분명히 직접 TCP를 비활성화하는 것은 제한된 IIS 사용자에게만 문제가 됩니다. 스포일러: IIS 사용자 트래픽은 어떻게든 로컬 ISA 프록시에 양방향으로 래핑되었습니다. 정확히 어떻게 작동하는지 재현하지 않았습니다.
2. 저는 특정 "DMZ"(Active Directory 도메인이 아니라 WORKGROUP)에 있습니다. 논리적으로 들립니다. 그러나 예상되는 개인("회색") IP 주소 대신에 이전에 공격한 것과 정확히 동일한 완전히 "흰색" IP 주소를 갖게 되었습니다. 이는 회사가 IPv4 주소 지정 분야에서 너무 오래되었기 때문에 128년 Cisco 매뉴얼에 설명된 대로 체계에 따라 NAT 없이 2005개의 "화이트" 주소에 대한 DMZ 영역을 유지할 여유가 있다는 것을 의미합니다.

서버가 오래되었기 때문에 Mimikatz는 메모리에서 직접 작동하는 것이 보장됩니다.

로컬 관리자 비밀번호를 받고 TCP를 통해 RDP 트래픽을 터널링한 후 아늑한 데스크탑에 로그인합니다. 서버로 원하는 것은 무엇이든 할 수 있었기 때문에 바이러스 백신을 제거하고 TCP 포트 80과 443을 통해서만 인터넷에서 서버에 액세스할 수 있었고 443은 사용 중이 아니라는 것을 확인했습니다. 443에 OpenVPN 서버를 설정하고, VPN 트래픽에 NAT 기능을 추가하고, OpenVPN을 통해 무제한 형태로 DMZ 네트워크에 직접 액세스할 수 있습니다. 비활성화되지 않은 일부 IPS 기능을 갖춘 ISA가 포트 스캐닝을 통해 내 트래픽을 차단했다는 점은 주목할 만합니다. 이를 위해 더 간단하고 규정을 준수하는 RRAS로 교체해야 했습니다. 따라서 침투 테스터는 때때로 여전히 모든 종류의 작업을 관리해야 합니다.

세심한 독자는 다음과 같이 질문할 것입니다. "두 번째 사이트인 NTLM 인증을 사용하는 위키는 어떻습니까? 이에 대해 너무 많은 내용이 기록되어 있습니다." 이에 대해서는 나중에 자세히 설명합니다.

파트 2: 아직 암호화하지 않으셨나요? 그렇다면 우리는 이미 여기 당신에게 가고 있습니다

따라서 DMZ 네트워크 세그먼트에 대한 액세스가 있습니다. 도메인 관리자에게 문의해야 합니다. 가장 먼저 떠오르는 것은 DMZ 세그먼트 내 서비스의 보안을 자동으로 확인하는 것입니다. 특히 현재 더 많은 서비스가 연구용으로 공개되어 있기 때문입니다. 침투 테스트 중 일반적인 그림: 외부 경계는 내부 서비스보다 더 잘 보호되며 대규모 인프라 내부에 액세스할 때 이 도메인이 시작되기 때문에 도메인에서 확장된 권한을 얻는 것이 훨씬 쉽습니다. 도구에 액세스할 수 있으며, 둘째, 수천 개의 호스트가 있는 인프라에는 항상 몇 가지 중요한 문제가 있습니다.

OpenVPN 터널을 통해 DMZ를 통해 스캐너를 충전하고 기다립니다. 나는 보고서를 열었습니다. 다시 한 번 심각한 것은 아닙니다. 분명히 누군가가 나보다 먼저 같은 방법을 겪었습니다. 다음 단계는 DMZ 네트워크 내의 호스트가 어떻게 통신하는지 조사하는 것입니다. 이렇게 하려면 먼저 일반 Wireshark를 시작하고 주로 ARP와 같은 브로드캐스트 요청을 수신합니다. ARP 패킷은 하루 종일 수집되었습니다. 이 세그먼트에는 여러 게이트웨이가 사용되는 것으로 나타났습니다. 이것은 나중에 유용할 것입니다. ARP 요청-응답 데이터와 포트 스캐닝 데이터를 결합하여 웹, 메일 등 기존에 알려진 서비스 외에 로컬 네트워크 내부에서 사용자 트래픽이 나가는 지점을 찾아냈습니다.

현재 다른 시스템에 대한 액세스 권한이 없고 기업 서비스에 대한 단일 계정도 없기 때문에 ARP 스푸핑을 사용하여 트래픽에서 최소한 일부 계정을 찾아내기로 결정했습니다.

비뇨기과 전문의 서버에 카인앤아벨이 런칭되었습니다. 식별된 트래픽 흐름을 고려하여 중간자 공격에 가장 유망한 쌍을 선택한 다음 서버를 재부팅하는 타이머와 함께 5~10분 동안 단기 실행으로 일부 네트워크 트래픽을 수신했습니다. 동결의 경우. 농담처럼 두 가지 소식이 있었습니다.

1. 좋다: 많은 자격 증명이 포착되었고 전체적으로 공격이 성공했습니다.
2. 나쁜 점은 모든 자격 증명이 고객의 클라이언트에서 나왔다는 것입니다. 지원 서비스를 제공하는 동안 고객 전문가는 항상 트래픽 암호화가 구성되어 있지 않은 클라이언트의 서비스에 연결됩니다.

그 결과, 프로젝트 맥락에서는 쓸모가 없지만 공격의 위험성을 입증하는 데는 확실히 흥미로운 많은 자격 증명을 획득했습니다. 텔넷을 사용하는 대기업의 경계 라우터는 디버그 http 포트를 모든 데이터와 함께 내부 CRM으로 전달하고, 로컬 네트워크의 Windows XP에서 RDP에 직접 액세스하고 기타 모호함을 나타냅니다. 이렇게 됐어요 MITRE 매트릭스에 따른 공급망 손상.

나는 또한 교통체증에서 편지를 수집할 수 있는 재미있는 기회를 발견했습니다. 이것은 고객이 고객의 SMTP 포트로 암호화 없이 전송한 기성 편지의 예입니다. 특정 Andrey가 자신의 이름을 딴 문서를 다시 보내달라고 요청하면 해당 문서는 하나의 응답 편지에 로그인, 비밀번호 및 링크와 함께 클라우드 디스크에 업로드됩니다.

이는 모든 서비스를 암호화하라는 또 다른 알림입니다. 제공자, 다른 회사의 시스템 관리자, 침투 테스터 등 누가 언제 귀하의 데이터를 읽고 사용할지는 알 수 없습니다. 나는 많은 사람들이 암호화되지 않은 트래픽을 간단히 가로챌 수 있다는 사실에 대해 침묵합니다.

명백한 성공에도 불구하고 이것은 우리를 목표에 더 가깝게 만들지 못했습니다. 물론 오랫동안 앉아서 귀중한 정보를 캐내는 것도 가능했지만, 거기에 나타날 것이라는 것은 사실이 아니며, 공격 자체는 네트워크의 무결성 측면에서 매우 위험합니다.

서비스를 한번 더 살펴보던 중 흥미로운 아이디어가 떠올랐습니다. 브로드캐스트 요청을 "중독"하여 SMB, HTTP, LDAP 등과 같은 다양한 프로토콜을 통해 연결을 유발하는 Responder(이 이름으로 사용 예를 쉽게 찾을 수 있음)라는 유틸리티가 있습니다. 그런 다음 연결하는 모든 사람에게 인증을 요청하고 NTLM을 통해 피해자에게 투명한 모드로 인증이 이루어지도록 설정합니다. 대부분의 경우 공격자는 이러한 방식으로 NetNTLMv2 핸드셰이크를 수집하고 사전을 사용하여 이 핸드셰이크에서 사용자 도메인 암호를 신속하게 복구합니다. 여기서도 비슷한 것을 원했지만 사용자는 "벽 뒤에" 앉아 있거나 오히려 방화벽으로 분리되어 Blue Coat 프록시 클러스터를 통해 웹에 액세스했습니다.

Active Directory 도메인 이름이 "외부" 도메인, 즉 company.ru와 일치한다고 지정했다는 것을 기억하십니까? 따라서 Windows, 보다 정확하게는 Internet Explorer(및 Edge 및 Chrome)에서는 사이트가 일부 "인트라넷 영역"에 있다고 판단하는 경우 사용자가 NTLM을 통해 HTTP에서 투명하게 인증할 수 있도록 허용합니다. "인트라넷"의 징후 중 하나는 "회색" IP 주소 또는 짧은 DNS 이름, 즉 점이 없는 액세스입니다. "화이트" IP 및 DNS 이름 preobrazhensky.company.ru를 가진 서버가 있었고 도메인 시스템은 일반적으로 단순화된 이름 입력을 위해 DHCP를 통해 Active Directory 도메인 접미사를 받기 때문에 주소 표시줄에 URL만 작성하면 되었습니다. 프레오브라젠스키, 이제 이 서버가 "인트라넷"이라고 불린다는 사실을 잊지 않고 손상된 비뇨기과 전문의의 서버에 대한 올바른 경로를 찾을 수 있습니다. 즉, 동시에 사용자가 모르는 사이에 사용자의 NTLM 핸드셰이크를 제공합니다. 남은 것은 클라이언트 브라우저가 이 서버에 긴급하게 접속해야 하는지 생각하도록 하는 것뿐입니다.

훌륭한 Intercepter-NG 유틸리티가 구출되었습니다(감사합니다. 인터셉터). 이를 통해 트래픽을 즉시 변경할 수 있었고 Windows 2003에서 훌륭하게 작동했습니다. 심지어 트래픽 흐름에서 JavaScript 파일만 수정하는 별도의 기능도 있었습니다. 일종의 대규모 Cross-Site Scripting이 계획되었습니다.

사용자가 글로벌 웹에 액세스하는 데 사용하는 Blue Coat 프록시는 정적 콘텐츠를 주기적으로 캐시했습니다. 트래픽을 차단함으로써 그들이 XNUMX시간 내내 작업하고 있으며 피크 시간대에 콘텐츠 표시 속도를 높이기 위해 자주 사용되는 정적 신호를 끝없이 요청하고 있음이 분명했습니다. 또한 BlueCoat에는 실제 사용자와 명확하게 구별되는 특정 User-Agent가 있습니다.

Javascript를 준비하였고 Intercepter-NG를 이용하여 Blue Coat용 JS 파일로 각 응답마다 밤에 XNUMX시간씩 구현하였습니다. 스크립트는 다음을 수행했습니다.

• User-Agent를 통해 현재 브라우저를 확인했습니다. Internet Explorer, Edge 또는 Chrome이라면 계속 작동했습니다.
• 페이지의 DOM이 형성될 때까지 기다렸습니다.
• 양식의 src 속성을 사용하여 보이지 않는 이미지를 DOM에 삽입했습니다. 프레오브라젠스키:8080/NNNNNNN.png, 여기서 NNN은 BlueCoat가 캐시하지 않도록 하는 임의의 숫자입니다.
• 주입이 완료되었으며 더 이상 이미지를 삽입할 필요가 없음을 나타내도록 전역 플래그 변수를 설정합니다.

브라우저는 이 이미지를 로드하려고 시도했으며 손상된 서버의 포트 8080에서 TCP 터널이 동일한 응답자가 실행 중인 내 노트북으로 이 이미지를 기다리고 있었기 때문에 브라우저가 NTLM을 통해 로그인해야 했습니다.

응답자 로그에 따르면 사람들은 아침에 출근하여 워크스테이션을 켠 다음 NTLM 악수를 "배수"하는 것을 잊지 않고 한꺼번에 눈에 띄지 않게 비뇨기과 의사의 서버를 방문하기 시작했습니다. 하루종일 악수가 쏟아졌고, 비밀번호를 복구하기 위한 공격이 명백히 성공했다는 자료가 쌓였습니다. 응답자 로그는 다음과 같습니다.

사용자의 비뇨기과 서버에 대한 대량 비밀 방문

당신은 아마도 이 모든 이야기가 "모든 것이 괜찮았지만 당황스러운 일이 있었고 극복한 일이 있었고 모든 것이 성공했다"는 원칙에 기초하고 있다는 것을 이미 알아차렸을 것입니다. 그래서 여기에 불만이있었습니다. 2번의 독특한 악수 중 단 한 건도 공개되지 않았습니다. 이는 프로세서가 작동하지 않는 노트북에서도 이러한 NTLMvXNUMX 핸드셰이크가 초당 수억 번의 시도 속도로 처리된다는 사실을 고려한 것입니다.

나는 비밀번호 변형 기술, 비디오 카드, 더 두꺼운 사전으로 무장하고 기다려야 했습니다. 오랜 시간이 흐른 후 "Q11111111....1111111q" 형식의 비밀번호를 사용하는 여러 계정이 공개되었습니다. 이는 모든 사용자가 한때 대소문자가 다른 매우 긴 비밀번호를 제시해야 했음을 시사합니다. 복잡하다. 하지만 노련한 사용자를 속일 수는 없으며 이것이 자신이 기억하기 쉽게 만든 방법입니다. 전체적으로 약 5개의 계정이 손상되었으며 그 중 하나만이 서비스에 대한 귀중한 권리를 가지고 있었습니다.

3부. Roskomnadzor의 반격

따라서 첫 번째 도메인 계정이 수신되었습니다. 오랫동안 읽으면서 이 시점까지 잠들지 않았다면 아마도 두 번째 인증 요소가 필요하지 않은 서비스, 즉 NTLM 인증을 사용하는 Wiki에 대해 언급한 것을 기억할 것입니다. 물론 가장 먼저 해야 할 일은 그곳에 들어가는 것이었다. 내부 지식 기반을 자세히 조사한 결과 다음과 같은 결과가 빠르게 나타났습니다.

• 회사에는 로컬 네트워크에 액세스할 수 있는 도메인 계정을 사용하여 인증하는 WiFi 네트워크가 있습니다. 현재 데이터 세트를 사용하면 이는 이미 작동하는 공격 벡터이지만 사무실에 직접 가서 고객 사무실 영역 어딘가에 위치해야 합니다.
• 사용자가 로컬 네트워크 내부에 있고 자신의 도메인 로그인과 비밀번호를 자신있게 기억하는 경우 "두 번째 요소" 인증 장치를 독립적으로 등록할 수 있는 서비스가 있다는 지침을 찾았습니다. 이 경우 "내부"와 "외부"는 사용자가 본 서비스 포트에 접근할 수 있는지 여부에 따라 결정됩니다. 이 항구는 인터넷으로는 접근할 수 없었지만 DMZ를 통해서는 접근이 가능했습니다.

물론, 내 휴대폰에 있는 애플리케이션 형태로 손상된 계정에 '두 번째 요소'가 즉시 추가되었습니다. 작업에 대한 "승인"/"비승인" 버튼을 사용하여 푸시 요청을 전화기에 큰 소리로 보내거나 추가 독립적인 입력을 위해 화면에 OTP 코드를 자동으로 표시할 수 있는 프로그램이 있었습니다. 또한 지침에 따르면 첫 번째 방법이 유일하게 올바른 것으로 간주되었지만 OTP 방법과 달리 작동하지 않았습니다.

"두 번째 요소"가 깨져서 Outlook Web Access 메일에 액세스하고 Citrix Netscaler Gateway에서 원격 액세스를 할 수 있었습니다. Outlook의 메일에 다음과 같은 놀라운 내용이 있었습니다.

이 드문 장면에서 Roskomnadzor가 침투 테스터를 어떻게 돕는지 확인할 수 있습니다.

수천 개의 주소를 가진 전체 네트워크가 액세스에서 완전히 사라진 유명한 Telegram의 "팬" 차단 이후 첫 달이었습니다. 푸시가 즉시 작동하지 않는 이유와 내 "피해자"가 영업 시간 동안 계정을 사용하기 시작했기 때문에 경보를 울리지 않은 이유가 분명해졌습니다.

Citrix Netscaler에 익숙한 사람이라면 일반적으로 그림 인터페이스만 사용자에게 전달될 수 있는 방식으로 구현되어 타사 응용 프로그램을 시작하고 데이터를 전송하는 도구를 제공하지 않고 가능한 모든 방법으로 작업을 제한하는 방식으로 구현된다고 상상합니다. 표준 제어 쉘을 통해. 내 "피해자"는 직업 때문에 1C만 받았습니다.

1C 인터페이스를 조금 둘러본 후 거기에 외부 처리 모듈이 있다는 것을 발견했습니다. 인터페이스에서 로드할 수 있으며 권한 및 설정에 따라 클라이언트 또는 서버에서 실행됩니다.

나는 1C 프로그래머 친구들에게 문자열을 받아들이고 실행하는 처리를 생성하도록 요청했습니다. 1C 언어에서 프로세스 시작은 다음과 같습니다(인터넷에서 가져옴). 1C 언어의 구문이 그 자발성으로 러시아어를 사용하는 사람들을 놀라게 한다는 데 동의하십니까?

처리는 완벽하게 수행되었으며 침투 테스터가 "셸"이라고 부르는 것으로 밝혀졌으며 이를 통해 Internet Explorer가 시작되었습니다.

이전에는 해당 지역으로의 패스를 주문할 수 있는 시스템 주소가 메일에서 발견되었습니다. WiFi 공격 벡터를 사용해야 할 경우를 대비해 패스를 주문했습니다.

고객 사무실에 여전히 맛있는 무료 케이터링이 있다는 이야기가 인터넷에 있지만 저는 여전히 원격으로 공격을 개발하는 것을 선호했기 때문에 더 차분했습니다.

AppLocker가 Citrix를 실행하는 응용 프로그램 서버에서 활성화되었지만 우회되었습니다. http(s) 버전이 연결을 원하지 않았고 당시 내부 프록시 주소를 몰랐기 때문에 동일한 Meterpreter가 DNS를 통해 로드되고 실행되었습니다. 그런데 이 순간부터 외부 침투 테스트는 본질적으로 완전히 내부 침투 테스트로 바뀌었습니다.

4부. 사용자의 관리자 권한이 좋지 않습니다. 그렇죠?

도메인 사용자 세션에 대한 제어권을 얻을 때 침투 테스터의 첫 번째 작업은 도메인의 권한에 대한 모든 정보를 수집하는 것입니다. 도메인 컨트롤러의 LDAP 프로토콜과 SMB를 통해 사용자, 컴퓨터, 보안 그룹에 대한 정보를 자동으로 다운로드할 수 있는 BloodHound 유틸리티가 있습니다. 최근 로그인한 사용자와 로컬 관리자가 누구인지에 대한 정보입니다.

도메인 관리자 권한을 획득하는 일반적인 기술은 단조로운 작업의 주기로 단순화되어 보입니다.

• 이미 캡처된 도메인 계정을 기반으로 로컬 관리자 권한이 있는 도메인 컴퓨터로 이동합니다.
• Mimikatz를 실행하고 최근 이 시스템에 로그인한 도메인 계정의 캐시된 비밀번호, Kerberos 티켓 및 NTLM 해시를 가져옵니다. 또는 lsass.exe 프로세스의 메모리 이미지를 제거하고 우리 측에서도 동일한 작업을 수행합니다. 이는 기본 설정을 사용하는 2012R2/Windows 8.1 이전 Windows에서 잘 작동합니다.
• 우리는 손상된 계정이 로컬 관리자 권한을 갖고 있는 위치를 확인합니다. 첫 번째 요점을 반복합니다. 어떤 단계에서 우리는 전체 도메인에 대한 관리자 권한을 얻습니다.

1C 프로그래머가 여기에 쓰는 것처럼 "사이클의 끝"입니다.

따라서 우리 사용자는 이름에 "VDI" 또는 "가상 데스크톱 인프라"라는 단어가 포함된 개인용 가상 머신인 Windows 7이 설치된 단 하나의 호스트에 대한 로컬 관리자로 밝혀졌습니다. 아마도 VDI 서비스 설계자는 VDI가 사용자의 개인 운영 체제이기 때문에 사용자가 원하는 대로 소프트웨어 환경을 변경하더라도 호스트를 계속 "다시 로드"할 수 있다는 의미였을 것입니다. 나는 또한 일반적으로 아이디어가 좋다고 생각하여 이 개인 VDI 호스트에 가서 그곳에 둥지를 틀었습니다.

• 거기에 OpenVPN 클라이언트를 설치했는데, 이는 인터넷을 통해 내 서버로 터널을 만들었습니다. 클라이언트는 도메인 인증과 함께 동일한 Blue Coat를 거쳐야 했지만 OpenVPN은 소위 "즉시" 이를 수행했습니다.
• VDI에 OpenSSH를 설치했습니다. 글쎄요, SSH가 없는 Windows 7이란 무엇일까요?

라이브로 본 모습은 이렇습니다. 이 모든 작업은 Citrix와 1C를 통해 수행되어야 함을 상기시켜 드리겠습니다.

인접한 컴퓨터에 대한 액세스를 승격시키는 한 가지 기술은 일치하는 로컬 관리자 암호를 확인하는 것입니다. 여기에 행운이 즉각적으로 기다리고 있었습니다. 기본 로컬 관리자(갑자기 관리자라고 불림)의 NTLM 해시가 해시 통과 공격을 통해 이웃 VDI 호스트(그 중 수백 개가 있음)에 접근했습니다. 물론 공격은 즉시 그들을 덮쳤다.

VDI 관리자가 두 번이나 자신의 발에 총을 쏜 곳은 바로 이곳입니다.

• 첫 번째는 VDI 시스템을 LAPS로 가져오지 않아 VDI에 대규모로 배포된 이미지와 동일한 로컬 관리자 비밀번호를 기본적으로 유지하는 경우였습니다.
• 기본 관리자는 해시 전달 공격에 취약한 유일한 로컬 계정입니다. 동일한 비밀번호를 사용하더라도 복잡한 무작위 비밀번호로 두 번째 로컬 관리자 계정을 생성하고 기본 비밀번호를 차단함으로써 대량 침해를 피할 수 있습니다.

해당 Windows에 SSH 서비스가 필요한 이유는 무엇입니까? 매우 간단합니다. 이제 OpenSSH 서버는 사용자 작업을 방해하지 않고 편리한 대화형 명령 셸을 제공할 뿐만 아니라 VDI의 양말5 프록시도 제공합니다. 이 양말을 통해 SMB를 통해 연결하고 수백 대의 VDI 시스템 모두에서 캐시된 계정을 수집한 다음 이를 사용하여 도메인 관리자에 대한 경로를 BloodHound 그래프에서 찾았습니다. 수백 개의 호스트를 마음대로 사용할 수 있었기 때문에 이 방법을 아주 빨리 찾았습니다. 도메인 관리자 권한을 얻었습니다.

다음은 유사한 검색을 보여주는 인터넷 사진입니다. 연결은 관리자가 어디에 있고 누가 어디에 로그인했는지 보여줍니다.

그건 그렇고, 프로젝트 시작부터 "소셜 엔지니어링을 사용하지 마십시오"라는 조건을 기억하십시오. 그래서 저는 진부한 피싱을 사용할 수 있다면 특수 효과가 있는 이 볼리우드가 얼마나 많이 차단될 것인지 생각해 볼 것을 제안합니다. 하지만 개인적으로 이 모든 일을 하는 것이 매우 흥미로웠습니다. 이 글을 읽으면서 즐거웠기를 바랍니다. 물론 모든 프로젝트가 그렇게 흥미로워 보이는 것은 아니지만, 작업 전체가 매우 어렵고 정체되는 것을 허용하지 않습니다.

아마도 누군가가 질문을 할 것입니다. 자신을 보호하는 방법은 무엇입니까? 이 문서에서도 Windows 관리자가 모르는 많은 기술에 대해 설명합니다. 그러나 나는 해킹된 원칙과 정보 보안 조치의 관점에서 이를 살펴볼 것을 제안합니다.

• 오래된 소프트웨어를 사용하지 마십시오(처음에 Windows 2003을 기억하십니까?)
• 불필요한 시스템을 켜두지 마세요. (비뇨기과 전문의 홈페이지는 왜 있는 걸까요?)
• 사용자 비밀번호를 직접 확인하세요(그렇지 않으면 군인... 침투 테스터가 이 작업을 수행합니다).
• 다른 계정에 동일한 비밀번호를 사용하지 않음(VDI 손상)
• 및 기타

물론 이것은 구현하기가 매우 어렵지만 다음 기사에서는 실제로 이것이 가능하다는 것을 보여줄 것입니다.

출처 : habr.com