Một câu chuyện về nghiên cứu và phát triển gồm 3 phần. Phần 1 mang tính chất khám phá.
Có rất nhiều cây sồi - thậm chí còn có nhiều lợi ích hơn.
Báo cáo sự cố
Trong các chiến dịch pentest và RedTeam, không phải lúc nào cũng có thể sử dụng các công cụ tiêu chuẩn của Khách hàng, chẳng hạn như VPN, RDP, Citrix, v.v. như một mỏ neo để vào mạng nội bộ. Ở một số nơi, VPN tiêu chuẩn hoạt động bằng cách sử dụng MFA và mã thông báo phần cứng được sử dụng làm yếu tố thứ hai, ở những nơi khác, nó bị giám sát chặt chẽ và thông tin đăng nhập VPN của chúng tôi ngay lập tức hiển thị, như người ta nói, với tất cả những gì nó đòi hỏi, nhưng ở những nơi khác thì có đơn giản là không có phương tiện như vậy.
Trong những trường hợp như vậy, chúng tôi liên tục phải tạo ra cái gọi là “đường hầm ngược” - kết nối từ mạng nội bộ đến tài nguyên bên ngoài hoặc máy chủ mà chúng tôi kiểm soát. Bên trong đường hầm như vậy, chúng tôi đã có thể làm việc với nguồn lực nội bộ của Khách hàng.
Có một số loại đường hầm quay trở lại này. Tất nhiên, nổi tiếng nhất trong số đó là Meterpreter. Các đường hầm SSH với tính năng chuyển tiếp cổng ngược cũng đang có nhu cầu lớn trong cộng đồng hacker. Có khá nhiều phương tiện để thực hiện đường hầm ngược và nhiều phương tiện trong số đó đã được nghiên cứu và mô tả kỹ lưỡng.
Tất nhiên, về phần mình, các nhà phát triển giải pháp bảo mật không đứng ngoài cuộc và chủ động phát hiện những hành động đó.
Ví dụ: các phiên MSF được phát hiện thành công bởi IPS hiện đại của Cisco hoặc Positive Tech và hầu hết mọi tường lửa thông thường đều có thể phát hiện ra đường hầm SSH ngược.
Do đó, để không bị chú ý trong một chiến dịch RedTeam tốt, chúng tôi cần xây dựng một đường hầm ngược bằng các phương tiện không chuẩn và thích ứng càng sát với chế độ hoạt động thực của mạng càng tốt.
Hãy thử tìm hoặc phát minh ra thứ gì đó tương tự.
Trước khi phát minh ra bất cứ thứ gì, chúng ta cần hiểu kết quả mà chúng ta muốn đạt được, sự phát triển của chúng ta nên thực hiện những chức năng gì. Những yêu cầu đối với đường hầm để chúng ta có thể làm việc ở chế độ tàng hình tối đa là gì?
Rõ ràng là đối với mỗi trường hợp, các yêu cầu như vậy có thể khác nhau rất nhiều, nhưng dựa trên kinh nghiệm làm việc, có thể xác định được những yêu cầu chính:
- hoạt động trên hệ điều hành Windows-7-10. Vì hầu hết các mạng công ty đều sử dụng Windows;
- máy khách kết nối với máy chủ qua SSL để tránh việc nghe lén bằng ips;
- Khi kết nối, máy khách phải hỗ trợ công việc thông qua máy chủ proxy có ủy quyền, bởi vì Ở nhiều công ty, việc truy cập Internet diễn ra thông qua proxy. Trên thực tế, máy khách thậm chí có thể không biết gì về nó và proxy được sử dụng ở chế độ trong suốt. Nhưng chúng tôi phải cung cấp chức năng đó;
- phần khách hàng phải ngắn gọn và dễ mang theo;
Rõ ràng là để hoạt động trong mạng của Khách hàng, bạn có thể cài đặt OpenVPN trên máy khách và tạo một đường hầm chính thức tới máy chủ của mình (may mắn thay, các máy khách openvpn có thể hoạt động thông qua proxy). Tuy nhiên, thứ nhất, điều này không phải lúc nào cũng hiệu quả, vì chúng tôi có thể không phải là quản trị viên địa phương ở đó, và thứ hai, nó sẽ gây ồn ào đến mức một SIEM hoặc HIPS tử tế sẽ ngay lập tức “bắt nạt” chúng tôi. Lý tưởng nhất là ứng dụng khách của chúng ta phải là một lệnh nội tuyến, chẳng hạn như nhiều bash shell được triển khai và khởi chạy thông qua dòng lệnh, chẳng hạn như khi thực thi các lệnh từ macro từ. - đường hầm của chúng tôi phải đa luồng và hỗ trợ nhiều kết nối cùng lúc;
- kết nối máy khách-máy chủ phải có một số loại ủy quyền để đường hầm chỉ được thiết lập cho máy khách của chúng tôi chứ không phải cho tất cả những người đến máy chủ của chúng tôi tại địa chỉ và cổng được chỉ định. Lý tưởng nhất là một trang đích có mèo hoặc các chủ đề chuyên môn liên quan đến tên miền ban đầu sẽ mở cho “người dùng bên thứ ba”.
Ví dụ: nếu Khách hàng là một tổ chức y tế, thì quản trị viên bảo mật thông tin sẽ quyết định kiểm tra tài nguyên mà nhân viên phòng khám đã truy cập, một trang có các sản phẩm dược phẩm, Wikipedia với mô tả chẩn đoán hoặc blog của bác sĩ Komarovsky, v.v. . nên mở.
Phân tích các công cụ hiện có
Trước khi phát minh lại chiếc xe đạp của riêng mình, bạn cần phân tích những chiếc xe đạp hiện có và hiểu liệu chúng ta có thực sự cần nó hay không và có lẽ chúng ta không phải là những người duy nhất nghĩ đến sự cần thiết của một chiếc xe đạp chức năng như vậy.
Tìm kiếm trên Internet (chúng tôi dường như google bình thường), cũng như tìm kiếm trên Github với từ khóa “vớ ngược” không cho nhiều kết quả. Về cơ bản, tất cả đều bắt nguồn từ việc xây dựng các đường hầm ssh với tính năng chuyển tiếp cổng ngược và mọi thứ được kết nối với nó. Ngoài các đường hầm SSH, còn có một số giải pháp:
Một triển khai lâu dài về đường hầm ngược từ những người ở Kaspersky Lab. Cái tên cho thấy rõ kịch bản này nhằm mục đích gì. Được triển khai bằng Python 2.7, đường hầm hoạt động ở chế độ văn bản rõ ràng (như cách nói thời nay - xin chào RKN)
Một cách triển khai khác bằng Python, cũng ở dạng văn bản rõ ràng, nhưng có nhiều khả năng hơn. Nó được viết dưới dạng một mô-đun và có API để tích hợp giải pháp vào các dự án của bạn.
Liên kết đầu tiên là phiên bản gốc của việc triển khai Reverse Sox ở Golang (không được nhà phát triển hỗ trợ).
Liên kết thứ hai là bản sửa đổi của chúng tôi với các tính năng bổ sung, cũng ở Golang. Trong phiên bản của chúng tôi, chúng tôi đã triển khai SSL, hoạt động thông qua proxy có ủy quyền NTLM, ủy quyền trên máy khách, trang đích trong trường hợp mật khẩu không chính xác (hay đúng hơn là chuyển hướng đến trang đích), chế độ đa luồng (tức là nhiều người có thể hoạt động với đường hầm cùng lúc), một hệ thống ping máy khách để xác định xem anh ta còn sống hay không.
Triển khai Reverse sox từ “những người bạn Trung Quốc” của chúng tôi bằng Python. Ở đó, dành cho những kẻ lười biếng và “bất tử”, có một tệp nhị phân (exe) làm sẵn, do người Trung Quốc lắp ráp và sẵn sàng để sử dụng. Ở đây, chỉ có Chúa Trung Quốc mới biết nhị phân này có thể chứa những gì khác ngoài chức năng chính, vì vậy hãy tự chịu rủi ro khi sử dụng.
Một dự án khá thú vị trong C++ để triển khai sox ngược và hơn thế nữa. Ngoài đường hầm ngược, nó có thể thực hiện chuyển tiếp cổng, tạo shell lệnh, v.v.
máy đo MSF
Ở đây, như họ nói, không có bình luận. Tất cả các tin tặc ít nhiều đều rất quen thuộc với điều này và hiểu nó có thể bị phát hiện dễ dàng như thế nào bởi các công cụ bảo mật.
Tất cả các công cụ được mô tả ở trên đều hoạt động bằng công nghệ tương tự: mô-đun nhị phân thực thi được chuẩn bị trước được khởi chạy trên một máy bên trong mạng, thiết lập kết nối với máy chủ bên ngoài. Máy chủ chạy máy chủ SOCKS4/5 chấp nhận các kết nối và chuyển tiếp chúng đến máy khách.
Điểm bất lợi của tất cả các công cụ trên là phải cài đặt Python hoặc Golang trên máy khách (bạn có thường thấy Python được cài đặt trên máy của giám đốc công ty hoặc nhân viên văn phòng không?) hoặc một công cụ được lắp ráp sẵn. nhị phân (thực ra là python) phải được kéo vào máy này và tập lệnh trong một chai) và chạy tệp nhị phân này ở đó. Và việc tải xuống một exe rồi khởi chạy nó cũng là một dấu hiệu cho phần mềm chống vi-rút cục bộ hoặc HIPS.
Nói chung, kết luận tự nó đã gợi ý - chúng ta cần một giải pháp powershell. Bây giờ cà chua sẽ bay về phía chúng tôi - họ nói rằng powershell đã bị hack, nó bị theo dõi, bị chặn, v.v. và như thế. Trong thực tế, không phải ở khắp mọi nơi. Chúng tôi tuyên bố có trách nhiệm. Nhân tiện, có rất nhiều cách để vượt qua việc chặn (ở đây lại có một cụm từ thời thượng về xin chào RKN 🙂), bắt đầu từ việc đổi tên ngu ngốc powershell.exe -> cmdd.exe và kết thúc bằng powerdll, v.v.
Hãy bắt đầu phát minh
Rõ ràng là trước tiên chúng tôi sẽ tìm trên Google và… chúng tôi sẽ không tìm thấy bất kỳ điều gì về chủ đề này (nếu ai đó đã tìm thấy nó, hãy đăng liên kết trong phần bình luận). chỉ có Socks5 trên powershell, nhưng đây là một sox "trực tiếp" thông thường, có một số nhược điểm riêng (chúng ta sẽ nói về chúng sau). Tất nhiên, bạn có thể biến nó thành một cái ngược lại, chỉ bằng một cử động nhẹ của bàn tay, nhưng đây sẽ chỉ là sox một luồng, đây không hẳn là thứ chúng ta cần.
Vì vậy, chúng tôi chưa tìm thấy bất cứ thứ gì làm sẵn, vì vậy chúng tôi vẫn sẽ phải phát minh lại bánh xe của mình. Chúng tôi sẽ lấy làm cơ sở cho chiếc xe đạp của mình đảo ngược sox ở Golang và chúng tôi triển khai ứng dụng khách cho nó trong powershell.
RSocksTun
Vậy rsockstun hoạt động như thế nào?
Hoạt động của RsocksTun (sau đây gọi tắt là rs) dựa trên hai thành phần phần mềm - máy chủ Yamux và Socks5. Máy chủ Vớ5 là một máy chủ vớ5 cục bộ thông thường, nó chạy trên máy khách. Và việc ghép kênh các kết nối tới nó (bạn có nhớ về đa luồng không?) được cung cấp bằng yamux (). Lược đồ này cho phép bạn khởi chạy một số máy chủ vớ5 máy khách và phân phối các kết nối bên ngoài tới chúng, chuyển tiếp chúng thông qua một kết nối TCP duy nhất (gần giống như trong máy đo tốc độ) từ máy khách đến máy chủ, từ đó triển khai chế độ đa luồng, nếu không có chế độ này chúng ta sẽ không thể có thể làm việc hoàn toàn trong mạng nội bộ.
Bản chất của cách thức hoạt động của yamux là nó giới thiệu một lớp luồng mạng bổ sung, triển khai nó dưới dạng tiêu đề 12 byte cho mỗi gói. (Ở đây chúng tôi cố tình sử dụng từ “luồng” chứ không phải luồng, để không khiến người đọc nhầm lẫn với “luồng” luồng chương trình - chúng tôi cũng sẽ sử dụng khái niệm này trong bài viết này). Tiêu đề yamux chứa số luồng, cờ để cài đặt/kết thúc luồng, số byte được truyền và kích thước của cửa sổ truyền.
Ngoài việc cài đặt/chấm dứt luồng, yamux còn triển khai cơ chế duy trì cho phép bạn giám sát hiệu suất của kênh liên lạc đã thiết lập. Hoạt động của cơ chế thông báo keeplive được định cấu hình khi tạo phiên Yamux. Trên thực tế, trong cài đặt chỉ có hai tham số: bật/tắt và tần suất gửi gói tính bằng giây. Tin nhắn lưu giữ có thể được gửi bởi máy chủ yamux hoặc máy khách yamux. Khi nhận được một tin nhắn lưu giữ, bên ở xa phải phản hồi nó bằng cách gửi chính xác mã nhận dạng tin nhắn (thực tế là một số) mà họ đã nhận được. Nói chung, keepalive có cùng ping, chỉ dành cho yamux.
Toàn bộ kỹ thuật vận hành của bộ ghép kênh: các loại gói, cờ thiết lập và kết thúc kết nối cũng như cơ chế truyền dữ liệu được mô tả chi tiết trong tới yamux.
Kết luận cho phần đầu tiên
Vì vậy, trong phần đầu của bài viết, chúng ta đã làm quen với một số công cụ tổ chức đường hầm ngược, xem xét ưu điểm và nhược điểm của chúng, nghiên cứu cơ chế hoạt động của bộ ghép kênh Yamux và mô tả các yêu cầu cơ bản đối với mô-đun powershell mới được tạo. Trong phần tiếp theo, chúng tôi sẽ tự phát triển mô-đun này từ đầu. Còn tiếp. Đừng chuyển đổi :)
Nguồn: www.habr.com