Trong quản trị hệ thống các anh em hay có như cầu chuyển đổi hệ thống ảo hóa qua lại với nhau từ các môi trường ảo hóa VMware Esxi sang hyper-v hoặc Hyper-V qua VMware Esxi, việc chuyển đổi này tương đương việc đổi các định dạng disk hệ thống cho phù hợp, Ví dụ Vmware (VMDK)=> Hyper-V (VHDX) hoặc ngược lại. Hôm nay Phương Nguyễn giới thiệu 1 tính năng rất hay của Veeam backup & Replication dùng để convert từ máy ảo VM từ môi trường VMware Vsphere Esxi sang Hyper-V nhé.
Thông tin
VM đang chạy ESXI6.7 đang chạy dịch vụ Microsoft Exchange 2016
Host Đang chạy Hyper-V cần move máy ảo Exchange qua.
Server Veeam backup & Replication v11 đã setup
Nhu cầu cần chuyển VM đang chạy Dịch vụ Microsoft Exchange 2016
Thực hiện
Tiến hành dùng Veeam and Replication để backup VM trên ESXI 6.7
Sau backup xong tiến hành restore chọn Hyper-V
Từ Home->backup->VM vừa backup xong chúng ta tận dụng tính năng Instant Recovery-> Microsoft Hyper-V. Ở đây có 2 tùy chọn VMware vsphere, nghĩa môi trường ngược lại thì chúng ta backup hyper-v restore sang Vmware, lab tôi đang cần move qua Hyper-V.
Chọn restore point cũng được, mặc định sẽ chọn backup cuối cùng
Chọn Host-> chọn Server Hyper-V cần migration qua
Chúng ta chọn nơi lưu cấu hình và disk cho VM cần move qua
Network để sau khi restore config sau
Giữ lưu UUID cũ,
Xem có scan virus không không cần bỏ qua
Retoring Instance nghĩa là sẽ mount trực tiếp từ respoisty lên làm datastores để chạy trực tiếp từ Hyper-V móc vào các Veeam backup nhé, mục tiêu giúp chạy nhanh giải quyết bussiness có thể giảm thiểu downtime hệ thống. Trạng thái các bạn đang thấy là status đã mounted.
Về mặt production sau khi đảm bảo giải quyết câu chuyện backup thì chúng ta sẽ chọn vào restore để migration to production chuyển đổi hoàn toàn luôn, nghĩa là sẽ copy và restoring sang host hyper-v nhé.
Khi migration to production chuyển trạng thái mounted-> restoring nhé.
Restore thành công nhé.
Như vậy là thành công chuyển đổi máy ảo Exchange 2016 từ môi trường VMware esxi vsphere sang môi trường Microsoft Hyper-V. Ngoài công cụ Veeam backup & replication có thể có nhiều công cụ giúp chúng ta chuyển đổi V2V, P2V… các bạn đoán xem phần 2 tại đây nhé.
Đối với 1 quản trị viên, IT system hoặc Helpdesk thì các phần mềm hiển kiểm tra và đo nhiệt độ CPU trong bài viết này sẽ là trợ thủ đắc lực để bạn kiểm tra hiệu suất máy tính để tiện cho việc sửa chữa, khắc phục hoặc nâng cấp nếu cảm thấy cần thiết. Các công cụ này cũng là giúp các anh em báo cáo cũng như đưa ra con số định lượng, bằng chứng xác thực giúp đánh giá máy tính, tình trạng disk để có cơ sở nâng cấp.
Top 10 phần mềm kiểm tra và đo nhiệt độ CPU máy tính chính xác nhất hiện nay
AIDA64 Extreme thực sự là một phần mềm kiểm tra và đo nhiệt độ CPU nổi danh với khả năng thông báo hết sức chi tiết tình trạng phần cứng, từ đó thay người dùng đánh giá mức độ hiệu quả trong quá trình thiết bị vận hành. Các chức năng nổi trội của AIDA64 Extreme bao gồm đánh giá lỗi phần cứng, kiểm soát hoạt động CPU và khả năng đo nhiệt độ CPU.
Phần mềm đo nhiệt độ CPU Speedfan từ lâu đã được biết đến là một trong những công cụ hỗ trợ đo nhiệt độ CPU tốt nhất trên thị trường. Ngoài khả năng theo dõi hiệu quả tốc độ quạt, điện áp và mức nhiệt hiện tại của máy tính, CPU Speedfan con cho phép hiệu chỉnh tốc độ quạt theo ý muốn. Điều này giúp chủ nhân thiết bị chủ động được nếu cảm thấy quạt CPU chạy quá nhanh, quá chậm hay quá ồn.
CPU-Z được không ít người lựa chọn khi kiếm tìm một phần mềm hiển thị tốc độ CPU nhẹ và hiệu quả. CPU-Z nổi danh nhờ khả năng thống kê tên CPU, tên mã, chipset, chỉ số TDP tối đa, loại chân cắm CPU. Thông qua CPU-Z, bạn sẽ kiểm tra được nhiều thông tin về phần cứng thiết bị, dữ liệu CPU máy tính và bộ nhớ cache, đồng thời đo nhiệt độ CPU hiệu quả.
Nếu bạn cần một công cụ giám sát phần cứng hiệu quả thì CPUID HWMonitor sẽ là sự lựa chọn hết sức hợp lý bởi phần mềm này có thể theo dõi những chỉ số ảnh hưởng trực tiếp đến sức mạnh của hệ thống. CPUID HWMonitor có giao diện rất dễ dùng, nổi bật ở khả năng nhận biết nhiệt độ ổ cứng qua card video GPU và S.M.A.R.T.
Ngoài việc phản ảnh nhiệt độ CPU, phần mềm Speccy còn tỏ ra nổi trội ở việc hiển thị đầy đủ thông tin về CPU, RAM, Motherboard, Graphics, ổ cứng, ổ CD và Audio. Sự toàn diện và tính giản đơn của Speccy đem tới một phương án hữu hiệu nhất dành cho những ai muốn nắm được thông tin nhiệt độ cùng với hiệu suất phần cứng trên chiếc PC, laptop mình đang dùng.
Với HWiNFO64, người dùng có thể theo dõi nhiều thông tin chi tiết về tình trạng hoạt động cũng như những thông tin phần cứng như CPU hay RAM máy tính. Mọi chỉ số cần thiết như tốc độ quạt, nhiệt độ, nguồn và điện thế được hiển thị đầy đủ trong giao diện cũng góp phần biến HWiNFO64 thành công cụ giám sát hệ thống đắc lực.
Với HWiNFO64, người dùng có thể theo dõi nhiều thông tin chi tiết về tình trạng hoạt động cũng như những thông tin phần cứng như CPU hay RAM máy tính. Mọi chỉ số cần thiết như tốc độ quạt, nhiệt độ, nguồn và điện thế được hiển thị đầy đủ trong giao diện cũng góp phần biến HWiNFO64 thành công cụ giám sát hệ thống đắc lực.
Nổi bật ở tác vụ phân tích nhiệt độ các loại chip máy tính, Real Temp là công cụ hỗ trợ quản lý quá trình làm việc hết sức đắc lực, giúp bạn thấy được đâu mới là tốc độ lý tưởng nhất cho chiếc PC/laptop mà mình sở hữu. Bạn cũng có thể thông qua Real Temp để biết được nhiệt độ tối thiểu và tối đa của cả hệ thống.
Nhờ giao diện thiết kế đẹp mắt mang phong cách gaming và khả năng hỗ trợ ép xung laptop chuyên nghiệp, MSI After burner trở thành phần mềm hiển thị nhiệt độ CPU trên laptop được nhiều game thủ lựa chọn. Nhìn trong hình dưới, chắc hẳn bạn cũng thấy rõ chỉ số tốc độ CPU được đặt ở vị trí rất dễ quan sát. Ngoài ra, bạn còn có thể thông qua MSI After burner để hiệu chỉnh tốc độ quạt và gia tăng hiệu suất bộ nhớ.
10. NZXT’s Cam software
Đây là một phần mềm có giao diện khá đẹp, thân thiện và dễ dùng, bao gồm nhiều mục giám sát như CPU, GPU, HDD, Network….Ngoài ra,bạn có thể mua 1 số linh kiện của hãng NZXT để dùng trong cùng 1 ứng dụng như mod đèn, chỉnh các chế độ đèn case…
Cách kiểm tra nhiệt độ CPU máy tính không cần phần mềm
Để thực hiện cách kiểm tra nhiệt độ CPU không cần phần mềm này, bạn cần mở BIOS bằng cách khởi động lại máy tính, sau đó nhấn các phím chức năng (Fn) ngay khi logo thương hiệu hiện ra.
Lúc này, bạn truy cập vào mục Power. Tại dòng CPU Temperature, hệ thống sẽ cho bạn thấy được mức nhiệt của CPU hiện tại là bao nhiêu.
It is important to configure the network adapter settings correctly for a DAG member. Few points that need to be noted:
Single NIC for DAG members is supported.
All DAG members should have the same number of networks, MAPI and Replication networks.
DAG members can have only one MAPI network and zero or more Replication networks.
Persistent static routes are used to configure traffic in a replication network.
It is recommended to have atleast two DAG networks, MAPI and a replication network.
The MAPI network should be connected to the production network, so that it can talk with other Exchange servers, AD, DNS etc. The MAPI network (NIC) should be configured as given in the table below.
Networking Features
Setting
Client for Microsoft Networks
Enabled
QoS Packet Scheduler
Optionally enable
File and Printer Sharing for Microsoft Networks
Enable
Internet Protocol Version 6 (TCP/IP v6)
Optionally enable
Internet Protocol Version 4 (TCP/IP v4)
Enabled
Link-Layer Topology Discovery Mapper I/O Driver
Enabled
Link-Layer Topology Discovery Responder
Enabled
Configure the following as well for the MAPI network.
The IP address can be manually assigned or configured to use DHCP. If DHCP is used, use persistent reservations for server’s IP address.
The MAPI network typically uses a default gateway, although one isn’t required.
At least one DNS server address must be configured. Using multiple DNS servers for redundancy.
The “Register this connection’s addresses in DNS” checkbox should be checked.
The Replication network (NIC) should be configured as given in the table below.
Networking Features
Setting
Client for Microsoft Networks
Disabled
QoS Packet Scheduler
Optionally enable
File and Printer Sharing for Microsoft Networks
Disabled
Internet Protocol Version 6 (TCP/IP v6)
Optionally enable
Internet Protocol Version 4 (TCP/IP v4)
Enabled
Link-Layer Topology Discovery Mapper I/O Driver
Enabled
Link-Layer Topology Discovery Responder
Enabled
Configure the following as well for the MAPI network.
The IP address can be manually assigned or configured to use DHCP. If DHCP is used, use persistent reservations for server’s IP address.
The Replication network typically doesn’t use a default gateway. If MAPI network has a gateway configured, then, no other networks should have a default gateway.
DNS server address should not be configured.
The “Register this connection’s addresses in DNS” checkbox should be unchecked.
Finally, the binding order has to be such that MAPI network comes first in the list.
Có một điều khi chúng ta đã cài Microsoft Exchange Server mà đã kích hoạt bản quyền key là Enterprise. Vì 1 lý do nào đó cần chuyển đối từ Enterprise về standard. Theo Microsoft thì khả năng từ nhỏ lên cao có thể ugprade ok tuy nhiên hạ cấp từ Enterprise về standard thì như thế nào ?
Hôm nay Phương Nguyễn chia sẽ các bạn cách hạ cấp key license Exchange Server đã kích hoạt từ Enterprise về standard, Như chúng ta đã biết các sương sống của Exchange chính là hệ thống domain controller nghĩa là mọi thông tin Exchange đều lưu trên Active Directory, nên chúng ta sẽ căn cứ vào đây để by-pass nhé.
Các bước như sau:
Bước 1: Chúng ta logon vào Domain controller mở run gỏ lệnh adsiedit.msc
Bước 2: Right click->Chọn Connect to => Configuration
Bước 3: Theo đường dẫn sau:
Mở Configuration > Services > Microsoft Exchange > Domain/Org > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) > Servers
Thay domain của các bạn nhé: ví dụ đây là PHUONG2.lab
Configuration > Services > Microsoft Exchange >PHUONGIT > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) >Servers
Bước 4 Chọn phải chuột vào Server ví dụ đây là Lab-EX2019 => chọn thuộc tính msExchProductID clear trắng nhé, có thể copy lại lưu 1 bản.
Chọn Clear => chọn oke nhé lưu lại
Quay lại Exhange Server để nhập lại key hoặc Powershell
Khoảng từ đầu tháng 08/2022, trong quá trình thực hiện giám sát an ninh mạng và xử lý sự cố, Trung tâm vận hành bảo mật GTSC SOC phát hiện một đơn vị trọng yếu bị tấn công an ninh mạng vào hệ thống ứng dụng Microsoft Exchange. Quá trình điều tra, đội ngũ chuyên gia BlueTeam xác định kẻ tấn công đã sử dụng một lỗ hổng bảo mật của Microsoft Exchange chưa từng được công bố – hay còn gọi là lỗ hổng 0-day. GTSC SOC Team ngay lập tức đưa ra phương án ngăn chặn tạm thời. Song song, các chuyên gia RedTeam cũng bắt tay ngay vào việc nghiên cứu, debug lại mã nguồn ứng dụng Mail Exchange để tìm ra mã khai thác (exploit). Với lỗ hổng bảo mật Exchange trước đây, đội ngũ RedTeam cũng đã từng phân tích ra exploit trước khi có exploit được public trên thế giới (1-day exploit) nên việc hiểu luồng, cơ chế xử lý của hệ thống Email Exchange đã giúp giảm thời gian cho quá trình research. Ngay sau khi nghiên cứu ra exploit, GTSC đã submit lên ZDI để làm việc với Microsoft nhằm nhanh chóng có bản vá.
Sau khi ZDI verify đã ghi nhận 2 bug liên quan đến exploit:
Tuy nhiên đến thời điểm hiện tại, GTSC ghi nhận thêm các đơn vị khác cũng đang gặp phải sự cố. Sau khi kiểm tra, GTSC xác nhận hệ thống bị tấn công qua lỗ hổng 0-day này. Để hỗ trợ cộng đồng ngăn chặn tạm thời trước khi có bản vá chính thức từ Microsoft, chúng tôi công bố bài viết này để cảnh báo tới các đơn vị có sử dụng hệ thống email Microsoft Exchange.
Thông tin lỗ hổng bảo mật
– Đội ngũ Blueteam trong quá trình giám sát phát hiện được các request exploit dựa trên log IIS có định dạng giống như lỗ hổng ProxyShell: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com. Đồng thời kiểm tra các logs khác, nhận thấy kẻ tấn công thực hiện được các câu lệnh trên hệ thống. Kiểm tra version number trên máy chủ Exchange bị tấn công nhận thấy máy chủ đã cài đặt bản cập nhật mới nhất tại thời điểm đó nên không thể có trường hợp khai thác bởi lỗ hổng Proxyshell -> xác nhận máy chủ bị khai thác bởi lỗ hổng 0-day RCE mới. Các thông tin này được Blueteam cung cấp lại cho Redteam, từ đó đội ngũ Redteam của GTSC đã tiến hành nghiên cứu để trả lời cho các câu hỏi như tại sao các request lại giống với request của bug ProxyShell?, luồng RCE được thực hiện như thế nào?
– Kết quả nghiên cứu đã giúp GTSC Redteam thành công tìm ra cách sử dụng đường dẫn trên để truy cập tới 1 component ở backend và thực hiện RCE. Thông tin kỹ thuật chi tiết về lỗ hổng tại thời điểm này chúng tôi xin phép chưa công bố.
Các hành vi sau khai thác
Sau quá trình khai thác thành công lỗ hổng, chúng tôi ghi nhận các hành vi tấn công nhằm thu thập thông tin và tạo chỗ đứng trong hệ thống của nạn nhân. Nhóm tấn công cũng sử dụng các kỹ thuật khác nhau nhằm tạo backdoor trên hệ thống bị ảnh hưởng và thực hiện lateral movement sang các máy chủ khác trong hệ thống.
Webshell
Chúng tôi phát hiện các webshell được drop xuống các máy chủ exchange. Các webshell chúng tôi thu thập được hầu hết được obfuscated. Thông qua User-agent chúng tôi phát hiện attacker sử dụng Antsword (một opensource có tính năng hỗ trợ quản lý webshell).
Chúng tôi nghi ngờ các hành vi khai thác này xuất phát từ các nhóm tấn công Trung Quốc, dựa trên codepage trong webshell là 936, một bảng mã ký tự Microsoft cho tiếng Trung giản thể (simplified Chinese).
Một đặc điểm đáng chú ý khác, bên cạnh việc drop các webshell mới hacker cũng thực hiện thay đổi nội dung trong file RedirSuiteServiceProxy.aspx thành nội dung webshell. RedirSuiteServiceProxy.aspx là một tên file hợp pháp sẵn có trong máy chủ Exchange
Bên cạnh các hành vi thu thập thông tin trên hệ thống, attacker thực hiện tải file và kiểm tra kết nối thông qua certutil có sẵn trên môi trường Windows
Ở cuối của mỗi câu lệnh mà kẻ tấn công thực hiện đều có chuỗi echo [S]&cd&echo [E], một trong những dấu hiệu nhận biết của China Chopper.
Ngoài ra, hacker cũng thực hiện inject DLL độc hại vào bộ nhớ, drop các file nghi ngờ lên các máy chủ bị tấn công, và thực thi các file này thông qua WMIC.
Suspicious File
Trên các máy chủ, chúng tôi phát hiện các file nghi ngờ có định dạng exe và dll
Trong số các file nghi ngờ trên, dựa vào các câu lệnh được thực hiện trên máy chủ, chúng tôi nhận định các file all.exe, dump.dll có nhiệm vụ trích xuất thông tin tài khoản trên hệ thống máy chủ. Sau các hành vi trích xuất thông tin tài khoản trên hệ thống, attacker sử dụng rar.exe để nén các file dump và copy ra webroot của máy chủ Exchange. Trong quá trình xử lý sự cố, các file trên đã không còn tồn tại trên hệ thống.
File cm.exe được drop xuống thư mục C:\PerfLogs\ là file cmd.exe
GTSC phân tích một mẫu cụ thể (074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82) để mô tả hành vi của mã độc, các mẫu DLL khác có nhiệm vụ và hành vi giống nhau, chỉ khác nhau về cấu hình listener
DLL gồm 2 hai class: Run và m. Bên trong mỗi class gọi tới các method thực hiện các nhiệm vụ khác nhau. Cụ thể:
Class Run thực hiện tạo listener lắng nghe các kết nối tới port 443, đường dẫn https://*:443/ews/web/webconfig/.
Sau quá trình lắng nghe, mã độc tạo thread mới goi tới r. Method r thực hiện:
– Kiểm tra request nhận được có data trong body hay không. Nếu không có data đi kèm trong request gửi lên máy chủ, kết quả trả về là 404.
– Ngược lại, nếu trong request có đi kèm data, DLL tiếp tục xử lý luồng bên trong nhánh IF:
Kiểm tra request nhận được có tồn tại “RPDbgEsJF9o8S=” hay không. Nếu có, gọi tới method i nằm trong class m để xử lý request nhận được. Kết quả trả về từ Run.m.i sẽ được covert sang chuỗi base64. Kết quả trả về cho client theo format
{
“result”:1,
“message”:”base64(aes(result))”
}
Class m
Method i thực hiện:
– Giải mã request nhận được bằng thuật toán AES với 16 bytes đầu tiên của request là giá trị IV, 16 bytes tiếp theo là giá trị key, các giá trị sau đó là data
– Sau khi giải mã, lấy phần tử đầu tiên trong mảng làm flag để xử lý các case đã được định nghĩa
Case 0: Gọi tới method info. Method này có nhiệm vụ thu thập thông tin hệ thống. Các thông tin bao như kiến trúc hệ điều hành, phiên bản framework, phiên bản hệ điều hành, v.v….GTSC mô phỏng lại case 0 bằng hình ảnh bên dưới. Request gửi lên theo format 16 bytes đầu là giá trị IV, 16 bytes tiếp theo là giá trị key, theo sau là flag để chỉ định option và phần còn lại là data.
base64 (IV | key | aes(flag|data))
Case 1: Gọi tới method sc. Method này có nhiệm vụ cấp phát vùng nhớ để thực thi shellcode
Case 2: Gọi tới 2 method p và r. Method p xử lý các dữ liệu được ngăn cách bởi ký tự “|” lưu vào mảng array3. Mảng array3 sẽ lấy 2 phần tử đầu tiên làm tham số cho method r, method r có nhiệm vụ thực thi command
Case 3: Gọi tới method ld. Method này có nhiệm vụ liệt kê thông tin thư mục và file theo format
D|-|<Ngày tạo> |<Ngày chỉnh sửa> |<tên thư mục hoặc tên file>
o Case 4: Gọi tới method wf. Method này có nhiệm vụ ghi file
o Case 5: Gọi tới method rf. Method này có nhiệm vụ đọc file
Case 6: Tạo thư mục
o Case 7: Xóa file hoặc thư mục
o Case 8: Di chuyển File
o Case 9: Set time cho file
o Case 10: Nạp và thực thi C# bytecode nhận từ request.
Các mẫu DLL khác có nhiệm vụ tương tự, chỉ khác nhau về cấu hình listener như sau:
Chúng tôi cũng phát hiện DLL được inject vào memory của tiến trình svchost.exe. DLL thực hiện kết nối gửi nhận dữ liệu tới địa chỉ 137[.]184[.]67[.]33 được config trong binary. Việc gửi nhận dữ liệu với C2 sử dụng thuật toán RC4, khóa sẽ được tạo trong thời gian chạy (runtime).
Các biện pháp ngăn chặn tạm thời
Quá trình xử lý sự cố trực tiếp của GTSC ghi nhận có trên 1 đơn vị tổ chức bị là nạn nhân của chiến dịch tấn công khai thác lỗ hổng zero day. Ngoài ra chúng tôi cũng lo ngại rằng có thể có nhiều tổ chức khác cũng đã bị khai thác nhưng chưa được phát hiện. Trong thời gian chờ đợi bản vá chính thức từ hãng, GTSC cung cấp biện pháp khắc phục tạm thời nhằm giảm thiểu việc tấn công khai thác lổ hổng bằng cách bổ sung rule chặn các request có dấu hiệu tấn công thông qua module URL Rewrite rule trên máy chủ IIS (Webserver)
– Trong Autodiscover tại FrontEnd chọn tab URL Rewrite chọn Request Blocking
– Add thêm chuỗi “.*autodiscover\.json.*\@.*Powershell.*“ vào Pattern (URL Path):
– Condition input: lựa chọn {REQUEST_URI}
Phát hiện tấn công
Nhằm kiểm tra hệ thống đã bị tấn công bởi lổ hỗng này, các đơn vị/tổ chức có thể thực hiện theo các cách thức sau:
Cách 1: Sử dụng powershell với câu lệnh sau: (Sử dụng powershell để thực hiện search trên toàn bộ folder log IIS mất khá nhiều thời gian)
Cấu hình mặc định IIS log nằm tại đường dẫn “%SystemDrive%\inetpub\logs\LogFiles”
Cách 2: Sử dụng công cụ do GTSC phát triển dựa trên dấu hiệu khai thác lỗ hổng, thời gian thực hiện search nhanh hơn so với việc sử dụng powershell. Đường dẫn tải về công cụ: https://github.com/ncsgroupvn/NCSE0Scanner
Cách 3: Sử dụng công cụ của MS luôn nhé Exchange On-premises Mitigation Tool v2 (EOMTv2) link download tại đây
Máy chủ Microsoft Exchange đang là mục tiêu của những kẻ phát tán phần mềm BlackCat Ransomware và có thông tin cho thấy tin tặc đang khai thác các lỗ hổng chưa được vá trên hệ thống để tạo ra phần mềm độc hại mã hóa tệp nói trên.
Người ta đã quan sát thấy rằng trong hơn hai trường hợp, tin tặc có thể đánh cắp thông tin đăng nhập và thông tin chuyển tiếp đến các máy chủ từ xa, để sử dụng dữ liệu đó cho việc tống tiền kép.
Tin tặc đầu tiên tấn công máy chủ nạn nhân trên một ghi chú ban đầu và sau đó được nhìn thấy đang triển khai các tải trọng BlackCat Ransomware trên toàn mạng thông qua PsExec.
Quy trình tấn công như sau:
Microsoft đã lưu ý về tình hình và nghi ngờ rằng các vụ tấn công đang được thực hiện bởi một băng nhóm có liên quan đến ransomware như một hoạt động dịch vụ và đang yêu cầu tất cả các máy chủ trao đổi của họ tuân theo một lời khuyên được đưa ra vào ngày 14 tháng 3 để giảm thiểu các cuộc tấn công ProxyLogon.
Một trong số chúng, một nhóm tội phạm mạng có động cơ tài chính được theo dõi là FIN12, được biết đến với việc triển khai Ryuk, Conti và Hive ransomware trước đây trong các cuộc tấn công chủ yếu nhắm vào các tổ chức chăm sóc sức khỏe.
Công ty công nghệ này đang kêu gọi các tổ chức sử dụng một giải pháp toàn diện như Microsoft 365 Defender của riêng mình để bảo vệ các rủi ro liên quan đến các cuộc tấn công và đã đưa ra lời khuyên chi tiết để hạn chế các vấn đề phát sinh từ các cuộc tấn công mạng.
LƯU Ý- Các phiên bản Ransomware của BlackCat đang hoạt động trên cả phiên bản Windows và Linux và trong môi trường của VMware ESXi. Kể từ năm 2021, phần mềm độc hại mã hóa tệp tin còn được gọi là ransomware ALPHV đã được nhìn thấy yêu cầu 5 triệu đô la từ các nạn nhân của nó.
Bài viết này Phương Nguyễn hướng dẫn các bạn system admin cấu hình bảo mật cho các thiết bị NAS Sysnology phiên bản 7.0 trở lên nhé. Vì những ưu việc tính năng vượt trội của DSM 7.0-7.1 về bảo mật hệ thống cho NAS chống các rủi ro bảo mật hệ thống NAS mà Sysnology mang lại. Bạn nào chưa update thì update ngay nhé. Xem bài viết hướng dẫn update tại đây.
Bảo mật chung-General
Vào control panel-> Chọn security-> General.
Hẹn giờ đăng xuất (phút): Người dùng sẽ tự động đăng xuất khỏi DSM nếu họ không hoạt động trong khoảng thời gian được chỉ định tại đây. Nhập bất kỳ giá trị nào từ 1 đến 65535.
Tăng cường khả năng tương thích của trình duyệt bằng cách bỏ qua kiểm tra IP: Nếu bạn truy cập NAS Synology thông qua proxy HTTP và gặp phải các lần đăng xuất ngẫu nhiên, bạn có thể bật tùy chọn này để bỏ qua kiểm tra IP.
Cải thiện khả năng bảo vệ chống lại các cuộc tấn công giả mạo yêu cầu trên nhiều trang web: Tùy chọn này tăng cường khả năng bảo vệ của hệ thống chống lại các cuộc tấn công tạo kịch bản trên nhiều trang web. Tùy chọn này sẽ có hiệu lực vào lần tiếp theo bạn đăng nhập vào DSM.
Cải thiện bảo mật với tiêu đề Chính sách bảo mật nội dung HTTP (CSP): Tùy chọn này tăng cường bảo mật của hệ thống chống lại các cuộc tấn công tập lệnh xuyên trang (XSS) bằng cách chỉ cho phép dữ liệu từ các nguồn đáng tin cậy và hạn chế thực thi tập lệnh nội tuyến.
Không cho phép nhúng DSM với iFrame: Bạn có thể bật tùy chọn này để hạn chế các trang web khác nhúng DSM vào các trang web khác với iFrame, do đó ngăn chặn một số kiểu tấn công từ các trang web độc hại. Để cho phép các trang web cụ thể nhúng DSM với iFrame, hãy nhấp vào Trang web được phép, thêm trang web, đi tới Bảng điều khiển> Cổng đăng nhập> DSM> Miền, thiết lập miền tùy chỉnh và đánh dấu vào Bật HSTS buộc trình duyệt sử dụng kết nối bảo mật. Đảm bảo rằng NAS Synology của bạn có chứng chỉ hợp lệ.
Xóa tất cả các phiên đăng nhập của người dùng đã lưu khi khởi động lại hệ thống: Tùy chọn này ngăn các lỗi hệ thống không mong muốn xảy ra nếu người dùng vẫn đăng nhập và thực hiện các thao tác trên hệ thống trong khi hệ thống đang sẵn sàng. Với tùy chọn này được bật, tất cả người dùng sẽ cần đăng nhập lại sau khi hệ thống khởi động lại.
Hiển thị thông báo trên màn hình DSM khi IP hiện tại thay đổi: Khi IP của người dùng hiện đang kết nối thay đổi, hãy gửi thông báo trên màn hình cho người dùng đó.
Trust Proxy: có thể đưa vào danh sách list các IP tin tưởng proxy.
Tài khoản-Account
Cần phải đặt mật khẩu phức tạp và bật tính năng xác thực 2 bước 2FA kết hợp với approve sign khi đăng nhập vào quản trị DSM (OTP hoặc HSM)
Tường lửa-Firewall
Cần phải bật tường lửa và cấu hình chính sách truy cập và cho phép dịch vụ nào ip nào truy cập NAS có thể hiểu như 1 Acclist truy cập.
Bảo vệ -Protection
Định nghĩa thời gian truy cập và khóa theo IP có thể cho phép đưa blocklist IP network ip cũng như allow network nào.
Cảnh báo nhanh về lỗ hổng 0day CVE-2022-26809, Lỗ hổng thực thi mã từ xa trong Windows RPC Runtime không cần xác thực đang bị khai thác trong tự nhiên. Lỗ hổng chưa có nhiều thông tin đánh giá và phân tích chi tiết hay PoC được công bố. Tuy vậy cũng cần nắm bắt đề phòng, kịp thời phản ứng. Ngoài ra cũng cập nhật thêm thông tin một số lỗ hổng cần chú ý trong bản vá tháng 4 của Microsoft.
Phạm vi ảnh hưởng/Điều kiện khai thác ( CVE-2022-26809 ):
Hệ thống mở port 445 ra ngoài internet đều dễ bị tấn công
Các phiên bản Windows chưa được cập nhật bản vá tháng 4 mới nhất đều bị ảnh hưởng
Không cần thông tin xác thực
Thông tin chi tiết:
CVE-2022-26809: Windows RPC Runtime RCE không cần xác thực
Lỗ hổng nằm trong thư viện rpcrt4.dll của Windows RPC Runtime. Hai function là OSF_CCALL::ProcessResponse and OSF_SCALL::ProcessReceivedPDU đảm nhận việc xử lý các gói tin RPC ở phía client (CCALL) và server (SCALL).
Trong đó tại hàm QUEUE :: PutOnQueue thuộc OSF_SCALL ::
ProcessReceivePDU có chức năng kiểm tra việc tràn số nguyên ( integer overflows
check ).
int64 fastcall sub_l80042028(unsigned int currentvalue, int addition, int *output) {
unsigned int afterAddition; // eax
int v4; // edx
int64 result; // rax
afterAddition = currentvalue + addition;
v4 = -1;
if ( afterAddition >= currentvalue )
v4 = afterAddition;
result = afterAddition < currentvalue ? 0x80070216 : 0;
’output = v4;
return result;
}
Tại OSF_SCALL:GetCoalescedBuffer việc tràn số nguyên này có thể gây lỗi heap buffer overflow từ đó có thể ghi ngoài giới hạn bộ đệm heap và thực thi mã tùy ý. Một số hàm khác cũng tương tự bao gồm:
OSF_CCALL::ProcessResponse
OSF_SCALL::GetCoalescedBuffer
OSF_CCALL::GetCoalescedBuffer
Một số lỗ hổng cần quan tâm trong Patch Tuesday tháng 4 của Microsoft
Trong tháng 04/2022, Microsoft đã phát hành bản vá cho 117 lỗ hổng (chưa bao gồm 17 lỗ hổng trong Microsoft Edge), trong đó có 9 lỗ hổng được đánh giá ở mức Nghiêm Trọng và 108 lỗ hổng được đánh giá là Quan Trọng. Tỉ trọng số lượng lỗ hổng như sau: Thực thi mã từ xa (RCE) và Leo thang đặc quyền (EoP) đều chiếm tỉ trọng lớn với 39,3%. Trong các lỗ hổng được vá lần này, cần lưu ý một số CVE được Microsoft đánh giá là nguy hiểm, có khả năng bị tấn công cao trong thực tế:
CVE
Lỗ hổng
CVSS
Mô tả
CVE-2022-
26809
RPC Runtime Library Remote Code
9.8
Lỗ hổng thực thi mã từ xa trong RPC Runtime Library. Chưa có thông tin chi
Execution Vulnerability
tiết và PoC liên quan đến lỗ hổng trên không gian mạng.
CVE-2022- 24491/24497
Windows Network File System Remote Code Execution Vulnerability
9.8
Lỗ hổng thực thi mã từ xa trong Windows Network File System. Chưa có thông tin chi tiết và PoC liên quan đến lỗ hổng trên không gian mạng.
CVE-2022-
26815
Windows DNS Server Remote Code Execution Vulnerability
7.2
Lỗ hổng thực thi mã từ xa trong Windows DNS Server. Chưa có thông tin chi tiết và PoC liên quan đến lỗ hổng trên không gian mạng.
CVE-2022-
26904
Windows User Profile Service Elevation of
Privilege Vulnerability
7.0
Lỗ hổng leo thang đặc quyền trong Windows User Profile Service. Lỗ hổng đã có PoC công bố trên không gian mạng.
CVE-2022-
24521
Windows Common Log File System Driver Elevation of Privilege
Vulnerability
7.8
Lỗ hổng leo thang đặc quyền trong Windows Common Log File System Driver. Lỗ hổng chưa có thông tin chi tiết và PoC công bố trên không gian mạng. Tuy nhiên, lỗ hổng đã được khai thác trong thực tế.
Cách phòng tránh/fix lỗi/phát hiện:
Lỗ hổng không có dấu hiệu nhận biết cụ thể. Chặn hoặc hạn chế kết nối từ port 445 từ ngoài mạng internet/mạng không phải kết nối trust. Áp dụng khuyến nghị bảo mật giao thức SMB theo nhà phát triển tại :
Sáng nay có bạn alo hỏi vụ sql tấn công và ăn cua… Tình hình có vẻ căng vụ publishing port SQL Server 1433 nhất là thuê hosting vps. Một số ý khuyến cáo chia sẽ ae bảo mật Server SQL: 1/ Buộc phải có tường lửa nếu thuê hosting thì cũng nên thuê thêm. Còn túng quá change port SQL. 2/ Access policy cho 1 số dịch vụ out in. 3/ Change mật khẩu quản trị sa mức độ phức tạp tránh bị bruce force. 4/ Phân quyền user logon và user ower db cần thiết. Không sử dụng quyền sa hoặc system admin roles để chạy user databases. 5/ Bảo mật chính application các bạn đang chạy như password admin root hay tài khoản có quyền admin… 6/ Update path KB mới nhất MSSQL. 7/ Update Os Windows Server mới nhất. 8/ Cài đặt antivirus và update mới nhất bật ips nếu có ví dụ SEP, Kis, mcafee…. 9/ Công tác này rất quan trọng là rà soát backup 3-2-1 tốt nhất backup lên đám mây và sử dụng VPN tránh bị ăn ransomware… Những ai đang chạy public trực tiếp xem xét khoá lại. Bài viết không nói rõ ứng dụng đích danh nào mà nói chung cho tất cả ứng dụng sử dụng SQL làm CSDL. Nghe đâu SQL server đang bị dính Cobalt Strike.
